►
From YouTube: Webinar: Using Cloud Native Technologies to Solve Complex Application Security Challenges in K8s
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Application security, defined as preventing malicious, automated attacks that appear to be legitimate, or syntactically correct that target your public facing web, mobile and API-based applications is an often overlooked element of your cloud native security stack. The infrastructure is covered by the cloud providers, often augmented with native and 3rd party services. Your containers can be protected by services and augmented by an immutable approach to your architecture. Yet at the application level, security is often overlooked. In this webinar, Shreyans Mehta, co-founder and CTO of Cequence Security will discuss the need for application security and how cloud native tools such as Envoy and Prometheus allow you to bake application security into your Kubernetes deployments.
A
A
Alright,
let's
go
ahead
and
get
started
first,
I'd
like
to
thank
everyone.
Who's
joining
us
today
welcome
to
today
fee
and
CF
webinar,
using
cloud
native
technologies
to
solve
complex
application,
security
challenges
in
kubernetes
deployments,
I'm
Shiela,
SE,
v6vf,
ambassador
and
open
source
program
manager
at
Comcast
and
I'll
be
moderating.
Today's
webinar
we'd
like
to
welcome
our
presenters
today,
Shreyas
Mehta,
the
co-founder
and
CTO
of
sequence,
security,
a
few
housekeeping
items
before
we
get
started
during
the
webinar
you're,
not
able
to
talk
as
an
attendee.
A
B
Thank
you
hi
again,
my
name
is
transmeta
and
like
like
I
was
introduced
and
co-founder
and
CTO
at
sequence,
security
today
in
the
webinar
I'm,
going
to
talk
about
mostly
introducing
a
new
way
to
do
application
security,
especially
focusing
on
the
runtime
application
security
aspects
where
we
have
more
and
more
of
api's,
more
applications
that
are
being
exposed
through
containers
in
the
kubernetes
and
micro
services
environments.
So
before
I,
kick
it
off.
I
just
want
to
briefly
talk
about
our
company
sequin
security.
B
We
are
event
to
back
the
start
up,
focusing
primarily
on
application
security
space.
We
build
an
AI
powered
security
platform
which
is
actually
delivered
as
containers
to
protect
the
web,
mobile
and
api-based
applications
from
bots
or
sometimes
called
as
business
logic
attacks
as
well
as
1/r
ability
exploits.
B
We
are
completely
built
on
top
of
cloud
name-
components
like
open.
It
is
envoy,
prometheus
and
likes,
and
we
play
well
with
the
existing
ingress
controllers,
like
site
cards
like
envoy
and
engine
egg,
so
you
don't
necessarily
need
to
replace
them
to
use
technologies
like
ours
and
for
more
information
about
us.
You
can
obviously
visit
our
site
sequence.
B
Star
AI,
so
kicking
it
off
so
the
world
as
we
see
it,
the
there
are
a
lot
of
public
publicly
facing
applications
and
you
need
to
expose
them
publicly
for
a
number
of
reasons,
primarily
for
your
customer
interactions.
Sometimes
you
might
have
mobile
applications
that
need
to
talk
to
to
the
actual
apps.
On
the
back
end
using
mobile
api's,
you
might
have
supplier
api
eyes,
you
might
have
partner
AP
eyes,
and
the
moment
you
expose
them.
B
B
So
the
content
really
appears
to
be
legitimate,
but
where
they're
actually
very
difficult
to
detect
and
block
using
traditional
signature-based
technologies,
and
then
there
are
these
traditional
attacks.
What
we
call
those
attacks
on
vulnerabilities-
they
are
highly
targeted,
they
can
be
both
known
attacks
or
zero-day
exploits,
depending
on
how
they're
they
are
being
executed.
So
that's
the
high-level
view
of
the
application
attack
landscape,
primarily
at
these
at
the
runtime.
B
So
let's
talk
a
little
bit
about
how
they
these
kinds
of
attacks
are
being
sort
of
protected
against,
at
least
so
far
and
and
and
the
traditional
world
is
all
about
monolithic
applications
and
think
for
our
discussion.
Think
of
a
retail
application
that
has,
let's
say
user
management
on
its
side,
the
shopping
cart.
B
So
the
first
kind
of
defense
is
the
defense
against
vulnerability
exploits
and
you
can
think
of
it
as
as
a
couple
of
examples.
The
first
thing
that
you
put
in
place
is
the
Web
Application
Firewall,
and
this
Web
Application
Firewall,
has
is
doing
a
couple
of
things.
It
is
trying
to
protect
the
application
from
more
like
OVAs
type
of
attacks.
B
It
is
also
needed
for
compliance
in
a
lot
of
cases
it
is
it
is,
it
is
helping
you
prevent
against
vulnerability,
scans,
think,
Metasploit,
think
open
mask,
which
is
trying
to
expose
anyone
durable
applications
that
you
might
be
running,
so
you
might
be
running
something
like
one
wonder:
Balu,
PHP
application
or
nodejs
application.
So
it's
it's
trying
to
uncover
that
and
that
becomes
sort
of
the
first
phase
of
the
attack.
B
The
second
phase
of
is
really
oh,
that
your
graph
is
also
protecting
against
is
the
actual
breaches
themselves,
you're
running
your
entire
user
database
on
the
back
end,
and
somebody
could
actually
exploit
eight,
the
entire
user
database
PII
information
transactions,
all
of
that
through
through
attacks
like
sequel
injection
or
you
might
have
something
like
elasticsearch
server
that
is
exposed.
So
the
job
of
Web,
Application
Firewall,
is
to
protect
against
these
kinds
of
attacks
that
lead
to
exfiltration
or
the
actual
exploit
themselves.
So
you
need
that.
B
The
second
part
that
we
spoke
about
earlier
is
also
about
the
highly
automated
attacks
that
are
also
called
bot
attacks,
so
think
of
a
case
now.
In
this
case,
this
is
a
retail
site
that
we
are
talking
about
so
bad
actors,
especially
competitors,
can
come
in
and
scrape
the
entire
database
of
inventory
that
you
might
have.
They
might
use
that
against
you
in
terms
of
the
pricing
information
that
you
have
and
then
competitively
put
prices
on
their
own
site.
B
Sometimes
we
also
see
competitors
scraping
content,
which
is
really
your
IP,
rather
than
rather
than
using
it
maliciously
they
are.
They
might
even
use
that
to
develop
their
own
own
content
around
it.
Based
on
what
you
have
posted
on
your
site,
we
also
see
in
the
retail
side
something
what
is
called
as
inventory.
B
We
also
see
cases
around
fake
account
creation
where
you
might
have
a
promotion
going
on
that
you
get,
let's
say,
X
number
of
carrot,
credits
or
certain,
maybe
dollars
or
something
like
that.
When
you
create
a
new
account
and
the
bad
actors,
can
you
can
end
up
creating
hundreds
of
thousands
of
such
accounts
and
and
drain
out
those
those
credits
that
you
have
available
for
legitimate
users?
B
What
we
see
really
is
there
are
billions
and
billions
of
the
username
passwords
that
are
available
in
the
black
market,
especially
because
of
the
breaches
that
have
been
happening
in
the
past
few
years.
It's
it's
either
username
passwords
or
email,
IDs
and
passwords,
so
they
these
are
stashes
of
credentials
that
have
been
breached
through
my
think
thing.
Going
back
right,
I
mean
LinkedIn,
Yahoo,
breach
most
recently
Chipotle
and
State
Farm,
and
things
like
that.
B
So
so
you
you
get
these
these
credentials
and
obviously
these
companies
have
gone
ahead
and
and
reset
the
username
passwords
for
these
guys
to
protect
the
individuals
but
the
other
sites.
Continuity.
You
have
the
same
username
password
just
because
nor
human
being
dentistry
reuse,
the
same
password
across
multiple
sites.
So
what
bad
actors
do
is
they
take
advantage
of
that
and
they
take
these
stolen
credentials
and
then
try
it
on
our
retail
sites
or
XYZ
retail
site
and
any
hit
they
get?
Is?
Is
money
to
these
guys?
B
So
that's
another
typical
case
of
a
part
attack
and
the
last
protection
that
you
need
is
protection
against
application
layer,
DDoS
now
think
of
it
as
your
your
monolithic
application.
Here
it
needs
to
scale
up
and
down
with
with
the
kind
of
traffic
that
is
that
it's
coming
in,
but
when
your
traffic
is
70,
80,
90
percent,
sometimes
you're
coming
from
the
synthetic
traffic
that
is
being
generated
by
these
BOTS
it.
B
It
means
Gayla,
but
just
the
the
web
server
level,
but
not
necessarily
at
the
application
level
or
the
back
in
nearest
database
level,
and
because
of
that
it
leads
to
unavailability
of
the
application
and
and
maybe
even
sometimes
slow
down.
So
some
in
some
ways
are
DDoS.
Attacks
are
related
to
heart
attacks
as
well,
but
it
doesn't
have
a
security
implication,
but
more
of
an
availability
implication.
So
from
your
perimeter
defense
perspective
for
your
monolithic
applications.
You
need
all
these
kinds
of
defenses
in
place.
B
No
matter
where
your
application
is
running
could
be
running
in
your
data
center.
It
could
be
running
in
a
public
cloud
wherever
that
might
be
so
now
coming
to
the
new
world
of
where
these
monolithic
applications
are
being
sort
of
split
up
into
micro
services
for
various
different
benefits.
Right
I
mean
we
all
understand
the
limitations
of
monolithic
applications,
it's
very
hard
to
do,
roll
out
new
new
updates
to
these
applications.
There
are
so
many
dependencies
between
different
components
that
anytime,
you
touch
one
component.
B
It
might
lead
to
sort
of
breaking
some
other
component
and
you
have
to
just
rely
on
one
application
start.
Maybe
it
could
be
a
Java.
Yes,
it's
harder
to
for
the
development
teams
to
to
sort
of
develop
at
a
much
faster
pace
that
sort
of
the
new
world
needs,
and
that's
why
people
are
moving
towards
micro
services
and
again,
you
guys
are
all
probably
experts
in
this
space,
but
this
just
to
give
you
an
idea
how
these
applications
are
breaking
up.
B
So
the
original
monolithic
app
that
we
spoke
about
can
now
potentially
be
split
into.
Let's
say
a
user
management
micro
service
that
then
in
turn
can
potentially
talk
to
the
data
access
micro
service.
You
might
have
a
shopping,
cart
micro
service.
That
is
separate.
You
might
have
a
customer
reviews
and
ratings
micro
service.
You
might
have
an
inventory
management,
micro
service
and
so
on
so
forth,
and
all
this
is
being
orchestrated
through
your
orchestration
platforms
like
kubernetes
or
steo,
and
and
so
on
so
forth.
Now
you
can
then
individually
scale
these
applications.
B
So
let's
say
you
have
an
uptake
in
the
new
new
new
customers,
because
you
have
a
promotion
going
on,
so
you
might
just
want
to
individually
scale
the
user
management
service
and
not
necessarily
everything
else.
You
might
have
a
sort
of
a
Thanksgiving
sale
going
on
and
you
might
want
to
scale
up
the
shopping,
cart
and
customer
review
service.
So
you
can
sort
of
take
sort
of
a
scalpel
like
approach
to
scale
up
and
down
these
services,
rather
than
scaling
up
the
entire
application
stack
in
an
animalistic
side.
B
So
these
these
are
sort
of
the
benefits
of
the
the
micro
services
based
approach
rather
than
a
monolithic
application.
Now
all
these
when
they
were
working
in
in
a
sort
of
monolithic
environment,
they
were
talking
to
each
other.
These
components
probably
still
existed,
but
they
were
talking
to
each
other
using
function,
calls
or
our
pcs
or
something
like
that,
but
but
in
the
sort
of
be
the
microservices
world,
these
applications
are
loosely
coupled.
B
They
are
exposed
through
api's
and
and
and
these
api's
have
sort
of
a
contract,
sometimes
that,
okay,
only
these
services
can
can
talk
to
other
services
and
I'm
going
to
talk
over
TLS
and
so
on
and
so
forth,
but
they
are
still
prone
to
the
kind
of
attacks
that
we
spoke
about
earlier
and,
let's
drill
down
a
little
bit
more
yeah.
So
so
when
we
move
from
the
the
monolith
world
to
the
micro-services
world
there's
these
are
some
of
the
additional
challenges
that
you
have
to
worry
about.
B
Number
one
is
because
of
the
newly
exposed
api's
for
these
micro
services.
You
have
a
whole
lot
more
entry
points
into
your
environment
right.
They
might
not
necessarily
be
exposed
directly,
but
they
might
be
exposed
into
that
in
the
sense
that
the
data
access
service
might
not
be
exposed
directly
to
the
outside
world.
B
Sometimes
these
services
can
even
break
the
contract
that
okay,
and
only
rather
than
doing
the
account
sort
of
a
check
or
authentication
I
might
be
doing
something
else,
just
because
somebody
compromise
some
some
other
of
Microsoft's.
So
so
that's
one
aspect.
The
second
aspect
is
the
scale-out
aspect.
B
Where,
in
in
the
monolith
world,
you
were
scaling
out,
the
entire
application
stack
stack
in
one
go
and
you
had
sized
your
runtime
application
security
services
to
maybe
for
the
peak.
So
let's
say
my
Thanksgiving
time.
My
needs
like
five
Giga
bits
of
traffic,
and
that's
why
my
my
my
app
runtime
application
security
stack
is
actually
sized
for
that.
B
But
it
does
not
account
for
specific
services
that
are
scaling
scaling
up
and
down,
because
the
needs
for
your
applications,
security
stack,
might
rely
on
the
individual
components
and
the
security
that
they
need,
rather
than
sort
of
a
sort
of
a
single
sort
of
a
brush
of
ok.
I
just
need
to
have
this
much
capacity.
B
So
that's
sorry,
it's
just
falling
down
for
me
so
that
that's
another
security
challenge
that
you
face
there,
where
you
have
individual
Mike
micro
services
that
are
scaling
up
and
down.
How
do
you
scale
up
and
down
your
security
services
along
with
it,
especially
when
these
services
are
in
some
ways
disconnected
from
from
the
micro
services
themselves?
B
The
second
big
effect
is
around
Keeping
Up,
with
the
sort
of
the
DevOps
space,
the
security,
keeping
up
with
the
DevOps
pace.
So
earlier
there
was
a
single
monolithic
application
and
the
security
team
was
actually
working
with
the
application
team.
Any
time
you
were
rolling
up,
update
to
the
application
and
working
closely
with
them.
The
whole
idea
of
moving
to
micro
services
is
in
the
development
name,
the
operations
team
they
can
pick
and
they
can
move
with.
The
lightning
speed,
but
they
can
roll
out
new
micro
services
while
coexisting
with
the
older
micro
service.
B
They
might
might
want
to
phase
out
the
the
reviews
or
ratings
application
and
then
roll
out
a
new
one
or
but
they
won't
only
want
to
do
it
based
on
a
region.
So
so
new
applications
are
being
rolled
out
at
a
at
a
much
faster
pace
and
and
how
does
the
application
security
become
aware
of
these
applications?
So
the
discovery
aspect,
the
protection
aspect.
This
becomes
a
challenge
from
the
application
security
perspective.
B
The
third
one
is
like
like
I
said
earlier,
is
earlier:
you
would
depend
just
on
sort
of
one
kind
of
application
security
application
stack
now.
What
micro-service
is
allowed
you
to
do
is
you
could
have
hit
Virginia's
environment
write
your
user,
Management
Service
could
be
running
on
a
Java
stack,
your
your
data
access
could
be
on
the
PHP
stack.
You
might
want
to
move
the
shopping,
cart
to
no
js'
stack
and
and
so
on
and
so
forth.
B
So
you
see
what
you
have
is,
rather
than
a
single
stack
and
sort
of
that
that
that
the
security
team
needs
to
deal
with
yeah.
Now
you
have
a
hit,
reduce
genius
environment
and
a
newer,
newer
stacks
keep
keep
coming
up,
and
the
security
team
again
needs
to
worry
about
these
individual
services
at
the
kind
of
protection
that
they
build,
rather
than
some
sort
of
again
a
single
approach
to
choose
to
solve
that
problem.
B
You
to
do
is
ability
to
run
in
in
multiple
cloud,
so
so
you
could
be
in
the
data
center
have
started
off
with
something
that
like
an
on-prem
of
pivotal
or
openshift,
and
you
could
be
moving
to
to
the
cloud
and
some
of
yourself
Microsoft's
is
still
running
on
Prem
and
then
somewhere
running
in
the
cloud
and
and
the
parameter
base.
Defense
approach
doesn't
really
work
there,
because
there
is
no
real
parameter.
B
B
Now
so
so
what
is
the
new
approach
that
a
we
can?
We
can
actually
work
with,
so
that
we
can
keep
up
with
the
the
the
needs
of
the
micro
services.
So
what
we're
proposing
is
a
new
way
to
do
this.
It's
it's
so,
rather
than
moving
having
application
security
at
the
parameter
level,
the
application
security
needs
to
move
closer
to
the
applications
themselves,
the
micro
services
that
they
are
there.
They
are
actually
running.
What
that
means
is
this?
B
The
the
app
tech
at
runtime
needs
to
packet,
be
packaged
in
as
containers
and
and
there
and
and
run
in
the
same
pods
as
as
the
applications
themselves.
So
when
you
are
when
you
are
scaling
up
your
application,
it
just
scales
up
and
down
with
that
application.
It
needs
to
the
way
it
can
it
can
work.
Is
it
can
work
with
your
sidecar?
B
So
when
you
are
in
the
in
the
in
the
part,
one
approach
to
do,
that
is
be
the
sidecar
itself
where
it
is,
it
is
working
when
the
request
comes
in
it
tries
to
hit
the
API
it
inspects.
The
application
gives
it
a
thumbs-up
or
thumbs
down.
If
it's
a
thumbs
down,
it
goes
ahead
and
and
takes
the
application
out
the
request
out
and
if
it's
a
thumbs
up,
it
lets
the
application
through.
But
you
do
need
to
to
worry
about
the
existing
site
cards
that
you
might
have
in
place.
B
You
might
have
been
working
with
the
non
water
proxy
or
an
engineer
proxy.
That
is
that
you
rely
on
for
your
application
delivery
and
you
don't
know
necessarily
need
to
to
rip
and
replace
the
existing
side
curves,
just
because
you
want
to
to
put
security
in
so
so
this
this.
These
are.
The
security
micro
services
can
actually
be
injected
in
conjunction
with
your
existing
site
cards,
either
as
a
side
side
car
chain,
where
the
fear
where
your
the
the
primary
side
car
is
head
has,
it
might
be
your
own
boy.
B
So
just
it
so
this
is
this
is
what
the
the
new
runtime
application
protection
needs
to
look
like
in
in
the
new
world,
rather
than
having
sort
of
application
security
at
the
parameter
level,
which
has
no
understanding
of
these
micro
services
themselves.
It
needs
to
move
closer
to
the
app
to
the
application
themselves.
That
way,
you
were
targeting
the
few
limitations
of
the
perimeter
defense
that
we
spoke
about
as
you're
scaling
up
and
down
these
micro
services
at
the
individual
level.
Your
application
security
is
scaling
up
and
down
along
with
it
as
these
applications.
B
New
applications
are
in
Joost.
They
can
automatically
be
sort
of
protected
through
your
orchestration
platform,
like
a
steel,
can
automatically
inject
this
micro
service
in
the
same
part,
and
then
you
are
automatically
protected
around
that
you
can
take
sort
of
a
scalpel
like
approach
for
protection,
so
you
might
have
different
platforms
that
you're
talking
about
like
user
management
running
on
Java
or
data
services
or
PHP
your
application,
runtime
application
security
stack,
is
focused
towards
protecting
just
that
application,
rather
than
just
applying
all
kinds
of
generic
protections
for
all
kinds
of
services.
So
you
can.
B
You
can
focus
on
individual
micro
services
to
be
protected
rather
than
sort
of
a
generic
approach
at
the
at
the
interest
level
or
at
the
departmental
level,
and
then
the
last
aspect.
The
limitation
that
we
spoke
about
in
the
the
monolithic
world
is
absolutely
as
as
the
as
the
micro
service
is
transitioning
from
on
crammed
to
the
cloud
world
or
from
one
cloud
to
another.
The
the
security
is
actually
moving
with
it.
So
you
don't
need
to
worry
about
that.
Ok
did
I
did
I
protect
my
application
in
the
new
environment.
B
It's
automatically
moving
with
that
with
that
setup,
but
but
this,
but
what
you
also
need,
along
with
it,
is
a
sort
of
a
centralized
application
security
visibility
in
control.
So
you
don't
want
to
individually
manage
these.
These
parts
you-you-you
need
a
centralized
management
that
can
actually
discover
all
these
applications
that
are
coming
up.
You
get
centralized
visibility.
How
many
apps
are
running?
B
What's
being
abused,
any
configuration
that
you
want
to
enable/disable
for
these
services,
so
that's
also
needs
to
be
delivered
as
a
micro
services
that
is
running
in
your
environment,
going
out
to
the
cloud
and
and
making
all
those
decisions.
So
that's
that
sort
of
the
the
framework
that
we
are
presenting
so
sort
of
surfer,
summing
up
on
some
must-haves
in
the
sort
of
the
runtime
application
protection
for
micro
services.
It,
given
that
you
want
to
empower
your
developers
to
to
roll
out
new
new
applications
at
a
very
fast
pace.
B
So
that's
that
sort
of
a
framework
of
must-haves
that
that
we
define
for
for
the
new
way
of
doing
application
security.
So,
in
the
end
I
just
want
to
talk
about
the
way
you
be
thinking
about
sort
of
the
new
security
stack.
Obviously,
you
need
to
worry
about
the
infrastructure
security,
where
your
kubernetes
environment
is
actually
running
virtual
machines.
Are
they
being
patched
or
not?
Does
your
company
just
start
have
any
vulnerabilities
that
can
be
exploited?
So
you
need
to
keep
up
with
that.
B
Who's
talking
to
who
is
are
they
is
the
the
communication
secure
or
not,
and
so
on
and
so
forth?
But
in
the
end,
you
also
need
to
worry
about
the
the
runtime
of
the
application
itself
through
protections
like
Web,
Application,
Firewall
sort
of
auto,
but
defense
and
application
layer,
DDoS
defense,
and
rather
than
having
it
at
the
perimeter
layer,
it's
it's
much
better
to
have
it
closer
to
the
micro
service
itself
and
and
think
about
that
as
part
of
the
the
security
stack
in
the
Microsoft
this
world.
So
this
is
this.
B
This
was
more
of
a
introductory
sort
of
webinar.
We
plan
to
have
for
the
webinar
on
the
actual
way
of
actually
how
to
do
it.
How
to
eject
these
services.
So
I
look
forward
to
presenting
that
in
the
in
the
coming
weeks
or
months,
I'm
going
to
wrap
it
up
any
questions
on
this,
please
free
to
send
it
over.
A
Awesome,
thank
you
sure,
ions
for
a
great
presentation.
We
do
have
some
time
for
some
questions
and
Before.
We
jump
into
that.
I
will
just
want
to
add
that
cube
con
cloud
native
con
North
America
is
CN,
CF,
s--
flagship
event,
and
it
will
be
here
before
you
know
it
this
year,
it's
being
held
in
San
Diego,
which
should
still
be
sunny
and
lovely
in
November.
This
is
the
time
for
the
community
to
come
together
to
further
education
and
to
advance
cloud
native
computing.
A
So,
if
you'd
like
to
attend,
please
go
to
cute
con
dot,
IO
for
more
info
and
lock
in
your
ticket
before
it
sells
out.
So
with
that,
I
will
go
ahead
and
jump
into
questions.
It
looks
like
we
have
quite
a
few
I
can
read
from
the
top
strands.
Wahid
Malik
is
asking.
Is
this
a
micro?
Is
this
a
micro
segmentation
or
nano
segmentation
solution,
or
both.
B
So,
depending
on
how
you
look
at
it,
the
idea
really
is
I
would
think
of
it
as
model
for
micro
segmentation.
So,
as
your
odds
are,
the
security
is
built
into
the
pod
itself.
How
you
define
the
pod
is
really
up
to
you,
so
if
you,
you
can
take
it
to
the
level
of
nano
segmentation
and,
if
you
like,
so
it
really
depends
on
how
you
are
actually
designing
that
that
solution.
B
We
have
a
generic
way
to
work
with
the
ingress
controllers
as
well,
but
if
that
is
something
like
that,
we
spoke
about
the
limitations
of
integrating
it
more
than
the
parameter
level
that
could
be
a
a
P
I
get
where's
Bob.
So
the
approach
that
we
are
suggesting
is
moving
it
closer
to
the
micro
services
themselves.
B
Not
really
so
what
we
see
is
number
one
is
captures
have
been
broken
for
a
while,
and
especially
in
the
the
sort
of
kubernetes
or
micro
services
we'll
be
talking
more
about
ap
is
an
API
scan,
be
exposed
primarily
for
your
mobile
apps
or
sort
of
sort
of
machine-to-machine
communications
and
captures,
don't
really
work.
There
I
mean
there's
a
lot
of
information
available
on
our
site.
Why
captures
don't
work
feel
free
to
come
there?
So
there's
it's
not
a
simple
answer,
but
we've
seen
them
broken
all
the
time.
A
B
This,
the
the
primary
difference
here
is
because
of
the
the
the
micro
service
is
talking
to
each
other.
You
could
have
a
compromised
at
one
of
the
micro
service
level
and
that
can
be
used
to
sort
of
sort
of
horizontally
move
and
abuse,
so
you
want
protection
closer
to
what
is
getting
abused
than
sort
of
a
better
maker
based
approach
to
solving
it.
A
B
So
we
have
a
sort
of
policy
based
approach
to
doing
this.
This
this
kinds
of
this
kind
of
technology
gives
you
sort
of
a
intent
that
what
kind
of
attack
is
actually
going
on.
So
you
could
see
like
a
scraping
activity.
You
could
see
something
like
faith
like
activity
and
we
you
can
define
policies
ranging
from
simply
blocking
you
could
rate
limit
them
or
you
can
even
receive
them
by
sending
fake
responses.
B
So
again,
there's
a
very
long
answer
to
it,
but
you
can
definitely
go
to
our
site
and
look
at
how
we
can
actually
do
it
so
weak,
but
we
can.
We
could
have
policy
based
actions
to
rate
limit
block.
Even
he
will
send
signals
upstream
for
you
or
your
applications
will
decide
what
you
want
to
do
with
it.
Okay,.
B
So
we
have
an
option
for
both.
It
really
depends
on
on
on
customers
the
we
can
keep
everything
within
your
environment.
So
if
you
don't
have
to
worry
about
the
PIR
I'll,
be
giving
the
environment
or
lots
leaving
your
environment
if
your
company
is
supposed
to
do
sending
any
data
to
the
SAS
service,
if
you
interested
in
sass
service,
we
support.
B
There
are
a
few
I
can't
think
of
them
on
top
of
my
head,
so
this
is
so
what
what
what
we
we
presented
here
primarily
is
more
of
a
framework,
and
then
you
can
put
together
these
services
like
these.
You
don't
necessarily
have
to
use
sequence.
To
do
that,
you
can
use
open
source
services
to
do
the
same.
A
A
B
B
We,
like
I,
said
it's
it's
more
of
policy
based
approach.
We
leave
it
to
our
customers,
how
they
want
to
deal
with
it,
so
we
can
deny
them.
We
can
quarantine
them
in
the
Senate
and
put
them
in
sort
of
like
a
tar
pit
or
an
area
where
it
actually
doesn't
really
hit
the
actual
microservice.
We
can
even
send
them
fake
responses,
so
we
have
a
bunch
of
options
that
we
can
work
with.
Okay,.
B
So
it
really
depends
on
you,
so
if
you
don't
have
anything,
you
can
use
the
sequence
ID
card.
If
you
like
I,
said
earlier,
if
you
already
have
nginx
your
own
voice,
ID
card
you
can
you
can
inject
into
that?
It
really
depends
on
how
your
environment
is
rather
than
us
us
forcing
a
particular
way
of
doing
things.
A
B
Okay,
so
though
it's
it's
not
for
layer,
different
strategy,
I
mean
you
need
to
have
things
that
you
want
to
handle
at
the
perimeter
layer,
things
like
infrastructure,
layer,
DDoS
and
things
like
that
to
be
handled
at
the
perimeter,
but
you
can't
just
stop
there.
The
idea
really
is
you
are
actually
protecting
the
actual
microservice
and
the
protection
needs
to
be
closer
to
that,
so
that
it
has
better
context
around
the
request.
B
Do
yes,
video,
so
it
can
be,
it's
not
just
a
randomized
we
can.
It
can
be
on
a
per
application
basis,
because
every
application
is
different.
You
can
have
define
your
own
success,
failure
criteria,
you
can
define
and
you
a
conflation
criteria.
You
can
respond
with
different
languages.
All
those
options
are
aware.
B
Like
I
said,
we
have
sort
of
a
more
of
a
sort
of
short
answer,
is
very
low,
false
positive
rate
and,
and
the
way
you
do
it
is.
We
have
a
sort
of
a
confidence
based
approach
and
policy
based
actions
where
you
can
actually
define
your
own
tiles.
What
is
the
the
rate
that
you
can
be
happy
with
and
beyond
that?
We
can
just
send
the
signals
upstream
through
your
other
applications
or
fraud
system,
so
they
can
combine
our
signal
with
theirs
to
take
actions.
A
B
A
Great
and
it
looks
like
we
don't
have
any
more
open
questions,
so
thank
you
strands
for
a
great
presentation
and
looks
like
that's
all.
It
looks
like
we've
covered
most
of
the
questions,
all
of
them
actually,
so
thank
you
so
much
for
joining
us
today.
The
webinar,
recording
and
slides
will
be
online
later
on
today
and
we're
looking
forward
to
seeing
you
at
future
CN
CF
webinar
have
a
wonderful
day.
Thank
you.
Yeah.