STRIDE Threat Modeling for Beginners - In 20 Minutes
Summary
TLDRThis 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
📝 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.
📈 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.
🛡️ 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.
💪 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.
🤔 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.
Mindmap
Keywords
💡threat modeling
💡data flow diagram (DFD)
💡trust boundary
💡STRIDE
💡vulnerability
💡mitigation
💡OWASP
💡principle of least privilege
💡risk
💡secure development lifecycle
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
浏览更多相关视频
Breaking The Kill Chain: A Defensive Approach
SDLC Life Cycle for Beginners | Software Development Life Cycle with Real life example
DP-203: 01 - Introduction
Incident Planning - CompTIA Security+ SY0-701 - 4.8
Cyber Security Interview Tips | Interview Topics Cyber Security Interview Preparation 2021
Pooling and Padding in Convolutional Neural Networks and Deep Learning
5.0 / 5 (0 votes)