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

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

OWASP testing guide per CISO

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

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

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

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

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

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

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:”

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

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 http://msdn.microsoft.com/en-us/library/ms994921.aspx

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

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

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, https://www.owasp.org/index.php/Testing_Guide_Introduction

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 : http://www.isaca.org/Journal/Past-Issues/2007/Volume-3/Pages/Analyzing-the-Security-of-Internet-Banking-Authentication-Mechanisms1.aspx

Threat Modeling Methodologies :OWASP Source OWASP Threat Risk Modeling https://www.owasp.org/index.php/Threat_Risk_Modeling

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 https://www.owasp.org/index.php/Application_Threat_Modeling

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 https://www.owasp.org/index.php/Application_Threat_Modeling

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

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

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

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 https://www.owasp.org/index.php/Application_Threat_Modeling

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