Presentation used to introduce new developers to threat modelling concepts and guide the threat modelling of a specific application.
● Convince you that threat modelling is an important part of
● 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
● Application and cloud security expert
● Open source evangelist
● w3af project leader
● Independent security consultant
○ 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
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
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.
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.
When: Design phase
● In order to have the highest ROI the threat
modelling process should be performed during the
● 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.
Who: Devs, security, QA, architects
● The three main actors in the threat modelling
process are: developers, security experts and
● But the perspective of fraud departments, SOC
(security operations center), customer service, and
other areas is equally important.
Data flow diagram
Data in transit and rest
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
○ Does the application communicate with third parties
(not controlled by our company)?
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?
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?
Process flow diagram
High level view of user actions
Who'll hack your application
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
○ (internal) developer
○ (internal) customer service representative
How you'll get hacked
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:
○ 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
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?
Identify mitigations and
Securing the application
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
● Documenting mitigations is important for developers to be able
to correctly implement them
● Owners should be assigned to each mitigation
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
Let's get our hands dirty
Applying all concepts