Application Security Assessment

Introduction to Threat Modeling

the Intro) • WHO would be involved • WHEN to do it • HOW to do it .Goals for this presentation THREAT MODELING… • WHAT it is & WHY do it (i.e.

and countermeasures in the context of a specific application scenario.What is a Threat Modeling • WHAT IS IT? – Threat modeling is a technique that can help identify attack threats. . • 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. vulnerabilities.

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.

• The threat modeling process should be led by: BSAs. • Info security & Risk Management groups should be informed of the effort or consulted as SMEs. • Architects. . front & back end developers.Who Performs Threat Modeling? • The Threat Modeling process can be performed by both security experts and non-experts. & web admins should also be involved. testers.

Decreasing Priority  .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 implications 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. Modeling for the CRs. however should be much lighter since the focus of CR is much narrower. Threat modeling should be done for both projects & CRs.

A Step-by-Step Approach .

DAMAGE TO REPUTATION: Estimate the loss of reputation derived from the system being misused or successfully attacked. LAWS. RUP : During Inception Agile: During 1st Iteration Documentation Artifacts: Document security objectives & identified . RULES. as a potential financial loss. BREACHING PRIVACY. 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. – To get started.Step 1: Create Security Vision • Define SECURITY OBJECTIVES for the effort. 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. Check for existing applicable security requirements. 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.

id reminder. • Further DECOMPOSE the app to understand data flows. entry & exit pages. reset password. ENTRY & EXIT POINTS: Key communication points. RUP: During Elaboration Documentation Artifacts: key identified Agile: As part of each iteration areas & . open ports. encoding. 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. etc. DATA FLOWS: Key communication pathways & protocols. Key areas to SURVEY: TRUST BOUNDARIES: Analyze data movement across a trust boundary such as web tier. Understand how and why data flows to various places. key services SECURITY FEATURES: Authentication. etc.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. encryption.

Various Examples of Modeling Attack tree analysis .example Actual AFWEB model Internet Users AFWeb Enivronment NetCache Big IP Production Staging 1 Web Server Trust Boundary Web Server Foglight Data flow model – example 1 Production Staging 2 Dev 6 Retirement Retirement Databases Databases 4 Shareholder ClearCase Application Servers 3 Shareholder Application Servers Intermediary 5 Intermediary Trust Boundary Star 8 Data flow model – example 2 7 LMC Management Interface NAS UltraSeek FREUD Management Interf .

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 Step 3: Identify Threats Vulnerabilities & Choose method(s) that the Threat Modeling Leads and the team feel most comfortable with. & Consequences (at min in . RUP: During Elaboration Documentation Artifacts: Captured Threats. Agile: As part of each iteration Vulnerabilities.

Documenting Security Risks Security Risk Register (Proposed Format) In Step 3. Easy to integrate • Other Variations (Used in WIC): RUP: Starting Elaboration Documentation Artifacts: Risk Register Agile: As part of each iteration with . ame format as project risk register. Focus Here Click here for the link to the template.

• Define risk response / mitigation strategy & dates. Focus Here RUP: Starting Elaboration Documentation Artifacts: Risk Register Agile: As part of each iteration Updated with . • For risks being mitigated. • Assign risk owners In Step 4.Step 4: Manage the Risks • Rate & rank security risks for prioritization. Accepted. define countermeasures. Transferred. • Determine how each risk will be managed: – Mitigated.


occur when untrusted data is sent to an interpreter as part of a command or query. Therefore. or other crimes. When they do. to a vulnerable web application. credit card fraud. such as a file. such as web access logs. Insufficient Applications frequently fail to authenticate. allowing attackers to compromise passwords. consider if the application requires nonrepudiation controls. d atabase server. directory. However. and authentication credentials. Broken Auth. frameworks. and not available to anonymous users. users should not be able to become any other user or assume the attributes of another user. such as SQL. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data. . to ensure that only the permitted roles can access privileged info. and so forth. and protect the confidentiality and integrity of sensitive network traffic. Applications must include strong controls to prevent user ID tampering and abuse. In particular. including the victim’s session cookie and any other Forgery automatically included authentication information. and maintained as many are not shipped with secure defaults. Cross-Site ScriptingOccurs whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. deface web sites. or exploit other implementation flaws to assume other users’ identities. or long queries should be reserved for authenticated and authorized users. or attackers will be able to forge URLs to access these hidden pages anyway. A direct object reference occurs when a developer exposes a reference to an internal implementation object. and LDAP injection. HTTP headers. such as credit cards. then it is vital to ensure that the user cannot elevate his/her role to a higher privilege one. Without an access control check or other protection. and platform. Users can potentially change data delivered to them. audit trails at each tier. SSNs. This includes keeping all software up to date. attackers can manipulate these references to access unauthorized data. Security Misconfiguration Good security requires having a secure configuration defined and deployed for the application. or database key. Instead. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions. All these settings should be defined. & Session Mangmnt Insecure Direct Object Reference Application functions related to authentication and session management are often not implemented correctly. The application should carefully check data received from the user and validate that it is sane and applicable before using or storing it. Insecure Crypto Storage Failure to Restrict Many web applications check URL access rights before rendering protected links and buttons. in implementing persistent values. keep in mind that the use of hidden fields is insecure by nature. or redirect user to malicious sites.. Every secure application also has a responsibility to minimize the amount of information stored by the web browser. complex calculations. If an application provides distinct user and administrative roles. Attackers may steal or modify such weakly protected data to conduct identity theft. Finally. with appropriate encryption or hashing. heavy-duty searches. return it. In particular. OS. and thereby potentially manipulate client-side validation. Cross-Site Request A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request. Beware of use of expensive resources such as large files. just in case browser leaks or leaves info behind. applications need to perform similar URL access access control checks each time these pages are accessed. implemented. Injection flaws. cookies. Users may dispute transactions if there is insufficient auditing or recordkeeping of their activity. session tokens. including all code libraries used by the application Many web applications do not properly protect sensitive data. GET and POST results.A: List of Key Security Threats Spoofing Identity Tampering with Data Repudiation Information Disclosure Denial of Service Elevation of Privilege Injection key risk for applications that have many users but provide a single execution context at the application and database level. all actions should be gated through an authorization matrix. application server. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim. simply not displaying privileged role links is insufficient. keys. encrypt. web server.

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.

and Countermeasures (in a Security Risk Register or as part of the Project Risk Register) . 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. data flows. Vulnerabilities.D: Required Documentation Summary • The goal of threat modeling is not to create a document. etc. list of components.e.) – Security Risks identifying Threats.

Sign up to vote on this title
UsefulNot useful