2.1 Threat Modeling Part 1
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Transcription
00:00
>> Hi, and welcome to
00:00
the second episode of
00:00
cybersecurity architecture fundamentals.
00:00
Today, which we shall talk about threat modeling.
00:00
In this module we shall cover
00:00
the core concepts of threat modeling,
00:00
some of the common threat models used,
00:00
the tools used in threat modeling,
00:00
and how to document your threat models.
00:00
What is threat modeling?
00:00
Well, threat modeling is an approach for
00:00
analyzing the security of an application or system.
00:00
It is a structured approach that enables you to identify,
00:00
quantify, and address the security risks
00:00
associated with an application or system.
00:00
Now, do remember threats are not vulnerabilities,
00:00
threats can exist even if there are no vulnerabilities.
00:00
The steps of threat modeling includes
00:00
diagramming, identifying the threats,
00:00
putting controls to mitigate the threats,
00:00
validate your controls,
00:00
and bake it back in to your drawings.
00:00
Now, threats can be
00:00
viewed from many different perspective.
00:00
Some of the more common perspective
00:00
include the functional view,
00:00
process view, the deployment or operational view,
00:00
and data flow views.
00:00
Some of the less common and more advanced perspective
00:00
includes the social view and the environmental view.
00:00
We shall cover some of these
00:00
as we go through this lecture.
00:00
I shall begin with one of
00:00
the most common perspective which
00:00
is the abuse or misuse case.
00:00
Now, most requirements of
00:00
a system are presented in a use case.
00:00
This is something very familiar to
00:00
most system designers or
00:00
solutions architect or business analysts.
00:00
In an Agile environment,
00:00
these might be user stories.
00:00
These use cases or
00:00
user stories show the expected functions of a system.
00:00
They are meant to show
00:00
the developers what they expect the systems to do,
00:00
but a security architect needs to consider
00:00
how these functions could be abused or misused.
00:00
In many cases,
00:00
most of the users would not think about this,
00:00
and it is the job of
00:00
the security architect to help put together how
00:00
a system could be manipulated or
00:00
abused through the functional expect.
00:00
To capture the abused or misused case,
00:00
instead of creating more models,
00:00
we will extend the standard use case or
00:00
storyboard to show the threats
00:00
and the mitigation measures.
00:00
I will now go through
00:00
a simple example to illustrate how this can be done.
00:00
The example I will use comes from
00:00
Ian Alexander's paper on misuse cases,
00:00
which is in the IEEE Software magazine from 2003.
00:00
Now, in this example,
00:00
we have the use case of a car.
00:00
The actor will be the driver and
00:00
the use case would be to drive the car.
00:00
A simple use case would be driver needs to drive the car.
00:00
In this case,
00:00
the security architect would come in and think
00:00
about what would prevent the driver
00:00
from driving the car or how can this be abuse.
00:00
A new actor will be introduced which is the car thief,
00:00
and a misuse case would be to steal the car.
00:00
Now, the convention use would be
00:00
to inverse the color of the use case,
00:00
so with the use case
00:00
being black text in the white circle,
00:00
we could use white text in
00:00
black circle to signify the misuse case.
00:00
With the misuse case identified,
00:00
the solution designer will now think of
00:00
a way to mitigate the misuse case.
00:00
In this case, a new use case function
00:00
of lock the car would be included,
00:00
which would mitigate the misuse case or steal the car.
00:00
With the new use case of lock the car,
00:00
the security architect will now think
00:00
about what else could he do to misuse it?
00:00
In this case, he can add another misuse case of,
00:00
well, if the car is locked,
00:00
we can short the ignition which would again
00:00
try to unlock the car which would
00:00
allow the car thieves to steal the car,
00:00
and this now goes back to the solutions architect.
00:00
With the new misuse case of short the ignition,
00:00
the solution designer or architect would now have to
00:00
increase the functional requirements
00:00
to include lock the transmission,
00:00
which would mitigate short the ignition,
00:00
which would try to lock the car and so on.
00:00
This as you can see,
00:00
is an iterative process
00:00
between the blue team and the red team to come up with
00:00
different scenarios
00:00
and different protection they would have to
00:00
put in for completeness of security of a system.
00:00
Now, this is a simple example of a human actor and
00:00
a deliberate action and as you can see it
00:00
forces the designer to add more use cases.
00:00
Now, we shall look at another example
00:00
of misuse case in a different setting.
00:00
Now, in this example,
00:00
we'll talk a little bit about
00:00
an environmental actor and an uncontrolled action.
00:00
In this case, we have
00:00
the driver needing to control the car,
00:00
which would be important if you're driving the car.
00:00
But controlling the car can be threatened by the weather,
00:00
which could make the car skid.
00:00
In this case, the threat is
00:00
from an environmental factor and it
00:00
is an uncontrolled event and
00:00
not a deliberate action to threaten the controls.
00:00
With this misuse case identified,
00:00
the system designer now think
00:00
about how to mitigate this,
00:00
and the solution would be to have
00:00
traction control and control the breaking with ABS.
00:00
Now, these are exceptions that
00:00
means we use a system to control
00:00
the car which takes away the human
00:00
from controlling the car because
00:00
their reaction may not be fast enough.
00:00
This is an example of a misuse case resulting in
00:00
some function taking away from
00:00
the original use case and
00:00
putting it into another subsystem.
00:00
As you can see, misuse case does not
00:00
always result in adding controls,
00:00
but it could also result in taking
00:00
away or moving controls to other systems.
00:00
Now, to get started,
00:00
you can consider using the tool called SeaMonster,
00:00
which can be found
00:00
in the link shown below,
00:00
sourceforge.net/projects/seamonster.
00:00
This project was last updated in 2016,
00:00
so it will not be able to run on the latest macOS,
00:00
but you can still run it through a VM.
00:00
This is a good diagramming tool that has
00:00
all the standard conventions
00:00
of a misuse case and it's free,
00:00
so it's a good way to get started
00:00
trying to build some misuse case on your own systems.
00:00
The best way to remember what
00:00
>> we've learned is to try it.
00:00
>> I do encourage you to download
00:00
the software and give it a try.
00:00
What did we learn in this lesson?
00:00
Well, we've learned what is a threat model,
00:00
how to create a misuse case diagram,
00:00
and the tools that was available for
00:00
you to start developing these models.
00:00
Please go ahead and give this a try.
00:00
In the next video,
00:00
we will cover more aspects of threat modeling,
00:00
where I would cover application threat models,
00:00
operation threat models,
00:00
and data flow threat models.
00:00
If you have time, please watch the next video.
Up Next
Similar Content
