WEBVTT
00:00:32.783 --> 00:00:37.513
If you've ever heard the words threat modeling, you've probably heard of Adam Shostack.
00:00:38.152 --> 00:00:39.112
In Threat modeling.
00:00:39.292 --> 00:00:42.563
Adam is a single name like Prince or Elvis.
00:00:43.162 --> 00:00:48.923
He's the first person I'm aware of that brought threat modeling to tech companies during his tenure at Microsoft.
00:00:49.792 --> 00:00:56.153
Adam's famous for many things within the world of threat modeling, but we'll focus on his four question framework about threat modeling.
00:00:57.097 --> 00:01:00.248
Who better to explain the framework than Adam himself?
00:01:02.013 --> 00:01:05.403
I think of the four questions as a framework.
00:01:05.403 --> 00:01:21.566
In fact, I call them the four question framework for threat modeling, I don't think of them as a methodology because we don't have specific ways of answering them, and that's both a strength and a weakness.
00:01:21.835 --> 00:01:33.802
It's a strength in that it enables us to vary up the way we answer them, and in varying them up, we can respond to the situations in which we find ourselves.
00:01:35.061 --> 00:01:47.371
I created the four question framework while I was at Microsoft, and in fact, I created it as five questions\ I was trying to simplify how we talked about threat modeling.
00:01:47.371 --> 00:01:53.131
T he first question about requirements and goals has fallen away.
00:01:53.776 --> 00:02:09.206
similarly, The first way I represented it was in a loop, in a hamster wheel of pain, to represent that we threat model at the beginning of a project, we threat model as we're creating features, we threat model at the end.
00:02:09.936 --> 00:02:16.377
The implication was that threat modeling is a never ending chore.
00:02:16.986 --> 00:02:22.657
So I simplified it to be more linear and I think that that's a superior approach.
00:02:23.734 --> 00:02:27.063
the four questions are, what are we working on?
00:02:27.243 --> 00:02:28.323
What can go wrong?
00:02:28.473 --> 00:02:29.823
What are we going to do about it?
00:02:30.274 --> 00:02:32.524
And did we do a good job?
00:02:33.574 --> 00:02:36.843
In the world of threat modeling, we often speak of methodology.
00:02:37.533 --> 00:02:44.313
Adam states that the four question framework is not a methodology, but it's essential to understand why that is.
00:02:45.093 --> 00:02:50.974
Some argue that methodology is a religious debate where their approach is the only way to do threat modeling.
00:02:51.859 --> 00:03:01.489
Threat modeling methodology is an approach that a practitioner uses to perform threat modeling, consisting of both a process and a set of threats and mitigations for consideration.
00:03:02.658 --> 00:03:11.808
Many different methodologies exist and we'll unpack many of them over time, but for now, you may have heard of Stride or Lindon, Pasta or No Dirt.
00:03:12.109 --> 00:03:15.919
These all represent different methodologies for performing threat modeling.
00:03:16.378 --> 00:03:19.198
As Adam said, the four questions are not a methodology.
00:03:19.737 --> 00:03:23.518
The four questions are a way to simplify threat modeling at its core.
00:03:24.207 --> 00:03:25.617
The four questions are simple.
00:03:26.218 --> 00:03:28.348
Simple always equals more secure.
00:03:28.918 --> 00:03:33.298
When something is simple, it's easier to explain to the people that need to internalize it.
00:03:34.078 --> 00:03:39.448
The four questions are a great place to start and are the foundation for how most people approach threat modeling.
00:03:40.468 --> 00:03:45.598
Let's dive deeper into the four questions because it is the easiest way to begin threat modeling.
00:03:46.078 --> 00:03:51.987
You don't have to remember a million details or facts or implement a 27 step process for success.
00:03:52.527 --> 00:03:55.108
The four questions are simple, by design.
00:03:55.587 --> 00:04:00.237
They lead you down a path/process that generates a meaningful outcome.
00:04:02.323 --> 00:04:12.163
The first question, what are we working on is a scoping question, and our friend, Izar likes to say, threat model.
00:04:12.163 --> 00:04:12.913
Every story.
00:04:12.913 --> 00:04:15.163
In which case, what are we working on?
00:04:15.673 --> 00:04:19.543
Is what are we working on in this story?
00:04:20.142 --> 00:04:42.762
Or if what we're working on is a big waterfall project, say windows or a rocket ship, or a self-driving car, what we're working on can be an overall question, but this question both gives us scope, it gives us an introduction to the project if we're coming in as a consultant.
00:04:43.250 --> 00:04:46.819
And it helps us gain a shared understanding.
00:04:46.819 --> 00:05:03.889
We tend to answer the question, what are we working on with diagrams often created in conversation to help bring people together in mutual understanding of the system that they're working on.
00:05:05.391 --> 00:05:09.982
With this question, as Adam said, we're addressing the scope of a given threat model.
00:05:10.552 --> 00:05:14.391
We want to encourage people to threat model whatever they are personally working on.
00:05:15.021 --> 00:05:19.762
So when a person answers this question, they can narrow the scope to a manageable size.
00:05:20.211 --> 00:05:25.732
The Izar he mentions is our friend, Izar Tarandach, who you'll hear from later in the series.
00:05:26.211 --> 00:05:28.942
Now for the second question, what can go wrong?
00:05:30.877 --> 00:05:39.187
The question of what can go wrong is both the heart of threat modeling and the hardest part of threat modeling.
00:05:39.757 --> 00:05:50.137
It's the core of the framework, and we answer it either from simply asking what can go wrong, or we can use structures.
00:05:50.153 --> 00:05:57.653
We can use things like stride or kill chains to help us answer the question of what can go wrong.
00:05:57.833 --> 00:06:05.692
And we do that to give us repeatability, which is a great property, but it's not an essential property.
00:06:06.413 --> 00:06:11.423
When I say it's the hardest part, I wanna mention here, if I may, my new book.
00:06:11.453 --> 00:06:22.276
Threats: What Every Engineer Should Learn From Star Wars is an attempt to share and to develop common answers.
00:06:22.336 --> 00:06:26.117
What are the norms that every engineer should know?
00:06:26.237 --> 00:06:35.723
Just subtitle of the book is really an essential part of how we get to that consistency, and so I'm really pleased with it.
00:06:36.091 --> 00:06:37.110
And hope people like it.
00:06:38.360 --> 00:06:48.110
The other thing I wanna mention about what can go wrong is just asking that question can be incredibly powerful.
00:06:48.110 --> 00:06:52.391
Making space for people to express the things about which they worry.
00:06:53.314 --> 00:06:57.814
This can be the evil brainstorming side of things that our friend Tanya Janca talks about.
00:06:58.535 --> 00:07:13.535
This can be the use of, fortunately, unfortunately, where I say, fortunately, we've encrypted that data and you say, unfortunately, the key is stored on the local machine.
00:07:13.834 --> 00:07:17.014
And I say, fortunately, we've set permissions on it.
00:07:17.014 --> 00:07:20.375
And you say, unfortunately, they're world readable.
00:07:21.305 --> 00:07:33.425
And we can even just use the question of what can go wrong and encourage people to speak, make their answers valid, tell them we appreciate hearing them.
00:07:33.905 --> 00:07:35.555
That's really powerful.
00:07:37.031 --> 00:07:51.661
What can go wrong is not prescribing a particular methodology but directing us to list the threats regardless of the source, as Adam states, as we document it in the threat modeling manifesto, threat modeling is both art and science.
00:07:52.730 --> 00:07:56.141
Evil brainstorming represents the creative side of threat modeling.
00:07:56.821 --> 00:07:58.360
On to the third question.
00:07:59.958 --> 00:08:15.377
So the third question of"what are we gonna do about it?" ranges from we're gonna develop controls, we're gonna develop features that make these threats harder to exploit, or we're gonna deploy controls.
00:08:15.454 --> 00:08:21.155
Technologies, products, processes that help us defend our systems.
00:08:21.694 --> 00:08:32.855
And when it's hard to develop or deploy controls, we can go towards risk management, where we can eliminate, accept, or transfer risk.
00:08:33.235 --> 00:08:59.269
And I think the relationship between a risk and a threat is a risk is a quantified threat, where we start to focus on likelihood and impact to help us decide between the various ways in which we do risk management because the controls are difficult to develop, deploy, operate, make the system unusable, et cetera.
00:09:00.320 --> 00:09:03.230
Mitigations are the key value driver of threat modeling.
00:09:03.860 --> 00:09:08.570
Without mitigations, we're wasting time, dreaming up threats that will never be resolved.
00:09:09.440 --> 00:09:14.389
Mitigations dictate the positive security change that occurs because of discovering the threats.
00:09:14.580 --> 00:09:15.669
Mitigations require.
00:09:15.669 --> 00:09:18.980
Follow up to determine if any fixes are in place.
00:09:20.549 --> 00:09:26.250
So the final question in the four question framework is, did we do a good job?
00:09:27.259 --> 00:09:31.278
And we can start this at a very mechanical level.
00:09:31.369 --> 00:09:32.839
Do we have a diagram?
00:09:32.928 --> 00:09:39.798
Do we have a list of threats, which is appropriate for the way in which we're engaged in these things?
00:09:40.980 --> 00:09:43.029
We can answer it at a satisfaction level.
00:09:43.721 --> 00:09:46.572
Would you recommend threat modeling to a colleague?
00:09:47.142 --> 00:09:49.272
And if you would, great.
00:09:49.331 --> 00:09:55.091
And if not, there's probably an issue and we can answer it retrospectively.
00:09:55.422 --> 00:09:59.532
Did our pen test do better this time than it did previously?
00:10:01.087 --> 00:10:07.658
We want to use retrospectives to pinpoint ways to improve our threat modeling process, methodology, or tools.
00:10:08.197 --> 00:10:12.577
The key to long-term security improvement is not being afraid of asking for feedback.
00:10:13.207 --> 00:10:15.108
We talk about this often in the DevOps world.
00:10:15.418 --> 00:10:19.298
Craving actionable feedback and blameless retrospective.
00:10:19.957 --> 00:10:21.967
The same applies to the world of threat modeling.
00:10:22.883 --> 00:10:27.952
Before I could wrap this up, I had to understand Adam's thoughts on the future of the four question framework.
00:10:28.403 --> 00:10:29.533
Where will it go in the future?
00:10:31.356 --> 00:10:31.716
All right.
00:10:31.716 --> 00:10:34.836
So do I see any evolution to the four questions?
00:10:35.557 --> 00:10:40.057
No, but that's the thing about evolution is it surprises you.
00:10:40.177 --> 00:10:51.427
When we were creating the manifesto, the team argued for did we do a good enough job, and made that case.
00:10:51.907 --> 00:10:55.147
If I had foreseen that I would have evolved it.
00:10:55.746 --> 00:11:02.346
So another thing that I did is when I started with the four questions, I would say, what are you working on?
00:11:03.216 --> 00:11:04.807
It was a consulting approach.
00:11:04.807 --> 00:11:08.407
It was an external approach rather than a collaborative approach.
00:11:08.746 --> 00:11:15.966
And I apologize to whoever made the case that we should make it"we" they made a strong case.
00:11:16.057 --> 00:11:22.596
And so now, I talk about the four questions in terms of what are we working on, what are we gonna do about it?
00:11:23.840 --> 00:11:27.440
The four question framework for threat modeling is a foundational approach.
00:11:27.950 --> 00:11:32.509
We see many different organizations building their threat modeling programs using this approach.
00:11:33.350 --> 00:11:35.539
The reason it's so successful is simple.
00:11:35.779 --> 00:11:36.830
The method is simple.
00:11:37.669 --> 00:11:41.629
By remembering four simple questions, you can threat model anything.
00:11:42.409 --> 00:11:45.769
So give it a try next time you're standing in the security line at the airport.
00:11:46.220 --> 00:11:47.620
But a tip from my experience.
00:11:48.409 --> 00:11:50.600
Don't share the results with them in real time.
00:11:51.230 --> 00:11:54.230
They may not share the same sense of humor that you do.
00:00:32.783 --> 00:00:37.513
If you've ever heard the words threat modeling, you've probably heard of Adam Shostack.
00:00:38.152 --> 00:00:39.112
In Threat modeling.
00:00:39.292 --> 00:00:42.563
Adam is a single name like Prince or Elvis.
00:00:43.162 --> 00:00:48.923
He's the first person I'm aware of that brought threat modeling to tech companies during his tenure at Microsoft.
00:00:49.792 --> 00:00:56.153
Adam's famous for many things within the world of threat modeling, but we'll focus on his four question framework about threat modeling.
00:00:57.097 --> 00:01:00.248
Who better to explain the framework than Adam himself?
00:01:02.013 --> 00:01:05.403
I think of the four questions as a framework.
00:01:05.403 --> 00:01:21.566
In fact, I call them the four question framework for threat modeling, I don't think of them as a methodology because we don't have specific ways of answering them, and that's both a strength and a weakness.
00:01:21.835 --> 00:01:33.802
It's a strength in that it enables us to vary up the way we answer them, and in varying them up, we can respond to the situations in which we find ourselves.
00:01:35.061 --> 00:01:47.371
I created the four question framework while I was at Microsoft, and in fact, I created it as five questions\ I was trying to simplify how we talked about threat modeling.
00:01:47.371 --> 00:01:53.131
T he first question about requirements and goals has fallen away.
00:01:53.776 --> 00:02:09.206
similarly, The first way I represented it was in a loop, in a hamster wheel of pain, to represent that we threat model at the beginning of a project, we threat model as we're creating features, we threat model at the end.
00:02:09.936 --> 00:02:16.377
The implication was that threat modeling is a never ending chore.
00:02:16.986 --> 00:02:22.657
So I simplified it to be more linear and I think that that's a superior approach.
00:02:23.734 --> 00:02:27.063
the four questions are, what are we working on?
00:02:27.243 --> 00:02:28.323
What can go wrong?
00:02:28.473 --> 00:02:29.823
What are we going to do about it?
00:02:30.274 --> 00:02:32.524
And did we do a good job?
00:02:33.574 --> 00:02:36.843
In the world of threat modeling, we often speak of methodology.
00:02:37.533 --> 00:02:44.313
Adam states that the four question framework is not a methodology, but it's essential to understand why that is.
00:02:45.093 --> 00:02:50.974
Some argue that methodology is a religious debate where their approach is the only way to do threat modeling.
00:02:51.859 --> 00:03:01.489
Threat modeling methodology is an approach that a practitioner uses to perform threat modeling, consisting of both a process and a set of threats and mitigations for consideration.
00:03:02.658 --> 00:03:11.808
Many different methodologies exist and we'll unpack many of them over time, but for now, you may have heard of Stride or Lindon, Pasta or No Dirt.
00:03:12.109 --> 00:03:15.919
These all represent different methodologies for performing threat modeling.
00:03:16.378 --> 00:03:19.198
As Adam said, the four questions are not a methodology.
00:03:19.737 --> 00:03:23.518
The four questions are a way to simplify threat modeling at its core.
00:03:24.207 --> 00:03:25.617
The four questions are simple.
00:03:26.218 --> 00:03:28.348
Simple always equals more secure.
00:03:28.918 --> 00:03:33.298
When something is simple, it's easier to explain to the people that need to internalize it.
00:03:34.078 --> 00:03:39.448
The four questions are a great place to start and are the foundation for how most people approach threat modeling.
00:03:40.468 --> 00:03:45.598
Let's dive deeper into the four questions because it is the easiest way to begin threat modeling.
00:03:46.078 --> 00:03:51.987
You don't have to remember a million details or facts or implement a 27 step process for success.
00:03:52.527 --> 00:03:55.108
The four questions are simple, by design.
00:03:55.587 --> 00:04:00.237
They lead you down a path/process that generates a meaningful outcome.
00:04:02.323 --> 00:04:12.163
The first question, what are we working on is a scoping question, and our friend, Izar likes to say, threat model.
00:04:12.163 --> 00:04:12.913
Every story.
00:04:12.913 --> 00:04:15.163
In which case, what are we working on?
00:04:15.673 --> 00:04:19.543
Is what are we working on in this story?
00:04:20.142 --> 00:04:42.762
Or if what we're working on is a big waterfall project, say windows or a rocket ship, or a self-driving car, what we're working on can be an overall question, but this question both gives us scope, it gives us an introduction to the project if we're coming in as a consultant.
00:04:43.250 --> 00:04:46.819
And it helps us gain a shared understanding.
00:04:46.819 --> 00:05:03.889
We tend to answer the question, what are we working on with diagrams often created in conversation to help bring people together in mutual understanding of the system that they're working on.
00:05:05.391 --> 00:05:09.982
With this question, as Adam said, we're addressing the scope of a given threat model.
00:05:10.552 --> 00:05:14.391
We want to encourage people to threat model whatever they are personally working on.
00:05:15.021 --> 00:05:19.762
So when a person answers this question, they can narrow the scope to a manageable size.
00:05:20.211 --> 00:05:25.732
The Izar he mentions is our friend, Izar Tarandach, who you'll hear from later in the series.
00:05:26.211 --> 00:05:28.942
Now for the second question, what can go wrong?
00:05:30.877 --> 00:05:39.187
The question of what can go wrong is both the heart of threat modeling and the hardest part of threat modeling.
00:05:39.757 --> 00:05:50.137
It's the core of the framework, and we answer it either from simply asking what can go wrong, or we can use structures.
00:05:50.153 --> 00:05:57.653
We can use things like stride or kill chains to help us answer the question of what can go wrong.
00:05:57.833 --> 00:06:05.692
And we do that to give us repeatability, which is a great property, but it's not an essential property.
00:06:06.413 --> 00:06:11.423
When I say it's the hardest part, I wanna mention here, if I may, my new book.
00:06:11.453 --> 00:06:22.276
Threats: What Every Engineer Should Learn From Star Wars is an attempt to share and to develop common answers.
00:06:22.336 --> 00:06:26.117
What are the norms that every engineer should know?
00:06:26.237 --> 00:06:35.723
Just subtitle of the book is really an essential part of how we get to that consistency, and so I'm really pleased with it.
00:06:36.091 --> 00:06:37.110
And hope people like it.
00:06:38.360 --> 00:06:48.110
The other thing I wanna mention about what can go wrong is just asking that question can be incredibly powerful.
00:06:48.110 --> 00:06:52.391
Making space for people to express the things about which they worry.
00:06:53.314 --> 00:06:57.814
This can be the evil brainstorming side of things that our friend Tanya Janca talks about.
00:06:58.535 --> 00:07:13.535
This can be the use of, fortunately, unfortunately, where I say, fortunately, we've encrypted that data and you say, unfortunately, the key is stored on the local machine.
00:07:13.834 --> 00:07:17.014
And I say, fortunately, we've set permissions on it.
00:07:17.014 --> 00:07:20.375
And you say, unfortunately, they're world readable.
00:07:21.305 --> 00:07:33.425
And we can even just use the question of what can go wrong and encourage people to speak, make their answers valid, tell them we appreciate hearing them.
00:07:33.905 --> 00:07:35.555
That's really powerful.
00:07:37.031 --> 00:07:51.661
What can go wrong is not prescribing a particular methodology but directing us to list the threats regardless of the source, as Adam states, as we document it in the threat modeling manifesto, threat modeling is both art and science.
00:07:52.730 --> 00:07:56.141
Evil brainstorming represents the creative side of threat modeling.
00:07:56.821 --> 00:07:58.360
On to the third question.
00:07:59.958 --> 00:08:15.377
So the third question of"what are we gonna do about it?" ranges from we're gonna develop controls, we're gonna develop features that make these threats harder to exploit, or we're gonna deploy controls.
00:08:15.454 --> 00:08:21.155
Technologies, products, processes that help us defend our systems.
00:08:21.694 --> 00:08:32.855
And when it's hard to develop or deploy controls, we can go towards risk management, where we can eliminate, accept, or transfer risk.
00:08:33.235 --> 00:08:59.269
And I think the relationship between a risk and a threat is a risk is a quantified threat, where we start to focus on likelihood and impact to help us decide between the various ways in which we do risk management because the controls are difficult to develop, deploy, operate, make the system unusable, et cetera.
00:09:00.320 --> 00:09:03.230
Mitigations are the key value driver of threat modeling.
00:09:03.860 --> 00:09:08.570
Without mitigations, we're wasting time, dreaming up threats that will never be resolved.
00:09:09.440 --> 00:09:14.389
Mitigations dictate the positive security change that occurs because of discovering the threats.
00:09:14.580 --> 00:09:15.669
Mitigations require.
00:09:15.669 --> 00:09:18.980
Follow up to determine if any fixes are in place.
00:09:20.549 --> 00:09:26.250
So the final question in the four question framework is, did we do a good job?
00:09:27.259 --> 00:09:31.278
And we can start this at a very mechanical level.
00:09:31.369 --> 00:09:32.839
Do we have a diagram?
00:09:32.928 --> 00:09:39.798
Do we have a list of threats, which is appropriate for the way in which we're engaged in these things?
00:09:40.980 --> 00:09:43.029
We can answer it at a satisfaction level.
00:09:43.721 --> 00:09:46.572
Would you recommend threat modeling to a colleague?
00:09:47.142 --> 00:09:49.272
And if you would, great.
00:09:49.331 --> 00:09:55.091
And if not, there's probably an issue and we can answer it retrospectively.
00:09:55.422 --> 00:09:59.532
Did our pen test do better this time than it did previously?
00:10:01.087 --> 00:10:07.658
We want to use retrospectives to pinpoint ways to improve our threat modeling process, methodology, or tools.
00:10:08.197 --> 00:10:12.577
The key to long-term security improvement is not being afraid of asking for feedback.
00:10:13.207 --> 00:10:15.108
We talk about this often in the DevOps world.
00:10:15.418 --> 00:10:19.298
Craving actionable feedback and blameless retrospective.
00:10:19.957 --> 00:10:21.967
The same applies to the world of threat modeling.
00:10:22.883 --> 00:10:27.952
Before I could wrap this up, I had to understand Adam's thoughts on the future of the four question framework.
00:10:28.403 --> 00:10:29.533
Where will it go in the future?
00:10:31.356 --> 00:10:31.716
All right.
00:10:31.716 --> 00:10:34.836
So do I see any evolution to the four questions?
00:10:35.557 --> 00:10:40.057
No, but that's the thing about evolution is it surprises you.
00:10:40.177 --> 00:10:51.427
When we were creating the manifesto, the team argued for did we do a good enough job, and made that case.
00:10:51.907 --> 00:10:55.147
If I had foreseen that I would have evolved it.
00:10:55.746 --> 00:11:02.346
So another thing that I did is when I started with the four questions, I would say, what are you working on?
00:11:03.216 --> 00:11:04.807
It was a consulting approach.
00:11:04.807 --> 00:11:08.407
It was an external approach rather than a collaborative approach.
00:11:08.746 --> 00:11:15.966
And I apologize to whoever made the case that we should make it"we" they made a strong case.
00:11:16.057 --> 00:11:22.596
And so now, I talk about the four questions in terms of what are we working on, what are we gonna do about it?
00:11:23.840 --> 00:11:27.440
The four question framework for threat modeling is a foundational approach.
00:11:27.950 --> 00:11:32.509
We see many different organizations building their threat modeling programs using this approach.
00:11:33.350 --> 00:11:35.539
The reason it's so successful is simple.
00:11:35.779 --> 00:11:36.830
The method is simple.
00:11:37.669 --> 00:11:41.629
By remembering four simple questions, you can threat model anything.
00:11:42.409 --> 00:11:45.769
So give it a try next time you're standing in the security line at the airport.
00:11:46.220 --> 00:11:47.620
But a tip from my experience.
00:11:48.409 --> 00:11:50.600
Don't share the results with them in real time.
00:11:51.230 --> 00:11:54.230
They may not share the same sense of humor that you do.
