Agile Threat Modeling

in 5 Simple Steps

In this guide you will learn 5 most

effective ways of Threat Modeling.

practical-devsecops.com
CONTENT S
01 Threat Modeling and Speed

02 KISS Threat Modeling in 5 Steps

03 The Key Ingredients for the 5 Steps

Step 1 Define

Step 2 Identify

Step 3 Rank

Step 4 Address

Step 5 Validate

04 Tips and Fine Tuning

Agile Threat Modeling in 5 Simple Steps ebook

CHAPTER 1

Threat Modeling and Speed

Agile Software Development frameworks and right into the software or a system. However just
methodologies have led to the sunset of older ways like traditional ways of software development,
of software development. DevOps has only fuelled threat modeling can inherently be perceived as
another revolution in the way software is delivered slow, and time consuming activity.
to customers, and end users. And there are newer Speed and velocity are very crucial across Agile
paradigms such as SRE, Platform Engineering, Software Development frameworks, so every
Software Factories which all have their roots in the activity that is a part of faster delivery cycles also
Agile Manifesto. They are either an extension of the needs to be faster.
Agile values, or merely an expression of Agile values
Let’s explore some of the proven ways that would
in a different form.
aid in faster ways of threat modeling leading to a
Over the years of software development, Threat secure design.
Modeling has proven to be an effective way to
identify design principles that help build security

www.practical-devsecops.com @pdevsecops @pdevsecops Practical DevSecOps

Agile Threat Modeling in 5 Simple Steps ebook

CHAPTER 2

KISS Threat Modeling in 5 Steps

To keep things simple and straightforward we are

going to consider threat modeling as a five step
process as listed below:

Define Rank Validate

Identify Address

Step 1
Define the scope of threat modeling itself,
the security requirements of a system.
KISS Versus The 4 Question
Step 2 Framework
Identify threats that exist in a system.
These 5 steps also fit into the four
Step 3
question framework of threat modeling.
Rank the threats to prioritize which threat
poses a higher risk to be addressed first. Step 1 is “What are we building?”
Step 4 Step 2 is “What can go wrong?”
Address the threats and the risk it poses Step 3, and step 4 are “What can we do
either by employing security controls, or about the things that can go wrong?”
through other ways. Step 5 is about “Did we do a good job?”

Step 5
Validate if threats are addressed properly.

www.practical-devsecops.com @pdevsecops @pdevsecops Practical DevSecOps

Agile Threat Modeling in 5 Simple Steps ebook

CHAPTER 3

The Key Ingredients

for the 5 Steps

In order to provide a bit of prescriptive advice we

are going to identify the four key ingredients for
every step. As an example, for the “Step 1 - Define”,
we are going to look at:

1. What is needed to Define?

2. When is an appropriate time to Define in
Agile Software Development?
3. How could the Define step be done in
Agile Software Development?
4. When do we know we are done Defining?

01
What is needed?
Defines some prerequisites, and participants
03
How could it be done?
Tried and tested ideas and tactics about how
that make the step as swift as possible. They a step can be performed. There can be many
are not necessarily mandatory, however if some other paths to achieve a certain goal, however
elements are absent, then it may significantly the outlined steps could also help you achieve
reduce the efficacy of the threat model itself. the same end goal.

02
When could it be done?
The Agile events and ceremonies where a step
04
When do we know we are done?
Every step needs to be continuous, meaning that
can be carried out. It does not necessarily with the cadence of Agile Software Development
mean that these are the only events where if your iteration is for 2 weeks or 3 weeks, then
a step needs to be carried out. In the true all the steps need to be continuously performed
spirit of empiricism, lessons learned based to adapt to the evolving business needs and the
on experimentation is an indispensable aid in software itself. However, are there some ways to
software development. bring a step to a satisfactory conclusion for an
iteration?

www.practical-devsecops.com @pdevsecops @pdevsecops Practical DevSecOps

Agile Threat Modeling in 5 Simple Steps ebook

STEP 1

Define
Define security requirements and
scope of the threat model

01
What is needed? 03
How could it be done?

1. Participants: Development Team, Architects, Defining the scope of the threat model and
Business Owners, Scrum Masters, Product identifying security requirements can be done
Owners, Secur ty (or a representative from by answering one or more of the following
each of the roles) questions:
2. A list of requirements in the form of themes,
1. Are there compliance requirements when not
or epics, or user stories
satisfied pose a threat to the system?
3. Assets, data either in the form of a High Level
2. Are there compliance requirements that guide
Design or in the form of a list
in the process of identifying security control
gaps?
3. What is the focus of the threat model? An

02
When could it be done?
entire system, or a theme, or an epic, or one
or more user stories?
1. Product Backlog Refinement sessions where
4. Does the security team have a list of
work items for the future iterations are
hardening guidelines or security guidelines to
refined to add more clarity
secure the system?
2. Sprint Planning sessions where work items
5. Are there any previous security assessment
for the current iteration are planned
reports where threats and security controls
3. Product Increment planning sessions where can be borrowed from?
work items for the future iterations are
6. Could the requirements be borrowed from
identified and refined
OWASP ASVS Levels or CIS Benchmark Levels?
4. Or any other event as the Agile Teams see fit

www.practical-devsecops.com @pdevsecops @pdevsecops Practical DevSecOps

Step 1: Define ebook

04
When do we know we are done?

1. When we know the scope of the threat

model which can be an entire system that
is yet to be developed, or a theme that is
being planned, or an epic or a collection of
user stories that would be developed and
delivered in the future.
2. Identified security requirements should help
the security team, architects, and developers
be able to design and deliver the system
securely.
3. Identified security requirements should help
the security team, architects, and developers
be able to uncover threats in the form of
security design or control gaps
4. When security goals are identified (Examples:
The uptime and availability of a system, the
critical data that should be revered as the
crown jewel, the asset that should the most
secure of all)

www.practical-devsecops.com @pdevsecops @pdevsecops Practical DevSecOps

Agile Threat Modeling in 5 Simple Steps ebook

STEP 2

Identify
Identify threats in the system

01
What is needed? 03
How could it be done?

1. Participants: Development Team, Architects, 1. Using techniques like Rapid Threat Model
Security (or a representative from each of the Prototyping
roles) 2. Using a short list of threats such as OWASP
2. A diagram of an architecture, or a mental Top 10, or CWE Top 25 and questioning if the
model of a proposed architecture that can be system is vulnerable to threats in the list
discussed to help in threat identification 3. Quickly drawing cards from the Elevation of
3. Criticality of data and assets Privilege card game, or OWASP Cornucopia, or
4. Security properties of a system or security Security Cards
goals 4. Answering a list of questions with respect
to Authentication, Authorization, Input
validation, Logging, Encryption, Hashing (Eg:

02
What are the authentication requirements?
When could it be done? What are the input validation requirements?)

1. Product Backlog Refinement sessions where 5. Using Mind Maps or Attack Trees to trace an
work items for the future iterations are attacker’s goal
refined to add more clarity 6. Identifying security gaps with the current
2. Sprint Planning sessions where work items implementation and the desired security
for the current iteration are planned requirements such as OWASP ASVS, or PCI
DSS, or CIS Benchmarks
3. Product Increment planning sessions where
work items for the future iterations are
identified and refined
4. Or any other event as the Agile Teams see fit

www.practical-devsecops.com @pdevsecops @pdevsecops Practical DevSecOps

Step 2: Identify ebook

04
When do we know we are done?

1. When an agreeable number of threats are

identified (the agreeable number can be 3, or
5, or 10, or 20, or 50 depending on the scope
of threat model, and when the threat model
activity is being done)
2. When all the cards in card game are drawn
and the relevance of the threats in the cards
are considered
3. When all the list of threats are enumerated to
identify their relevance for the system
4. When an agreed timebox expires (the
timebox can be 10 minutes to a couple
of hours depending on when the threat
modeling activity is performed)

www.practical-devsecops.com @pdevsecops @pdevsecops Practical DevSecOps

Agile Threat Modeling in 5 Simple Steps ebook

STEP 3

Rank
Rank risks based on likelihood and
impact ratings

01
What is needed? 03
How could it be done?

1. Participants: Development Team, Architects, 1. Threats need to be rated first to assign

Security, Business Owners, Product Owners themselves a risk score using some of the
(or a representative from each of the roles) following ways:
2. A list of threats (can be vulnerabilities, design – Risks can be scored with Rapid Risk
improvements, security requirements, Assessment technique from Mozille or
security control gaps) using a Bug Bar which is technique used at
Microsoft
– Risks can also be scored with OWASP Risk

02
When could it be done?
Rating Methodology with online calculators
– Risks can also be scored with a simple
1. Product Backlog Refinement sessions where likelihood versus impact rating based on
work items for the future iterations are the impact of Confidentiality, Integrity, and
refined to add more clarity Availability
2. Sprint Planning sessions where work items – Risks can also be scored based on the
for the current iteration are planned “shortest path to a high privileged asset”
3. Product Increment planning sessions where as prescribed in the Rapid Threat Model
work items for the future iterations are Prototyping technique
identified and refined – Risks can also be quickly scored on based
4. Or any other event as the Agile Teams see fit on a class of weaknesses (Example: Many
a times Injection flaws can be more
catastrophic than not having an audit trail
of events)

2. Risks need to be ordered according to their

score. Risks are ordered based on their
score, the higher the score the best it is to be
addressed first

www.practical-devsecops.com @pdevsecops @pdevsecops Practical DevSecOps

Step 3: Rank ebook

04
When do we know we are done?

1. When Top 10 risks are identified, when top 25

risks are identified
2. When all threats are ranked based on their
risk levels
3. When the timebox expires (to help not to get
lost in likelihood discussions, which many a
times may be highly subjective)

www.practical-devsecops.com @pdevsecops @pdevsecops Practical DevSecOps

Agile Threat Modeling in 5 Simple Steps ebook

STEP 4

Address
Address risks to secure the system

01
What is needed? 02
When could it be done?

1. Participants: Development Team, Architects, 1. Product Backlog Refinement sessions where

Security, Business Owners, Product Owners work items for the future iterations are
(or a representative from each of the roles) refined to add more clarity
2. A list of ordered Risks 2. Sprint Planning sessions where work items
for the current iteration are planned
3. Product Increment planning sessions where

03
How could it be done?
work items for the future iterations are
identified and refined
1. Risks can be addressed by one of the risk 4. Or any other event as the Agile Teams see fit
addressing techniques:

– Threats can be addressed by implementing

security controls to reduce risk
– Threats can be avoided by scrapping a
04
When do we know we are done?

feature or by changing the design of a 1. When the Top 10 risks are addressed
system 2. When all the identified risks are addressed
– Threats can be accepted if the risk is low 3. When the timebox expires
– Threats can be transferred to a vendor or a
third party if needed

2. The additional effort that requires design or

implementation changes needs to be justified
to the business stakeholders

10

www.practical-devsecops.com @pdevsecops @pdevsecops Practical DevSecOps

Step 4: Address ebook

11

www.practical-devsecops.com @pdevsecops @pdevsecops Practical DevSecOps

Agile Threat Modeling in 5 Simple Steps ebook

STEP 5

Validate
Validate risks are addressed
appropriately

01
What is needed? 02
When could it be done?

1. Participants: Development Team, Architects, 1. Sprint Review sessions where software

Security (or a representative from each of the increments are reviewed
roles) 2. System Demo events, Solution Demo events,
2. The threat model itself which can be a or any suitable event in the Agile Release
combination of a model and threats in the Train
form of risks or user or abuser stories 3. Or any other event as the Agile Teams see fit
3. If present, tests, test cases or other forms of
validation

03
How could it be done? 04
When do we know we are done?

1. By answering some of the below questions: 1. When the top 10 risks are found to be
addressed or not addressed
– Are the top 10 risks addressed and if the
security mitigations or controls are working 2. If the verification of security controls passed
as expected or failed

– Are the risks accepted or transferred if 3. If we know whether the threat model is still
addressed through risk acceptance or risk relevant to the system or not
transfer

2. By verifying if automated compliance checks

succeed
3. By verifying if security works as expected
through manual or automated verification
techniques
4. By checking if the threat model is still relevant
to the changes in the software increment of if
the threat model needs to be adjusted

12

www.practical-devsecops.com @pdevsecops @pdevsecops Practical DevSecOps

Agile Threat Modeling in 5 Simple Steps ebook

“
CHAPTER 4

Tips and Fine Tuning

All of the 5 steps can be completed quickly in less Some of the tactics
than 10 or 30 minutes by a highly agile team of
professionals that practice the techniques every
may look like shortcuts,
iteration. however the end goal
For new teams that adopt threat modeling in their is a secure system.
Agile Software development some of the above
steps may be condensed or merged. Initially
Threat Modeling does
iterations planning may take more time to complete not necessarily need to
a certain step, however as the teams mature, threat
modeling in 5 simple steps is going to become much
be comprehensive or
more efficient. complete, as long as it
If some of the participants are not available as is continuously refined
recommended, then the activity of threat modeling
can be performed with the available list of
through iterations as the
participants. The most important participants in an system evolves.
Agile set up are eventually the three underpinning
Scrum roles, that is the Development Team, Scrum
Master, and the Product Owner.

Many times threats and risks, requirements

and mitigations or user stories can be used
interchangeably if the collaboration between
Certified Threat Modeling Professional
Development, Operations, and Security strives to
achieve the security end goal.

Timeboxing is another essential tool to have

focussed discussions, timebox also keeps the
involved participants on their toes, to be nimble,
and comprehensive at the same time.

Some of the tactics may look like shortcuts,

however the end goal is a secure system.
Threat Modeling does not necessarily need to
be comprehensive or complete, as long as it is
continuously refined through iterations as the
system evolves.

13

www.practical-devsecops.com @pdevsecops @pdevsecops Practical DevSecOps

 Become a Certified
Threat Modeling Professional

Get Started

© 2023 Hysn Technologies Inc, All rights reserved