►
From YouTube: StackRox Office Hours (E5): Discover, Remediate, and Harden Against Log4Shell Vulnerabilities
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
B
We
had
a
little
bit
of
a
firework
towards
the
end
of
the
year
with
log
for
shell,
so
we
figured
we'd,
kick
it
off
with
a
bang,
bring
some
stack
rocks
experts
on
and
talk
about,
log
for
j
lock
for
shell
exploit
kubernetes.
What
was
different
a
little
bit
of
stack,
rocks
and
stack,
rocks
news
and
to
join
me.
I
have
out
to
my
left.
I
got
neil
carpenter
senior
principal
specialist
solutions,
architect
below
me.
B
B
A
A
The
initial
disclosure,
I
think,
was
done
rather
rapidly
and
a
lot
of
people
were
taken
unaware,
but
this
is
kind
of
the
worst
fear
of
most
security
teams.
There
is
this
vulnerability
in
a
very,
very
commonly
used
java
library.
So
almost
every
enterprise
java
application
out
there
depends
on
the
log4j
library
it
allows
enough
unauthenticated
remote
attacker
to
essentially
cause
a
remote
execution
in
your
environment.
Right
now,
there's
a
couple
of
you
know:
requirements
for
that.
A
Your
the
applications
that
are
exposed
are
have
to
be
writing
that
data
to
the
log
and
not
parsing
it
or
or
you
know,
sanitizing
it.
So
it's
a
problem
of
unsanitized
input,
so
the
carefully
crafted
message
that
can
be
submitted
to
an
application.
If
that
that
particular
badge
string
gets
logged
through
the
log4j
library,
you
can
cause
an
arbitrary
code
execution
on
ldap
or
ndi
server.
A
So
it's
it's
really
widespread.
It's
really
easy
for
an
attacker
to
exploit
and
the
result
gives
most
the
attacker.
You
know
a
substantial
amount
of
application
freedom,
so
this
gets
that
10.0
on
that
scale
of
one
to
ten.
It's
the
kind
of
the
worst
nightmare.
I've
seen
it
labeled
as
the
worst
security
vulnerability.
Ever
you
know,
we've
we've
seen
a
lot
of
organizations
scrambling
to
find
out.
You
know
where
they're
they're
impacted
by
this.
A
The
other
challenge
with
it
has
been
that
over
the
course
of
a
couple
of
weeks,
the
mitigation
for
this
has
been
a
little
bit
muddled,
and
so
the
initial
exploit
came
out.
There
was
an
immediate
fix.
There
were
some
recommendations
around
changing
the
configuration
using
environment
variables
that
you
could
use
to
mitigate
this
that
turned
out
to
be
incomplete
or
ineffective
in
mitigating
the
problem.
A
I
think
that
what
happened
is
that
security
researchers
turned
their
eye
to
this
library
after
the
initial
discovery,
and
so
there
were
a
couple
of
other
additional
discoveries,
so
you
know
the
authority
on.
All
of
this,
of
course,
is
the
apache
page
for
log4j
to
look
at
the
various
vulnerabilities,
but
we're
not
talking
about
a
single
vulnerability
here,
but
a
series
of
them
that
ended
up
either
being
arbitrary
code,
execution
or
denial
of
service.
A
You
know
we
want
to
talk
a
little
bit
about
how
the
process
should
work,
because
organizations
that
found
themselves
with
a
blind.
You
know
blind
side
here
by
this
really
should
use
the
opportunity,
in
my
opinion,
to
establish
a
more
of
a
permanent
process,
because
this
isn't
going
to
be
the
last
one
right,
there's
no
way
that
the
world
is
done
with
vulnerabilities
and
commonly
used
libraries
and
so
setting
up
a
process.
You
know
the
the
crisis
here
drives
an
opportunity
for
us
to
help.
Customers
and
users
improve
the
situation
going
forward.
C
C
The
game
which
is
all
java
based
and
what
was
happening
was
this
vulnerability
is
so
flexible
that,
by
sending
a
single
message
in
chat,
apparently
they
were
able
to
compromise
both
minecraft
server
and
everybody
connected
to
that
server
right,
an
incredibly
powerful
vulnerability
that
that,
since
then,
has
been
used
in
a
lot
of
different
places
for
a
lot
of
different
things,
but
it
really
it
really
drives
home.
How
foundational
this
this
particular
issue
is
and
why
everybody's
been
so
so
concerned
about
it.
B
And
you
touched
on
a
little
bit
of
the
see
the
challenges
with
the
update
right,
because
there
was
an
initial
patch
and
there
was
a
believe
that
that
was
the
fix.
Then
it
also
had
a
slight
misconfiguration.
Let's
say,
and
one
of
the
reasons
why
I
want
to
talk
about
open
shift
in
kubernetes
specifically,
is
you
do
need
some
sort
of
process
where
okay
yeah
we
had
a
misstep
or
something's
gone
wrong?
B
You
know:
what's
the
quickest
way,
we
can
get
updated
and
then
can
we
verify
that
we've
done
all
those
upgrades
that
the
right
version's
in
there
and
that
we've
made
the
configuration
changes.
So
I
was
hoping
you
could
talk
a
little
bit
about
how
you
know
we
can
set
something
like
we
can
use
kubernetes
to
let's
say
make
that
fixing
process
a
little
bit
easier
and
identify
those
vulnerabilities
a
little
bit
quicker.
C
Yeah,
maybe,
instead
of
just
talking
about
it,
I
could
show
you
some
of
this
and
I
will
practice
this
by
saying
the
lab
environment
I
have
up.
None
of
what's
running
is
available
from
the
internet
because
I'm
going
to
show
you.
I
have
some
some
vulnerable
things
running
here,
but
you
can't
get
to
any
of
that,
so
I've
got
openshift
up
and
running
in
this
environment.
C
C
How
are
we?
How
are
we
using
that?
Where
are
we
using
that
and
so
in
acs?
I
can
go
dive
through
all
the
components
that
are
currently
in
use
in
the
images
that
are
backing
my
deployments,
and
so
I
can
see
here
a
list
of
all
of
the
components
across
everything
and
I
can
pretty
easily
filter
this
down
to.
C
Let's
look
for
log4j
there,
we
have
it
and
I
can
see
I
have
a
number
of
different
versions
of
log4j
currently
currently
running
in
my
environment
and
so
like
in
the
initial,
in
the
initial
vulnerability
in
2021
44228
everything
2.14
and
below.
If
I
remember
rate,
was
vulnerable,
don't
don't
quote
me
on
that,
but
1.x
was
not
so
I
could.
I
could
easily
come
in
here
and
go
well.
I've
got
a
2.6.2
and
2.11
and
2.11
and
2.14
and
2.14
all
of
those
appear
to
be
vulnerable.
So
this
is.
C
This
is
a
starting
point
for
me
before
we
even
get
to
the
vulnerability.
It's
about
being
able
to
look
at
that
makeup
that
inventory
of
what
we're
running
and
understand
what's
going
on
and
where
things
are
going
on,
so
I
can
see,
for
example,
here
I've
got
a
bunch
of
images
that
are
not
actually
in
use.
In
my
environment
today,
but
I
do
have
this
2.11.1
is
in
use
in
two
deployments
and
I
can
go
look
at
what
those
deployments
are.
C
Then
there
are
some
outdated
versions
of
sonar
cube.
I'm
still
running
in
this
in
this
lab
just
to
have
something
to
show
off,
but
I
can
go
dig
into
them
and
find
those
things
and
dig
and
and
get
to
them
now
from
there
once
I
have
a
cve
to
look
at
once
again
that
inventory
based
on
vulnerability.
So
I
can
say:
let's
go.
C
C
To
that
I
can
see
the
deployments
they're
running
in
so
now.
This
is
starting
to
get
me
to
a
place
where
I
don't
know
late
december,
when
everybody
was
was
trying
to
figure
out
what
was
going
on,
what
the
extent
of
their
exposure
was.
This
is
starting
to
give
me
that
information,
so
I
can.
I
can
take
this
inventory
dive
into
what's
deployed,
what's
running
in
my
environment
and
say
all
right.
C
Here's
where
I
actually
have
a
problem
with
this,
and
this
is
something
I
think
chris
eric
and
I
all
talk
to
a
number
of
customers
about
in
late
december
and
into
january
was
how
do
we
go
start
with
this
inventory?
How
do
we
figure
out?
What's
already
deployed
one
of
the
issues
with
log4j?
Is
it's
such
a
ubiquitous
component?
It's
such
it's
so
common
in
java
applications
that
nobody
really
knew
everywhere.
It
was
being
used.
C
It
had
been
upstream
vendors,
had
used
it
to
log
data
and
to
manage
that
off-the-shelf
software
used
it
lots
of
people
had
used
it.
So
nobody
really
had
a
good
understanding
sort
of
the
third
week
in
december
of
of
where
they
were
impacted
and
what
what
was
impacted.
So
this
gets
us
there
right.
We
can
go.
Look
at
what's
currently
deployed,
see
all
right.
We've
got
a
problem
now
from
here
there's
a
couple
of
things
that
we
can
do
that
I
think
are
of
interest.
C
The
next
thing
is
so
if
we
know
what's,
if
we,
if
we've
got
our
arms
around
where
we
are
today,
we
want
to
start
creating
policy
to
catch
this.
This
particular
problem
acs.
We
have
some
generic
policies
that
are
going
to
catch
all
of
our
vulnerabilities,
but
that's
that's
a
fair
amount
of
data
going
on
and
a
fair
amount
of
work
that
that
customers
typically
do
with
that.
We
may
want
to
create
if
we
have
a
particular
emerging
set
of
circumstances
like
log
for
shell.
C
C
We
have
some
information
here
about
it,
and
so
we
can
find
it
and
we
can
go.
Look
in
our
violations
and
say
show
me
any
violations
of
that
policy,
and
I
can
see
where
my
deployments
have
cut
across
that
I
could
turn
on
notification
and
start
sending
these
out.
So
somebody
tries
to
deploy
something
we
get
an
email
or
we
get
a
slack
message
or
whatever.
C
Now,
that's
starting
to
get
my
arms
around
this
issue,
but
ultimately,
what
I'd
like
to
do
is
shift
left
right.
We've
all
talked
about
that
for
for
years
now,
but
I'd
really
like
to
start
catching
this
before
somebody
ever
tries
to
deploy
it,
and
so
not
only
can
I
can
I
enforce
this
at
deploy
time,
but
I
can
move
it
back
and
it
build
time
start
looking
at
what
I'm
building
start
scanning
and
start
returning
results
and
start
applying
these
policies
at
build
time
same
policy
same
criteria.
C
We
caught
not
just
our
general
vulnerability
policy.
This
has
got
a
number
of
vulnerabilities
in
it,
but
specifically
this
log
for
shell
policy
that
we
created,
and
so
I
can
see
that
that's
being
caught
there
and
and
so
now
I've
taken
that
I've
taken
that
security
concern
I've
taken
it
all
the
way
left
to
where
I'm
building
or
ingesting
images
and
I'm
able
to
catch
that
and
start.
I
actually
wasn't
enforcing
this,
but
I'm
able
to
start
breaking
builds
so
that
you
have
to
fix
this
vulnerability.
B
And
having
that
flexibility,
I
think,
is
where
let's
say
the
money's
made,
because
you
don't
really
want
to
be
just
forcing
decisions
on
developers,
maybe
give
them.
You
know
something's
not
getting
pushed
to
production
right
away,
you're,
giving
them
a
little
bit
of
time.
Saying
hey!
If
you
don't
fix
this
within
two
more
builds,
you
know
we're
we're
going
to
basically
flip
the
policy
or
or
something
like
that.
B
C
And
for
me
you
know,
I
think,
there's
there's
some
big
things
there
right.
First
of
all,
the
flexibility
of
a
policy-based
approach
lets
you
start
defining.
What
do
I
what
I
mean?
What
am
I
interested
in?
What
do
I
want
to
see
and
then
further
on?
What
do
I
actually
want
to
enforce?
Where
do
I
want
gates
that
I'm
not
going
to
allow
things
to
get
past
and
defining
those
things
and
applying
them
flexibly
across
that
whole
pipeline
from
build
time
to
deploy
time
and
then
into
runtime.
B
And
realistically
you're
probably
going
to
have
you
know
five,
six,
seven
teams,
all
with
different
types
of
gates
and
different
applications,
set
up
too
right,
so
you're
going
to
need
some,
maybe
some
flexibility,
because
some
teams
use
different.
You
know
ci
and
build
tools
so
that
all
needs
to
be
adjusted
too
right
and,
like
some
teams
are,
will
have
you
know,
front
end
and
others
are
data
science.
Maybe
it's
less
impact
right.
A
I
mean,
I
think,
I'd
like
to
think
the
best
of
my
development
teams
right
if
I'm
a
security
director,
you
know
I
got
to
assume
that
they
want
to
fix
these
things.
Don't
want
to
be
on
the
the
big
board
for
for
being
a
huge
risk
here
right.
What
I
like
about
this
policy-based
approach,
is
that
hey
it's
it's
present
in
your
build.
You
do
what
you
need
to
do
to
fix
it.
It
could
be
update
the
version
of
it.
A
Maybe
let
maybe
this
is
something
that's
not
not
easy
to
do
with
long
log
for
j,
but
with
a
lot
of
other
components,
you
find
a
vulnerability
in
something
that
you're
really
not
even
using
right.
If
it's
not
a
critical
part
of
your
application,
just
take
it
out
right,
it
came
with
your
docker
base
image.
It
came
with.
You
know
some
other
install
that
you
did.
A
Maybe
you
weren't
aware,
you
know,
there's
a
lot
of
reasons
why
the
the
policy
here
is
left
in
the
hands
of
the
of
the
developer,
because,
instead
of
you
know,
fixing
a
vulnerability
by
updating
to
an
you
know
properly
fixed
version
of
that
library.
Another
option
is,
you
know,
remove
that
dependency,
if
you
don't
have
it
there,
you
don't
have
to
maintain
it.
I
don't
care
as
a
security
director.
I
don't
care
one
way
or
the
other.
A
D
Yeah-
and
I
think,
like
you
know
just
from
a
couple
customer
examples
right,
I
think,
like
the
first,
the
first
thing
everybody
wanted
to
do,
which
neil
was
showing
in
the
beginning
of
the
demos
everybody
wanted
to
just
know.
Okay,
am
I
exposed
to
this
vulnerability?
Do
I
have
it
running
in
a
deployment,
and
I
had
a
couple.
You
know
customers
come
to
me
and
go
okay.
D
I've
done
that
a
couple
times
I
was
able
to
use
the
information
in
acs
to
hand
you
know
hand
something
to
a
developer
and
say
yeah
fix
this
and
they
were
able
to
move
the
needle
on
that.
The
next
question
logically
becomes
okay.
How
do
I
remove
myself
from
that
feedback
loop
so
that
I
have
an
automated
control
in
place
to
tell
developers
about
those
things,
and
I
think
it
gets
really
interesting
there.
D
You
know
they
want
to
add
an
extension
to
that
policy
that
captures
okay.
This
is
this
is
something
that's
vulnerable,
but
we
also
want
to
capture.
You
know
x,
y
and
z,
or
we
want
to
put
a
preference
on
these
name
spaces,
and
so
I
think,
there's
there's
a
lot
of
automated
control
you
we,
you
know
we
give
the
security
team
right
like
to
to
be
able
to
put
that
in
a
policy,
and
you
know
remove
themselves
from
just
having
to
inventory
things
constantly
and-
and
you
know
manually,
doing
a
lot
of
that
stuff.
A
A
The
thing
is
back
right,
and
so
once
the
attention
drops
from
that
manual
review
process,
then
then
we'll
find
that
old
vulnerability
is
resurface
right,
and
so
you
know,
we
love
giving
developers
the
flexibility
to
to
do
what
they
want
to
experiment
with
different
packages
to
go
out,
and
you
know
try
that
new
software
component,
but
then
we
find
out
that
it's
still
got
these
dependencies
on
these
old
versions.
But
a
policy
is
not
going
to
forget
right.
A
That's
not
going
to
forget
that
you
brought
in
this
library
and
they
found
that
it
still
has
that
vulnerable
version
on
it,
so
that
I
think
I
think
that
you
know
we're
talking
about
here
is
not
just
log4j.
It's
honestly
any
vulnerability
having
a
process
in
place,
and
we
have
customers
who
had
such
a
process
in
place
and
they
had
a
lot
less
to
worry
about
when
this
thing
was
released.
They
knew
that
no
further
development,
you
know
nobody
could
push
a
build.
A
D
I
think
that
that
also,
you
know
it
moves
the
needle
on
the
enforcement
conversation
and
in
these
organizations
right
where
you
know
these
are
these
are
kind
of
those
blessings
in
disguise.
Almost
where
you
know
security
is
able
to
take
a
little
bit
of
a
leap
forward.
I
think,
in
that
conversation
around
you
know
we
can
have
something
that
we
turn
on,
because
this
is
one
of
I
think
one
of
those
perfect
examples
where
you
know.
D
Turning
on
like
the
deploy
time
policy,
that
neil
showed
is
actually
a
pretty
suitable
option
for
production
environments
right
and
actually
denying
a
deployment-
and
you
know
you
know
obviously
within
a
certain
implementation,
you
want
to
be
careful
of
how
you
do
that,
but
I
think
that
the
the
fact,
like
you
said
chris,
the
fact
that,
like
we
have
that
enforcement
story
is,
is
powerful.
You
know,
because
there's
a
lot
of
tools
that
can
scan
for
this
vulnerability.
D
I
think
there's
a
lot
of
vulnerability,
assessment
technology
and
scanning
tools
that
can
you
know,
give
give
an
idea
of
where
it's
inventoried,
but
I
think
you
know
there's
not
a
lot
of
ways
of
doing
that:
native
enforcement
in
a
way
that,
like
moves,
the
needle
for
security
to
say,
okay
yeah,
we
can,
we
can
put
a
hard.
We
can
draw
a
hard
line
here.
We
can
turn
this
on
and
prevent
this,
and
you
know
I'm
I'm
more
interested
to
see
like
how
is
that
gonna?
How
is
that
gonna
help
them
with
other
things?
D
You
know
other
things
they're
trying
to
do
organizationally
right.
If
you
have
success
with
something
this
critical,
you
know,
can
you
can
you
begin
to
turn
on
additional
policies
that
have
nothing
to
do
with
the
log4j?
But
because
you
build
that
confidence,
you
know
in
security,
you're
able
to
kind
of
move
the
needle
right,
okay
and.
C
You
know
a
year
ago,
two
years
ago
we
talked
about
ci
and
everything
was
built
internally
for
the
most
part
one,
especially
when
we
talked
to
enterprises.
Everything
was
focused
on
what
my
developers
are
doing.
What
my
developers
are
delivering
and
what's
happened
is
we're,
starting
to
see
vendors
and
external
organizations
deliver
software
as
container
images
as
helm,
charts
as
operators,
whether
it's
the
the
5g
providers
in
in
telecom,
it's
ibm
cloud
packs,
you
know
chris
and
eric.
I
think
I
think
I
told
you
guys.
C
C
They've
got
a
catalog
of
helm,
charts
that
deploy
on
top
of
that
this.
This
sort
of
consumerification
of
of
containers
means
that
security
teams
have
to
think
about
that
as
well
right,
not
just
how
are
we
not?
How
are
we
scanning
the
things
our
developers
are
building?
But
how
are
we
scanning?
The
cloud
packs
we're
getting
from
ibm
or
the
container
images
we're
getting
from
ericsson
are
the
the
things
that
external
vendors
delivering
to
us
to
run
on
top
of
openshift
on
top
of
eks
or
wherever
we're
running
them.
C
C
It's
supplied
by
an
external
vendor
doesn't
mean
your
security
policies
don't
apply,
and
I
think
this
is
a
really
great
example
of
where
you
know,
because
log4j
is
so
ubiquitous.
It's
it's
been
important
to
be
able
to
go
as
early
as
possible
to
scan
those
externally
supplied
container
images
as
well
and
understand
what
the
inventory
is
there.
A
Neil
you've
been
you've,
been
doing,
threat,
hunting
and
incident
response
for
a
long
time
right.
The
container
format
seems
to
me
right
with
kubernetes
that
it's
a
little
bit
more,
you
know
prescribed
right.
We've
got
some
limits
around
it.
I've
got
a
pipeline.
I
can
establish
a
process.
Is
it
easier
than
in
this
environment
to
track
this
sort
of
thing
down?
If
I've
got,
you
know
limits
on
where
I
get
my
images
from
I
force
them
to
go
through
a
process.
C
C
You
know
an
idea
of
what
this
was
going
to
look
like,
and
so
we
worked
with
them
and
they
deployed
day
one
with
enforcement
turned
on
at
both
build
time
and
deploy
time
for
their
most
important,
their
their
critical
applications,
their
most
serious
security
policies
out
of
the
gate
they
had,
they
had
controls
where
they
could
say
you
can't
pass
here.
If
you
don't
pass
these
checks,
you,
don't
you
don't
get
these
right,
yeah!
That's
that's!
C
B
B
A
Yeah,
I
don't
want
to
trivialize
that
it's
not
easy
for
organizations
to
make
a
shift
if
they're
used
to
builds.
You
know
weekly
monthly,
quarterly
right
and
releases
to
go
out
in
a
big
way
rather
than
a
continual
process,
but
when
they
make
that
change
and
as
developers
get
used
to
the
idea
that
a
new
build
every
day
every
hour,
every
pull
request
like
creates
a
build,
and
then
every
one
of
those
is
an
opportunity
to
pull
in
the
latest
to
get
those
fixes
down.
A
You
know
like
that
allows
them
to
react
any
of
these,
so
you
know
we'll
keep
saying
this,
but
this
is
not
the
last
of
these.
I'm
not
even
sure
that
we're
done
with
log
for
j,
yet
right.
So
there's
going
to
be
more
of
these
things
that
security
researchers
will
find
and
and
being
able
to
quickly
go
out
and
take
advantage
of
those
fixes.
As
soon
as
you
possibly
can,
developers
are
better
off
when
their
dependencies
are
explicitly
defined
in
something
like
a
docker
file
and
they
can
just
rerun
that
build.
A
You
know
again
and
again,
it
is
one
of
the
better
things
about
this.
This
format
here
you're
right
too,
we
said
earlier,
michael
about
you
know
we
call
it
the
common
language
between
security
and
developers.
They
haven't
had
a
whole
lot
to
talk
about
in
common,
but
we
talk
about
you
know
using
kubernetes
as
kind
of
a
language
of
discussion
here
about
deployments
and
images,
and
you
know
defense
and
depth
in
those
terminology.
Both
sides
can
understand
it.
So
it's
it
is
good.
A
The
right
authorities
you'll
get
less
of
the
developer
headaches,
who
you
know,
developers
have
a
headache
with
security
tools
that
just
enforce
they
don't
provide
information,
they
just
break
things
and
that
violates
that
principle
that
I
want
to
specify
everything
in
code
and,
of
course,
the
security
teams
know
that
if
we
let
developers
do
whatever
they
want,
they
don't
prioritize
security.
Fixes
right
I
mean
that's
natural
right,
you
prioritize
new
features
and
you
know
fixing
bugs
and
things
like
that.
A
B
Now
we
talked
a
little
bit
about
policy,
a
lot
about
policy
and
about
log
for
j,
I'm
kind
of
curious.
Is
there
any
sort
of
things
that
people
could
be
doing
beforehand
that
you
can
maybe
show
us?
So
you
know
obviously
there's
a
little
bit
of
configuration
in
kubernetes
just
a
little
bit
of
configuration.
B
Obviously
these
things
are
going
to
happen.
You
know
what
are
some
practical
ways:
practical
policies
best
like
just
great
habits
that
people
can
get
into,
so
that
when
this
does
happen,
that
they
can
one
find
those
really
quickly
and
then
two
make
sure
that
you
know
the
impact
is
very
low.
Even
if
something
you
know
was
able
to
stay
in
the
the
cluster
for
a
couple
days,
because
I
think
it
was
like
five
days
right
until
nist
released
it
as
a
an
actual
vulnerability
but
like
from
the
minecraft
day
until
yeah.
C
It
was
widely
acknowledged,
nice
lag
there.
You
know
so
I
I'll
start
in
there
and
I
often
say
that
when
you
move
to
containers
and
kubernetes
an
open
shift
to
some
extent,
your
security
problems
don't
change
as
at
the
same
time,
everything
changes.
So
a
lot
of
the
approaches
are
the
same
that
we've
been
talking
about
for
years
right
if
I
can
reduce
the
the
blast
radius
of
of
a
particular
compromise.
C
If
I
can
so
you
know,
I
I
sort
of
have
to
accept
that
at
some
point,
they're
going
to
be
zero-day
vulnerabilities,
they're
going
to
be
unpatched
vulnerabilities.
I
couldn't
patch
for
some
reason
right.
There
they're
going
to
be
some
set
of
things
that
that
result
in
something
in
my
environment
getting
compromised.
C
That's
we
used
to
call
we
still.
I
just
call
it
assume,
breach
and
assume
breach,
mindset
right.
So
if
I
start
there,
the
next
thing
I
can
do
is
start
making
it
so
that
if
any
particular
piece
of
my
application
of
my
environment
gets
compromised,
I
can
limit
what
an
attacker
does
with
that,
and
so
one
of
the
examples
I
think
I
think
works
really
well.
C
In
kubernetes
and
openshift,
once
you
start
getting
your
mind
around
it
and
figure
out,
the
right
approach
is
network
policies
so
start
applying,
essentially
micro
service
firewalling
down
to
the
container
level.
That
says,
the
only
thing
this
container
can
talk
to
is
this
other
container
that
it
always
talks
to,
and
it
can't
talk
to
anything
outside
of
that
outside
of
that
pattern,
and
now
you've
locked
an
attacker
into
that
they
can't
compromise
one
container
and
then
use
it
to
jump
to
others
other
significant
pieces
in
there
in
the
environment.
C
That's
a
that
sort
of
thing
is
an
incredibly
powerful
tool
and
a
great
place
to
to
maybe
not
start,
but
once
you
start
getting
your
arms
around
this
to
to
dig
into
and
figure
out,
how
do
we
do
that?
How
do
we?
How
do
we
reduce
the
the
blast
radius,
the
impact
of
any
particular
container
being
compromised
and
lock
them
down.
A
At
one
point
they
have
loads
of
tools
on
them
that
are
useful
for
maintaining
and
updating
a
virtual
machine.
They
have
you
know
all
your
standard
linux
file
system
on
there,
they've
cool
utilities
like
curl
and
and
open
access
to
the
internet,
and
so
now
your
attacker
who's,
able
to
run
arbitrary
commands,
go
and
pull
down
a
crypto
miner
from
github
and
start
running
it.
You
know
we
see
that
it
isn't
even
just
an
attempt
to
like
steal
data
or
establish
back
doors
in
the
environment,
but
there's
free
resources
right.
A
A
Of
course,
two
developers
need
to
be
careful
about
the
kind
of
input
they
accept
and
sanitizing
it.
But
that's
a
that's
a
different
topic
right:
that's
the
source
code,
practice
and
and
and
secure
coding
topic.
But
all
these
things
contribute
right.
The
more
you
know
painful.
We
can
make
it
for
an
attacker
to
do
anything
useful.
I
think
you're
gonna
be
in
better
shape,
so.
D
I
think
I
think,
like
it's
the
things
you
mentioned
chris
and
neil.
I
think
those
are
like
good
starting
points
too,
like
when
people
ask
like
okay.
What
can
I
focus
on
when
it
comes
to
risk
or
when
it
comes
to
like
things
I
might
be
able
to
enforce
a
little
bit
sooner
than
then
later
you
know,
there's
like
a
handful
of
those
high
end
to
the
right
types
of
configurations
and
risks
that
you
can.
D
You
know
that,
like
any
customer
should
care
about,
you
know
like
there's,
obviously
the
unique
stuff
that
might
be
depending
on
how
a
customer's
running
their
specific
environment,
but
like
in
general,
you
don't
want
to
be
running.
You
know
as
privileged
in
general.
You
don't
want
to
be
running
as
root.
You
don't
want
to
be
running.
You
know
in
these
in
these
over
excessive
configurations,
so
I
think
it's,
I
think,
like
a
lot
of
that's
just
like
customers
getting
educated
on.
D
You
know
those
things
between
developers
and
some
of
those
processes
are
in
place,
they're
able
to
actually
take
advantage
of
enforcement,
eventually
right
and-
and
you
know,
do
some
of
those
things
but
but
yeah,
I
think
it's.
I
think
it's
like
a
really
good
opportunity.
You
know
to
just
you
know
not
not
focus
on
everything
that
you
could
possibly
prevent,
but
there's
a
handful
of
really
just
like
low
hanging
fruit.
D
B
B
Is
you
have
a
developer,
who
might
just
do
the
build
for
the
container
and
they
don't
set
up
the
configuration
and
then
it's
okay?
Well,
does
the
operations
team
know
exactly
what's
going
on
in
the
container
and
now?
Okay?
Well,
if
you
give
them
a
ui
that
shows
them
the
normal
traffic
in
the
test
environment,
for
example.
B
Well,
then
we
can
mold
a
network
policy
and
test
it
and
that,
but
that
communication
it
can
be
really
annoying
right,
especially
as
you
try
to
grow
kubernetes
and
grow
your
team
and
expand,
and
maybe
you
lose
a
developer
so
that
just
having
that
wealth
of
information,
I
think
is
well,
I
think,
was
one
of
the
largest
hurdles
early
in
the
kubernetes.
I
think
it's
been
somewhat
solved,
although
developers
might
say
different,
but
yeah.
I
was
kind
of
curious.
B
You
know
how
do
you
bridge
that
gap
and
like
what
specific
actions
and
the
tools
do
you
look
for
to
kind
of
help
with
that
communication,
especially
from
a
network
policy?
I
think
that
is
one
of
the
let's
say
once
you
get
to
scale,
and
you
start
looking
at
you're,
looking
at
hundreds
of
network
policies,
thousands
of
network
policies
right.
How
do
you
visualize
that?
How
do
you
keep
that
all
organized.
B
A
Well,
it's
a
tough
it's
a
tough
challenge
when,
when
organizations
are
coming
out
of
the
way,
the
way
most
of
these
platforms
get
rolled
out,
so
kubernetes
is
in
use
and
you're
trying
to
get
security
coming
in
after
the
fact
right
developers
are
racing
in
a
million
miles
an
hour
to
go
to
these
platforms.
It's
super
easy
to
provision
these
clusters
and-
and
you
know,
to
repurpose
bare
metal
or
vms
for
kubernetes
now
and
security
team
is
forced
to
come
in.
A
I
mean
you
know
it's
like
tackling
anything
right
with
with
cloud
10
years
ago
you
got
to
carve
off
little
manageable
bits.
You
got
to
be
willing
to
make
exceptions
and
understand
where
you
know,
there's
business
priorities
right.
We
talk
about
risk,
a
lot
at
stack
rocks
and
you
know
security
organizations
want
to
reduce
that
risk,
but
sometimes
there's
you
know
a
need
right.
Certain
things
need
to
be
exposed
in
a
way
to
make
them
useful
and
application
teams
need
to
understand
what
some
of
that
risk
is
and
be
willing
to
to
accept
it.
A
So
I
actually
have
a
tough
time
answering
this
question
about
where
to
get
started,
except
when
the
customer
has
some
goal
like
hey,
we
have
to
be
pci
compliant
or
or
we
you
know,
we
want
to
follow.
Nist
like
it's
great,
to
have
a
set
of
marching
orders,
because
then
I
can
go
and
point
out:
hey,
hey,
pci,
hey
that
talks
specifically
about
some
of
the
the
networking
stuff
that
neil
was
addressing
right
and
minimization
of
privileges
is
frankly,
you
know
a
bog
standard
part
of
every
compliance
benchmark
out.
A
Some
applications
are
the
the
crown
jewels.
Some
applications
are
frankly,
you
know,
you
know
that
we
need
to
run
them,
but
they're,
not
they're,
not
super
critical
right.
So
if
organizations
have
a
means
of
identifying
that
and
specifying
how
that
works
here,
kubernetes
gives
us
a
little
bit
of
help
with
being
able
to
use
metadata
like
a
namespace
like
labels
and
annotations
like
make
use
of
those
standards
to
express
something
about
the
priority
of
it.
It'll
help
everybody
in
operations
and
development
and
and
others
it'll
help
security
teams
make
a
decision
about.
A
You
know
about
exceptions
to
those
policies,
so,
in
general,
the
way
to
approach
this,
I
think,
is
lots
of
tools,
lots
of
visibility,
there's
tons
of
stuff.
I
would
start
with
the
crown
jewels
right.
I
want
to
identify
a
particular
name
space
that
has
this
super
important
client
data
in
it
or
you
know
it's
sensitive
regulatory
data
or
whatever
it
might
be,
and
that's
where
we
start
to
apply
the
scrutiny
and
start
to
to
enforce
things
and-
and
you
know,
notifications
and
warnings
and
then
followed
by
by
enforcement.
A
One
of
the
things
that
we've
seen
is
a
tendency
for
organizations
to
treat
you
know:
production
really
differently,
security,
wise
from
from
development
and
and
uat
right.
Development
environments
are
usually
these
sandboxes
that
are
kind
of
like
throwaway
they're
a
mess,
but
we
know
that
attackers
find
them
just
as
valuable
as
your
production
applications
right,
maybe
even
more
so
so
I'm
starting
to
get
away
from
saying
that
you
know
hey.
You
could
warn
somebody
about
this
in
development,
but
let
them
run
whatever
they
want.
A
Whatever
the
trendy
you
know,
coin
of
the
the
week
is
so
I
think,
having
that
kind
of
scrutiny
like
you
quickly
need
to
move
from
thinking
about
one
production
application
to
to
getting
to
basically
an
a
you
know,
an
organization-wide
policy
there's
a
couple
of
steps
you
can
take
in
there,
but
you
need
to
get
to
that
organization-wide
strategy.
So.
C
You
know
michael
there's,
two
other
things
that
occurred
to
me
and
you're,
both
both
of
your
last
two
questions:
war
game,
this
stuff
right,
don't
wait
until
log
for
shell
2.0
comes
out
to
figure
out
where
all
of
this
information
is
who
owns
which
pieces
of
it?
Who
needs
to
do
what?
How
you
quickly
resolve
a
vulnerability
and
ship
a
new
image
go!
Do
that
stuff.
C
Today,
you
know
it's
january,
everybody's,
probably
a
little
slow
but
periodically
work
through
these
sorts
of
situations,
and
I
think
the
other
thing
that
goes
along
with
that
is
know
your
outside
resources,
your
vendors
and
and
other
people
who
can
help
right.
So
if,
if
you're
running,
open
shift
and
acs
stack,
rocks
and
you're
using
red
hat,
ubi
images
know
how
to
get
in
touch
with
us
or
whoever,
whoever
your
vendors
in
those
spaces
are.
C
B
B
D
Yeah,
neil
neil,
I
like
it,
I
like
how
you
kind
of
brought
it
back
to
something
simple,
which
is
just
like
get
everybody
in
a
room
and
and
play
these
things
out
and
talk
about
it
right,
like
you,
don't
need
to
like
you,
don't
need
to
be
advanced,
you
don't
need
you
know
by
getting
getting
all
the
relevant
parties
in
a
room.
I
was
meeting
with
a
a
university
the
other
day,
a
large
university
in
california,
and
they
you
know
they
didn't
have
all
the
processes
in
place.
D
They
didn't
have
all
the
technologies,
they
didn't
have
all
the
advancements,
but
what
they
had
was
a
desire
across
all
the
teams
to
work
towards
the
mark.
You
know-
and
I
thought
that
was
really
really
cool,
to
see
that
when
one
of
the
developers
you
know
we
go
hey.
What
do
you
think
about
security
and
he
goes?
I
just
want
to
build
things
in
a
safe
way
and
not
do
something.
D
That's
going
to
go
against
what
the
organization
is
trying
to
do,
and
it
was
just
it
was
such
a
simple,
like
quote,
but
it
reflected
like
the
appropriate
mindset
right
like
if
nothing
else
if
everybody
gets
in
a
room
across
platform,
security
operations,
development
and
starts
talking
about
hey.
This
is
a
real
problem.
You
know,
let's,
let's
have
like
regular
occurring
meetings
about
the
the
the
realities
of
of
cyber
security
risk.
I
I
think
that's
like
that.
Like
that's
like
huge
right,
you
know
like
so
I
don't.
I
wanna.
D
A
Okay,
so
silver
lining,
if
log4j
is
the
catalyst
for
you
know
for
having
these
discussions
to
say
you
know:
hey
we've
got
this
problem.
It's
widespread.
We've
got
to
have
another,
the
next
one.
You
know
the
dark
corners
get
illuminated
a
little
bit
and
teams
start
to
think
about
how
to
make
this
better.
I
mean
it's
speaking
to
all
the
you
know,
all
the
current,
the
current
trends
and
security
and
the
the
news
you
see
around
supply
chain
and
vulnerabilities
and
compromise
vendors,
and
you
know
being
able
to
sort
this
stuff
out.
A
B
Yeah
quickly,
I
have
a
little
bit
of
a
hot
potato
for
the
end
topic
because
we're
coming
up
on
time
so
because
it's
an
open
source
vulnerability
there
has
been
conversation
about
you
know
is
it
is
open,
source,
secure
and
like
what
is
secure,
open
source.
You
know,
how
do
we
make
sure
all
these
packages
are
maintained,
just
kind
of
want
to
throw
it
out
there?
You
know,
what's
your
opinion,
do
you
think
it's
overblown?
A
Well,
I
mean
if
this
was
a
commercial
product,
the
same
vulnerability
would
be
present.
We
just
know
a
lot
less
about
it
right
I
mean
there's,
never
a
point
where
hiding
any
of
this
stuff
really
makes
makes
any
sense
in
terms
of
security,
so
I
think
that
open
source
here
really
is
you
know
this
is
one
of
the
shining
moments
right
that
you
know,
vendors
that
are
dependent
on
this
were
able
to
easily
determine
that
the
open
source
components
in
their
environment
were
impacted
by
this.
A
The
suppliers,
like
red
hat,
were
able
to
quickly
alert
customers
to
it,
and
you
know
supply
fixes
as
soon
as
those
became
available,
because
it
was
very
obvious
to
everyone.
There's
pressure
on
anyone.
Who's
got
this
known,
supply,
vulnerable
version,
and
I
think
that
the
process
makes
sure
that
it's
there
it's
easier
to
do.
Diligence
when
you
know
when
everything
is
open
in
this
way,.
B
A
Right,
you
can't
get
that
kind
of
collaboration
with
a
closed
source
environment
right
and-
and
you
know
you
have
to
depend
on
the
you
know-
the
responsibility
of
the
vendor
to
disclose
those
things
when
they
come
up
in
a
closed
source.
You
know,
especially
when
something's
being
shipped
to
you
as
a
binary.
You
know
an
operating
system,
image
a
router
or
switch
image.
You
know
those
things
aren't
very
transparent
and
so
you're,
relying
on
the
goodwill
of
the
the
vendor
that
supplied
it
and
their
expertise.
Now
most
vendors
are
are
responsible
in
that
way.
A
C
You
know,
I
I
think
it's
a
software
problem,
it's
not
an
open
source
or
a
closed
source
problem
right.
So
it's
it's
really
about
having
good
process
being
able
to
find
these
things
having
vendors,
you
trust
and
can
work
with,
and
then
you
know
the
assume
breach
stuff,
limiting
the
the
blast
radius
being
able
to
find
anomalies
all
of
the
stuff,
because,
no
matter
how
good
your
vendors
are,
no
matter
how
good
you
are
at
this
stuff
at
some
point,
somebody's
going
to
be
faster,
smarter,
luckier
than
you
are
going
to
compromise
an
asset.