►
Description
Exit Stage Left: Replacing Theater with Chaos - Kelly Shortridge, Capsule8
Kelly will explore how security theater leads to increased organizational friction, especially in the realm of software delivery, rather than promoting safety. She'll contrast these dramatics with a security chaos engineering approach – one which embraces the importance of convenience, alignment with organizational goals, and the wisdom derived from failure.
A
Welcome
to
exit
stage
left,
replacing
theater
with
chaos,
I'm
kelly
shortridge,
I'm
the
product
management
and
product
strategy
at
capsley,
just
startup
based
in
new
york
city,
that
provides
infrastructure,
monitoring
and
protection
for
production
systems.
My
spare
time,
and
maybe
how
you
know
me
already.
I
researched
the
intersection
of
information,
security
and
behavioral
economics.
A
A
So
what
can
we
do
to
remove
the
drama
and
the
pain
from
security
theater
and
actually
start
delivering
safe
software
and
systems?
This
talk
will
explore
one
way
to
start
so
in
act
one.
We
will
welcome
you
to
the
security
theater
and
act,
two
we'll
explore
the
fisticuffs
between
security,
theater
and
security
chaos
engineering,
so
that
act.
One
welcome
to
security
theater
to
spoof,
the
classic
song,
welcome
to
the
theater,
to
the
magic
to
the
fun
where
snake
oil
tools
and
roadblocks
grow
and
blaming
rings
fortissimo.
A
So
what
do
we
actually
mean
by
security
theater,
similar
to
the
origins
terms
and
physical
security?
Security?
Theater
involves
any
effort
towards
producing
the
perception
of
improved
security.
Unfortunately,
creating
the
perception
of
improved
security
is
often
at
odds
with
actually
creating
meaningful
and
valuable
security
outcomes.
The
end
result
is
that
you
produce
a
whole
lot
of
drama.
You
have
historic
theatrics
about
enough
for
the
entire
audience
to
hear
security.
Theater
is
also
particularly
obsessed
with
bad
apples
which
are
referring
to
humans,
who
do
something
malicious
or
accidentally.
A
So,
as
bogna
said,
there
might
be
someone
who
can't
be
trusted,
the
strategy
seems
to
be
preventative
control
on
everybody
instead
of
damage
control
on
those
few,
the
philosophy
basically
sucks
for
everyone,
but
the
actors
on
the
security
theater
stage
in
infosec.
This
is
why
we
often
see
the
department
of
no
they
say
no
to
all
requests.
Just
in
case
someone
is
a
bad
apple,
and
this
is
in
part,
what
fuels
the
high
conflict
relationship
we
see,
often
between
infosec
and
engineering.
A
Now,
if
you
think
about
things
like
shift
left
right,
the
goal
is
really
like
for
a
developer
and
architect
on
each
team
to
understand
things
like
threat
modeling
to
help
build
systems
more
securely
by
design,
but
instead
what
we
see
with
something
like
shifting
left
is
catch,
the
os
top
10
or
whatever
else
our
tools
say,
is
important
during
the
build
phase,
rather
than
the
deployment
phase.
There's,
maybe
a
kind
of
benefit
to
shifting
that
friction
earlier,
but
to
be
real,
it's
minimal
and
it
certainly
isn't
fulfilling
the
stated
goal.
A
Relatedly,
even
though
I
still
think
the
buzzword
is
useless
at
best
sec,
ops
kind
of
marches
onto
the
stage
and
says
I'm
not
a
regular
security
theater,
I'm
a
cool
security
theater
in
an
ideal
world
deficit
op
should
be
about
similarly
unifying
accountability
and
responsibility
in
the
realm
of
security.
Just
as
dev
and
ops
was
the
unification
of
responsibility
and
accountability
around
operations.
A
A
A
So
when
you
see
devsecops,
it's
like
devops
is
like
a
building.
Then
security
is
smashing
through
the
building
like
it's
the
kool-aid
man,
and
why
stop
at
devsecops?
Why
not
devsec
test
stops?
Why
not
devsec
tests
and
dba
ops
right
we're
actually
delivering
secure
software?
Then
it's
a
seamless
part
of
devops
processes
and
its
insertion
into
the
buzzword
is
totally
extraneous.
A
I
actually
discussed
this
in
a
recent
blog
post
about
yoga
sec
versus
fomo
sec.
I
recommend
you
all
checking
out,
but
fomosar
can
be
thought
of
security
security
strategy,
that's
driven
by
fear
of
missing
out
and
all
of
the
related
thought
patterns
around
it.
So
it
gains
the
spotlight
and
fomo
seconds
escaping
the
feeling
of
inadequacy.
A
You
want
to
regain
a
sense
that
security
is
in
control
and
it
isn't
irrelevant,
even
if
that's
at
the
expense
of
security
outcomes
what's
interesting
is
envy
is
actually
at
the
heart
of
fomo
security
and
for
the
context
of
this
talk,
the
most
relevant
target
of
infosex
envy
is
actually
software
engineers,
so
devon
ops
actually
possess
meaningful
goals
and
that
are
part
of
meaningful
work,
all
of
which
is
measurable
and
allows
them
to
somewhat
answer
the
question
of.
Like.
A
A
Ironically,
though,
infosec's
homosexual
and
lust
for
the
idea
of
being
treated
equally
to
devon,
ops
at
the
big
kids
business
table
makes
it
lose
sight
of
organizational
priorities.
It's
so
intense
on
maintaining
control
and
feeling
important
that
it
actually
architects
sub-optimal
strategy
that
keeps
it
from
earning
its
seat
at
the
table.
A
Bombos
sex
histrionics
around
desperately
desiring
feeling
control,
make
infosec.
Quite
like
someone
who's
like
statically
gripping
a
wheel.
Even
the
wheel
isn't
attached
to
anything
and
all
that
fake
steering
maybe
makes
you
feel
like
you're
doing
something
but
you're
actually
staying
stagnant
and,
if
you're
staying
stagnant,
there's
no
way
you're,
actually
promoting
safety
or
security
in
your
systems,
as
shown
in
dr
nicole
forsgren's
state
of
devops
research,
the
elite
organizations
who
have
the
fastest
deploy
frequency
and
shortest
lead
time
for
changes
also
actually
exhibit
the
lowest
change.
Failure
rates
and
shortest
time
to
restore
service.
A
In
fact,
like
the
organizations
that
have
the
most
restrictions
in
place
and
which
are,
in
theory
like
the
most
careful
aren't
actually
the
ones
that
are
most
stable
because
they
experience
the
highest
change
failure
rates.
So
these,
seemingly
you
know
careful
and
cautious
organizations
actually
see
46
to
60
percent
of
their
deployed
changes,
result
in
either
degraded
service
or
something
that
requires
subsequent
remediation.
A
A
For
instance,
if
there's
a
nasty
like
remote
code,
execution,
vulnerability
and
a
library,
that's
critical
for
one
of
your
product
production
systems,
you
want
to
fix
that
quickly
right.
So
a
heavy
and
inconvenient
change
management
process
will
actually
make
it
harder
to
deploy
a
patch,
which
means
your
production
systems
will
languish
with
both
security
and
stability
at
risk.
But
if
your
process
is
speedy,
you
can
push
out
patches
and
fixes
and
other
sorts
of
enhancements,
much
faster,
which
allows
for
continuous
improvement
of
your
system.
A
Stability
and
security
instead,
ultimately
like
a
fortress
of
approvals
and
red
tape
and
nebulous
policy,
doesn't
help
your
security
program
as
much
as
ensuring
that
you
can
adapt
your
security
program.
As
your
system's
environments
evolve,
you
can
test
and
fix
things
quickly
and
easily.
You
can
actually
actually
bolster
security
far
more
than
any
sort
of
like
extra
strict
okay,
so
we
can
probably
agree
security.
Theater
is
like
not
a
great
time.
So
how
do
we
spot
security,
theaters
red
flags
and
is
there
a
better
way
ahead?
A
Yes,
there
is.
This
brings
us
to
act,
two
which
is
theater
and
chaos
and
fisticuffs.
So
there's
conflict
born
from
how
we
should
treat
security
failure
and
where
accountability
for
security
rests.
On
one
side
we
have
security
theater
and
on
the
other,
there
stands
security,
chaos,
engineering,
we're
exploring
these
tensions.
Presently,
the
tldr
on
security,
cams
engineering
is
that
it
seeks
to
leverage
failure
as
a
learning
opportunity
and
as
a
chance
to
build
knowledge
of
systems
level
dynamics
towards
continuously
improving
systems.
A
Resilience,
I'm
actually
releasing
a
report
on
this
topic
with
my
co-author,
aaron
reinhardt
might
actually
be
out
by
the
time
this
airs
by
o'reilly
so
check
that
out.
If
you
want
a
deeper
dive
into
the
topic
again,
security
theaters
five
isn't
nearly
as
chill.
They
would
like
to
feel
absolutely
harsh
or
mellow.
So
the
security
team
that
acts
in
the
security
theater
troop
wants
to
avoid
failure
by
any
means
necessary
and
punishes
chosen
humans
involved
when
incidents
occur.
A
A
They
don't
expect
to
know
all
the
ways
things
can
fail,
so
they
instead
pursue
and
incentivize
feedback,
loops
and
experimentation
to
uncover
evidence
of
how
systems
behave.
Teams
who
adopt
security.
Theater,
though,
are
pretty
stubborn.
They
lament
that,
if
only
you
know,
humans
followed
all
of
the
infosec
laws
and
the
kingdom
perfectly
incidents
wouldn't
happen.
These
are
lazy
or
stupider
the
aforementioned
bad
apples,
so
they
deserve
to
be
ruled
with
sort
of
iron
fist.
A
Despite
the
fact
that
policies
are
never
going
to
be
globally
applied,
given
the
reality
of
context
nuance,
another
comparison
is
security
programs
following
security
chaos,
engineering
are
designed
to
minimize
the
impact
of
incidents
by
making
incident
recovery
as
efficient
and
graceful
as
possible.
So
teams
know
that
know
that
pointing
fingers
is
useless
and
that
conducting
experiments
to
power
feedback
loops
instead
is
incredibly
valuable.
A
Security
programs,
though,
that
are
following
a
security,
theater
approach,
use
technology
and
policy
to
eliminate
the
possibility
of
failure
if
they
can,
which
they
can't
and
allow
for
easier
blame
when
incidents
happen,
but
no
one
can
enumerate
all
possible
failure
in
any
sort
of
complex
system
and
keep
any
failure
from
happening
with
control.
So
you
know,
I
guess,
we'll
see.
A
Teams
pursuing
circadian
engineering
want
to
unify
accountability,
responsibility
by
handing
off
acceptance
of
risk
to
the
engineering
teams
that
are
actually
performing
work,
which
we
refer
to
as
localized
change
approvals.
So
the
security
team
instead
operates
as
an
advisor
sharing
knowledge
as
widely
as
possible.
In
the
o'reilly
report.
A
As
far
as
culture,
security
cast
engineering
is
all
about
a
culture
of
security
culture-
curiosity,
that's
always
down
for
like
a
healthy
retrospective
and
an
open
discussion
of
oofs.
Even
big
moves
and
teams
feel
super
safe,
coming
forward
about
security
issues,
because
they
know
they
won't
be
ridiculed
or
blamed,
and
also
they
know
that
problems
can
actually
be
solved.
Collaboratively
security.
Theater,
of
course,
is
the
opposite
because
of
its
fear
of
change.
A
They
welcome
audience
participation
and
challenging
assumptions
about
security
strategy,
because
it's
accepted
that
security
strategy
has
to
evolve
as
your
systems
and
your
environmental
context
involves
evolves,
but
security
teams
with
a
security
theater
approach
instead
are
a
stickler
for
rules
and
they
find
the
status
quo
very
comforting.
They
would
much
rather
copy-paste
policies
over
from
the
world
they're
familiar
with
to
this
new
scary
world,
which
is
why
you
see
things
like
container
firewalls,
which
don't
make
a
lot
of
sense.
A
So,
ultimately,
do
you
want
to
thrive
in
the
real
world?
Or
do
you
want
to
try
to
survive
in
security,
theater's,
fantasy
world,
but
security
chaos?
Engineering's
teams
are
ultimately
accepting
reality
and
especially
the
reality
that
security
just
isn't
the
most
important
priority
to
most
organizations.
A
It's
really
about
you
know,
building
a
custom
base
like
fueling
revenue,
growth,
improving
profitability
and
so
forth
with
security
theater.
It's
almost
like
teams
are
method,
acting
so
hard
that
they
start
to
believe
in
this
fantasyland
and
they
start
to
feel
that
security
actually
is
the
top
priority,
and
you
know
there's
this
elaborate
song
and
dance
required
to
fulfill
it.
It's
just
not
true,
so
those
who
actually
adopt
a
security
cast
engineering
approach
want
to
produce
meaningful
outcomes.
A
They
don't
care
about
doing
something
just
for
appearances
sake
again
going
back
to
that
blog
post
I
mentioned
on
yolo.
Second
fomosec
security
chaos.
Engineering
also
doesn't
encourage.
I
feel
like
caring
about
feeling
important
or
buying
the
latest
security
shiny,
just
because
everyone
else
is
doing
it.
That's
really
important.
A
The
other
thing
is
that
most
engineering
teams
already
understand
that
bugs
that
could
disrupt
performance
are
inevitable,
so
they
try
to
continually
test
and
refine
their
systems
to
get
the
results.
They
want
security.
Chaos
engineering
thinks
super.
Similarly
to
this,
which
means
that
it's
actually
aligning
to
how
developers
and
operators
already
operate
so
security
bugs
exist.
This
configurations
are
a
fact
of
life.
Keys
are
accidentally
going
to
be
pasted
into
code.
It's
quite
silly
to
think
that,
just
because
some
security
checks
passed
once
that
everything
is
perfect.
A
If
everyone
is
treated
like
a
bad
apple,
they're,
more
likely
to
hide
and
keep
secrets
which,
ironically,
actually
turns
the
innocence
into
bad
apples,
that's
terrible
instead
they're
going
to
now
start
covering
up
mistakes
and
they're
going
to
be
too
scared
or
resentful
to
actually
raise
concerns
which
totally
dismantles
your
feedback
loop
and
honestly.
It
also
erodes
the
security
team's
political
capital
which,
as
much
as
we
would
like
that
not
to
exist
it's
a
fact
of
most
like
organizational
realities,
and
so
without
this
feedback
loop.
A
How
can
you
actually
be
certain
that
your
security
program
is
working?
This
brings
us
to
scene
two
about
judgment
security.
Chaos.
Engineering
welcomes
objective
judgment,
whereas
security
theater
would
rather
bribe
the
judges
so
classic
a
red
flag
of
like
any
sort
of
security
theater
is
that
it's
nearly
impossible
to
directly
tie
costs
to
benefits,
there's
often
a
lot
of
hand
waving
and
purposely
vague
math
at
all.
A
So
it's
obvious,
but
you
either
want
to
prove
that
you've
avoided
a
monetary
loss
which
is
more
common
in
infosec
or
that
you're
helping
your
organization
make
more
money,
definitely
rare
in
infosec,
but
I
think
we
can
get
there
problem
is
this
calculation
also
needs
to
consider
the
effects
that
your
security
program
has
on
other
parts
of
the
organization
in
economics,
literature.
This
is
what's
referred
to
as
negative
externalities,
so
drawing
on
an
example
in
the
physical
security
domain.
A
One
study
by
blalock
and
their
colleagues
suggested
that
road
fatalities
actually
increased
as
a
result
of
airport
security
theater,
because
more
people
decided
to
try
rather
than
deal
with
all
of
that
pain
at
the
airport,
so
security
metrics
as
a
result
of
all
this
are
often
way
too
tone-deaf
to
what
the
rest
of
the
organization
is
doing.
No
one
cares
about
your
number
of
phishing
link
clicks.
Just
like
no
one
cares
about
line
of
code
written
on
the
engineering
side.
A
A
A
You
want
to
investigate
security's
impact
on
software
delivery
and
ensure
there
aren't
any
negative
consequences
to
the
policies
and
programs
you're
instituting,
because
otherwise
those
might
appear
like
security
improvements
when
they're,
actually
not,
as
is
likely
obvious
like
this,
is
going
to
require
collaboration
both
between
security
and
software
engineering.
The
mutual
benefits
are
right
for
the
picking,
as
is
explored
in
that
ireland
report.
I
mentioned
on
security,
cams
engineering.
A
A
So
again,
continuous
improvement
is
our
goal
for
systems
performance,
and
it
also
should
be
for
system
stability
as
well
and
security
chaos.
Engineering
is
the
path
to
get
there
plus
I
mean
we
constantly
hear
about
how
attackers
are
constantly
evolving
their
methods
and
they're
so
far
ahead.
So
shouldn't
our
defenders
and
our
defense
continually
be
evolving
too
makes
sense
right.
A
So
security
teams,
as
we
discuss
in
the
report,
can
be
freed
from
the
burden
of
heavy-handed
control
and
they
can
instead
become
advisors
allowing
them
to
focus
on
more
strategic
work.
Product
and
engineering
teams
are
actually
the
ones
that
start
to
accept
accountability
for
all
these
security
changes
and,
importantly,
cleaning
up
any
resulting
impact
of
these
changes,
which
makes
for
healthier
security
for
everyone.
A
So
I
hope
today,
all
of
you
are
very
motivated
to
close
the
curtain
on
security
theater
and
let
speed
and
stability
instead
flow
in
concert
through
the
security
chaos
engineering
approach.
I
always
like
to
close
with
a
quote
so
I'll
invoke
chuck
paul,
yuck,
classic
kind
of
monologue
tradition
at
the
theater.
People
don't
want
their
lives
fixed.
Nobody
wants
their
problem
solved,
their
dramas,
their
distractions,
their
stories
resolved
their
mess
is
cleaned
up,
because
what
would
they
have
left
just
a
big
scary,
unknown
again.
A
This
was
only
surface
dive
in
security,
gas
engineering,
which
we're
really
excited
about
so
check
out.
The
o'reilly
report
I
wrote
with
my
co-author
aaron
reinhart
it
is
available
for
free,
should
be
at
the
link
by
the
time
this
airs
so
download
and
dive
into
it
and
again,
hopefully
close
the
theater
at
close
the
curtain
on
security
theater
that,
thank
you
all
very
much.