►
From YouTube: CNCF Webinar Series - Cloud Native Security Panel
Description
While Cloud Native Applications open up many new possibilities they also bring new challenges. One of the most discussed challenges is security.
In this webinar, we were joined by a panel of industry experts and did a deep dive into all aspects of securing a cloud native application.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! 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.
A
All
right,
so
it
seems
the
number
of
participants
is
now
stabilizing,
so
we're
gonna
go
ahead
and
get
started.
Welcome
to
this
eighth
I
believe
could
even
be
the
ninth
CN
CF
webinar.
For
those
of
you
been
to
one
of
these
before
we're
mixing
me
up
a
bit
normally
there's
a
couple
of
speakers
and
a
slide
deck,
but
this
time
we're
going
with
the
panel
and
it's
all
about
considerations
to
be
made
around
cloud
native
security.
It's
a
big
subject,
which
is
why
we've
got
a
whole
bunch
of
panelists
in
no
particular
order
of
preference.
A
We've
got
Ben,
Diogo,
Matias,
Dimitri,
Liz
and
Christopher
I'm
gonna.
Let
them
introduce
themselves
in
a
moment,
but
before
we
do
that,
let's
get
into
some
rules.
There's
too
many
of
you
on
the
courts
will
be
able
to
talk
live.
So
if
you
have
questions
throughout
drop
them
into
either
the
Q&A
window
or
the
chat
window
and
I
will
find
opportune.
Moments
to
interrupt
panelists
do
feel
free
to
aim
the
questions
at
specific,
panelists
and
you'll
know
more
about
them
in
a
minute
when
they
introduce
themselves
and
whatever
you
do.
A
B
C
E
F
G
I'm,
the
CTO
and
co-founder
for
ty
Guerra
and
the
original
architect
behind
a
project
called
Project
calico.
We
do
networking
and
policy
enforcement
for
container
and
other
environments
and
I've
got
operational
experience
in
big
networks
for
a
long
time.
So
a
little
bit
an
operational
experience
as
well
Thank.
A
You,
Christopher
and
lest
I
guess,
I
should
include
I'm
here
in
my
capacity
as
the
marketing
chairperson
for
cognitive
computing
foundation,
so
we're
gonna
jump
straight
in.
We
came
up
with
some
questions
beforehand,
because
we've
noticed
in
the
past
attendees
are
at
first
a
little
bit
shy,
but
I'm
hoping
they'll
change
as
we
go
through
how
to
begin
there's
so
many
good
ones.
Here,
let's
start
with
a
nice,
let's
start
with
a
nice
generic
one
and
I'm
gonna
aim
it
generally
at
the
panel,
so
do
jump
in
if
you've
got
an
answer.
A
F
I
can
jump
in
with
them
opening
an
opening
source
on
that
and
I.
Think
one
of
the
things
that's
synonymous
with
cloud
native
and
containerization
is
the
idea
of
micro
services
and
by
decomposing
a
software
problem
into
smaller
micro
services.
It
gives
us
a
way
to
reason
about
the
security
in
a
decomposed
way
as
well.
C
Yeah
and
I
would
actually,
if
I,
could
jump
in
to
build
on
what
Lee
said,
I
think
on
a
cloud
native
component,
the
first
thing
or
the
major
difference
between
work,
though
there's
running
on
the
cloud
and
workload
that
is
a
traditional
application
and
I.
Think
it's
one
of
the
reasons
why
we're
seeing
so
many
people
adopt
the
cloud
and
why
we're
seeing
the
floods
around
the
cloud
is
insecure
disappear
completely,
is
the
fact
that
it
gives
us
one
security
property?
C
G
So
you
know,
but
off
of
Liz's
point
I
think
the
thing
that
is
interesting
is
she
says:
is
we've
now
be
composed
services,
it's
easier
to
reason
and
as
Liz
said
about
what
each
component
does
and
those
components
now
are
handled
automatically
and
in
the
rate
of
so
there's
an
advantage
to
this,
as
we
now
have
more
discrete
simple
components,
it's
easier,
potentially
to
figure
out
what
policies
should
be
applied
to
them.
However,
you
desire
to
do
that.
G
I
think
the
thing
that
does
become
maybe
a
little
bit
more
interesting,
a
little
bit
more
of
a
challenge
as
these
things
now
are
much
more
dynamic
than
they
were
before.
These
environments
are
much
more
dynamic.
You
have
turn
you
know,
turn
rates
and
volumes
of
moving
pieces
in
your
cloud
now
of
many
words
magnitude
more
than
you
did
in
the
classical
siloed
virtualization
world
or
even
predecessor
to
that
so
I
think
you
do
need
I.
You
have
these
these
capabilities.
G
You
have
the
ability
to
have
very
small
micro-services,
easy
to
reason
about,
but
you
have
you
have
to
deal
with
them
being
much
more
dynamic
than
they
were
before.
I
think
one
of
the
key
things
that
cloud
native
brings
to
this
is
cloud
native,
as
the
general
rule
wraps
lots
of
metadata
around
all
of
these
components,
so
you
can
now
start
using
that
metadata
that
the
orchestration
system,
et
cetera,
is
using
to
place
workloads
and
scale
workloads,
etc.
G
You
can
use
that
to
also
drive
security
and
policy
decisions
at
the
same
time
that
the
orchestration
platform
is
actually
mutating
the
environment
to
meet
the
current
needs.
So
if
you
don't
leverage
that
I
think
you
do
end
up
with
a
trophy
trying
to
build
a
legacy
policy
enforcement
environment
in
this
space,
we
will
end
up
with
trouble
if,
for
no
other
reason,
the
amount
of
dynamicism
that
exists.
Yeah.
B
You
can't
use
speed
bumps
anymore
for
security,
so
that
means
that
you
know
it
starts
from
hygiene
of
things
that
get
into
production,
and
so
before
you
actually
put
things
into
production.
You
need
to
automatically
inspect
them,
because
you
could
have
done
that
manually
before
that
and
once
they
get
into
production,
we
were
talking
about
active
threat
protection
like
pre,
breach,
post
breach.
You
know,
laughs,
anomaly,
detection,
all
that
type
of
stuff,
anything
that
required
manual.
B
Intervention
needs
to
be
now
updated
automatically
so
which
it's
basically
a
game
changer,
but,
like
you
said,
a
lot
of
the
stuff
is
already
declared
like
there's
no
set-up
guide,
there's
no
security
guide,
it's
just
declarative
language,
the
developers
or
the
DevOps
actually
used,
and
that
gives
you
a
way
to
automate
things
which
is
which
is
great
and
there's
less
room
for
mistakes,
because
there's
less
manual
work.
Oh.
E
I
see
it
actually
as
his
three
dimensions
right
the
three
common
problems
that
security
teams
had.
Is
they
didn't
know
what
was
running
out
there,
so
they
were
trying
to
guess
all
the
time
what
to
protect.
They
developers
coolin
express
what
they
wanted
from
security.
The
interface,
the
API
between
developers
and
security
was
a
spreadsheet
and
security
was
starting
and
I.
Think
cloud
native
helps
us
across
all
these
dimensions,
and
so
the
previous
people
said
is
the
first
one
inventory
is
just
an
API
away.
E
The
developers
can
now
express
their
intent
and
by
expressing
their
intense
people,
security
knows
what
the
developers
are
trying
to
do.
So
you
can
do
something
educated
and
for
me
the
third
is
that
security
itself
can
become
part
of
the
code.
So
essentially
we
are
moving
to
a
direction
where
security
security
policy
security
guidelines,
whatever
is
the
security
posture,
will
be
one
of
the
organization
who
be
texting
to
github
together
with
the
rest
of
the
code
right
so
I
think
across
all
dimensions.
A
Thanks
guys,
so
one
thing,
I've
noticed
a
couple
of
attendees
using
the
hand
feature.
Unfortunately,
there's
way
too
many
of
you
for
me
to
keep
track
of
that.
So
if
you've
got
questions
drop
them
either
in
the
chat
or
use
the
Q&A
box.
Speaking
of
the
Lancer,
we
have
a
question
coming
in,
which
is
a
little
bit
meta.
C
That
it's
delegated
to
me,
I
think
actually
been
hit.
A
really
good
point,
which
is
declarative
infrastructure,
is
one
of
the
biggest
components
that
I
have
in
my
in
my
mind,
as
one
of
the
biggest
components
of
cloud
native
cloud
native
means
that
there's
one
declaration
how
infrastructure
is
running
such
that
you
can
deploy
in
a
cloud
environment
and
it
can
be
set
up
in
a
remote
control
structure.
C
This
is
like
the
current
de
facto
best
practices
and
standards.
This
is
all
what
I
define
as
cloud
native
but
agree
that
there's
a
lot
of
definitions
agreed
that
there's
way
too
many
cooks
in
the
kitchen
agreed
there's
a
lot
of
confusion
between
the
containerization
orchestration
and
what
cloud
native
actually
means.
I
use
it
as
a
catch-all
for
the
current
standard.
Best
practices
of
this
new
generation
of
orchestrators
and
containers,
micro
services
and
service
meshes.
B
I
like
to
you,
know:
I'm,
it's
not
a
good
efficient.
This
has
been,
but
I
think
that
the
opposite
of
cloud
native
is
like
server
native.
So
anything
that's
not
sort
of
server
native
becomes
like
cloud
native,
because
the
whole
point
is
distributed
software
and
and
things
that
don't
tie
themselves
to
a
specific
server
and
and
they
focus
on
the
application
itself,
and
then
that
application
could
be
actually
Orchestrator,
orchestrated
and
and
executed
in
this
entity.
B
D
The
highly
dynamic
nature
that
was
brought
up
in
the
previous
question
and
and
just
a
sheer
scaled
and
number
of
types
of
components
and
then
specific
instances
and
and
how
quickly
the
system
can
change
over
time.
That's
also
sort
of
a
new,
unique
angle
on
this
kind
of
specifically
Club
native
I,
think
yeah.
G
I
think
you
know
from
my
perspective
it
it
really
does
Diogo
mentioned
it.
It's
this
declarative
model
and
your
infrastructure
is
now
code
right,
you're,
not
you're,
not
raising
a
ticket
with
the
IT
team,
the
storage
team
to
get
a
set
of
block
volume
assigned
to
you,
etcetera,
and
you
know
we
ended
up
coming
down
the
throttle,
but
I
know
is
the
question
mentioned
AWS,
as
people
started,
leveraging
third-party
services
for
what
had
inherently
been
pieces
of
infrastructure
before
s3
buckets
or
whatever
else
they
started
needing
to
write
infrastructure
hooks
into
their
code.
G
Cloud
native
is
just
the
you
know,
the
evolution
of
that,
where
you
know
I
now
have
to
be
declarative
about
the
things
I'm
going
to
use,
because
I
may
not
even
be
in
an
environment
where
I
control,
those
or
even
my
company
controls
us
so
I
have
to
be
declarative
about
them
and
that's
really
turned
us
into
a
declarative
piece,
metadata,
driven
environment
and
that's
five
native.
It
doesn't
mean
it's
all
containers
you
can
bring
legacy
workloads
into
this
environment
and
you
can
attach
the
same
tactic,
declarations
and
and
metadata
to
them.
G
It
just
means
that
that
might
be
harder,
because
some
those
things
might
be
bigger
and
Messier
and
more
difficult
to
wrap
your
hands
around
as
far
as
what
to
declare,
but
there's
you
know,
this
doesn't
necessarily
just
mean
containers,
it
can
mean
surplus,
it
can
mean
VMs,
it
can
bear
mentally
it's.
You
know
it's
not
a
specific
type
of
containerization
or
virtualization.
So.
A
David,
who
actually
asked
the
original
question
retorts
with
so
wouldn't
containers
that
are,
in
essence,
servers
not
be
cloud
native,
I'm,
viewing
it
more
as
service
versus
service.
Having
a
declaration
of
your
infrastructure
doesn't
necessarily
mean
you
secure
it
any
differently
than
you
would
traditional
servers.
He
argues
I.
B
Just
I
said
that
it's
so
I
just
feel
like
comply
to
say
no
containers
are
not
in
essence,
servers
as
far
as
I
know,
containers
are
actually
workloads
that
are
server.
Agnostic,
I
mean
service
is
one
way
to
do
it.
Containers
is
a
different
way
if
you're
using
orchestration,
your
containers
are
not
tied
to
a
certain
server.
So
that's
the
whole
point
of
them
they're
their
server
lists,
and
that's
in
that
essence
I
mean
so
I
object
to
saying
that
containers
are
in
essence
servers.
I,
don't
think
so
in
I
would.
F
Yeah
I
was
just
going
to
say
that
you
know
containers
are
really
not
the
same
as
tourism
and
not
the
same
as
virtual
machines.
You
do
have
a
different
level
of
isolation
there.
That
means
you
do
want
to
be
looking
at
native
security
solutions.
You
know
if
you're,
if
you're
running,
for
example,
some
kind
of
vulnerability
inside
a
container
and
that
gets
exploited,
you
don't
then
have
the
protection
of
VM
isolation
to
to
help
you.
So
you
do
have
to
approach
this
from
a
kind
of
containers.
F
C
Jumping
and
I
think
that
there's
something
to
be
said
for
or
on
the
containers
side
of
things
and
on
the
declarative,
declarative,
infrastucture
s
code
side
of
things,
there's
something
to
be
said
that
fundamentally
changes
security,
which
is,
if
you
have
a
declarative
way
or
if
you
declared
a
pre
hand
what
your
effort
factor
is
supposed
to
run.
You
have
effectively
a
map
of
what
should
be
running
where
and
if
you
tie
this
together
with
the
immutability
components
that
containers
in
these
new
generations
of
tools
give
you
this
completely
changes
again
for
security.
C
You
can
you
have
a
mutable
infrastructure,
you
understand
what
the
expected
state
is,
and
it
becomes
a
lot
easier
for
you
to
effectively
have
a
diff
between
the
current
state
of
your
infrastructure
and
the
expected
state,
and
it
also
means
that
your
security
team
does
not
have
to
inspect
necessarily
or
constantly
the
current
state.
It
should
have
that
component,
but
it
can
reason
about
the
security
architecture.
It
can
reason
about
the
flows.
They
can
reason
about
the
exposure
of
applications
by
literally
just
reading
files
that
describe
what
are
gonna
be
open
to
the
outside.
C
What
ports
are
exposing
a
little
balancer?
What
services
are
connected
to
each
other?
It
can
actually
draw
flow
Maps,
just
from
yeah,
more
files
itself
to
understand
what
the
flow
is
supposed
to
be,
and
then
yes,
absolutely
there
should
be
a
component
that,
in
runtime
in
reality
verifies
that
these
are
the
expected
results,
but
the
security
team
can
design.
Can
architects
can
understand
where
things
are
supposed
to
go,
whereas
before
we
didn't
have
that,
so
this
is
a
game-changer
for
us,
I
think.
G
You
know
just
to
clarify
I
wasn't
saying
that
servers
are
like
containers.
What
I
was
one
at
the
point
I
was
trying
to
get
across
is
in
any
environment.
You
have
a
number
of
different
environments.
You
know
nothing's
ever
really
truly
greenfield.
You
can
now
bring
some
of
those
things
into
a
cloud
native
environment.
There
do
some
at
some
levels,
but
the
idea
is
not
to
base
things
around
servers
to
base
things
around
workloads
wherever
those
workloads
happen
to
be
executing
and
having
metadata
that
drive
them.
G
If
you
try
and
secure
this
base
the
the
question,
if
you
try
and
secure
this
the
way
you
secured
things
before,
where
you
raised
firewall
tickets
and
now
I
have
to
get
another
IP
address,
put
into
the
firewall
to
allow
a
specific
thing
that
may
work
if
you're
running
a
purely
server
environment
and
you
push
configs
to
those
servers
every
couple
of
weeks.
People
are
not
burning
down.
G
G
So
you
can't,
even
if
you
are
using
servers
or
VMs
in
your
cloud
native
environment,
alongside
containers
or
server
lists,
you
select
come
up
with
a
different
way
of
securing
it
because
you're
not
going
to
be
able
to
meet
the
demands
of
the
business
or
your
infrastructure.
By
doing
this,
bypassing
emails
around
asking
for
firewalls
to
be
updated
or
load
balancers
to
be
changed.
That's
got
to
be
done
as
part
of
the
orchestration
environment
automatically
based
on
the
metadata
and.
B
Back
to
your
point,
though,
about
the
VM
is
infected,
yogas
point
I
think
that
anyone
who's
just
taking
you
know
workloads
traditional
workloads
and
just
put
something
huge
in
a
container
like
a
SharePoint
and
I'm.
Just
saying
like
putting
a
SharePoint
VM
on
a
container
and
spinning
it
off
opening
all
the
ports
and
and
thinking
that
he's
going
to
get
more
secure.
Is
that
probably
not
you
know
he
hasn't
done
himself,
a
good
good
service,
I
think
probably.
B
Because
he's
probably
not
declared
you
know
his
declarative
language
is
probably
not
describing
it
very
well,
because
he
doesn't
know
what
that
sharepoint
is
doing,
and
so
he
can
take
advantage
of
a
lot
of
these
things
and
so
and
and
also
like
there's
no
microservices.
He
can't
sort
of
keep
checking
what
he's
pushing
into
production,
like
he's,
probably
doing
himself
more
damage
than
then
then
he
would
have
kept
it
in
the
first
place.
A
I'm
going
to
jump
in
here
because
the
original
and
we're
gonna
leave
this
thread
after
this
next
question.
I
think
cuz.
There's
a
lot
to
get
through,
but
David
says
fair
I'm
gonna
do
his
voice,
for
you,
I
mean.
Imagine,
he's
exasperated
fair
enough
Ben
I
guess
it
depends
more
on
what
type
of
workload
you're
running,
but,
for
example,
if
you're
running
a
simple
Web,
API
server
as
a
container.
How
does
that
change
anything
to
how
you
would
protect
the
service?
I'm,
not
saying
that
having
a
declarative
infrastructure
isn't
good.
Believe
me,
I
love,
metadata.
B
So
I
hope
I
understand
the
question
right,
but
just
the
fact
that
you're
running
say
like
you're
running
a
REST
API.
So
the
good
thing
is
that,
with
declarative
language,
you
could
know
exactly
what's
supposed
to
run,
so
you
know
which
processes
are
supposed
to
run.
You
could
probably
know
which
system
calls
are
supposed
to
run.
You
could
probably
know
if
it's
running
on
an
apache.
You
know
that
this
this
processes
should
be
using.
You
know,
you
know
exactly
where
the
configuration
sits.
B
You
could
automate
automatically
know
that
only
this
process
should
only
listen
to
that
sport.
There's
a
lot
of
things
that
you
can
lock
down
the
traditional
security
didn't
give
you
the
advantage
of
doing
so.
You
know
if
you
look
at
traditional
security
when
you're
trying
to
secure
application
against
breaches.
You
were
typically
looking
at
blacklist
and
you're.
B
Thinking
about
how
typical
attack
patterns
looks
like,
and
here
you
could
basically
just
see
if
the
container
is
actually
doing
what
it's
supposed
to
do
or
not
doing
what
it's
supposed
to
do,
so
that
that
gives
you
a
lot
of
advantages,
and
this
is
just
by
learning
what
what
the
declarative
language
looked
like.
But
even
if
you
you
know,
if
you
skip
the
declarative
language,
just
the
fact
that
it's
minimalistic
could
actually
help
you
apply.
You
know.
B
Machine
learning
is
a
hot
topic
right
now,
but
but
what
we're
doing
or
what
you
could
do
is
you
can
apply
machine
learning
to
these
elements
and,
and
you
could,
there
is
much
more
signals
than
noise
when
you
start
working
on
micro
services,
and
so
once
you
start
breaking
it
into
different
REST
API
is
you
know
some
of
the
concept
like
micro
segmentation,
nano
segmentation
that
used
to
require
an
admin
where
think
very
hard
on
doing
now?
You
could
actually
do
that
automatically,
and
that
gives
you
a
lot
of
power.
B
F
It's
just
building
us
on
that
the
very
concept
of
immutability
that
I
think
Diego
mentioned
earlier.
If
you
deploy
that
web
server
as
an
example
inside
a
container,
not
only
can
you
sort
of
minimize
the
activities
that
are
supposed
to
happen,
you
know
like
Ben
was
talking
about
you're
only
opening
certain
Network
ports,
but
you
also
can
restrict
access
like
there's
no
reason
to
SSH
into
that
cloud.
Native
sort
of
processes
tend
to
lead
toward
immutable
code.
F
There's
no
reason
for
anybody
to
be
directly
getting
into
that
container
or
even
getting
into
the
VM
and
changing
it
executables
available
on
that
on
that
servation
can
all
be
automated,
and
that
does
give
you
a
different
level
of
protection
in
terms
of
the
software.
That's
been
deployed.
It's
all
automated.
You
should
have
a
very
clear
record
of
what's
being
deployed
into
your.
B
Classic
security
there's
something
called
indication
of
compromise
and
it's
it's
blacklisting
what
Liz
just
described,
helps
us
actually
generate
indication
of
compromise.
Like
you
look
at
all
the
indication
of
compromise
and
you're
trying
to
say:
okay,
these
are
events
and
I'm
trying
to
extract
an
alert
out
of
it.
So
you
get
much
more
granular
level
of
what's
supposed
to
to
be
an
indication
of
compromise,
so
it
doesn't
mean
that
just
like
Liz
said
it
doesn't
mean
that
any
person
that
logged
into
the
machine
like
it's
the
end
of
the
world.
B
But
if
you
see
a
person
logging
into
the
machinery
see
processes
that
were
not
part
of
interactive
session.
That's,
let's
that's
a
bad
sign.
If
you
see
someone's
logging
into
the
machine,
maybe
that's
totally
fine,
maybe
that's
a
configuration
drift
that
isn't
a
good
thing,
but
it's
probably
not
an
attack,
but
anyway,
all
that
massive
information
allows
you
to
generate
much
better
and
realistic
alerts.
Then
you
would
get
in
in
traditional
security
software,
where
they're
traditionally,
either
too
noisy
or
or
too
not
noisy,
actually,
actually,.
E
B
So
they
have
like,
after
you
realize
that
you
get
disconnected
every
five
seconds,
so
you
just
make
sure
you
continue.
You
know
you
continue
in
looking
at
what
you're
exploring
it
like
there's
an
attacker
at
the
other
side.
So
we
could
look
at
that
side
and
that
side,
like
is
the
persistence,
is
in
his
mind
not
in
the
server
necessarily
so
their
way
to
work
around
that
I
wouldn't
use
that
as
the
first
layer
of
defense.
What.
G
I
would
like
to
maybe
level
us
a
little
differently,
we're
always
talking.
We
talked
about
security
or
when
things
about
hackers
etc,
and
that's
definitely
something
that
you
know
we're
talking
about
here
and
how
you
secure
it.
Security
is
also
availability,
so
I'll
put
my
operator
hat
back
on
and
running
a
really
big
network.
I
hated
people
SS
aging
into
routers,
because
inevitably
someone
in
the
NOC
would
SSA
to
the
router
and
change
something
and
then
that
routers
a
snowflake,
it's
different
from
any
other
element
in
the
network
and
it's
behavior
is
different.
G
If
you
take,
that
was
bad
enough.
You
know,
so
we
always
want
everything
to
go
in
through
your
configs
and
you
pushes
continuous
down.
If
you
need
to
make
a
change.
That's
a
general
push!
If
you
do
that,
not
a
cloud
native
environment
where
things
are
automatically
scaling
et
cetera,
all
of
a
sudden,
you
have
a
snowflake
because
someone
SSH
into
a
container
to
fix
a
problem
when
they
fixed
it
on
that
one
and
they
didn't
fix.
No
anything
else.
Also,
you
have
one
snowflake
in
your
load.
Balancing
that
behaves
differently.
G
Try
and
troubleshoot
that
one
one
out
of
every
thousand
queries
goes
that
because
you've
got
a
snowflake
there.
You
know
the
immutability
is
really
really
important
here,
because
the
system
and
a
higher
level
the
orchestrator
is
firing
these
things
up
and
scaling
them
up
and
scaling
them
down,
and
if
you
have
things
that
are
snowflakes
on
an
even
unintentionally
in
here
you're
going
to
have
availability
problems
at
the
bare
minimum.
So
you
know
don't
do
that?
Maybe
that's
you
know.
G
A
Thanks
everyone,
I'm
gonna,
I'm
gonna,
stop
that
there,
because
we've
been
going
in
the
same
direction
for
a
while
I
want
to
take
a
slightly
different
look.
David
says:
thank
you
for
your
answers
by
the
way,
so
you've
say
ciated
his
desire
for
knowledge.
Now,
there's
a
couple
of
questions
coming
in
which
look
like
they're
from
4chan,
some
of
those
for
a
minute.
Let's
take
a
slightly
different
tack
here.
A
Be
put
as
how
do
we?
How
do
we
deal
with
the
fact
that
some
of
the
teams
within
the
organization
to
be
doing
all
this
new
kind
of
stuff
and
the
rest
of
the
organizations?
Let
me
do
old
stuff
when
we
still
got
the
same
team
in
the
middle,
trying
to
manage
everything
right?
If
that's
not
what
you
meant
put
another
question
in
I.
Think.
E
That's
actually
a
very
good
question.
There
was
a
a
good
comment
actually
by
this
guy
Jeremiah
Grossman
she's
an
absurd
I.
The
other
day
that
said
90%
of
the
security
innovation
is
going
to
the
new
applications
to
the
new
things
and
90%
of
the
security
problems
are
actually
know
the
legacy
infrastructure
and
we
are
not
doing
much
to
solve
these
problems
and
I.
E
My
database
is
cloud
native
when
am
I
gonna
move
my
high
to
clusters
to
cloud
native
or
whatever
this
component
is
right
and
I
think
we
cannot
see
security
just
in
isolation
right
by
just
solving
the
problem
within
the
core
native
environment.
I.
Don't
think
we
can
address
the
real
problems
that
the
operations
people
are
facing,
so
it
is,
it
is
definitely
a
cup
and
the
only
way
to
gradually
move
it.
It's
a
it's
gonna,
be
a
gradual
transition
position,
giving
the
peace
to
people
I.
E
C
I'll
jump
in
and
be
a
little
low,
controversial.
I
think
this
is
absolutely
right.
I
think
Demetri
is
right,
I
think
and
Jeremiah
is
amazing
and
he's
absolutely
right.
My
performer
abilities
aren't
the
old
thing:
the
job
application
that
hasn't
been
touched
for
25
years.
That
still
has
to
be
deployed
in
infrastructure.
Well,
whatever
it
is,
however,
actually
like
it
number
one.
C
That's
like
some
of
our
focus.
The
reason
for
this
is
that
we
have
25
years
of
failing
at
security
of
the
normal
infrastructure.
So,
there's
no
hope
that
there's
some
new
vendor
that
comes
in
2017
and
says
that
are
gonna
fix
the
same
problems
of
the
same
infrastructures
when
we've
had
all
the
other
vendors
and
all
the
other
engineers
failing
kinds
so
consistently
for
the
past
25
to
230
years.
And
so
it's
just
like
this.
C
This
unreasonable
expectation
that
just
because
people
are
putting
ml
and
hey
I
like
been
said
on
their
slide
decks
that
companies
will
somehow,
without
any
difference,
go
back
to
the
old
legacy.
Applications
and
secure
them
and
I
feel
like
the
hope
of
all
of
us
in
this
in
this
webinar
is
the
fact
that,
as
people
move
to
these
new
components
has
moved.
They
move
to
these
new
systems
and
use
new
ways
of
thinking
that
have
core
advantages
on
the
immutability
on
the
on
the
actual
transparency,
visibility.
C
A
Clarify
this
question,
so
just
let
me
it's
it's
a
long
same
lines,
but
Bret
has
clarified
his
question,
so
I
just
want
to
so
he's
basically
asking
he
says.
If
traditional
stock
teams
aren't
up
to
speed
on
all
the
cool
new
stuff,
how
can
they
add
value
if
other
people
in
the
organization
are
using
dr.
Cuba,
Denny's,
exact
et
cetera?
How
can
they
respond
to
a
text
if
they
don't
know
how
to
reason
about
the
system
they
run
in?
G
G
It
is,
it
is,
and
this
is
something
you
know
we
actually
have
worked
with
a
lot
of
folks
who
have
this
legacy:
new
environment,
stuff
and
I.
Think
part
of
this
is
just
getting
the
sock
teams
to
understand,
or
whatever
teams,
classify
operations,
teams
accept
or
understand.
The
things
now
are
really
driven
by
in
this
environment
really
grown
by
policy.
G
You
don't
write
firewall
rules
anymore
right,
imagining
firewall
rules
and
IP
address
list
is
pretty
much
useless
and
guess
what
there
is
frustrated
dealing
with
that
kind
of
stuff,
as
we
have
been
because
they've
been
taking
it
on
the
head
for
the
last
10
years
on
why
they
can't
get
the
firewall
rules
to
match
or
gee.
Is
that
firewall
rule?
It's
been
there
five
years,
even
valid
anymore?
G
If
you,
if
you
point
out
that
what
you
now
need
to
think
about
is
in
terms
of
policy,
what
should
be
able
to
talk
to
what
you
know,
things
that
do
this
should
be
able
to
things
that
do
this
should
have
this
kind
of
communications
path
and
once
they
get
that
they
actually
usually
come
on
board,
because
they
realize
that
that's
going
to
make
their
life
somewhat
easier.
They
understand
how
this
works
in
the
new
world
that
now,
if
they
need
to
do
something
a
new
corporate
policy.
G
It
is
a
policy
statement
not
trying
to
figure
out
how
to
distill
it
into
Cisco
ACL
rules,
and
then
they
start
looking
for
ways
of
bringing
that
kind
of
technology
back
into
the
legacy
side
and
there's
many
different
ways
of
doing
that.
But
once
they
see
that
this
can
be
done
as
a
policy
during
model
could,
rather
than
based
on
things
you
infer
based
on
IP
addresses,
etc,
they
usually
sort
of
come
along
with
it,
but
it
is
a
bit
of
an
education
to
get
them
to
step
up.
Now
you
get
the
one
I
love.
G
G
D
I
would
just
add
a
bit
of
a
cautionary
note
on
on
policy.
Some
people
I
believe
poison
Bethany
the
way
to
go,
but
also
historically,
there
have
been
many
cases
of
the
unintended
consequences
all
right,
if
it
it's
very
easy
to
change
some
fairly
abstract
policy
without
actually
understanding
what
the
applications
are,
what
the
implications
are
of
that
and
similarly
I
think
us
also,
obviously
the
kind
of
problem
of
proof
or
business
security
members
that
the
policies
that
you
have
to
find
actually
in
reality
also
get
in
force.
B
I
understood
the
question
a
little
bit
differently
and
I
think
there's
a
lot
of
security
tools
today
in
the
cloud
era.
That
start
with
discoverability
I
mean
that's.
That
became
sort
of
like
a
core
thing.
When
you
looked
at
cast
be
like
the
cloud
something
solution
broker
like
you
know,
folks,
like
add
alarm
and
I,
don't
know
some
of
the
other
security
companies
out
there.
B
That
did
it
the
most
popular
thing
they
did,
they
call
it
shadow
IT
and
they
were
you'd,
go
to
a
company
and
ask
them:
do
you
know
how
many
cloud
services
you're
using
and
the
company
would
pick
a
number
and
then
it'll
be
hundreds,
cuz
cuz?
Suddenly
they,
you
know
the
IT
team
realized
or
the
security
team
realized
they're
using
much
more
than
they
thought
they
did
now,
I
think
in
the
cloud
era.
B
What
you're,
looking
for
in
a
security
solution
is
something
that
could
plug
into
all
your
security
architecture,
something
that
could
plug
into
your
cloud
and
discover
for
you
what's
actually
happening
there
and
give
you
sort
of
a
report,
a
table
viously
an
ongoing
report.
But
you
want
to
make
sure
you're
not
missing,
because,
just
like
we
described
there's
a
there's.
B
Shorter
paths
between
someone
thinking,
hey
I'll
food
and
SSH
daemon
introduction
is
actually
getting
into
production
or
spinning
off
you
know:
hey
I
got
the
AWS
credentials,
I'll
just
start
in
another
VM
and
do
something
you
know.
I
forgot
about
it,
and
so
you
should
be
searching
for
in
your
solution.
Architecture
is
the
way
for,
or
you
should
put
discoverability
as
one
of
the
pillars
there.
E
F
F
It's
about
continuous
integration
and
continuous
deployment,
and
it
means
that
we
can
automate
a
whole
bunch
of
the
security
concerns
much
earlier
in
the
process.
You
know
there's
no
getting
away
from
educating
the
security
teams
about
this,
but
one
of
the
good
things
about
me
because
I've
made
it
is,
you
know.
D
F
Well,
a
security
team
can
naively
you
sort
of
think.
Oh
no,
my
developers
are
just
going
to
be
throwing
me
all
these
containers
and
I.
Don't
know
what
the
containers
have
in
them,
but
the
reality
is
tools
can
be
built
into
that
process.
Developers
can
take
more
responsibility
for
security.
They
can
be
helping
their
security
teams.
It's
not
going
to
happen
overnight
as
a
cultural
change
there,
where
developers
are
no
longer
just
throwing
code
over
the
wall
and
having
a
security
team
deal
with
all
the
issues.
Around
security
becomes
a
much
more
continuous
process.
A
A
I'm
gonna
go
there.
We
have
an
Equifax
question,
so
an
anonymous
attendee
asks.
We've
had
a
number
of
very
high
profile.
Beta
breaches.
Recently
Equifax
comes
to
mind,
could
I
guess
how
could
docker
handle
cloud
native
infrastructure
have
helped
here
and
I?
Think
I
want
to
add
a
bit.
This
is
where
wouldn't
his
have
helped?
Okay,.
C
So
I'll
jump
in
first
so
would
not
have
helped
that
helped
with
specifically
remote
code
execution
on
an
application
that
allows
somebody
to
extract
a
password
from
the
database
from
memory
and
then
the
memory
database
from
being
dumped
to
the
outside.
If
this
assuming-
and
this
is
a
big
assumption-
if
this
was
their
infrastructure,
if
they
literally
got
their
database
connected
to
a
front-end
server
that
was
directly
exposed
to
the
internet,
then
that
we
could
not
have
done
anything
about
in
terms
of
specifically
docker
and
cloud
native
and
I.
C
Think
Ben
and
Liam
talked
a
little
bit
about
like
the
intrusion,
detection
system,
components
and
that
will
help
a
little
bit.
But
what
would
have
helped
number
one
if
it
required
any
kind
of
lateral
movement,
so
remote
code
execution
on
this
front-end
server
that
was
running
Apache
struts
and
it
required
any
kind
of
inspection.
The
fact
that
is
inside
of
a
container
is
by
default
means
that
it's
more
isolated,
there's
not
have
access
to
the
file
system
of
the
host
itself.
It
is
limited
in
nature.
C
Has
a
limited
number
of
system
calls,
if
required
any
kind
of
escalation
of
privilege?
It
is
limited
in
nature,
if
required,
any
kind
of
attack
on
the
sidelines
on
the
network.
It
is
limited
in
nature
by
just
a
virtue
of
being
inside
of
a
docker
container.
If
the
docker
container
was
running
as
we'd
only
file
system,
it
would
have
been
really
really
hard
for
an
attacker
to
actually
download
the
normal
tool,
sets
and
compile
them,
and
just
continue
doing.
C
Movement
and
inspection
scanning
so
on
and
so
forth,
and
the
fact
that
it
is
inside
of
a
docker
container
means
that
it
is
more
inspectable
and
that
you
have
access
to
all
of
these
new
applications,
and
we
have
both
twist
lock
in
a
sec
represented
that
it
will
for
sure
jump
on
the
opportunity
to
talk
about
this.
That
allows
them
to
actually
matter.
C
The
system
calls
that
are
happening
and
detect
weird
patterns
of
behavior
of
these
applications,
and
so
the
actual
answer
is
that
it
would
have
helped
a
lot
if
they
had
an
infrastructure
that
was
following
these
best
practices
that
was
deployed
instead
of
containers
that
had
minimal
least
privileged
containers
and
images,
and
did
not
really
allow
attackers
to
have
this
free
range
over.
The
network,
it
would
not
have
helped
exactly
if
the
attacker
is
just
extracting
passwords
for
memory
and
directly
access
and
database,
and
just
explore
trading
back.
It
would
have
helped
immensely
I
would.
G
Once
meet
you
to
my
purse
services,
you
get
a
couple
benefits
which
would
have
helped
here.
We
believe
I
believe
one
is.
You
can
implement
more
of
a
zero
trust
model.
You
know
very
often
someone
finds
vulnerable
server
level
component
of
your
environment
once
they
get
in
there
they're
within
the
trust,
boundary
they're
within
the
perimeter,
and
they
can
go
on
a
hunting
expedition
and
spend
as
much
time
as
they
want
find
the
fine,
interesting
bits
and
indexable
trade
it
out.
G
If
you
now
know,
if
you
open
a
micro
service
and
I
know
that
this
thing's
gonna
be
able
to
talk
to
these
things,
you
can
actually
enforce
rules
and
policies
and
say
I
shouldn't
talk
to
anything
else
right.
So
it
now
becomes
much
harder
to
do
the
crawl
through
the
infrastructure
to
find
the
interesting
bits
right.
So
he
now
can
scope
these
things
to
very
limited
environments
in
Orillia,
zero
trust
model.
You
don't
know
any
want
to
protect
the
container
from
everything
else
or
the
workloads
more.
G
If
they
know
someone
imperfect
everything
else
from
that
work
would
assume
those
workloads
are
going
to
go
bad
and
you
want
to
constrain
what
they
can
do.
That's
one
benefit
to
people
don't
patch
very
often,
because
the
thing
that
they're
trying
to
patch
is
big
and
complicated,
and
they
don't
know
what
all
that
patch
is
going
to
affect.
If
you've
distilled
your
services
down
into
more
manageable
components,
then
this
thing
is
just
a
front-end
load:
balancer,
it's
just
a
what
acting
as
a
web
server,
etc.
G
It
becomes
easier
to
patch
it
because
it's
immutable,
you
can
gin
in
an
orchestrated
environment.
You
can
just
say:
okay
I'm
there,
all
a
new
version
of
Apache
with
this
patch
supplied
and
I'm,
going
to
tell
the
orchestration
system
start
deploying
that
and
retiring
the
old
version.
It
becomes
much
easier
to
patch
and
keep
up
with
security
events,
rather
than
somebody
going.
G
The
one
thing
that
it's
not
going
to
not
going
to
protect
here
is
in
Equifax
there
and
there's
no
one
bingo
as
a
perfect
example
of
it
is
the
things
like
social
engineering.
We
can't
fix
that.
You
know
somebody
registering
a
site
to
collect
a
company.
Registering
the
site
to
collect
sensitive
data
outside
of
their
domain
outside
of
their
direct
control.
Do
have
people
ready.
Mr.
F
G
E
If
somebody
can
do
a
remote
code
execution
and
then
you
can
go
access
the
database
and
exfiltrate
data,
then
you
know
you
cannot
solve
anything
I
think
if
security
would
move
up
to
the
application
semantics
and
not
just
you
know,
if
I'm
at
the
network
I
see
packets,
write
packets,
don't
mean
much
if
I'm
at
the
system
call
as
the
system
calls
everybody
up
as
a
shock,
it
doesn't
mean
much
when
security
moves
up
the
application
semantics.
So
then
we
know
what
is
the
API
that
is
actually
being
driven
there.
E
What
are
the
semantics
of
the
API
that
is
actually
being
called
or
what
is
the
sequence
of
the
ATIS
and
so
on?
Right
as
we
move
security
about
the
application,
semantics
I
think
we
have
the
opportunity
to
put
Sen,
do
a
more
forceful
control,
even
force
like
this
remote
execution.
But
having
said
that,
that
is
challenging
right.
That
is
challenging
because
it
expects
that
it
would
expect
from
developers
not
all
only
to
declare
their
intent
about
the
infrastructure,
but
declare
also
they
are
intended
out
the
application,
semantics,
but
I
think.
E
B
Want
to
give
like
cos,
they
asked
specifically
about
Equifax,
like
so
the
security
solution
available
available
today
and
I'm
representing
it
twistlock
so,
but
but
they
would
obviously
solve
this
because,
like
first
of
all,
you
got
like
cloud
native
laughs.
So
if
there's
a
vulnerable,
you
know
actually
before
going
into
that,
like
if
you
install
today
a
security
solution
that
looks
at
cloud
native,
you
get
like
a
big
sign,
saying
like
you
idiot,
you
have
like
something
unpatched
that
is
basically
facing
the
internet.
Okay,
so
that's
very
simple
and
you'd
fetch
it.
B
B
But
if
it's
an
unknown
attack,
which
wasn't
the
case
with
Equifax,
when
when
you
actually
inject
the
shell
code,
like
the
shell
code
and
someone
tries
to
spin
off
a
shell,
that
shell
wouldn't
go
up,
because
you
know
that
that
shell
shouldn't
be
and
run
in
the
first
place
so
they're
about
like
three
four
different
ways
in
which
you
could
have
first
prevented
it.
And
then,
if
it
would,
the
attack
would
actually
happen.
It
would
actually
be
blocked
and
all
of
that
happens
automatically.
B
You
don't
need
a
person
who
might
have
forgotten
to
configure
the
wife
or
might
have
forgotten
to
configure
the
eastwest
firewall,
and
you
could
actually,
if
it's
a
known
vulnerability,
which
is
at
that
time,
I'm
not
sure
when
that
server
was
deployed.
But
if
it
was
already
deployed.
You
get
like
a
big
sign,
saying
like
stop
doing
what
you're
doing
and
like
you
should
actually
fetch
this,
because
it's
running
and
it's
internet-facing.
B
But
if
you,
but
if
it
was
even
something
that
someone
pushed
into
production,
you
can
actually
block
it
at
the
CI
CD
level,
so
someone's
using
some
CI
CD,
say
Jenkins
and
developer.
Trying
to
push
it
up
because
now
he's
updating
the
software
or
something
and
then
he
gets
back,
say
hey.
You
can't
push
that
into
production.
It
contains
vulnerability
and
that's
not
according
to
our
company's
policy.
So
there's
so
many
things
already
existing
today.
That
would
have
stopped
that.
A
F
Absolutely
I
think
you
know
that
these
policy
rules,
whether
they're
network
based
whether
they're
based
on
which
executables
can
run
which
user
IDs
can
run.
These
things
are
really
powerful
tools
that
can
prevent
you
know
they're
not
going
to
prevent
every
single
possible
zero
day
exploit,
but
they
can
protect
against
their
ok
exploits
you
know.
So
there
is
some
really
sophisticated
tool
and
outlet.
F
A
So
we've
had
we've
answered
16
questions
so
far.
We
don't
we're
doing
great
got
about
9
minutes
left,
there's
a
good
one.
Unfortunately,
it's
anonymous
I,
don't
know
who
asked
it,
but
it's
fantastic
question:
we've
been
speaking
a
lot
about
technology
tooling.
The
question
is
as
immutability
and
faster
CD
pipelines
allow
us
to
get
fixes
out
quicker.
It
also
means
that
we're
pushing
more
potentially
broken
stuff
out
quicker
to
what
organizational
changes
are
required
to
address
these
challenges.
I.
C
Think
well,
I
guess:
I'll
go
first,
we're
getting
organizational
changes,
I
mean,
let's,
let's
use
buzzword,
DevOps
e
right.
So
if
you
have
a
DevOps
process
and
you
actually
have
a
structure
that
allows
you
to
move
fast
and
you're
continuously
having
integration
tests
and
unit
tests
may
have
CI
CD
pipelines
that
are
structured
and
you
have
artifact
generations
that
are
scanned.
And
then
you
have
a
deployment
procedure
that
is
known,
and
you
have
this
sequence
of
events.
C
C
What
do
you
have
to
think
of
is
I
have
to
create
systems
in
the
pipeline
that
allow
me
to
detect
these
wrong
abilities
in
these
issues
automatically
and
then
once
I
have
the
pipeline
established.
It's
all
advantages,
because
I
can
move
a
lot
faster
to
fix
things
that
then
I
find
on
foreign
production
and
they
go
through
the
pipeline
and
checked.
G
Changes,
the
automation
of
testing,
be
that
for
function
or
be
that
for
security,
I
think
the
other
thing
as
we've
talked
about
is
infrastructure
is
code,
and
you
know
we've
made
it
a
point
to
meet.
You
I
think
made
a
point
of
operations.
Teams
and
infrastructure
teams
now
need
to
become
coders
need
to
necessarily
write
huge
amounts
of
code,
but
they
need
to
follow
the
same
kind
of
practices.
Your
infrastructure
is
now
defined
by
code,
so
those
infrastructure
definitions
need
them.
G
Eml
files
or
become
some
higher-level
constructs
et
cetera,
need
to
go
through
the
same
kind
of
C
ICD
pipeline
and
there's
actually
a
benefit
to
having
the
entire
company
starting
to
follow
the
same
process.
Now
I
do
a
new
release
or
a
policy
in
the
infrastructure,
because
we
got
some
hit
new
HIPAA
requirements
that
goes
through
the
same.
We
process
the
same
review
process,
the
same
automated
testing
process,
et
cetera
as
someone
pushing
a
new
piece
of
code,
so
I
think
if
the
or
what
this
drives
eventually
the
whole
organization.
G
Taking
this
more,
you
call
it
agile
or
see
ICD
chain
or
a
DevOps,
you
kind
of
change,
but
everyone
starts
thinking
about
the
problem
in
the
same
way
versus
someone
I'm
thinking
about
first
infrastructure
teams,
thinking
about
it
very
different
from
the
way
software
engineering
teams
have
done,
and
the
legacy
software
engineering
teams
thinking
about
very
different
than
the
new
generation
software
teams
haven't
done
in
the
past.
You.
D
If
you
point
this
term
get
ops
right,
it
is
new
world
right
if
the
entire
organization
it
takes
this
declarative
model
and
you
really
rapid
deployment
through
your
throttle,
controls
with
all
the
trail
etc
seriously.
Then
you're
the
much
much
better
position
to
you
quickly,
detect
when
something
is
wrong
and
respond
to
it.
B
Used
to
be
friendly
with
the
network
team,
with
the
team
that
used
to
do
all
sort
of
that
stuff,
like
your
solution,
if
they're
not
going
to
be
vetted
by
the
dev
ops
team,
they're
out
of
there
so
or
they're
not
going
to
use
it.
So
you
as
a
security
person
when
you
think
about
the
organization,
you
must
buy
lunch
to
the
cloud
people
starting
now.