WEBVTT
00:00:00.160 --> 00:00:02.080
Let's talk about threat modeling.
00:00:02.319 --> 00:00:09.119
If that phrase makes you picture whiteboards and diagrams and never-ending meetings, I get it.
00:00:09.839 --> 00:00:12.160
But here is the actual truth.
00:00:12.400 --> 00:00:16.000
Most developers do threat modeling all the time.
00:00:16.399 --> 00:00:18.160
We just don't call it that.
00:00:18.480 --> 00:00:24.719
Today, I want to show you how to do it on purpose in about 15 minutes.
00:00:25.199 --> 00:00:29.039
Hi, I'm Tanya Jenka, also known as SheHexPurple.
00:00:29.280 --> 00:00:36.240
Welcome to DevSecStation, a podcast for software developers who want to build more secure software.
00:00:36.479 --> 00:00:46.479
In each episode, I'll share a short practical lesson about secure coding, software security, and how to build safer systems without slowing development down.
00:00:46.719 --> 00:00:50.320
You can jump in at any episode, at any time.
00:00:50.799 --> 00:00:52.640
No homework required.
00:00:53.439 --> 00:00:56.079
This episode is sponsored by MAES.
00:00:56.399 --> 00:01:06.560
One of the biggest problems in security right now is that every vulnerability or cloud scanner says everything is critical, and honestly, no one has time for that.
00:01:06.879 --> 00:01:18.239
MAZES uses AI agents to investigate vulnerabilities in context, so you can focus on the issues that are actually exploitable in your environment and not just theoretically scary.
00:01:18.560 --> 00:01:30.000
Their AI agents also generate and prioritize fixes that knock out multiple vulnerabilities at once, which is honestly the kind of scaling that security teams really need right now.
00:01:30.239 --> 00:01:35.439
Learn more about maze at mazehq.com slash devsec.
00:01:36.000 --> 00:01:46.719
If you're building a new feature, adding an endpoint, integrating a service, or changing how data flows through your system, this episode is for you.
00:01:47.840 --> 00:01:57.840
So for your information, you do not need security approval, special tooling, or a diagram app or tool to do this.
00:01:58.079 --> 00:01:59.599
You can just start now.
00:02:00.000 --> 00:02:06.879
Threat modeling sounds complicated because we wrapped it in process, but at its core, it's actually very simple.
00:02:07.120 --> 00:02:16.159
Threat modeling is just intentionally thinking about what you're building, what you're protecting, and how it could be misused.
00:02:16.719 --> 00:02:18.400
That's it, seriously.
00:02:18.639 --> 00:02:29.759
The goal is not to predict every single possible attack, it's to notice obvious problems before they turn into security incidents and then fix them.
00:02:30.080 --> 00:02:34.479
Developers do this informally, literally, all the time.
00:02:34.800 --> 00:02:38.479
You add a new endpoint and you think, hmm, should this be authenticated?
00:02:38.560 --> 00:02:40.240
I should add authentication.
00:02:40.479 --> 00:02:44.879
You store something new in the database and you think, is this sensitive?
00:02:45.199 --> 00:02:49.599
You integrate a service and you think, oh, what's gonna happen if this goes down?
00:02:49.759 --> 00:02:51.120
If this goes down, then what?
00:02:51.280 --> 00:02:52.159
What should I do?
00:02:52.400 --> 00:02:54.639
That's literally you threat modeling.
00:02:54.800 --> 00:03:00.080
The difference is that when we do it casually, it's very easy to miss things.
00:03:00.319 --> 00:03:05.120
But when we do it intentionally, usually we catch all the important stuff.
00:03:05.360 --> 00:03:07.120
So how about we try it?
00:03:07.360 --> 00:03:13.360
I'm gonna give you a simple way to threat model one feature without a diagram.
00:03:13.599 --> 00:03:15.120
Okay, are you ready?
00:03:15.439 --> 00:03:18.400
Step one, define the thing.
00:03:18.719 --> 00:03:23.360
Write down on a piece of paper or type it out what you're building in just one sentence.
00:03:23.599 --> 00:03:28.479
So for example, I'm building an endpoint that lets users update their profile.
00:03:28.800 --> 00:03:35.520
If you cannot describe a feature simply, that's already a signal that you probably have a problem here.
00:03:35.680 --> 00:03:36.000
Okay.
00:03:36.560 --> 00:03:40.319
Step two, let's identify what you are protecting.
00:03:40.560 --> 00:03:43.199
Ask yourself, what data is involved?
00:03:43.439 --> 00:03:44.639
Is it sensitive?
00:03:44.879 --> 00:03:47.280
Who should be allowed to do this action?
00:03:47.520 --> 00:03:51.360
Would it be bad if something went wrong and what would that be?
00:03:51.840 --> 00:03:56.319
Step three, identify entry points and trust boundaries.
00:03:56.560 --> 00:03:59.919
Ask yourself, where does this data come from?
00:04:00.400 --> 00:04:03.840
Where does it cross from untrusted into trusted?
00:04:04.080 --> 00:04:07.520
Where do we rely on authentication and authorization?
00:04:07.840 --> 00:04:09.199
I have a tip for you.
00:04:09.439 --> 00:04:13.360
These are the same places you look at during a secure code review.
00:04:13.599 --> 00:04:15.759
Remember that from the last episode?
00:04:16.240 --> 00:04:17.759
Okay, step four.
00:04:18.000 --> 00:04:20.079
Ask three misuse questions.
00:04:20.240 --> 00:04:27.199
You don't need a long list, just ask a few things such as, what if someone who shouldn't do this tries to do it anyway?
00:04:27.439 --> 00:04:31.759
What if this input is malicious or otherwise unexpected?
00:04:32.079 --> 00:04:35.199
What happens if this fails in a really weird way?
00:04:35.519 --> 00:04:39.199
If you can answer those questions, you're doing threat modeling.
00:04:39.519 --> 00:04:42.800
Step five, decide what needs a control.
00:04:43.279 --> 00:04:51.600
So for anything that you feel uncomfortable about, you need to decide, do we already have a control to protect against this?
00:04:51.920 --> 00:04:55.040
And if not, does one need to be added?
00:04:55.279 --> 00:04:59.279
This is where threat modeling turns from just a discussion into action.
00:04:59.519 --> 00:05:04.800
We don't just want to identify threats, we want to defend against the ones that actually scare us.
00:05:05.040 --> 00:05:07.519
Shall we do our bad better best thing now?
00:05:07.680 --> 00:05:08.959
I think we should.
00:05:09.279 --> 00:05:14.480
A bad approach for threat modeling is assuming security testing will just catch everything later.
00:05:14.720 --> 00:05:19.839
It pushes risk downstream, where fixes are more expensive, and it might get missed.
00:05:20.079 --> 00:05:24.480
A slightly better approach is thinking about threats casually while building.
00:05:24.720 --> 00:05:32.959
This helps, but it's inconsistent, and it depends largely on memory, which, as we know, is not a reliable way to do things.
00:05:33.199 --> 00:05:38.639
The best approach is threat modeling each new app or feature on purpose.
00:05:38.879 --> 00:05:43.199
One feature can be 15 minutes, a single page of notes, done.
00:05:43.439 --> 00:05:47.360
When you do this regularly, secure design becomes a habit.
00:05:47.519 --> 00:05:51.199
If you do just one thing after this episode, please do this.
00:05:51.439 --> 00:05:55.040
Threat model one feature that you are currently working on.
00:05:55.279 --> 00:05:57.279
Use the five steps that we just covered.
00:05:57.439 --> 00:06:00.319
Write it down somewhere that your team can see it.
00:06:00.480 --> 00:06:08.720
So you could put it in a PR description, a ticket, or a simple markdown file, whatever it is that makes sense to you, but so it won't disappear.
00:06:08.959 --> 00:06:10.959
You don't need to solve everything.
00:06:11.279 --> 00:06:16.319
Just identify one place where a control is missing or unclear and then fix it.
00:06:16.480 --> 00:06:18.319
That's a huge win.
00:06:18.879 --> 00:06:21.759
Threat modeling is not security theater.
00:06:22.079 --> 00:06:24.480
It really can create true value.
00:06:24.639 --> 00:06:28.160
It's a way to ensure fewer surprises happen to you later.
00:06:28.399 --> 00:06:33.600
When developers do it themselves, security stops becoming a blocker for you.
00:06:33.680 --> 00:06:40.480
And instead, security starts to be part of what you think of as good design.
00:06:41.199 --> 00:06:43.839
Thanks for listening to DevSecStation.
00:06:44.000 --> 00:06:49.360
If you enjoyed this episode, please subscribe, share it with a friend, or leave a review.
00:06:49.519 --> 00:06:52.000
It helps more people discover the show.
00:06:52.240 --> 00:06:57.279
If you'd like to learn more, I'm Tanya Jenka, also known as SheHacksPurple.
00:06:57.439 --> 00:07:01.040
And I teach secure coding training for software developers.
00:07:01.279 --> 00:07:04.560
You can find me online at shehackspurple.ca.
00:07:05.199 --> 00:07:07.040
Thank you for being here.
00:00:00.160 --> 00:00:02.080
Let's talk about threat modeling.
00:00:02.319 --> 00:00:09.119
If that phrase makes you picture whiteboards and diagrams and never-ending meetings, I get it.
00:00:09.839 --> 00:00:12.160
But here is the actual truth.
00:00:12.400 --> 00:00:16.000
Most developers do threat modeling all the time.
00:00:16.399 --> 00:00:18.160
We just don't call it that.
00:00:18.480 --> 00:00:24.719
Today, I want to show you how to do it on purpose in about 15 minutes.
00:00:25.199 --> 00:00:29.039
Hi, I'm Tanya Jenka, also known as SheHexPurple.
00:00:29.280 --> 00:00:36.240
Welcome to DevSecStation, a podcast for software developers who want to build more secure software.
00:00:36.479 --> 00:00:46.479
In each episode, I'll share a short practical lesson about secure coding, software security, and how to build safer systems without slowing development down.
00:00:46.719 --> 00:00:50.320
You can jump in at any episode, at any time.
00:00:50.799 --> 00:00:52.640
No homework required.
00:00:53.439 --> 00:00:56.079
This episode is sponsored by MAES.
00:00:56.399 --> 00:01:06.560
One of the biggest problems in security right now is that every vulnerability or cloud scanner says everything is critical, and honestly, no one has time for that.
00:01:06.879 --> 00:01:18.239
MAZES uses AI agents to investigate vulnerabilities in context, so you can focus on the issues that are actually exploitable in your environment and not just theoretically scary.
00:01:18.560 --> 00:01:30.000
Their AI agents also generate and prioritize fixes that knock out multiple vulnerabilities at once, which is honestly the kind of scaling that security teams really need right now.
00:01:30.239 --> 00:01:35.439
Learn more about maze at mazehq.com slash devsec.
00:01:36.000 --> 00:01:46.719
If you're building a new feature, adding an endpoint, integrating a service, or changing how data flows through your system, this episode is for you.
00:01:47.840 --> 00:01:57.840
So for your information, you do not need security approval, special tooling, or a diagram app or tool to do this.
00:01:58.079 --> 00:01:59.599
You can just start now.
00:02:00.000 --> 00:02:06.879
Threat modeling sounds complicated because we wrapped it in process, but at its core, it's actually very simple.
00:02:07.120 --> 00:02:16.159
Threat modeling is just intentionally thinking about what you're building, what you're protecting, and how it could be misused.
00:02:16.719 --> 00:02:18.400
That's it, seriously.
00:02:18.639 --> 00:02:29.759
The goal is not to predict every single possible attack, it's to notice obvious problems before they turn into security incidents and then fix them.
00:02:30.080 --> 00:02:34.479
Developers do this informally, literally, all the time.
00:02:34.800 --> 00:02:38.479
You add a new endpoint and you think, hmm, should this be authenticated?
00:02:38.560 --> 00:02:40.240
I should add authentication.
00:02:40.479 --> 00:02:44.879
You store something new in the database and you think, is this sensitive?
00:02:45.199 --> 00:02:49.599
You integrate a service and you think, oh, what's gonna happen if this goes down?
00:02:49.759 --> 00:02:51.120
If this goes down, then what?
00:02:51.280 --> 00:02:52.159
What should I do?
00:02:52.400 --> 00:02:54.639
That's literally you threat modeling.
00:02:54.800 --> 00:03:00.080
The difference is that when we do it casually, it's very easy to miss things.
00:03:00.319 --> 00:03:05.120
But when we do it intentionally, usually we catch all the important stuff.
00:03:05.360 --> 00:03:07.120
So how about we try it?
00:03:07.360 --> 00:03:13.360
I'm gonna give you a simple way to threat model one feature without a diagram.
00:03:13.599 --> 00:03:15.120
Okay, are you ready?
00:03:15.439 --> 00:03:18.400
Step one, define the thing.
00:03:18.719 --> 00:03:23.360
Write down on a piece of paper or type it out what you're building in just one sentence.
00:03:23.599 --> 00:03:28.479
So for example, I'm building an endpoint that lets users update their profile.
00:03:28.800 --> 00:03:35.520
If you cannot describe a feature simply, that's already a signal that you probably have a problem here.
00:03:35.680 --> 00:03:36.000
Okay.
00:03:36.560 --> 00:03:40.319
Step two, let's identify what you are protecting.
00:03:40.560 --> 00:03:43.199
Ask yourself, what data is involved?
00:03:43.439 --> 00:03:44.639
Is it sensitive?
00:03:44.879 --> 00:03:47.280
Who should be allowed to do this action?
00:03:47.520 --> 00:03:51.360
Would it be bad if something went wrong and what would that be?
00:03:51.840 --> 00:03:56.319
Step three, identify entry points and trust boundaries.
00:03:56.560 --> 00:03:59.919
Ask yourself, where does this data come from?
00:04:00.400 --> 00:04:03.840
Where does it cross from untrusted into trusted?
00:04:04.080 --> 00:04:07.520
Where do we rely on authentication and authorization?
00:04:07.840 --> 00:04:09.199
I have a tip for you.
00:04:09.439 --> 00:04:13.360
These are the same places you look at during a secure code review.
00:04:13.599 --> 00:04:15.759
Remember that from the last episode?
00:04:16.240 --> 00:04:17.759
Okay, step four.
00:04:18.000 --> 00:04:20.079
Ask three misuse questions.
00:04:20.240 --> 00:04:27.199
You don't need a long list, just ask a few things such as, what if someone who shouldn't do this tries to do it anyway?
00:04:27.439 --> 00:04:31.759
What if this input is malicious or otherwise unexpected?
00:04:32.079 --> 00:04:35.199
What happens if this fails in a really weird way?
00:04:35.519 --> 00:04:39.199
If you can answer those questions, you're doing threat modeling.
00:04:39.519 --> 00:04:42.800
Step five, decide what needs a control.
00:04:43.279 --> 00:04:51.600
So for anything that you feel uncomfortable about, you need to decide, do we already have a control to protect against this?
00:04:51.920 --> 00:04:55.040
And if not, does one need to be added?
00:04:55.279 --> 00:04:59.279
This is where threat modeling turns from just a discussion into action.
00:04:59.519 --> 00:05:04.800
We don't just want to identify threats, we want to defend against the ones that actually scare us.
00:05:05.040 --> 00:05:07.519
Shall we do our bad better best thing now?
00:05:07.680 --> 00:05:08.959
I think we should.
00:05:09.279 --> 00:05:14.480
A bad approach for threat modeling is assuming security testing will just catch everything later.
00:05:14.720 --> 00:05:19.839
It pushes risk downstream, where fixes are more expensive, and it might get missed.
00:05:20.079 --> 00:05:24.480
A slightly better approach is thinking about threats casually while building.
00:05:24.720 --> 00:05:32.959
This helps, but it's inconsistent, and it depends largely on memory, which, as we know, is not a reliable way to do things.
00:05:33.199 --> 00:05:38.639
The best approach is threat modeling each new app or feature on purpose.
00:05:38.879 --> 00:05:43.199
One feature can be 15 minutes, a single page of notes, done.
00:05:43.439 --> 00:05:47.360
When you do this regularly, secure design becomes a habit.
00:05:47.519 --> 00:05:51.199
If you do just one thing after this episode, please do this.
00:05:51.439 --> 00:05:55.040
Threat model one feature that you are currently working on.
00:05:55.279 --> 00:05:57.279
Use the five steps that we just covered.
00:05:57.439 --> 00:06:00.319
Write it down somewhere that your team can see it.
00:06:00.480 --> 00:06:08.720
So you could put it in a PR description, a ticket, or a simple markdown file, whatever it is that makes sense to you, but so it won't disappear.
00:06:08.959 --> 00:06:10.959
You don't need to solve everything.
00:06:11.279 --> 00:06:16.319
Just identify one place where a control is missing or unclear and then fix it.
00:06:16.480 --> 00:06:18.319
That's a huge win.
00:06:18.879 --> 00:06:21.759
Threat modeling is not security theater.
00:06:22.079 --> 00:06:24.480
It really can create true value.
00:06:24.639 --> 00:06:28.160
It's a way to ensure fewer surprises happen to you later.
00:06:28.399 --> 00:06:33.600
When developers do it themselves, security stops becoming a blocker for you.
00:06:33.680 --> 00:06:40.480
And instead, security starts to be part of what you think of as good design.
00:06:41.199 --> 00:06:43.839
Thanks for listening to DevSecStation.
00:06:44.000 --> 00:06:49.360
If you enjoyed this episode, please subscribe, share it with a friend, or leave a review.
00:06:49.519 --> 00:06:52.000
It helps more people discover the show.
00:06:52.240 --> 00:06:57.279
If you'd like to learn more, I'm Tanya Jenka, also known as SheHacksPurple.
00:06:57.439 --> 00:07:01.040
And I teach secure coding training for software developers.
00:07:01.279 --> 00:07:04.560
You can find me online at shehackspurple.ca.
00:07:05.199 --> 00:07:07.040
Thank you for being here.
