►
From YouTube: Deep Dive: Serverless Security (STAG Presentation)
Description
Deep Dive: Serverless Security (STAG Presentation) - Moderated by Andrew J Krug, Datadog; Ragashree M C, Nokia; Ashish Rajan, CISO & Ariel Shuper, Cisco
Serverless encompasses many different facets and technologies in its creation, use, and execution. Serverless computing available by a provider permits the execution of a piece of code by dynamically allocating resources and adhere to a consumption based pricing model. These snippets or sections of code are called “functions” and can serve multiple needs as identified in the newly released CNCF Serverless Whitepaper, first available at KubeCon EU 2022. Over the past 6 months the CNCF Security Technology Advisory group has been working on a platform independent whitepaper on serverless security. This whitepaper incorporates the industry experience of STAG members alongside industry standard best practices. Join Ashish Rajan and Andrew Krug for this panel discussion with STAG whitepaper authors. We'll discuss what's changed since the last whitepaper was released and predict a few things about where serverless security is headed.
A
Hello
and
welcome
to
the
panel
for
cncf
today
we
are
well.
We
are
an
interesting
bunch
over
here
to
talk
to
you
about
serverless
and
everything
server
security
for
to
start
off
with
we're
going
to
do
a
basic
introduction.
I'll
just
start
with
my
introduction,
I
love
to
have
a
few
words
from
each
one
of
the
members
over
here
on
the
panel.
My
name
is
ashish.
I
am
the
host
of
classification
podcast,
I'm
a
cso
on
my925
and
run
a
live
stream
on
cloud
security
and
cloud
native
security
over
the
weekend.
B
C
A
Awesome,
thank
you
everyone
for
coming,
so
I
want
to
kick
it
off
because
considering
that's
a
40
minute
panel,
I
want
to
start
off
with
the
basic
for
a
lot
of
people
may
not
even
know
who
we
are.
What
do
we
do
so?
Maybe
the
first
question
to
ask
is
what
is
tag
in
the
cncf
and
how
does
anyone
become
part
of
it
andrew?
Do
you
want
to
just
kick
it
off
man.
B
Yeah,
so
the
the
tag
group
or
the
security
technology
advisory
group
is
a
a
group
of
folks
who
facilitate
and
collaborate
on
a
variety
of
security
topics
across
cncf
right.
So
they
do
do
everything
from
architecture
patterns,
prescriptive
guidance
to
white
papers
like
the
the
one
that
we're
going
to
talk
about
a
little
later
on
in
the
panel.
But
basically
this
is
just
an
open
group
that
really
anyone
can
be
a
part
of-
and
I
think
that's
one
of
the
really
cool
things
about
all
things.
B
People
can
join
any
security
project
and
there's
there's
a
variety
of
security
products
going
on
everything
from
like
serverless
to
software,
build
materials
projects
to
things
like
gatekeeper
for
kubernetes,
like
all
that
lots,
lots
and
lots
of
great
work.
So
I'd
encourage
anybody
who
was
interested
in
this
panel
you're,
probably
the
target
demographic
for
the
stack
right.
A
C
Right
so
there
is
a
serverless
white
paper
and
I
think
there
was
a
great
work
which
was
done.
You
know
a
few
years
ago
to
try
to
highlight
what
is
the
threat
landscape,
but
you
know,
like
everything
in
security
things
are
changing,
you
know,
serverless
is
changing.
There
are
more
services,
there
are
more
attack,
options,
more
risks
which
are
being
discovered,
and
I
think
it
was
a
good
time
to
refresh
the
previous
work
to
take
a
more
broader
look,
both
what
the
risk
which
exists
or
what
new
you
know.
A
C
C
I
would
say
the
way
you
can
visualize
your
entire
environment
or
the
permissions
that
you
grant
your
entitlement
and
and
different
configurations
that
you
do
on
different
cloud
services
has
a
significant
impact
on
the
actual
risk
of
the
serverless
function.
So
I
think
in
the
beginning
there
was
the
motivation
to
try
and
to
draft
what
would
be
the
risk
model.
What
will
be
the
different
threats
now?
We
can
see
more
and
more
services
which
are
being
used
today,
together
with
serverless
functions.
C
In
your
serverless
function,
so
even
if
there
are
small
pieces
of
code,
they
still
contain
different
packages
or
different.
You
know
they
use
different
services
that
create
a
different
risk
on
your
application.
So
I
think
all
of
it
together
nailed
down
to
a
need
to
both
address
the
serverless
security
from
you
know,
an
updated
angle.
Did
I
answer
your
question.
Ashish.
A
C
So
I
think
you
know
we
can
just
take
a
look,
and
I
think
you
know
we
can
discuss
it
more
in
lens.
You
know
later
in
you
know,
in
our
panel
about
the
new
exposure
of
https
http
endpoint,
without
passing
through
the
api
gateway
to
make
it.
You
know
simpler
and
easy
to
to
use
those
endpoints,
but
eventually
you
know
you
you
overlook.
I
mean
it's
very
easy
and
I
understand
the
motivation
why
you
know,
for
example,
in
aws
they
released
this
functionality,
but
bypassing
you
know,
api
gateway
or
bypassing.
C
You
know,
load
balancers.
It
avoids
all
of
the
security.
You
know
a
lot
of
security
mechanisms
which
are
built
into
it.
You
know
to
validate
and
to
verify
and
to
authenticate
and
authorize
the
requests
which
again,
for
as
an
example,
give
put
the
serverless
function,
which
is
being
invoked
in
a
different
risk.
So
maybe
this
is
like
something
specific
to
a
new
service.
C
C
Now,
when
you
look
at,
for
example,
you
know
what
all
you
know,
the
different
the
functions,
and
you
know
the
different
services
or
the
buses.
You
know
that
they
are
connected
and
again
under
the
assumption
that
you
want
them
to
run
free.
You
want
them
to
run
in
a
very
smooth
way.
You
want
to
avoid
performance,
you
know
degradations.
B
Think
the
bottom
line
here
when
we
think
about
the
attacks
and
threats
for
serverless
is
really
to
to
spin
that
and
think
about
how
the
attack
surface
is
increasing
right.
So
when
I
first
started
to
look
at
this
stuff
in
in
2017,
aws
lambda,
for
example,
was
pretty
new
and
you
know
there's
like
a
couple
of
patterns
for
for
getting
events
and
doing
invocations.
B
B
So
it's
just
more
and
more
complicated
and
as
different
runtimes
bolt
on
more
functionality
to
extend
the
capability
of
the
runtime
like
we
have
layers
now
and
you
can
even
bring
your
own
docker
container
that
suddenly
can
be
run
as
a
serverless
function,
the
more
diversity
that
we
get
in
those
environments.
They
become
more.
C
B
C
Yeah
yeah
and
you
know
I
definitely
could
I
just
wanted
one.
You
know
sword
and
andrew
said
you
know,
the
attack
victories
increases
but
unlocking
it
from
the
defender
side.
The
ability
to
defend
without
you
know
creating
you
know,
friction
or
degradation,
or
you
know
imposing
some
you
know
external
binaries
into
your
functions
is
really
small.
This
is
why
you
know
you
need
to
be
super
careful
and
how
do
you
configure
the
monitor.
A
Yeah
is
actually
true.
I
was
going
to
add
a
few
more
solid
examples
as
well.
I
think
to
what
you
said:
aerial
as
well
about
the
api
space.
I
think
it's
definitely
interesting
because-
and
I
think
maybe
this
is
a
combination
of
what
andrew
and
both
you
said
as
well,
with
the
apis
being,
I
guess,
the
trigger
for
starting
off
an
event
or
a
serverless
event,
not
having
control
over
the
api
that
can
send
a
request
to
your
android,
be
multi-cloud.
A
It
could
be
an
iot
device
and
plus
the
fact
that
now
there
is
no
workload,
protection
or
there's
no
antivirus
that
you
can
actually
deploy
on
a
serverless
machine.
The
the
I
guess
the
monitoring
aspect
of
it
is
like.
What
are
you
really
looking
for
in
a
real-time
context?
Is
a
lot
more
complex
and
I
don't
know
how
many
people
actually
out.
There
are
thinking
about
hey.
We
want
to
deploy
serverless,
but
then
I
don't
have
to
work
like
you
got
andrew
again
shared
responsibility.
How
much
is
mine?
A
B
I
mean
there's,
there's
a
variety
right
and
I
think
that
there's
been
a
lot
of
attention
lately
on
the
crypto
miners
that
have
popped
up.
Oh
yeah,
there
are
our
purpose
built
for
lambda
functions,
so
this
is
kind
of
a
interesting
time
right,
because
we
we
have
this
thing
now.
That
is
popular
enough,
that
people
are
making
bespoke
malware.
But
that's
really
not
the
attack
vector.
That's
the
the
post
exploitation.
You
know,
sort
of
mechanism
that
the
attacker
is
using.
B
I
think
the
most
important
thing
to
to
realize
is
that
attack
vectors
for
serverless
are
really
just
attack.
Vectors
like
this
they're,
the
same
ones
that
are
prevalent
in
our
owasp
top
10
model.
It's
just
that
from
a
forensics
perspective,
because
the
environment
gets
thrown
away
at
the
end,
it
can
be
really
really
difficult
to
reverse
what
happened.
So,
if
you
think
about
something
like
deserialization
vulnerabilities,
really
really
basic
right,
but
the
evidence
that's
left
behind
is
only
as
good
as
the
logging.
C
Yeah,
I
want
you
to
know
what
you
know
andrew
was
saying
it's
really
an
important
point.
You
know
how
do
you
inspect
them
because
in
containers,
for
example,
if
you're
on
crypto
miner
campaign
in
your
environment,
it's
easy
to
see
the
new
amount
of
containers
in
your
search
and
say:
hey,
I'm
not
familiar
with
it,
but
in
functions
you
know
which
are
ephemeral,
so
they
execute
and
decide,
and
you
only
can
see
afterwards.
C
A
Yeah,
I
mean
maybe
it's
a
good
segue
into-
what's
probably
a
good
practice
to
have
for
managing
or
certainly
starting
off,
doing,
serverless
security.
I
think
some
of
the
initial
points
that
come
to
mind
is
to
have
a
control
over
your
identity,
which
again,
we've
called
out
already,
maybe
having
some
kind
of
a
rollback
role
based
access
control
for
how
much,
because
I
think
the
number
of
lambda
functions
you
see
with
admin
roles
in
aws
and
I'm
sure
the
versions
of
this
do
exist
in
azure
and
google
cloud
as
well.
A
The
whole
supply
chain
security
has
definitely
become
quite
common
as
well.
They
have
a
cicd
pipeline
that
can,
at
the
end,
trigger
a
lambda
or
some
other
kind
of
a
serverless
function,
but
isn't
even
doing
a
validation,
whether
it's
authenticated
or
if
it's
restricted
to
a
certain
function
as
well.
A
I
think
the
one
theme
that
I've
taken
away
from
what
what
you
have
ariel
and
andrew
said
is
the
the
in
the
detection
part,
and
I
know
I
think,
andrew
you
had
some
thoughts
on
the
whole
logging
aspect
of
this
as
well
in
the
serverless
space.
What
do
people
do
for
logging
because
it
sounds
like
I
mean
I
can
build
the
most
secure
serverless
function
with
identities
covered
of
good.
I
don't
know
my
code
is
really
secure.
A
B
Yeah,
I
think
it's
it's
really
interesting
kind
of
right
now.
What
we're
seeing
evolve
in
the
serverless
space,
which
is
that
observability,
that
we
used
to
use
for
performance
monitoring
and
just
generally
determining
if
the
system
is
healthy,
has
become
the
very
same
facilities
that
we
need
to
do.
Security
right
and
in
some
ways
our
need
to
use
those
same
logs
for
security
has
enhanced
the
the
way
that
we're
doing
logging
right.
B
So
when
those
attacks
do
come
in
and
you
do
have
a
facility
for
detecting
that
that
the
attack
has
come
into
the
service
serverless
environment,
you
can
immediately
sort
of
create
this
graph.
And
when
I
say
graph,
I
mean
like
graph
like
bloodhound
makes
like
graph
theory,
that
of
the
potential
path
of
the
attacker
through.
B
A
Oh
something
like
a
miter
attack
framework,
a
little
bit
yeah.
Okay.
That
would
be
so.
To
your
point
I
mean
I
guess,
because
what
ariel
pen
mentioned
was
quite
interesting,
because
if
it
doesn't
exist,
are
there
any
specific
things
we're
looking
for
logging
then,
like,
I
think,
are
there
from
a
security
perspective.
What
do
you
recommend?
How
does
this
help?
It.
B
So
I
think
it's
important
to
divide
divide
this
up
into
like
kind
of
two
efforts
right.
It's
like
one
effort
number
one
is
like:
how
do
you
make
the
logs
so
that
they're,
readable
by
machines
and
by
humans
right
you'll,
hear
people
say
like
oh
jason,
just
jsonify,
all
your
logs
and
you're
kind
of
done.
B
A
B
Use
in
a
detection
platform
or
something
and
maybe
standardize,
those
or
or
remap
them
to
the
same
ones
I
use
for
the
cloud
providers,
control
plane.
So
all
of
a
sudden
we're
able
to
do
correlation
between
events
in
something
like
aws
cloudtrail
and
what's
happening
inside
of
the
application
itself,
so
sort
of
just
thinking
about
what
are
the
pieces
of
data
for
my
business.
You
know
my
use
case
and
service
that
I
want
to
bring
together
to
perform
detections
on
the
application
itself.
A
B
Yeah,
so
if
you,
if
you
really
think
about
it,
what
what
you
want
is
you
want
this
entire
chain
of
custody,
of
attribution
from
the
invocation
of
the
function,
to
the
time
that
that
function,
exits,
right
and
and
depending
on
the
method
by
which
you're
you're
invoking
the
run
time?
That
runs
the
code,
that
that
could
be
a
bunch
of
different
ways
right.
So
if
it
comes
in
through
api
gateway,
that's
an
event
whose
identity
is
api
gateway.
B
If
it's
a
user
calling
invoke
function,
that's
different
if
it's
a
cloudwatch
event
on
eventbridge,
that's
a
different
story
too,
so
being
able
to
attribute
those
back
to
how
did
this
thing
even
get
started
and
then
knowing
what
happened
inside
of
it
and
knowing
what
happened
afterwards?
Potentially,
if
somebody
got
an
identity
out,
that's
telling
the
story.
A
Yeah-
and
I
guess
to
your
point,
if
you
can
trace
it
back
to
what
was
the
change
in
the
function
code
itself,
maybe
that
could
be
one
one
more
data
point
into
that
whole
flow.
If
there's
a
data
point
chain
or
if
there's
a
change
to
the
function
which
made
the
change
and
how
did
that
travel
across
your
production
or
whatever
cool
anything,
to
add
to
this
aerial
or
you're
good,
I
think
you're
good.
A
Oh
perfect
cool,
so
because
I
think
I
was
going
to
say:
maybe
it's
also
a
good
segue
into,
because
I
guess
what
we're
also
trying
to
cover
is
some
of
the
interesting
topics
that
came
out
of
the
whole
server
is
security
by
papery
road,
so
I'll
definitely
encourage
people
to
kind
of
check
it
out
when
we
release
it.
But
one
thing
that
we
were
looking
also
was
into
the
whole
evolution
and
what
does
the
future
of
serverless
look
like?
A
Obviously,
everyone,
who's
listening
to
the
panel
has
obviously
heard
about
the
different
kind
of
threats
that
exist.
They've
also
heard
about.
How
do
you
log
it
properly?
So
if
there
is
a
change
or
there
is
a
threat
that
needs
to
be
picked
up,
there
is
to
andrew's
point,
there's
an
end
to
end
attack
path
that
you
can
come
up
with,
maybe
similar
to
attack
miter.
A
Maybe
attack
might
may
come
up
with
a
framework
for
this
as
well,
but
one
of
the
things
that
came
up
with
the
future
thing
was
the
the
whole
aspect
of
abstraction,
as
we
kind
of
keep
going
into
more
layers
of,
I
don't
need
to
care
about.
In
my
infrastructure
anymore,
so
that
means
I
don't
need
to
care
about
patching.
I
don't
care
about
my
workload
protection.
I
don't
care
about
antivirus,
then,
if
I
go
into
ci
cd
pipeline
well
as
long
my
function
probably
covers
the
whole
basic
application.
A
There's
a
lot
more
abstraction,
but
that's
kind
of
what
we
won't
have
the
future
for,
but
I
I'm
pretty
sure,
as
all
of
us
are
hinting
towards
white
paper,
we
kind
of
probably
should
go
in
through
what
went
through
into
doing
the
whole
white
paper
as
well.
Maybe
raga
you
could
just
probably
give
us
some
intro
into
the
whole.
Was
the
process
undertaken
for
the
white
paper
since
you
were
quite
involved
as
well.
Could
you
shed
some
light
on
that
for
everyone
listening.
D
Surely
so
the
basic
process
itself
is
already
stated
in
this
call.
There
was
already
a
serverless
white
paper
available,
so
the
first
step
for
us
is
to
identify
what
are
the
gaps
that
was
in
the
white
paper,
and
how
could
we
fill
it
from
the
security
perspective
itself?
So
majority
of
the
threads,
some
of
the
myths
we
had
to
burst
and
some
of
the
best
practices
we
can
share
with
the
community
to
enlighten
and
support
in
the
complete
end-to-end
life
cycle
of
their
securing
the
serverless
itself.
D
So
with
this,
the
first
step
itself
was
to
jot
down
all
the
aspects
we
wanted
to
cover
in
the
white
paper
and,
second,
is
to
trigger
one
issue
in
our
stag
github.
So
with
this
we
got
a
lot
of
interest
from
the
community.
We
assigned
some
of
the
project,
leaders
and
rolled
out
the
plan,
and
we
had
consistent
meetings
across
a
couple
of
weeks.
D
We
synced
up,
I
think,
once
in
a
week
and
aligned
with
all
of
us,
took
the
projects
and
we
worked
on
our
content
individually,
got
the
feedback
and
released
the
first
set
of
version
for
the
internal
reviews
as
well,
and
once
we
thought
we
are
in
good
shape
and
we
are
okay
to
go
ahead
for
a
wider
audience
review.
The
paper
was
released
for
the
complete,
secure,
stack
security
team's
mailing
list,
and
it
is
now
in
the
review
phase
of
the
the
community
as
well.
A
It's
really
I
I
can
definitely
watch
for.
There
are
definitely
interesting
conversations
during
the
whole
whether
something
is
relevant
for
the
white
paper
who's,
the
audience.
What's
the
context
for
it
as
well,
so
people
who
may
be
thinking
about
hey,
I
want
to
contribute,
because
I've
heard
these
four
awesome
people
on
a
panel,
and
I
wanna-
I
don't
know-
is
there
a
mailing
list
or
something
or
the
other
people
can
subscribe
to?
You.
D
Absolutely
stacks
github,
I
think
andrew
has
already
pasted
on
the
chat
so
stacks
github.
You
can
subscribe
to
this
repository.
There
is
a
mailing
list
right
in
the
stacks
repo.
Please
subscribe
to
the
mailing
list.
You
will
get
all
the
content
up
to
date
with
whatever
we
are
publishing.
There
are
several
lots
of
projects
available
right
from
the
policy
s-bombs
and
serverless
here,
and
we
also
have
an
interesting
topic
of
lexicon.
D
So,
whatever
you
want
to
contribute,
you
can
just
pull
up
an
issue
and
get
the
attention
of
our
chairs
and
we're
here
to
help
you
and
we
have
a
wonderful
support
system
in
terms
of
mentorship
or
anything.
You
need
to
get
started
or,
if
you're,
a
seasoned
professional
we
are
seeking,
your
inputs
always
so
feel
free
to
get
in
touch
with
us.
We
have
our
stag
security
slack
as
well,
so
feel
free
to
dm
us
and
we're
happy
to
help.
A
Sounds
good
and,
although,
as
I
said
earlier,
serverless
security,
probably
the
coolest
group
and
they've,
been
the
batch,
but
there's
definitely
a
lot
more
projects
in
there.
I
got
already
if
you
want
to
work
on
s
bomb,
but
software
bill
of
material,
because
it
was
a
presidential
order,
but
you
can
totally
do
that
as
well.