►
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Change is Hard - Securing the Future Today- Andrew Clay Shafer, Red Hat
The future of security is here now, but isn't evenly distributed. Change is inevitable, but resistance to change may be even more inevitable. What can we do to help organizations overcome the resistance to improve? The social engineering to solve is at least as hard as the technical challenges. This presentation will mix research and anecdote to discuss security as a socio-technical system recognizing the agency of the humans involved in addition to the technology advances that are driving the state of the art to solve security problems more holistically from first principles.
A
This
is
just
a
picture
of
my
peak
pandemic
beard.
This
has
been
shaved
and
you
can
see
we're
almost
back
to
that
and
and
just
to
kind
of
put
this
out
there.
If
anyone
wants
to
get
a
hold
of
me,
linkedin
or
twitter,
that's
probably
the
fastest
way,
and
I
come
in
various
configurations
of
hair
and
beard
and
if
you
see
me
anywhere
else
in,
I
might
look
very
different
than
I
do
right
now.
So
with
that
being
said,
I
would
claim
no
expertise
in
security.
A
I've
been
involved
in
lots
of
things
where
security
was
a
consideration,
but
it's
never
been
my
job.
My
responsibility,
my
name
on
the
line
for
security,
so
take
everything.
I
say
with
that
as
a
context.
What
I
would
consider
myself
is
an
aspiring
pattern.
Matcher
and
puzzle.
Solver
and
security
has
been
a
goal
and
a
constraint,
but
it's
never
been
exactly
the
thing
that
I
was
100
focus
on.
So
with
that,
I'm
not
going
to
talk
about
all
the
buzzwords
of
the
day.
The
buzzwords
you
know
them,
there's
lots
of
other
talks
about
them.
A
Some
of
you
are
probably
working
on
them.
I
would
hope
most
people
listening
to
this
know
more
things
or
know
more
about
these
things
than
I
do.
But
that
being
said,
I'm
not
not
talking
about
those
things
either.
What
I'm
really
going
to
focus
on
is
kind
of
the
dynamics
of
how
organizations
change
their
behavior.
So
there's
a
couple
things
that
I
think
are
really
not
changed
here
in
the
sense
that
the
the
basics
are
essentially.
A
Is
there
an
identity
that
we
can
authenticate
against
and
then
once
we
have,
those
identities
authenticated?
Is
that
identity
authorized
to
do
whatever
they're
trying
to
do
so?
You
have
this
kind
of
who?
What,
when
thing
that
you
both
want
to
be
able
to
enforce,
and
then
also
record-
and
this
has
not
really
changed,
like
the
fundamentals
of
some
of
this
stuff,
in
my
opinion-
isn't
fundamentally
changing.
A
So
this
is
something
that
I
think
is
very
exciting
about
the
way
a
lot
of
these
tools
are
emerging
is
we're
getting
into
this
world
where,
instead
of
the
the
theatrics
of
inspection,
we
can
move
into
some
hope
of
a
future
where
everything
is
is
verified
by
by
cryptographic,
identity
and
policies
enforced
based
on
that
identity,
instead
of
the
sort
of
theatrics
that
seem
to
dominate
what
most
people
do
for
security
today.
So
this
is
this
notion
of
continuous.
A
A
You
also
have
these
legacy
cultures
and
I'm
going
to
introduce
an
idea
here
which
isn't
isn't
something
I'm
making
up,
but
there's
this
notion
of
a
socio-technical
system.
It's
not
technology
alone
that
solves
these
problems
that
develops
or
delivers
the
imp
applications
the
infrastructure
of
the
security.
It's
that
socio-technical
system.
That
does
so
so
you
have
to
address
that
so
too
long
gonna
read!
This
talk
is
basically
the
change
is
hard.
A
That's
the
title
that
the
point
I've
already
started
to
make
that
security
is
qualitative,
it's
not
a
condition:
you're,
not
secure
or
insecure,
but
but
there's
qualities
that
are
more
secure
and
less
secure.
Those
are
qualities
of
a
socio-technical
system.
You
have
to
treat
that
system
as
as
a
single
thing,
if
you
think
about
it,
purely
as
technical
problem
or
purely
as
a
cultural
problem.
A
You
run
into
these
things
where
it's
very
difficult
to
to
to
change
or
move
past
where
you
get
stuck,
and
then
this
is
sort
of
the
new
kind
of
ideas
I'm
going
to
hopefully
introduce
that
you'll
find
interesting
and
insightful.
Is
this
notion
of
collective
interest
and
selfish
interest
and
how
those
come
together,
and
then
this
is
something
I
like
to
say,
and
sometimes
I
say
it
with
swear
words,
but
broken
things
tend
to
get
fixed,
but
things
are
merely
bad
can
can
often
live
forever.
So
you
want
to
change
the
world.
A
We
we
all
want
to
change
the
world.
This
is
a
exciting
time.
We
see
all
the
advancements
in
technology
some.
Sometimes
we
get
to
make
some
of
those,
and
I
just
want
to
remind
you
of
some
of
the
some
of
the
ideas
from
the
past
on
this
topic.
So
this
is
machiavelli,
who
some
of
you
might
have
heard
of,
and
maybe
one
day
I'll
give
a
talk.
A
So
the
the
simple
version
of
this
is
that
science
advances
one
funeral
at
a
time.
There's
another
dynamic,
which
I
want
to
point
out
which
used
to
frustrate
me
in
a
lot
of
the
work.
I
was
trying
to
do
getting
people
to
kind
of
adopt
these
new
ways
of
working
and
do
things
in
a
better
way.
Is
that
you
you
have
this
thing
that
we're
kind
of
a
part
of
innovating.
A
You
see
this
in
sort
of
the
state
of
devos
reports,
some
of
these
other
things
with
with
automation,
and
then
you
get
into
this
early
majority
late
majority
and
you
start
to
see
this
phenomenon
where
people
don't
actually
adopt
the
real
practices
or,
in
some
cases,
even
the
real
tools.
But
they
start
using
all
the
words
and
they
start
changing
all
the
titles,
and
this
is
this
is
studied
as
a
phenomena
which
we
don't
have
time
to
get
into
all
the
research
here.
A
But
what
ends
up
happening
as
you
kind
of
cross
the
chasm
and
come
into
the
majority,
is
that
these
organizations
are
not
actually
seeking
an
advantage.
They're
seeking
legitimacy
and
the
legitimacy
is
because
there's
other
people
who
got
the
advantage,
but
they're
not
they're,
not
seeking
that
they're
just
seeking
the
words
and
that
that's
enough
for
them.
They'll
they'll
just
take
those
titles
and
now
they're,
sres
or
whatever,
even
though
they
change
nothing.
So
where
were
we?
A
This
is
a
blog
post
from
legacy
andrew
in
2010
about
what
devops
meant
to
me
at
the
time.
Developers
and
operators
can
should
work
together.
System
administration
is
evolving,
look
more
like
software
development,
and
it's
this
is
this
is
last
but
not
least,
in
some
ways.
Most
important
is
that
this
is
evolving
together
as
a
global
community
sharing
solutions,
and
I
think
that's
the
most
exciting
thing
I
think
that's
also
happening
with
with
cloud
native
and
and
for
all
intents
and
purposes
I
feel
like
these
are
a
continuation
of
similar
things
right.
A
So
this
is
my
definition
of
devops.
I've
used
in
many
conference
talks
that
it's
optimizing,
the
human
human
experience
and
performance
of
operating
software
with
software
and
with
humans,
which
is
important
in
a
minute
and
just
a
piece,
completely
buzzword
compliant.
You
know
continuously
devops
micro
serverless,
we'll
check
a
lot
of
boxes
for
the
day
so
related
to
this
definition
that
I
use
for
devops.
Is
this
theme
about
software's
eating
the
world
right
like
that,
is
essentially
arguing
that
software
is
optimizing
everything
it
can
optimizing.
A
Human
performance
and
experience
and
and
devops
is
really
just
an
extension
of
that
cloud
native
is,
is
a
you
know,
another
level
extension
of
that
and
what
we're
seeing
and
what
I
would
think
a
lot
of
this
community
is
about
is
that
software
is
actually
eating
software
right.
So
we're
seeing
this
sort
of
software
software
platformification.
A
A
So
we
have
this.
This
situation,
people
always
say
software's
in
the
world.
I
don't
think
that's
entirely
true.
I
think
there's
a
lot
of
other
infrastructure
and
circumstances
support
that.
So
we
live
in
this
time,
I'm
speaking
to
you
through
the
internet,
super
computers
everywhere
connecting
all
human
knowledge
with
high-speed
networks,
but
it's
also
connecting
all
that
to
the
adversaries-
and
I
said
this
as
my
part
of
my
definition
coming
back
to
it.
Every
aspect
of
human
performance
and
experience
that
can
be
optimized
will
be
including
owning
you.
A
So
with
that
in
mind,
you
know
devsec
ops,
just
to
kind
of
rub
the
same
pattern
on
it
and
I'll
say
this
now.
I've
said
it
before
and
we'll
surprise
it
again.
Devsecops
is
another
buzzword
of
the
day,
and
it's
really
adding
that
that
considers
a
consideration
of
security
as
a
first
class
part
of
the
equation,
so
security
is
involved
to
include
and
is
included
in
software
development.
A
So
the
software
of
security
is
looking
more
like
more
like
software
development,
like
with
the
life
cycle
of
software
development,
and
it
needs
to
be
included
in
the
rest
of
the
software
development
life
cycle
and
then
here's
the
exciting
part
that
we're
part
of
right
now.
Like
I
said
I
wish
I
was
together
with
you,
and
we
could
do
this
a
little
bit
more
personally
but
reach
out
to
me.
This
is
a
global
community
sharing
solutions.
A
So
this
is
a
very
famous
quote
from
2006.,
I'm
just
throwing
in
the
middle
of
this,
because
I
think
I
think
it's
relevant
to
some
of
the
some
of
the
themes
and
what
we're
struggling
with
in
a
lot
of
these
organizations
and-
and
I'm
not
gonna,
read
the
whole
thing
today,
but
you
can,
you
can
read
it
and
I'll
you
know
slides
will
be
available,
but
verner
vogels
2006,
you
build
it.
You
run
it.
People
say
that
all
the
time
they
pull
that
all
the
time.
A
Okay,
that's
cool,
but
who,
who
who's
actually
gonna
secure
it
yeah.
That's,
might
be
a
little
bit
of
a
problem
and
if
you
look
at
the
big
picture
of
what
verner's
talking
about
and
what
was
it
at
amazon
at
that
time,
in
2006
burner
doesn't
mean
that
these
developers
are
going
to
provision
bare
metal.
You
know
get
everything
racked
and
stacked,
install
operating
systems,
install
libraries
install
and
manage
databases.
That's
not
what
he
means
at
all.
A
What
he
really
needs
is
really
that
team
of
software
developers
manages
this
this
top
layer,
so
I'm
going
to
go
back
through.
This
is
kind
of
like
a
reprisal
of
some
classic
devops
conversations
and
this
notion
of
traditional
I.t
being
a
wall
of
confusion
between
developers
and
operators,
and
then
I'm
also
going
to
introduce
some
some
research
from
my
colleague
javed
in
a
minute.
So
these
are
two
different
games,
so
you
can
kind
of
think
of
devenops
as
trying
to
win
two
slightly
different
games.
A
A
A
A
So
this
this
traditional
framing
with
the
wall
of
confusion
between
us
sort
of
sets,
these
two
forces
against
each
other,
but
now
we're
adding
another
consideration
right.
So,
if
we're
going
to
consider
security,
then
we
have
in
a
lot
of
cases
a
lot
of
organizations
added
a
new,
a
new
wall
of
confusion
right,
so
you
have
these
traditional
forces
developers,
don't
necessarily
understand
security
security
doesn't
understand
operations
there's
in
in
some
organizations.
A
A
But,
for
the
sake
of
the
argument,
I
we're
gonna
we're
gonna
go
with
it,
so
these
walls
are
there
because
we
don't
understand
the
other
games
that
these
these
other.
These
are
people,
we're
all
people,
and
we
don't
understand
that
they're
connected
together
that
there's
there's
really
like
one
organizational
game.
There's
one
collective
that
we
that
we're
serving
so
is
there
a
way
to
win
all
of
these
games
together.
A
There's
a
new
way
and
I'm
gonna
start
with
this
academic
framing,
hopefully
get
more
and
more
concrete
and
and
hopefully,
more
and
more
relevant.
So
this
new
game-
and
this
is
this-
is
from
james
language-
is
this
this
scope
economy,
so
it
acts
a
bit
like
a
clutch
or
kind
of
like
a
fulcrum
that
balances
the
differentiation
in
the
scale
economy,
to
enable
innovation
and
efficiency
and
security
and
the
scope
economy
in
the
in
the
best
cases
of
this
results
from
these
ongoing
negotiations
recognizing
the
selfish
interests
in
favor
of
the
collective
interests.
A
So
getting
more
and
more
concrete,
you
have,
if
you've
optimized
everything
for
innovation
and
you
allow
every
single
team
to
make
all
the
choices
they
want.
You
end
up
with
a
lot
of
different,
different
and
varied
ways
to
do
pipelines
to
do
you
know
the
object
mall
to
do
the
databases
to
do
whatever
and
that
that
is
great
for
the
innovation,
but
you've
created
all
this
downstream
operational
burden
for
the
organization
and
you've
created
this
like
very
broad
and
widening
attack
surface
from
a
security
perspective.
A
So
it
might
be
more
valuable
to
look
at
those
patterns
that
were
innovative
and
look
at
the
commonalities
that
might
be
reused
across
the
organization
and
bring
those
into
this
central
platform
to
be
reused
by
everyone.
And
then,
conversely,
you
also
see
this
in
especially
in
in
heavily
regulated
organizations
where
the
resources
are
overly
restricted
and
as
a
consequence
of
that
restriction,
you're,
not
really
getting
innovation
and
so
figuring
out
kind
of
based
on
the
risk
and
and
the
the
you
know,
the
policies
that
you
can
enforce
with
the
platform.
A
A
These
platforms
has
built
these
platforms
is
building
and
extending
these
platforms
because
they
have
to
you,
can't
you
can't
get
to
the
scale
and
keep
the
promises
that
you
need
to
keep
if
you're
doing
everything
with
this
artisanal
you
know
hand,
hand,
automation
and
security
approach,
so
this
is
from
the
sre
book.
This
is
the
google
way,
I'm
not
going
to
read
the
whole
thing,
but
I'm
just
going
to
read
this
this
bottom
part,
so
development
teams
can
focus
on
the
business
logic,
because
the
framework
already
takes
care
of
correct
infrastructure
use.
A
This
is
google
explaining
in
in
some
degree
how
they
built
their
shared
platform.
That's
straight
from
the
sr.
Ebook
borg
is
a
scope
economy.
Construct
kubernetes
is
a
scope
economy
construct
yay.
I
also
think
it's
interesting
to
think
about.
Kubernetes
is
an
open
source
global
commons
to
build
a
local
shared
platform.
Commons
and
then
establishing
an
slo
is
a
calming
exercise
between
sres
and
software
engineers.
So
what
is
the
equivalent
negotiation
for
securability?
A
What
is
securability?
What
are
the
principles
of
securability?
I'm
not
sure
either
right.
I
never
said
I
know
a
security.
Even
is
it's
never
been
my
job,
but
I
I
do
know
a
thing
about
reliability,
and
this
is
one
of
my
favorite
characters
in
that
narrative
shout
out
to
joe
armstrong
rest
in
peace
and
erlang,
and
this
is
the
six
laws
of
reliability.
A
And
I'm
not
saying
this
is
the
rel
the
laws
of
secure
ability,
but
it's
not
a
bad
place
to
start
isolation,
concurrency
failure,
detection
fall
determination,
live
code,
upgrade
and
stable
storage
go
look
into
some
of
his
work
and
some
of
his
talks
on
these
topics,
and
then
this
is
me
being
silly
on
twitter.
Any
sufficiently
complicated.
A
This
is
this:
is
the
chapters
from
the
sre
book
that
I
recommend
everyone
read
no
matter
what
your
job
is:
security
operations,
development,
whatever
embracing
risk,
limiting
toil
most
of
those
ideas,
would
translate
into
any
domain
and
be
a
collective
concern,
and
then
what
would
it
mean
to
have
a
security
level
objective?
And
how
would
you
measure
that?
And
I'm
not
sure
I
have
the
answers,
but
I
I
really
like
thinking
about
this
and
and
measuring
this
and
being
in
a
position
to
to
help
organizations
make
progress.
So
this
is
the
the
same.
Exact
quote.
A
The
only
thing
I
really
changed
here
was
the
word
security.
So
just
to
kind
of
read
the
same
thing
again:
development
teams
can
focus
on
the
business
logic,
because
the
framework
already
takes
care
of
security
considerations.
That's
the
holy
grail
to
me,
so
this
platform
that
we're
building
whatever
it
is
for
your
organization
has
to
continuously
and
automatically
audit
and
enforce
policy,
because
the
old
style
of
security
and
inspection
and
theatrics
cannot
keep
up
with
this
micro
service
world
we're
moving
into
so
how's
that
platform
get
implemented.
A
Well,
it's
this
notion
of
commenting
and
bringing
all
these
selfish
interests
that
we
all
have
into
that
platform
into
that
manifestation
of
our
organizational
needs.
Risks
need
for
innovation,
need
for
efficiency
and
building
the
right
thing.
If
you
get
too
far
in
one
direction
you
get
out
of
balance,
it
doesn't
really
work
right.
A
So
if
developers
are
running
everything
then
you're
creating
a
lot
of
operational
burden
if
operators
are
stopping
everything
or
security,
stopping
everything
you're,
not
really
innovating,
so
finding
that
balancing
point
by
getting
those
selfish
interests
to
negotiate
with
each
other
in
favor
of
the
collective
interest.
So
this
is
the
holy
grail
we
want
to
get
to
developers
can
do
everything
to
create
novelty,
to
create
innovation.
A
A
Believe
me,
I
know,
and
I'm
sure
some
of
you
know
when
you
hear
this
all
the
time
you
know
the
culture
is
the
hard
thing,
but
but
it's
it's
yeah,
it's
hard.
So
security
is
also
never
done.
That's
another
thing.
This
is
an
ongoing
negotiation.
Sometimes
I
hear
people
say
this.
I
I
frequently
hear
people
say
this,
which
is
like
good
luck.
Good
luck
with
that,
so
just
keep
in
mind.
Resistance
to
change
might
be
the
only
thing
more
inevitable
than
change,
and
there's
this
there's
this
dynamic.
A
You
know
where
we
don't
want
to
forget
how
we
do
things
here.
That's
what
we
are.
This
is
how
we
do
things
and
going
back
to
this,
that
I
introduced
you
to
earlier.
My
advice
to
you
is
to
seek
advantage
always
be
seeking
the
advantage
so
coming
to
the
end
conclusion.
This
is
not
a
technical
problem.
A
This
security
is
not
a
people
problem.
Security
is
a
socio-technical
system
and
you
have
to
solve
both
of
these
together.
I
don't
have
time
to
learn
new
things,
because
I'm
too
busy
getting
things
done.
That's
a
very
famous
quote
by
the
least
productive
person
in
the
world,
and
with
that.
Thank
you.
I'm
not
here
to
answer
questions
I'm
here
to
have
conversations.