hi everyone and welcome to our
presentation for the absec village
at defcon 29 uh it's
both uh uh an honor and uh a very uh
nice thing for both of us to be able to
be here talking to you guys about this
uh we are matt and i am izar
something about us and why are we
talking about this stuff here
uh i'm a security principal security
engineer
at squarespace security thing for a long
time
mostly on the defense side on the
builder side
and i am currently focusing on modern
sdlcs
and how we get security into them and
how we get developers to actually
do security and i'm matt coles
i'm a security engineer over at at dell
technologies and i work on protecting
physical devices primarily and
ecosystems making them secure for the
products that we sell and the ways that
we build them
we have been collaborating since 2010
when we both
worked at what was at the time the uh
the broad security office had to tell
that sorry
at the time it was emc then it became
delvmc
we have uh recently co-authored an
o'reilly book
called threat modeling a practical guide
for development teams
or as we internally call it the ugly
fishbook
and we are proud members of the 15
experts that came together last year to
write the threat modeling manifesto
which actually we are going to be citing
throughout this presentation
now the standard disclaimer is in there
we are speaking for ourselves we are not
speaking for our
uh respective employers and
let's take it on the road so what do we
have for you today
we are going to talk mostly about the
modeling part
of threat modeling we in our experience
working with developers in doing threat
models we
have seen that many times they are not
exactly
very happy
to be asked to do diagrams in some cases
hey they have been
what can even be called referentary to
the uh
idea of sitting down and doing a
a model we are going to talk a bit about
the many ways that you can
model a system uh we are going to
discuss briefly the role of actually
diagramming creating diagrams
in system modeling and then we are going
to ask ourselves what can we do
differently
what can mitigate those small problems
that we have
with the developer community in uh doing
the uh the models for their threat
models
and then we're going to show what we
think is a very developer friendly
uh distributed way to actually create a
model
and take things a bit further
so the big question here is why is this
important
why do we even need to model our systems
developers know what they're writing
right they know what they're building
yeah sure they do so
basically a threat model is a function
of whatever representation of the system
we put together
and then the second part which is the
threat elicitation
now we as security experts we're very
good at second part we're very good at
the threat
dissertation we know how to figure out
what could possibly go wrong
where we and the developers many times
are a bit not so good is
on the system representation which
you could say is the set of all the
elements
in the system plus the way that they
interact with each other
plus the attributes that they have and
we're going to talk a bit
a bit more about what these attributes
are later in the
talk now
who is this person that can create
models uh
how can we create a representation that
is
more clear and more representative than
the sum of their parts
how can we codify the way that they talk
to each other in a way that somebody can
look at it and be able to infer security
value
from what's represented in there so
developers engineers they they many
times they see
very different angles from an architect
or from people from qa
or anybody else that works with that
system
so when you give developers the task the
engineers the the task to
uh to represent that that model many
times would come out of it is what we
call
eureka moments you have the the room and
everybody's discussing the model and the
big architect is saying hey
the way that we do this is part a talks
to part b and then they
both get whatever was uh was uh
processed in there and they dumped it
into part c and then you have to join
your developer there in the end of the
room
slowly raises their hand and says hey
you know what
yeah that's the way that it was designed
but unfortunately because of the
constraints of the framework that we use
because of the language because of the
deployment we have to slightly
change things and now you have this part
d between
b and c that actually translates things
and that's when people start noticing
that the system
actually as it exists is not exactly
what they had in their minds
now many times you have to get into that
um
explain lycom5 thing meaning
you know if you can't model your system
then let's be very honest
you you have bigger problems than threat
modeling if you can't
construct a representation of whatever
it is that you are building in your mind
and be able to translate it into a way
that you can explain to somebody else
which is basically creating a model
you have bigger problems and it's time
to step back from threat modeling
and reconsider the whole enterprise
and yeah to tell you the truth uh it's
good
documentation it's useful later on not
only for threat modeling but for other
things as well
so it's an after effect but actually it
proves to be a very
uh uh valuable one
now why is it that developers
come and say that they don't like to try
to model their systems
sometimes they say it sometimes they
actually do but mostly they just say it
so first of all many times they they
don't even know that they already know
how to do it
i mean how many times completely
detached from threat modeling have you
seen a team
get together in a room and start
discussing what is it that they're
building and somebody immediately jumps
up
and starts drawing circles and arrows on
the whiteboard
and then somebody gets another caller
and starts erasing the first arrows and
putting arrows to different
blobs and whatnot they don't know that
they already know how to do it but when
you put it in the framework of hey this
is part of start modeling
we'll see later things can get a bit
scary people become a bit reluctant of
what's going to happen
again it is considered the documentation
of effort and sometimes developers say
you know what
it was hard to write it should be hard
to read so we're not going to
document it more than it should
then we have the phenomenon of passing
the ball passing the ball hallway you
know what the guy that actually knows
the system enough to create a model of
it
it just happens to not be around this
week so yeah
no or hey you're the security guy can't
you do it yourself
they forget that as security people we
are probably never going to understand
the system as well as the people who
actually wrote it
they also seem to forget is our sorry
interrupt that
you know this is not something that a
security person
should be doing on in a vacuum right
this is
a team sport by design i'll use that
phrase
uh and and you know so passing the ball
here they want to
keep themselves out of loop because it's
hard or it's work
and not necessarily and and try to get
others to do their work for them but
it's more than that right so you know
keep in mind that
this is a collaborative effort and
should be a collaborative effort
yeah and then we have you know that that
part that is really really really not
nice to reach but unfortunately
sometimes happens which is winding it
away
oh you're going to drop our velocity
because you're stopping us from actually
writing lines of code
to draw a model oh it's not going to
work it's not going to add anything to
the effort
so there is that little myopia is not
not being able to see that
small effort in the beginning actually
is going to to bear fruit later on
and bring advantages to the
understanding of the whole system
people actually get out of a modeling
exercise i'm not even
reaching the threat part of it of a
modeling exercise
the team itself as matt said it's a team
sport
take them out with a better
understanding of what is it that they
are building
so however it is that at the end of the
day we express that
that model people will get a benefit
from understanding better what is it
that they are doing together
at the end of the day one of the big
things
that stops people from that modeling
effort is the fact that
there isn't an agreed way of doing that
that model there isn't an agreed
language you don't go
forward and you say hey guys we're going
to use blah blah blah and we're going to
have this amazing model that everybody
understands because
everybody speaks blah blah blah and all
of a sudden i feel like i'm in a disney
movie
anyways yeah yeah
so so speaking of agreed upon language
even if we
agree on a language uh or somebody
agrees on a language there
it's not necessarily understandable to
everybody
right so so why do we why do we rely on
diagrams in particular for for modeling
right so
when we do a model we're we're building
this representation
right and we want to understand what the
system looks like but we don't need
all the details right and so
we so that we need to model but
we rely on diagrams because well
you're different different people in
your organization will have
different understandings of things but
also potentially be i mean literally
speaking different languages
or won't completely understand the
terminology
or the context of things and so we
as engineers especially and architects
uh systems designers
uh and security people you know qa any
type of role that you're doing
you tend to be very visual right and so
you could describe a system and in fact
we're we're big fans of
of describing a system verbally
but you can loot that can there's a lot
that can be lost in translation
uh and so we really want to
look at you know or or as as
professionals as experts and not only
and as developers we turn to models to
diagrams in particular
to give us a better understanding about
a system with uh with as minimal
translation as possible
so if we look at the language uh on the
left right
that actually describes this model but
obviously
it's a lot easier to read that in that
model than it is to
to read that text right uh and so
in a nutshell in a in a few symbols on a
page
you can quickly understand what the
system is doing uh whereas
you know you'd have to go out to google
translate or something and and
and hopefully you get back the right
information right and so
it's not perfect but that's okay
right we ex you're able to uh express
to your your your team especially and
and actually that's
that's really important we probably
should touch upon that for a sec
uh that models need to be valuable and
meaningful to the
to the people or the or the
organizations that are going to be
consuming the model and not really
anybody else
right uh and so if you're a developer
a designer a qa a security lead
you know the model has to has to make
sense because obviously we're going to
take it to the next level and do that
threat elicitation
so it has to have enough information
encoded in it
but but beyond that that's really all
you need right and
here we have a model that has a
small number of number of elements in
them with some basic interactions
and some some attributes that we can
then
leverage and that gets a point across
and that's the important part here
and i apologize to the scott scottish
people for
for butchering this i'm sure using uh
using automatic translation software
but actually matt there is one more
important thing here that
the mention of gaelic just reminded me
we work in distributed teams
and many times we have people from many
countries working together
and english is the lingua franca of
development but not everybody speaks
english at the same level or with the
same
fluency and i
i've seen in the past that somebody
who's in that
role where they can't they don't really
speak clear english
they were able to point at the diagram
and say it's not like this
so you you break down barriers of
language
and sometimes even of culture by giving
people another different way of
looking at that system and agreeing that
that's actually what we are building
right that's a really that's really good
pointers are
um and so there are really a lot of ways
you could express
a system model uh we've touched upon a
couple of them already but
but just to just sort of flesh out the
list here
in the in the creative process a lot of
people talk about
you know drawing a little you know
something on a back of a paper napkin
and that's the big vision that they have
and by the way that's perfectly
reasonable right you can pre you can
you can reasonably construct a model of
a system a representation of a system
on a piece of paper or on the back of a
napkin just as a doodle
right or in you know paint or whatever
like
whatever you want and then but there's
more
structured ways of of doing doing
diagramming uh as a
as a team an organization gets more
mature and
and capable right uh so back in napkin
drawing
perfectly reasonable i don't think i've
seen it too often
myself i don't always are if you've ever
ever seen this in a business since but
i'm sure i'm sure it happens
it can get kind of confusing you have to
put multiple pieces of napkin together
uh so not recommended for big systems
but certainly it could be done
uh but it's a concept actually more so
than anything else right so as opposed
to
a structured thing where it's you know a
big event and
and you know that documentation
on a quick meeting in somebody's office
right where you grab that little side
whiteboard on your on your cube or
uh you grab a piece of paper off the
printer and just start drawing drawing
something on that
to express an idea again that graphical
nature comes through
and you can use that to express some
basic information which you can then use
to do some of that basic threat
elicitation that we've
we're again we're not going to talk
about today but that's the next step in
the process
now as you move up the sort of the
maturity and the
structured scale right you'll have some
block diagrams
now we talked earlier about how
developers
uh you know sometimes have a hard time
doing modeling because they think it's
it's hard or it's different or it's not
their job
but in fact they already do as is our as
mentioned because
they build block diagrams right of an
architecture
right when you if you have a software
stack or you have a system stack in
general
you know you may have a block diagram
that shows the different building blocks
and how they sort of
sit on each other or next to each other
or how they potentially have
interactions
and so you know somebody should be able
to use that
to start at least start the conversation
around around
a a system an understanding of a system
that you can use to do threat modeling
but it also could be used directly right
um now traditional threat modeling uses
something called data flow diagrams
or i should say the most more common
methods of
doing threat modeling use data flow
diagrams where we basically describe
the elements of a system and their
interactions but specifically how data
flows through a system it ignores
architectural information to a grand
extent
but really does highlight how data flows
throughout the system
and it's usually along data flows where
you get security concerns
right but again
and so far we've talked about three ways
of doing modeling they all express
similar things they provide information
in a graphical form
usually in a graphical form to to the
attendees or the stakeholders
and they're all valid for purposes of
doing a system model
moving up the scale might look at
something like a sequence diagram
uh where now instead of looking at an
object in the interaction how data flows
we may look at those objects
interactions in terms of order
and time dependence right so not only
does something
does a talk to b but does a talk to b
and then b
talks to c and and what order do those
messages occur
because that can be very important uh
other diagrams as we move up the scale
process diagrams is a good one so how to
not only to have
how to system objects talk to each other
but how do
uh how do maybe systems and processes
work right so this happens a lot in
process engineering especially for
like chemical plants and things like
that but you could use it for
really for any type of system analysis
um
and i just realized we left something
off this slide um
which is attack trees right so we have
this notion of of attack trees that are
another form of model
it's another another graphical system
but it really connects a
cut it's sort of a cause and effect
diagram right and so
we look at what does an attacker what's
an attacker's goal
and how are they going to meet get to
that goal by
what are the things necessary in order
to meet that and build you build up this
hierarchy
and it's an attack tree it's effectively
a sequence
of attack of attack and defense
mechanisms
um when it's fully constructed and it
expresses information in a different way
but still useful for that that threat
analysis side of things
the last three on this are a little bit
different so dfd3
is dfd version 3 being championed by uh
adam shostak uh who is uh as anybody who
does security for a living probably
knows
knows of him uh and uh
and especially threat mulling well
specifically threat modeling
uh and that uh you know dfd3
is is a more simplified version of the
traditional data flow
uh diagram so data flow diagrams have
these free esoteric shapes
that are hard to draw in certain drawing
packages
easy to draw on a whiteboard but hard to
really draw electronically
dfg3 makes it easy because it uses basic
flowchart shapes
in order to do this so it becomes a
little bit more accessible
you can also describe systems in a
descriptive language
such as aadl which is an architecture
description language which
you can use to talk about a system and
its components and its interactions
and then lastly we can also build the
model in
code now here's where it gets
interesting and we're going to talk
about this
you know sort of towards the back end of
the presentation uh
where instead of building a model by
drawing so we're going to break out of
this we're going to do a diagram right
away
we're going to describe the system in
code and let the code build us a model
and this is a great way for for people
who don't like the draw
or who are not very artistic or just
don't want to
i don't spend the time or whatever it
breaks down those barriers because now
they can talk
in the language they in a language they
speak
which is code and have the code
generate the model for us so effectively
you get
the diagram as an after effect of the
discussion around
the architecture of the system yes how
many how many times how many side
effects do we get in this uh
in this conversation as many as you can
like
i don't know a headache but
[Laughter]
it's important to to say too that before
we said hey there's no standard language
of doing this thing
but the fd dfd3
appears to be making strides
into in that direction
and uh eventually we actually would be
glad to see it being used
more uh extensively okay it's very
simple
and yet it manages to be very uh uh
expressed and and and i i guess i'll
just add to that
uh one additional thing so in our
travels of course we've
uh uh looked you know at various
uh modeling techniques obviously we have
we have a few up here and and there's
certainly more i'm sure that we've
missed uh and
these are by and large extensible
because
you're going to potentially find things
that work for you right
so as an example i i have a personal
extension to
to dfds where
dfd is because you lose architectural
information
it's useful to know which end point in
the in an interaction
initiates a communication so i've added
a little tick mark
to that to that data flow and in dfd3
it's easy because you just take an arrow
and you make it really short and you
attach it to one end of a
of a data flow and and the coming out
bound from from the
endpoint that actually initiates the
communication and it adds a lot of value
for
for me and for the teams i work with
um because they get to see that that ext
you know they see that representation
say oh
that you know a is talking to b not the
other way around
and and you don't always get that
information from the data flow alone
now i should also mention that data
flows in particular
require other information so the the
diagram itself
has information in it but in order to
make this really work
you also have to have well you know
annotations
descriptions about the objects um and
those and those
those attributes and whatnot um sort of
on the side right you have to have that
available in order to really interpret
the the model
it's not to say it's bad it's just it's
two pieces of information that have to
go together
yeah and actually uh matt just reminded
me and this is probably going to be a
good segue for the next slides
uh looking here at my poster of the
threat modeling manifesto
one of the anti-patterns that gets
called in there is the
perfect representation one specifying
that there is no
perfect representation
go ahead sometimes different views of uh
system different representations
different models of the same system
are going to reveal different uh kinds
of information that are
valuable in doing the threat elicitation
you were going to say man
i was going to say interesting you you
called that out
if we go to the next slide so as
ours as azar was saying uh an
anti-pattern
is perfect representation meaning it's
there is no perfect way to represent
represent a system
from a model right models by design
are going to be flawed but
they can bring out and there's useful
information you can still get out of
these things as long as you don't try to
be perfect
and here's a good here are some good
examples right so this in the next few
slides you'll see
all describe the same system they all
describe them in different ways
yet they're all valuable from the
modeling and
the elicitation standpoint so here we
have
a system right and this is the dfd model
right so this is a data flow diagram
describing a system where a user talks
to
a server a server a talks to server b
server b talks to a data store and it
does this over https jdbc
and then local file access and right off
the bat you probably are
noticing a few things that would be
valuable if you're going to be looking
for threats
because we've encoded enough information
into the model
that it's easy to get that point across
with really nothing else
right no no other information there is
other information available for this
model but you don't really need it
because you know that you have
two processes a data store and a user
and some communication in
channels and that's great if we go to
the next slide
you'll see we have the exact same model
exact same system sorry
now using a different representation
right so now we have
dfd3 version of this there's again a
need to have annotations so it describes
what a b
and c are but you still know and we
should have actually probably should
have started with this one as opposed to
the previous slide because you have a
and b that talk to each other and they
talk to c which is a data store and you
have a user that talks to a
right and we know that there's this
relationship and
just from looking at the model you can
make certain judgment calls about
what the system is what it does and how
it operates
and that's the important part about
about having a model a good
representation
and you also have the trust boundaries
in here so it stores that a
lives in a separate level of trust than
b and c
which we also saw in the previous one
but represented in a different way yep
absolutely
yeah and so you can make you can
eventually you'll make judgment calls
you'll you'll do that elicitation part
to say uh there's a bad pattern here
right but but right now you can have
this you can have a conversation with
your development team
as a developer you can have a
conversation with your stakeholders and
say this is what we're building
does this make sense to you is this
actually what we built
[Music]
which is the fun part
uh all right and then the next slide is
yet again
another implementation another
representation of the same system now
this obviously is
is a sequence diagram and we left a lot
of the specific
you know details of the messages out but
really we have
again a user a b and c and there's a
flow to that data and there's an order
of operations now that we get
out of this and if you were to take this
and and and match it to
the previous slide or two two slides ago
you would then have a really good
understanding of how the system
actually operates uh and how it's
designed to work
and from that you can then take that
model and do things with it
such as finding finding threats and
that's the key part right so
we document uh we document a system
and as a side effect well we document
the system
which may be the side effect in the
first place but we document the system
and that allows us to then do things
with that to get
value and meaning out of it which
includes
threats um but you know this is
this is important right so we we finally
have a way of representing a system it
doesn't have to be perfect it just has
to be meaningful
and just for completeness here in the uh
the sequence uh
diagram if uh you all are not familiar
with it
you have the component of time edited
that's what makes it a sequence
so time flows from the top to the bottom
meaning that that that message between
the user the actor and a happens before
the one
that goes from a to the user so this way
we can also look at different
uh ways that the protocol happens
when we can even analyze a full protocol
and look for
issues that would be more difficult
to figure out from representation for
example as a bfd
right so actually sorry go ahead
just finish your thought uh you're going
where where i think uh i wanted to go
well yeah so so before we go into the
next slide i was just gonna say we
we we haven't really talked about threat
elicitation really what it means because
we don't really want to
focus on that but but we do need to
focus on a little bit then
in that well how do you make thread
elicitation how do you make those
decisions
and it really comes down to the
information that's encoded and there's a
certain set of threats
that um that can be identified
that rely on this timing information
right you can only know
if you know this information right and
so just
knowing that you have process a and
process b and they talk to each other
isn't sufficient to find those things
but knowing you have process a and
process b
and they they operate in a certain way
and and order of operations
matter now you can start making those
judgment calls about whether you
actually have a particular class of
threat or not
exactly next slide so
here yet again similar
right we have another another diagram
same system
modeled in a completely different way
right so this is a network architecture
diagram right so we have a user talking
to a browser a browser
goes over the internet nice cloud that
we got there
goes to a load balancer hits a front end
and then eventually makes its way to a
back-end server and there's data that
passes between them
now keep in mind this load balancer here
in the middle
we we didn't have that in those other
diagrams
right and because we weren't looking at
architecture we're only caring about the
data flowed in
you know between components and so we
don't necessarily
get all of the information from those
models again the models are not meant to
be
perfect the models are meant to be
representative
right and so that's why not only can
there be no perfect representation
but if you know that there can't be
perfect
representation then having multiple
representations
gives you better information uh and it
also may be that you have this diagram
already because
this is i mean this is how you build
market marketing slides out of
or you know how your use cases are just
developed or whatever right and
and so you may already have this
information
maybe you have a deployment guide and
you have and you have this um
as opposed to a dfd which you know you
may not have
naturally
so switching gears just a little bit
so we've talked a little bit about how
developers may be reticent to build
diagrams to build models
and and do diagramming because it's
confusing
or not my job i don't have time or a
various number of reasons but
one of those other reasons that
developers uh sometimes or and not just
developers but but others
uh stakeholders in the process and the
security process may
um have a hard time
[Music]
doing the action of building a model
especially for security is
it can be scary sometimes right uh and
we don't want to scare anybody except
for on halloween and defcon and
you know don't want to show up on the
wall of sheep and all that sort of stuff
so so
we want to we want to be careful
that we don't scare people for the wrong
reason right
and we can help as security
professionals especially so
really this slide is talking to the
security professional professionals out
there who are who are watching
that we can help sort of smooth over and
help with this activity by
not using the big words right
so you know when you're talking about i
have process and process b and the user
is
you know talking over http and and
they're going to send their
username and password they're basically
authenticated right well
you could use that word or you could say
the web server is going to prove the
identity of the
of the user or even further down
uh you know uh sort of not not dumbing
it down but making it you know more
understandable to the more common
stakeholder
um you know the the the server is going
to identify
the server is going to identify the user
right they do that through
authentication but that's okay right you
don't necessarily need to say
that cryptography another big word
right what does that mean right there's
a lot of stuff that fits in that in that
bucket
it's confusing it's math some people
don't like math it's math
uh and so you know we're going to
protect data right by we're going to
obfuscate that data that might be a big
word we're going to change that data
from for
one form to another through some
mathematical process
we don't need to know what that process
is it happens to be cryptography
but you know we can we can sort of
minimize the angst
right and so some of these
of course we can't do that and in fact
one of these words as called out here
really
always is scary and there's really no
nothing you can do about it
um but uh you know so we can help
we can help developers and other
stakeholders
reveal their secrets right what
information we need to get out of this
exercise and and
when i say we i i sort of mean security
professional if you're
if you're moderating one of these
exercises or you're leading a threat
modeling exercise
uh or if you're a stakeholder in an
exercise with a
with the development team especially if
this is you know say this is an agile
scrum team or
uh or or you're part of a a project
to to do security analysis you can help
by facilitating the conversation
by doing some basic translation right
make this accessible to stakeholders
right so that they can be more involved
in the process and then from that you
get better information that can give you
a better representation
and therefore a better model is or do
you have any thoughts you want to add on
that
no i think products are scary
no the the only thing that i would add
here probably is that uh
eventually when you talk about risk
developers
then many times the uh
the conversation goes towards but why
would someone do that
and i find that in those cases it's very
helpful
to translate risk to
this is gonna happen and it's bad right
we can all agree that it's bad
that that's not something that should be
happening right and that takes away
the why would somebody do that and
translates it into something bad
happening to the system
which usually is something that
developers care more about
than whomever is coming in and doing bad
things
yeah yeah and this um actually this uh
the notion of translation
um you know i've seen this myself with
uh working with
with engineers who are you know
brilliant people understand
their systems that they're working
inside and out but don't understand the
security terms right
and so there's a sense of you know
potential of failure right which is very
a bad place for a lot of people to be
and we don't want to
we don't want them to fail it's hard to
actually fail in this right but we don't
want them to fail or think they're going
to fail
because this stuff is confusing or new
or it's special
and and so that's really that's really
key right and and again
this just comes down to giving a
helping them understand the concept and
the principles involved
uh and and maybe glossing over the
specific terminology unless it's
important or
eventually you get to okay that means
it's authenticated we put that label in
there and that means a whole bunch of
things
and we get that one word as a
placeholder as opposed to
starting with that and having people
wonder okay what do you mean by that and
then you have confusion
and actually madame i'm going to hijack
for a minute
the conversation because i think that we
forgot to talk about something very
important
now that we're talking about things that
are scary uh
it occurred to me we haven't talked
about
basically the the stopping problem of
threat modeling and
there are two parts to it the first one
is during the modeling
how do we know that we have modeled the
system enough
and that is
once you got to a point and this is my
personal
personal experience and it works for me
and others will have
other views on the issue but i think
that once you get to a presentation that
lets you
actually make all those assumptions and
inferences that matt was relating to
i think that that's the good enough and
we're going to address the good enough
soon
but the other one is when do i know that
i have listed enough threats
and that's another thing that makes
things like this scary
you wake up in the morning in three in
the morning asking yourself just forget
something and you know what you probably
did yes
because this whole thing first of all we
have to keep in mind
it's evolutionary the fact that you
didn't have a threat model yesterday
is bad you have one today that's much
better and the one that you're going to
have tomorrow it's going to be much
better because
you're going to have learned more so
don't let that stopping problem stop you
from threat modeling
okay the important thing is to start do
it
and then move forward with the process
that was my parenthesis sorry for the
hijacking that works
so how else do we get developers to
reveal their secrets
uh so the way that i like to work with
teams
uh that i found very useful is as
somebody who's
both facilitating a conversation or
being asked to be the
the sme the subject matter expert on
security for the project
it's very useful if we start with you
know
what is it that we do here right not
necessarily what do
you as the engineer do on the project
but what does the system that you're
building do
right what is it what is it meant to do
how is it meant to operate
not necessarily from a security
standpoint let's start basic right
get the conversation started with what
is this thing
and how does it work and what does it do
and what does it operate on right
and basically this has a this has a
systems engineering term right
concept of operations if you build out
the concept of operations of the conops
you get you get first off you get a lot
of information
but also you start to establish that
rapport part of
facilitating a threat modeling exercise
and part of even just having
a team come together and do the
collaboration is really
an exchange of ideas because it's not
one person talking to another
it is in part in practice but really
it's a team getting together
and discussing what they've been
building and how it
was designed versus implemented uh and
then from that
what could somebody do to break it
horribly
uh and so with the concept of a concept
of operations
uh you get some basic information about
okay we have this thing it has a web
server and a text
and a user bring you know use their
browser from their home and they're on
this network and then
our web server talks to database and
passes information
and in that you can start doing things
like building a model
right you get information that allows
you to say i have object a and object b
and they have communications and there's
a data store and there's a user
that has a browser and now we have a
network flow and you get that from
just having the concept of operations
don't have anything else right but at
least you have that conversation and you
can ask questions
right and then you can now you can
launch into okay what else
right which brings us to the next point
keep on the eye keep your eye on the
prize what are we actually trying to get
out of this exercise we're trying to get
elements interactions and attributes
we're looking for the what
the when and the how right so the what
and the how really is the
what do we have what exists how do these
objects
you know interact how do they store data
how do they
how do they communicate with other
things and then sort of
the when if especially if we're looking
at sequence data especially
um you know so how order of operations
but you could also find out things like
okay are there times in this in the
systems life cycle
when we maybe don't have the database
protected
right or maybe the network is wide open
during setup or
oh that key that you wanted to protect
yeah it's it's it's in the clear until
we encrypt it
at some point later right and so we
really get the what the how and the when
based on what the system is and then we
can start asking the questions okay oh
so you have this database okay how do
you talk to the database oh okay
do you use uh do you do you do you prove
that the server is the server talk into
the database
aka do you authenticate the data the web
server
oh yeah we do that with a password that
we store on disk
oh how do we store that oh it's in the
clear until the first pass and then it
gets encrypted
okay so now we can we can move on to do
some thread elicitation from that
we can build out some attack trees about
how an attacker might want to
influence the system to steal that key
for instance
and so that's really the the
conversation starter and into
the exercise and you see that's why you
are
a much better modeler than than i am
because i just try to have those
meetings like at lunchtime i bring pizza
and i say nobody gets pizza until i get
all the secrets
it probably works better than than how i
approach it but
i think that you get better results than
i do i think
well it in and actually it it is funny
uh you know that you can take different
approaches
some people do the good cop bad cop
arrangement um
it's hard when you're the good cop and
the bad cop at the same time
um unless you're dr jekyll and mr hyde
uh
and uh you know or or
you're you know friends with the
developers right meaning you get
friendly you get be part of the team i
like to get integrated with the team
when i
when i talk to them right and really be
a part of the
part of the group not because i want
them to like me
but that helps but but because i want
them
to know that i'm there as a trusted
partner right i'm there
to facilitate i'm there to provide my
expertise to them
if they don't have it or to provide
another pair of eyes if they do
right and that's important and you
actually just reminded me of a
conversation that i had with
brooke jones who's another amazing
threat modeling expert and we were
discussing uh talking to two teams
and especially that barrier between
being the guy
coming to help do the trust model
another guy coming to threat model
the guy coming to help do the threat
model there's a
big distinction in there and how
sometimes
even when you're modeling you you hit
that barrier
where the team feels that you are
basically criticizing their design
so it's important to let them know that
no you you're not there to tell them
you wrote this thing badly you're there
to help them make whatever it is that
they built whatever it is that they're
building
more robust more secure okay so when
you're having this dialogue with the
team
it's really important for them to
understand that you are on their side
you're not the big bad auditor or
whatever the big security guy
that came to say that's wrong that's
wrong that's wrong fix that
you the guy that's working with them to
make the thing that they are already
doing
better absolutely yeah definitely
all right so some other
tips here um
first one is when you're
thinking about a system in order to help
facilitate a model
it's helpful to think about this in
terms of
subject action target attributes now let
me explain that a little bit more
when you build out a model a diagram
especially you're going to put
say you're going to put object a and
object b on the on the diagram
and you're going to connect them with a
line well connect them with a line
establishes a subject and a target and
some action
and there's attributes that go along
with those objects and that interaction
such as right whether it's authenticated
or not for instance
so so let's say we have process a
something a
and something b and they communicate so
a communicates with b
now saying a communicates with b means
a initiates communication meaning sends
a message
or requests information from b
we can also say as the other example
here we have a process
that listens on port 8080 and it'll take
a username and password from user
aka i have a process it opens a network
communication port and waits for a
connection on port 80 so i would have a
line coming inbound to
this process and i would have have
attributes that says
it's over port 8080 and it's
authenticated
now of course it's port 8080 so it's in
the clear
i was counting minor
minor problem right but that's okay
right and so so really the
language that you use to describe the
system when you're communicating
to to stakeholders where as stakeholders
are communicating amongst themselves
you can build the model from that
language
because you're basically describing the
system as you're talking right and
that's important
it's important because you're not doing
that translation of okay well blah blah
blah blah blah we have
we have this this object and we have
this object and it makes a function call
to this api and this api then transmits
tcp data over
over a network block okay great but we
don't actually need all of that to make
the
determination of i have port 8080 http
and i'm passing a username and password
over it
right and so that's that's important
uh as as the tip here is if you keep in
mind that okay what talks to what and
how does it talk to that
and then what are the attributes on that
now you get the language that allows you
to build a model
easier lastly
uh or at least you know for for this
slide we want to remind developers
that they already have a lot of
information we've already talked about
this
uh and we'll just hammer this point home
right that
there's probably already a body of
information available
that you can use to to either jump start
the conversation or to bootstrap
the modeling exercise
uh so that you get you know you can pull
good information out
right you may have drawings block
diagrams especially architecture
diagrams
etc you may have specifications for the
system or requirements or use cases
right and you can use that information
to then
you know do the right thing when it
comes to building out a representation
and then doing thread elicitation
so it's recommended or i will make a
recommendation
to use what you have already use the
body of information that you already
have available
to start the conversation right that way
you certainly if you're a stakeholder if
you're a security expert coming in from
the outside
you get that connection to the team you
can they can feel like you're
you're invested you've invested time to
look at what they've already been doing
and and there's a trust that can be
established there
and then don't be afraid to give out
homework right
to to stakeholders right if there's a if
there's a problem that you hit
during the modeling exercise like oh we
have this process we're not not sure how
it does what it does like
we know it talks to these things but we
don't really know how that happens
okay fine break for the break for the
evening and
tell you know hey can you uh joe or jim
and
go off and research that come back to us
at the next meeting
right it's okay to give out homework
right the information is there somewhere
if it's not in diagrams or in
specifications it's potentially in code
right and somebody has to just go figure
it out
uh is our next slide thank you so we
talk a little bit about good enough is
good enough
sounds easy right so let's set
clear expectations about what we mean by
what do we need versus what we want
right we can never have it be
perfect because representations of the
real thing are never going to be exact
because if we have exactly the real
thing then we're not building a
representation we're
building the real thing and so we just
need to decide how much information is
going to be sufficient
and then figure out okay are we there
yet can we stop
and say it's good enough right so
because there are no perfect
representations there's different ways
that we can express
data and that data can then allow us to
do
to make judgment calls about what's what
what
security concerns there might be
especially or what privacy or other
concerns there might be
we just as as a stakeholder or as a team
we decide
are we are we there yet right or have we
met that
good enough state and it's okay to say
we're good enough with having
one of those diagrams we had previously
if that's if that's a system
maybe that's good enough right so
it's up to you and it's really up to the
stakeholders to know what's meaningful
and valuable to them
all right so a couple things about
barriers and how do we remove those
barriers
so keep in mind that we have uh in this
new work from anywhere
or uh you know posts well or post or
current
uh pandemic uh environment
with people working remotely working
from home
you need a way of building a model
collaboratively right and so
there are a number of ways you could do
this uh and and we'll talk about
we'll talk about a couple of ways a
little later so i don't want to step on
his heart's toes
uh but you know keep in mind that when
you
you have ways of building
collaboratively right so you can do like
a zoom call
right and on a virtual whiteboard uh
you know if somebody sets up a webcam
looking at their at their wall with a
with a whiteboard on it and you can draw
it's hard sometimes because sometimes
you don't don't get good camera
resolution or you might have delays in
the video etc
but that's one way of of building a
model collaboratively
but you can also build it by a good
selection of tools one things we
talk about in the threat mining
manifesto
is choosing tools that are useful
and not making them the center of your
world but using them to facilitate the
conversation
right facilitate the construction of
that documentation
and nothing else uh so that's important
now once you
have chosen the right method of doing a
collaborative model
you want to make sure that we maintain
that right so as the system changes
we want to keep the diagram up to date
to keep the model up to date more
importantly because
the diagram and its annotations um to
keep that up to date so that as the
system changes we can keep track of
things and
and threats will come and go right so
say you
change that interface on that process
from h to from
you know http port 8080 to 8443
well now i've closed out a set of
threats i may have introduced new ones
right and so it's important to keep the
diagram up to date west and the model up
to date as changes occur so that the
thread elicitation can follow
and then lastly at least for for me here
the
the common patterns and diagrams exist
so as you're looking through a system
and as you're describing the system
you'll notice that patterns appear right
so you have
i have a web server over over a http
well that means that's a pretty common
pattern actually i mean you could first
off you could build a toolkit
of of objects that you could plug in
like if you had a stencil kit right you
could create those um
but also just interpreting a diagram you
may then match that to
a pattern in your threat modeling
process and and izar can certainly talk
more about something like
uh continuous threat modeling which
looks at these patterns
and and allows you to do that thread
elicitation
easier because you have a common pattern
that appears throughout your models
and i'll turn over you as our for some
other thoughts there and
these other ideas so uh very very
quickly and very hand wavy
there is a bunch of other ideas on how
to overcome this
this uh this type of this uh
obstacles so for example you could say
hey you know what you guys don't want to
draw
to draw don't draw let's get somebody
who is ready to draw
put them in the head of the class and as
people talk he's going to draw
on a whiteboard then we take a picture
of the whiteboard
and we distribute to everybody yay we
have a model and you know what that's
perfectly
fine the important thing is you have a
model the problem is you don't have a
model that you can easily
update keep a version put together with
your code
distribute annotate but you know what
you have a model that's already a good
thing another thing is infer diagrams
you have enough stuff you should have
enough stuff lying around
to give you enough to start with some
kind
of diagram and who knows perhaps people
see what you did and they start saying
that's wrong that's wrong that's wrong
and you end up with one that's actually
right
but you could start from requirements
you could start from use cases
you could start from post-its that
people left around saying hey this is
how i wrote this thing
you could even look if there is a code
and come up with something that the team
can look at and say yeah you know what
it's a good start let's let's finish it
well
then you have especially to address the
collabor
a part of the thing diagram's a service
we have
nowadays enough uh
things like lucidcharts and draw io and
i don't know the next one and
the other one that people can actually
collaborate over
with their mouse in their browsers
everybody together doesn't matter if
it's a mac
linux or pc or anything people are just
working on the same canvas
and trying at the same time to model
that system
so that's that's a good one uh
and then we close with model as code
and modulus code for us it's very close
and dear to our hearts
because it's part of something called
threat modernist code
or threat modeling from code which matt
has already alluded
and now we are sort of going to show you
now i have very fat fingers i uh i am
terrible when i do
live demos so instead i'm going to show
you the whole thing
and point you in the right direction so
that you can try by yourself
so we are talking about something called
pythia
ptm started about uh two three years ago
wow and uh matt and i started it
with uh uh with the help of some great
people
john vaz uh uh nick
one of the organizers of the the village
and
uh rohit shamboni as well
and what we thought in there was hey
wouldn't it be cool if we have a simple
way
to express a system
and once we did that we would get
diagrams and we would get threats
out of it a different way
of threat modeling for developers by
developers
and that escapes a bit from the tried
and true method of
i'll give you a gui you drag some shapes
you connect them
and you're going to set attributes and
then you're going to get a report
uh surprisingly enough some people don't
really like that flow
and as we we alluded to they prefer to
express
their systems in a way that they already
know that they're already familiar with
and that
we could even say is a bit less
threatening for them
so what is by the end the library
written in python
that lets you define the components of
the model and the relationships
which now we know are the data flows it
knows how to generate a dfd
or a sequence diagram
it lets you annotate to the components
with their attributes
and it uses those attributes and the
data flows
to elicit threats that
derive from a wasp top 10 from
the top 25 list from kpac
uh and give you those threads as a
function of the components and the data
flow attributes
now what does it look like and actually
before you
jump into the what does it look like
just to remind folks it is open source
and it's up on github you can find it
and i think we have a link for it later
so this is the minimal scaffolding that
you need to write
up itm uh model description
everybody recognizes by now the
invocation to python 3 we
are not python 2 comparable and
we basically start by importing some uh
classes that represent elements like the
whole
threat model itself tm an actor a trust
boundary
uh classification for data you can say
if data is top secret
restricted public uh an object for
data itself we treat data as an element
which is not something that you see a
lot nowhere else
uh then you have dataflow
to carry that data between elements you
have a data store to store the data and
then you have a process
and a higher class element which is a
server
we start by defining the threat model
object itself it's going to hold
everything together and where you see
there in red your
model goes here that's the place where
you actually add
your description of your model and then
you call tm.process which will take
all the description that you just wrote
plus the
arguments that you supplied in the
common line and come out with the output
that you
required now what goes into that your
model goes here
we start simple with what would be in a
dvd
the blobs so those are the elements that
we have in this case
we have a user we have a client we have
a server we have a database
things are kept very simple in here we
say what they are and we give them names
then we start with the data flows the
relationships between
those elements that we just uh described
so in here actually uh these slides are
a bit uh
dated and where you see data flow
from where to where and then the third
field
here it is a name for the data flow a
description for the data flow
actually now we require data flow
objects in there
so the data flow is sorry data objects
in there
so the data flow actually is enriched by
the attributes of the data that it
carries
and we can see here an interaction
between the user and client
data that comes in from the client to
the server data that gets saved from the
server to the database and so on and so
forth
with just that in place
we are able to generate these two
diagrams the top one is a dfd
and again the slide is a bit dated we
have ported
uh itm to support dfd3
so now we are moving on with the times
and supporting that effort
and the bottom one is a sequence
diagram and now that we see them both
side to side
we can reinforce what matt had said that
they actually
describe the same system describe the
same relationships
but in different ways that let you see
uh
different aspects of the system and
perhaps infer different threats
right but then we go
further we now define trust boundaries
remember when we spoke about it in the
in the beginning with the
the sample diagrams
we are defining levels of trust in
between
the elements and how the data flows
cross
those levels of trust so we declare a
public boundary and a protected boundary
and then we start putting elements
inside the respective boundaries where
they sit
once we again run the script
we get our dfd with full representation
of the trust boundaries
so we can infer even more security
uh information out of it
in the end we have a very simple
template language
that lets you express what can clearly
be seen
as a full thread model report
so we have the diagram
we enrich it with information about the
data flows
things that if we put it in the diagram
even though it's possible
if we put it in there it would make it
very difficult
to read and to follow the diagram so
we decided to put it on a separate table
and basically you get the same
information but enriched with the data
then we have a data dictionary we want
to know what are the units of data that
this system works on
it gives us a better understanding of
how things flow from one part to another
and how they are transformed and then
we close with a list of the potential
threats
that uh have been found in this
with this representation and and sorry
before you before you close that out is
our it's important to note
you know we basically have 20
25 lines of code which
generate a model with significant
significant sufficient amount of
information and the annotations that go
with it
to then do thread elicitation right and
and that's important as a model then we
can also keep up to date
as the system changes it can be
collaborative because we can put that
model
into say you know a source code
repository tool and you can do code
reviews on it
uh or do you know pull requests
and now we've met all of those goals
right
and it's a pretty straightforward method
now obviously we're biased because
you know this is this is our tool that
we've worked on for a while now
um but this is this demonstrates of a
way of this
that you can do this and and certainly
there are other tools out there
right we encourage you to find the tool
that works for you
but this does address that challenge of
having
an easy way of describing a system that
you can pull
from existing material that you can do
collaboratively
and you don't have to be a fan you don't
have to be an artist to do it
yep and uh we have had cases where
people have collaborated
long vast distances by uh as
matt said submitting prs real real time
or just committing to the same uh to the
same branch
and it's just a matter of each one
writes their part of the description you
run the thing
you get the diagram right away
now uh one important thing pythm
follows the philosophy of unix tools it
tries to do well
what it's supposed to do and nothing
beyond that so we use things like plan
to ml
we use graphviz and uh
for the the creation of the report we
created in a textual manner
that you can use something like uh
sphinx sphinx
or pandork and to translate between
different formats
so uh it's a very uh low
low weight low barrier of an entry and
even though it's written in python and
even though it
uh it asks for a python script you can
see from the
the syntax that anybody that has any
kind of experience
with uh an object-oriented language is
able to to describe that system
so you can go to a javascript uh
developer you can go to a c plus plus
developer and they'll be able to
write in jump and describe their systems
there's no
there's a very low barrier of entry to
be able to describe your
your system uh
i guess that that's what we had and we
are over time actually
yep so next slide yeah thank you very
much for
for attending this presentation
hopefully you'll have a chance to ask
some questions when it's
live and you have some references here
the first one is the threat modeling
manifesto which we heartily
recommend as even a starting point to
threat modeling
then you have the ugly fish book
you have the pointer to uh ptm
which actually is an incubator project
on owasp
and the next four are basically
uh threat modeling information but
to a deeper level the continuous track
model in the math alluded to
is something that uh we we developed
some time ago in autodesk
open sourced as a way to do threat
modeling
by developers with developers for
developers and
the next two books are books that we
personally really like
adam shostak strat modeling designing
for security which is already a classic
on uh threat modeling and talks about
basically
everything and uh brook sanford's
security systems where he gives
great examples of architectures and
threats to those architectures how to
mitigate them and he simply draws from
his
very very very vast experience and
for those that need a bit more
accessible reading there is the safe
code technical threat modeling
which looks at facets of threat modeling
just to build that common language and
let people start
and take something away from it
so i guess that now we move to questions
and uh
now we go live so
see you there