The Four Question Framework with Adam Shostack

In this episode, we discuss the four-question framework for threat modeling with its creator, Adam Shostack. We dive deep into the meaning and purpose of each question and how they simplify the threat modeling process. The four questions are: 1) What are we working on? 2) What can go wrong? 3) What are we going to do about it? 4) Did we do a good job? 

Adam explains that these questions are not a methodology but a foundation for a more practical approach to threat modeling. We also discuss the importance of retrospectives, evolving the framework, and how it can be applied in various situations. Lean into the four questions, and you might become a threat modeling Jedi.

Welcome to Smart Threat Modeling. Devici makes threat modeling simple, actionable, and scalable. Identify and deal with threats faster than ever. Build three free models and collaborate with up to ten people in our Free Forever plan. Get started at devici.com and threat model for free! Smart threat modeling for development teams.

Episode Transcript

(00:09):
If you've ever heard the wordsthreat modeling, you've probably
heard of Adam Shostack.
In Threat modeling.
Adam is a single name likePrince or Elvis.
He's the first person I'm awareof that brought threat modeling
to tech companies during histenure at Microsoft.
Adam's famous for many thingswithin the world of threat
modeling, but we'll focus on hisfour question framework about

(00:32):
threat modeling.
Who better to explain theframework than Adam himself?

Adam Shostack (00:38):
I think of the four questions as a framework.
In fact, I call them the fourquestion framework for threat
modeling, I don't think of themas a methodology because we
don't have specific ways ofanswering them, and that's both
a strength and a weakness.
It's a strength in that itenables us to vary up the way we

(01:04):
answer them, and in varying themup, we can respond to the
situations in which we findourselves.
I created the four questionframework while I was at
Microsoft, and in fact, Icreated it as five questions\ I
was trying to simplify how wetalked about threat modeling.
T he first question aboutrequirements and goals has

(01:28):
fallen away.
similarly, The first way Irepresented it was in a loop, in
a hamster wheel of pain, torepresent that we threat model
at the beginning of a project,we threat model as we're
creating features, we threatmodel at the end.
The implication was that threatmodeling is a never ending

(01:52):
chore.
So I simplified it to be morelinear and I think that that's a
superior approach.
the four questions are, what arewe working on?
What can go wrong?
What are we going to do aboutit?
And did we do a good job?

Chris Romeo (02:10):
In the world of threat modeling, we often speak
of methodology.
Adam states that the fourquestion framework is not a
methodology, but it's essentialto understand why that is.
Some argue that methodology is areligious debate where their
approach is the only way to dothreat modeling.
Threat modeling methodology isan approach that a practitioner

(02:31):
uses to perform threat modeling,consisting of both a process and
a set of threats and mitigationsfor consideration.
Many different methodologiesexist and we'll unpack many of
them over time, but for now, youmay have heard of Stride or
Lindon, Pasta or No Dirt.
These all represent differentmethodologies for performing

(02:51):
threat modeling.
As Adam said, the four questionsare not a methodology.
The four questions are a way tosimplify threat modeling at its
core.
The four questions are simple.
Simple always equals moresecure.
When something is simple, it'seasier to explain to the people
that need to internalize it.
The four questions are a greatplace to start and are the

(03:13):
foundation for how most peopleapproach threat modeling.
Let's dive deeper into the fourquestions because it is the
easiest way to begin threatmodeling.
You don't have to remember amillion details or facts or
implement a 27 step process forsuccess.
The four questions are simple,by design.
They lead you down apath/process that generates a

(03:35):
meaningful outcome.

Adam Shostack (03:38):
The first question, what are we working on
is a scoping question, and ourfriend, Izar likes to say,
threat model.
Every story.
In which case, what are weworking on?
Is what are we working on inthis story?
Or if what we're working on is abig waterfall project, say

(04:02):
windows or a rocket ship, or aself-driving car, what we're
working on can be an overallquestion, but this question both
gives us scope, it gives us anintroduction to the project if
we're coming in as a consultant.
And it helps us gain a sharedunderstanding.

(04:23):
We tend to answer the question,what are we working on with
diagrams often created inconversation to help bring
people together in mutualunderstanding of the system that
they're working on.

Chris Romeo (04:42):
With this question, as Adam said, we're addressing
the scope of a given threatmodel.
We want to encourage people tothreat model whatever they are
personally working on.
So when a person answers thisquestion, they can narrow the
scope to a manageable size.
The Izar he mentions is ourfriend, Izar Tarandach, who
you'll hear from later in theseries.

(05:02):
Now for the second question,what can go wrong?

Adam Shostack (05:07):
The question of what can go wrong is both the
heart of threat modeling and thehardest part of threat modeling.
It's the core of the framework,and we answer it either from
simply asking what can go wrong,or we can use structures.
We can use things like stride orkill chains to help us answer

(05:31):
the question of what can gowrong.
And we do that to give usrepeatability, which is a great
property, but it's not anessential property.
When I say it's the hardestpart, I wanna mention here, if I
may, my new book.

Threats (05:48):
What Every Engineer Should Learn From Star Wars is
an attempt to share and todevelop common answers.
What are the norms that everyengineer should know?
Just subtitle of the book isreally an essential part of how

(06:08):
we get to that consistency, andso I'm really pleased with it.
And hope people like it.
The other thing I wanna mentionabout what can go wrong is just
asking that question can beincredibly powerful.
Making space for people toexpress the things about which
they worry.

(06:29):
This can be the evilbrainstorming side of things
that our friend Tanya Jancatalks about.
This can be the use of,fortunately, unfortunately,
where I say, fortunately, we'veencrypted that data and you say,
unfortunately, the key is storedon the local machine.

(06:50):
And I say, fortunately, we'veset permissions on it.
And you say, unfortunately,they're world readable.
And we can even just use thequestion of what can go wrong
and encourage people to speak,make their answers valid, tell
them we appreciate hearing them.

(07:10):
That's really powerful.

Chris Romeo (07:13):
What can go wrong is not prescribing a particular
methodology but directing us tolist the threats regardless of
the source, as Adam states, aswe document it in the threat
modeling manifesto, threatmodeling is both art and
science.
Evil brainstorming representsthe creative side of threat
modeling.
On to the third question.

Adam Shostack (07:36):
So the third question of"what are we gonna do
about it?" ranges from we'regonna develop controls, we're
gonna develop features that makethese threats harder to exploit,
or we're gonna deploy controls.
Technologies, products,processes that help us defend

(07:56):
our systems.
And when it's hard to develop ordeploy controls, we can go
towards risk management, wherewe can eliminate, accept, or
transfer risk.
And I think the relationshipbetween a risk and a threat is a
risk is a quantified threat,where we start to focus on

(08:19):
likelihood and impact to help usdecide between the various ways
in which we do risk managementbecause the controls are
difficult to develop, deploy,operate, make the system
unusable, et cetera.

Chris Romeo (08:36):
Mitigations are the key value driver of threat
modeling.
Without mitigations, we'rewasting time, dreaming up
threats that will never beresolved.
Mitigations dictate the positivesecurity change that occurs
because of discovering thethreats.
Mitigations require.
Follow up to determine if anyfixes are in place.

Adam Shostack (08:57):
So the final question in the four question
framework is, did we do a goodjob?
And we can start this at a verymechanical level.
Do we have a diagram?
Do we have a list of threats,which is appropriate for the way
in which we're engaged in thesethings?

(09:17):
We can answer it at asatisfaction level.
Would you recommend threatmodeling to a colleague?
And if you would, great.
And if not, there's probably anissue and we can answer it
retrospectively.
Did our pen test do better thistime than it did previously?

Chris Romeo (09:37):
We want to use retrospectives to pinpoint ways
to improve our threat modelingprocess, methodology, or tools.
The key to long-term securityimprovement is not being afraid
of asking for feedback.
We talk about this often in theDevOps world.
Craving actionable feedback andblameless retrospective.
The same applies to the world ofthreat modeling.

(09:59):
Before I could wrap this up, Ihad to understand Adam's
thoughts on the future of thefour question framework.
Where will it go in the future?

Adam Shostack (10:07):
All right.
So do I see any evolution to thefour questions?
No, but that's the thing aboutevolution is it surprises you.
When we were creating themanifesto, the team argued for
did we do a good enough job, andmade that case.

(10:28):
If I had foreseen that I wouldhave evolved it.
So another thing that I did iswhen I started with the four
questions, I would say, what areyou working on?
It was a consulting approach.
It was an external approachrather than a collaborative
approach.
And I apologize to whoever madethe case that we should make it

(10:49):
"we" they made a strong case.
And so now, I talk about thefour questions in terms of what
are we working on, what are wegonna do about it?

Chris Romeo (11:00):
The four question framework for threat modeling is
a foundational approach.
We see many differentorganizations building their
threat modeling programs usingthis approach.
The reason it's so successful issimple.
The method is simple.
By remembering four simplequestions, you can threat model
anything.
So give it a try next timeyou're standing in the security

(11:21):
line at the airport.
But a tip from my experience.
Don't share the results withthem in real time.
They may not share the samesense of humor that you do.