►
From YouTube: Case study: How Containers Makes Security and Compliance Instantly Easier - John Morello
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
Case study: How Containers Makes Security and Compliance Instantly Easier - John Morello, Twistlock (Intermediate Skill Level)
As containers become the commonplace method for delivering and deploying applications, we've seen more of our customers taking a lift-and-shift approach to migrating their existing applications. In this session, John Morello at Twistlock will discuss a non-profit that provides environmental science and engineering oversight to some of the world's largest civil waterworks projects. This organization relies on a critical 14-year old app that models storm surge. The move to containers for this application delivered immediate benefits, making it easier to manage vulnerabilities, ensure regulatory compliance, and provide runtime defense. Throughout this session, we'll break down the security advantages of containers relative to traditional architectures using this real-life app as an example.
About John
John Morello is the Chief Technology Officer at Twistlock. As CTO, John leads the work with strategic customers and partners and drives the product roadmap. Prior to Twistlock, John was the CISO of Albemarle, a Fortune 500 global chemical company. Before that, John spent 14 years at Microsoft, in both Microsoft Consulting Services and product teams. He ran feature teams that shipped security technologies in Windows, Azure, and Office 365 and served as the Lead Architect of the hybrid cloud consulting team for the Americas. John lives in Louisiana with his wife and two young sons. A passionate fisherman and scuba diver, he also serves as Chairman of the Coalition to Restore Coastal Louisiana.
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
A
You
know
really
interesting
sessions
about
the
very
next
things
that
are
coming
technology,
like
very
innovative
stuff
that
you
know
may
not
be
actually
production-ready,
but
it's
going
to
be
really
cool.
It's
going
to
kind
of
set
the
direction
of
things
for
the
next
five
years.
That's
not
what
this
talk
is
about.
A
Actually,
this
talk
is
about
something
that
is
I,
think
much
more
real
and
practical
when
you
think
about
all
this
great
stuff
that
that
we
as
an
industry
and
as
a
community
have
created
around
you,
know,
orchestration
and
containers,
and
this
whole
new
way
of
computing
and
developing
and
delivering
applications
still
has
to
deal
with
the
reality
in
most
industries.
That
doesn't
mean
that
that
means
it
basically
you're
not
going
to
be
able
to
upgrade
everything
to
the
very
latest
versions.
A
A
That's
out
there
a
huge
amount
of
legacy,
applications
that
are
out
there
very
real
compliance
and
security
requirements
that
you
know
you
can
argue
about
whether
or
not
they
make
sense
or
not,
but
the
reality
is
they're
required
from
a
governmental
standpoint,
and
so
how
can
we
help
those
kinds
of
organizations
which
is
really
the
the
bulk
of
humanity?
I
guess,
or
certainly
of
like
the
enterprise
space.
A
How
can
we
help
those
organizations
realize
the
value
of
these
capabilities
in
that
workload
base
that
they
already
have,
while
they're
adapting
and
adopting
these
technologies
for
the
newer
stuff
that
they
have
in
a
more
cloud
native
kind
of
natural
way
by
default?
And
what
we're
gonna
do
during
this
session
is
talk
about
a
particular
customer
we
have
that
has
gone
through
this
journey
of
basically
taking
a
legacy
workload
that
was
really
mission-critical
to
them
that
they've
had
in
their
organization
for
well
over
a
dozen
years.
A
At
this
point,
it
obviously
didn't
start
out
as
a
containerized,
app
didn't
even
start
out
virtualized
and
to
talk
about
the
values
that
they
got
the
benefits
they
got
of
migrating,
that
to
containers
as
a
way
to
understand
how
this
can
be
helpful
to
organizations
really
of
all
sizes
and
all
industries
that
are
out
there
that
face
similar
challenges.
One
of
the
things
that
I
often
tell
customers
and
I
think
you
guys
have
probably
observed
in
your
own.
You
know
personal
work
lives
as
well
as
complexity
is
never
destroyed.
It's
just
moved
around
right.
A
A
A
lot
of
those
organizations
have
mainframes,
and
still,
you
know,
probably
will
have
mainframes
for
the
foreseeable
future,
but
that
doesn't
mean
that
they
can't
get
advantages
from
taking
those
applications
and
packaging
them
up
in
a
way
that
leverages
the
capabilities
in
this
cloud
native
stack
to
be
able
to
get
additional
benefits
from
a
security
standpoint.
In
addition
to
all
the
agility
and
developer
benefits
that
drive
people
to
make
these
decisions
in
the
first
place.
A
So
I
want
to
first
start
talking
about
like
what
is
this
notion
of
lift
and
shift
like
what
are
the
things
that
customers
are
gonna
go
through
when
you
think
about
a
lift
and
shift
of
an
application
with
containers?
And
then
what
does
that
customer
example
really
look
like
we're
not
going
to
talk
about
all
the
mechanics
of
like
containerized,
an
application.
A
So,
if
you
think
about
what
the
definition
is
here,
I
think
it's
always
important
to
be
clear
about
what
we're
talking
about
when
I
talk
about
lifted
shifts
in
the
context
of
this
case
study
that
we're
going
to
spend
all
the
time
on
it's
about.
How
do
you
take
an
app
that
was
never
really
developed
with
cloud
native
in
mind
because
it
might
predate
cloud
native
by
a
decade?
How
do
you
take
that
and
deliver
that
into
a
different
way
of
managing
and
developing
that
application?
A
You
know,
how
do
you
containerize
it
and
how
do
you
run
it
after
you've
done
so
and
then,
more
importantly,
is
like
what
are
the
benefits
that
you
see
from
it?
Why
would
you
want
to
do
that
specifically
from
a
security
standpoint,
in
addition
to
all
like
the
DevOps
and
agility
benefits
that
you
get
from
containerization
and
that's
really?
A
How
can
you
leverage
that,
from
a
security
standpoint,
to
improve
your
overall
security
for
the
same
application,
so
the
the
flow
that
people
really
usually
go
through
with
this
is
is
or
the
rationale
I
should
say
that
people
go
through
for
why
they
do
this?
Lift
and
shift
in
the
first
place,
usually
is
around
three
major
reasons.
The
first
two
I'll
just
talk
about
to
set
the
context,
and
the
third
one
is
the
one
that
we're
really
going
to
focus
on
from
a
security
standpoint.
A
A
A
Just
taking
that
old,
app
and
putting
in
container
can
deliver
some
really
significant
benefits
to
you
from
an
operational
standpoint,
right
test
and
deployment
becomes
instantly
much
easier.
We
have
a
large
financial
services
customer
one
of
the
largest
credit
card
companies
in
the
world.
That
is
doing
this
exact
process
now,
with
literally
hundreds
of
legacy
applications.
They
have
with
the
full
realization
that
this
migration
for
those
legacy
apps
is
not
going
to
magically
transform
them
into
something.
That's
a
cloud
native
application.
A
You
know
like
a
45-page
word
document
with
screenshots
and
when
they
want
to
deploy
that
app,
there's
actually
a
person
that
sits
through
there
and
clicks
buttons
and
types
commands
and
at
the
end
of
it
they
still
have
to
fight
with
version
compatibility
issues
and
all
the
other
crap
that
people
deal
with
with
legacy
sort
of
applications.
When
just
you
simply
containerize
that
out,
there's
a
lot
of
benefits
to
be
gained
from
that
and
that
agility
aspect
of
it
is
one
of
the
big
drivers
for
it.
A
Additionally,
that
that
notion
of
improving
automation
and
efficiency
also
encompasses
that
the
whole
kind
of
DevOps
process
right,
because
once
you
have
it
in
containers,
obviously
it's
easier
to
integrate
with
the
DevOps
flows
that
you're
using
you
can
have
more
of
a
pipeline
based
approach
to
building
your
application.
Even
if
it's
a
monolith
just
again
getting
in
a
container
makes
it
a
lot
simpler
to
have
a
consistent
thing
to
use
in
development
and
test
and
in
production.
A
But
the
thing
that
we're
really
gonna
focus
on
today
is
the
improvements
that
you
get
from
a
security
standpoint.
What
those
actually
are,
how
they're
realized
and
really
what
are
the
other
options
that
you
have
once
you
make
this
migration
to
further
improve
your
security
in
this
cloud
native
space.
A
So
this
application
that
they
have
is
something
that
they've
used
for
many
years
now.
It's
I
think
that,
as
best
I
think
anybody
there
knows
it
was
developed
somewhere
around
like
2005
or
so
it
was
originally
developed
on
Java,
like
1.2
or
something
or
1.3,
or
something
in
that
nature,
and
this
is
an
application
that
they
use
for
a
variety
of
different
parts
of
their
workflow.
A
It's
kind
of
this
ugly
thing
that,
as
you
guys
have
seen,
probably
with
lots
of
other
applications,
started
out
doing
one
particular
thing
and
then
got
additional
things
added
to
it
over
time
to
the
point
now
where
it's
almost
like
this,
like
office,
suite
beast
of
an
application.
Initially,
it
was
designed
to
basically
be
a
tool
for
modeling
things
like
storm
surge
and
the
effects
of
a
river
diversion
or
a
levee
that
would
be
put
in
one
place.
How
does
that
impact
water
usage
in
other
areas
of
the
coast
over
time?
A
They
also
added
capabilities
to
it,
to
figure
out
well,
given
a
certain
project
and
budgets
for
that
project.
You
know
how
would
different
kinds
of
investments
of
that
budget
and
different
technologies
affect
the
outcomes
from
a
science
standpoint,
and
so
the
application
has
become
fairly
complex,
the
use
cases
they
have,
or
also
you
know,
complex
because
of
the
the
specific
end-users
that
consume
the
application.
A
So
it's
not
just
an
app
where
you
have
of
you
know
a
set
of
internal
people
that
are
all
in
the
same
managed
directory
and
they
log
on
to
it
from
a
browser
or
computer
that
you,
you
know,
have
some
control
over
the
standards
for
the
reality.
For
this
particular
application
is
that's
used
by
people
all
around
the
world.
You
can't
control
the
device
they
have.
You
can't
control
the
you
know
the
browser
version
that
they
have.
A
You
also
don't
have
the
ability
to
really
enforce
any
kind
of
modern
ways
of
doing
authentication
all
the
accounts
that
are
used
for
authentication
of
this
app
exist
locally
and
that
really
limits
your
ability
to
protect
that
application
from
kind
of
remote
attack.
You
know,
by
definition
it's
something
that's
got
to
be
exposed
to
the
Internet
as
a
whole,
because
you
don't
know
if
you're
gonna
be
working
with
somebody
who's.
You
know
in
the
United
States
or
in
Denmark
or
in
Cambodia
for
that
matter,
and
so
it's
really
open
to
the
entire
Internet.
A
Obviously,
as
we
talked
about
earlier,
it
uses
a
lot
of
really
legacy
components
there.
So
there's
a
high
risk
of
vulnerabilities,
being,
you
know,
found
in
those
components
and
being
difficult
to
remediate,
and
that
application
is
also
something
that
you
know
has
a
lot
of
data
that
is
under
various
regulatory
regimes,
because
they
do
a
lot
of
work
with
the
US
government,
they're
required
to
have
FISMA
compliance
capabilities
and
to
be
able
to
attest
to
their
compliance
with
FISMA,
because
they
do
a
lot
of
work
with
people's
people
in
Europe
and
they
store.
A
Obviously
things
like
contact
information
for
those
individuals.
Now
gdpr
is
a
concern
that
they
have
so
those
those
aspects
of
their
requirements
are
not
things
that
they
directly
control
but,
like
most
other
enterprises
out
there,
they
nonetheless
have
have
to
live
with
those
applications,
and
they
have
to
understand
like
how
does
that
impact?
A
You
know
their
ability
to
suit
to
secure
them
and
what
are
the
trade-offs
that
they
have
to
make
to
be
able
to
do
so,
because
that
application,
and
and
because
the
users
are
also
coming
again
from
across
the
internet
and
and
from
basically,
you
know
any
kind
of
device.
It
also
limits
the
kind
of
like
pre-check
abilities.
A
You
can
have
you
can't
necessarily
do
like
a
you
know,
a
proxy
based
solution
where
people
are
going
to
first
authenticate
through
some
kind
of
sam'l
provider
like
G,
suite
or
something
before
they
come
into
it,
and
you
have
at
least
sort
of
a
filter
of
the
authentication.
This
traffic-
that's
that's
coming
in.
Instead,
again,
the
model
is
everything
happens
directly
with
the
application.
A
So
this
is
one
of
those
cases
which
you
often
see
in
a
lot
of
legacy,
environments
in
which
all
of
the
advantages
are
basically
with
the
attackers
right
this
organization,
the
people
that
are
responsible
for
defending
this
application
and
the
data
that
it
has
are
really
at
a
significant
disadvantage.
They're
stuck
with
using
old
tools.
A
Now,
like
most
organizations
that
are
in
this
same
space,
this
isn't
an
app
that
they're.
You
know
iterating
on
and
shipping
a
new-build
of
every
day
right,
like
enterprises
are
very
thrilled,
usually
if
they
can
go
to
like
quarterly
release.
Release
cycles
like
this
is
a
huge
step
forward
for
most
fortune
1000
sort
of
organizations
and
the
same
thing
with
these
guys.
You
know
their
goal
here
is
not
to
be
you
know,
fully
agile
and
to
be
able
to
like
ship
new
code
and
production.
You
know
every
day
before
lunch.
A
Their
goal
is
to
really
be
able
to
still
have
almost
a
waterfall
approach
with
shorter
iterations.
Obviously
you
know
talking
about
something
that
might
happen
every
few
months
versus
you
know
once
every
year
or
even
more
than
a
year.
But
how
do
you
do
that
in
a
way
where
you
can
have
greater
consistency
between
development
and
tests
and
production,
and
particularly
from
a
security
standpoint?
How
can
you
show
the
organizations
that
you
have
to
prove
compliance
with?
A
This
application
has
also
had
an
interesting
kind
of
ride
in
terms
of
where
it's
gone
and
where
it's
like
physically
existed
during
its
life
cycle,
it
initially
started
off
as
a
bare-metal
server
that
ran
in
their
own
datacenter.
Eventually,
that
was
virtualized
also
in
their
own
datacenter
and
about
a
guess
about
a
year
and
a
half
ago,
I
think
they
moved
from
their
own
datacenter
into
Azure.
So
right
now,
this
is
just
simply
a
very
basic
sort
of
configuration.
A
It's
not
running
on
as
recuperar
Nettie's
service,
it's
simply
just
a
standalone
host
a
standalone
as
your
instance.
That's
running
this
workload
as
a
containerized
workload
and
that
may
be
sort
of
like
you
know,
shocking
or
I
roll
you
worthy,
but
the
reality
is,
for
other
thing,
a
lot
of
enterprise
organizations.
There
will
be
a
lot
of
workloads
like
that
for
the
foreseeable
future,
because
you
can't
take
this
application
that
you
wrote
that
long
ago
and
without
significant
amount
of
Ryoka
texture
and
redevelopment
kind
of
instantly
turn
it
into
something.
A
That's
like
fully
cloud
native
right,
but
again
you
can
get
a
lot
of
benefits
like
these
security
benefits.
We're
gonna
get
into
in
a
moment
a
lot
of
benefits
from
simply
packaging
that
up
and
used
a
lot
utilizing
containers
as
a
more
effective
way
to
package
the
application
and
to
ensure
security
of
that
application.
A
So,
as
I
mentioned,
they,
they
had
a
few
a
few
major
challenges
that
really
drove
them
to
think
about
containers
as
a
solution
for
the
problem
set
that
they
were
faced
with.
One
of
the
first
challenges
they
had
and
what
we
talked
about
a
moment
ago
was
maintaining
a
consistency
across
the
different
environments.
They
have
dev
test
and
production,
and
the
reason
I
wanted
to
talk
about
this
in
more
detail
is
one
of
the
big
challenges
that
they
had
was
the
problem
that
they're
faced
with
when
they
have
one
team.
A
That's
an
outsourced
team
that
does
the
development
of
the
application
and
a
different
team,
which
is
an
in-house
team
that
actually
does
the
operations,
which
is
a
pretty
common
model
right
or
maybe
that
both
teams
are
even
outsourced
and
they
may
be
from
different
different
companies
that
you're
painted
to
do
that.
Work.
The
the
big
challenge
they
had
and
something
that
was
a
constant
source
of
frustration
for
them
was
how
do
I
ensure
that
what
we
built
in
development
is
the
same
thing
that
we
tested
and
is
the
same
thing.
A
They're
learning
in
production,
right
kind
of
a
classic
use
case
that
containers
really
do
a
good
job
of
helping
you
solve,
but
the
the
biggest
challenge
from
a
security
standpoint
that
they
faced
with.
That
was
that
what
the
operations
team
thought
that
they
had
from
an
operational
kind
of
design
and
configuration
standpoint
was
wholly
divorced
from
what
the
development
team
used
to
actually
build.
The
application
and
again,
you've,
probably
seen
this
in
your
own
personal
work
lives
as
well,
in
which
you
know
you've
got
a
certain
configuration
development
or
test
you.
A
Do
you
build
your
application?
Everything
works
beautifully,
then
you
hand
it
off
to
somebody
else,
and
you
know
it's
broken
or
it
crash
or
whatever
you
know,
whatever
the
feedback
is
that
they
provide,
and
the
reason
for
that
is
you
end
up
with
different
configurations
along
the
way
and
so
over
time
with
it.
What
really
ended
up
happening
for
them
is
again
a
classic
kind
of
enterprise
challenge
here.
Is
that
everything
just
sort
of
settled
down
to
the
lowest
common
denominator
from
a
security
standpoint?
A
You
know
if
the
application
worked
in
development
with
a
particular
configuration
for
like
the
JRE.
Well,
they
would
just
put
that
same
configuration
in
production
without
really
thinking
through
their
security
ramifications
of
it.
You
know
if
the
way
that
that
they
they
authenticated
users
worked
in
production,
but
not
in
development.
It
we
just
kind
of
like
lower
the
security
requirements
and
development,
and
this
is
something
that
you
often
see.
This
notion
I
would
say
not
really
of
security,
rot,
which
I
think
of
as
more
like
configurations
that
go
bad
over
time.
A
But
if
security
compromised
like
like
the
fact
that
you're
just
going
to
continuously
like
accept
the
the
worst
possible
solution,
as
long
as
it
makes
the
application
actually
run
and
that's
a
hard
thing
to
combat,
if
you
don't
have
a
declarative
way
to
transfer
that
application
through
the
different
phases
of
its
lifecycle,
because
you're,
basically
depending
on
people
to
have
that
consistency
in
what
they
build
and
what
they
operate
and
deploy
over
time
versus
allowing
software
to
do
that.
For
you,
and
software
obviously
is
much
more
efficient
at
doing
so.
A
Dr
was
another
big
issue.
You
kind
of
considered
er
I
think
always
at
least
to
be
tangentially
related
to
security.
If
you
think
about
the
you
know
the
classic
CIA
triad,
that
availability
is
obviously
impacted
a
lot
by
by
dr
and
one
of
the
real
issues
they
had
with.
That
was
the
fact
that,
when
somebody
needed
to
recover
that
environment,
it
was
like
a
multi-day
process,
a
lot
of
cases,
because
they
didn't
always
have
a
crash,
consistent
sort
of
backup
that
they
could
restore.
A
You
know
with
confidence,
because
you
know,
as
is
most
time
like
you,
end
up
making
compromises
some
things
like
it
worked
most
the
time
and
nobody
spent
the
time
to
really
investigate
why
it
didn't
always
work,
and
so
that
was
a
real
challenge,
especially
in
situations
where
they
would
have
to
rebuild
the
application
and
restore
the
data,
because,
again
just
rebuilding
the
application
itself
was
a
very
difficult
and
manual
process,
and
we
talked
about
this.
This
is
great.
A
We
talked
about
this
notion
as
well
of
the
fact
that
there
was
continuous
security
updates
over
time
for
the
app
the
problem
that
they
were
faced
with,
though,
is
because
they
didn't
want
to
deal
with
updating
the
application
when
it
was
in
a
working
State.
They
basically
ignored
security
updates
for
years
and
a
lot
of
cases
they
had.
You
know
Java
vulnerabilities.
A
That
would
be
critical
in
nature
that
they
just
never
addressed,
because
everybody
was
afraid
of
breaking
the
app
right,
I'm
sure
none
of
you
guys
have
ever
seen
something
like
that
happen
in
your
own
organizations
right
everybody
deploys
every
update
as
as
soon
as
it
comes
out
right,
of
course,
it's
late
in
the
day.
It's
supposed
to
be
funny.
Maybe
that's
a
translate
to
us,
so
so
that's
a
real
issue
the
day
that
they
were
faced
with
two
is
like:
how
do
I?
How
can
I
actually
utilize?
A
What
is
it
about
the
nature
of
containers
that
that
enables
you
to
have
security
more
effectively,
applied
to
legacy
applications
or
attaining
application?
For
that
matter?
The
first
area
is:
is
the
characteristics
of
being
minimal
right?
A
container
is
a
minimal
kind
of
set
of
code,
a
set
of
bits
relative
to
a
virtual
hard
drive
right
like
if
I
have
a
VMDK,
as
these
guys
did
of
their
application.
That
VMDK
includes
a
lot
of
stuff
right.
It's
a
full
OS,
as
you
know,
drivers
and
binaries
for
things
that
have
nothing
to
do
with
the
application.
A
When
you
assess
a
you
know
an
artifact,
an
image
or
you
know
the
NDK,
the
more
difficult
it
is
I
think
to
do
so
accurately
right,
there's
there's
a
lot
more
chances
for
there
to
be
corner
cases,
there's
just
a
lot
more
stuff
involved
with
it,
and
it
takes
longer
right.
It's
a
longer
to
go
in,
like
figure
out
all
the
files
that
exist
inside
of
a
virtual,
hard
drive
versus
doing
that
inside
of
a
typical
container.
A
Containers
are
also
really
declarative,
which
is
a
key
thing
for
enabling
software-defined
security
and
software
enabled
security,
as
we
do
here,
which
is
the
fact
that
a
container
is
built
from
an
image
image
or
built
from
layers
layers
are
described
in
a
docker
file
means
it's
possible
for
software,
like
ourselves
or
even
others,
to
be
able
to
go
through
and
understand
in
an
accurate,
comprehensive
way,
all
the
stuff.
That's
inside
of
that
image,
and
all
of
the
things
that
it
should
normally
do
at
runtime.
A
A
lot
of
that
you
can
learn
through
just
pure
static
analysis,
like
you,
can
understand
all
the
packages
and
components
that
are
in
there
some
static
aspects
of
their
configuration,
their
versioning
and
so
forth.
You
can
use
that
to
identify
vulnerabilities
to
use
that
to
identify
compliance,
defects
like
do
they
have
a
private
key
for
their
database
connection,
string
embedded
in
the
image.
Those
are
all
things
that
you
can
see
very
easily
because
there's
a
consistent,
understandable
format
for
what
that
image
looks
like,
and
that
enables
again
a
lot
of
security
automation.
A
That,
historically,
has
not
really
been
very
practical
to
do
at
least
not
at
scale,
and
it
finally
is
is
the
predictable
nature
of
containers,
and
this
is
really
the
thing
that
I
think
enables
the
most
interesting
aspect
of
security.
Around
active
threat,
protection
for
an
application.
That's
been
containerized
one
of
the
challenges
that
these
guys
had
and
again
you'll
see
with.
Basically,
any
large
organization
were
for
the
legacy
apps
that
they
have
is
oftentimes.
A
No
one
at
that
organization
really
understands
how
the
application
is
supposed
to
work,
and
if
you
don't
understand
exactly
how
it's
supposed
to
work,
you're
almost
never
going
to
be
able
to
effectively
secure
it
right.
You
might
understand
on
the
surface,
it
has
a
particular
version
of
job
and
it
listens
on
port
80.
But
do
you
really
know
like
all
the
process
activity
that
normally
occurs
in
that?
Do
you
know
the
way
that,
like
the
front
end
talks
to
the
data
tier
or
talks
to
the
cache
layer?
A
Most
organizations
don't
have
that
depth
of
knowledge
about
the
entire
portfolio
of
their
apps,
maybe
not
even
about
most
of
their
apps.
Frankly,
and
so
what
you're
able
to
do
with,
because
they're
predictable
in
nature,
is
you
can
model?
What
is
normal
activity?
You
know
you
can
learn
the
fact
that
this
container
normally
is
going
to
run
httpd
with
a
particular
check.
Some
of
that
binary.
It's
normally
gonna,
listen
on
port
80.
It's
normally
gonna
resolve
names
in
a
particular
DNS
namespace.
A
To
move
to
an
explicit
allow
list
approach
to
security,
because
you
can
leverage
that
automation
that
we
talked
about
earlier
and
the
fact
that
containers
are
predictable
over
time
to
be
able
to
look
for
anomalies.
Relative
to
what
that
model
predicted,
so
you
don't
have
to
create
a
rule
in
this
case
to
protect
that
that
Java
based
web
application
is
say
like
hey.
This
thing
should
never
run
in
map
or
netcat.
It
should
never
listen
on
any
port
other
than
443.
A
It
should
only
write
to
this
particular
file
path,
because
you
can
learn
that
dynamically
and
you
can
create
those
rules
automatically.
So
it's
not
just
as
simply
about
saying
we're
going
to
take
this
app
and
put
it
into
containers,
and
you
know
deployments
easier
and
maybe
vulnerability
management
is
easier.
You
can
really
have
a
much
stronger
ability
to
have
active
threat
protection
to
the
application
or
for
the
application,
because
you
now
can
move
to
a
model
in
which
you
know
what
is
normal
and
you
can
automatically
prevent
everything.
A
That's
abnormal
and
that's
a
really
key
difference
between
this
containerized
kind
of
cloud
native
approach
and
what
you
could
do
with
any
traditional
tool,
and
that
requires
sort
of
a
manual
configuration
or
you
know
the
the
users
to
go
in
there
and
say
what's
good
and
what's
not
so
from
a
vulnerability
management
standpoint.
The
advantages
that
they've
gotten
from
this
move
have
been
they've
moved
from
an
approach
in
which
vulnerability
management
was
an
inherently
reactive
technique.
A
You
know
they
would
deploy
the
app
and
they
would
use
necess
or
some
other
tool
to
scan
it,
and
they
would
get
a
report
of
all
the
things
that
were
bad
and
they'd
open
up
like
some
tickets
and
they
would
never
address
the
tickets
and
then
eventually
like
they'd.
Do
this
whole
thing
again?
You
know
a
few
months
later,
they've
moved
from
that
model
into
something
where
literally,
the
security
assessment
is
something
that
happens
continuously
as
they
build
the
application
they're
checking
for
vulnerabilities
with
every
build.
A
They
can
have
enforcement
at
build
time
that
you
know
if
this
app
includes
Java
vulnerabilities
that
are
medium
severity
or
higher,
for
which
a
vendor
fixes
available
fail.
The
build
like
make
the
developer
fix
it
right
than
in
there,
which
reduces
the
risk,
of
course,
but
also
reduces
all
the
complexity
and
hassle
of
trying
to
do
that.
After
the
fact.
A
You
know
we
talked
about
the
fact
that
that
they
have
GPR
and
FISMA
and
other
requirements
that
they
need
to
live
up
to
and
historically
that
was
a
completely
manual
process
as
it
is
in
my
experience
in
virtually
every
Fortune
1000
type
organization.
You
know,
if
you
want
to
do
compliance.
There
is
a
human
being.
Some
person
who
has
some
kind
of
internal
audit
function
who's
going
to
have
a
checklist
and
they're
gonna
like
literally
go
through
and
look
at.
A
But
historically,
it's
been
so
hard
to
do
that
effectively
through
software,
because
the
software
base
line
in
a
non
stateful
or
in
a
nice
tight,
loose
environment,
a
stateful
environment
is
always
changing
right,
so
you
so
you
basically
are
always
having
to
go
out
there
and
assess
and
figure
out
like
what's
the
current
posture
with
containers
again,
because
that
declarative
nature,
because
they're
predictable,
you
can
not
only
check
for
that
in
production
through
automation
very
easily
and
say,
like
hey,
is
this
container
running
as
root?
You
know?
A
Is
there
a
secret,
that's
embedded
inside
this
image?
You
know:
does
this
container
mount
privileged
ports?
All
you
know,
like
literally
hundreds
of
things
that
exist
in
you,
know
the
CIS
benchmarks
for
docker
and
kubernetes
and
so
forth,
as
well
as
really
application.
Things
can
all
be
much
more
automated,
but
you
can
also
have
that
same
capability
again
throughout
the
lifecycle
so
before
the
image
ever
leaves
Jenkins
before
it
ever
makes
it
into
a
registry.
You
can
make
sure
that
they
don't
have
embedded
private
keys.
A
You
can
make
sure
they
have
a
named
user
for
thee
for
the
application
things
that
historically
been
really
difficult
to
enforce
because
they
were
all
dependent
upon
a
manual.
Configuration
can
now
be
done
much
more
kind
of
declaratively
as
part
of
your
build
process,
because
all
of
that
declarative
capabilities
of
containers
enables
you
to
wrap
software
around
that
to
enforce
the
configuration
throughout
the
lifecycle
and
then
finally,
is
that
capability
around
threat
protection.
You
know
we
I'm
ention
earlier
that
ability
to
be
able
to
find
and
understand
what
is
the
normal
behavior
of
an
application.
A
You
know
what
are
the
typical
processes
that
it
runs.
What
are
the
sockets
that
it
binds
to?
What
are
the
outbound
protocols
it
uses?
The
system
calls
that
it
makes
like
if
you
gave
a
person.
You
know
a
full
day
or
multiple
days
of
time
to
investigate
that
for
just
this
one
application
they
probably
would
not
be
able
to
do
that
half
as
effectively
as
you
can
do
with
software
right
with
software.
It's
very
easy
to
be
able
to
say
we
know
this
image
this
image.
A
We
can
learn
a
bunch
of
stuff
about
the
static
configuration
we
can
kind
of
follow
the
entry
point.
If
there's
an
it
script,
we
can
learn
about
that
and
we
can,
you
know,
see
what
kind
of
static
things
might
be
declared
in
the
configuration
of
the
image,
but
then,
more
importantly,
is
once
that
image
is
running
in
a
container.
We
can
apply
machine
learning
to
learn
about
what
is
normal
again.
All
the
process
activity
system
calls
and
so
forth,
develop
what
we
call
a
model
for
that
application
that
you
can
see
and
understand.
A
You
do
not
have
to
have
a
rule
in
this
case
that
says,
I
should
not
be
able
to
run
in
map
in
this
application.
We
know
automatically
that
this
app
should
only
run
a
particular
version
of
Apache,
and
anything
else
will
just
simply
be
prevented
and
that's
a
really
critical
advantage
that
you
can't
really
get
unless
you
take
this
model
of
cloud
native
and
containers
and
apply
that
software
automation
to
it.
A
So,
in
summary,
there's
a
lot
of
benefits
from
repackaging
those
those
monolithic
applications
into
containers.
Obviously,
we
talked
about
the
agility,
but
also
the
security
benefits,
which
was
the
core
of
this
talk,
and
the
thing
I
really
want
to
highlight
is
that
this
is
while
maybe
not
the
most
ideal
in
case
I'm,
not
saying
that
you
should
look
at
this
as
preferable
or
even
optional.
A
Frankly,
if
you
have
the
opportunity
to
build
an
application
to
be
truly
cloud
native
clearly,
if
you
have
the
resources
and
the
time
and
so
forth,
to
build
something
from
the
ground
up
as
a
real
cloud
native
app
there's
a
huge
amount
of
advantage
to
doing
so
versus
just
simply
repackaging
it.
The
reality,
though,
in
most
organizations,
is
there's
going
to
be
an
enormous
amount
of
legacy
application
base,
hundreds
of
apps
and
even
fairly
small,
like
fortune.
A
Five:
five
hundred
sort
of
organizations,
hundreds
or
even
thousands
of
workloads
that
you're
never
going
to
have
the
time
or
the
money
to
rebuild
from
scratch,
and
this
approach
of
container
in
those
container
izing
those
applications
yields
real
performance
and
real
security
benefits.
In
terms
of
how
do
you
protect
that
application
throughout
its
lifecycle?
And
how
do
you
protect
it
against
active
threats?
A
A
A
Does
it
match
what
I
have
in
the
model?
If
not
stop
it,
you
know
every
network
socket,
that's
open.
Does
it
match?
What's
in
the
model,
if
not
prevent
that,
and
so
the
generic
approach
is
really
one
about
learning
through
direct
observation
describing
they're
clear
to
the
model
for
it
and
then
looking
for
anomalies
relative
to
what
that
model
predicts.
A
Yeah
I
think
tools
are
I,
guess
technologies,
I,
guess
like
like
OPA
the
opportunity
there
is
to
have
to
basically
have
the
ability
to
call
out
to
a
security
tool
that
can
make
decisions
about
what
is
good
or
not
good,
and
what
should
be
allowed
to
run.
Based
on
this
analysis
that
you're
doing
maybe
not
like
the
runtime
piece,
which
is
kind
of
inherently
like
talking
about
things
that
have
happened
after
you've
deployed
right,
but
all
that
vulnerability
and
compliance
piece
is
like
a
clear
point
of
integration.
A
It
certainly
something
you
know
we're
looking
at
as
well,
which
is
to
say,
like
you
know,
we've
already
built
and
having
our
product.
You
know
our
own
mechanisms
for
preventing
images
from
running
based
on
you
know,
vulnerability,
stayed
and
compliance
stayed
and
slots
of
granular
rules,
but
there's
a
real
opportunity
now
to
make
that
a
more
generic
approach
that
that
works
across
and
works
in
a
more
integrated
kind
of
pluggable
way.
A
A
The
reality
is,
though,
it
was
really
difficult
to
do
that
accurately
before
and
it
was
so
manually
intensive.
No
one
was
really
gonna.
Invest
in
doing
that.
It's
scale
right
I
mean
like
the
level
of
expertise.
That's
required.
You
know
to
go
through
that
process
to
understand
it
to
actually
be
able
to
create
an
output,
for
it
is
so
high
that
it
was
really
just
not
something
that
most
organizations
could
do
and
I
think
like
in
general
with
containers.
You
know
one
of
the
coolest
parts
of
this
whole
space
is.
A
Is
that
notion
of,
like
democratizing
things
that
used
to
be
like
really
high
in,
like
you
know,
is
only
available
in
Google,
but
now
everybody
can
use
it
I
kind
of
think
of
this
as
a
similar
thing
like
yeah.
You
could
have
done
things
like
this
before,
but
this
is
a
way
that
everybody
can
do
it
in
a
really
practical
way.
Like
I
said.
Even
this
organization
is
not
an
IT
shop,
it's
an
ancient
application,
but
yet
they
can
still
get
these
advantages
from
just
this
transition.
A
A
A
In
this
case,
we're
basically
saying
each
build
is
a
unique
image.
Each
image
is
a
unique
model,
and
so
you
always
have
a
model.
That's
tuned
specifically
for
that
build
of
the
application,
and
that's
been
again
something
that
you
really
haven't
Mabel
to
do
at
scale
in
the
past,
because
it
just
required
too
much
effort,
so
I'll
be
outside
for
any
other
questions.
Thank
you
guys
for
coming.