Dear viewer, these subtitles were generated by a machine via the service YouTube and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/3259 Thanks!
the next talk getting started with Fred
modeling is by AR Patmos AR travels in
the field of information security of
crossed areas ranging from usable
security to Sid train analysis he has
also taught the various branches that
make up security engineering currently
AR's main interest is how the how the
application of risk management of fr can
lead into design development and
deployment of more secure
systems welcome to the introductory
training on threat modeling for
development
teams the goal of this training is to
teach you how to design more secure
products and the idea is that you have a
little voice in your head telling you uh
what could possibly go wrong as well as
a concrete methodolog olical approach to
walk through such issues as well as how
to address
problems now before we go into the
content of this training I'd strongly
recommend that you grab a pen and some
paper as taking notes on paper really
helps in knowledge retention and also
because we'll be working through various
practical
exercises now what we're going to look
at is first some underlying fundamental
principles behind throut modeling go
into some of the Practical
aspects uh look at various worked
examples have you do some exercises and
we'll close with some
recommended uh but optional homework
exercises let's start by looking at some
of the fundamental principles behind
thrat
modeling now when talking about thrat
model in and specifically the concept of
threats many people think of adversaries
or attackers or people that might want
to harm us and while this is a valid
perspective when talking about a threat
modeling we are really talking about
systems we focus on systems and the
question of what could possibly go wrong
with those
systems now this is in line with
the threat modeling Manifesto which asks
us to analyze representations of systems
to highlight concerns about security and
privacy
characteristics before we go into this
in more detail let's first look back at
some history even though this history is
fuzzy it can teach us many
things let's have a look at the concept
of information security which is what
cyber security used to be
called now this term information what do
we mean by
this when talking about information we
talk about data data and data
specifically data addressed data in
motion and data in
use or in other words the storage
transmission and Pro processing of
data
now one way of representing data is
through so-called data flow diagrams and
this is one of the earliest if not the
earliest data flow diagram from
1975 and it represents a simple computer
program the arrows represent data
flowing from one computation to another
computation and the circles represent
processing of
data this is a data F diagram from 3
years later in
1978 which besides circles as data
processing arrows as data transfer also
has lines which represent data storage
as well as a rectangle to represent
external entities interacting with a
system
now these this syntax is still mostly
used today uh here we see a data flow
diagram that is more security centered
uh from
2014 which it still has these rectangles
for external entities arrows for data
flows and um the
two um parallel horizontal lines to
represent data being stored as well as
the rounded rectangles to represent data
processing now the only real
extension H since the 1970s for security
is this are these dotted lines or these
um these dotted rectangles and they
represent trust boundaries or trust
zones that indicate which part of a
system rely on one another or in other
words which part of the system uh trust
other
parts so knowing what we mean by
information let's have a look at the
concept of
security when talking about security we
really talk about the confidentiality
integrity and availability of
information and the use of
authentication authorization and
accountability controls to ensure Ure
that here confidentiality refers to
ensuring that only legitimate entities
can read certain information integrity
means that only authorized parties can
change information and availability
means that uh authorized entities can
have access to information or services
by authentication we mean ensuring that
someone is who they claim to be so
checking someone's identity
authorization refers to checking the
access the intended level of access of
someone and accountability refers to
ensuring that we have an audit Trail or
in other words that logging is in
place now as security is a negative
non-functional requirement or a negative
quality
attribute we cannot show that we have
achieved any of these six
goals instead what we do is looking for
uh any of these types of problem so the
inverse of the goals that we just saw so
we look for potential disclosure of
information to
attackers we look for information being
tampered or Services service being
denied uh possible impersonation by
attackers or attackers running code or
executing other actions or teers being
able to say it wasn't
me now one way of uh remembering these
six General types of threats or things
that can go wrong is the stride
pneumonic which was first described
Microsoft in the end at the end of the
'90s uh and it stands for spoofing
tampering repudiation information
disclosure denial of service and
elevation of privilege and so these are
really very um highlevel types or
categories of
threats there's uh several other
approaches to uh look at more detailed
tpes of things that can go wrong so on
the left we see an attack tree or a
threat tree where the root note
represents the general type of threats
so the the attacker's goal and the
branches and leaves they represent the
different attack steps or sub
threats now these threat trees can be
quite complex to construct and also they
can become quite
convoluted another way of uh looking at
this uh looking at the different attack
steps is through a So-Cal attack graph
which you see on the right where all the
different ways or paths through a system
so the different attack steps are
diagrammed and this can can really help
to ident identify the um kind of
shortest or easiest path for an attacker
to go from an entry point so from a
starting position to one of the assets
that an attacker is
after so now that we know what we mean
by information and what we mean by
security uh let's combine these two
things so when talking about information
security we really talk about creating a
representation of a system so in this
case a graphical model a graph graphic
diagram and thinking about different
things that can go wrong with that
system here we see uh one of the early
the earliest uh example of such a throut
model uh from the end of
the60s and what we see here is a uh time
sharing system and a lot of the uh
threats identified they are still
relevant
today now let's have a look at some of
the uh some related
Concepts so when talking about a uh
system it's important to realize that
this system is defined on the Bas is of
the system boundary that we deem
relevant for a certain
analysis and a system is always uh
embedded within a certain context within
an
environment with its Associated
environmental
assumptions uh also this system has a so
on the system boundary there is certain
interfaces or entry points to that
system which connect system to the rest
of the
environment uh additionally there is
certain assets or things of value
contained within the
system so let's look at an example here
we see an office environment where on
the left we see various entry points
such as Windows Doors uh even stairs to
a parking garage and things such as um
Plumbing for example
now on the right what we see is the
relevant assets or things of value such
as soft drings or even a fax
machine now in this example there we
have only specified the
external uh interfaces and we have
identified what we want to protect but
there's still many different options as
to how this system is archit
detected so when looking at uh threat
modeling and we looking at uh risk
assessment what we're interested in is
looking at such different architecture
different ways of structuring a system
and identifying which architectures lead
to the lowest residual risk at the
lowest
cost there's different ways of doing
this but the the general approach is to
First specify a certain system
architecture uh to go through this
architecture identifying various uh
threats and possible
attacks uh and then on the basis of uh
component risks looking at the um and
and specific vulnerabilities to really
prioritize these and to use that to um
short list and identify specific
measures and if this leads to a new
system architecture to then go through
this process again uh until the residual
risk is acceptably
low
now
the
original um grandfathers of threat
modeling at Microsoft uh what they once
said is that if they could only do one
thing they would do threat modeling
every single day of the
week so uh take a take half a minute to
think about why Howard and lipner might
have said this and also think about the
position of threat modeling within the
development life cycle of a
system
so the main reason is related to cost
and specifically the cost to fix
problems at specific points within the
development life cycle so although a lot
of these uh figures get quoted without
uh reference this is a um one of the
original references one of the original
um some original data
around how much it costs to fix problems
at requirements design uh coding
development testing or operations
time and this is not a uh linear but a
logi logarithmic skill so fixing
problems once a system is already out in
the fields is orders of magnitude more
expensive than fixing issues at design
time so and as threat modeling allows us
to analyze potential um security issues
in an
architecture problems can already be
identified during the design and not so
during the design phase so before even a
single line of code may be
written so we can position a threp
modeling within the broader development
life cycle after we have a an initial
design uh we can then uh review the
architecture through throughout modeling
and that can then uh lead to for example
redesigns but it can also lead to um a
specific uh risk
based um implementation level analysis
or code review it can also lead to uh
identifying where we want to focus uh
penetration testing activities and um so
both code review and pentesting can then
feed back into our threat Ming
activities for things that we've
overlooked um as well as ideally uh
limited
redesign so we looked at what threat
modeling is uh um and also why threat
modeling is useful so let's now look at
some of the Practical aspects of threat
modeling and specific uh ways of doing
threat
modeling now one big problem when threat
modeling is that there are many many
many different
approaches so here for example we see a
GitHub repo with around 20 plus
different
methodologies now these can generally be
structured from
very um kind of rigid uh checklist based
approaches to completely
unstructured um kind of whiteboarding
sessions now what we've the approach
that we've chosen is to take a a semi
structured
approach um so really uh not not going
for a just checklists and also not going
for a complete uh free form
approach now in threat modeling it makes
sense to look at uh existing ways of
doing things and to not reinvent the
wheel so let's have a look at a
framework for structuring existing
approaches and specifically we'll do
this by looking at kind of six General
uh aspects that play a role in threat
modeling and we'll uh walk through these
one by one uh these aspects being the
architecture of the system uh the
important
elements uh specific ways an attacker
can access a system things that can go
wrong
um how like broader scenarios as well as
things that we can do about
those now when talking about the
architecture of a system uh there is
many ways of um representing that
architecture but generally we focus on
the data flow within the system using
data flow diagrams and also look at the
relevant trust zones uh within the
system so here so we've looked at some
examples of of data flow diagrams and
and Trust zones so this is really um one
of the main approaches and also the
recommended ways way of way of doing
things
then if we have a
view of the structure of the system we
can then think of where within the
system our crown jewels or key assets
are located and so these are really what
the attacker targets and what we value
and there's different ways of
identifying these but it makes sense to
kind of Link these key assets to what is
most important to the business and to to
not identify every element as important
because if everything's important then
uh nothing
is so having identified uh a crown
jewels uh another
important aspect is thinking about ways
in which an attacker can interact with
the
system so these are external
interfaces and these are strongly
related to the system boundary that
we've identified and also the
assumptions that we make about the
system uh and these entry points they
can also be thought of as where within
our system we position the
attacker so knowing the architecture key
assets and entry points uh we can think
of the threat events or um hypothetical
exploits or potential vulnerability
and here this is really where uh an
approach like stride comes in or more uh
structured methods such as uh attack
libraries now in order to know what
threats we really want to address in
order to prioritize these um one way is
to think about attack paths that go from
entry points to key assets because if
there is a path from an entry point to
key assets made up of one or more
threats um then we really want to focus
on the attacks or attack scenarios that
are the easiest for an attacker to
execute so once we
know what things we want to focus on
first so what potential attacks we want
to mitigate first we can start thinking
about both reducing so counter measures
to reduce the likelihood of something
bad happening as well as ways of
mitigating the impacts and especially
this second thing so impact mitigation
whether that's through early detection
uh or things like backups uh this is
often forgotten and many Mees instead
focus on likelihood
reduction now these uh six uh aspects
they are not linear and they can really
be uh walked through in kind of any
order and there are also like you also
there's no this is not like a one-time
thing but something to uh go through
multiple
times additionally
underlying these six aspects there's
various assumptions that tie them
together um such as around the
environment around relevant um attacker
capabilities uh
Etc and ways of feeding these
assumptions as well as the the other
aspects um it's relevant to look at uh
the business model or threat
intelligence around attackers the
preferred System Scope for analysis and
things like the use cases supported by
the
system um additionally both these
assumptions identified throughout the a
a threat
modeling um Workshop or through mon
engagement these are useful output for
example for um making choices during
quality Gates uh for con for
constructing test plans uh identifying
which areas of a system require uh the
greatest effort with respect to working
off security debts
and so output from a threat modeling uh
Workshop can also be useful for um
knowing or for for choosing where to
place uh sensors for monitoring
activities so summarizing this uh there
are six relevant facets to focus on so a
sketch of the architecture
identification of CR Jewels uh looking
at all the relevant interfaces thinking
of stuff that can go wrong and broader
scenarios uh built up of specific attack
steps and then picking counter measures
to both reduce likelihood and impact of
attacks and tying all of this together
are various critical assumptions around
attackers business processes users
system the system boundary and the
environment and all of this is both fed
by as well as feeds into various other
activities now this is just one
framework and really this can be
modified in many different ways U so
really think about your own context uh
think about what is useful within that
context and uh what steps in in in what
um so what what kind of process makes
sense for you and really evolve it on
the basis of Real World Experience
because what many many people forget
is that threat modeling and threat
modeling methods that they are tools and
these tools they have a specific purpose
which is helping you to find problems
and
prioritizing uh what you do about those
problems so having looked at the theory
behind threat modeling and having looked
at a general framework for threat
modeling let's have a look at some work
examples so here we see a simple uh it
system uh with a browser a web server
and a
backend so in order to think about what
could possibly go wrong we can apply the
stride
moronic we can think of for example the
HTTP data flow how both tampering and
information disclosure is
possible how the for example in the
connection to the database server how we
have sorry in the connection to the web
server how we can have potential
spoofing from the
browser or look at uh say payroll data
uh both temporary and information
disclosure is
possible so on this basis we can then
think of potential countermeasures such
as for tempering an information
disclosure on the HTTP data flow we can
apply um ssl/tls or for the lp flow use
uh IPC to ensure both uh confidentiality
and
integrity for the the audit data and the
web pages uh things like exess control
lists might be useful counter measures
Etc so this is a very simple data flow
diagram we can also extend this uh both
uh looking at the uh both kind
horizontally and
vertically uh by for the uh vertical
perspective looking at different layers
so we can sketch a context
diagram that identifies the external
entities interacting with our
system uh then we can identify a level
zero diagram that provides some more
detail and then really looking into
which part of the system we think are uh
is the the parts of the system that we
think are most interesting that POS the
highest risk and to then kind of uh look
at this as a matosa doll really uh
diving into additional detail and uh
really sketching the data flows
happening at different
levels so for example here we have a s a
simple web
application uh where the external
entities are shown so we have a customer
Anonymous user and the
administrator now our level zero system
shows this in some more detail um both
the web app itself as well as various
other uh components that do further
processing such as the ordering
component
4.7 in order to know what's going on
there we can zoom in and look at the
relevant data
flows so here we have a um lower level
data flow diagram that really zooms into
to what's happening within the ordering
component and we can then use such a
lower level data flow diagram to explore
specific uh spoofing tempering
repudiation information disclosure now
service and elevation of privilege
threats to each uh data flow and each uh
uh each process and each data store as
well as the different uh external
entities now of course at a certain
point we need to kind of stop stop
digging uh so at some point we start
making assumptions and we start treating
system elements as black boxes so in
this case the uh asp.net and The NET
Framework we um we treat this as black
boxes and we make certain security
assumptions about them as well as the uh
web server TCP IP stack Network driver
Etc so we really have a specific scope
for our threat model as well as certain
security
assumptions now we can also uh kind of
scale out or look uh look at a kind of
broader take a broader perspective for a
kind of horizontal level
looking at different attack
paths so here again we have a simple
data flow diagram of a web application
um application server SQL database
Etc and so the next step is identifying
trust boundaries where we have the
internet a demilitarized zone and the
corporate Network which we can then use
to identify
threats so um things like spoofing the
web application uh or jering with a web
application um things such as elevation
of
privilege U Etc now once we have applied
stride to all these elements we can then
think of specific attack paths through
the system so here we have an example of
some of these attack paths and and
whereas some of these are quite short
others are much longer and we can use
this depending of course on the expected
um work factor or efforts on the part of
the attacker we can use we can then use
this to prioritize our coun measure
selection now let's look at a
integrated
example here we're looking at at um
smart Mobility or um kind of connected
vehicles um and what we see here is
really the the broad system so looking
at both um backend services such as
Satellite Communication as well as
different entities both uh cars
buses um but also things like the mobile
mobile um Communications so
telecommunications uh
Etc um Fleet Management Systems uh Wi-Fi
connections information around traffic
and uh specific
obstructions now suppose that having
like looking at looking at this this
broader system that we then want to zoom
in on a connected vehicle and
specifically one of these cars
now it makes sense to start with getting
a perspective of the attack surface so
the different attack vectors into this
system into this connected vehicle and
many modern cars they have quite a large
attack surface so uh ranging from very
specific things such as the tire
pressure monitor uh system um the uh
incar entertainment system which is
where for example connecting phone CDs
Etc uh but also uh maybe Wi-Fi or
Bluetooth or even a connection to the
back end over uh
3G 4G 5G
Etc now knowing
the uh external interfaces let's let's
also have let's then have a look at the
architecture of this of this car and
generally we see a uh Gateway a shared
uh can bus um which the different parts
of this car um use to communicate with
one
another so it really gives an idea of
the uh internal structure of the system
that we're looking at and we can use
this to get a view of kind of the
different parts and what can go wrong
with those parts and you then kind of
map out different attack paths through
the system so let's have a look at a
specific uh attack
path what we see here is the Jeep
Cherokee from
2014 and one attack path that was
possible and also
exploitable was a connection um over so
this this car would be connected to the
internet over the phone network and it
would have an actual public IP address
so an attacker could connect to this car
um and this car was running
a uh an entertainment system so um a
kind heads up display where I mean this
was running Linux an old version of
Linux which had exploitable
vulnerability so an attacker would be
able to take over uh this entertainment
console uh it would be able
to uh to then kind of using this
foothold then reprogram certain chips
which at a certain which after certain
certain attack St steps would lead to
the attacker being able to inject
messages into the canabas
so having access to the cust would then
allow things like uh steering left or
right uh
acceleration uh breaking Etc and of
course um yeah in essence complete
control over the
vehicle now uh further uh information
and and further detail on uh this worked
example uh have a look at the um the car
hackers handbook and specifically the uh
first chapter uh it's it's it's uh
publicly available and uh so so have a
look at the these different data for
diagrams and
how um stride and and other uh kind of
broad classes of attacks how they are
possible at these different elements and
uh yeah yeah so it's it's it's really
interesting to have a look at at these
uh at what at the the different things
that can go
wrong uh and of course these are
not um so just just without looking at
the structure of the system uh it can be
pretty hard
to uh just think of threats out of thin
erir so this is really a useful approach
for uh for thinking of what could
possibly go
wrong now that we've looked at the
theory and the practice behind trap
modeling and now that we've seen some
concrete
applications let's go through several
exercises so grab a pen grab some
paper now what we see here is a highle
diagram of a of of tele medicine so of
on the right we see a regional hospital
on the left we see a private Health
practice uh there's it with a general
practitioner uh in the regional hospital
we have a
cardiologist um we also have specific
Health Data being stored a dedicated
Network for communication as well as an
encrypted Channel over the
Internet uh we have uh firewalls
and there is a connection to the
patient now the question to you is take
half a minute to think of what details
you are missing in this data flow
diagram so really uh take some paper and
write these
down
so this diagram is missing a a lot of
detail um so things AR would probably be
interested in is uh or things like what
data is actually going over the network
uh what type of
protocols um would also be interested in
how how is a GP and a cardiologist how
are they actually uh like kind know what
what commands what data are they
entering into the system um how is
authentication and access control and
and auditing
arranged uh even so also for the data
crossing the internet how is this even
encrypted and how are these uh firewalls
configured uh what data is being
recorded in the
database and looking at the patient what
is there is there only data coming from
the patient so is data only being read
or is there also a flow towards the
patient and whether that's data or
energy this makes a lot of difference uh
with respect to potential risks um also
what kind of medical device is connected
to the to the patient uh what's running
on there as well as on these two
computers uh what software uh what
operating
system um so really there's there's a
lot of a lot of details missing here
that would be important for us to be
able to uh throughout model the system
properly now let's have a look at at
another example um here we see a web
browser connecting to a web server with
uh some other software running on a
virtualized Linux on a physical
host as well as an admin connecting to
this uh uh virtualized Linux instance
for
administration so here the same question
take half a minute to think about what
details you think are are missing
here
so here again there is a lot of
additional detail that would be very
useful when throughout
modeling um so here thinking about kind
of where is this host even stored uh
even though we're looking at a data flow
diagram um these are things that are
relevant to consider uh but specifically
focusing on the data um is so what kind
of operating system is um is this
virtualized Linux instance uh running on
there uh What uh kind of what what
hypervisor are we dealing with uh are
there multiple instances running in
parallel um and looking at kind of the
the trust zones or trust boundaries um
what can make can we make that more fine
grained uh so even within of a
virtualized instance uh what parts of
this system trust one another and what
parts don't uh looking at the kind of
external entities and the the
connections to the system um is it the
case that we're only talking HTTP or is
there uh https being used uh what kind
of users are using this system uh how is
this administrator authenticating what
kind of command
are they sending uh what part of the
system are they connecting to and what
uh should they be able to control um
looking at the web server what kind of
web server is this and uh what kind of
um use case are we talking about um so
there's there's really a lot of
unanswered questions here uh that should
be detailed like that should be added to
the diagram for us to be able to uh kind
of engage in in proper threat
modeling so here we have uh two data for
diagrams on the left and on the right uh
so take a couple of seconds for some
First
Impressions so what we see here on the
left uh this deler diagram is most
likely to be too simple even though it's
it's good to um kind of draw only those
elements or those facets of a system
that are really Salient to security
analysis uh this is like the data
diagram on the left probably has two
little detail now on the right um here
the even though less is not necessarily
more uh more is also not necessarily
more right this is uh quite a convoluted
diagram and it can make sense to split
these up into uh into multiple uh
diagrams or to uh to really have more of
an an overview diagram first and to then
dive into specific details in a lower
level
diagram
let's look at another exercise uh what
we see here is a uh simple DFD of an
Integrity uh monitoring solution so
something like trip wire that monitors
the Integrity of files and registry on a
system so here we have some host
software that uh monitors the registry
and the file system and that is uh
controlled by an administ ministrative
console where an administrator can
provide instructions and also view the
Integrity of the different systems under
their
control so the question to you is apply
so take half a minute to apply stride to
identify at least three different kinds
of
threats
so threats are possible uh many
different uh points within the system um
so thinking about tampering uh this is
possible at any of the data stores so uh
we want to protect against adversaries
changing data within the registry file
system configuration data and around the
database that track that tracks the
Integrity of files
um information disclosure is possible at
any of the data flows and also at any of
the uh data
Stores um on looking at the processes
this is so at a process we see that any
um any of these and any of the standard
threat classes is possible so um one so
a process can spoof another process uh
there's potential tampering of the code
running um there is a repudiation of a
uh so a process uh so an attacker kind
of being able to claim that certain
actions did not take place uh there's
potential for information disclosure as
data is being processed as well as for
uh overloading processes to cause a
denal of service attack um and even
elevation of privilege for example
through a buffer
overflow
now uh other potential for uh
repudiation we see at
the um external entities so an attacker
being able to claim that they're someone
else or that they didn't take a certain
action um and attack being a to spoof um
a legitimate
administrator now the one thing that
stands out is that at the data flows we
see um not just tempering information
disclosure in the Nile of service but we
also see a Potential repudiation
Threat so the reason for this is that
for an attacker to perform an attack on
a system they would not only have to
change the registry and file system but
they would also have to ensure that this
data
doesn't show up in the Integrity files
database or that it would have to uh be
able to change it
afterwards here we have a an exercise on
kind of
scoping um so we see the headquarters of
the
Acme um
organization and we also see their
Network Services building we see a
perimeter a guard a front gate um as
well as their it
infrastructure so here take a couple of
seconds to think about what you would
focus
on so you can focus on many things but
from a data diagram perspective and a
threat Ming perspective uh we probably
initially want to focus on this part so
the it
infrastructure and the data flowing
through that
infrastructure uh so we we really need
to kind of remember that this is only
part of the system uh and that focusing
on data flow is also just uh one
aspect but um it does tend to be the
thing to focus on
first so suppose that we have a an
architecture um or a a network
infrastructure um and suppose that that
this is a diagram of that um Network
infrastructure take um half a minute to
think about different problems within um
this network as well as potential things
that you could do to address those
problems
okay
so one of the major issues we see here
is that the web servers which we can
assume are um can be accessed from the
internet that they are on the same
subnet as the office servers and the
desktops so I we really want to apply
some Network segmentation between those
as well as between the different web
servers especially if you if they don't
need to talk to one
another additionally we see both
administrators and developers being on
the same subnet and those desktops being
able to talk to each other so that's
also something to address as well as
their connection to the office
servers now on the uh router side we see
that there is no prodoc filtering
happening whatsoever
and it it probably makes sense to
rethink that to think about um and to
kind of reduce the U attack service and
to reduce the possibility for attackers
to um uh to contact different uh parts
of our our Network to think of what
protocols are really
necessary
here we see a uh real world case study
um of an attack on the bank of
Bangladesh so again here the same
question um take one half a minute to
think of what issues you see here as
well as ways to address
them
so the major issue we we see here and
the way to address that is that that
there's a that that there was a direct
connection between the end user computer
and the internet now we're talking about
the uh Swift system for um interbank
payments and ideally we don't want that
connected directly to the Internet so we
could give the uh end user a dedicated
terminal for serving the internet um and
to then have the uh the kind of backend
systems and the the end user computer uh
sry the computer that the end user uses
to uh kind of give um payment commands
to have that be air gapped from the
internet at least to not have a direct
connection to the internet but only to
the uh Swift
network uh additionally uh within the uh
customer Network it can make sense to uh
have some additional segmentation
through for example firewalling as well
as between the internet in this this
other um this
additional uh computer for the
enduser U of course there's also various
uh potential threats around information
disclosure and uh ways of addressing
those through the use of cryptography
really the main focus and the main thing
to address here is this direct
connection to the internet and the use
of segmentation to address
that we've looked at different ways in
which threat modeling can be applies to
analyzing a system so the structure of a
system but threat modeling can also be
analyzed to look at the uh the life
cycle or the different stages used for
um for building a piece of software or
Hardware so what we see here is are the
the different steps for uh building a
piece of software um from the developer
checking things into uh Source control a
build
environment um the relying on certain
dependencies uh that leading to packages
which are distributed to a
consumer now take a couple of seconds to
think about what are some security goals
for this
system so the primary goals are ensuring
the Integrity of source code
as well as ensuring the Integrity of the
build
process now take a couple of seconds to
think about where things can go wrong
within this uh
pipeline things can really can really go
wrong um pretty much anywhere um
and the so the next question to you is
take around half a minute to kind of to
to describe a couple of these threats in
more
detail
so what could go wrong is that a an
attacker might be able to um submit
unauthorized changes is um it could even
be that a developer is actually an uh an
inside threat uh it could be that an
attacker is able to compromise the
repository hosting the source code uh
there might be a problem where there is
a um that the source code is modified as
it's being built uh the build process
itself so the build server could be
compromised by an attacker uh it could
be that an attacker is able to upload
modified packages or is able to replace
certain
dependencies uh it could also be that an
attacker can uh is able to get uh access
to the package repository where they're
able to replace certain
packages uh and it could also be that an
attacker
is able to send um or to convince a
consumer to use different packages that
have been back
doored so let's have a look at a
more um complex exercise so we've looked
at the different steps that are relevant
when threat modeling and for this
exercise you're encourage to think of uh
really any um iot so internet of things
related
application and to create a threat model
for this
application um so and you can really
think of any any area whether this is
the electricity grid um some aspect of a
smart home um or related more more to
the medical sector uh or even
agriculture or um uh smart industry uh
you can you can also look at um smart
Mobility or various really any um any
device such as even maybe an an ATM U so
really think of think of any iot related
application and um
carry out a the different steps of
threat modeling on this
application
now if you don't have a specific
application in mind uh you can use uh
this case study to practice uh this is a
smart washing
machine which um has specific sensors
and
actuators uh it connects to a back end
over uh Wi-Fi there's various cloud
services and also um there is also
access the kind of services responsible
for Access Control uh to those cloud
services there is an a smartphone app
with um specific programs uh either
delivered by the manufacturer or
possibly third
parties so um whether it's this case
study or something that you have um
defined yourself um some constraints are
that your system um is involves an
embedded system U that is pretty simple
for example in ESP a266 or an ESB 32 or
any other simple uh arm chip um
additionally there should be some
machine learning and cloud services
involved um so well here here we see Ai
and Cloud inside so the idea is not to
have that inside the um the uh small
embedded system but to have that be part
of the back end now as to the network
architecture uh here we have a reference
architecture where we have a local area
network a home router and the internet
um very is cloud services involving uh
Telemetry and also uh access control um
Services uh potentially also other
services for streaming or even news uh
on this local network um there might be
things like smart TVs smart fridges uh
connected over Wi-Fi uh there might be
various a gateway to connect to uh
things like smart lights um smart locks
Etc so assume that this smart washing
machine or any other um case study that
you're you're investigating assume that
that makes use of a similar Network
architecture so a short reminder as to
the different aspects to focus on for
threat modeling uh think through so
create a data flow diagram of the system
architecture of the data at rest uh in
motion and in use uh think about the
different trust zones the different
trust
boundaries uh identify the crown jewels
within the system as well as the
assumptions that you make around which
interfaces an attacker has access to and
use uh stride or uh related approaches
to think through all the different
things that can go wrong
um and think of uh whether they are
single threats or combination of threats
um that can lead to specific attack
scenarios and think of which ones are
easiest for an attacker to execute and
based on that uh also look at various
counter measures that are possible both
to reduce the likelihood as well as to
reduce the potential impacts um and
throughout all of this think about uh
the assumption that you make and also
record those around attackers relevant
processes users um the environment
Etc um some tips around this uh think
about which parts of a system so kind of
make a general um overview of the system
and ensure that that overview kind of
the the level LEL of of detail the so
the resolution that that allows you to
make certain risk-based decisions around
what you want to focus on so here we see
a uh a fire map a fire Insurance map um
from the um 19th or beginning 20th
century um which was used to get an idea
of the material that different houses
were made from so that insurance
premiums to be calculated now the same
idea can also be applied to this
exercise so think around think about the
different elements that your system is
made of and think about which ones
require most attention from a risk-based
perspective um sketch the data flow the
relevant entry
points um relevant trust boundaries as
well as the um assets or protected
resources that that you care
about as to uh threat modeling of course
uh you can use stride uh but also to get
some more uh concrete ideas there's
there's different approaches um one
useful resource or one useful approach
are so-called flaw hypothesis generators
and iidea from the uh
1970s uh and such flaw hypothesis
generators are for example Le uh looking
at things that have gone wrong in the
past so General uh system
weaknesses um specific attack strategies
that attackers have used um but also
looking at kind of the interfaces that
are exposed uh thinking about so in this
case you might not but depending on the
the the case that you look at if there
is a user manual or uh developer
documentation if there are specific
warnings on things not to do uh that can
be inspiration for um ideas on things
that could possibly go wrong right so
there's so you can use um use this list
or other lists to uh get some idea of
things that could possibly go
wrong um and again a some some other
reminders uh don't just think about um
things to
prevent stuff from going wrong but also
look at when looking at countermeasures
think about reactive barriers think
about um ways
of finding problems early on um and ways
of responding to that to those um kind
of to compromises quickly and so so
really kind of combining these two
things also remember that threat model
is not a thing you do once so you can so
so go through these different steps
multiple times so they you you don't
just create a diagram once um but kind
of revisit the diagram uh once you have
identified which parts of the system are
most risky and then maybe zoom into
specific elements and really see this as
a
um an iterative
process um so take so look at this
exercise so so of course you can do this
on your own um you can also um do this
together with other people uh it's also
interesting to do it um so to have to
kind of compare the output of different
teams working on the same exercise so or
individuals or teams and to look at the
the diagrams they uh come up
with um and so so yeah so this is kind
of the
a a more in-depth exercise to really
practice your threat Ming skills uh if
you want to then think of how that fits
within a broader framework you can also
think of how you might then use that
threat model to
explore um the relation for example with
uh testing plans um around uh for
example uh code review and really how
this would be how this threat model
would drive or could drive many of the
system engineering decisions that are
made uh so have a look at kind of who or
you could think additionally think about
um who could contribute to this Sprat
model if you are missing certain details
then can just just assume that for for
this exercise but um also kind of keep a
list of who you might uh want to ask
things or ask um ask additional detail
with who you you might want to check
certain assumptions um and also how this
threat model would be useful for getting
idea of how secure the system actually
is um on Guiding uh penetration testing
planning as well as directing code
reviews so this exercise is really meant
as a way of kind of getting familiar and
walking through the
um the different parts the different
aspects of threat modeling and to really
integrate this into one uh
hole we've now arrived at the final part
of this training a collection of
recommended homework
exercises let's have a look at uh some
recommended readings and Associated
exercises we've seen the threat modeling
Manifesto before in the context of the
definition of system Centric threat
modeling it also provides various other
useful
insights for example the section on uh
patterns and anti patterns and you can
use this to reflect on your own
practice uh and even pick one or more
specific patterns that you can use as a
focus for uh further professional
development there's also this book from
2006 which provides a really interesting
snapshot of Microsoft's approach to
threat
modeling as a nice activity uh you can
reflect on the process described in this
book in chapter 9 and compare and
contrast this with the framework that we
discussed during the
training and and you can also think
about which parts of the process you
think are most relevant to your own
situation it can also be useful to look
at the metric that Microsoft
describes that they used for evaluating
their thr models and whether and how
they may or may not apply to your own
threat models
another interesting book is this one by
one of the authors of the original
1999 um white paper from Microsoft that
uh describes
stride this provides an interesting
reflection on Microsoft's threat Ming
process and also chapter two describes a
lot of practical tips and realistic
expectations around getting started
started and setting
priorities again take a look at how the
threat molding process describe in this
chapter how this compares to the
framework that we discussed during the
training and how it and how both of
these compare to the approach that your
own team
applies for useful background
information on common countermeasures uh
see this book by Van orot now when it
comes to thout modeling van orot uses a
slightly different and slightly
inconsistent terminology and he has some
Divergent views on the utility of models
of attackers and attack trees but even
so section
1.5.1 and section
1.5.3 they give a really good summary of
some of the key aspects that we've
discussed during the
training and it also discusses how
threat libraries or attack libraries can
serve as a useful uh Learning
Resource uh besides that see section 1.6
for a really interesting discussion on
the limitations of trat
modeling now as to uh exercises uh have
a look at the security design
principles that F orsal gives in section
1.7 or really any other list of security
design principles such as these
information security practice principles
from uh ja
metal and consider how uh such a list
can be used for directing attention
while threat modeling and how it could
guide um
a more General euristic evaluation of uh
a system security
architecture taking an even broader view
or broader perspective uh here we see
ISO
31,000 which is a really useful source
for understanding how threat modeling or
architectural risk assessment fits into
the broader framework of enterprise risk
management uh key features of this
framework are
the describes the cyclical nature of
risk
management uh how risk management aligns
with both business objectives and
business activities as well as the
importance of assigning risk
ownership now for your own situation uh
it's interesting to consider how
throughout model
relates on the one hand to scoping as
well as risk treatment decisions and so
have a look at um so look back at some
previous threat modeling sessions and
consider whether it was clear going into
this session what the major organization
risks were and
whether the selection of counter
measures as a result of this uh frat
balling session were whether those were
based on the business impact the
expected business impact of a tax and
whether the uh countermeasures were
weighed against other types of risk and
also think of whether someone actually
took ownership of the prioritization
tracking and also the validation of risk
treatments and finally also consider
whether any of your threat models have
ever been revised and if so what
actually triggered
this of
course understanding and reflection is
important but it is also vital to
actually get started with trap
modeling so really just gather a dous
team and include both people with a
technical as well as a business
background um and pick really pick any
kind of existing system or components or
a new product or feature that you're
working on then grab a whiteboard and
explore what could possibly go wrong and
what you could do about
it and remember that when doing this
remember that all models are wrong but
that some models are useful and threat
models are useful if they
drive changes within your system that
lead to more secure
products now that was it for this
training thank you for joining and don't
forget to have fun throughout
modeling welcome back I've got iron with
me here right
now uh so we
can take a look at some of the
questions so first of all
uh do you have any recommended reading
if I if I've just like seen seen your
training seen this talk and I want to
find out more where where do I start
looking yeah so as as discussed in the
in in the talk um there's of course the
the book by kelder and the um to and
jewes book by or
uh there's also some like more General
Security uh books that that are very
useful because thrum holding is really
it's just a kind of widely applicable
technique and so it's also good to have
more of like a more some some more
background knowledge um and there's like
the cyber security body of knowledge for
example uh Ross Anderson's book go has a
uh book as well on on kind of more the
distributed systems perspective uh so
there's there's there's really various
various resources um also on my uh geta
page especially the there's there's um
an overview of different thring examples
that are that are quite um extensive so
if you want some inspiration there
that's that's also I think useful
including a list of blog post SL papers
slash Talks by um inhouse th moders who
also share their experien I think this
also really useful to kind reflect on
see like if you're exploring either
introducing this in in your own uh
context or trying to kind of like yeah
revisit your your current approach um
would you recommend reading into the
relevant ISO standard or is that only
something you should do if you're
looking at threat modeling on
organizational organizational level yeah
I think that would be more at an
organization level um I think so so good
ly there aren't that many um kind of
like standards specific to um threat
molding least at an ISO level there is
one part of the uh IEC 62443 standards
uh which goes
into one of the standards which goes
into throut modeling more for practical
uh sorry for for embed
assistance um what do you think in terms
of of like copying frat modeling from
other people or other companies is that
something that you can do if you adapted
or should you always start from scratch
and try to figure out your model
yourself
so I think so so thrs are very kind of
context specific uh
but you can draw some inspiration from
existing uh existing threat models and
also from existing Ming approaches but
really like what works for you in the
end and of course for very uh like
people and organizations just starting
out integrating security into the
development process it might even make
sense not to course threat modeling
helps to get more of a design
perspective but it could also help to
have uh to kind of combine that with
some more uh kind of strict security
guidance so yeah it it really depends on
the context um is there any re research
that has been done into threat modeling
any like academic level
uh looking looking into threat
modeling uh yeah so there's there's been
some most of this research is is is of
the kind kind of like yet another threat
modeling uh method basically um and like
that hasn't actually been been evaluated
so there's been some work exploring how
thr is applied in in practice uh but
there's there's a lot of work still to
be done um and I think one highlight
from last year was a de that basically
took a group of students and had them
think aloud while they were applying uh
da for diagrams and Strikes to uh kind
still somewhat make Rel system but yeah
at least that that showed a lot of the
challenges that people have in having
practice so there's some work but but a
lot still to be done after after a
security incident of sorts should I
revise my threet modeling look into it
and see whether the threet that actually
CA that incident uh was
underestimated yes or whether it was
underestimated but especially if it was
if it wasn't in your threat model then
also not just revisiting the threat
model adding that to the threat model
but also
considering how could it have been that
it wasn't picked up right during the thr
modeling process so not just not just uh
revising the threat model but also
re-evaluating the process to see whether
you've missed anything else yeah yeah
and the same not just incident response
but also with with pen testing like if
your pentest uh breaks your threat model
so to say then you have a
problem um I think that that's it for
our time slot today thank you very much
for joining
us um yeah thanks for your talk yeah
thanks everyone for
joining