►
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
All
right,
everyone,
thank
you
for
joining
us.
Welcome
to
today's
cncf
live
webinar.
How
to
achieve
comprehensive
protection
for
your
applications
and
workloads.
I'm,
Libby,
Schultz
and
I
will
be
monitoring.
Today's
moderating
today's
webinar
I'm,
going
to
read
our
code
of
conduct
then
hand
over
to
Yvonne,
Malia
senior
manager,
product
marketing,
Prisma
cloud
and
Mohit
Basin
senior
product
marketing
manager,
both
with
Palo
Alto
networks,
a
few
housekeeping
items
before
we
get
started
during
the
webinar.
You
are
not
able
to
talk
as
an
attendee.
A
There
is
a
q,
a
chat
box
on
the
right
hand,
side
of
the
screen
that
you'll
see,
please
feel
free
to
drop
your
questions
there
and
we'll
get
to
as
many
as
we
can.
At
the
end.
This
is
an
official
webinar
of
the
cncf
and,
as
such
is
subject
to
the
cncf
code
of
conduct.
Please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct
and
please
be
respectful
all
of
your
fellow
participants
and
presenters.
A
Please
also
note
that
the
recording
and
slides
will
be
posted
later
today
to
the
cncf
online
programs,
page
at
community.cncf.io
under
online
programs.
They
are
also
available
via
your
registration
link
and
the
recording
will
also
be
available
on
our
online
programs.
Youtube
playlist
with
that
I
will
hand
things
over
to
Yvonne
and
Mohit.
D
And
overall
security
and
then
we're
going
to
go
into
more
details
around
some
specific
risks
and
counter
measures
at
the
Run
stage,
pertinent
to
containers
and
applications
in
general,
and
then
we're
going
to
show
a
little
demo
of
our
product
and
how
it
maps
to
that
application.
Security.
Continuum
story
that
we
will
present.
D
D
D
Agent
based
defense,
in-depth
protection
in
order
to
provide
a
full,
comprehensive
Security
in
a
hybrid
Cloud,
World
distributed
environments
and
mixed
workloads
are
a
norm.
There's
a
growing
number
of
entities
to
secure
which
resulted
in
adoption
of
many
point
products
on
the
market
and
that's
the
reality
today.
The
way
I
see
this
ultimately
drives
the
investment
and
a
maintenance
and
operational
cost
up
which
inevitably
increases
the
complexity
brought
by
these
sound
operations.
That
leaves
many
blind
spots
on
one
side.
D
We
have
many
different
environments
infrastructure
as
a
service
platform
as
a
service
containers
as
a
service.
On
the
other
hand,
we
have
complexity,
that's
increasing
due
to
various
benefits
of
cloud.
We
have
microservices,
we
have
containers
and
so
on,
and
we
believe
in
a
unified,
platform-centric
approach.
D
We
want
to
ship
products
and
features
faster
security.
Operational
teams
are
the
integral
part
in
the
grand
scheme
of
things,
and
we
believe
that
security
needs
to
be
spread
out
across
these
different
layers
and
all
the
teams
that
are
involved
for
that
shared
responsibility
model,
and
there
are
two
types
of
responsibility
models:
one
that
you
have
with
your
cloud
service
provider,
where
their
responsible
for
everything
from
the
infrastructure
below
and
onus
is
the
need
to
manage
your
applications
and
security.
D
D
Now,
how
workloads
have
changed,
allowing
for
more
degrees
of
freedom
where
attacks
surface
effectively
expands
and
what
the
workloads
have
become?
I
will
describe
with
these
four
characteristics.
We
have
location,
size,
duration
and
an
architecture
and
the
way
I
would
rationalize
this
from
a
location
perspective.
Workloads
are
portable,
they
can
be
on
and
off
cloud
and
data
center
air-gapped
environments
from
a
size
perspective.
It's
about
granularity
of
workloads.
We
have
technology
and
products
around
microservices.
It
effectively
enable
this
it's
much
easier
to
manage
an
application
this
way
throughout
their
life
cycle.
D
From
a
duration
perspective,
workloads
are
ephemeral
and
that's
a
good
thing.
Some
need
scaling
up
down
or
scaling
out.
Some
are
updated,
released
on
a
daily
basis
and
then
from
an
architectural
perspective.
You
know
immutable
workloads
again,
microservices
containerization,
proliferated,
use
of
serverless
functions
effectively.
Workloads
are
deployed
using
this
heterogeneous
tools
across
distributed
environments.
Why
is
all
this
important
for
us
where,
if
we
look
at
the
four
stages
in
this
modern
application,
life
cycle
I
mentioned
across
code,
build
deploy
and
Iran
the
stat?
The
attack
surface
effectively
increased?
D
My
bottom
line
here
is
that
traditional
security
controls
don't
fit
multi-cloud
environments,
there's
an
overall
lack
of
visibility
into
vulnerabilities
across
the
application
life
cycle,
everything
from
Cloud
misconfigurations
to
vulnerable
software
components
of
our
applications
that
attackers
can
use
to
enter
our
system,
containers
and
microservices-based
applications.
Serverless
functions.
They
all
require
a
very
different
architectural
option
for
enforcing
application.
Security
and
Legacy
systems
can't
provide
the
actionable
insights
into
these
heterogeneous
environments.
D
So
chances
are
you
have
a
distributed
environment.
You
have
mixed
workload,
types
different
application
Stacks.
You
know
that
a
subset
of
your
deployment
will
need
threat,
detection,
anomaly,
detection
and
runtime
prevention.
You
will
need
that
defense
in
depth,
maybe
not
for
100
of
your
Assets
in
the
cloud,
but
for
some
so
instead
of
making
that
leap
to
that
state
of
full
defense
and
depth
that
could
leave
you
with
more
questions
than
answers.
D
We
invested
in
agentless
workload
scanning
to
provide
this
application
security
continue
and
now
again
chances
are
you
don't
have
the
visibility
into
what's
running
across
your
Cloud
workloads?
So
maybe
start
with
that
visibility
into
running
environment
map
that
environment,
based
on
your
known,
onboarded,
accounts,
understand
the
workload
types
you
have
the
application
deployment
you
have
and
then
review
these
reports
and
craft
your
application
security
strategy
that
leverages
both
agents
and
agentless
capabilities
together.
D
Some
of
the
key
questions
that
are
driving
the
decisions
as
you're
starting
or
looking
to
change
something
in
your
application.
Securities.
First,
visibility:
initially,
you
may
not
know
what
you
don't
know
and
you're
looking
for
a
quick
way
to
gain
insights
into
the
running
environment,
plus,
there's
a
there's,
a
very
fast
pace
of
change,
as
we
all
know,
with
with
the
applications
and
and
containers
specifically
on
a
daily
basis.
D
So
that's
something
that
that
needs
to
be
incorporated
in
a
tool
that
that
visibility
of
of
that
base
of
change,
so
any
new
applications,
workloads
that
are
being
provisioned
and
deployed.
We
need
to
know
very
fast
about
those
and
then
scan
them
for
vulnerabilities
too.
You
may
be
thinking
about
how
deeply
integrated
you
want
security
to
be
with
your
environment.
What
permissions
you
need
to
set!
What's
your
level
of
comfort,
do
you
need
to
run
an
agent
here
or
not
for
that
defense
in
depth
and
and
three
it's
really
about?
D
What
is
that
you
would
like
to
accomplish
at
the
end
of
the
day,
I
think
both
agentless
and
agents
are
in
your
future,
so
maintaining
that
possibility
to
switch
at
any
time
with
this
same
pricing
model
is
something
we
have
built
now
we're
a
quick
slide
here
on
on
The
anti-agent
View
that
we
have
out
there
they're,
certainly
building
a
good
case
for
agently
scanning,
but
it's
not
really
about
one
versus
the
other.
The
truth
is,
there
are
many
agents
that
are
running
an
environment
today,
everything
from
monitoring
services,
kubernetes,
schedulers
and
so
on.
D
There
is
nothing
inherently
different
with
any
workload.
Security
agents
do
firewalls
impact
the
line
rate,
yes,
but
we
still
need
them
so
take
agent
resources
into
considerations
for
your
planning
and,
lastly,
maybe
difficult
to
get
the
Ops
Team
to
pretty
much
install
anything,
but
that's
not
the
reason
to
drop
security
and,
in
my
view,
working
together
across
their
teams,
is
more
difficult
than
producting
protecting
against
a
zero
day
threats.
You
have
to
implement
tools
and
processes
that
benefit
all
stakeholders
and
I.
D
Think
the
insights
you
gain
with
agentless
scanning
can
also
help
you
get
the
better
sense
of
what,
after
that
initial
scan
the
abstract
story
does
not
end
there.
We
need
to
apply
the
appropriate
model
on
a
per
workload
basis,
based
on
the
risk
requirements
calculate
that
risk
as
you
map
your
environments,
leverage
agentless,
where
frictionless
visibility
is
required,
and
then
leverage
agents
where
criticality
and
exposure
warrant,
runtime
protection
and
then
throughout.
D
This
presentation
also
show
how
why
this
is
also
important
from
a
web
application
security
perspective
and
then
for
that
we'll
show
a
little
animation
here
around
web-based
attacks.
So
between
your
application
and
the
internet,
there
is
a
routing
element
by
design
a
router
or
a
firewall
that
provides
some
sort
of
l2l3
protections,
IP
port,
filtering
intrusion,
preventions
and
so
on.
Everything
else
would
appear
as
legitimate
traffic,
in
this
case
we're
looking
at
HTTP
https
traffic.
D
It's
a
known
fact
that
web
attacks
are
most
common
type
of
external
attacks
that
are
facing
applications
and
Mohit
is
going
to
talk
more
about
this
overall
web
attacks
and
API
vulnerabilities
are
just
one
piece
of
the
puzzle
when
it
comes
to
securing
your
Cloud
native
apps
there,
but
effectively
an
entry
point
into
the
system.
Isolated,
Point
Solutions,
lack
a
broader
context
into
misconfigurations
vulnerabilities
and
applications
application
attacks
and
are
creating
unwanted
noise.
D
One
thing
for
web-based
attacks
specifically
that
we're
adding
and-
and
it
follows
that
overall
application
Security
in
the
runtime
Journey
when
we
go
from
agent
list
to
agent-based
security
and
how
that
enables
web
application.
Abs
security
is
really
that
vast
product
that
is
part
of
a
of
a
of
a
platform.
D
It
includes
a
web
application
firewall,
also
known
as
wav.
They
operate
on
the
application
layer
and
they're
highly
effective
Gatekeepers
when
it
comes
to
filtering
monitoring
and
blocking
HTTP
https
traffic
to
and
from
a
web
service.
A
majority
of
web
apps
today
are
built
using
Cloud
native
architectures,
the
ideal
approach
to
secure
against
web-based
attacks
changed
and,
and
we
feel
the
web
apps.
D
This
app
security,
particularly
coupled
with
API
security,
should
be
factored
in
overall
Cloud
security
strategy,
so
having
a
solution
across
a
full
app
lifecycle
that
includes
securing
workload,
whether
it's
a
VM,
container
or
serverless
function,
as
well
as
protecting
the
web,
apps
and
apis
that
run
on
those
workloads,
and
this
is
the
reason
we're
introducing
Watts
at
this
level
on
the
slide
here
now.
Webs
are
desegregating,
because
these
capabilities
need
to
be
closer
to
the
application.
They
need
to
be
more
app
aware.
D
Whereas
solution
adds
the
API
security,
which
is
one
of
the
major
problems
today
in
addition
to
bot
protection,
dos
protection
and
also
distributed
analysis
service
at
the
at
the
app
level,
specifically
distributed
analysis
for
HTTP
https
traffic.
Now
you
may
or
may
not
be
aware
about
the
recent
breach
of
data
with
the
tier
one
service
provider
in
Australia
Optus.
D
Basically,
there
was
no
authentication
method.
Anyone
from
a
a
public
IP
address
could
have
initiated
an
API
called
and,
and
what
did
that
could
effectively
did
initiated
that
APL
could
call
11.2
million
times
to
get
the
data
of
11.2
million
customers.
So
this
is
definitely
something
that,
with
the
tools
and
processes
that
we
have
today,
it's
fairly
easy
to
put
in
place
different
protections
at
the
different
points
in
in
in
the
infrastructure
to
really
prevent
these
kind
of
attacks
such
as
anomaly,
detection
rate
limiting
and
so
on.
D
Specifically
when
it
comes
to
abuse
of
the
aps,
because
they're
they're
effectively
a
very
good
entry
point
into
the
system
and
if,
if
the
infrastructure
is
not
secure,
it
will
allow
a
pretty
a
large
attack,
Vector
there
and
then
now
see
so.
For
example,
in
that,
in
that
case
of
an
API
abuse
that
that
would
even
appear
as
a
legitimate
traffic
it
would,
it
would
bypass
I,
bypassed
any
routing
element
at
the
Metro
perimeter
and
bypassed
any
controls
they
if
they
had
between
the
application
and
the
internet.
D
Okay,
so
we
have
a
number
of
risks
in
the
Run
phase,
and
the
best
way
to
look
at
a
situation
is
to
the
length
of
an
operating
system
where
we
have
everything
from
network
access
to
host
operating
system,
our
configurations,
our
runtime
and
the
application
software,
and
how
a
system
is
compromised.
I
just
mentioned
a
number
of
ways,
just
using
from
an
L7
perspective.
Http
is
traffic
through
different
attacks
at
the
web
applications
and
API.
D
Once
in
the
system,
the
attacker
would
typically
perform
various
reconnaissance
techniques
to
find
other
exploits
and
what
other
nefarious
things
could
be
done.
This
would
include
similar
techniques
that
we
would
use
in
penetration,
testing
and
ethical
hacking
of
things
involved,
involving
operating
system,
fingerprinting,
file,
permission
analysis.
It
would
try
to
run
a
new
process,
typically
a
network
service,
and
it
would
try
to
expand
laterally
from
one
container.
That
was
that
external
phase
and
then
laterally
go
to
other
containers.
Look
for
that
Crown
Jewel!
Look
for
that
data
that.
A
D
Could
steal
now
here's
my
selection
of
risks
at
the
runtime
level
across
Network,
host,
OS,
runtime,
config,
runtime
software
and
then
application
itself
that
will
cover
some
of
these
I
would
select
some
of
these
that
are
really
relevant
to
our
conversation
today
and
then
also
to
a
web
applications,
vulnerabilities
and-
and
it
will
show
in
a
demo
to
how
this
really
works.
So
I'll
pick
the
first
one
here
vulnerabilities
within
the
runtime
application.
D
They
may
be
relatively
common
and
rare,
but
a
particularly
dangerous
in
scenarios
where
a
malicious
software
can
attack
resources
in
other
containers
or
even
the
host
OS.
It
will
allow
an
attacker
to
access
another
container
or
monitor
intercontainer
communication
from
account
and
measure
perspective.
A
vulnerable
runtime
exposes
all
containers
it
supports
and
the
host
itself
to
risk.
So
what
we
need
to
do
is
carefully
monitor
for
vulnerabilities
and
when
problems
are
detected,
they
should
be
remediated
or
otherwise
patched
quickly.
D
The
other
one
I
would
pick
up
the
application.
Vulnerabilities
not
so
much
about
a
container,
but
the
application
it
runs
in.
It
now
consider
again
a
web
application
I
mentioned,
subject
to
cross-site
scripting
or
a
database
subject
to
SQL
injection.
This
would
be
considered
a
compromised
container
and
it
can
be
misused
in
a
way
that
would
Grant
the
non-authorized
access
to
sensitive
information.
D
What
we
should
Implement
is
additional
tools
that
are
more
application
and
container
aware
so
I
mentioned
a
little
bit
on
the
web
application
and
API
security
side.
One
other
thing
that
that
we
could
do
is
automatically
profile
containerized
applications
by
using
some
of
the
behavioral
learning
techniques
and
build
these
security
profiles
and
models
for
containers
to
minimize
any
human
interaction,
and
then
these
profiles
could
then
be
used
to
prevent
and
detect
anomalies
at
the
runtime.
D
Now,
typically,
the
events
that
would
be
looked
against
in
order
to
create
these
models
would
effectively
be
across
a
file
system.
Network
and
processes,
so
we
would
look
at
things
such
as
invalid
or
unexpected
process,
execution
or
invalid.
Unexpected
system
call,
because
why
would
a
random
container
spawn
a
process
that
would
peek
and
poke
in
our
memory?
Do
something
to
our
file
system
or
issue?
A
number
of
system
calls
that
we
don't
expect
so
changes
to
protected
config
files.
D
D
The
next
one
large
attack
surface.
It's
an
easy
one.
It's
about
optimizing.
The
attack,
surface
and
lots
of
people
do
this
today.
It's
about
minimizing
the
channels
that
can
open
up
for
a
potential
attack,
such
as
a
network
accessible
service,
provides
a
potential
entry
point
for
attackers.
Now
all
the
people
that
what
they
do
here
is
they
use
the
container
specific
operating
systems
where
threats
are
typically
more
minimal
to
start
with,
since
this
minimalistic
operating
systems
are
specifically
designed
to
host
containers
and
they
have
other
services
and
functionality
disabled
by
default.
D
D
And
then
let
me
see
your
last
one,
maybe
here,
host
operating
system
file
system
tampering,
so
here
is
about
insecure
container
configs
that
can
expose
host
volumes
to
greater
risk
of
file
tampering.
So,
for
example,
if
a
container
is
allowed
to
mount
sensitive
directories
on
the
host
OS,
that
container
can
then
change
files
in
those
directories,
and
these
changes
could
impact
the
stability
and
security
of
the
host
and
all
other
containers
that
are
running
on
it
here.
What
we
need
to
do
is
ensure
that
containers
are
run
with
the
minimal
set
of
permissions.
D
Very
rarely
should
contain
a
mount
local
file
systems
on
a
host.
Any
file
changes
that
containers
need
to
persist
with
disk
should
be
made
within
storage
volume.
Specifically,
that
is
allocated
for
that
purpose
and
I
think
in
no
case
should
container
be
able
to
mount
sensitive
directors
on
a
host
file
system,
especially
the
containers
that
contain
any
config
settings
for
the
operating
system.
So
we
got
to
use
tools
that
can
monitor
what
directories
are
being
mounted
by
containers
and
prevent
the
deployment
of
containers
that
violate
these
policies.
D
I
think
many
of
these
counter
measures
you
could
start
implementing
tomorrow.
The
question
is
that
you
need
to
ask
yourself
is
how
to
do
this
efficiently
at
speed
in
the
scale.
What
could
be
automated
here
and
one
thing
I
want
to
mention,
as
I
close
my
section
here
and
just
slowly
introduce
a
little
bit
around
our
product,
the
Prisma
cloud
and
Mohit
and
I
are
representing
Prisma
Cloud
compute
portion
of
our
platform.
This
is
about
that
predictive
model,
I
mentioned
and
I'm
calling
it
out
here.
D
In
my
opinion,
it's
it's
one
of
the
best
features
here,
especially
if
we're
looking
at
that
runtime
defense.
If
you're,
looking
at
really
prevention
and
near
real
time,
what
we
do
here
is
we
start
with
static
analysis.
That's
a
testing
methodology
that
analyzes
application
components
to
find
security
vulnerabilities
that
would
make
an
application
susceptible
to
an
attack
using
machine
learning
for
correlation
and
model
input
would
give
us
a
predictive
model
of
this
application.
D
D
The
second
thing
I
like
to
call
it
on
this
model,
specifically,
is
that
that
model
effectively
builds
applications
DNA
and
prevents
malware
in
real
time,
even
without
any
security
policies
in
place.
So
there's
a
there's,
a
few
learning
modes
here,
learning
mode
and
initially
would
would
a
look
across
as
I
mentioned
before,
processes,
file
systems
and
network
and
then
build
out
that
DNA
for
us
to
use
in
real
time.
So
I
think
it's
a
powerful
combination
of
tools
and
processes
that
would
provide
both
visibility
and
real-time
protection
for
applications.
D
Now
tying
this
all
in
into
application.
Security,
Continuum
I
talked
a
little
bit
about
agentless
scanning.
This
is
something
that
we
have
available
in
our
platform
in
our
offer.
I
see.
This
is
a
first
step
in
securing
Cloud
environments.
I
talked
about
First,
Step
being
that
visibility
turn
on
the
light
switch
map,
your
environment,
it's
ideal
for
that
easy,
quick
visibility
into
your
distributed
environments.
When
you
need
a
quick
posture
overview,
we
do
this
by
creating
a
snapshot
on
a
customer
environment,
extremely
low
cost,
from
a
compute
storage.
D
D
Is
that
now
first
step
in
defending
Cloud
environments,
because
this
part
is
now
about
defense
and
depth
where
you
detect
and
prevent
threats
in
real
time
by
doing
runtime
scanning
and
normally
detection
things
that
I
just
mentioned
in
the
previous
slide,
when
we
create
that
model.
So
it's
great
for
that
defense
in
depth
and
and
and
for
active
prevention
of
exploits
where
we
have
agents
deployed
on
the
application
infrastructure
and
then
the
last
piece
to
this
application.
C
And
then
you
know,
Defender
based
protection
is
to
implement
some
actual
protection,
but
where
rasp
plays
a
role
in
this,
is
it's
an
added
layer
of
protection
for
your
web
apps
on
these
containerized
or
hosts
or
serverless
workloads
or
apis
that
are
talking
to
each
other,
whether
it's
the
north-south
API
traffic,
or
whether
it's
East-West,
when
it's
from
one
workload
to
another
one
application
to
another?
And
what
we're
really
doing
here
is
we're
looking
at
all
of
those
requests
over
HTTP
and
https,
and
then
analyzing
them
to
see.
B
C
As
well
as
protecting
against
dos
and
boss
bot
protection,
okay
and
the
reason
why
we're
doing
this
is
because
we
realize
that
web
application
exploits
are
the
most
common
form
of
an
external
attack.
In
fact
that
there's
a
recent
study
by
Forester
that
said
that
39
of
external
attacks
are
web
application
tax
and
there's
another
study
by
bleeding
computer.
That
said
that,
there's
about
a
600
growth
in
attacks
to
apis
just
in
2021
and
as
you
know,
developers
and
companies
start
leveraging
apis
more
and
more
heavily.
C
We're
going
to
see
that
attackers
will
then
go
and
Target
this
much
larger
attack
surface,
because
a
lot
of
these
apis
are
insecure.
Like
yvon
said
earlier,
there
was
a
breach
from
Optus
where
they
made
about
11.2
million
calls
to
an
API
like
how
can
someone
make
11.2
million
calls
to
an
API
without
it
going
unnoticed?
C
You
know,
Prisma
Cloud
platform
that
we're
sharing
with
you
here
today
we're
offering
we
built
a
built-in
web
app
firewall,
as
well
as
a
built-in
API
security
solution
for
those
applications
that
have
vulnerable
web
applications
or
vulnerable
apis.
And
then,
on
top
of
this,
we're
able
to
also
protect
against
Bots,
whether
they're,
good
Bots,
known
Bots,
search
engine,
Bots
or
bad
Bots,
and
as
well
as
Bots
that
you
can
Define.
C
And
on
top
of
this,
we're
also
able
to
detect
against
the
Dos
attacks
by
rate
limiting
some
of
the
requests
we're
seeing
towards
the
application,
and
we
also
give
you
insight
into
all
the
requests
analytics
events
and
whatnot
within
one
screen
two.
So
you
can
prioritize
risk,
and
all
of
this
is
backed
by
our
unit.
C
The
biggest
benefit
is
that
all
of
these
Solutions
is
that
you're
getting
better
security
with
fewer
tools,
because
all
this
has
been
integrated
into
the
same
prismacloud
platform,
whether
it's
workload,
protection,
WAP,
API,
security,
cspm
or
cwp.
It's
all
through
that
single
platform
and
the
reason
why
we
made
black
wax
as
a
part
of
our
Cloud
native
application
production
platform.
Just
because
we
realize
that
these
Legacy
Solutions
like
failed
to
really
protect
like
Cloud
native
applications.
C
We
want
to
really
emphasize
that
we're
looking
at
this
from
a
cloud-native
perspective,
where
your
traditional
laugh
was
usually
a
box
that
would
sit
in
front
of
your
old
data
center
and
it
would
protect
a
VM
or
a
old-school
machine
and
they
didn't
really
look
at
apis.
Nor
did
it
scale
on
demand
because
it
was
an
actual
physical
box
and
you
had
to
stack
more
boxes
on
on
top
of
each
other
and
they
couldn't
be
deployed
for
private
public
cloud
or
hybrid
Cloud
use
cases
and
your
Cloud
laughs.
C
A
C
C
We're
able
to
scale
easily
because
we
place
our
Solution
on
top
of
the
workload.
So
as
the
workload
or
application
scales,
the
security
solution
scales
with
the
application.
So
you
never
have
any
downside
of
hey.
You
know
my
wife
or
API
security
is
like
breaking
my
application
because
it's
limiting
number
of
traffic
or
requests,
and
that's
that's
really
big
in
cases
for
large
deployments,
and
on
top
of
that,
we
offer
a
lot
of
flexibility
on
how
customers
want
to
consume
that
whether
they
want
to
consume
it
for
applications
on
their
private
Cloud
public
Cloud.
C
They
have
a
hybrid
approach
or
you
want
to
use
it
on
premises.
We
even
we
have.
We
have
all
the
flexibility
within
the
product
and
then
on
top
of
this,
we
also
offer
inline
and
out-of-band
protection,
meaning
that
you
can
have
inline
protection
for
those
critical
applications
and
apis
that
need
protection
on
a
day-to-day
basis,
and
you
can
also
have
out-of-band
observability,
which
is
just
greater
visibility
into
understanding
all
the
risks
and
threats
associated
with
your
application,
without
actually
having
something
in
the
middle
That,
Could,
Break,
Your
application.
C
And
here's
just
some
other
reasons
to
why
customers
have
been
choosing
our
last
solution
over
there
and
ditching
their
classic
wow
for
their.
You
know.
First
gen
API
security
product
is
because
of
the
fact
that
we
are
able
to
be
deployed
on
your
public
Cloud
private
Cloud
take
a
hybrid
approach
or
whatnot,
whether
it's
inline
or
out
of
band.
B
B
C
Well,
with
the
application
like
I
said
earlier,
because
as
a
one
point
now
we
sit
on
the
actual
workload,
whether
it's
the
container
or
the
host
machine.
So
as
your
application
scales,
we
scale
with
it
as
well,
and
then,
on
top
of
that,
we
are
integrated
into
a
cloud
native
application
protection
platform,
meaning
that
we're
the
only
laugh
in
API
security
Solution
on
the
market,
that's
built
into
a
holistic,
Cloud
security
solution.
C
So
we
give
you
a
holistic
view
into
security
for
the
applications,
whether
it's
cspn
point
of
view,
whether
it's
a
vulnerability
management
point
of
view,
whether
it's
a
wac
or
API
security,
point
of
view
we
give
it.
We
give
you
a
360
View
out
of
security
for
your
application,
because
we
know
that,
like
I
said
earlier,
the
web,
app
attacks
or
the
API
attacks
are
just
one
entry
point
into
your
application.
So
you
want
a
complete
visibility
of
everything.
Even
the
back
end,
databases
and
whatnot.
C
D
All
right
so
I'd
like
to
show
a
few
things
around
vulnerability,
management,
runtime,
security
and,
and
so
on
things
that
I've
talked
about
before
and
then
I'll
hand
over
back
to
mohi,
to
talk
about
Waz
specific
and
then
show
a
little
demo
around
that
I've
pre-loaded
here
a
Raider
view,
but
and
I'll
come
back
to
that.
I
wanted
to
show
one
other
thing
before
that
it's
really
on
boarding
or
unboxing
prismacloud.
If
you
will,
where
you
would
start
with
adding
a
cloud
account.
These
are
the
clouds
that
we
support.
D
C
D
Was
my
VPN
it
was
connecting
in
them
at
that
moment.
Let
me
just
go
back
here
all
right,
so
settings
Cloud
accounts.
Add
a
cloud
account.
These
are
the
cloud
service
providers
we
support.
Currently
they
can
AWS
here,
basically
naming
your
account,
choosing
an
onboarding
type
and
then
choosing
between
a
read-only
mode
or
Monitor
and
protect
mode.
D
D
And
we
talked,
we
talked
about
that
flexibility
that
we
have
with
agent
based
and
agentless
approaches
for
a
comprehensive
vulnerability
management
for
hosts
containers,
serverless
functions,
We
Believe
customers
should
have
to
choose,
should
should
not
have
to
choose
between
simple
or
secure.
We
should
have
both
simple
and
secure,
so
we
mentioned
use
agent
list
for
that
quick
scanning,
agent-based
approaches
for
more
sensitive
environments.
Once
you
map
your
environment,
you
figure
out
what
to
deploy
where,
and
this
is
an
example
of
an
application
that
runs
so
here,
I'm.
D
Looking
at
the
book
info
application,
where
I
can
see
a
color
coded
based
on
my
application
risk
any
if
this
feels
a
little
bit
overwhelming
in
terms
of
how
many
stuff
there
are
that's,
because
application
security
is
overwhelming,
but
I
assure
that
there
are
other
parts
of
the
Prisma
cloud
that,
and
we
constantly
work
on
this
Simplicity
and
automation,
to
really
get
to
you
to
that
risk.
Profiling
risk
prioritization
very
fast.
D
D
D
That
shows
what
kind
of
items
were
found
for
that
specific
image,
and
here
we
see
there
are
lots
of
critical
severities,
high
severities,
medium
severities,
low
attack,
complexity,
attack
Vector
through
the
network,
the
knowledge
service
and
so
on.
So
we
can
click
on
this
registry
details
and
then
look
at
the
different
vulnerabilities
here
as
we
go
through
vulnerabilities
compliance
and
different
aspects
here,
so
just
to
call
out
a
few
things.
D
So
if
we
go
on
compliance
here,
I
can
see
that
this
image
was
was
created
with
a
root
root
user
and
that's
something
we
should
avoid.
So
it's
been
called
out
here
as
a
as
a
compliance
check.
If
I
go
back
on
vulnerabilities
and
choose
something
critical
here,
so
see,
I
I
see
here
that
the
zlib
package
has
number
of
vulnerabilities
and
then
it
can
drill
down
on
a
specific
packages
that
are
part
of
this
image,
and
here
I
can
see
a
different
risk
score
I
see
specifically
for
this
CDE.
D
D
D
That
would
look
at
different
things,
processes
that
could
modify
my
binaries
scan
for
crypto
miners.
Look
for
that
reverse
shell
attacks,
scanner
for
processes
that
are
used
for
lateral
movement
and
lateral
breach
expansion,
and
then
you
could
choose
alert,
prevent
or
block.
This
is
something
you
have
when
you
deploy
an
agent
for
that
defense
in
depth.
D
D
Are
the
container
models,
so
we
talked
a
little
bit
about
creating
that
model.
So
just
pick
the
first
one
here,
so
this
Maps
through
static
analysis
methodologies
also
also
behavioral
as
well.
These
are
the
processes
that
have
been
identified
as
a
known
expected
processes.
So
one
thing
calling
out
here:
kubernetes
agent
is
there
and
various
other
processes.
Also
from
a
networking
perspective,
we
can
see
that
kubernetes
agents
would
listen
at
this
ports.
D
We
also
behaviorally
learned
about
the
outbound
internet
port
443,
that's
open
for
not
so
much
from
a
file
system
perspective,
except
that
kubernetes
agent
has
a
number
of
paths
here
that
it's
using
so
this
this
would
be
constituted
as
a
known
expected.
Behavior
and
everything
else
out
of
this
bounds
would
be
an
anomaly
anomaly
that
would
be
flagged
for
a
user
to
do
something
about
it.
I'll
stop
sharing
here
and
hand
over
to
Mohit
to
show
a
little
bit
on
the
last
side.
C
C
Let
me
widen
the
screen
and
actually
drill
down,
there's
an
application
about
book
info,
where
we
save
all
the
information
about
books
and
if
I
click
on
it,
I
can
see
everything
I
go
outside
from
one
page:
the
vulnerabilities,
the
compliance,
the
runtime
events
as
well
as
wax,
and,
as
you
can
see,
we
automatically
detected
that
there's
an
unprotected
web
app
on
running
on
this
container
and
we've
profiled
it
as
well.
And
it's
as.
B
C
So
if
I
were
to
go
and
add
protection,
like
I
said
earlier,
we
have
a
built-in
WAFF
where
you
can
come
in
and
simply
click
the
type
of
protection
you
want,
whether
it's
disable
the
protection
you
want
to
alert.
You
want
to
prevent
the
xql
injection
or
you
want
to
ban
it.
The
difference
between
prevent
and
ban
is
prevent,
prevents
the
request.
C
The
band
is
that
we
deny
all
requests
coming
from
that
known
IP
for
the
next
five
and
it's
kind
of
like
a
penalty
box,
and
we
do
this
for
everything
across
the
OAS
top
10.,
such
as
code
injection,
CrossFit,
cross-site,
scripting
and
more,
and
then
we
also
provide
dos
protection,
which
is
we
do
it
by
rate
limiting
some
of
the
requests
coming
to
the
application.
So
it's
not
DDOS,
but
it
is
denial
of
service
by
understanding
the
request.
C
We
also
provide
custom
rules
for
your
application,
where
you
can
write
a
custom
rule
to
prevent
certain
requests
for
your
application
and
then
our
here's,
our
advanced
settings.
But
we
also
have
out
of
the
box
virtual
patches,
which
are
unit
42
threat.
Research
team
creates
which
customers
can
then
go
and
Implement
on
their
application
for
like
zero
day
vulnerabilities.blog
for
shell
and
Azure
Escape.
C
Here
you
can
go
and
find
some
of
the
virtual
patches,
whether
it's
for
CBE
spring
shell
and
more,
that
are
research
team
defined
in
this
mirror.
Like
I
said
all
this
can
be
done
within
a
single
pane
of
glass.
You
can
see
all
the
results
for
the
for
your
application
in
one
holistic
view,
which
gives
you
complete:
comprehensive
protection
and
visibility
for
your
workloads
and
applications
on
any
Cloud
native
environment
that
I'm
going
to
pause
to
see.
If
there's
any
other
questions
before
we
wrap
it
up.
C
We
have
one
question
last
protection
for
container:
is
it
container
workload?
Is
it
a
sidecar
or
per
host?
So
Felipe?
The
question
is
really
good,
so
how
last
works
is
because
you
already
have
an
agent
deployed
on
your
container
workload.
It's
not
really
a
sidecar.
It
actually
sits
on
the
actual
workload,
so
we
are
able
to
protect
inline
requests
coming
to
the
application.
C
But
if
you
don't
want
it
to
sit
in
line,
we
can
have
it
sit
out
of
band
as
well,
where
it
kind
of
sits
as
like
a
sidecar
where
we
just
give
you
the
complete
visibility
for
your
container
and
usually
works.
It
usually
sits
on
the
container
node
itself
or
the
host
OS.
So
if
it's
on
the
container
node,
you
can
look
at
all
the
containers
within
that.
B
B
D
D
B
D
D
The
protection
that
cloud
workloads
really
need.
Is
that
proactive,
comprehensive
approaches?
Specifically
when
you
talk
about
investment
in
technology,
people
and
processes,
I
think
you
can
have
all
the
tools
in
the
world,
but
the
number
one
best
practice
is
just
enable
the
partnership
between
the
teams
and
use
use,
modern
tools
that
are
application
aware
and
can
help
you
prioritize
that
risk
and
rescan
for
things
that
matter.
D
We
talked
about
defense
and
depth,
so
this
is
a
big
item
for
real
time:
threat,
detection
and
threat
prevention,
anomaly,
detection
and
so
on.
So
I
think
it's
a
big
one
for
very
sensitive
parts
of
your
environment
that
you
can
learn
from
your
initial
scan
to
understand
really
where
you
need
to
deploy,
Defenders
and
and
provide
that
defense
in
depth.
D
We
talked
a
lot
about
waffs
we
mentioned
these
Solutions
are
disaggregating
on
the
market
right
now
and
it
started
a
few
years
ago
because
really
you
need
an
application
aware
web
app
and
API
security,
so
it's
they're
coming
closer
to
the
app
they've
disaggregated
and
became
virtual
and
then
application.
Api
security
came
in
as
an
offer
and
the
way
we
are
integrating.
D
It
is
a
very
neat
module
that
is
part
of
the
overall
Prisma
Cloud
compute
offer
so
that
you
can
really
go
from
agent
list
to
Defenders
and
then
really
enabling
the
web
app
and
API
security
and
then,
lastly,
obviously
simple
one
look
for
a
solution
that
provides
you
with
more
insights
with
less
effort,
you
I,
don't
think
you
need
a
solution
that
is
focused
on
one
piece
of
the
puzzle,
we'll
just
leave
it
with
too
many
blind
spots.
You
need
a
comprehensive
solution
where
really
each
capability
is
best
of
breed.
D
C
Just
like
to
iterate
on
your
first
point,
like
you
want
like
our
job
here,
is
to
enable
collaboration
between
teams
to
help
you
guys,
you
know,
secure
your
workloads,
there's
all
vulnerabilities
and
secure
your
applications
and
I
think
that's
like
really
important.
It's
like
trying
to
figure
out
that
process
internally
can
be
tough
and
try
to
pair
with
a
good
solution
that
works,
for
you
is,
is
just
as
tough,
so
really
try
to
understand
how
you
can
take
a
complete
holistic
view
into
application
security.
A
D
D
Please
do
reach
out
to
me
in
Mohit
as
well,
if
you
would
like
any
any
specific,
if
you
have
any
specific
questions
or
if
we
need
any
follow-ups,
we'll
be
happy
to
provide
a
demo
and
talk
about
your
specific
use
case
and
spend
some
time
around
it.
This
link,
you
can
use
to
request
one
of
the
trials
specifically
and
then
start
your
Cloud
native
application
protection
Journey
with
the
prismacloud.