Module 3 - Secure Application Design & Architecture

J.NET]
Module Objectives CASE

Understand the Importance of Secure Application Design

Discuss Various Secure Design Principles

Understand Threat Modeling

Describe Threat Modeling Process

Discuss STRIDE and DREAD Model

Describe Secure Application Architecture Design

Page 60
| J NET]
CASE

Most of the web applications are vulnerable due to insecure design of

application at design phase.

J.NET]
CASE

“Secure programming cannot make up for a poor design.”

-- PHP Security Consortium

Page 61
Relative Cost of Fixing Vulnerabilities at Different C §E
Phases of SDLC oo im
Cost of fixing vulnerabilities increases exponentially as SDLC
progresses
100X

3 15%

Ss

i =

Design Development Testing Deployment i

SDLC Phases —
Source: hittp://www.ibm.com
i g g . NET

Secure Application Design and Architecture C | SE

J A security negligence at design and architecture phase may lead to

vulnerabilities that are difficult
to detect and expensive to fix in production
~1 Security vigilance at design phase enables detecting potential
security flaws early in the software
development lifecycle

J Secure design of an application is based on security requirements

identified in the previous phase
of the SDLC

| Secure design is a challenging process as designing required

security controls may obstruct the
business functionality requirements

Page 62
Goal of Secure Design Process

i AN Identifying the threats in sufficient details for developers to

understand and code

® GC

accordingly to mitigate the risk associated with the threats

Designing a architecture in such a way that it mitigates as many

threats as possible

Enforcing secure design principles that force developers to consider

security while coding

Secure Design Actions

Security Requirement
Specifications

Design the application according to security

specifications gathered at requirement phase

{Covered in Module 02: Security Requirements Gathering)

Secure Design Principles

Define the secure coding standards to be

implemented in development phase

Threat Modeling

Perform threat modeling to know your threats

Secure Application
Architecture

Design secure application architecture

Page 63
Secure Design Principles

Define Secure Design Principles CASE

“| Secure design principles are the state of practices or guidelines
that should be enforced on the
developers to follow during development phase

I It helps in deriving secure architectural decisions

| It helps to eliminate design and architecture flaws and mitigate

common security vulnerabilities
within the application

Page 64
Secure Design Principles

J List of secure design principles to prevent common security

vulnerabilities:

Enable auditing and logging

& Fault avoidance
Keep security simple

Loose couplin 1
Separation of duties ping

i Gd & High cohesion

Fix security issues correctly JEniconesial

1
@ Security through obscurity i & Protect sensitive data
1 1
@ Secure the weakest link } @ Exception handling ]
1 1]
@ Use least privilege principle 1 & Secure memory management i
1 1]
1 1
@ Secure by default i @ Protect memory or storage secrets 1
@ Fail securely © Fundamentals of control granularity
© Apply defense in depth i © Fault tolerance i
@ Do not trust user input
p © Fault detection
@ Reduce attack surface 1 :
i & Fault removal }
}
e
[-]
@
@

Apply security in design phase © Change management and version control

Secure Design Principles (Cont'd) CA SE

Security through Obscurity Secure the Weakest Link

@ Security Through Obscurity (STO) relies on © Attackers target a

system that is easy to penetrate
preventing access to certain users to protect
internal data © For example, to gain access to the encrypted data

on the network, attackers will not intercept the

@ STO systems may have theoretical or actual data and crack

encryption; instead they will go
security vulnerabilities, but designers believe after the end points
of communication to find a
that flaws are unknown and attackers are flaw that discloses the data
unlikely to find them

@ Identify and strengthen the areas at risk until

@ Its usefulness has declined with the rise of open levels of risk are
satisfactory
systems, networking, greater understanding of
programming techniques, and increased

\ of home users Ww. J

Page 65
Secure Design Principles (Cont'd) CASE

Use Least Privilege Principle

# Applications with maximum system privileges are vulnerable to the

attacks

© For example: Many web applications use database admin account though
not required to connect to the backend database,
enhancing the impact of SQL injection exploits

© Protects application from malicious attacks by:

& Determining and assigning rights only to those who require
privileges to complete the specific task

& Avoiding applications that get installed and run by default

\_ 2 Writing applications that can be used by users having non-

administrative privileges J

Secure by Default

@ The software solution or application provided to the users should be

security enabled by default. If permitted, it is up to the
user to reduce the security

© For example: By default the security feature password aging and

complexity should be enabled

Secure Design Principles (Cont'd) C |

Fail Securely

Do Not Trust User Input

@ The developer should not give

application secrets by default error
messages
© The architects and developers
should consider all the levels of
the software to impose security
while developing software

© Protect the application from all

malicious inputs coming from the
user input to the application

© Application that discloses

confidential information on failure - . i
assists attackers in creating an & Implement security mechanisms

. 5
: 1
y i
1 I
i 1
! H
' |
H 1
i
! i
1
1 + pe THY
; : @ Consider all inputs as a malicious
! |
i bg
i
S| i i
attack Ed at different layers that include
! i
i
i |
! |
1 1
1 I
! i
! i
i
i 1
! H
l i
I
' |
H 1
i
! }
! H
1 1
1 1

1
1

i 1

1 1

i i

[} i

1 1

i 1

i input and apply security i

i measures to restrict them :

network layer, kernel layer, i |

& When an application fails, physical layer, and the file system |
H
determine what may occur and i :
ensure that it does not threaten i H
the application i :
i 1

1 1

[} 1

1 1

layer

© Provide logical and useful error

messages to the users and store
the details in the log file

Page 66
Secure Design Principles (Cont'd) CASE

Reduce Attack Surface

© Application attack surface area is to be minimized by reducing the

number of entry points into the application

@ Remove or turn off the features, protocols, and functionality which

are not in use to minimize number of vulnerabilities and
the overall risk

@ For example: If a vulnerability exists in a way an XML is parsed,

denying XML from unknown users minimizes that security
vulnerability
Enable Auditing and Logging

© Auditing and logging states how the security related events are
recorded by an application

© Auditing enables identification of attacks or intruders in progress,

whereas logging aids in identifying how an attack is
performed

@ Perform auditing and logging to gather information about attacks

Secure Design Principles (Cont'd) CA SE

Keep Security Simple

& If the design is complicated, it is hard to understand and
errors are likely to occur in implementation, configuration, and
use

© On the other hand, if the complexity of security mechanisms

increases, the effort required to reach the appropriate
level of software assurance also increases

© Avoid complex architectures and opt for simpler approaches that are
fast and simple

Separation of Duties

© Separation of duties is the key control of fraud

® When assigning privileges, system roles are to be considered. In

general, system administrators are also the users as
same super user privileges are required to make the system run

© For example: System administrator can set the password policy, turn
off or on the system, etc. but should not be able to
log in as a super-privileged user

Page 67
Secure Design Principles (Cont'd)

Fix Security Issues Correctly

© When a security issue is identified, fix !

it, considering it as the actual i
problem, and then go through the ]
security process as you do for the
new code, ensuring that the fix does
not introduce new errors

© For example: User capable of viewing | |

another user's account balance by
simply adjusting cookie. In this i
context once the security issue is
fixed it has to be tested on all the i
applications as cookie handling code :
is shared among all applications

Apply Security in Design Phase

@ Before starting the application
development process, always
consider security issues that can help
prevent many security vulnerabilities

© Considering security issues helps you

understand the coding weaknesses
and vulnerabilities from the most
obvious exploits

Protect Sensitive Data

© Do not hard code the sensitive data

such as passwords in the program

© Use data encryption mechanism to

transmit data over the network

’ _ | AE
Secure Design Principles (Cont'd) C | ASE
Exception Handling Secure Memory Management Protect Memory or Storage

© Events that disrupt the coding

process are called exceptions

© Exception handling occurs when

error conditions interrupt the normal
flow of a program’s execution

designing for exception handling, as

continuous checking for error
conditions is necessary

© Proper use of exception handling

helps to ensure proper error

1
I
1
1
1]
1]
1
1]
1]
1
1
1
1
1
1]
1]
1
1]
1
1]
1
1]
H
@ Programmers have difficulty in Hh
1
1]
1
1
¥
1]
|]
1
1]
i
handling !
I
1]
I
1

& Check memory bounds on the length

of input variables, arrays, and
arguments to prevent buffer
overflow attacks

1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
L
@ Apply coding standards for simplicity, i
which help in implementing security |
in the program and keep things .
simple |
1

1
1

Secrets

© Encrypt secrets to protect memory

storage from ending up in crash dump
file

@ Use a perfect cryptographic method

to perform encrypting secrets process

© Scrub secrets in memory storage

before deletion

Page 68
Secure Design Principles (Cont'd) C

Fundamentals of Control Granularity

© Applications managing sensitive data should possess privacy

protection that can be achieved through
flow control

@ Flow control prevents data from non-secure information flows

@ Systems with low-level granularity may lack control in protecting
data from misuse

© System administrators are given better control of granularity at the

URL level, shared directory level, and
application level

@ Different granularity is needed to control information flows within

an application

© Role-based Access Control (RBAC) is a flow control model offering

multiple levels of control granularity
2 Also called an n-leveled RBAC (LnRBAC), as a level of granularity is
controlled by a level of RBAC control
© Handles and solves problems caused by abnormal program stopping

2 Controls method invocation, write accesses, and avoids Trojan horses

Secure Design Principles (Cont'd) C

Fault Tolerance Fault Detection

© Strategy applied to software design (or system @ Closely linked to

fault tolerance, used in detecting faults
design) to permit system to continue functioning and producing
appropriate responses of system
even in the presence of faults by enhancing its behavior
robustness © Examples include system monitors, safety monitors,

built-in tests, loop-back tests, etc.

@ Removes faults during design process

@ Examples include error detection, verification through development
process

Avoids errors that contribute to system faults during the

inspection, built-in testing, correction functions, etc.

Examples include defensive programming, error

minimization during design process, minimization of
safety critical code, using appropriate SDLC techniques,
etc.

Page 69
Secure Design Principles (Cont'd)

rir

| J.NET}
CASE

Procedures that operate independently from other procedures are called

loosely coupled procedures
Loose coupling describes the exchange relationship that occurs between
two or more systems or organizations
The concept loose coupling of systems is adopted when either source or
destination machines are supposed to be changed frequently

Loose coupling can be achieved in web services or service-oriented

architecture by hiding the implementation details from the caller

Loose Coupling

Well-known Techniques that create Loose Coupling

2 Vendor and platform independent messages

Coarse-grained, self-describing, and self-contained messages

Well-defined interfaces
Extensible versionable interfaces
Constrained interfaces

2 Stateless messaging

Human readable strings (URIs) for service and instance addresses

Stateless messaging where possible and appropriate
Humans controlling clients where possible and appropriate

Asynchronous exchange patterns where possible and appropriate

Secure Design Principles (Cont'd)

High Cohesion

Procedures that perform a single function

Cohesion is a measure of identifying the extent of

strongly related functionalities in the source code
of the single module

A particular class is said to have high cohesion if

the methods in that class perform similar actions
in many aspects

This high cohesively code increases the code

readability and reusability without increasing
complexity

Procedures that are more reliable, easy to read,

and maintain are usually loosely coupled and
have high cohesion

Change Management and Version Control

Integrity of system changes is controlled by a well-

defined process called configuration management

Allows all stakeholders to know upcoming changes

Change management controls integration costs and

development

Required changes to code may cause vulnerabilities

Anticipation of change requirements may limit

negative effects

Page 70
J NET}
CASE

Threat Modeling

| J NET]
CASE
“It is not possible to design and develop a secure application until
you know
your threats.”

Source: msdn. microsoft.com

Page 71
Threat Modeling C

=>
‘»
im

_| Threat modeling is a process of identifying, analyzing, and

mitigating the threats to the application

| Itis a structured approach that allows the developer to rate the

threats based on the architecture and
implementation of the application

J It is performed at the design phase of the secure development

lifecycle

| Itis an iterative process that starts from the design phase of the
application and iterates throughout the application
lifecycle until all possible threats to the applications are
identified

_| The output of threat modeling is a threats model exposing all the

possible threats and vulnerabilities on an
application

J .NET]|
Threat Modeling Phases CASE

Attack Surface nr, 0 : " : :

. Application is decomposed and its entry points are reviewed from an
attacker’s perspective
Evaluation pRliceran P : fy pel vd peSpEEH
Threat
9 4 Each entry points are then reviewed against potential threats
Identification Ee E g
Impact Analysis | Impact of potential threats is calculated in terms
of risk |
Control : : _
= Security controls are recommended to meet security objectives
Recommendations

Page 72
: | a
Threat Modeling Process CASE

| The steps involved in Threat Modeling process are as follows:

1. Identify
Security
Objectives
Re
5. Identify 2. Application
Vulnerabilities Overview
4. Identify 3. Decompose

Threats Application

Identify the Security Objectives CA SE

| To proceed with creating threat model for an application, the

security objectives of the application should be
identified clearly

| These security objectives are goals and constraints that needs to be

attain to maintain confidentiality, integrity,
and availability of application and its data

| Security objectives are the subset of the application’s functional

objectives

| With security objectives clearly identified,

© You can identify the areas which need more closer attention and
where to focus your efforts
© You can understand goals of potential attackers

Page 73
a | app soca gi

| Am
How to Identify Security Objectives C ASE

| Security objectives are identified by conducting brain storming

sessions, questionnaires, storyboarding, etc. with
relevant stakeholders of the project

Sample Questionnaires Sample Security Objectives

© Does your application handles or processes sensitive data

that you need to protect from unauthorized access? Identify @

Application should prevent unauthorized person
such data that you need to protect from customers/clients pp 3 from
accessing confidential information of the
2 Example of Sensitive data: user names, passwords, customer account
details, customers

personal information, financial details, transaction details, credit

card
numbers, bank details, etc.

© Does your application requires to comply with certain

security policies, privacy laws, regulations, or standards EE

P @ Application should meet the compliance

© Example: PCI-DSS, HIPPA, etc. requirements

© Does organization wants application to satisfy certain quality

of service requirements [2 =
2 Example: availability, performance, etc.

@ Application should meet the quality of service

requirements

e Fir has any intangible assets that you need to = > @ Application
should protect the company's online
business credibility

© For example: Organization's reputation, trade secrets,

intellectual property,
etc.

Create an Application Overview C Ss E

| The aim of creating application overview is to understand what the

application does

| Creating an application overview Involves:

€ Understanding the application functionality

# Understanding the purpose and the key features of the application

€ Identifying application users or clients

| Create application overview with the help of these activities:

1 Draw the end-to-end deployment architecture

Identify various user roles

Identify technologies

2
@ Identify use case scenarios
po

Identify application security mechanisms

Page 74
_| Draw a high-level diagram that describes the overall structure of
the application and its subsystems in the deployment environment
“I Identify end-to-end deployment topology, logical layers, key
components and services, communication ports and protocols, etc.

1 Add authentication, authorization, and communication mechanisms at

broad level in the deployment diagram

Sample Application Architecture Diagram

NTFS.

File Authorization

Permissions URL Authorization

Net Roles
Authorizatio:
(huthorzation) 1p horization)

= 3
(Privacy/Integrity) - u
Anonymous Forms
Authentication Authentication

User-Defined
Role
(Authorization)

Trust Boundary

ASPNET
(Process Identity) >

~
VC
a

(i((¢]
ne NRRAY
w
2
Lig

IPSec
(Privacy/integrity)

Windows
Authentication

Identify Various User Roles

J Identify who can do what in the application

J Identify users or group of users with higher privileges

1]
1
1
|
1 Identify the rights of specific users i
I
1
1]
1

Examples of Roles

Anonymous Web User

User With Valid Login Credentials

User With Invalid Login Credentials
Librarian

Database Server Administrator

Website Administrator
‘Web Server User Process

Database Read User

Database Read/Write User

Page 75
| NET]
Identify Use Case Scenarios CAS E

_| Identify the functionality and usage of an application

| Identify Create, Read, Update, and Delete operations in the

application

| Review following items to gain understanding of key usage of the

application
© Review existing documents
© Review the use cases

© Review requirements

ONNONNORNO

| This will help you understand how the application should be used and
how it can be misused

Identify Technologies CA

| Identify the technologies used to develop and deploy the application

Operating systems

Web server software

Database server software

Technologies used in the presentation, business, and data access

layers

Development languages

e6008

J This will help you identify technology-specific threats

Page 76
Identify Application Security Mechanisms C

[I NET |
ASE

Input and data validation

Authorization

Sensitive data
Cryptography

Exception management

J This will help you add details wherever necessary

Identify and highlight key elements with respect to following

application security mechanisms

Authentication

Configuration management

Session management

Parameter manipulation

Auditing and logging

Decompose the Application

| It helps to conduct attack surface analysis

| Decompose application with the help of these activities:

Prepare and Document Threat Model Information

Enumerate External Dependencies
I Enumerate Entry Paints
Enumerate Assets
Enumerate Trust levels

[ Data Flow Diagrams

| Decompose the application to the level where it is possible to

identify external entities, trust boundaries, data flow,
entry points, and privileged code in the application and recognize the
areas of vulnerabilities among them

Page 77
| J .NET]
Prepare and Document Threat Model Information ~~ ( | ASE

Application Name

Application Version

Description

Document Owner

Participants

Reviewer

The following fields should be documented to begin with threat

modeling
The name of the application

The current version of the application

A high level description of the application

The name of the threat modeling document owner

The people involved in the threat modeling for the application

The name of the reviewer(s) of the threat model

Example: Threat Model Information CA SE

Application Version

Description

Document Owner

Participants

Reviewer

Source: hitps.//www.owasp.org

Threat Model Information

1.0

The college library website is the first implementation of a website

to provide librarians and library
patrons (students and college staff) with online services

As this is the first implementation of the website, the functionality

will be limited. There will be three
users of the application:

1. Students
2. Staff
3. Librarians

Staff and Students will be able to log in and search for books, and
staff members can request books.
Librarians will be able to log in, add books, add users, and search
for books

John

Jason

Mathew

Page 78
J.NET]
Identify the External Dependencies CASE
External dependency defines the application's dependency on
outside entities such as servers, firewalls, security
policies, OS, network, etc.

These entities are the essential components of application but lay

outside of the application's code

Though these entities are outside of the application's control,

they are still within the control of the organization

| Identifying such external dependencies may help to minimize the

application's overall risk

To find out external dependencies, analyze different factors on which

application security will depend in a production
1 environment

| For example
@ How the application will be deployed?
@ Will application is expected to run on the server?

@ Will there be firewall sitting before server?

| Document such external dependencies with ID and Description field

. | AE
External Dependencies: Example CASE

ots | Riptads seas te

1D Description

The college library website will run on a Linux server running Apache.
This server will be hardened as per
1 the college's server hardening standard. This includes the
application of the latest operating systems and
application security patches

The database server will be MySQL and it will run on a Linux server.
This server will be hardened as per the
2 college’s server hardening standard. This will include the
application of the latest operating system and
application security patches

3 The connection between the Web Server and the database server will
be over a private network

4 The Web Server is behind a firewall and the only communications is

TLS

Source: https://www.owasp.org

Page 79
| Tm
Identify the Entry Points CASE

| Entry points are interfaces through which users input data or

interact with the application
| A potential attacker may take advantages to such entry points to
attack an application

(mp) | There can be multilayer entry points in the application; for

example, external entry are exposed to the users and
” internal entry points exposed to subcomponents across the layers of
the application
(ws) | Attacker can bypass first level of entry point and directly
attack an internal entry point

Document all the entry points including multi layer entry points; they
should be documented with ID, Name,
Description field

| Typical Entry Points are:

© Loginfauthentication entry points @ Business workflows

© Admin interfaces @ Transactional interfaces/APls

© Inquiries and search functions @ Operational command and monitoring

interfaces/APIs
€ Data entry (CRUD) forms @ Interfaces with other applications/systems

| J NET]
Entry Points: Example CASE

ID Name Description

The college library website will be accessible via TLS. All pages
within the

= LIES ES college library website are layered on this entry points

1.1 Library Main Page is page for the college library website is the
entry point for all
1.2 her Students, faculty members and librarians must log in to the
college library
g 8 8 website before they can carry out of the use cases
12.1 Login Function The login function accepts user supplied
credentials and compares them
with those in the database
1.3 Search Entry Page The page used to enter a search query

Source: https://www.owosp.org

Page 80
. J NET]
Identify the Assets CASE

| Applications asset is resources/ items/areas which has a value of

attacker's interest
| They are essential threats targets which puts the application under
risk of being attacked
| These assets can be physical and abstract

| For example,

@ Abstract: reputation, safety

| Assets can interact with other assets

J Identify all the assets of an application which needs to be

protected from unauthorized access

| Document both physical and abstract assets of the application with

its ID, Name, and Description

I
[]
1}
1
I
[]
1}
|
1
1}
i
|]
]
|]
|)
I
I
1
1}
1]
1}
|
© Physical: data i
1}
1]
1}
1}
|
1
1}
I
[}
1}
I
[]
1
1
I
[}
1
1
1
1]
1
I

A —— om nn om mn nm. mm a. ~

| J NET]
Assets: Example C AS E
Assets

ID Name Description

1 Library Users and Librarians Assets relating to student, faculty

members, and librarians

The login credentials that a student or a faculty member will use to

log into the college

i i il 2
1.1 User Login Details library website
1.2 Librarians Login Details The login credentials that a librarian
will use to log into the college library website.
i Sp 2 = :
13 Personal Data The college library website will store personal
information relating to the students,
faculty members, and librarians
2 System Assets relating to the underlying system

Availability Of College Library ~~ The College Library website should

be available 24 hrs. a day and can be accessed by all
Website students, college faculty members, and librarians

Ability To Execute Code as a

ZiE Web Server User

This is the ability to execute source code on the web server as a web
server users

Source: https://www.owasp.org

Page 81
Assets: Example (Cont'd) C | A SE

ID Name Description
23 Ability To Execute SQL as a This is the ability to execute SQL
select queries on the database, and thus retrieve any
Ee Database Read User information stored within the College Library
database
Ablity To Execute SQL 35 2 This is the ability to execlite saL select,
insert, and update aulresion the database, and
2.4 . thus have read and write access to any information stored within
the College Library
Database Read/Write User
database
3 Website Assets relating to the College Library website
31 Logi = cosion This is the login session of a user to the College
Library website. This user could be a

student, a member of the college faculty, or a Librarian

Access to the database server allows you to the administrator the

database, giving you

3.2 Access to The Database Server

YET full access to the database user and all the data contain within
the database
= The ability to create users would allow an individuals to create a
new users on the
.. Abili ;
8:3 Sito Seats Users system. These could be students users, faculty
member users, and librarians users
Th 0 h ll} it-abl hi Ir ithin th li li
34 Access to Audit Data e audit data shows all audit-able events that
occurred within the college library

application by students, staff, and librarians

Source: https:/fwww owosp.org

Identify the Trust Levels CASE

J Trust level defines the access rights which applications should

grant to the external entities

I Define the possible roles including set of privileges and trust

levels assigned to the roles

| Document the trust levels with its 1D, Name, and Description filed

Page 82
Trust Levels: Example

| J-NET]
EASE

ID Name

1 Anonymous Web User :

credentials

User with valid login

credentials credentials
3 User with invalid login
credentials using invalid credentials
4 Haran information
5 Database Server : ¢
Administrator used by the college library website
6 Website Administrator
u Ee against the database server as.
8 Database Read User
9 Database Read/ Write User

Source: https.//www.owasp.org

Description

A user who has connected to the college library website but has not
provided valid

A user who has connected to the college library website and logged in
using valid
A user who has connected to the college library website and is
attempting to log in

The librarian can create users on the library website and view their
personal

The database server administrator has read and write access to the
database that is

The website administrator can configure the college library website

This is the process/user that the web server executes code as and
authenticates itself

The database user account used to access the database for read access

The database user account used to access the database for read and
write access

Define Trust Levels to Entry points

| JNET]
CASE

| Define the appropriate trust level required for each identified

entry point

Example:

ID Name Description
The college library will be only be accessible via TLS. All
1 HTTPS Post pages within the college library website are layered on
this
entry point
. x The Splash page for the college library website is the entry
1.1 Library Main Page point for all users
Students, faculty members and librarians must log into the
1.2 Login Page college library website before they can carry out any
of the

cases

The login function accepts user supplied credentials and

121 Login Function

OEIELENO compares them with those in the database

13 Search Entry Page

The page used to enter a search query

Source: https.//www.owasp.org

Trust Levels

{1) Anonymous Web User

(2) User with Valid Login Credentials
(3) User with Invalid Login Credentials
(4) Librarian

(1) Anonymous Web User

(2) User with Valid Login Credentials

(3) User with Invalid Login Credentials
(4) Librarian

(1) Anonymous Web User

(2) User with Valid Login Credentials

(3) User with Invalid Login Credentials
(4) Librarian

(2) User with valid Login Credentials

(3) User with Invalid Login Credentials
(4) Librarian

(2) User with Valid Login Credentials

(4) Librarian

Page 83
Define Trust Levels to Assets

| Define the appropriate trust level required for each identified

asset

Example:
Assets
ID Name Description Trust Levels
it Library Users and Librarian Assets relating to students, faculty
members, and librarians
{2) User with Valid Login Credentials
(4) Librarian
- . The login credentials that a student or a faculty member will use
to log (5) Database Server Administrator
chit User ogi Detalls into the College Library website {7) Web Server
User Process
(8) Database Read User
(9) Database Read/Write User
(4) Librarian
: eg ~ 2 (5) Database Server Administrator
12 Librarian Login Details ois that a Librarian will use to log into
the College {7} Web Server User Process
+! (8) Database Read User
(9) Database Read/Write User
(4) Librarian
(5) Database Server Administrator
13 Personal Data The College Library website will store personal
information relating to (6) Website Administrator
E the students, faculty members, and librarians {7) Web Server User
Process
(8) Database Read User
(9) Database Read/Write User
2 System Assets relating to the underlying system
Source: https.//www.owasp.org

Define Trust Levels to Assets (Cont'd)

2.1

2.2

23

2.4

31

3.2

33

3.4

Availability of College
Library Website

Ability to Execute Code

as a Web Server User

Ability to Execute SOL

as a Database Read
User

Ability to Execute SQL

as a Database
Read/Write User
‘Website

Login Session

Access to the Database

Server

Ability to Create Users

Access to Audit Data

The College Library website should be available 24 hours a day and can
be
accessed by all students, college faculty members, and librarians

This is the ability to execute source code on the web server as a web
server user

This is the ability to execute SAL select queries on the database, and
thus
retrieve any information stored within the College Library database

This is the ability to execute SQL. Select, insert, and update queries
on the
database and thus have read and write access to any information stored
within

the College Library database

Assets relating to the College Library website

This is the login session of a user to the College Library website.

This user could

be a student, a member of the college faculty, or a Librarian

Access to the database server allows you to administer the database,

giving you

full access to the database users and all data contained within the
database

The ability to create users would allow an individual to create new

users on the

system. Theses could be students users, faculty member users, and

librarian
users

The audit data shows all audit-able events that occurred within the
College
Library application by students, staff, and librarians

(5) Database Server

Administrator
(6) Website Administrator

(6) Website Administrator

(7) Web Server User Process

(5) Database Server

Administrator

(8) Database Read User

(9) Database Read/Write User

(5) Database Server

Administrator
{9) Database Read/Write User

(2) User with Valid Login

Credentials
(4) Librarian

(5) Database Server

Administrator

(4) Librarian
(6) Website Administrator

{6) Website Administrator

Source: https.//www.owasp.org

Page 84
Perform Application Modeling using Data Flow

Diagrams (DFDs)

(I NET]
CASE

application by using Data Flow Diagrams (DFDs)

| Start with higher level DFD and go on creating lower DFDs to

decompose the application into different process and their

lower-level sub processes or functions

The collected information such as external entities, entry points,

assets and trust level will help in accurately modeling the

DFD will help in understanding how the data flows through the
application and what happens to data while flowing

The higher level DFD will help you understand overall the scope of the
application while lower level DFDs will help you
understand working of lower-level specific processes

Perform Application Modeling using Data Flow

Diagrams (DFDs) (Cont'd)

| NET)
CASE

External
Entity

Pil

Data Flow

Different Components in DFD

It is used to represents external

entity which interacts with the
application from outside

It is used to represents
collection of sub processes

It is used to represents the

movement of data within the
application

Data Store
Privilege Boundary

It is used to represents actions or

function to accomplish specific task

It is used to represents locations

where data is stored

It is used to represents change of

privilege levels

Page 85
Perform Application Modeling using Data Flow SE
Diagrams (DFDs) (Cont'd) ois 2

| Create Context level DFD to map the scope of the application

Example:

Data Flow Diagram for the College Library Website

Datbase
Files
Data

Source: hittps://www.owosp.org

Perform Application Modeling using Data Flow

| A&E
Diagrams (DFDs) (Contd) CAS E

| Go on creating lower level DFD to depict specific process

Example:

\
User | Web Server
Boundary

\
£5 Toy Authenicatelse()
#
C= |
Process.
Result
Fo

Login Resins

| Authenticate
User SOL
Authenticate
1 User SOL Cincy
) Pages Query Resuly =
[ ea) NO ee “Ved Server /
J
i
h

Source: https /Ywww.owasp.org

Page 86
Determine the Threats: Identify the Goal of an
Attacker and Create Threat Profile lB

J Once the DFD's are created at lowest level, you can identify
all the external dependencies, entry/exits points, trust
levels in an application

J It helps to easily identify what data need to be provided to

specific process in DFD and corresponding attacker's
goal to exploit the functionality of specific process

_| This goal is used in DFD to determine the threat path in the

application

_| Identify all the possible attacker’s goals and vulnerabilities

which allows attackers ta accomplish their goals

Example: Attacker’s Goal/Threat Profile and C x §E

Vulnerabilities Associated os i
| ——

Goal: Attacker may steal user authentication credentials

Vulnerability:
© Insecure storage of credential at the client system
© Credentials are sent with GET parameters

Example #2:

Goal: Attacker may login with brute force attempt

Vulnerability :

© Use of Improper input validation and weak password

Example#3:
Goal: Attacker may launch a denial of service attack i
Vulnerability: i
© Lack of account lockout functionality
1
i
1

© Absence of CAPTCHA

Page 87
J NET]
Determine the Threats: Create a Security Profile CASE

Auditing and Logging

i Security Profile
: 3 Trust
1 ickati k
| To create security profile for an | ibe J Boundavies
- . 1
1
1 i
NC
© Various design and implementation ! =
approaches of an application which can be | eal
most susceptible to vulnerabilities i
|
1
© Various areas of applications which can be |
most susceptible to vulnerabilities 1
HN ETT =a
1]
_) Document the security profile for i
application depending on the area of i
vulnerabilities i Ext Se mage:
: oo n Assets
i
| =

Determine the Threats: Create a Security Profile

J NET]
CASE

(Cont'd)

| Following considerations help you to identify vulnerabilities in

design and implementation of your application

Input Validation

Authentication

Authorization

Configuration
Management

Sensitive Data

ga

@ Is all input data validated?

© Could an attacker inject malicious commands or data in the input

fields?

© Is data validated as it is passed between separate trust boundaries

(by the recipient entry point)?
© Can data in the database be trusted?

© Are credentials secured if they are passed over the network? Are
strong account policies used?
& Are strong passwords enforced?

© Are you using certificates?

© Are password verifiers (using one-way hashes) used for user
passwords?

© What gatekeepers are used at the entry points of the application?

How is authorization enforced at the database?
© Is defense in depth strategy used?
© Do you fail securely and only allow access upon successful
confirmation of credentials?

© What administration interfaces does the application support? How are

they secured?
© How is remote administration secured?
© What configuration stores are used and how are they secured?

© What sensitive data is by the ion? How is it over the and in

persistent stores?
© What type of encryption is used and how are encryption keys secured?

Page 88
Determine the Threats: Create a Security Profile

| J.NET]
(Cont'd) C | A S E

Category Considerations

© How are session cookies generated? How are they secured to prevent
session hijacking?
& How is persistent session state secured?
Session Management © How is session state secured as it crosses the
network?
© How does the application authenticate users with the session store?
© Are credentials passed transmitted and are they maintained by the
application? If so, how are they secured?

# What algorithms and cryptographic techniques are used? How long are
encryption keys and how are they secured?
Cryptography © Does the application put its own encryption into
action?

[-]

How often are keys recycled?

Parameter © Does the application detect tampered parameters? Does it

validate all parameters in form fields, ViewState, cookie
Manipulation data, and HTTP headers?

= © How does the application performs error handling? Are exceptions

ever allowed to propagate back to the client?
Exception Management i . ) . .
© Are generic error messages that do not contain exploitable
information used?

Auditing and Logging © Does your application audit activity across all
tiers on all servers? How are log files secured?
J.NET]
Identify the Threats CASE

To identify threats, they need to be broadly categorized into

different possible categories

This threat categorization provides structured way to systematically

identify different threats on the
application

Threat identification process uses STRIDE model to categorize threats

and examine each aspect of the
security profile of the application

Page 89
| J.NET}
Identify the Threats: The STRIDE Model C AS E

J The STRIDE model categorizes the application threats based on the

goals and purpose of the attack which helps developer to
develop a security strategy

It also includes the countermeasures for all threat categories

| This model describes the following threat categories:

EERERan

‘Authentication Spoofing Unauthorized access to a system by using a

false identity

Integrity Tampering Code and data modification without authorization

Nopreputistan Hepudiation lila af users to claim that they do not

perform some actions against the
application

Confidentiality Information disclosure Unwanted exposure of private

data to unauthorized users

Availability Denial of service Ability to deny a system or application

unavailable to the legitimate users

Authorization Diivilege Escalation Ability of user with limited

privileges to elevate their privileges with an

application without authorization

Source: httpsy//www.owasp.org

Example: Threat Categorized and Identified using C | A $B

STRIDE rt et cd

STRIDE Threat List

Type Examples
Soaofin Threat action aimed to illegally access and use another user’s
credentials, such as username and
P g password
Threat action aimed to maliciously change/modify persistent data, such
as persistent data in a
Tampering database, and the alteration of data in transit between two
computers over an open network,
such as the internet

25 Threat action aimed to perform illegal operations in a system that

lacks the ability to trace the
Repudiation ma :

prohibited operations
Information disclosure Threat action to read a file that one was not
granted access to, or to read data in transit

Threat aimed to deny access to valid users, such as by making a web

server temporarily
unavailable or unusable

Denial of Service

Threat aimed to gain privilege access to resources for gaining

unauthorized access to

levation of privil 3
Elerion paves information or to compromise a system

Source: https://www.owosp.org

Page 90
Determine Countermeasures and Mitigation
Security Controls

| J NET]
CASE

J Identify the set of controls and countermeasures to prevent

identified threat

Desired Property Countermeasures/Controls

© Use strong authentication mechanisms

Authentication Spoofing © Avoid storing credentials in clear text
© Do not pass sensitive data in clear text over networks

Use strong authentication mechanisms

@ Secure authentication tokens with encrypted communication

Integrity Tampering channels

&

Use digital signature

& Identify malicious behavior
Non-repudiation Repudiation 8 Create secure audit trails
& Use digital signature

© Use strong authorization and encryption mechanism

Confidentiality Information disclosure i 3 5

© Avoid storing credentials in clear text

Availability Denial of service © Use bandwidth controlling techniques
Authorization Privilege escalation © Use limited privileged service
accounts

Source: httpsy//www.owasp.org

Document the Threats C | A SE

| A standard template that describes several threat attributes

including threat description and threat target are used to
document the threat

J The risk rate is left blank as it is to be filled in during the

final risk rating step

A Sample Template for Documenting the Threats

Attacker obtains Authentication

Credentials by Monitoring the Network

Threat Description

Threat Target Web application user authentication process

Risk

Attack Techniques Use of network monitoring software

Countermeasures Use SSL to provide encrypted channel

Page 91
Rating the Threats

NET]
CASE

The formula for calculating risk is:

RISK = PROBABILITY * DAMAGE POTENTIAL

This step rates the threats based on the risks they possess

Threat resolution is prioritized based on the risk ratings

Rating the Threats: DREAD Model

| J NET]
ASE

¢
DREAD Model

DREAD stands for damage

potential, reproducibility,
exploitability, affected users,
and discoverability

DREAD model is used to rate

the various security threats
on the application by
calculating risks of each
threats

| The severity levels are

assigned to various threats on
the application so as to
mitigate these threats as per
their severity

Damage
Potential

Reproducibility

Exploitability

Affected Users

Discoverability

The attacker can subvert the

security system; get full trust
authorization run as
administrator; upload content

The attack can be produced

every time and does not
require a timing window

A novice programmer could

make the attack in a short time

All users, default configuration

key customers

Published information explains

the attack. The vulnerability is
found in the most commonly
used feature and is very
noticeable

Leaking sensitive
information

The attack can be

reproduced, but only with a
timing window and a
particular race situation

A skilled programmer could

make the attack then repeat
the steps

Some users, non-default

configuration

The vulnerability in a
seldom-used part of the
product and only a few
users should come across it.
It would take some thinking
to see malicious use

Leaking trivial
information

The attack is very difficult

to reproduce even with
knowledge of the security
hole

The attacker requires an

extremely skilled person
and in-depth knowledge
every time to exploit

Very small percentage of

users, obscure feature
affects anonymous users

The bug is obscure and it

is unlikely that users will
work out damage
potential

Page 92

| J.NET]
Rating the Threats: DREAD Model (Cont'd) CASE

Sample DREAD Rating Table

Attacker obtains authentication credentials by High

monitoring the network B

SQL commands injected into application 3 3 3 3 2 14 High

A Sample Template for Documenting the Threats after Risk Rating

Threat Description

Attacker obtains Authentication Credentials by Monitoring the Network

Threat target Web application user authentication process

Risk rating High

Attack techniques Use of network monitoring software

Countermeasures Use SSL to provide encrypted channel

| J NET]
CASE

Secure Application Architecture

Page 93
Design Secure Application Architecture CASE

Pp] oh A typical web application architecture comprises of three tiers

i.e. web, application and database

(2) Security at one tier is not enough as attacker can breach the
security of another tier to compromise the application

S) Design web application architecture with defense-in-depth principle

i.e. providing security at each tier of the web
application

© A multi-tiered security include proper input validation, database

layer abstraction, server configuration, proxies, web
application firewalls, data encryption, OS hardening, and so on

: . | Am
Design Secure Application Architecture (Cont'd) CASE

| Applying multiple layer security in application architecture design

makes application robust and secure

Tier 4 Tier 2 Tier 3

Input validation, users bre one = 25
ization, secure an encrypt or has|
A identities , secure the data stored in
configuration can be done be database
LE LH performed at this tier

Internet
Client running browser

Web Server Application Server Database Server

Can protect sensitive data using

secure communication channel Can protect the
sensitive database
communication

Page 94
| PNET]
Module Summary C A S E

| Security negligence at design and architecture phase may lead to

vulnerabilities that are most difficult to detect
and expensive to fix in production
| Secure design of an application is more straightforward once the
security requirements are identified

| Secure design principles are the state of practices or guidelines

which should be enforced on the developers ta
follow during development phase

| Threat modeling is a process of identifying, analyzing, and

mitigating the threats to the application

| A multiple tired security include proper input validation, database

layer abstraction, server configuration,
proxies, web application firewalls, data encryption, OS hardening,
etc.

Back to Contents