STRIDE Threat Modeling for Beginners - In 20 Minutes

Summary

This engaging video from NetC Explained dives into the often overlooked but crucial aspect of cybersecurity: threat modeling. The host demystifies the concept, making it accessible and intriguing, especially for those new to the field. Viewers learn to create Data Flow Diagrams, identify trust boundaries, and evaluate the strengths and weaknesses of an application, using a simplified stride framework. Real-world examples, like a railway reservation system and a college library website, illustrate the process. The video emphasizes collaboration across teams and the proactive integration of security measures in the development lifecycle, promising not just theoretical knowledge but practical tools to enhance application security and potentially save significant resources.

Takeaways

• 🔍 Threat modeling is a crucial, yet often overlooked part of security that involves understanding the details of an application to identify and address potential threats.
• 🚀 Understanding threat modeling can significantly reduce time, headaches, and financial costs for consultants and clients alike.
• 📈 The basics of threat modeling involve creating a Data Flow Diagram (DFD), labeling trust boundaries, and identifying the strengths and weaknesses of an application.
• 🛠️ The OWASP threat modeling process is recommended for further detailed guidance beyond the basics.
• 📊 DFDs are used in threat modeling to visualize data flow within systems, varying in detail from level 0 (least detailed) to level 5 (most detailed).
• 🔐 Trust boundaries in DFDs help identify where trust levels change within the system, crucial for spotting potential security vulnerabilities.
• 🗒️ Utilizing frameworks like STRIDE within threat modeling helps systematically identify and address various types of security threats.
• 🤝 Threat modeling should be a collaborative and ongoing process involving multiple stakeholders to ensure comprehensive security coverage.
• 🕒 The time required for threat modeling can vary, but it is an essential investment for securing applications effectively.
• 🎓 Proper threat modeling can empower developers, improve application security, and should ideally be conducted before writing any code or making significant changes.

Q & A

What is threat modeling and why is it important?

Threat modeling is a process used to identify and assess potential threats to a system, including the strengths and weaknesses of the application. It is important because it helps in understanding the application at a detailed level, identifying and mitigating potential vulnerabilities, and enhancing the security of the system.

What are the three basic steps of threat modeling mentioned in the video?

The three basic steps of threat modeling mentioned are creating a Data Flow Diagram (DFD), labeling the trust boundaries, and identifying the strengths and weaknesses of the application.

What is a Data Flow Diagram (DFD) and its purpose in threat modeling?

A Data Flow Diagram (DFD) is a graphical representation of the flow of data through a system. It shows how data is processed by the system's components. In threat modeling, DFDs help in understanding how the system works and in identifying potential security vulnerabilities.

What are trust boundaries in the context of threat modeling?

Trust boundaries in threat modeling represent the points in the data flow where the level of trust changes, such as between unauthenticated and authenticated users or between regular users and administrators. Identifying trust boundaries helps in understanding where to apply security controls to prevent unauthorized access.

Can you explain the STRIDE methodology used for identifying threats?

STRIDE is a methodology used to identify threats based on six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privileges. It helps in systematically assessing and addressing the potential vulnerabilities in each area.

Why is it recommended to perform threat modeling early in the software development lifecycle?

Performing threat modeling early in the software development lifecycle, ideally before any code is written, allows for the identification and mitigation of potential security issues in the planning phase. This approach helps in building security into the application from the start rather than trying to address vulnerabilities after development.

What is the importance of collaboration in threat modeling?

Collaboration is crucial in threat modeling because it involves working with developers, architects, and other stakeholders to understand the system's architecture and potential threats. This collaborative process ensures a comprehensive view of the application's security posture and promotes shared responsibility for security.

How does the video suggest handling the completion of a threat model?

The video suggests handling the completion of a threat model through a series of meetings: an initial meeting to understand the application and identify threats, a second meeting to confirm findings and correct any inaccuracies, and a final meeting after drafting the threat model to ensure everyone agrees and understands the identified threats and mitigations.

What are the benefits of using existing application architecture diagrams in threat modeling?

Using existing application architecture diagrams in threat modeling can simplify the process by providing a base to overlay the threat model. It helps in easier identification of components, data flows, and trust boundaries, making the creation of DFDs more efficient and accurate.

Why might a threat model need to be updated, and how often should this be done?

A threat model might need to be updated due to changes in the application's architecture, introduction of new features, or emerging threats. It should be revisited and updated regularly, especially before major changes in the application, to ensure it accurately reflects the current state of the system and its security needs.

Outlines

00:00

📝 What is threat modeling and why it matters

The first paragraph introduces threat modeling, explaining it is an often overlooked part of security that involves understanding an application in detail to identify threats. It can save time, make clients happy, and help find bugs. The speaker promises to teach the basics of threat modeling in three parts: creating a data flow diagram, labeling trust boundaries, and identifying strengths/weaknesses.

05:03

📈 Creating data flow diagrams (DFDs)

The second paragraph explains data flow diagrams, which map data flows in a system. It shows DFDs at levels 0 (high-level), 1 (adds some detail), and 2 (very detailed). Level 1 is best for basic threat modeling since it balances understandability and detail. DFDs overlay well with existing architecture diagrams.

10:03

🛡️ Labeling trust boundaries

The third paragraph introduces trust boundaries, which indicate changing trust levels, like between user and application backend. It shows examples of labeling trust boundaries on sample DFDs based on privilege levels and access controls, following the principle of least privilege.

15:04

💪 Identifying strengths and weaknesses

The fourth paragraph explains using the STRIDE framework to list security strengths and weaknesses at each trust boundary. It shows an example spreadsheet breaking down protections and vulnerabilities for spoof, tamper, repudiation, information disclosure, denial of service, elevation of privilege.

20:05

🤔 Answering common questions

The fifth paragraph answers common questions about threat modeling: when to do it (planning phase), working with teams (collaborative meetings), and time required (2-3 weeks to start). It emphasizes threat modeling is an ongoing process centered on security conversations.

Keywords

💡threat modeling

Threat modeling is the process of analyzing an application or system to identify potential security threats. In the video, it is presented as an important but often overlooked part of the security process. Threat modeling involves creating data flow diagrams, identifying trust boundaries, and calling out strengths/weaknesses using a framework like STRIDE. It helps developers build more secure software by considering threats early in the design process.

💡data flow diagram (DFD)

A data flow diagram (DFD) visually maps out the architecture and data flows in an application or system. DFDs are created at different levels of detail (0-5) during threat modeling to understand the basic pieces of the system and how data moves between them. The video shows examples of DFDs at levels 0, 1, and 2.

💡trust boundary

A trust boundary represents a separation between areas of different trust levels in a system, like between public users and authenticated users. Identifying trust boundaries is an important step in threat modeling. It helps to isolate components and highlight areas to focus additional security controls.

💡STRIDE

STRIDE is a threat modeling framework used to categorize different types of threats: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. In the video, STRIDE is used to list strengths/weaknesses at different trust boundaries.

💡vulnerability

A vulnerability is a weakness in a system that can be exploited by threats. As part of threat modeling, hypothetical vulnerabilities are included in the example (like no 2FA or cleartext credentials) to demonstrate identifying weaknesses that could turn into threats.

💡mitigation

A mitigation is a safeguard put in place to reduce the risk or potential impact of threats exploiting vulnerabilities. Strong mitigations are listed as strengths during the threat modeling process (like TLS certificates, authorization controls etc.).

💡OWASP

OWASP (Open Web Application Security Project) is an organization focused on web app security. The video references the OWASP threat modeling methodology as a source for additional details on performing more advanced threat modeling.

💡principle of least privilege

The principle of least privilege is an important concept in information security. It means limiting access rights for users, accounts, and processes to only those needed to perform their tasks. This principle is mentioned in the video when discussing separation between application components.

💡risk

Risk refers to the likelihood and impact associated with a threat successfully exploiting a vulnerability. While not explicitly covered, threat modeling ultimately enables better risk assessment by revealing priorities for security efforts.

💡secure development lifecycle

The secure development lifecycle incorporates security practices like threat modeling into the software development process. The video recommends threat modeling early, during planning and design phases, before issues multiply.

Highlights

Threat modeling often goes overlooked but can save time, make clients happy, and identify bugs.

Threat modeling involves creating data flow diagrams, labeling trust boundaries, and identifying strengths and weaknesses.

Data flow diagrams visually map how data flows through an application at different levels of detail.

Trust boundaries indicate where trust levels change, like between unauthenticated and authenticated users.

Use the STRIDE framework to list security strengths and weaknesses at each trust boundary.

The user side focuses on spoofing, repudiation, information disclosure and denial of service.

The application side focuses on tampering, repudiation, information disclosure and escalation of privileges.

Ideally threat modeling is done in the planning phase before any code is written.

Threat modeling is a collaborative, ongoing process involving multiple meetings with stakeholders.

The real value in threat modeling is pushing security responsibility onto developers.

Creating a basic threat model doesn't take long, but getting stakeholder buy-in and info can take weeks.

Finished example threat models help demonstrate structure and validate assumptions.

Use threat models to build security into applications instead of tacking it on later.

Let developers feel empowered by threat modeling instead of treating it as an audit.

Try the exercise yourself to identify additional strengths, weaknesses, assumptions.

Transcripts

if I could save a company a million

dollar a year on their security budget

this is how I would do it what's going

on everybody Welcome to netc explained

and in this video we're going to be

talking about a piece of the security

puzzle that often goes way overlooked

and that is threat modeling now if the

first thing you thought when you heard

threat modeling was H that sounds boring

it's really not in fact it's really

exciting to learn the ins and outs of an

application in that level of detail

to be honest this is something that I

wish I knew when I was first starting

out my career in Consulting and bug

hunting this would have saved me a lot

of time and it would have made my

clients happy too but if you're not

convinced I have a finished threat model

in the description below of an AI

application very similar to chat GPT

this will give you an idea of what one

of these threat models can look like and

how they can help you in identifying and

determining new bugs in an application

now if you want to learn how to make one

yourself to save time headache and money

then and that's what we're going to get

into today I'm excited so let's get

started now for this video we're only

going to go over the basics of threat

modeling and we're going to do that in

three parts we're going to create a DFD

or a data flow diagram we're going to

label the trust boundaries and then

we're going to identify the strengths

and weaknesses of the application right

we're going to call out the threats

there's obviously more we can do after

that but this will get you started to

take things further I highly recommend

the oos threat modeling process for more

detail it's a really solid guide and I

highly recommend you check it out after

this video I also want to point out that

for this video I'll mainly be focusing

on applications but this exact same

process works for any other system such

as networking or Cloud step one data

flow diagrams dfds can come into

different levels of detail so we'll

starting at zero going down to one two

all the way down to five getting more

and more detailed as you go further so

let's take a look Okay so here's an

example of a level zero DFD this is for

a railway reservation system so we see

that we have a passenger who can submit

a reservation or cancel a reservation

and then receive travel information from

the railway reservation itself and then

we also have admin which has kind of a

back Channel access to uh reserve and

cancel information as well as uh upload

and download train info and gather

passenger information so think of data

flow diagram level zero as a back of the

napkin kind of thing right it's a very

quick sketch that you draw out in about

2 minutes so not a lot of detail but

they're still very useful in

understanding parts of the application

okay the next one is a level one data

flow diagram notice how this goes into a

little bit more detail right so we

separate the railway reservation system

into the reservation process and the

inquiry process the passenger still has

access to both processes uh but we see

how the reservation process handles

reservations through the reservation

storage then we see how inquiries handle

things through uploads and downloads it

also connects to a ticket generation

process and allows you to generate

reports to the

admin level one is the one that I use

most often uh this is goes into enough

detail to understand a little bit of the

underlying bits of the system but not

too much detail where it over

complicates the process what's also

really nice is that a lot of application

developers will already have

architecture diagram that you can kind

of read off of so you can overlay your

threat model with our architecture

diagrams and it makes things a lot

easier when you're creating a threat

model and having those

conversations the last one I want you to

take a look at is a level two data flow

diagram notice how this goes into way

more detail so we have the reservation

process query process Railway department

and inquiry process over here that's

being used for passengers as well as for

reporting and

reservations we're communicating back to

a searching process and then that talks

to a waiting process a confirmation

process a cancellation process and then

the ticket generation and it goes all

the way out to generate the ticket for

the client so this is a lot more detail

almost a little too much for what we

need to create a basic threat model but

this just kind of gives you an idea of

what a level two data flow diagram looks

like now that we have a map of our

application data flow we need to

identify the trust boundaries I have

here up on the screen uh an example of a

data flow with trust boundaries that are

being labeled trust boundaries are

places in the DFD where trust levels

change so think unauthenticated user to

authenticated user or regular user to a

power user to admin to internal engineer

you get the idea I have a couple data

flow diagrams for us to take a look at

and label the trust boundaries so you

can see what that process looks like

okay here's an example data flow diagram

this is a level one data flow diagram

I'm using draw IO I find it to be very

helpful when creating these things for

clients because it's easier for me to

finish up the report create the data

flow diagram and then pass that off to

the development team so they can further

their

practices so we have a couple things

labeled here right we have our actor

which is usually in a small rectangle

and that's going to be our user in this

case we have data flows going to

multiple processes and those processes

uh communicate to either the user or

backend systems and then you see this

multi Circle over here on the right uh

which is is a multi-process so this is

something that we use to kind of

abstract a bunch of different things

happening all at the same time uh access

to our database is going to be our data

store as or asset Library uh so this is

going to be the app database and it's

with two lines one on top and one on

bottom so this is somewhat standard of

data flow diagrams so if you look online

on how to create a data flow diagram

you're going to see a lot of these

symbols finally we have our trust

boundary which is represented by a

dotted line that we saw earlier so in

this case we have a user that can

connect to an application backend and

modify a report they also receive static

files from what looks like to be a web

application that application backend

then also connects to a backend data

store so this is going to be an

application database for storing and

modification and then it has access to

some other backend processes that either

May tie back into the user or it may tie

into some other function being performed

on the back

end so in this case what we want to do

is we want to look for uh change in

trust levels right so for example if we

go from an unauthenticated user to an

authenticated user or maybe we want to

keep the user separate from the process

in the application backend itself that's

usually where you'll find the First

Trust boundary we want to separate the

user from the application we don't want

to give them full access to that

application so let's go ahead and add a

trust boundary

to this spot between the user and the

application

backend now there's still a couple more

that we need to set up if you look

closely you can see that the application

backend talks to a back-end database now

we want to be very careful because

things like SQL injection can happen or

data corruption so we want to limit the

access that the application has to the

back-end database right we're not going

to run it with admin credentials or

anything like that we want to follow the

principle of least privilege so we're

going to put another trust boundary

there in the application database

oops there we

go and then finally our application

backend can communicate to some other

processes on the back end as well um

usually this is done through apis but we

want to continue to follow principle of

least privileged so especially since

this application backend has the slim

but possibility of being compromised by

a user we want to create a separate

barrier between the application itself

that the user can interface with and the

further services that are down

Downstream so we're going to create one

last trust boundary between the

application process and the backend

Services I'll just go ahead and rotate

that so it looks a little

nicer awesome this is our completed data

flow diagram for this level one

DFD I have one more data flow diagram

for us to take a look at and this is

going to be the level two data flow

diagram so here we can see this looks

like a college library website and even

though it's a level two we still have a

couple abstracted multi-processes going

on and I did that to keep things a

little simple so it all fit on one

screen so here we have the users that

can send requests and receive responses

from the library website itself and then

likewise we have Librarians which can

receive requests and receive responses

we have web pages that are in disk now

this can either be static files or

dynamic files such as PHP go python Java

you name it uh that's communicating with

the library website

and then of course we have a back-end

database which is part of the College

library database and the database

files so when we're looking at this we

want to make sure that we do have a

separation between the users and the

application users should not have full R

of the application and usually they'll

have at least somewhat limited access to

the application even once they log in

right they're not all going to be

considered admin or an internal engineer

likewise the Librarians even though they

might have more access than a regular

user in order to do different things

they're still going to have limited

access because they're also not admin or

internal engineer so the First Trust

boundary we're going to put is actually

going to be between the library in uh

the Librarians and the users and the

library's website

itself so let's go ahead and add

that and rotate this a

bit

oops and let's

expand

so that we create a separate uh

separation between the users the

Librarians and then the college website

itself cool so we see that because we

have this separation the web pages on

disk are separate from the users but

what about the library website and the

database just like the last data flow

diagram we want to have a separation

between the web application that users

are directly interacting with and then

any other Downstream system just like

this database but we don't need a put

any other boundary between the database

and the database files right maybe this

is a distributed database or uh maybe

this is just an abstraction showing that

the database has access to some other

files on the back end right this could

be an S3 bucket or some sort of local

file storage or even just a separate

database entirely so let's go ahead and

add another data uh another trust

boundary between the College library

website and the College library

database

and that's it there's only two trust

boundaries here uh these are the only

places where trust levels are going to

change within the application at least

that we're showing right now uh you'll

notice that the multiprocess little

Loops here uh these are here because

they're also part of that same trust

level if they were parts of different

trust levels we would want to separate

that out and then highlight the trust

boundaries in there as well again most

of the time I use level one data flow

diagrams level two data flow diagrams

can go into a lot more detail but they

also become a lot more

complicated awesome the last thing we're

going to do here is pick a framework to

list out our strengths and

weaknesses for this exercise I'm going

to use stride but if you're an internal

team I also really like the idea behind

pasta as well so you may want to look

into that stride stands for spoofing

tampering repudiation basically a fancy

word for logging that way I can't say

that I didn't do something information

disclosure denial of service and

elevation of privileges

what you want to do here is look at each

of your trust boundaries and then write

down the strengths and weaknesses for

each category you're going to do this

for both sides of the trust boundary

just to make sure you get proper

coverage your strengths in this case are

really your mitigations so for spoofing

as an example we're going to use a

username and password to log into the

application so I can't pretend to be

somebody else but depending on the

application maybe we need a little bit

more right maybe we need multiactor

authentication so that's something that

we're going to want to write down as

well or we can use SS TLS to prevent

tampering or information disclosure for

anything that's in transit across that

trust

boundary so let's take a look here's the

DFD that we're going to look at we have

three trust boundaries so we're going to

want to set up three sections in our

spreadsheet so this is our example

spreadsheet I usually use this when I'm

going through my trust boundaries in

order to identify this stride

methodology so we have three trust

boundaries trust boundary 01 which is

going from the user to the application

backend trust boundary 02 two which is

going from the application backend to

the application database and then trust

boundary 3 which is going from the

application backend to the other

services that we

identified so I'm going to keep things

simple and we're only going to fill out

trust boundary one in this video uh for

a complete list of what this looks like

again take a look at the finished threat

model at the link in the description

something I want to point out is that

not all of the stride categories always

make sense when you're looking at

different aspects of the application so

you'll notice here in trust boundary R1

I have a couple gray boxes and the

reason why I have these gray boxes is

because if we're the user we don't need

to worry about tampering data that we

enter into the application but the

application itself needs to worry about

information that we tampered into it

same thing with information disclosure

denial of service and escalation of

privileges so the user doesn't really

need to worry about these things so we

gray these out to keep things a little

simple now as I mentioned earlier we're

going to have something as a strength in

our application right so we're running

with the assumption that there's an

authentication like a login flow so a

username and

password so I'm going to list that in as

one of the strengths but maybe this is

an application that requires a little

bit more security so let's call out no

two-factor authentication as one of our

first vulnerabilities or first weakness

in the

application so this is going to be

labeled as

vol01 for repudiation let's say there's

no logging Trail or Telemetry coming

from the user uh so this is something

that we'll want to call out as uh

limitation right so no audit Trail and

this is going to be our vul

O2 we're just going to make

things look nice I'll just keep

everything

lowercase bump that up so we're done

with the user side now let's look at the

application side so how do we prevent

oh I just realized I misspelled

strengths that's

funny that's silly all right all

fixed so on the application side how do

we make sure that the application isn't

being spoofed back to the user so if

this was a regular HTTP site we wouldn't

be able to tell um somebody could spoof

the DNS or there could be some bit

flipping or they could even just visit

the wrong website maybe they change a

letter on accident but in this case

we're going to use a TLS certificate to

prevent spoofing the application to the

user so this is going to stop uh Hackers

from doing something like a man- inthe

middle attack so this is going to be our

TLS

certificate now what about tampering

what do we have in place to prevent the

user from tampering with different

aspects of the application now if you

know about crossy scripting and input

injection you're probably already

familiar with input filtering out output

en coding but let's run with the

assumption that this application doesn't

have either of those so we're going to

put

no business validation input and this is

going to be our

vul

vol03 I'll just fix that so it looks

nice and neat so that's going to be our

vul 03 uh what

about uh repudiation let's say for

instance the application doesn't have

any logging on itself or at least we

don't have proper logging on the

application other than the fact that

somebody's accessing the app uh so this

will be no

logging user actions and this is going

to be

v04 uh let's take a look at information

disclosure let's say that the app was

really poorly made and so we have uh

clear text

credentials and this is going to be

volum

05

and then as far as denial of service

let's say that we do have a strength and

we have uh backup ISP and a WF in

place and then as far as escalation of

privileges let's say that we have a

strong authorization control pattern

that we put at every aspect of the

application if I can

spell

awesome so when we're done this is what

it's going to look like for each of

these and we can continue through trust

boundary 2 and Trust boundary 3 but I'll

leave that as an exercise for you to see

if there's any other strengths or

weaknesses that you can come up with on

your own if you do this exercise let me

know in the comments below and see what

you come up with how many

vulnerabilities did you identify what

kind of assumptions did you make it's a

lot of fun doing this kind of

exercise perfect and that's threat

modeling in a nutshell once you finish

everything that we did in this video I

really want you to go back to the oos

threat modeling process and list out the

threats and identify mitigations for

each one as I said earlier there's

obviously a lot more that you can do

with this and I encourage you to

continue to play around and learn for a

finished threat model take a look at the

one that I have in the description below

it shows you what a final report looks

like including my assumptions strengths

and weaknesses and mitigation approach

now there's a couple common questions

that I want to go over before I let you

go the first question is when should you

do threat modeling here's a diagram of

the software development life cycle so

when you should do threat modeling is

ideally before any line of code is

written so that's going to be in the

planning phase now if this is an

application that already exists and you

want to do threat modeling on that then

make sure that you do threat modeling

before any major changes are done to the

application once you get everybody on

board with threat model then it's a lot

easier to build the security into the

application instead of tacking it onto

the side at the end now the second

question is how do you work with other

teams it's important to keep in mind

that threat modeling isn't a oneandone

kind of thing right it's a collaborative

and ongoing process so you're going to

want to get other stakeholders on board

the biggest value of a threat model

isn't the report at the end it's going

through the process and pushing that

security responsibility onto your

developers so that they can feel more

empowered to do their best work now I

would recommend three meetings at least

so the first meeting is for you to work

with the developers and The Architects

to get an understanding of how the

application works and any possible

threats that you can come up with right

out the gate from there you're going to

want to create your first draft of the

data flow diagram the test boundaries

and the threats identified then you're

going to have your second meeting and in

your second meeting you're going to

confirm with developer teams and the

architects in order to make sure that

everybody's on the same page usually in

the second meeting you're going to

notice that there are some things that

you're missing or some assumptions that

you made or maybe the developers didn't

communicate certain things properly so

they'll be able to correct you there now

if everything goes well then you're

going to have one more meeting and

that's going to be after you draft your

final version of the threat model which

includes your data flow diagram and your

threats uh I would also add in

mitigations and prioritize risks as well

which you'll see in the OAS threat

modeling process so so this final

meeting is really just to get a check

off from everybody to make sure that

we're all on the same page we've

identified everything that we need to

and we're good to go the last common

question is how long does it take to

make a threat model well the answer to

this kind of depends on the application

and the team and a lot of other factors

so I can't give you a solid number I

would recommend spending at least two to

three weeks especially if you're not

part of the org or if you're not part of

the development team remember it takes a

lot of time to get all of the St steh

holders into their same room for a

meeting so factor that into your

timeline once you have all your

information and everybody signed off the

actual creation of the threat model

doesn't take that long at all so to give

you an example the AI threat model that

I put together in the description that

took me only a couple of days once I

knew how I wanted to lay out the

application and what common applications

look like so there you have it a brief

introduction to threat modeling systems

I hope this video has convinced you of

how helpful threat models can be and

give you the confidence to start

building them on your own well that's

all I have for you guys today for more

information check out the links in the

description below if you like this video

let me know by leaving a thumbs up it

really helps with the YouTube algorithm

and don't forget to subscribe to see

more videos like this I'll see you next

time