►
From YouTube: DevSecOps is the Way (S1E9): Remediation Month! Full-Lifecycle Cloud Remediation at Scale
Description
In this monthly series, learn how Red Hat weaves together DevOps and Security to master the force called DevSecOps. This show brings you Red Hat products and our security ecosystem partners to aid in your journey. October is Remediation month! In this episode, we will discuss how easy can be to effectively identify and remediate risk and reduce your time-to-resolution by analyzing data within the context of your cloud environment, correlating vulnerabilities to layers to know exactly how vulnerabilities were introduced into an image, and then using that analysis to intelligently prioritize remediation. We’ll also guide on how to implement continuous assessment-informed remediation by hooking directly into developer’s workflow and using runtime checks to enable remediation automation based on policies that address risk like cloud security misconfigurations.
Bring your lightsaber and be prepared to train hard... may the DevSecOps be with you!
A
A
A
A
A
I
just
wanted
to
let
everybody
know
that
this
is
a
series,
a
monthly
series.
Sometimes
we
have
two
shows,
but
we
also
produce
some
podcasts
and
you
can
see
the
different
monthly
categories
that
we've
been
exploring
over
the
last
few
months
around
devsecops
everything
from
vulnerability,
analysis,
compliance,
identity,
application
analysis,
and
this
month
november
is
all
about
remediation.
B
Absolutely
thank
you
dave
and,
first
of
all,
thank
you
very
much
for
having
me
here.
So
welcome
you
all
to
this
month's
edition
of
the
show.
I
hope
I
can
add
a
little
bit
more
value
to
you.
My
name
is
hari
srinivasan,
I'm
a
senior
director
of
products
for
prismacloud
compute,
which
is
responsible
for
compute
workload
protections.
B
So
that's
my
background
and
at
palo
alto,
I'm
responsible
for
the
compute
workload
protection,
I'm
hoping
today
we
can
have
a
nice
conversation
about
how
you
can
benefit
and
out
of
utilization
tools
which
are
there
in
the
market
and
kind
of
get
some
new
perspective
about
how
to
protect,
how
to
protect
your
environments
in
a
devsecops
way.
Thank
you.
Dave.
A
B
It
it
does
so
when
we
think
about
compute,
it
actually
kind
of
has
a
computer
workload.
It
actually
does
primarily
two
different
two
two
things:
one
about
different
kinds
of
architecture,
containers,
the
most
prevalent
and
popular
and
upgrades
container,
kubernetes
hosts
or
virtual
machines,
serverless
functions
and
the
application,
which
actually
also
runs
on
top
of
it
as
well
like
we
actually
have
a
a
solution
for
web
application.
Api
security,
so
the
com
compute
encompasses
both
of
these
things
within
the
prismacloud
family,
and
it
does
so
across
the
entire
pipeline.
A
Today's
or
this
month's
topic,
really
is
remediation,
which
you
know
is,
is
always
sort
of
a
silver
bullet
or
or
a
holy
grail
of
trying
to
fix
issues
automatically.
I
guess
in
the
market
today,
where
do
you
see
this
space
in
terms
of
how
customers
are
adopting
it?
What
what
processes,
what
technology.
B
That's
a
great
that's
a
great
question
dave
so
so
talking
about
remediation
right.
There
is
the
in
the
security
world.
Remediation
has
been
there
for
a
long
time,
there's
a
established
process
for
detecting
of
incidents
and
having
a
response
and
even
remediating
in
different
layers,
but
very
specifically
in
this
new
world
of
cloud
native
technologies
and
new
people.
B
New
players
involved
into
the
space
remediation
becomes
a
very
interesting
thing
because,
like
we
are
when
we
are
addressing
developers,
they
want
the
fast
and
the
efficient
way
to
kind
of
deliver
their
application
and
they're
all
happy
to
say
that
hey.
If
you
could
tell
me
what
are
the
problems,
I
have
from
a
security
stand
point
of
view,
which
will
be
a
for
risk
for
my
application
later
they
would.
They
would
be
more
than
willing
to
kind
of
make
those
modifications
and
kind
of
forget
get
moving
with
their
software
development
process.
B
So
remediation
for
their
world
is
actionable
information
for
them
within
their
tool
set,
so
they
can
quickly
kind
of
remedy
it.
So
it's
like
being
more
prescriptive
and
being
more
easy
to
accomplish
compared
to
a
lengthy
analysis
process
is
the
new
way
of
our
modern
way
of
thinking
about
remediation
right,
be
prioritize.
It
be
prescriptive
and
be
programmatic
in
a
way
that
you
can
actually
kind
of
accomplish
it
faster.
So
that's
where
I
see
market
well,
like
that's,
why
I
see
customers
moving
as
they
adopt
these
new
technologies.
B
B
How
can
I,
how
can
I
get
a
visibility
into
it?
That's
a
second
layer.
Third
layer
is,
as
I
continuously
build
the
applications
and
test
it
integrating
security
into
it
with
that
I'll.
Just
take
one
moment
to
kind
of
show
you
this
interesting
functionality,
which
I
think
is
actually
pretty
pretty
popular
across
our
the
user
space,
which
we
see.
I
hope
you
can
see
my
screen.
B
So
this
in
this
case
you're
integrating
with
the
repository
pulling
in
a
kubernetes
aml
file
and
analyzing
that
against
a
data
against
misconfiguration
issues
in
this
case
like,
for
example,
my
file,
this
particular
cluster
shows
that
it's
like
the
endpoint
is
accessible
to
public
is
publicly
enabled
this
other
one
which
actually
says
that
this
overtly
purpose
of
traffic.
You
actually
also
have
things
like
the
logging
plane
is
disabled.
B
That's
the
one
which
actually
it's
not
just
about
telling
you
what
the
problem
is,
tells
you
it
tells
you
the
different
definition
of
like
why
why
this
problem
exists
and
all
the
history
behind
it,
and
I
can
also
go
ahead
and
say
that
okay
fix,
when
I
say
fix
it,
basically
submits
a
pr.
So
you
get
to
have
the
rest
of
all
the
prs
created
for
it,
and
now
I
am
in
the
dev.
B
The
security
tool
is
in
the
developer
pipeline
chain
to
kind
of
do
this
initiative
because
for
from
from
palo
alto
perspective,
we
have
this
tool
integrated
into
the
product.
We
also
have
an
open
source
offering
called
checkoff
with
checkoff
users
can
actually
kind
of
integrate
that
independently
into
the
pipe
into
their
entire
tool
chain,
to
kind
of
do
it
so
to
your
question:
where
does
it
apply?
It
starts
with
the
journey
starts
here.
If
I
may
point
before,
even
you
kind
of
move
on
to
a
continuous
integration
testing
it
is
about
when
I'm
developing.
A
Yeah,
I
think
the
age-old
question
with
remediation
is:
when
do
you
automatically
fix
and
when
do
you
need
some
sort
of
manual
review
before
you
apply
the
fix?
So
what
do?
What
do
you
see
like
your
customers
doing?
Are
they?
Are
they
one
integrating
that
fix
into
the
ci
cd,
so
prs
are
automatically
created,
or
do
you
see,
customers
more
taking
the
stance
of
well,
we
want
to
want
to
you
know,
look
at
this
data
first
make.
B
Sure
so
it
is
a
it's
the
conversation
of
maturity
and
kind
of,
and
it's
also
the
conversation
of
like
it's
almost
like
you
get
trained
and
used
to
certain
level
of
checks
right,
so
nobody
wants
to
fix
automatically
because
everybody
every
application,
that's
the
reality
right.
Every
application
is
little
unique,
but
again
it's
the
journey
which
they
take
towards
it.
If
I
know
the
known
problems,
it
can
be
fixed
faster
they
would
like
to.
But
that's
where
the
automated
pr
comes
into
place,
we
are
creating
a
pr
not
merging
it
automatically.
B
Every
kubernetes
administrator
is
creating
a
new
new
yaml
file
for
every
incarnation
of
an
application
or
a
piece
of
alligator,
and
most
of
it
is
like
copying
from
a
different
version
modifying
a
bunch
of
things
and
kind
of
repurposing
it.
In
this
case,
the
number
of
issues
which
you
find
some
of
them
are
kind
of
very
standard
in
your
organization
which
you
can
fix
automatically.
You
will
accept
an
automatic,
automated
commitment
to
a
pr.
You
know
most
other
cases.
You
want
to
take
it
to
the
end
where
you
have.
A
A
Yeah
similar
it's,
it's
doesn't
seem
to
be
a
dominant
answer
in
the
market,
there's
some
that
are
really
risk
adverse
and
want
to
make
sure
that
they're
seeing
everything-
and
I
think
it
all
also
depends-
like
you
mentioned-
on
a
maturity,
but
also
volume
so
in
business,
critical
application
type
stuff.
But
if
they,
you
know
it's,
it's
not
much
of
a
lift
when
you're
automatically
creating
prs,
but
you
can
always,
you
know,
deny
those
prs
and
delete
them
versus
having
somebody
go
to
a
tool
like
palo
alto
and
just
viewing
the
details
there.
B
We
we
actually
annotate
those
prs
with
as
much
as
information
as
needed,
crispy
so
that
they
have
some
context,
and
most
of
it
is
straightforward,
but
I
agree
with
you
in
general:
nobody
wants
to
push
a
commit
button
automatically
from
a
tool,
but
rather
they
would
allow
to
take
you
to
the
end,
which
says
I
have
a
pr.
This
is
the
reason
for
the
pr
and
then
take
it
from
there.
Yeah.
A
A
B
B
Said,
there's
also
a
need
for
shifting
right
as
well,
but
things
don't
disappear.
Problems
happen,
they
don't
disappear
automatically
from
a
from
a
from
a
utilization
stand
point
of
view.
Some
of
the
older
tools
still
exist,
the
ir
tools
like
ticketing
systems
and
sim
systems,
and
other
things
are
all
there
and
and
as
a
security
tool
it
all
the
most
of
them
will
look
for
a
easy,
quick
integration
into
their
existing
processes.
B
So
remediation
can
have
two
kinds
of
notions.
One.
Can
I
prevent
a
problem
from
happening
these
new
architectures,
like
kubernetes
and
other
things?
It's
it's
wonderful
in
a
way
that
you
can
actually
even
prevent
the
problem
from
happening.
If
some
of
those
standard
configuration
issues
which
you
which
can
lead
into
a
potential
opening
of
a
potential
threat,
vector
runtime,
so
you
can
prevent
them
from
happening
and
in
some
other
cases,
once
a
problem
happens.
How
do
you
react
to
it?
B
What
kind
of
a
data
do
you
collect
and
how
do
you
kind
of
audit
it,
and
how
do
you
move
forward?
In
that
case,
all
the
tool
integration
is
still
valid.
I
can
take
a
quick
detour.
I'll
show
you
one
interesting
aspect
when
it
comes
from
a
preventing
standpoint
of
you
before
even
talking
a
little
bit
deeper
about
how
to
take
an
action
right
like
just.
Let
me
share
the
screen
quickly.
B
So
what?
What
do
you?
What
you're
seeing
on
the
screen,
like
you
saw
about
the
yaml
file,
which
you're
doing
in
addition
to
that?
We
also
have
this
option
for
preventative
measures,
which
is
like,
as
you
kind
of
go
down
to
kubernetes
kubernetes,
provides
you
with
this
beautiful
capability
for
admission
control,
admission,
control,
kind
of
wets.
What
can
go
into
on
to
a
deploy,
a
deploy
onto
a
which
can
be
deployed
right
basically
onto
a
runtime
with
open
policy.
Agent
is
extremely
popular
with
the
language
called
rego.
This
is
being
defined.
B
So
what
you
see
on
the
screen
here
is
from
palo
alto.
Of
course,
we
kind
of
have
an
integration
in
this
sense,
the
same
sense
within
admission
controller,
so
we
can
deploy
and
admission
controller
which
can
help
you.
If
you
look
at
it.
Some
of
these
interesting
things
are
like
privileged
part,
being
created,
alert
on
particular
privilege,
part
being
created.
You
can
actually
move
down
to
from
an
alert
perspective
down
to
a
block,
which
means
that
it
will
even
stop
something
from
actually
happening.
B
So
you
can
you
can
in
the
you,
can
enable
a
quick
policy.
You
can
say
that
do
not
allow
privileged
parts
into
the
picture
and,
of
course,
if
you,
you
can
also
import
rules
from
outside
other
regal
libraries,
which
you
see
on
the
internet,
which
you
want
to
pull
in
and
kind
of,
have
copy
those
policies
over.
You
can
import
those
policies
and
you
can
set
those
things
as
soon
as
you
set
those
things.
Everything
kind
of
I'm
switching
screens
here
to
show
you
all
the
events.
B
Anything
which
gets
created
is
got
alerted
and
that's
what
I
said
like
if
you
have
a
policy
or
front
application.
So
this
is
a
form
of
remediation.
I
would
even
call
it
like
it's
it's
the
preventative
measure
towards
actually
being
remediated.
Since
you
also
really
mentioned
this
thing,
the
whole
volume
business
so
a
lot
of
environment
things
are
very
flexible,
ephemeral,
spins
up
and
spins
down.
So
how
do
you
manage
things
and,
of
course,
the
second
part
of
it?
B
Provide
you
with
enough
context,
and
you
can
use
this
information
to
be
pulled
into
your
remediation
tools,
which
you
can
either
trigger
a
playbook
to
kind
of
automatically
kick
off
things
in
the
kubernetes
world
and
container
world.
The
best
part
is
to
kind
of
you
can
drop
the
container
pod
and
have
the
kubernetes
spin
up
a
container
from
a
known
good
previous
image.
So
in
no
time
you
actually
have
an
application
up
and
running
with
a
better
one.
So
you
don't
need
to
kind
of
live
with
the
malware
quarantine.
B
A
Yeah
I've
always
heard
well,
you
don't
want
to
shut
down
your
mission
critical
applications,
but
I
think
kubernetes
openshift
allows
you
to
to
do
that
on
specific
issues.
You
know
suspicious
activity
because
it'll
gen
back
up
another
pod,
and
if
you
have
you
know
auto
scaling
and
a
bunch
of
pods
out
there
you're
right,
you
can
boot
back
up
from
a
known
version.
So
what
are?
What
are
some
of
the
typical
suspicious
activities
that
you
would
want
to
destroy
a
pod
on.
B
That
you
see
that's
a
good
question
right.
Typically,
we
offline,
we
see
like
a
bunch
of
these
things
of
activities
right.
One
is
malware
malware
coming
into
your
system
from
the
whole
supply
chain
process
right,
like
people,
picking
up
images
which
are
which
are
which
are
probably
not
completely
vetted
or
probably
not
clearly,
kind
of
analyzes.
That
kind
of
kind
of
jumps
into
the
system.
B
The
other
one
which
which
actually
kind
of
also
happens
here,
is
the
crypto
jacking
thing
thing,
pods
being
used
for
multiple
other
processes
with
the
over
a
period
of
time.
It
has
moved
from
just
being
able
to
kind
of
signature,
identify
those
binaries
to
now
having
a
clear
set
of
heuristics
and
ai
driven
methodology
to
know
if
there
is
an
actual
crypto
miner
activity
happening.
B
I've
seen
customers
kind
of
set
some
of
these
things
to
be
like
auto
block
and
and
again
not
on
all
environments
and
in
some
of
the
environments
I've
seen
the
larger
customers
because
of
the
scale
of
it,
some
of
the
lower
end
environments.
They
are
auto
block
these
things,
which
means
that
it
basically
kills
the
container
and
the
kubernetes
takes
care
of
spinning
it
up
from
a
better
one
right.
So
those
are
the
primary
ones
and
of
course,
there
are
some
suspicious
binaries.
B
Another
thing
you
basically
lock
down
the
image
because
the
whole
container
world
and
not
just
containers,
even
they
when
the
virtual
machine
world
is
moving
towards
a
very
immutable
way
of
dealing
with
stuff.
So
they
want
to
lock
down
as
much
as
processes
like
say,
having
an
ssh
open.
You
know
that's
supposed
to
not
supposed
to
be
there,
so
take
those
things
off
which
actually
has
an
ssh
processes
open
and
spin,
something
up
which
actually
from
an
image
which,
without
that
particular
process,
has
been
actually
being
actively
opened.
B
A
B
Absolutely
the
traditional
tools
are
very
much
embedded
into
deep
into
the
processes
process
change
within
the
industry,
so
they
they
are
like
the
ticketing
or
an
ir
tool
doesn't
go
away,
but
there
are
modern
incarnations
of
those
kinds
of
tools
or
tool
chain.
The
new
vendors
in
the
market
will
actually
do
a
better
soar
than
the
previous
ones,
better
threat
intelligence
on
top
of
the
incidents
that
have
been
identified
to
be
able
to
distill
better.
B
So
there
is
always
an
evolution
in
that
space
from
a
from
a
user
standpoint
of
you,
things
have
also
changed
a
little
bit
to
kind
of
previously.
Nobody
is
terminally
terminally
in
to
a
container
to
take
it
like
a
like
a
like
a
dump
of
all
those
artifacts
to
kind
of
move
forward.
Rather
they
were
like
kind
of
frequent
replacement
of
a
model
right.
B
I
would
actually
kind
of
also
see
is
it's
not
just
about
one
is
about
reacting
to
it,
but
also
kind
of
using
the
learning
which
is
there
from
the
shift
right,
if
I
may,
in
the
right
side
of
the
run
time
kind
of,
has
a
cyclical
process
like
pulling
this
back
into
your
ci
cd
pipeline.
It's
just
like
a
common
action
right.
If
you
prevent
you,
you
detect
you
take
the
detection
back
and
kind
of
channel
it
back
from
a
sock
to
a
devops
cycle.
B
These
new
tools
are
actually
also
involved
in
kicking
off
some
of
those
automation
processes
which
update
a
policy
set
which
are
primarily
used
in
sea
ice.
Anything
new
malware
being
identified,
a
new
cv
breaks
out,
there's
some
identification,
just
false
pulls
back.
So
it's
a
change
in
evolution
in
terms
of
ir
processes
and
evolution
in
terms
of
a
tool
chain.
Traditional
tools
may
or
may
not
work.
Some
of
them
have
modified.
Some
of
them
are
kind
of
still
in
the
order,
space
and
still
older
ways
of
doing
things.
B
A
You
know
one
one
thing
we
always
talk
about
on
this
show
is
devops
equals
devsecops.
We
understand
security's,
always
been
part
of
devops,
but
we
we
like
to
say
devsecops,
because
we
want
the
security
teams
to
have
a
seat
at
the
table,
and
you
know
that
they're
as
much
involved
in
the
process
as
the
dev
developers
and
operations,
folks
that
they,
you
know
that
they
share
the
same
sort
of
kpis
things
like
that.
A
B
There's
an
opportunity
they're
telling
you
before
fix
it
early
on
and
the
one
the
best
part
here
is
security
can
bring
in
a
lot
more
interesting
context.
If
a
zero
day
comes
and
if
a
new
thing
gets
identified,
they
have
their
intelligence
to
kind
of
distill
and
say
what
they
need.
So
it's
actually
a
a
good
handshake
where
security
can
help
remediate
better
is
by
a
being
able
to
help
developers
to
kind
of
look
at
what
to
remediate
forward,
and
there
is
a
good
level
of
handshake
which
is
required.
B
Requiring
detailed
information
for
a
dev
perspective,
the
security
teams
still
have
the
control
or
they
have
the
guidance
factor.
I
wouldn't
even
use
the
word
controller.
They
are,
they
are
actually
able
to
guide
the
team
a
little
better
with
their
insights.
On
these
things
like,
let
me
give
you
an
example.
I
think
I
can.
This
will
be
better
demonstrated
right,
it's
something
which
alive,
which
I
recently
did
with
another
user
of
ours,
and
then
they
kind
of
really
liked
this
idea.
So
so,
let's
say,
if
I
am
a
dev
developer,
I
live
in
jenkins.
B
I
live
in
jenkins.
I
live
in
my
build
outputs.
I
get
a
slack
message
saying
that
hey
this
build
failed
because
of
these
high
seas:
critical
vulnerabilities.
What
do
I
do
next?
I
get
to
know
the
details,
so
I
get
to
kind
of
come
to
jenkins.
Look
at
like
that.
My
build
fail.
I
can
have
two
options:
drop
the
build,
make
something
else
or
make
figure
out
what
to
fix
it.
B
So
a
tool
will
help
you
to
tell
you
what
needs
to
be
fixed
like
what
the
area
needs
to
be
fixed
and
they
can
kind
of
react
to
it
or
that
better
way
of
visualizing
this
a
little
nicely
into
the
product
results
you
can
visualize.
This
is
where
the
security
team
comes
into
play,
where
they
want
to
know
what
the
developer
is
actually
seeing.
They
get
to
see
that
okay,
the
same
image
same
thing,
which
actually
happened
on
the
ci
pipeline.
B
They
get
to
see
what
is
going
on
in
that
thing,
which
layer
is
actually
failing.
What
are
they
incorporating?
Where
does
those
vulnerabilities
exist?
So
this
is
a
from
a
view
perspective,
but
where
can
where
does
security
team
become
a
better
guide?
Is
they
have
some
level
of
influence
in
terms
of
helping
teams?
Do
a
little
better
and
also
get
exceptions
as
well
so
from
our
product?
We
have
this
option
for
adding
a
rule
for
the
ci
process.
B
It
can
have
a
very
minimalistic
way
of
like,
let's
let
me
say
my
demo
rule,
I
let's
say
dave
favorite
application.
I'll
just
use
this
one
here
and
say
that
dave
was
my
developer.
Who
has
his
favorite
application?
He
would
like
to
know
if
he
has
high
critical.
He
would
like
to
fix
it,
but
at
the
same
time
dave
does
a
lot
of
work
during
the
process.
He
generates
multiple
builds
and
he
just
doesn't
want
to
keep
on
kind
of
looking
at
an
output
to
do.
B
He
wants
to
kind
of
even
help
him
manage
it
a
little
better,
so
they
can
set
up
like
a
if,
if
sort
of
critical
vulnerabilities
identified
set
it
to
critical
and
of
course
not
all
the
things
can
be
addressed
sooner.
Some
applications
you
might
want
like
critical
is
like
I.
I
need
like
five
days
of
like
a
day
of
grace
period,
or
I
would
like
to
kind
of
go
to
say
that
I
need
like
few
days
of
crispy
right
so
that
the
dave
has
actually
has
72
hours
right.
B
Let's
say
three
or
three
days
now:
comes
the
security
team
play
right
like
when
they
create
these
things,
specifically
for
your
application,
which
is
basically
I'm
setting
it
for
the
scope
for
dave's
application.
Your
application
dave-
and
I
can
I,
as
a
security
team,
can
also
say
that
you
know
what
dave
they've
sent
me
a
message
saying
that
I
need
to
have
some
exceptions
on
some
cvs,
which
are
great
because
I
don't
understand,
I
cannot
fix
it
right
away.
I'll
have
a
day's
time.
B
This
is
that
happy
medium.
This
is
where
security
teams
and
dev
are
working
together.
This
new,
this
new
terminology,
devsecops,
are
sector
sectors.
However,
you
want
to
call
it
eventually.
They
are
having
a
seat
at
the
table
where
a
they
are
giving
you
or
enabling
you
with
the
tool
which
gives
you
information,
b,
they're
able
to
guide
you
through
the
process
and,
more
importantly,
see
all
of
this
c
for
collaboration.
B
A
Nice
yeah,
just
as
you
were
showing
that
demo,
we
actually
got
a
question
from
the
chat
from
endograph
and
they're
asking.
Could
you
show
an
example
where
shift
write
gives
feedback
to
ci
cd,
which
I
think
you
talked
about
a
little
bit
and
then
what
could
you
think
about
stack
trace,
runtime
and
how
does
that
help
ci
cd.
B
Absolutely
so
that's
a
great
question
thanks
for
asking
that
right,
yeah,
so
we
talked
about.
I
can
break
this
into
three
parts.
Part
a
is.
We
talked
about.
Prevention
is
better
than
radiating
at
some
point
of
time,
and
the
kubernetes
environment
gives
you
the
flexibility
right
now.
Let's
take
this
example
from
kubernetes,
you
don't
have
these
admission
controllers
turned
on
you,
don't
have
these
rules
turned
on
now.
You
have
this
new
thing,
which
is
actually
kind
of
spinning
things
up
and
you
would
like
to
kind
of.
A
B
Have
an
option
to
say
that,
okay,
I
don't
know-
I
have
not
turned
on
the
admission
controller
and
my
team
is
not
responsible
yet
to
kind
of
take
this
up.
Yet
it's
a
little
bit
time
away.
What
can
you
do
to
kind
of
do
the
loop
cycle
and
how
does
it
look
back?
The
loop
back
actually
happens
by
in
terms
of
audits.
B
So
if
you
have
audits
from
admissions
you
get
to
kind
of
see
all
these
things
being
created,
you
either
have
a
kubernetes
audit
of
things
that
just
happened
or
your
audits
from
a
security
team
perspective.
These
are
the
things
which
you
get
alerted
on.
You
can
trigger
this
back
to
a
policy
to
be
added
into
the
previous
policy
for
admission
controller,
which
we
saw
wherein
these
now
can
be
a
new
set
of
policies.
We've
been
enabled
again
some
of
the
tools,
including
us
and
prisma.
B
A
B
Demo,
application
not
a
real
application,
not
to
have
these
numbers
on
my
real
application
for
him,
but
if
I'm
a
security
team,
if
I
have
this
much
amount
of
problems,
I
at
least
would
like
to
see
a
matrix
of
like
where
the
problem
lies
right.
So
what
one
of
the
things
which
we
also
do
is
when
we
identify
some
problems
and
we
want
to
kind
of
funnel
it
back
into
the
process.
We
have
these
opportunities
to
kind
of,
because
we
do
this
whole
profiling
and
modeling
when
I
say
vs
in
the
prismacolor
tool.
B
If
you
identify
something
to
be
a
false,
positive,
false
negative
or
you
want
to
identify
something
as
to
be
a
thing
which
you
want
to
kind
of
push
forward,
you
can
extend
the
learning
back,
so
we
extend
the
learning
back,
which
means
that
it
learns
this
new
application,
in
addition
to
it,
vulnerability
is
being
detected.
New
things
being
detected
automatically
gets
added
to
the
intelligence
stream.
B
So
that's
a
that's
an
invisible
layer
of
threat
intelligence
which
actually
kind
of
rolls
into
the
product
a
better
way
of
showing
this
is,
I
think,
maybe
I
can
show
it
this
way
like
when
I
define
the
rules,
I
define
these
rules
and
one
of
the
things
which
we
always
have
for
anything
is
use
the
use,
the
intelligent
stream
to
kind
of
detect
something
use,
advanced
thread
protection.
So
one
of
the
things
which
we
do
in
the
tool
is
automatically
keep
updating.
This
advanced
threat
protection
rules,
so
these
things
get
keep
sure
this
church.
B
This
is
the
third
part
it
keeps
churning.
We
identify
new
things.
We
automatically
kind
of
loop
back
into
the
system,
so
you
don't
need
to
do
anything
as
an
end
user.
You
actually
are
consuming
a
threat,
intelligence
feed
which
is
actually
live
and
kicking
and
reacting
to
it.
So
those
are
three
parts,
maybe
helping
in
prevention,
helping
in
in
terms
of
better
modeling
of
application
to
kind
of
add
new
thing
detections
back
into
it,
so
you
can
prevent
better
across
all
the
other
applications
of
the
same
kind.
B
Three
is
this:
this
invisible
layer
which
actually
exists
within
our
system
which,
which
we
help
in
kind
of
populating.
So
when
we
apply
the
rule
set
in
ci,
we
get
to
see
the
new
malwares
which
are
previously
not
been
seen.
So
we
kind
of
look
back
automatically,
hopefully
the
the
the
the
person
who
actually
asked
the
question.
A
B
A
B
B
B
B
Which
is
basically
all
being
said.
Sorry,
all
being
said,
you
do
need
an
integration
into
into
the
process
chain
which
we
talked
about.
So
all
being
said,
a
you
need
the
logs.
You
need
the
data,
you
need
the
context
and
you
need
to
be
sent
to
certain
tools.
So
we
in
personal
cloud
integrated
like
a
a
wide
range
of
things
right.
It
can
be
a
simple
slack
or
a
jira.
I
think
I
for
my
teams
in
internally
here
we
actually
have
a
slack
channel.
B
We
keep
getting
some
reports
if
I
tell
anything
it's
anything
else
of
a
sec
of
a
threat
from
from
a
qa
environments,
but
if
you
have
a
tool
of
your
choice,
integration
of
your
choice,
so
be
it
or
be
it
much
more
open-ended.
Take
it
to
our
web
book.
Take
it
to
any
of
those
tools
and,
as
you
could
see
on
this
side,
it's
not
just
like
as
much
as
I
would
say
that
everything
should
be
automated.
I'm
saying
everything
could
be
a
closed
loop
system.
B
It
automatically
runs,
there's
also
a
little
bit
of
intervention,
and
here,
when
you
want
based
upon
the
problem
statement,
you
can
flexibly
choose
to
say
which
tool
and
whom
to
reach
to
where
they
became
the
decision
maker,
so
human
personal
involved
in
the
process,
or
at
least
enabling
them
to
act
more
efficiently
by
integrating
into
the
tool
chain
which
they're
used
to
so
that's
actually
important.
I
believe
we
and
other
vendors
we're
all
kind
of
cognizant
of
this
fact,
and
we
can
do
it
in
prismacloud
a
wide
range
of
integrations
in
that
front.
A
B
Yes,
yes,
so
we
do
have
integrations
with,
let's
say
the
popular
ones
like
splunk,
consumer
logic
and
other
things,
and
of
course
we
have
our
logs
being
flushed
to
syslog
as
well.
So
people
can
take
those
as
a
part
of
your
syslog
agent
integration
into
it.
If
they
choose
to
or
via
api,
we
can
do
directly.
We
actually
have
an
application
in
splunk
that
can
actually
be
deployed
directly
to
kind
of
pull
data
from
from
prismacloud
into
splunk.
A
Nice
splunk
is
one
of
red
hat's
partners
as
well.
So
if
anybody
has
any
other
questions
feel
free
to
add
them
to
the
chat
in
the
meantime,
I'll
just
put
up
the
monthly
security
series
slide
again
again,
this
is
a
part
of
a
monthly
series
that
we
do
called.
Devsecops
is
the
way
we
do
podcasts
live
streaming
shows.
I
would
direct
you
to
prismacloud
for
openshift
on
the
palo
altonetworks.com
site.
A
That's
going
to
be
exciting
and,
and
then
next
month
last
month
of
the
year,
is
all
about
platform
and
platform
security,
and
that's
going
to
be
a
lot
of
what
you
get
with
openshift
out
of
the
box
on
top
of
what
you,
which
you
would
not
get
with
kubernetes
upstream.
So
look
forward
to
those
conte
that
content
and
I
want
to
thank
hari
for
joining
us
today.
It
was
great
great
talking
with
you,
wonderful
demos
and
continue
to
look
forward
to
working
with
you
in
the
future.