imagine moving at the speed of cyber .
The operator needs something , he sends
a request , a developer quickly program
something , sends it over , deploys it
into the production environment the
operator uses it . The enemy is
destroyed . Mission accomplished . What
type of reality are you living in ? For
me it takes like five hours to fill out
this one single form that then goes
into like five different offices to get
this one piece of software onto the
infrastructure and then that
infrastructure goes down within a
matter of minutes because it's all held
by duct tape and glue . Like we're not
living in modern day practices here .
Well today we're going to discuss this
problem . So first we're going to start
off by introducing ourselves . I'm eric
cook and I'm captain brundage and we're
going to talk about the concepts devops
and agile these buzzwords and what they
actually mean in reality then we're
going to talk about how they are
applied in the real world . Then we're
going to discuss a few specific ways
forward using these concepts in our
cybersecurity community . And lastly
we'll conclude our presentation with a
call to action for our community . So
let's go into a totally non realistic
tale between four developers that
wanted to change the world and automate
everything . So back in the summer ,
this development crew built their very
first house got the very first project ,
they started coding everything was
great . They were living the developer
dream and then after their first sprint
they tried to deploy little
deV , little DEV can I come in ? Oh no ,
the deployment failed
it teams had , there were other
teams that were doing the same thing
that we were trying to do when the
deaths were trying to figure out how to
actually implement the tool . No one
knew the standards , They were
referencing outdated documentation .
The team also didn't know if the code
would actually work in production and
our deployment process just took a
whole long time because of all these
factors . So
eric is there a better way at how we
can do development practices around ?
Well , there are a couple of terms that
I use on my PowerPoint slides a lot and
they really sell very well . So are
those terms like agile and devops ?
Devops ? Yeah , I think so . So like
what does that mean ? Like , I don't
know , I mean mostly to me they're just
a couple of buzzwords like they mean
anything that's good , right ? I like I
have a hard time with this like devops ,
it's not a one size fits all tool ,
like it should be around uh , how our
culture fits and how we should interact
and like produce software in a cohesive
and comprehensible way . Well why don't
we talk a little bit about what those
concepts actually mean ? Alright , so
let's go into agile back in
2001 , A group of 17
developers met to discuss how they can
make software better and the end result
was a manifesto that described the
vision for lightweight software
development . This was originated
because waterfall in the , in the 1919
90s was the way of delivering
software , waterfalls , a very
effective methodical way of describing
the requirements needed for a
particular project that have become
fall short when it needs to adapt to
any particular changes . And so these
group of developers came up with four
values with 12 describing principles
and so we're gonna talk a little bit
about those four values . The first
value being people over processes , we
shouldn't be spending our time
dictating that era is the only tool
that we should be using it . If you
only use jura then you'll be successful .
Our teams need to be describing and the
processes that they need to use um and
utilizing the tools that they want to
use that makes them productive . And if
teams are more productive and they feel
more comfortable , they're going to
deliver a product that's actually good ,
then therefore we need to be focusing
on software that is working , we need
to be focusing on things that work in
small increments and so by doing this
like we need to break things fast and
early within the process . We don't
need to be working focusing on
documentation and like making sure that
all the documentation fits around to
these like perfect pieces that
we also need to ensure that we're
collaborating . Our project is open
with , all stakeholders , all
stakeholders can provide their feedback
early and often in that process . It's
easy to have a very long project and
after the end of the project , come
back to the stakeholder and they are
like , this is not what I ordered in
order to do this . We need to ensure
that they're coming in early into that
product feedback development and
finally we need to respond to change
changes very expensive , especially in
software development , but so is
delivering a failed product , if we are
not delivering our product and it's not
exceeding uh documentation , then
we have failed , we have failed as an
organization , so when we're talking
about Agile , we're talking about these
principles and these values , we're not
talking about hey you have a two week
Sprint with Sprint retrospectives and
all those planning means those are ways
of how to implement agile , but that's
not the core . And what we're actually
talking about when we're talking about ,
hey we're an agile organization when
we're saying that hey , we're an agile
organization , we're meaning hey , we
can adapt to change and we have the
organizational flexibility to adapt and
overcome any challenges that come our
way . So why do we focus on all these
principles ? Ah we focus on all these
principles because communication is
hard , it's easy to go , hey ERIC ,
these are all the things that I wanted
to talk to you about and then erIC goes
off and it's like , all right , cool .
Olivia says this is a problem and goes
off , tell someone else and then it
becomes my problem . They and eric
doesn't know what the actual problem is
and so then he falls into a ditch and
then the person that says that this is
a problem also falls into a ditch and
so how we go about this is just
ensuring , going back and getting that
active feedback with that customer and
saying like , hey , did you actually
understand what it is and if we can
actually go back to uh the
stakeholders when the within the
conversation and say , hey , what is ,
what did you think I came across as
then ? Uh you can't fully have the
confidence that they understand what
you actually meant and that is what
agile and devops helps us incorporate
in so what exactly is devops ?
Well , the term devops was coined back
in 2008 at a devops days convention in
Belgium , but specifically devops is a
implementation or evolution of agile
depending on your frame of reference
and it's centered around three ways
flow feedback and continuous learning .
Now , these were originally derived
from 1/20 century best management
practices called lean management . The
Toyota company pioneered some new
manufacturing methods to improve single
piece flow through their value stream
in order to optimize their
organizational success . So the three
ways of develop , sent around first
creating single piece flow in your
organization , identifying some kind of
value that you create in any
organization creates value , optimizing
that flow so that you begin to rapidly
create value . Then introducing
feedback mechanisms so you can see your
success in real time , then you improve
based on that feedback in a continuous
learning cycle . Now . Additionally ,
there are five principles centered
around devops . First is simplicity and
locality . That means that when we're
dealing with lean management , we
remove all the weight and excess , We
do whatever is necessary to achieve the
mission , but not more than that .
Additionally , the second principle is
focus flow and joy . That means we
focus on what really matters . We take
joy in doing it and we do it fast . The
third is improvement of daily work .
That means that we send ourselves
around improving the way that we do
work even more than just doing that
work itself because every time we
improve the way we do work , we improve
our ability to do much more work in the
future . Fourth is psychological safety
in our continuous learning cycles . We
need to be able to assess our own
failures to learn from them . That
means that we all have to feel safe in
admitting what went wrong and knowing
that that's part of a process , failure ,
not necessarily an individual failure .
When we have a retrospective , we don't
say I should have done this , she could
have done this . We say this process
should have been different here and not
even should have been different , but
this is how we will change the process
in the future so that that doesn't
happen again . Now the last principle
is customer focus , that means that
we're centering ourselves around doing
what is necessary to improve the
experience of the customer producing
value for them . And just like the fact
that every organization has some unit
of value . Every organization has a
customer that we're helping and
supplying . And so now we're gonna go
over how we can actually apply these
principles . So we'll start off with
culture . Hearkening back to what we
were just talking about . We center
around a culture of driving towards
organizational success in military
terms that can mean that we start with
the y or fight to win . We do what we
do in order to succeed and win the
nation's wars . We optimize around some
unit of value , improve our flow
towards that value . And we have a
culture of continuous learning to make
that process better . Next is
automation , we have to find what the
perfect system is . In order to
actually automate automation should
help drive our processes , computers
should solve uh those repetitive
problems and people should actually
solve the root of the problems .
Automating reduces human error and
duplication of efforts . And it lets us
get back to the real work . But it's
really hard to come back and to
abstract out what we actually need to
automate . And so there's three things
that can help us with that process .
One understanding the root core of the
process , understanding what are we
trying to get at to break it down into
the simplest steps . Once we understand
what our record processes outlining
each of that flow and then finally
factoring the development time it would
take to automate all those particular
steps and gauging how much productivity
will gain from that . But automating
everything has its cost and we should
be mindful of that as we're
implementing devops into our
organization . Finally , we should also
just ensure that as we're automating
something , we don't leave it on the
shelf and have it collect dust . We
should have it incorporated into our
culture , continuing to update that
documentation continually to update its
dependencies so that when others people
have seen that we have solved that
problem , they have a reliable software
to depend on the next is metrics ,
metrics are essential to actually
stepping from this buzzword world into
reality . So it means that we can take
anything that we do have actual
quantifiable metrics to center around
and then move towards success from
there . So that means that we're
deploying quickly in actual measurable
numbers that are multiple times per day
and our lead time for changes the time
from product requirement to producing
something for the customer and giving
it to them could be less than one day
in an elite devops organization . And
so finally we also just need to
eliminate silos , ensuring that
everyone in the organization has a
shared responsibility idea does this
quite well with their shared
responsibility model , Having a cloud
infrastructure is a hard problem . You
don't know who's in charge of what
customers are in charge of securing and
configuring their environment is in
charge of ensuring that that
environment is available for the
customer to use . But where does that
responsibility lie in the customer and
knowing how to actually configure and
secure the environment ? Well , it's up
to us to provide that education
material to them and so by having the
shared responsibility being open and
collaborative , make sure that everyone
knows one what they're supposed to be
doing and then to that we're all
working together and we're eliminating
our bus factor . So let's check back in
on our house . In this little devoPS
world , we tried to do some of these
initial best practices . We had a ci
pipeline , we had automated packages ,
but then we tried to deploy little
Debbie , Little Debbie can I come in
and then everything fell down ,
deployment still took a very long time ,
no one knew the standards , there are a
lot of issues and this is because when
we talk about devoPS and agile , it has
to be an organizational effort and even
we didn't incorporate all of the
principles that we really are talking
about here today . So let's go forward
and figure out like how can we actually
get to our brick house where it doesn't
fall down at every single term . So the
way forward really consists of five
steps , you may recognize these as
adapted from the lean management cycle ,
but first it starts with identifying
organizational value . Our organization
produces some value , we identify that
and we are center ourselves around it .
Next we map processes and visualized
work . We create a concrete value
stream from the beginning of a process
to create value all the way to the end
of it and we visualize our steps along
the way . Next we implement metrics .
We see how long it takes takes to get
from Point A to point B . And we build
our processes in order to improve that
flow . Next we introduce honesty and
psychological safety so that when
things go wrong in those processes we
change ourselves to be better without
fearing for our own safety . And lastly
we introduced this culture of
continuous learning to always make that
process better . Alright . Eric I think
you have enough talking for now . We
need to start doing , let's go start
doing keep in touch . Thank you .