►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Improving Security while Reducing Toil with DevSecOps - Paul Czarkowski, Pivotal
DevOps is not just about deploying software, it’s about reducing bottlenecks and bringing value to the business. By utilizing DevOps techniques we can build a strong security practice that everybody is invested in, even your Developers and Operations Teams! In a previous role I utilized DevOps practices to lead a major transformation of the security and auditing practices of our team taking them from failure-prone manual repetitive tasks to fully automated unicorn status. This talk will outline the changes we made both technically and culturally to transform not only the security team, but the whole organization into treating security as a design goal rather than an afterthought. You’ll leave this talk with a solid grasp of the tools and techniques needed to knock down the silos around your security team and enter a utopian world of security first engineering.
https://sched.co/Nrv3
A
All
right,
so
it
looks
like
right
at
time,
so
let's
get
going
so
thanks
for
thanks
for
coming
we're
at
a
kubernetes
conference,
which
is
very
exciting,
so
I
appreciate
you
taking
your
time
to
come
to
a
topic.
That's
not
specifically
about
kubernetes
I'm
gonna,
be
talking
about
security
and
compliance
and
sort
of
taking
our
knowledge
and
how
we
do
things
from
DevOps
and
applying
that
to
security
compliance
and
so
I
was
I
wanted
to
talk
about
security
in
general.
But
it's
such
a
broad
topic.
I
figured
I.
A
Just
you
know,
zoom
in
on
the
compliance
side
of
stuff
and
then
the
rest
of
the
security
stuff
I
mean
if
you're
now
compliance.
You
can
then
use
those
same
techniques
for
the
rest
of
that
stuff.
So
my
name
is
Paul
and
I'm.
A
developer
advocate
at
pivotal
or,
as
my
wife
would
tell
you,
I'm
a
professional
vacationer,
so
I
have
the
privilege
of
being
able
to
travel
the
world
and
come
into
places
like
Shanghai
to
talk
about.
You
know
what
it
is.
A
I
do
even
when
it's
not
specifically
about
things
that
pivotal
does,
which
is
great.
So
I
really
appreciate
your
inviting
me
to
come
here
and
I
really
appreciate
the
ability
to
speak
to
you
in
my
native
language.
You
would
not
like
me
to
try
and
speak
to
you
in
Chinese
I'd,
be
able
to
say
one
word
hello
and
that's
about
it.
So
thank
you
for
that.
A
So
I'm
gonna
talk
a
little
bit
about
compliance
kind
of
exactly
what
I
mean
when
I
say
compliance,
then
DevOps
go
through
some
of
the
DevOps
concepts
and
then
tie
the
two
together
with
just
some
thoughts
about
the
two
together,
but
also
some
concrete
examples
from
what
we
did
at
a
previous
job.
And
then,
if
we
have
time
we
can
do
some
questions
so
we'll
see
how
we
go.
A
We
need
to
make
sure
this
can't
happen
again,
and
then
you
have
a
bunch
of
different
types
of
compliance
that
apply
to
different
types
of
companies
and
different
types
of
activities,
and
so
these
are
kind
of
fairly
like
American,
centric
stuff,
but
I
did
add
a
couple
of
non-american
ones
there
for
examples.
So
you
have
like
PCI,
which
is
really
about
people,
that
companies
are
handling
like
credit
cards
and
people's
money
and
how
you
store
the
information
about
their
credit
cards
and
their
personally
identifiable
information.
A
Hipper
is
for
say
the
health
and
and
medical
industry
same
thing
about
really
protecting
the
consumers
of
the
health
and
medical
industry,
because
they're
very
lot
of
sensitive
information
there.
And
then
you
have
things
like
socks
or
sarbanes-oxley,
which
is
about
protecting
us
from
actually
like
bad
actors
like
large
enterprises.
That
have
like
bad
actions
right.
A
You
know,
I,
think
a
lot
of
that
came
out
of
like
Enron
and
stuff
like
that
right,
so
really
protecting
us
as
consumers,
from
not
just
like
accounting
errors,
but
also
from
like
actual
fraudulent
activities
in
those
large
enterprises
and
then
so.
That's
kind
of
your
government
legislative
body
style
compliance,
there's
also
compliance
that
we
self
impose
or
imposed
on
us
by
our
customers
and
some
examples
of
that
is
maybe
the
CIS
controls
or
the
stig,
which
is
a
security,
technical
implementation
guide
and
they're
they're
pieces
of
compliance
that
somebody
has
built.
A
That
really
knows
how
to
say,
secure,
Linux
system
and
has
basically
open
sourced
that
information
and
any
company
that
wants
to
make
sure
they
have
a
secure
Linux
system
can
follow
these
compliance
guides
and
sort
of
have
a
higher
chance
of
having
a
secure
system
and
there's
really.
These
three
main
aspects
to
compliance
are:
there's
the
compliance
Doc's
themselves.
A
The
specifications
they're
often
lengthy
and
verbose,
and
not
very
clear,
which
can
create
a
lot
of
problems
for
us
when
we're
trying
to
actually
build
controls
around
around
that
compliance
and
that
sort
of
way
checklists
are
your
controls.
These
are
the
policies
and
procedures
that
we've
taken.
We've
turned
the
specification
into
to
make
sure
that
we're
going
to
follow
that
compliance
and
then
there's
some
sort
of
verification.
A
A
1
is
a
bad
thing
and
it
tells
you
exactly
how
to
how
to
check
for
it
like
it
gives
you
the
exact
command
to
check
for
it,
and
it
also
yeah,
and
so
it
also
has
like
some
really
good
control
names
and
rule
IDs
and
stuff.
So
it's
very
easy
to
follow
and
I
can
give
this
to
anybody
who
is
capable
of
SS
etching
into
a
Linux
server,
and
they
can
follow
through
like
go
through
the
compliance
guide
and
make
sure
that
a
given
Linux
server
is
compliant.
A
So
this
is
a
good
example
of
really
good
compliance.
This
is
from
PCI
and
I
would
say.
This
is
an
example
of
the
type
of
compliance
I,
don't
like,
because
it's
not
very
prescriptive
as
in
exactly
what
you
should
do,
and
you
can't
a
lot
of
it.
You
can't
solve
by
testing
settings
on
a
server,
because
it's
more
about
like
access
control
who
has
access
to
what
and
how
and
stuff
like
that.
A
So
a
lot
of
this
type
of
compliance
like
there,
a
lot
of
the
legislative
body
driven
comply,
has
to
be
solved
as
like
a
policy
and
procedure
as
much
as
you
can
solve
it
with
software.
So
the
stig
side
of
compliance
is
great.
I
can
solve
that
with
software,
the
PC
I
type
compliance
there.
It
may
be
some
bit
pieces
I
can
solve
with
the
software,
but
often
it's
like
people,
following
particular
procedures
and
policies,
and
then,
as
we
interpret
that
compliance,
we
may
come
across
more
and
more
things
that
we
can
add
to
software.
A
So
you
have
to
hire
experts
that
it
that
are
able
to
read
and
decipher
that
compliance,
but
also
that
they're
experts
in
your
business
and
how
you
work.
So
they
can
figure
out
how
to
build
the
appropriate
controls,
the
policies
and
procedures
to
make
sure
that
you're
adhering
to
that
compliance.
So
you
know
you
need
to
determine
like
how
access
is
granted
to
a
particular
user.
A
A
So
they
really
need
to
know
like
deep
dive
into
what
you
as
a
business
and
as
an
IT
organization
is
doing
as
well
as
what
the
compliance
is
saying
and
so
to
ensure
accuracy,
most
organizations
kind
of
tend
to
opt
to
like
create
these
separation
of
duties
by
having
like
a
person
or
a
team
that
are
built
to
do
specific
activities
within
compliance
and
compliance
itself
is
kind
of
you
know,
you're
covering
yourself
you're,
protecting
yourself,
and
so
that
tends
to
enter
the
system.
So
you
want
to
make
sure
there's
lots
of
auditable
events.
A
A
So
hopefully
you
know
a
little
bit
about
DevOps.
This
is
kind
of
a
famous
DevOps
picture
from
nearly
ten
years
ago
now,
from
Andrew
Schaeffer
I
think
was
the
first
person
to
kind
of
do
this,
and
it's
kind
of
showing
that
there
seems
like
developers
and
operations
have
different
goals.
The
developers
like
needs
to
be
writing
features
right,
needs
to
be
adding
software,
that's
their
got
job.
The
operators
need
to
keep
the
servers
running
so
their
focus
on
stability,
so
any
changes
to
the
software
adds
risk
to
the
stability.
A
So
this
is
they're
kind
of
at
odds
with
each
other.
They
have
different
goals
and
often
what
happens?
Is
you
kind
of
have
this
wall?
That's
up
there,
which
was
labeled
a
wall
of
confusion
where,
basically,
the
development
team
is
just
throwing
like
software,
maybe
they've,
maybe
they've
already
built
it
into
a
package.
Maybe
they
haven't
through
operations.
Just
saying
I
need
you
to
run
this
for
me
operations
like
I,
don't
know!
A
What's
in
this
I'm,
not
gonna,
go
I'm,
not
gonna,
run
it
until
I
do
like
a
lot
of
testing
and
stuff,
and
you
had
this
very
lengthy
period
of
trying
to
get
stuff
running
as
we
as
we
sort
of
hit
2010
or
so
we
started
to
think
about
approaching
infrastructure
and
operations
in
like
an
agile
way.
Taking
some
of
the
things
we
learn
from
agile
software
development,
and
this
really
started
hit
up
so
at
one
of
the
first
examples
of
like
DevOps
type
stuff
came
out
here
on
in
20,
2009
or
2010.
A
It
was
actually
2008,
X,
I,
think
actually
John
Osborne
and
Paul
Hammond
at
there
were
Flickr
and
they're
basically
were
talking
about
how
they
do.
Ten
plus
deploys
per
day
at
Flickr
by
having
like
Devon
Ops
working
tightly
together
and
removing
that
wall
of
confusion,
and
so
we
started
to
form.
So
in
2009
we
had
a
first
DevOps
today's
conference
by
Patrick
Dubois,
as
we
started
to
really
get
serious
about
this.
A
And
so
we
have
this
comms
acronym,
and
basically
these
are
the
things
you
need
to
be
focusing
on
as
you're
as
you're
doing
DevOps,
in
whatever
way
to
actually
have
good
outcomes,
and
when
you
follow
that
comms
kind
of
methodology,
you
kind
of
create
this
like
a
feedback,
loop
type
feedback,
loop
of
increasing
continuous
improvement,
and
so
this
is
kind
of
an
example
is
a
bunch
of
different
types
of
these
types
of
feedback
loops.
This
is
kind
of
the
OODA
loop,
which
is
observe,
orient,
decide
and
act.
A
So
if
you
look
back
at
what
we
had
like
automation,
measurement
sharing,
they
kind
of
map
into
into
this
loop,
and
so
when
we
use
lis
lean
techniques
to
apply
automation,
measurement,
etc.
We're
basically
building
out
this.
This
feedback
loop,
this
constant
self-improving
feedback
loop,
but
that
was
DevOps
right
and
so
a
few
years
ago,
people
started
talking
about
like
dev,
sec,
ops
and
I
was
similar
in
love.
We
have
fin
ops
and
all
these
other
terms
and
like
a
lot
of
us,
were
kind
of
thought.
A
This
was
strange
at
first
because,
like
we
thought
that
we
were
building
out
DevOps
to
be
this
very
inclusive
like
it's
not
really
just
developer
in
operations,
it's
the
whole
business,
but
it
didn't
really
work
out
that
way.
I
mean
you
look
at
you
know.
There's.
This
is
with
a
word
cloud
built
out
to
look
at
like
I,
think
some
of
the
DevOps
conferences
and
what
the
topics
were
and
there's
no
security
and
compliance
listed
in
here.
A
We
conflict
management,
chef
and
puppet
new
things
like
terraform,
but
we
were
kind
of
just
are
they
acknowledged
or
just
paying
lip
service
to
like
security
and
compliance
and
even
other
aspects
of
the
business
and
that
kind
of
left
the
security
team
trying
to
play
catch-up
and
generally
they
ended
up
how
to
creating
check
box
security
that
didn't
wasn't,
didn't
really
have
any
teeth,
and
then
we
would
make
up
like
dumb
memes
about
them
and
say:
look
how
stupid
the
security
team
is
right
and
that
didn't
really
help.
So
we
didn't.
A
Not
only
did
we
not
help
like
bring
the
security
and
compliance
teams
with
us,
but
we
also
kind
of
in
a
way
actively
deprived
them
of
their
ability
to
do
anything
other
than
like
very
basic
check
box
style
security.
So
they
tried
to
add
themselves
to
the
conversation
by
coming
up
with
extensions
to
that
term.
So
dev,
sec,
ops,
rugged,
DevOps,
secure,
DevOps
world
terms
that
we're
all
kind
of
thrown
around
dev,
SEC
OPS's
seems
to
be
what
has
stuck
and
so,
and
not
only
that
but
they've
actually
kind
of
built.
A
This
fairly
strong
body
of
work
that
we
are
in
the
DevOps
community
didn't
even
really
know
about
because
we
weren't
paying
attention
to
this
to
this
concept,
and
we
were
often
actually
do
writing
and
saying.
We
don't
need
to
have
said
cops.
It's
just
DevOps
with
another
name,
and
so
like
companies
like
fannie
mae,
we're
building
out
really
strong
dev,
say
cops
pipelines
where
they
were
bringing
security
and
compliance
into
the
into
the
development
cycle.
A
You
know
we,
we
realized
that
they
needed
a
culture
in
which
they
incentivize
developers
and
operations
to
consider
security
in
compliance
into
every
aspect
of
the
life
cycle,
and
now
the
problem
is
as
developers
and
operations
we're,
not
security
experts
and
for
a
long
time
we
were
just
like
hey.
You
need
to
write,
secure
software
and,
like
you,
can
tell
me
that,
as
often
as
you
want,
I,
don't
add
or
I
security
software
right
I'm,
not
at
the
security
expert.
A
A
So
if
we
need
to
call
that
this
effort,
DEP
SEC,
ops,
I,
think
that's
cool,
but
we
as
DevOps
--es
need
to
like
get
involved
and
learn
from
them
and
also
teach
them
right.
Because
there's
a
lot
of
things
that
we
do
in
DevOps
that
we
could
help
the
dev
SEC
ops,
folks
with
as
well,
and
so
basically
a
John
Willis.
We've
taught
them
some
folks
about
it
and
he
was
like
it's
just
a
name
like
get
over
it
and
let's
just
figure
out
how
to
work
together.
So
we're
gonna,
throw
away
that
term.
A
Devops
dev
ser
cops
or
whatever,
and
just
focus
on
like
the
comms
side
of
things,
because,
regardless
what
aspect
of
the
business
you're
working
in,
if
you
like
think
about
these
things
like
this,
is
how
you
get
improved.
This
is
one
way
to
get
that
continuous
feedback,
continuous
improvement
cycle.
So
we
can
just
focus
on
this
whether
we're
security,
whether
we're
compliance,
whether
were
operations
or
you
know
even
finance,
there's
plenty
of
ways.
You
can
apply
these
to
finance
right.
A
So
this
focus
on
the
calm
side
of
things
and
not
worry
so
much
about
like
with
dev,
ops
or
dev,
said
cops
or
rugged,
dev,
ops
or
whatever.
We
want
to
call
it
so
now
we're
gonna
tie
the
two
together
and
but
first
of
all,
I
want
to
actually
talk
a
little
bit
about
what
we
do.
A
pivotal
and
I
want
to
say:
I'm
not
trying
to
sell
you
anything
here.
A
I
just
want
to
talk
about
how
a
company
that
does
some
fairly
mature,
like
automated
operations
and
automated
security
works
and
then
I'll
get
on
to
talk
about
Xero
back
down
on
compliance
and
talk
about
how
at
a
previous
job,
we
really
focused
in
on
building
out
compliance
as
code
and
doing
dev
check-ups
with
that
focus
on
compliance,
because
it's
often
this
one
of
the
easier
parts
of
security
to
start
with
and
is
also
often
one
of
the
most
like
manual
labor
intensive
aspects.
So
at
pivotal
we
build
and
operate
platforms.
A
We
work
with
cloud
foundry
foundation
to
build
open
source
projects
like
cloud
Foundry.
The
CFC
are,
which
is
the
kubernetes
runtime,
and
then
it
we
used
to
have
RIF,
which
was
our
functions
runtime,
but
now
we're
focusing
on
K
native,
which
is
the
function
runtimes
that
runs
on
top
of
kubernetes.
And
then
we
we
take
those
projects
and
we
operationalize
them
into
our
product,
which
is
called
pivotal.
A
Unfortunately,
not
I,
don't
think
we
have
support
for
Alibaba
cloud
or
any
of
the
local
clouds,
and
so
not
only
does
it
install,
but
also
like
monitors
the
infrastructure
and
repairs
the
infrastructure
if
something
changes
or
something
goes
wrong.
So
it's
kind
of
not
just
that
day
one.
But
it's
also
the
day.
A
Two
and
a
day,
two
side
of
things
is
where
you
can
build
in,
like
automated
security
of
things
so
like
if
a
vmware
fails,
if
a
vm
fails
like
bosch,
sees
that
and
will
remediated
replace
the
vm
etc
same
with
applications
and
so
like
as
a
human,
I
could
mess
with
a
vm,
that's
managed
by
Bosh,
but
Bosh
would
just
show
up
and
like
destroy
that
machine
and
recreate
it
right.
It's
not
going
to
try
and
fix
it.
A
It's
not
gonna,
try
and
undo
what
I
did
it's
gonna
be
pretty
destructive
on
that
machine,
and
then
the
platform
on
top
of
Bosh
is
pretty
resilient,
so
it
handles
that
okay,
so
I
could
SSH
into
a
VM
and
change
the
setting.
Bosh
is
going
to
destroy
it
now,
not
just
me,
but
also
like.
If
someone
manages
to
find
a
vulnerability
in
that
system
and
someone
gets
some
malware
into
that
system.
Bosh
is
gonna,
come
along
pretty
quickly
and
say
that,
doesn't
that
system
doesn't
look
right,
I'm
gonna,
destroy
it
and
create
a
new
one.
A
A
I
just
sat
there
for
months,
sometimes
even
years,
just
looking
around
at
the
network,
looking
at
the
infrastructure
and
looking
into
getting
passwords
for
databases
and
stuff
like
that,
and
eventually
they
find
enough
things
that
they
can
then
grab
all
of
your
passwords
grab.
All
of
your
credit
card
numbers,
social
security
numbers,
whatever
it
is
they're
looking
for
so
by
removing
the
amount
of
time
that
they
can
be
on
that
system.
A
A
So
at
pivotal
we
run
a
number
of
security
compliance
tests
as
part
of
our
CI
process
and
also
part
of
that
Seany
Seany
process.
We
follow
the
CIS
compliance
and
plus
a
bunch
of
the
like,
PCI
and
other
stuff,
and
we
can
make
those
available
to
people
that
want
to
make
sure
we're
compliant,
but
any
updates
to
an
application,
basically
results
in
a
complete,
rebuild
and
deployment
of
the
immutable
infrastructure
in
that
platform.
A
Obviously,
we
manage
the
state
and
databases
and
stuff
and
we
provide
automatic
deployment
updates
like
as
soon
as
we
release
them
in
the
form
of
like
CI
pipelines.
So
we
have
a
lot
of
customers
where,
when
we
release
an
update,
they
automatically
consume
that
update
and
automatically
upgrade
their
platform
to
the
newer
version
that
doesn't
have
that
vulnerability,
and
that
happens
both
on
the
the
the
under
the
platform
and
also
above
the
platform,
with
their
actual
applications
that
they're
running
on
top
of
the
platform,
and
we
we
do
it
with
like
canary
deployments
and
stuff.
A
So
it's
a
pretty
safe
operation
and
we
do
a
lot
of
validation
to
make
sure
it
works.
So
basically,
the
entire
platform
is
actually
frequently
rebuilt
and
redeployed,
often
several
times
a
month,
and
we
actually
have
customers
large
banks
that
actually
forcefully
our
repave
they're
their
machines
like
every
couple
of
days.
So
the
long
list,
a
piece
of
like
a
vulnerable
software
or
a
piece
of
malware,
can
be
on
a
system
is
just
a
couple
of
days
and
then
we
also
do
things
like
automatically
rotating
credentials
and
certificates
on
a
scheduled
basis.
A
And
so
we
call
this
kind
of
the
the
three
hours
of
security,
rotate
repair
and
repave.
So
if
you're
using
Cloud
Foundry
today,
you
kind
of
get
all
of
these
things
and
it
helps
you
have
a
secure,
a
more
secure
system,
but
most
people
don't
have
Cloud
Foundry
and
the
people
that
do
have
Cloud
Foundry
also
have
a
lot
of
other
infrastructure.
That's
not
managed
by
Cloud
Foundry
and
I'm,
not
gonna.
A
Tell
you
to
go
and
route
right
right,
bush
releases
and
start
running
everything
through
Bush
yourselves,
because
that
would
be
like
that's
a
very
large
hammer
and
it's
not
really
something
that
you
would
necessarily
need
to
do.
And
you
already
have
probably
some
sort
of
automation
tooling
in
your
system,
like
that,
you
use
in
your
operation
system
so
like
share
for
puppet
or
ansible
terraform,
so
you
can
like
use
those
and
add
onto
those
to
start
bringing
some
of
the
secure
and
compliant
stuff.
A
So
we'll
talk
about
some
of
the
practical
steps
you
can
take,
no
matter
where
or
like
what
sort
of
infrastructure
you're
using,
and
we
do
that
by
applying
comms
to
our
security
or
as
I'm
going
to
be
specifically
talking
about
compliance,
so
culture
is
kind
of
a
hard
thing
right.
It's
at
large
companies
like
the
culture
of
the
company,
is
what
it
is,
and
it's
very
difficult
as
a
practitioner
to
try
and
change
it.
A
But
when
you
have
a
good
culture,
sorry,
so
the
thing
we
have
with
large
companies,
any
kind
of
companies
is
like
behavior
is
what
basically
sets
your
culture
and
behavior
is
driven
by
incentives
and
those
incentives
are
set
by
like
the
executives
at
your
company.
So
it
really
needs
to
be
like
to
really
change
your
culture.
A
Individual
teams
can
have
cultural
elements
that
are
much
better
than
the
larger
company,
but
they're
really
driven
by
members
of
that
team,
and
if
those
members
of
that
team
leave
or
something
happens,
that,
like
better
culture
bubble,
that
you've
built
goes
away
quite
quickly.
So
it's
really
important
to
try
and
get
your
company
to
like
focus
on
like
a
larger
cultural
shift.
If
you
don't
have
a
very
strong
culture,
that's
not
amenable
to
like
the
comms
type
framework.
A
So
when
you
do
have
a
devops
culture,
you
create
high
performance
teams.
High
performance
teams
have
clear
and
effective
decision-making
methods,
engage
leadership,
high
trust
and
clear
communications.
They
accept
failure
and
they
embrace
failure
and
they
adopt
things
like
blameless.
Post-Mortems
I
think
you
vote
on
amita
teams
and
their
members,
and
this
all
helps
create
these
high
performance
teams,
where
everyone
is
taking
ownership
and
responsibility
for
the
business
goals
right
and
there's
some
really
good
information
about
adopting
a
DevOps
culture
and
there's
the
book
accelerate
by
dr.
A
Nicole,
fours,
groom
and
some
other
folks,
and
they
also
do
the
DevOps.
The
yearly
DevOps
report
there's
a
lot
of
amazing
information
there
about
how
companies
are
making
a
culture
change
and
how
they're
adopting
DevOps
type
things,
and
also
how
they're
failing
to
adopt
DevOps,
which
is
also
often
the
more
important
information
right.
A
You
have
lean
so
right
before
you
start
any
journey,
you
have
to
have
a
map,
and
this
is
the
the
map
of
the
flat
earth,
because
I
think
we're
all
agreeing.
We
have
a
flat
earth
right
j-j-joey.
You
agree
yes
great!
So
if
you
want
to
measure
success,
you
kind
of
need
to
know
where
you
are
and
where
you
want
to
go
and
so
like
from
a
compliance
perspective.
A
How
are
you
currently
implementing
compliance
and
like
where,
in
your
business,
even
implementing
compliance-
and
you
can
use
this
thing-
called
value
stream
mapping
which
is
kind
of
inside
the
Lean
framework
to
create
these
maps?
He's
going
to
take
a
few
days
to
like
map
out
your
entire
process
and
your
current
state?
And
then
you
kind
of
look
at
that,
and
it
becomes
pretty
obvious
where,
like
your
waste,
is
where
your
bottlenecks
are.
A
And
then
you
start
to
rebuild
like
what
you
want,
your
ideal
state
to
be,
and
so
you
basically
have
your
existing
state
and
you
have
your
ideal
state
and
then
you
can
start
mapping
out
what
it
is.
You
need
to
do
to
get
from
one
to
the
other
and
you
can
do
that
in
depending
on
the
size
of
the
processes
you're
trying
to
map
out
from
from
a
couple
of
days
to
like
a
week
or
two,
it's
a
very
large
IT
or
with
very
complicated
like
server,
provisioning
and
stuff.
A
So
in
my
experience
we
have
kind
of
a
few
places
we
can
attack
wasted
time
and
security
and
compliance
when
you're
actually
like
provisioning
infrastructure.
Well,
it's
actually
like
when
you're
writing
software
over
here
I
didn't
I.
Didn't
increase
include
that
there's
when
you're
writing
software
there's
when
you're
provisioning
infrastructure
there's
when
you're
actually
releasing
software.
A
A
Do
the
same
thing
again:
now
we
had
a
couple
of
thousand
servers,
and
so
that
took
a
lot
of
time,
and
so
by
the
time
they
got
through
them
all,
they
would
just
have
to
go
back
to
the
first
server
and
start
again
and
it'd
probably
be
an
extra
couple
of
hundred
servers
that
had
been
provisioned
in
the
meantime.
So
we
had
there
was
like
three
or
four
full
time:
people
that
were
just
doing
this
job,
and
so
that
was
a
lot
of.
A
There
was
a
lot
of
wasted
tile,
a
lot
of
wasted
human
capital
and
coming
from
a
DevOps
background,
where
I
had
been
doing
where
I
had
been
doing
a
lot
of
work,
around
automating,
away,
wasted,
labor
and
toil
no.
This
was
like
this
is
cool.
This
is
a
problem.
I
want
to
help
solve,
and
so
I
really
dug
in
with
them
and
I
introduced
them
to
a
couple
of
things.
A
So,
first
of
all,
we
were
already
using
ansible
on
the
infrastructure
side,
the
devops
side,
to
build
out
our
servers
to
install
our
software
and
to
make
sure
like
what
we
wanted
was
what
was
in
place
on
our
servers.
So
I
said:
let's
have
a
look
at
this
antal
hardening
thing,
which
is
a
set
of
playbooks
that
were
originally
developed
at
Rackspace
for
deploying
secure,
OpenStack
installs
and
it
basically
went
through
and
implemented
the
stinking
so
that
control
I
showed
you
earlier.
A
It
implemented
all
of
those
into
ansible,
so
you
can
have
even
more
or
less
run
this
against
any
modern
linux
system,
and
it
will
basically
make
sure
that
that
system
is
compliant
with
stink
and
so
I
said
this
is
really
great.
And
while
we
we
have
our
own
internal
compliance,
we
don't
necessarily
follow
stig,
there's,
probably
about
95%
of
it
will
match
right
and
so
let's
implement
this,
and
then
we
can
dig
into
it
and
see
what's
different,
and
so
we
did
that,
and
so
I
said.
A
A
A
I'm
like
how
about
I
take
I,
take
on
the
the
anti-bullying
and
I
get
that
working
sorry,
how
about
I,
implement
the
listing
so
the
testing
and
make
sure
that
our
systems
are
compliant
and
testing
and
while
I'm
doing
that,
you
guys
take
the
the
anti-bullying
and
validate
it
on
some
on
some
of
our
test
systems
and
make
sure
it's
not
going
to
break
anything
right
because
any
times
it's
the
changing
settings
on
a
system.
You
need
to
make
sure
you're
not
breaking
anything
important.
A
So
we
did
that,
and
it
only
took
me
about
a
week
to
get
the
testing
to
all
of
our
infrastructure
and
it
took
a
little
bit
longer
for
the
security
team
to
do
it.
So
again,
that's
this
destice
day
you
saying
SSH
needs
to
be
version
2.
This
is
what
the
inspect
control
looks
like
so
really
simple,
some
tags
and
stuff.
But
this
is
the
important
bit.
A
We
were
monitoring
for
it,
we
were
logging
for
it,
and
then
we
implemented
the
antipas
side
of
things.
So
now
we're
making
sure
when
we're
building
servers,
they
are
compliant,
and
so
that
was
kind
of
getting
the
basic
compliance
into
our
Linux
systems
and
it
worked
really
well
and
actually
how
we
knew
it
worked
really
well
with
security
and
compliance
team
on
their
own
added
this
to
our
CI
infrastructure.
A
We
were
able
to
measure
it,
and
so
the
easiest
measurement
was
how
much
wasted
time
are
we
saving,
and
that
was
like
four
people's
worth,
and
so
they
were
able
to
go
to
the
their
management
and
say:
we've
now
saved
tens
of
thousands
of
dollars
on
labor
and
we're
actually
more
effective
at
what
we
were
doing,
and
so
that
was
really
great
gave
them
a
lot
of
trust
in
the
org
and
I
am
out
of
time.
So
sure
enough,
be
nice
to
share
and
there's
a
ton
of
other
stuff
that
you
can
automate
like.
A
I
did
with
compliance.
I've
got
some
stuff
there,
but
basically
almost
any
security
team
tool,
you're
using
you'll,
be
able
to
automate
and
put
into
your
continuous
integration
pipeline,
and
we
are
way
out
of
time.
So
we
probably
don't
have
time
for
questions,
but
I'll
be
hanging
around
in
the
hall
later.
So
thank
you.