Application Security Assessment

Introduction
to Threat Modeling
 Goals for this presentation

THREAT MODELING…

• WHAT it is & WHY do it (i.e. the

Intro)

• WHO would be involved

• WHEN to do it

• HOW to do it
 What is a Threat Modeling

• WHAT IS IT?
– Threat modeling is a technique that can help
identify attack threats, vulnerabilities, and
countermeasures in the context of a specific
application scenario.

• WHY DO IT?
– Shape the application design to meet security
objectives
– Help make right trade-offs during key design
decisions
– Reduce the risk of security issues arising during
development and operations.
 A bit of level-setting: Glossary

• Asset – resource of value to organization

• Threat – an undesired event with potential to damage
the asset(s).
• Attack (exploit) – realizing the threat
• Vulnerability – a weakness that makes the attack
possible.
• Countermeasure – addresses vulnerabilities or
reduces the risk
of the attack.
 Who Performs Threat Modeling?

• The Threat Modeling process can be performed by

both security experts and non-experts.

• The threat modeling process should be led by: BSAs.

• Architects, front & back end developers, testers, & web

admins should also be involved.

• Info security & Risk Management groups should be

informed of the effort or consulted as SMEs.
 When To Threat Model
Threat modeling should be considered when an
effort impacts one or more of the following:

• Security and privacy features

• Features whose failures may have security or privacy
Decreasing

implications
Priority 

• Features whose data crosses trust boundaries

• It’s recommended that threat modeling is done periodically at the

whole application level to assess changes implemented over time.

• Threat modeling should be done for both projects & CRs. Modeling
for the CRs, however should be much lighter since the focus of CR is
much narrower.
A Step-by-Step Approach
 Step 1: Create Security Vision
• Define SECURITY OBJECTIVES for the effort.
– To get started, consider common major risks:
Potential BUSSINESS Risks:
IDENTITY THEFT: Does the application protect user identity from abuse? Are there adequate controls
to validate the identity?
FINANCIAL LOSS: Assess the level of risk the organization is prepared to absorb in remediation, as a
potential financial loss.
DAMAGE TO REPUTATION: Estimate the loss of reputation derived from the system being misused or
successfully attacked.
BREACHING PRIVACY, LAWS, RULES, OR REGULATIONS: To what extent will the application have to
protect user data?
BREACHING ESTABLISHED AGREEMENTS OR GUARANTEES: Is the application required to be
– Security objectives should mitigate identified major risks.
available per a SLA?
What about service level expectations with the users? Vendor SLA or NDA?

Identify any other relevant security requirements

•
Many security requirements are consistent across the organization. Check for existing applicable security requirements.
–

RUP : During Inception Documentation Artifacts:

Agile: During 1st Iteration Document security objectives & identified
 Step 2: Model
• SURVEY the app to identify the following key areas:

Key areas to SURVEY:

ROLES: Who are the key actors in the application. What do they do?
KEY SCENARIOS: What are the application scenarios most important to the business?
TECHNOLOGIES: What technologies are being used in the application?
COMPONENTS: Application architecture modules; key services
SECURITY FEATURES: Authentication, reset password, id reminder, encryption, encoding, etc.

• Further DECOMPOSE the app to understand data flows.

Key areas to SURVEY:

TRUST BOUNDARIES: Analyze data movement across a trust boundary such as web tier.
ENTRY & EXIT POINTS: Key communication points, entry & exit pages, open ports, etc.
DATA FLOWS: Key communication pathways & protocols. Understand how and why data flows to various
places.

RUP: During Elaboration Documentation Artifacts: key identified

Agile: As part of each iteration areas &
 Various Examples of Modeling
Attack tree analysis - example Actual AFWEB model
Internet

Users

AFWeb Enivronment

Big IP
NetCache

Production Staging

1
Web Server Web Server

Trust Boundary

Foglight

Data flow model – example 1

Production Staging

2 6
Dev Retirement Retirement

4 Databases
Databases

Shareholder 3 Shareholder
ClearCase Application Servers
5 Application Servers
Intermediary Intermediary

Trust Boundary
8
Star FREUD
Data flow model
7 – example 2
LMC

Management Interface Management Interf

UltraSeek
NAS
 Step 3: Identify Threats &
Vulnerabilities
Identify Threats & Vulnerabilities
using ANY ONE or SEVERAL of the following methods:

• Using Security Frame

• Using STRIDE framework
• Along application use cases
• Along data flows & boundaries
• Explore additional threats using attack trees

Choose method(s) that the Threat Modeling

Leads and the team feel most comfortable with.

RUP: During Elaboration Documentation Artifacts: Captured Threats,

Agile: As part of each iteration Vulnerabilities, & Consequences (at min in
 Documenting Security Risks
Security Risk Register (Proposed Format)

In Step 3,
Focus Here
Click here for the link to the template.

ame format as project risk register. Easy to integrate

• Other Variations
(Used in WIC):

RUP: Starting Elaboration Documentation Artifacts: Risk Register

Agile: As part of each iteration with
 Step 4: Manage the Risks
• Rate & rank security risks for prioritization.
• Determine how each risk will be managed:
– Mitigated, Accepted, Transferred.
• For risks being mitigated, define countermeasures.
• Define risk response / mitigation strategy & dates.
• Assign risk owners

In Step 4,
Focus Here

RUP: Starting Elaboration Documentation Artifacts: Risk Register

Agile: As part of each iterationUpdated with
APPENDIX
 A: List of Key Security Threats
Spoofing Identity key risk for applications that have many users but provide a single execution context at the application and database level. In particular, users should
not be able to become any other user or assume the attributes of another user.

Tampering with Users can potentially change data delivered to them, return it, and thereby potentially manipulate client-side validation, GET and POST results, cookies,
Data HTTP headers, and so forth. The application should carefully check data received from the user and validate that it is sane and applicable before using
or storing it.

Repudiation Users may dispute transactions if there is insufficient auditing or recordkeeping of their activity. Therefore, consider if the application requires non-
repudiation controls, such as web access logs, audit trails at each tier.

Information Applications must include strong controls to prevent user ID tampering and abuse. Every secure application also has a responsibility to minimize the
Disclosure amount of information stored by the web browser, just in case browser leaks or leaves info behind. Finally, in implementing persistent values, keep in
mind that the use of hidden fields is insecure by nature.

Denial of Service Beware of use of expensive resources such as large files, complex calculations, heavy-duty searches, or long queries should be reserved for
authenticated and authorized users, and not available to anonymous users.

Elevation of If an application provides distinct user and administrative roles, then it is vital to ensure that the user cannot elevate his/her role to a higher privilege
Privilege one. In particular, simply not displaying privileged role links is insufficient. Instead, all actions should be gated through an authorization matrix, to
ensure that only the permitted roles can access privileged info.

Injection Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The
attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data.

Cross-Site ScriptingOccurs whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS
allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect user to malicious sites.

Broken Auth. & Application functions related to authentication and session management are often not implemented correctly, allowing attackers to
Session Mangmnt compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities.

Insecure Direct A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or
Object Reference database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.

Cross-Site Request A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other
Forgery automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to
generate requests the vulnerable application thinks are legitimate requests from the victim..

Security Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, d
Misconfiguration atabase server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure
defaults. This includes keeping all software up to date, including all code libraries used by the application

Insecure Crypto Many web applications do not properly protect sensitive data, such as credit cards, SSNs, and authentication credentials, with appropriate
Storage encryption or hashing. Attackers may steal or modify such weakly protected data to conduct identity theft, credit card fraud, or other crimes.

Failure to Restrict Many web applications check URL access rights before rendering protected links and buttons. However, applications need to perform similar
URL access access control checks each time these pages are accessed, or attackers will be able to forge URLs to access these hidden pages anyway.

Insufficient Applications frequently fail to authenticate, encrypt, and protect the confidentiality and integrity of sensitive network traffic. When they do,
B: Security Frame
 C: Security Frame Samples
• Security Frame Risk Register

Click here for the link to the template.

Security Risk Register Sample

Click here for the link to the example.

 D: Required Documentation
Summary
• The goal of threat modeling is not to create a document,
but to identify and mitigate security risks…

• Here is a recommendation on what to document

during a threat modeling exercise:
– Identified Security Objectives
– Key Security Requirements or
references to existing security requirements or best practices
– Results of the modeling exercise (i.e. list of components, data flows, etc.)
– Security Risks identifying Threats, Vulnerabilities, and Countermeasures
(in a Security Risk Register or as part of the Project Risk Register)