1. Application Threat Modeling Workshop
Sponsored by
ISACA Ireland Chapters
in collaboration with the OWASP Foundation
Marco Morana (OWASP)

2. Application Threat Modeling Workshop
Sponsored by
ISACA Ireland Chapters
in collaboration with the OWASP Foundation
Marco Morana (OWASP)

4. OWASP testing guide per CISO

5. Workshop Agenda & Time Schedule
Part I - Threat Modeling Fundamentals - 45 min
Break - 15 min
Part II – Introduction to the PASTA™ - 45 min
Part III : Threat Modeling Practice - 45 min

6. Terminology
Threat: “The potential of a “threat source” to exploit a specific vulnerability”
Threat source: “The intent and method targeting the exploitation of a vulnerability either intentionally or accidentally
Vulnerability: “The weakness in procedures, design, implementation controls etc. that can be exploited and result in a violation of system’s security policy
Threat analysis: “The examination of threat sources against vulnerabilities to determine threat to a particular system in a particular operational environment”
Risk Analysis: “The process of identifying risks and determine probability of occurrence, impact and safeguards that mitigate that impact
Risk Management: “The process of identifying, controlling and mitigating risks, it includes risk analysis, cost-benefit analysis and the implementation, test and evaluation of safeguards.
It is important to familiarize on the basic terminology of risk
Source: NIST

7. PART I Threat Modeling Fundamentals
We are going to cover the basic concepts of risk and formal methods used in threat modeling

8. Threats, Vulnerabilities & Assets
It is important to characterize risk as function of threats, vulnerabilities and assets. It is important not to confuse threats with vulnerabilities.
A vulnerability is a condition such as weakness such as a gap in security control where a threat is a potential for damage.
A threat has a characteristics of a threat source-agent, motives of the threat agent and capabilities. Example fraudster, motivation=fraud, capabilities=online tools banking trojans
Risk is characterize as a threat causing and impact on assets and characteristics of the asset such as CIA value and type
Source: Application Threat Modeling, Chapter V, Threat Modeling & Risk Management ,Wiley

9. Application Risk Domains
Risk = Threats (probability) x Assets (impact) x
Control Vulnerabilities
(exploit)
So the question is how we can characterize the risk for a web application? By expanding on the risk domain of assets threats but also impact and controls
Source: Application Threat Modeling, Chapter V, Threat Modeling & Risk Management ,Wiley

10. The Essential Elements of Risk Management
People trained to use risk frameworks to analyze technical and business risks with technical and business experience
Processes for identifying gaps in security measures, identify vulnerabilities and assign levels of risks and impact
Tools for the management of risk of the IT assets the management of vulnerabilities, the identification of threats to these assets and determination of countermeasures
Essential means necessary components, we tend to forget it that is not just process but how an organization is mature in all these domains 10

11. Threat Modeling 101: Definitions
“A strategic process aimed at considering possible attack scenarios and vulnerabilities within a proposed or existing application environment for the purpose of clearly identifying risk and impact levels” [Application Threat Modeling Book, Morana Ucedavelez, Wiley]
“Formal methods to categorize threats, map them to vulnerabilities and identify countermeasures”
Attacks & Attack Libraries
Use-Misuse Cases
Data-Flow Diagrams
Threat-Attack Trees
Use-Misuse Cases
Data-Flow Diagrams
The scope of TM is to identify threats in the application with the objective to find countermeasures and reduce impact.
This can be accomplished using different methodologies. Tm rely on different risk models and tools to produce consistent results
“Tools for modeling the threat, attack and vulnerability/weaknesses analysis:”

12. Focalizations of Threat Modeling
Software/Architecture Centric – Concentrates on the security of software for an evaluated web app. Starts with a model of the system/application/software
Asset Centric – Focused on more risk based approach to application threat modeling. Starts with the data/assets classifications/values
Attacker Centric – Focuses on the attacker’s goals/targets and how can be achieved. Starts with a model of the threat agents and the attack vectors
Security Centric – Addresses security and technical risks to threats revealed by application threat model. Starts with business objectives, security and compliance requirements
No one is better, different strokes for different folks
Legitimate use cases for each type of approach
Largely dependent on org culture and audience

13. Web Application Security: Threats & Controls
Application Security Controls
Network Security Controls
Server Security Configurations
Securing not just the application but the enviornment where the application lives in and the tiers and the logical applications.
The role of threat analysis is look a threats as 360 def and identify mitigations
From Improving Web Application Security: Threats and Countermeasures

14. Web Application Data Flows & Control Analysis
Exercise to connect the dots for APIs and other data interfaces
Maps out data interfaces across application layers (presentation, app, data, etc)
Maps out relationships amongst actors, assets, data sources, trust boundaries, and eventually the variables of the attack tree
Incorporates actors and assets as data flow start & end points
Trust Boundaries
Data Process Components
. Data flow diagrams can be utilized to understand how the data flows through the system, the major processes involved, the trust boundaries and the external interactions. An example of data flow diagraming in support of threat modeling activity is shown in figure 3, documenting the architecture tiers (web server, application server and database server) the security controls (encryption, authentication, authorization, input validation, session management and exception handling and logging) and the trust boundaries (when control changes).
Data flows
Security Controls

15. Data Flow Analysis Using Data Flow Diagrams
STRIDE e’ un modo di categorizarre I threats e associarli gli elementi della architectrura che sono evidenziati qui nel data flow diagram

16. Abuse of Functionality Analysis
Use and abuse cases define how applications can be used and abused
Security requirements can be derived using use and abuse cases
Test cases can be derived to test abuse of functionality and identify gaps in security controls
Abuse Cases
Use Cases
Adaptation of a proven object-oriented modeling technique, use cases, to capture and analyze security requirements in a simple way.
We define a use case as a specification of a type of complete interaction between a system and one or more actors.
We define an abuse case as a specification of a type of complete interaction between a system and one or more actors, where the results of the interaction are harmful to the system, one of the actors, or one of the stakeholders in the system.
The graphical example in Figure TBD depicts the derivation of security requirements via use and and misuse cases. The functional scenario consists on the user action: entering username and password and for the application actions: authenticate the user and provide for an error message if validation fails. The misuse case consists on the actions: hacker trying to break authentication by brute forcing the password via a dictionary attack and by guessing the valid username from the error messages. By graphically representing the threats to the user actions (misuses) it is possible to derive the countermeasures as the application actions that mitigate such threats.
User
Malicious User
Source: OWASP Testing Guide Vs 3,

17. Attack Analysis Using Attack Trees
Attack trees are formal methods to analyze how an application can be exploited by an attacker and to determine the different possible paths that lead to an exploit. Node represent the goal of the attacker and branches represent the sub-goals. The example show the different ways a bank account can be compromised. Methodology was developed by B Schneider.
The figure is from ISACA 2007 publication from christos Dimitriadits shows attacks to user terminal/user (UT/U), the communication channel (CC) and the Internet banking server (IBS).
user terminal/user (UT/U), the communication channel (CC) and the Internet banking server (IBS).
Analyzing the Security of Internet Banking Authentication Mechanisms :

18. Threat Modeling Methodologies :OWASP
Source OWASP Threat Risk Modeling

19. OWASP Application Threat Modeling
The OWASP ATM basic steps are
Decompose the application
Analyze data flows to identify entry and exit points, assets
Enumerate a list of threats such as STRIDE against the application
Assert controls to mitigate threats
Determine the risk of threats unmitigated
Identify countermeasures and propose mitigations
The OWASP TM basic steps are
Decompose the application
Conduct a DFD of the data flows identify entry and exit points, assets
Enumerate a list of threats such as STRIDE against the application
Assert controls to mitigate threats
Determine the risk of threats unmitigated
Identify countermeasures and propose mitigations
OWASP Application Threat Risk Modeling

20. Threats & Security Controls Assessment
Formal methods can be used to associate threats to controls
STRIDE provides categorization of threats by considering attacker goals such as Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
DREAD provides for threat-risk ranking according to the technical risk factors for impact (e.g. Damage, Affected Users) and ease of exploitation (Reproducibility, Exploitability, Discoverability). This risk factorization allows the assignment of values to the different influencing factors of a threat
OWASP Application Threat Modeling

21. Application Security Control Frameworks
Application security control frameworks can focus on the security controls instead of the attacks and look that design flaws that might expose the application assets to possible attacks

22. Modeling Attacks
Web App
Use Case
Misuse Case
Vuln
Attack
Attacks Types: targeted or opportunistic attacks toward web applications
Attack Vectors: channels for which attacks can be introduced
Attack Trees: Walking’ the app allows for threats to be IDed while understanding motives
Attack Scenarios: based upon threat feeds & observed incidents (SIRTs)
Attack Libraries: are key to effective Threat Model and testing with use/ misuse cases & vulns
Modeling of attacks starts looking to the attach types, the vectors, use attack trees to determine the most likely path of attack leading to an exploit, the attack scenarios based upon threat intelligence and the attack libraries used for

23. Modeling Threats, Vulnerabilities and Countermeasures
Maps opportunistic attacks to exploit of vulnerabilities
Allows to think like an attacker in the pursuit of the attacker’s goals/exploits
Attacks map to one to many vulnerabilities
Vulnerabilities can map to one or more countermeasures
Threat
Vulnerabilities &
Control gapsc
Threat is un-authorized access to data, the vulnerability can be leaving the computer un-attended via shared terminal, a SQL injection attack, elevation of privileged from a logged session or simply access to data from the browser that allows you to get to the data.
All the orange ones are vulnerabilities while the green ones are the countermeasures
It is important to emphasize the one to may relationship between attack and vulnerabilities and vulnerabilities to countermeasures
Countermeasures

24. Assigning Risk to Threats
Threats severity can be calculated using risk factors
Threat Prioritization and Risk Rating It is important that organizations have risk management processes on how to deal with such threats. For example these threats must be accepted by the business otherwise the design of the application must change to remove the threat entirely (e.g. don't store credit card numbers to remove the threat of disclosure). .
Through a prioritized list of threats the business can make informed decisions on which threats have to be mitigated first or whether to mitigate them at all. For each threat, a risk model should provide an assessment of the likelihood and impact factors to determine the criticality of the threat and the overall risk or severity level. Ultimately the overall risk has to take into account the business impact since this is a critical factor for the business risk management strategy
OWASP Application Threat Modeling

25. Q
&
Q U E S T I O N S
A N S W E R S