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

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

3. Why Threat Modeling?

4. 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 …

5. 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

6. 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

7. 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”?

8. 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

9. System / Application Decomposition

10. 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

11. 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

12. 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

13. 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

14. Demo

15. Threat Mapping

16. 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

17. 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?

18. 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

19. 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”

20. 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

21. Demo

22. Threat & Risk Rating

23. 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…

24. 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

25. Demo

26. Planning Threat Response & Mitigations

27. 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

28. Demo

29. Best Practices in TM

30. 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

31. 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:
Always remember – its never too late for Threat Modelling!

32. Questions?