Threat Modelling

Presentation used to introduce new developers to threat modelling concepts and guide the threat modelling of a specific application.

Transcript

1. Threat Modelling January 2019
2. Objectives • Convince you that threat modelling is an important part of the SDLC • Learn how to do threat modelling • Apply threat modelling to a project and give the team the guidelines to apply it to any other project
3. /me • Application and cloud security expert • developer • Open source evangelist • w3af project leader • Independent security consultant
4. Agenda • Introduction ◦ What is a threat model? ◦ Why should we create a threat model? ◦ When should it be done? ◦ Who should do it? • Core concepts and process ◦ Data flow diagram ◦ Process flow diagram ◦ Threat agents ◦ Attack tree • Closing the circle ◦ Identify mitigations and assign owners ◦ Make sure mitigations are in place
6. What: Something you did many times • Threat modeling is something you've already done hundreds of times, you just don't know the name for it • Today we'll focus on improving what you've done by formalizing the process and practicing
7. What: Critical security thinking • Threat modeling is a process by which potential threats, such as structural vulnerabilities can be identified, enumerated, and prioritized – all from a hypothetical attacker’s point of view • Critical thinking about application security • Guided application security brainstorming • Not meant to identify implementation bugs such as SQL injection, Cross-Site Scripting, etc. There are other tools and processes which aim to uncover those.
8. Why: Identify issues in design phase • Identify the application's security requirements during the design phase to create secure code later • Helps identify security weaknesses in the application's architecture and use-cases • Aims to reduce the number of security issues that will have to be fixed after the software is released • Fixing things earlier in the SDLC is cheaper, both in effort and money. Use threat modelling when you want to work less and be more efficient.
9. When: Design phase • In order to have the highest ROI the threat modelling process should be performed during the design phase. • Threat modelling can be performed during any other phase (such as implementation) where issues will be found but they are already part of the code and will be harder to solve.
10. Who: Devs, security, QA, architects • The three main actors in the threat modelling process are: developers, security experts and product owners. • But the perspective of fraud departments, SOC (security operations center), customer service, and other areas is equally important.
11. Data flow diagram Data in transit and rest
12. Data flow diagram • A data flow diagram (DFD) is a graphical representation of the flow of data through an information system • We'll try to answer: ◦ How does the application receive data? ◦ Where does the application store data? ◦ How does the application communicate with other APIs and databases? Is that communication encrypted? ◦ Does the application communicate with third parties (not controlled by our company)?
13. Data flow diagram: Example
14. Data flow diagram: Example
15. Data flow diagram • Identify sensitive data such as: ◦ Users and passwords ◦ Credit cards ◦ Loyalty points ◦ Account association records • Are there compliance requirements for this application such as PCI or HIPAA? • Is data in transit encrypted? What about data at rest?
16. Data flow diagram • Identify attack surface and trust boundaries: ◦ What is outside our frontend firewall? ◦ What can be consumed by an internal adversary? ◦ What can be consumed by a partner? • Make sure all APIs (external and internal) and frontend applications are shown in the data flow diagram • Identify different user roles in the application. How do these affect the data flow? Can customer support read / write customer records? Is there an admin role?
17. Process flow diagram High level view of user actions
18. Process flow diagram: Example
19. Process flow diagram: Example
20. Threat agents Who'll hack your application
21. Threat agents: Who'll hack us? • The term is used to indicate an individual or group that can manifest a threat. It is fundamental to identify who would want to exploit the assets of a company, and how they might use them against the company. • Most common attackers are: ◦ Hacker: High technical knowledge ◦ Fraudster: Aims to find business logic flaw and exploits it ◦ Competitor ◦ (internal) developer ◦ (internal) customer service representative
22. Attack trees How you'll get hacked
23. Attack trees: How will they hack us? • Attack trees are conceptual diagrams showing how an asset or target might be attacked • Some attacks to use as inspiration: ◦ Phishing ◦ Password brute-force ◦ Password reuse ◦ Consume unauthenticated services ◦ Business logic flaw ◦ Breach of partner's network ◦ User impersonation ◦ Intercept communications (web or SMTP) ◦ Access user's email account
24. Attack trees: Impact and likelihood • Analyze likelihood and impact of these attacks and prioritize • Estimate risk from 1 to 5, where 5 is the highest, use DREAD to guide the estimation: ◦ Damage - how bad would an attack be? ◦ Reproducibility - how easy it is to reproduce the attack? ◦ Exploitability - how much work does the attack require? ◦ Affected users - how many users will be impacted? ◦ Discoverability - how easy it is to discover the issue?
25. Attack trees: Example
26. Attack trees: Example
27. Identify mitigations and assign owners Securing the application
28. Securing the architecture and flows • Identifying the issues is just the first part of the story, providing guidance on how to fix them is equally important. An incomplete or incorrect mitigation can lead to the vulnerability still being exploitable. • Mitigations should be implemented for all attacks with high or medium risk. • Documenting mitigations is important for developers to be able to correctly implement them • Owners should be assigned to each mitigation
29. Track mitigation progress • The application security team is in charge of tracking the vulnerability mitigation progress • Each mitigation should be verified to be implemented in the source code and confirmed through live testing
30. Let's get our hands dirty Applying all concepts
31. Thanks!