[Music]
hey everybody it's alyssa miller how are
you guys doing you have made it through
two days of circle city con
it's been a lot of good stuff i hope
you're really enjoying it um here we sit
now we're in the
the uh the final
run here i guess of today's
today's events so
so glad to see you all here so glad you
could be with us thank you for joining
me let's dive in i don't even want to
wait because we're getting happy we're
going to be super happy we're making
devstech ops actually work in our
environments in our organizations
wherever it is that we're developing
software
but before we begin just in case you
don't know who i am
let me introduce myself so like i said
i'm melissa miller first and foremost
i'm a hacker a researcher and a security
advocate now what do i mean by security
advocate means i like to get out and do
stuff just like i'm doing right now talk
to all you share some ideas talk about
problems that we face in security hear
what you're thinking tell you what i'm
thinking or what i found in my research
and see what we can do to get better
that's what it's all about
i am also a be so
hmm what does that mean well we'll talk
about that in a second but i'ma be so
for s p global ratings so if you've
heard of standard and poor yeah that's
that s p so maybe like the s p 500 you
might be familiar with that as well
that's who we are now i said you know
what is the beso business information
security officer i'm not going to go
into details right now but if you want
there's a link i wrote a blog on it when
i got the job because i knew people were
going to ask melissa you you got this
job as a be so what the heck is that
so check it out if you're interested
otherwise just know it's business
information security officer i lead the
security strategy for s p global ratings
now my history in tech
it's it i've been a lot of places 10
years as a developer that's how i got
started and then i spent the last 16
years in security i pivoted from a
development job into a pen testing job
i then became a consultant for a while
and ultimately now i find myself at smp
and then finally i'm an author a blogger
a podcaster i kind of
try to do a lot of different things
again just ways that i can interact with
our community and really exchange ideas
and just again it's all about trying to
make us better
so that's it that's enough about me you
have heard enough let me tell you about
a few other really important people that
are going to be a part of today's
discussion no they're not here with me
but it's important that you know the
history so we're talking devsecops
how many of you actually know the
history of where dev ops and devsecops
came from
not everybody does so let me give you a
quick history lesson so i'm going to
rewind you all the way back to the year
2008 god i can't believe that's actually
13 years ago
wow some of you might not have even been
working in like full-time jobs yet by
then
um and that's great i love it i'm glad
we got new faces but that's why i'm
going to tell you this story so in 2008
this gentleman his name is patrick
dubois he lives in belgium
and he was a software developer among
other things and he was really
frustrated with
just the difficulty that his development
teams had getting software from you know
the conceptual stage and getting it
written and built and tested all the way
through to deployment
and he was looking for a way to make
this easier how could he reduce the
friction between his dev teams and the
operational teams that he had to work
with who were ultimately the ones he had
to satisfy in order to get his software
to production
but he wasn't the only one thinking this
this is andrew schafer
andrew schaffer was thinking some of the
same things back in 2008 in fact i don't
recall the name of the conference but at
a conference they were both going to
andrew schaefer put out an idea for a
birds of a feather session you know
where you get a few people together and
you talk about some idea
and
patrick saw this he thought it was great
he's like okay great i'm i'm i'm gonna
go to this so patrick signed up well
patrick was the only one who signed up
and in fact he was the only one who
showed up because andrew didn't show up
because there was only one person
and so
long story short they ended up meeting
later and
they got to talking about this idea of
how they would unite developers and
operations together break down the walls
make everything happy for everybody so
we could deploy software a whole lot
faster
and from that idea they spawned
devsecop stage or devops days excuse me
which is the first time that we know of
that term being used dev ops and it was
just this idea of we can make software
delivery so much faster if we just break
down all these barriers
but who's missing from this conversation
you see
this was 2009 and we started having
conferences about this
it wasn't until 2012 that security
started to realize like okay this is a
real movement we got to do something
about
organizations were starting to adopt it
amazon was doing millions of deployments
you know every year
everybody was jumping on this idea of a
devops bandwagon
so two gentlemen josh corman and gene
kim in 2012 gave what is kind of their
now pretty infamous talk security is
dead long live rugged dev ops and the
whole idea was if we're going to do this
devops thing and we're going to be super
fast and i know they cited that like i
think at that point amazon was averaging
deployments every 11 seconds in their
devops pipeline
these guys are like look if we're going
to do this we got to think about
security all differently so we are going
to jump in and they talked about this
idea of rugged devops where software
didn't just get built secure but it had
to be built ruggedly and you can go find
that talk it's definitely still online i
encourage you to check it out sometime
but
we're now in the year 2021
and we still as security people seem to
struggle with this and some of the
conversation begins with just who is
ultimately responsible for security
so prior to my current role i worked for
a company called sneak and last year we
did our state of open source security
report we talked about i went into a lot
of research on a lot of different topics
but one of the things we did was we we
had a survey and we surveyed literally
thousands of people about you know how
security
open source devsecops how all that
looked in their organization so one of
the questions i asked and it was a
follow-up to what we had asked in the
previous year was
who's responsible for the security of
your software and your infrastructure
and what you see here is kind of some
interesting results
now they could answer that question with
multiple answers so they could choose
all three they could have chosen all
four which are all five which have been
a little weird but
you see here that like 85 said devs are
responsible for the security of the
software but only 55
thought security was involved in that
and only 35 thought operations
when it came to infrastructure it
leveled off a lot more you can see the
impacts that infrastructure has code and
cloud native technologies are having
here because now suddenly devs aren't as
responsible operations predictably came
up quite a bit and security still sat
there only half of them thought security
played a part in securing the
infrastructure
so these are really interesting
attitudes that we're seeing and it makes
it really complex when we want to bring
security to the dev ops discussion
because no one really wants to say who's
responsible for security
but that's not the only problem
devops has created a whole
gamut of new technologies and new
approaches to things that we didn't have
back when i was a software developer 16
years ago
and so there's a lot of issues and a lot
of them start with just knowing what's
in your software
modern day development is more complex
than it's ever been before because we've
added all these things to ultimately
make it faster i know that seems odd
more complex development means faster
development
alyssa you've lost your mind
i promise you it does actually make
sense but we've created a lot of
technologies and you know maybe you're
familiar
with the this question here what is in
your software think about if you
remember that
breach in 2017 equifax
where apparently and we'll never really
know for sure but apparently they had
some open source struts libraries that
had known vulnerabilities they didn't
know that they were there and they got
compromised
this is the challenge we have now where
does it come from
well it's how we write our code so back
in my day god do i sound old when i say
that
back when i was a software developer
that sounds a little better
um you know if you had an application
that was 100 000 lines of code it meant
that developers in your organization
wrote 100 000 lines of code
but it's not that way anymore
you see the open source community cloud
native have all become involved in our
development in an effort to make things
faster as we've got devops developers
working to quickly
construct code and deploy it we've
created this open source community that
is wonderful and it means that i don't
have to write a 100 000 lines of code
because a lot of the functionality i may
need i go grab from the open source
community
and i just do that in the form of
dependencies that i introduce into my
software
so here's a great example there's a java
application all right and this is the
you're seeing the manifest here now this
java application is only 280 lines of
code that this developer wrote
great okay super simple app right seems
really simple
yeah but they introduce eight
dependencies through the manifest
okay
so i've got eight packages of software
that i'm going to go pull from the open
source community
that are going to now be a part of my
software all right not the end of the
world
the only problem is
each of those dependencies each package
that i introduced has its own
dependencies 89 subdependencies and
suddenly my 280 lines of code has turned
into 2.4
million lines of code that i'm
responsible for as a developer that i'm
responsible for as a security
practitioner trying to secure my
applications do you see the problem now
this is the challenge that devops has
brought to us from just a software
development perspective where we've
gotten faster and faster and faster
we've introduced this idea of
dependencies and if you're if you're a
node.js developer in particular if
you're working with npm you know the
story you go and you open up your
project you go get some coffee while you
wait for npm to reload all your
dependencies
that's what software development's like
these days but it's not just software
developers what about our ops teams i
love this quote from kelsey hightower is
a great tweet he put out a while back
i've latched onto it i'm never letting
it go he says so you want to roll your
own application platform well great all
you need to know is you need to know
linux and docker and kubernetes and
istio and prometheus and fluentd and
grafana and jaeger and harbor and oh my
god
are you kidding me
this is what we expect our ops teams to
be able to deal with
this is cloud native world hey great
devops cloud native we're going full
bore straight ahead
oh we've got our ops and our devs teams
working together they're really excited
they you know but oh my god look at what
we're asking of them when we talk cloud
native have you seen this yet this is
the cloud native uh computing
foundation's uh cloud native
landscape
now this is actually a few months old so
it's probably even worse than this now
these are all the technologies that go
into building a cloud native environment
holy crap
i've made this as big as i can and you
can't even read the names on most of
these you might recognize some of the
logos
these are all the things that our devs
and our ops teams need to be experts in
they need to understand how to configure
all these and so when we say that
they're responsible for security we want
them to be able to secure all these
things how in the heck are they going to
do that
it's just not feasible so okay great
that's why we have security teams right
security to the rescue we're going to
hop in because security is going to come
in and we're going to do that appsec
thing
sure we'll get to that appsec thing
right after we're done worrying about
perimeter security and network security
yeah well by the way endpoint security
because you got to worry about all those
people who got laptops and desktops on
our network
we got to think about policy management
we got to build all the policies that
are going to govern all this we got to
think about operations and then maybe we
can get to application security but
application security also of course
brings with it data security are you
exhausted yet listening to me because
i'm exhausted talking about this
this is crazy stuff this is everything
that falls under our security umbrella
and if you work in security or you've
talked to anybody in security you know
that we all have unlimited budgets to do
all this right
no we don't
we have limited resources we have
limited budgets just the same as
everybody else so trying to
manage all of this is so complex for the
security team but that's okay i have an
answer we have tools lots and lots of
tools all the security products are
gonna make us better they're gonna help
secure us god this looks just like that
cloud native
doesn't it it's the same thing
lots and lots of technologies that we
have to understand we got to understand
infrastructure security endpoint
security application security messaging
security web security security
operations and is in response risking
compliance threat intelligence mobile
security oh god i'm stopping i'm losing
my breath
what are we doing here
nobody can know all these things right
so if we're saying that you have to have
all of these tools to make your software
more secure and to defend your
environments
is it any wonder we're still seeing more
and more breaches every single year
no
it's not
and we in security are responsible for
many of the problems that we have
now when it comes to application
security and specifically when i'm
talking devops and how do we bring the
security conversation to devops
i have been to easily
20 or more talks
at various conferences over the last
three years
talking about devsecops
now remember devsecops
we started talking about this in 2012
josh corman gene kim thank you guys
i'm still hearing talks 20 of them in
three years that i went to
and what i noticed is none of them seem
to in my opinion at least get it
and so i started really sitting down and
listening i went back through a lot of
these talks that i had heard and i went
out and i looked up some others i could
find online
and i wanted to see what's the message
here what aren't we doing from a
security perspective is it the message
that's wrong or are we just not
implementing it
and what i found was there's a lot of
myths that we perpetrate as security
practitioners when it comes to devsecops
things that we say you gotta do things
that we say are absolutely necessary
attitudes that we have ways that we
approach this that are just plain dead
wrong
you almost got me to drop enough bomb
there but i caught myself
gonna be good today i know it's circle
citycon but i still must behave
so
what i'm gonna talk to you about today
what we're diving into next i'm gonna
talk to you about five of the myths
five themes that i saw in these talks or
that i've heard from security
practitioners even within my own
organizations
things that i've heard
as a consultant
that companies were talking about that
they thought they had to do to make
devsecops work this is where i want to
start to break down these myths
it starts with you today
we're going to start to do devsecops
better and it starts now
myth number one
tool automation is how you achieve
devsec ups
how many times have you heard it
oh devps like ops we're moving really
fast companies like amazon are deploying
every 11 seconds this means we need to
get all the security tools and they must
all integrate and be automated in our
pipeline and that's how we're going to
make devsecops happen
is that what
devops was
think back a minute what did i tell you
that
you know as those guys back in 2008 2009
2012 are putting this together
were they talking tools
no
patrick dubois andrew schafer when they
got together it wasn't about how do we
get better tools it was how do we get
groups of people working together
ultimately what they wanted was a
culture oh there's an evil term we hate
when we talk about culture yeah yeah
because it's hard to do
culture's tough how do i desi how do i
build a culture that's hard
but that's the reality when we're
talking devops or more importantly now
devsecops we are talking about building
a culture that means we cannot focus on
tools and yet that's what we what we
always do
proof i went out i went to google and i
checked search stats
in searches that included the term
devsecops
what did i find number one was devsecops
just that was the search number two i
think was devsecops um
and then i i only remember what the
other word but it was
not inconsequential
number three was tools so defcycops
tools was the number three most searched
term including devseconds
devsecops practices
didn't show up until number nine
methodology was 12 it was 10 excuse me
so now we're at the bottom of that first
page of results from google thank you
devstuck ops roles the people side of
this was number 12 and devsecops culture
didn't show up until number 14. so we're
halfway through the second page of
results
think about this if i want to build a
culture it's not just about tools and
technology it's about the people it's
about the processes and that evil g word
governance oh everybody hates governance
because governance is you yuck it's
policy
it's audits it's all this yucky stuff
how are you going to build a meaningful
culture and know if it's working if you
don't have governance if you're not
monitoring your metrics seeing what
works
you know i i told i referenced this stat
over and over again already from gene
and josh's
talk about amazon deploying every 11
seconds how does amazon know that
because they have meaningful metrics and
they have governance that says
we're going to make sure that people are
following what we're what our processes
are they're following our standards
they're doing the things they're using
the tooling and we're going to make sure
we know what's working and what isn't so
we can continue to get better that's how
you build a culture
now why is this culture so important
the motion of today's devsig ops
pipeline is very conflicting
with this
new world in particular of cloud native
which always seems to come along with
the devsecops discussion we've got these
conflicting motions we've got security
who's trying to push left god love us as
long as i've been in security we have
been talking about the need to push left
16 years
in fact we were talking about it when i
was a developer we were talking about
pushing left not just in terms of
security but also our testing we wanted
qa to push left how do we do this
testing sooner
but now we've introduced cloud native
and the influence of developers is
pushing further to the right
developers now through things like
infrastructure as code are divided
excuse me defining the very
infrastructure on which they're going to
deploy their software
so their influence moves farther and
farther right into the pipeline
but then you've got ops ops is having to
push up the stack right because ops can
no longer worry about just bare metal
servers and operating systems they need
to understand things like kubernetes and
the database
layer and they need to be a part of
creating containers all this is defined
in code they're working in things like
terraform but oh my gosh
this isn't just about plugging blades
into into server racks and things like
that this is no we're writing code as
operations folks this is where the sre
role has come from
and then finally pushing down into
granular levels of involvement in the
pipeline is our business
we've got business people writing user
stories they're putting new information
on our backlogs all the time they are
directly defining our sprints many times
they're typically at least involved in
our sprint planning if we do that if
we're true ci cd maybe they don't even
have planning and so they're there as
part of helping prioritize various user
stories
so we have all these conflicting motions
and this is why culture is so important
because having a culture around
devsecops is what's going to allow us to
align these various motions together and
coordinate them and make them happen and
that feeds right into our second myth
the second myth that i always hear when
i go
and talk to security people about
devsecops is that shared responsibility
means
everyone's responsible for security
have you heard this term shared
responsibility before this is talked
about a lot when we talk devops and
devsecops it's this idea that everybody
has a shared responsibility for getting
software out
and that's the key because when i say
shared responsibility means everyone's
responsible for security well what are
my devs in my sres saying
they're asking what the hell about us
what about all those times you told us
security you said you had the answers to
make this right and you're still telling
us we're not secure
devsecops shared responsibility this
this shared responsibility which is at
the core of devsecops culture
is not just about security
how arrogant are we as security
practitioners that we want to go in
there and say it's a shared
responsibility you all must do security
it's not just about security what about
us as security practitioners how do we
take on a shared responsibility now i
promise you this is one of
very few times and it is the only time
in this presentation that you will see a
venn diagram for me i hate these things
but
i had to use it it was the only way that
i could really think of that i could
illustrate this next point
shared responsibility is everybody is
responsible for the pipeline the
deployment of software that means all of
our goals have to align so let's talk
about those goals for a minute you have
developers what are the developers
motivations what are they trying to do
they're trying to deploy fast and
they're trying to minimize works in
progress
if you work in a development
organization maybe you've seen the
kanban boards that that our development
teams use to manage this they know
what's in the backlog they know it's a
work in progress they know what's done
what's been deployed and that work in
progress column is always the one that
we're trying to minimize
we don't want things sitting in work in
progress any longer than we have to the
key to getting to a quick ci cd work
we're continuously deploying new
software
at that 11 seconds mark
it's about reducing work in progress
moving things through the pipeline
quickly
now for ops what they're worried about
is uptime and responsiveness if things
are running slow or servers are down or
containers are failing or are kubernetes
clusters are having problems that's
their world that's what they're worried
about all that infrastructure stuff when
it comes to software they are worried
about
is it available and is it running
efficiently
and then security of course we're
looking to eliminate vulnerabilities and
defend our systems we want to get rid of
the risk we want to make sure we don't
get hacked so we are working on this
but when i talk shared responsibility in
devsecops this is where it happens it's
when those intersect when my security
team understands that security is
responsible for deploying fast and
minimizing works in progress
security is responsible for uptime and
responsiveness
same thing for ops they're responsible
for deploying fast and minimizing works
in progress as well as eliminating
vulnerabilities and defending systems
and our devs understand that they are
responsible for eliminating
vulnerabilities and defending systems
and making sure that their software
is up as often as pos as much as
possible and that it's responsive
everybody has these in their goals that
is the shared responsibility that we're
talking about when we talk about
devsecops
so we need to be building this into our
culture this understanding that
everybody is not only responsible for
security everybody is responsible
for making that pipeline as efficient as
possible and everybody is responsible
for making sure that the software in our
production environments runs as
efficiently as possible and that it is
always available at least to whatever
service level it is that we are shooting
for
that
that's shared responsibility
oh this is sounding fun isn't it but
we're not done yet that's only the
second myth
i got more
we're busting miss left and right
myth number three
build gates into the pipeline to achieve
security and devsec ops
those of you that know me and follow me
on twitter or have talked to me in any
way about software development and
devsecops you know this is probably my
single biggest pet
peeve
the story the narrative that in order to
do devsecops in order to bring security
into devops we need to put gates in the
pipeline where we do the security thing
where we validate the security of the
software
reality is
we've been doing this forever
when i go to these and we haven't
changed right when i go to these talks
this is what people suggest they suggest
that well you know when something moves
from the backlog to the point where to
the coding phase well you need to do
your threat modeling then
and then
when you're ready when that code gets
committed well now we need to do our sas
and das tools and then when we're before
we can deploy after we built and tested
it well now we need to do our das tools
and then after it's deployed we gotta do
penetration testing
this creates friction these create long
feedback loops that slow down our
pipeline more on that in a minute
we need to think in terms of
frictionless enablement when it comes to
devsecops how does security
frictionlessly enable the pipeline to
flow remember security is responsible
for
you know fast deploys and reducing works
in progress that's our responsibility
now so we have to be all about
frictionless enablement
to do that we need to make our security
practices
part of those phases they cannot be
gates in between let's talk a little bit
more about this now when i hear people
talk about gates in the pipeline usually
what they're talking about is breaking
the build you'll hear this discussed a
lot of times in conversations about devs
like ox so how does that work well i've
got developers who are constantly
developing they're writing comm they're
writing their code they're committing
their code they're writing more code
they're committing more code and at some
point that code is going to get promoted
when that code gets promoted it gets
built and when that code gets built it
gets tested and this is all automated as
well right this is where the ci portion
of our pipeline starts that continuous
integration and then from there it's
going to reach a point our testing is
done and the last piece is then now
we're ready to move to release we're
going to promote again but now we have
to test it again this is where we do our
regression test
and now we package it up and we deploy
it
so where does security fit
we put in gates we want to break the
build so what do we say we say that yes
we test as part of your build so after
your software builds we run our security
tests in an automated fashion maybe it's
source code analysis or sas tools maybe
we do source code or yes source code
analysis or software composition
analysis excuse me sca
and what do we do oh you have too many
vulnerabilities or you have to make
critical or severe or high
vulnerabilities
you have packages that have
vulnerabilities and need to be updated
we're going to push the pipeline
backward and you're going back to
development
what happens when we go to release same
thing we launch testing we test their
packages oh sorry this doesn't match up
to our expectations
we're going to break it we're putting
that gate in that gate stays closed you
can't go to production we're sending you
all the way back to development this
breaks cicd this breaks the whole
concept of devsecops
so how do we get to a true ci cd
well we've got our developers doing what
they do we want them coding and
committing all day that's what we want
them doing constantly coding and
committing putting new code into the
repository keep building up our packages
integration still looks the same we
build and then we test so somewhere in
this process we've got those
you know we're doing various testing
that's great
and then our release
package it up test it and deploy it
great
the key here is
we need to enable these developers
differently
when i talk frictionless enablement i'm
talking about giving the developers the
ability to do
much of the security work before
anything gets built
before it moves into that testing phase
so that when we get to the testing phase
vulnerabilities we're finding
are not so critical that we have to
break a build instead we're moving
toward the point where our
vulnerabilities are
low enough severity that i can just
throw them in the backlog with a high
priority
and they just get addressed in the next
cycle
another key to this is the speed so when
security is focused on making our ci cd
flow quickly on deploying fast i know
that because i'm deploying on average
every 11 seconds
then it's not going to take long for
that p1 security vulnerability i just
got put into the backlog to get fixed so
if that security vulnerability goes
through and is deployed to production i
know very quickly it will be addressed
by our developers because there's a p1
user story out there that's going to get
grabbed next
and i can do the same thing with the
testing that happens pre-deployment
this is our goal this should be our goal
as security practitioners working in
application security when we're working
in devsecops with a ci cd pipeline we
don't want to push that pipeline
backward
we need to keep it flowing and make it
faster and faster because that is what
is going to give us rugged devops we
become rugged
when
those things get fixed quickly and we
continue to improve the software at a
high rate of speed
that's where we need to go as security
practitioners it's not about building
gates and stopping that pipeline
it's about enabling our developers to
move faster to do this quicker and to
understand the security concepts that we
want them to be aware of that we want
them to incorporate into their code and
giving them tools to do it
how many of your developers have sas
tools
sca tools that run within their ids that
run on their repos when they commit code
those packages are there that tooling is
there that's one piece of it training
them giving them that awareness working
with them and enabling them with things
like reference architectures
design standards things that they can
reference back to and quickly address
the security needs of the user story
they're working on
and this brings us to our next myth
myth number four
is that threat modeling is incompatible
with devsecops
i was told this once i was working as a
consultant and i worked with this
organization who had a very well
well-defined threat modeling process
it was great i mean they had spent years
building it they went through it they
had it down to where they could do this
they called it um i don't even remember
it wasn't architecture review but they
it was like security architecture review
or something like that it's not
important but basically it was threat
modeling and they had it down to where
they could do it within a day
they could bring everybody together they
had certain artifacts that had to be
created in advance but everybody got
together in one day and they did this
thing
and i remember coming out of one of
these sessions
and talking to a developer who told me
he was so excited he couldn't wait until
they didn't have to do this anymore
because they were going to a devsecops
model
and you can't do threat modeling if
you're in devsecops
wrong
wrong wrong wrong if you saw my talk
yesterday on threat modeling you know i
hit this and we're about to talk about
it again
i promised you yesterday i would get in
deeper into this discussion so if you
saw that talk you saw this
for those of you that didn't
2019 circle cim puppet released their
state of dev ops report
in that report they analyzed a lot of
different things about devops culture
and so forth but one of the things they
looked at was security practices in the
devops
community
they looked at the frequency with which
we practice certain security tasks
versus the importance or the impact that
they have on the security posture of the
software
and they plotted it out in four
quadrants
this upper left quadrant those things
that we do a lot
that
don't necessarily have the impact we we
would want on security posture that's
where we see things and i know it's hard
to read but you see things like
penetration testing
dependency checkers static code analysis
security requirements
but it's when we go down here
to the lower right
those things that
we don't do very often they're not as
well adopted but have significant impact
we see this one that's circled it says
security and dev teams
collaborating on threat models
this is how important threat modeling is
threat modeling has such a massive
impact on the security posture of our
software and it's one of those things
that allows us to push further left
but when i say threat modeling people
start to think of this
and you probably do too if you've done
any threat modeling you see that data
flow diagram up there and you think
about oh yeah for threat modeling we
have to put together this whole data
flow diagram that maps out data
throughout our entire system where it
flows where it's stored where it's
processed the
trust boundaries that it crosses and we
got to know the whole system so that
requires us to have a big heavy design
session to make that happen doesn't it
[Music]
well no wonder we don't think it's
compatible with devsecops and then by
the way
after we've done that we're going to use
stride this thing this framework that we
use to classify threatened models
here's how we're going to classify our
threats and we're going to use really
con
technical terminology from the security
world we're going to talk about spoofing
and tampering and repudiation and
integrity
what
no one understands that come on we're
the only ones who get that but then
we're going to say that we're going to
create attack trees so there's another
process we have to map out all the
threats and how they turn into attack
trees to to realize those threats and
and we're gonna realize that some of
those some of those attack patterns
are impossible
so we're gonna scratch those off now
that's a lot of wasted effort oh and now
we're gonna use dread because now that
we've got our threats and our tax mapped
out well we got to prioritize them so we
are going to use dreaded as a framework
to help us do that and then we're going
to do this in the cyclical fashion we're
going to have to do this over and over
again
so that's all complex so then we're
going to create this thing called the
capex taxonomy because that's going to
make everything easier
does that look easy to you
doesn't to me this is why people don't
think devsecops and threat modeling can
possibly go together
but
i said that's a myth
and it is
because we can do this so much
differently
we need to think a little bit
differently
go back to the basics of threat modeling
for a minute and i know i've got
a colleague of mine she's probably
disappointed because i don't have the
slide in this particular deck you saw it
yesterday this is the infamous timmy
turner
attitude
threat modeling all it really is is
asking what could possibly go wrong
that's it
we don't need all these frameworks and
things we don't need all this
information we don't need
big design cycles
all we need to do is in plain language
define what are our critical assets and
what could possibly go wrong with them
now
we also want to push left
how much further left can you possibly
push
than the user story
that's where it begins it all starts at
the user story so if we can push
security practices left to the user
story
we've gone as far left as we could
possibly imagine and that's exactly
where we need to go so think about this
if threat modeling is just simply asking
what could possibly go wrong you do that
every day
every one of us does if you're my my
favorite example is you live in the
suburbs and you're going to go to the
city for a show
what are you going to think about you're
going to probably think about well where
am i going to find parking close enough
to the show how much is it going to cost
me
what happens if the car has issues on
the way down i get a flat tire or
whatever
is the area i'm going to and where i'm
going to park well lit and safe
what's the crime like in that area is
this an okay place to go what time do i
leave so i get there on time these are
all threats you're threat modeling in
your head and you're thinking about what
am i going to do about that so we want
our business people who write our user
stories to do the same
tell us what's important to you in this
just the scope of this user story
what critical assets are introduced or
being modified is it personal
information is it critical functions
that need to be available at all times
is is it you know financial assets or
trade secrets and then tell us what the
threats are is there a threat that they
could be stolen so there's a threat of
theft
is there a possibility of fraud
what are the key threats that you're
worried about and just put it in plain
language
because now this feeds the rest of our
pipeline and i'm going to show you how
this starts to progress us toward making
that pipeline faster and it shows our
teams how security can make them faster
and more efficient so i've got this
threat information in my backlog it's in
my user story i go and i pull that
user's story maybe as part of sprint
planning or i'm just a dev who is in a
really really fast-paced ci cd and i
just pull the next high priority item
next highest priority item off of the
backlog
i look at that threat information either
way and i can say i understand my
security requirements because they've
told me what's important here and
they've told me the threats so now as i
move into coding i can build security
controls
i can reference back if we're really
mature i can reference back to reference
architectures or design standards
engineering standards those things that
help
our developers be more
enabled to create these
security controls but it doesn't stop
there because i have this information
and now i know what security controls
i've prioritized and created well that
can feed my test cases
because now i know what's most important
from a security perspective so i can
feed that into my automated test cases
and then because that information is
there when i moved to deployment
my sres my ops teams everybody was
responsible
for that piece of it they understand how
to configure the monitoring to watch for
those potential threats
this is how threat modeling can fit in
here and is how threat modeling can be
used to make your pipeline faster
reduce works in progress
deploy quicker because security you're
responsible for it so this is how you
get there
use threat modeling not only is it not
incompatible
it's necessary and it's a huge asset to
you so let's start to
let's do this
now if you want to know more again go to
my talk from yesterday
see that talk pasta
octave stride oh my
and i'll give you more pointers in that
one on how you do this
last myth myth number five you guys
almost made it we're almost there
one more myth i need you security people
to stop putting out there and that is
this idea that we need to break down the
silos in order to build devsecops
culture
silos exist for a reason
because we need
people who specialize in certain
knowledge
when i say shared responsibility that
doesn't mean that i want my
security people
to be in there configuring databases
configuring
you know kubernetes clusters things of
that nature
i don't want my ops writing application
code
i want everybody to have an
understanding and to do their part
but we still want those expert those
areas of expertise we don't want to
break down silos we need to network
those silos
we want them to talk and work together
productively
build up scrum teams let's dive into
that let's talk about this before i get
ahead of myself
building that empathy and culture
is how we network these silos together
empathy is one of the things that i
think is so underrated i but i'm glad
i'm hearing more and more people talk
about the need for it in security we
need it in devsecops
because it's how we make all this work
it's how we network across silos and
make sure that instead of breaking down
silos we make the silos work together
in concert with each other
one of the ways you can do this is this
idea of walking a mile in their shoes
job shadowing get dev and sec and ops
spending time
working in each other's roles and don't
just use your junior devs don't just use
your junior security analysts send the
senior folks i know it's tough because
they're very productive and you don't
want to give up that productivity
but they're the ones who will have the
best perspective to bring that back to
the team
and this is all about building that
empathy where now they understand what
the people in security what the people
in ops are dealing with as a result of
what comes to them from the development
side and now they can start to shape
that they start interfacing with those
people on a daily basis and it humanizes
each other and now they interact better
from a security perspective if we're
going to talk about
new processes new tools anything
we have got to meet them where they live
provide resources and tooling that fit
in the pipeline
this is knowledge this is processes this
is tooling it's all of it make sure that
if you're going to introduce a new piece
of security tooling maybe you're
launching a new sca platform or some new
cloud security product
how does that tie into their pipeline
can it be automated
can their build scripts automate that
can the results be automated into new
entries in the backlog
how do we make this happen make sure
everything
plugs in
to their existing tooling
this is how we eliminate friction
so
while automation isn't
the only part of devsecops it is still
part of those five areas we talked about
to building that culture so make sure
you meet them where they live give them
tools that are familiar to them things
that plug into their ide so they don't
have to learn a new way of doing their
job they don't have to add additional
complexity to the things that they're
doing
so that they can continue to improve the
speed and reduce works in progress
then it's about paving the road
so as you're building this as you're
looking at it in terms of tool selection
you're throwing it out there you're
enabling your developers now comes that
idea of income of accountable trust
how many of us deal with security teams
who are overwhelmed with work we can't
keep up with
all of the demands of you know trying to
review all the software that comes our
way from our development teams
make them accountable trust them to do
the right thing trust them to see that
if there is a better way
they can accomplish the same objective
in that other way
and enable them to do that you trust
them but you trust them because you've
built a culture where they understand
that they're accountable
this takes time it takes effort and
security still needs some level of
oversight
but at the end of the day this is how we
get better because we can't keep up we
don't have those unlimited budgets it
just doesn't happen
pave the road put the path make it so
that the secure way to get there is the
easiest way to get there
but then if you're wrong enable them to
change that path and pave their own road
and then finally mutual engagement when
we're talking about empathy this is huge
how many of you invite your sres and
your security team
to your your scrums to your daily
stand-ups
to your sprint planning to your
retrospectives
do they come to your risk committee
meetings your devs and your ops teams
they should you should all be
interacting on a daily basis
when these daily activities include
everybody this builds that idea of
shared responsibility where everybody
understands that while they bring their
own expertise and perspectives they're
ultimately all responsible for the same
thing
that's how you get to a devsecops
culture you need to get everybody
into that mode of we work together for
the same objectives
creating that mutual engagement drives
that culture it builds that empathy and
again it humanizes each other where we
understand the challenges and we don't
just make assumptions when we see
something we don't like that it's
because somebody was being lazy
so it's just about time for me to wrap
up here but as i usually do i want to
leave you with a quote and this one
comes from henry ford
coming together is the beginning
creating an organization of lots of
different people
keeping together is progress so
establishing those processes and things
that we all work within
but working
together
the shared responsibility is where we
find success
that is the key to devsecops that is the
vision that patrick and andrew and gene
and josh
laid out for us so many years ago
that we need to keep driving for
security practitioners we need to
understand how we
insecurity
need to be just as responsible
as our developers
and as our operations teams
and we can make this work
so
did i get it wrong
am i completely out of my guard
do you want to nitpick something i said
and i didn't quite get it right let me
know interact with me here's my social
media information twitter is by far the
easiest way you've got my linkedin
information there as well my website you
can contact me through there
find out where i'm speaking next if you
want to catch me at a real life
conference since we're starting to get
back to those now
come talk to me
share your ideas criticize what i've
said challenge me let's all get better
at this
so finally as i'm wrapping up
big big big big thank you
thank you circle citycon it has been my
honor to be able to present here today
and yesterday too
thank you s p ratings for making it
possible for me to be here to share some
of the experiences that i've developed
just working through that organization
but most importantly thank all of you
thank you so much for being here thank
you for your support not only of me not
only of this conference
but the whole idea of making our
security community better i love you all
thank you very much have a wonderful
rest of your weekend take care