Practical Threat Modeling for Software Architects & System Developers Shay Zalalichin CISSP, PCI:DSS QSA AppSec Division Manager Comsec Consulting

Agenda Why Threat Modeling? System / Application Decomposition Threat Mapping Threat & Risk Rating Planning Threat Response & Mitigations Best Practices in TM

Why Threat Modeling?

What is Threat Modeling? A formal (or semi-formal) framework for security-based analysis Identify, understand, and mitigate threats Can be practiced on both new applications as well as on existing ones We all know that it is much cheaper to discover security bugs earlier …

What is Threat Modeling? (Cont.) Should be used by Architects, Designers, Developers & Security personnel (Usually) composed of the following phases: Decomposition Threat Mapping Threat / Risk Rating Threat Response & Mitigations

You cannot build a secure system until you understand your threats Why Threat Modeling? Simple: You cannot build a secure system until you understand your threats

Why Threat Modeling (Cont.)? Security-based analysis Find security bugs early (and complex bugs) Think about security in a (relatively) formal way Address threats in logical order according to greatest risk Reduce overall risk by mitigating important threats How do you know when your application is “secure enough”?

Why Threat Modeling (Cont.)? Additional Benefits: Helps better understand your application Complex interactions Justification for security features and relation to identified threat Clearly documented assumptions and/or consequences Educational (e.g. new team members) Testers can specifically test against known threats Helps prevent duplication of security efforts

System / Application Decomposition

System / Application Decomposition Define scope Create an architecture overview Function Logical architecture Physical deployment Technologies Identify assets Mark trust boundaries Identify data flows, entry points, and assumptions Make note of privileged code

System / Application Decomposition Remember: The goal of security mechanisms is covering your “assets” Assets could be: Web pages Sensitive data Server resources Define asset CIA requirements: Confidentiality Integrity Availability Web pages Sensitive data Server resources

System / Application Decomposition Use modelling diagrams for a visual representation of how the subsystems operate and work together The type of diagram is not important, but it should focus on data and how it flows through the system For instance, DFDs and Use Cases are useful But don’t go too deep - 2 or 3 levels is enough

System / Application Decomposition Create a security profile for the application Ignore inner workings when modelling the architecture Note events or requests that the system recognizes Notice data sources that relate to each request and response Ascertain the recipient of each response

Demo

Threat Mapping

Identifying Threats Analyze each aspect of the architecture/design Ask questions with regards to attacker goals Can the user’s identity be spoofed? Can data be accessed without authorization? Can the system be easily blocked? … Compare application to common threats Are Cross-Site Scripting (XSS) attacks relevant? Is canonicalization an issue? Can user sessions be hijacked? Use structured methods to identify threats

Identifying Threats (Cont.) To identify threats or goals, ask the following questions: How can the adversary use or manipulate the asset to modify or control the system? Retrieve information within the system? Manipulate information within the system? Cause the system to fail or become unusable? Gain additional rights? Can the adversary access the asset - Without being audited? And skip any access control checks? And appear to be another user?

STRIDE Model A common model for classifying attacker goals is the STRIDE model: Spoofing – Posing as another user, component, or external system that should be identified by the system Tampering – Unauthorized modification of data Repudiation – Denying performing an action without the system being able to prove otherwise Information Disclosure – Exposure of protected data to an unauthorized user Denial of Service – Disallowing valid users to access the system Elevation of Privileges – Gaining privileged access by a lower privileged user

Threat Trees Threat trees can be another useful method to explore valid attack paths A threat tree represents conditions needed to exploit the threat Threat trees are used to determine all the combined vulnerabilities associated with a threat Focus on mitigating the vulnerabilities that form the “path of least resistance”

Each threat should be documented with: Identifying Threats Each threat should be documented with: Title Target component Threat type(s) (e.g. STRIDE) Attack techniques (e.g. threat tree) Risk Mitigation

Demo

Threat & Risk Rating

Rating Threats and Risk How do I measure risk? Use a structured methodology Predefine general values to avoid confusion Record the calculated risk Simple formula: Risk = Probability * Damage Potential Define expected damage for each value Divide scale in three bands: High, Medium, Low Simple, yet lacking dimension Not always easy to agree…

Another method for determining risk is the DREAD model: Damage potential – How great is the damage if the vulnerability is exploited? Reproducibility – How easy is it to reproduce the attack? Exploitability – How easy is it to launch an attack? Affected users – As a rough percentage, how many users are affected? Discoverability – How easy is it to find the vulnerability? Risk = Min(D, (D+R+E+A+D) / 5) Agree beforehand on values of each factor

Demo

Planning Threat Response & Mitigations

Vulnerability Resolution and Mitigation Threats can be resolved by: Risk Acceptance - doing nothing Risk Transference - pass risk to an externality Risk Avoidance - removing the feature/component that causes the risk Risk Mitigation - decrease the risk Mitigation strategies should be examined for each threat Mitigations should be chosen according to the appropriate technology Resolution should be decided according to risk level and cost of mitigations

Demo

Best Practices in TM

Use structured & consistent methodologies Best Practices in TM Use structured & consistent methodologies Predefine and agree on risk ratings that work for you Include all relevant shareholders in TM discussions: Security Architecture / Design Coding Testing Don’t let TM discussions to degenerate to finding solutions before the threats have been fully identified

Best Practices in TM (Cont.) Don’t model too deep – don’t get carried away in the details Document TM results so they could be used later on for: Next versions Similar products / systems Education Use common attack libraries / patterns for consistency and additional ideas For example: http://www.owasp.org/index.php/Category:Attack Always remember – its never too late for Threat Modelling!

Questions?