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
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
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
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.
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.
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.
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.
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)?
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?
◦ 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?
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
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
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?
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
charge of tracking the vulnerability mitigation progress • Each mitigation should be verified to be implemented in the source code and confirmed through live testing
andresriancho
seike460
naokihaba
kyoheig3
kakao
0si43
petamoriken
mayuki
kazupon
1024jp
mizoguchicoji
ivargrimstad
mikik0
addyosmani
keavy
mojombo
rmw
jponch
mongodb
jlugia
sstephenson
lauravandoore
wjessup
ddemaree
samanthasiow
