►
From YouTube: Webinar: Securing Your Serverless Journey
Description
With serverless, the cloud provider is responsible for securing the underlying infrastructure, from the data centers all the way up to the container and runtime environment. This relieves much of the security burden from the application owner, however, it also poses many unique challenges when it comes to securing the application layer. In this presentation, Ron Harnik of Palo Alto Networks will discuss the most critical challenges related to securing serverless applications – from development to deployment. We will also walk through a live demo of a realistic serverless application that contains several common vulnerabilities, and see how they can be exploited by attackers, and how to secure them.
A
Good
come
okay,
so
thank
you.
Everyone
for
joining
us
welcome
to
today's
CNC
ebon
are
securing
your
server
list
journey,
I'm,
Sanjeev,
Rampal,
I'm,
the
principal
engineer
at
Cisco
and
I'm,
also
a
CNC.
If
ambassador
I'll
be
moderating
today's
webinar,
we
would
like
to
welcome
our
presenter
Ron
Harnack,
who
is
the
senior
product
planning,
marketing
manager
at
Prisma
cloud
by
Palo,
Alto
Networks,
a
couple
of
housekeeping
items
during
the
webinar
me,
you
will
not
be
able
to
talk
as
an
attendee.
There
is
a
Q&A
box
at
the
bottom
of
your
screen.
A
Questions
again
note:
please
do
not
put
your
questions
in
the
chat
window,
please
put
them
in
the
Q&A
window.
This
is
an
official
webinar
of
the
CNC
f
and
a
subject
to
the
cnc
of
code
of
conduct.
Please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct.
Basically,
please
be
respectful
of
yourself,
your
fellow
participants
and
presenters
with
that
I'm
gonna
hand
it
over
to
Ron
to
kick
off
today's
presentation.
A
B
B
I
started
out
as
network
engineer
and
then
slowly
move
through
different
roles
within
the
engineering
organizations
and
product
before
I,
eventually
sold
out
and
moved
to
a
marketing
role.
So
I
was
with
pure
sec
the
several
security
platform
that
was
acquired
by
Palo,
Alto,
Networks
I
think
just
over
six
months
ago,
and
then
I
got
the
opportunity
to
join
the
Prisma
cloud
product
marketing
team.
So
even
though
now
I
get
to
talk
about
cloud
native
security
as
a
whole,
server
list
is
still
something
that
I'm
very
passionate
about.
B
So
I'll
take
every
opportunity
that
I
can
to
yell
at
my
laptop
about
serverless.
So
so
thank
you
for
giving
me
another
one
of
those
opportunities.
I
live
in
Israel
with
my
wife
and
my
two
beautiful
twin
girls,
which
I
am
obsessed
with
throwing
a
picture
in
them
of
them
in
everything.
I
do
so
here's
a
picture
of
them
now.
Alright!
So
let's
quickly
go
over
the
agenda
for
today
and
just
like,
we
said
at
the
top,
please
feel
free
to
send
your
questions
through
the
Q&A
panel.
B
I'll
try
to
get
to
most
of
these
as
I
go
along,
but
if
there'll
be
any
unanswered
questions
by
the
time
we
wrap
up
we'll
try
to
get
to
those
in
the
end.
So
we'll
start
off
by
covering
what
service
security
is
in
a
nutshell
at
a
high
level
and
make
sure
that
we
all
understand
just
generally
how
a
function-based
application
works,
we'll
focus
on
a
few
risks
and
pitfalls.
B
Obviously,
there's
a
lot
that
we
can
talk
about
and
we
can
even
broaden
the
discussion
to
cover
application
security
as
a
whole,
but
we'll
very
much
focus
on
function,
based
applications
and
and
we'll
take
a
look
at
a
few
of
the
things
that
you
need
to
be
on
the
lookout
there
and
then
we'll
wrap
it
up
by
doing
a
quick
demo
of
how
we
might
carry
out
an
attack.
You
know,
I'll
tell
a
fun
little
story
that
that
happened
to
us.
While
we
were
at
pure
SEC.
B
That
I
think
really
helps
illustrate
the
importance
of
permissions
on
on
functions.
So
it
should
be
a
good
time.
Okay,
so
the
first
part
of
almost
any
conversation
that
you
have
about
cloud
security,
not
just
server
low
security,
almost
always
starts
with
this
idea
of
the
shared
model
of
responsibility
and
I'm.
Sure
most
of
you
on
this
webinar
ever
heard
this
a
million
times
when
you
move
to
the
cloud
when
you
start
using
something
like
Google
cloud
platform
or
AWS
or
any
other
public
cloud
platform.
B
The
shared
model
of
responsibility
at
its
simplest
form
divides
into
two.
The
cloud
provider
is
responsible
for
the
security
of
the
cloud,
so
that
is
anything
like
the
data
centers
themselves
or
anything
underneath
the
virtualization
layer
that
you
care
about
and
you
as
a
user.
You
care
about
the
security
in
the
cloud,
so
everything
that
you
put
into
these
workloads.
So
your
code,
the
your
permissions
into
into
these
workloads,
things
like
that
with
server
lists,
there's
an
interesting
shift
that
that
happens
within
that
model.
B
Beneath
the
virtualization,
when
you
go
serverless
or
when
you
start,
this
is
offset
a
little
bit
sorry
about
that.
So,
but
when
you
adopt
more
of
a
service
framework,
there's
something
really
interesting.
That
happens
to
this
split,
where
the
cloud
provider
actually
takes
on
a
lot
of
responsibility,
and
you
take
on
less
responsibility
when
it
comes
to
what
is
left
to
secure.
B
So
it
almost
ends
up
being
like
this
50/50
split,
and
it's
interesting
for
someone
in
my
position,
because
working
for
a
security
company
typically
would
go
up
on
stage,
and
you
would
talk
about
this
scary,
new
technology
that
you
have
to
do
all
these
things
in
order
to
leverage
successfully
while
with
server
lists.
The
conversation
is
more
like
you
just
have
to
think
about
a
few
things
differently,
but
your
starting
point
in
terms
of
security
is
actually
pretty
strong,
because
now
you
don't
have
to
think
about
patching
your
operating
system.
B
You
don't
have
to
think
about
networking
or
a
big
list
of
other
things
that
you
used
to
have
to
worry
about.
Obviously,
there
are
new
attack,
vectors
and
new
things
that
you
have
to
worry
about
and
most
of
the
things
that
are
relevant
to
application
security.
As
you
know,
them
today
are
still
going
to
be
irrelevant
and
that's
exactly
what
we're
gonna
be
covering
today,
so
just
to
make
sure
that
we're
all
in
the
same
page,
I
try
to
make
this
as
accessible
as
possible.
B
To
folks
who
are
veterans
with
server
lists
and
folks
who
are
new
to
serverless
workloads
and
even
the
term
server
lists
can
be
sort
of
like
a
point
of
contention
in
terms
of
what
it
actually
means,
but
for
the
sake
of
our
discussion
today,
I'm
talking
specifically
about
applications
that
are
based
around
functions.
So
around
function
as
a
service
services
like
lambda
or
Google
cloud
functions,
for
example.
So,
typically
how
these
applications
would
work
is
something
like
this.
B
You
would
have
a
developer
commit
code
to
a
code
repository
and
then
that
code
will
go
into
a
function,
for
example
in
AWS
lambda
function,
then
that
code
would
sit
there
and
it
would
wait
to
be
triggered
by
some
sort
of
an
event.
So
some
sort
of
an
event
will
happen.
It
will
trigger
this
piece
of
code.
Then
the
function
will
do
whatever
it
is.
It
was
designed
to
do.
B
Maybe
it
will
interact
with
another
cloud
resource
or
maybe
it
will
just
have
some
sort
of
output,
for
example,
in
a
little
bit
we'll
be
covering
a
serverless
application
that
is
essentially
used
for
HR
for
hiring,
so
someone
sends
an
email
with
PDF
resume
attached
to
it.
That's
yet
that
get
insert
that
gets
intercepted
by
a
cloud
service
that
then
triggers
a
lambda
function
and
then
that
lambda
function
takes
that
file,
converts
it
to
text
and
puts
it
in
database
table.
B
So
roughly
follows
the
the
sequence
of
events
that
were
seen
here:
the
the
core
of
server
lists
or
the
core
of
these
types
of
function
as
a
service
tools
that
you
can
use
is
that
typically,
this
will
be
a
very
small
piece
of
code
that
represents
like
a
micro
service.
It
will
usually
not
be
some
massive,
like
monolith
of
code,
it's
very
much
towards
the
cloud
native
approach
of
adopting
micro
services,
because
these
functions
will
typically
be
short-lived.
B
So
they'll.
Typically,
you
live
for
only
about
15
minutes.
So
it's
really
not
a
discussion
of.
Should
you
go
a
hundred
percent
server
list,
or
should
you
go?
Should
you
evolve
from,
for
example,
containers
into
server
lists,
it's
more
of
like
a
spectrum
right,
a
spectrum
of
compute
options
where
you
might
have
your
virtual
machines
on
one
side
and
you'll
have
something
like
like
Fargate
or
Google
cloud
run,
and
then
you
might
have
something
like
lambda
or
cloud
functions,
and
every
different
tool
is
going
to
be
good
for
different
types
of
jobs,
all
right.
B
Let's
focus
on
what
weighs
not
what
what
the
actual
risks
are.
But
what
are
the
paths
that
he
could
possibly
take
in
order
to
compromise
our
application,
so
the
first
and
maybe
the
most
unique,
to
serve
a
list
that
that
needs
to
take
a
look
at
is
event.
Data
injection
and
I'm
sure
we're
familiar
with
injection
attacks
like
SQL
injection,
for
example,
but
with
server
lists.
You
have
to
remember
that
there
are
thousands
of
event
sources
that
you
could
potentially
use
in
order
to
trigger
your
function.
B
So
it's
it's
not
necessarily
going
to
be
an
HTTP
header
that
we
can
be
very
familiar
with
with
fields
in
the
cookies
and
and
the
different
parameters
within
there,
but
it
can
be
an
s3
bucket
or
it
can
be
a
kanessa
stream
or
you
know
any
of
those
types
of
things.
Each
one
of
those
events
or
tsa's
is
going
to
have
its
own
structure
in
its
own
format,
of
how
it
conveys
information
and
those
are
things
that
could
potentially
be
manipulated.
B
In
order
to
compromise
the
function,
another
would
be
unauthorized
deployment,
so
this
would
be,
for
example,
a
phishing
attack
where
someone
was
able
to
deploy
code
out-of-band
directly
into
your
lambda
function,
for
example,
because
they
got
the
credentials
to
your
AWS
account
or
anything
in
in
that
way.
Something
that's
gonna,
be
less
far-fetched
and
much
more
common,
not
just
in
service,
but
in
application
security
in
general,
it's
going
to
be
dependency,
poisoning
in
dependency
poisoning.
Really.
B
So
that
would
be
something
to
look
out
for
this
vector
I
just
want
to
add
dependency
poisoning,
it's
something
that
is,
that
exists
as
an
attack
vector
in
pretty
much
all
forms
of
application
security.
Specifically
what
server
lists
the
challenge
is
going
to
be.
How
do
you
detect
that?
And
what
can
the
attacker
actually
do
if
they
compromised
your
function?
And
finally,
the
last
vector
that
I
want
to
talk
about
is
tampering
with
data
or
really
compromising
the
cloud
services
that
your
function
interacts
with.
B
So
a
typical
function
based
application
or
a
service
application
is
not
going
to
be
made
just
out
of
functions.
You're
gonna
have
maybe
a
storage
bucket
talking
to
a
function,
that's
talking
to
a
database
table,
and
maybe
that
is
talking
to
another
function,
or
maybe
you
have
a
website
where
you
have
multiple
different
functions.
Doing
the
login
or
one
is
loading.
The
pictures
and
one
is
the
storing
all
the
user
data
whatever
it
might
be,
there's
going
to
be
interaction
to
a
lot
of
different
cloud
sources
within
that
process.
B
If
one
of
those
other
services
it
gets
compromised,
then
that
entire
application
could
get
compromised
and
that's
actually
exactly
the
example
that
I'm
gonna
walk
through
in
just
a
little
bit
and
a
little
story
that
we
put
together
for
you
so
I
think
the
most
famous
example
of
this
is
s3
buckets
that
are
open
to
the
Internet.
So
maybe
your
function
itself
is
locked
down
tight,
but
it
stores
lots
of
data
on
an
s3
bucket
that
is
open
to
the
Internet
and
then
an
attacker
might
be
able
to
compromise
your
function
through
there.
B
What
can
an
attacker
actually
hope
to
achieve
with
these
types
of
attacks?
Well,
these
are
typically
the
same
things
that
you
will
find
with
typical
applications
security,
so
they
might
be
able
to
compromise
data.
So,
for
example,
let's
say
that
you
have
a
function.
That's
talking
to
a
DynamoDB
table.
If
that
function
has
permissions
to
essentially
do
whatever
it
wants.
With
that
DynamoDB
table
once
that
function
is
compromised,
then
the
attacker
will
be
able
to
exfiltrate
data
from
the
DynamoDB
table.
B
That
they're
talking
to
which
again
is
relevant
to
the
example
that
that
we'll
see
in
a
little
bit.
So
this
is
just
a
quick
overview
of
some
of
the
vectors
that
you
might
need
to
look
out
for
with
service.
So
what
can
you
do
to
educate
yourself
about
this?
So
one
thing
that
I
would
definitely
definitely
recommend
is
to
read
this
white
paper
from
the
Cloud
Security
Alliance.
This
is
something
that
a
lot
of
different
experts
from
different
companies
came
together
and
put
this
together.
Definitely
not
product
related.
B
B
I
would
very
much
recommend
that
you
go
through
it
and
read
it
just
because
it
goes
into
much
more
detailed
and
we'll
have
time
for
today,
for
what
are
the
attack
vectors
that
that
you
should
be
worried
about,
should
be
on
the
lookout,
for
what
can
you
do
to
harden
your
applications,
and
it
also
just
has
a
lot
of
really
great
insights
about
how
function
as
a
service
tools
work.
So
I
can't
cannot
recommend
this
enough,
and
this
was
done
by
the
cloud
security
Alliance,
which
is
a
fantastic
organization
all
right.
B
You
don't
have
access
to
any
of
that
under
underlying
infrastructure,
so,
for
example,
if
you
have
that
s3
bucket,
that's
talking
to
your
lambda
function,
there's
nowhere
for
you
to
put
a
firewall
between
those
two
and,
if
you're,
only
using
something,
for
example,
that
looks
at
an
API
request,
its
HTTP
headers.
That's
only
gonna
cover
a
small
percentage
of
the
things
that
could
trigger
your
functions,
so
that
is
typically
where
you
have
to
think
about
this.
A
little
bit
differently.
So
with
server
lists.
The
application
owner
doesn't
have
any
control
over
the
infrastructure.
B
So
traditional
security
tools,
I,
don't
know
if
traditional
is
the
right
word
here,
but
traditional
security
tools
are
unsuitable
to
secure
a
hundred
percent
of
these
types
of
environments.
Having
said
that,
I'm
very
much
laser
focused
on
service.
For
this
conversation,
it
is
important
to
remember
that
in
most
environments
it's
gonna
be
some
sort
of
a
hybrid
right.
You're
gonna
have
your
server
list
applications
you're
going
to
have
your
containers.
You're
gonna
have
your
differently
at
your
G
ke
s
and
E
KS
and
Fargate,
and
your
actual
VMs.
B
So
security
is
a
much
broader
conversation,
but
specifically
about
how
do
you
secure,
for
example,
a
lambda
talking
to
a
dynamodb
table,
yeah
you're
not
going
to
be
able
to
do
that
with
an
agent
deployed
on
a
server
or
or
with
something
that
inspects
anomalies
on
the
network?
Let's
take
a
look
at
how
typically,
you
would
protect
an
application,
you
might
have
your
application
code
and
you
might
have
something
for
endpoint
protection
that
takes
a
look
at
the
behavior
of
the
application
itself.
B
Maybe
you'll
have
some
sort
of
IPs
type
tool
that
takes
a
look
at
Network
anomalies.
You
might
have
a
secure
web
gateway
that
takes
a
look
at
outbound
traffic
or
you
might
have
some
sort
of
firewall
that
takes
a
look
at
inbound
traffic
and
you'll
have
maybe
even
an
external
firewall.
Taking
a
look
at
your
your
layer,
seven
traffic
and
all
of
this
goes
on
your
infrastructure.
B
So
with
that,
the
entire
concept
of
security
is
pretty
much
reduced
to
strong
code
and
strict
configurations.
So
what
can
each
function
do?
What
permissions
does
it
have?
Obviously,
there
are
other
tools
out
there
that
that
you
can
use
in
order
to
take
another
step,
but
those
are
those
become
the
two
strongest
components
of
serverless
security.
B
So
I'd
like
to
take
a
quick
break
from
just
trying
to
reiterate
the
same
point
over
and
over
again
about
the
difference
between
surveillance
and
traditional
applications
and
I'd
like
to
go
through
a
story
that
I
think
does
a
really
good
job
at
illustrating
the
importance
of
permissions
with
serverless
applications.
So
this
is
something
that
happened
while
we
were
at
pure
sex.
So
this
was
before
the
acquisition
and
we
just
thought
it
was
a
fun
story
to
share.
So
this
guy
Caleb
Zima,
who
I
think
is
with
Capital
One.
B
Now
he
essentially
put
up
this
website
called
lambda
she'll
calm,
it's
no
longer
up,
but
what
he
wanted
to
see
is
his
service
in
secured
his
tool
like
lambda,
for
example,
is
it
a
security
risk,
let's
find
out
so
I
threw
up
this
website.
He
put
a
shell
into
the
application
on
the
website
and
he
said
that
if
someone
is
successful
with
hacking
into
this
application,
they'll
give
them
a
thousand
dollar
bounty,
so
our
CTO
at
the
time
Ori
Sehgal.
This
is
him,
saw
this
and
essentially
he
was
like
okay
challenge
accepted
so
aurea's.
B
Now
that's
at
Palo,
Alto
Networks
leading
a
product
team,
but
at
the
time
he
was
the
CTO
of
pure
sec,
so
we
saw
that
he
said.
Maybe
this
could
be
some
good
PR
for
us,
let's
go
ahead
and
and
do
it
okay,
so
the
first
thing
that
he
wanted
to
do.
You
already
have
access
to
this
shell
right
so
from
some
remote
code
execution,
essentially
like
the
holy
grail
of
application
security.
He
thought
he
was
most
of
the
way
done
already.
B
So
the
first
thing
that
he
tried
to
do
is
to
get
the
environment
variables,
and
all
of
this
is
no
longer
online.
So
that's
why
we
have
no
problem.
You
know
putting
this
on
a
public
webinar,
but
he
try
to
get
the
environment
variables
from
from
the
shell
in
order
to
try
to
impersonate
the
lambda
function,
so
he
exported
the
secret
access
key
and
the
access
key
to
his
own
machine
and
then,
when
he
did
SDS
get
call
her
identity.
Essentially,
he
tried
to
check
how
does
a
double
use.
B
How
does
AWS
sees
me
as
the
role
of
this
function?
He
saw
that
he
actually
assumed
the
role
of
this
function,
so
he
effectively
impersonated
the
function
itself.
So
in
his
mind
he
was
essentially
in
like
he
did
it
so
right
after
that
or
he
was
walking
around
I'm,
the
smartest
and
alive.
This
is
awesome.
He
was
genuinely
very,
very
happy
afterwards.
He
tried
playing
around
with
the
I'm
permissions
a
little
bit,
so
he
tried
to
list
the
different
functions.
He
tried
to
run
a
few
commands
and
he
saw
that
he
failed
miserably.
Now.
B
This
is
interesting
because
he
got
access
to
where
the
code
is
right.
He
got
access
to
the
function
so
in
any
other
form
of
application
security
that
could
have
been
game
over.
But
because
there
was
a
strict
I
am
profile
around
that
lambda
function.
Then
he
wasn't
able
to
really
do
anything
other
than
what
this
function
is
supposed
to
do.
So
there
were
pretty
strict
on
permissions,
so
it's
it's
kind
of
it
kind
of
reduced
the
blast
radius
around
that
function.
B
B
It
was
not
a
good
time
at
the
office,
then
one
of
our
researchers
suggested
that
there's
a
there's,
probably
an
s3
bucket
involved
just
and
typically
best
practice
is
usually
to
use
the
domain
name
for
the
name
of
the
bucket,
where
you
host
the
files
for
it.
So
he
ran
this
command
head
bucket
and
he
saw
that
he
didn't
get
anything
in
return
and
essentially
what
this
prompted
him
to
think
is.
B
Is
this
some
sort
of
quirk
of
AWS,
or
maybe
there
is
a
bucket
there,
and
and
maybe
so
because
he
saw
that
he
was
not
getting
an
error
or,
like
a
permission
denied,
so
he
tried
a
few
times.
He
tried
to
do
the
same
command
with
just
another
random
domain
name,
and
then
he
saw
that
he
did
get
the
404,
so
is
confirmed
from
him
for
him
that
this
original
bucket
does
really
exist.
B
Okay,
so
he
was
able
to
list
the
different
objects
within
there
and
he
saw
that
he
did
gain
some.
Some
sort
of
access
into
this
s3
bucket
and
his
next
step
was
to
see.
Do
I
actually
have
write.
Permissions
can
I
actually
do
something
with
this
bucket,
so
maybe
he
was
a
little
bit
drunk
off
of
the
champagne
that
he
had
earlier,
but
his
first
idea
was
to
delete
the
index.html
file
that
then
he
found
there,
which
of
course,
immediately
crashed
the
website
and
again.
B
So
a
key
component
in
that
story,
one
of
the
main
characters
there
was
I,
am
Identity
and
Access
Management.
Typically,
that's
the
way
it's
called
to
process
all
the
different
clouds.
Most
of
my
examples
here
were
on
AWS,
just
because
that's
where
most
of
this
happened,
so
let's
talk
a
little
bit
about
what
you
can
actually
do
in
order
to
leverage
I
am
to
secure
these
types
of
applications.
So
the
challenge
with
the
least
privileged
approach,
which
is
I,
think
pretty
unanimously
the
best
approach
you
could
possibly
have
with
with
serverless
or
with
functions.
B
It
will
essentially
mean
that
you
want
each
function
to
only
be
able
to
do
the
very
least
that
it's
that
it
can
or
just
exactly
the
task
that
that
it's
supposed
to
do
and
nothing
else.
So,
for
example,
if
you
have
a
function
that
all
it's
supposed
to
do
is
to
put
files
in
a
DynamoDB
table,
then
that
should
be
everything
that
that
function
is
allowed
to
do.
B
The
model
around
around
I
am
is
extremely
powerful.
It
just
it's
hard
to
get
right,
because
what
do
you
do
when
you
have
thousands
of
different
functions
right?
It
gets
challenging
at
scale,
so
the
problem
typically
is
introduced
with
the
human
factor,
and
it
becomes
very
tempting
to
use
that
star
button
right.
B
A
wild
card
in
your
permissions
that
essentially
will
give
a
function
complete
permission
into
whatever
it
is
that
that
it's
interacting
with
the
issues
around
functions
having
more
permissions
than
they
should
are
probably
the
most
common
service
security
issues
that
we're
seeing
out
there.
Obviously,
serverless
is
still
on
the
rise.
It's
still
something
that
is
in
the
middle
of
adoption.
It's
not
as
mainstream
as
containers.
Just
yet,
but
I
mean,
with
the
rate
that
tools
like
Google
cloud
functions
and
lambda
have
been
growing,
there's
no
doubt
that
it's
on
its
way.
B
So,
for
example,
if
all
the
function
actually
has
to
do
is
to
put
items
in
a
DynamoDB
table,
but
with
the
permissions
you
see
here,
there's
a
star.
It
means
that
if
that
function
is
if
that
function
is
compromised,
it
means
that
that
DynamoDB
table,
regardless
of
its
own
permissions,
will
definitely
be
compromised.
So,
when
I
do
this
session,
live
I'd
like
to
do
a
quick
quiz
at
this
point
and
talk
about
how
we
you
can
kind
of
name
and
how
you
have
to
know
how,
to
name
and
spell
the
correct
time
permissions.
B
Obviously
we're
not
going
to
do
that
here,
but
what
we
typically
talk
about
is
how
do
you
spell
the
exact
permission
to
put
item
for
dynamodb,
because
the
permissions,
when
you're
talking
about
what
the
function
can
do
and
what
a
user
can
do
they
look
a
little
bit
different.
So
you
have
to
make
sure
that
you
read
documentation
and
that
you
use
the
the
correct
write
the
correct
form.
B
If
you
do
end
up
giving
your
function
just
a
wild
card,
in
the
permission
just
a
total
permission
to
do
whatever
it
needs
to
do
with
that
dynamodb
table.
This
is
everything
that
it
will
be
able
to
do
so
it
will
be
able
to
completely
annihilate
that
dynamodb
table
and
I'm
I
just
keep
using
the
same
tools
for
this
example,
because
I
feel
that
if
I'll
start
mentioning
millions
of
different
tools,
it
might
just
get
too
confusing,
so
I'm
sticking
to
lambda
and
dynamodb.
B
Just
because
that's
the
example
that
we'll
be
looking
at
so
you
can
take,
you
can
think
about
I'm
permissions
kind
of
like
bulkheads
in
a
submarine
or
on
a
ship
right,
even
if
the
function
itself
or
whatever
service
that
that
that
I'm
profile
is
wrapped
around.
Even
if
that
gets
compromised.
The
blast
radius
is
pretty
much
contained
exactly
like
a
bulkhead
on
on
a
submarine
that
function
can
only
put
more
stuff
into
that
dynamodb
table.
It's
not
ideal,
but
it's
better.
B
Okay,
so
a
few
quick
tips
for
getting
on
permissions
right
so,
like
we
said
trying
to
adopt
a
role
per
function
model
where
you
have
a
specific
role
for
each
function.
That
only
gives
it
least
privileged
exactly
what
it
needs
to
be
able
to
do
think
twice
before
it
hitting
shift
eight.
That
eight
here
is
missing
a
little
pop-up
here
in
a
little
bit,
Sam
managed
policies.
Are
your
friend
there's
a
an
example
for
this
as
well
and
there's
an
equivalent
with
serverless
framework
for
this
as
well?
B
So
here's
an
example
of
what
not
to
do
Amazon
DynamoDB
full
access,
just
the
equivalent
of
putting
the
star
in
that
profile.
Here's
a
better
thing
to
do
where
you
only
give
crud
permissions
to
one
specific
table
and
here's
the
even
better
thing
that
you
can
do
give
the
give
your
function
just
a
very
specific
action
that
it
should
be
allowed
to
do
for
each
for
each
function.
There
is
a
free
least
privileged
I
am
automatic
role
generator,
which
is
an
open-source
tool
that
that
you
could
use
still
available
for
now.
B
I'll
link
it
a
little
bit
later,
but
it's
still.
It's
still
out
there
for
now,
so
I'll
have
a
link
for
that
at
the
end
of
the
slide.
Alright.
So
before
we
wrap
up,
let's
take
a
look
at
a
quick
example
and
I
think
this
would
be
a
good
way
to
a
good
thing
to
end
on
and
let's
take
a
look
at
a
sample
application
that
we
have
built
out
as
an
example
for
how
you
might
carry
out
such
an
attack.
So
we
have
this
CV
filtering
system.
B
This
HR,
automated
application
that
we've
built
that
is
completely
based
on
service
pools,
so
lambda
and
other
abstracted
services
from
AWS
in
this
case,
and
essentially
what
it
does.
A
candidate
will
send
an
email
with
a
PDF
attached
to
it
a
resume
that
will
get
intercepted
by
simple
email
service
and
they'll
get
a
receipt
back,
just
an
email
back
saying
like
hey,
we
got
your
resume
Thanks
and
then
that
triggers
an
SNS,
Q
and
sorry
an
SNS
topic,
and
then
that
topic
will
trigger
a
lambda
function.
B
All
that
lambda
function
does
is
essentially
it
receives
the
PDF,
it
converts
it
to
text
and
it
stores
it
in
a
DynamoDB
table.
If
you've
been
following
around
this
presentation,
you
probably
know
where
this
is
going,
but
this
is
the
application
that
we
have
here
built
app.
So,
let's,
let's
take
a
look
at
it.
So
I
have
this
gmail
account
open
here,
since
this
application
rests
on
essentially
receiving
emails
with
PDFs
attached
to
them.
B
So
there's
no
kind
of
web
portal
for
me
or
like
webpage
for
me
to
attack
so
first,
let's
see
that
the
application
works
as
a
as
a
chip.
So
in
the
subject,
let's
say
my
CV:
this
is
my
CV
patched
and
let's
go
ahead
and
attach
my
John
Smith
dot.
Pdf
file,
I'm
gonna,
send
this
over
and
the
application
will
work
as
we
as
we
saw
it.
Illustrated
the
the
file
will
get
intercepted
by
simple
email
service.
It
will
talk
to
us
and
s.
B
It
will
talk
the
lambda
and
will
do
the
whole
things
and
in
about
10
seconds
we
should
get
a
receipt
back.
So
here
it
is.
Thank
you
for
contacting
us.
One
of
our
recruiters
will
contact
you
shortly.
Great.
The
application
is
working
as
expected.
Now,
let's
say
for
the
sake
of
discussion
that
I
did
not
get
the
job,
and
now
it
has
become
my
sole
purpose
in
life
to
destroy
this
company.
That
didn't
give
me
the
job,
so
I
want
to
do
a
bit
of
reconnaissance
right.
B
I
want
to
understand
a
little
bit
about
this,
this
application.
So
let's
try
this
a
chart,
email
again
and
once
again,
let's
say
this
is
my
CV
and
this
time.
Essentially,
if
you
think
about
it,
I
don't
really
have
a
lot
to
work
with
here,
except
for
the
name
of
the
file.
So
obviously
there's
there
are
a
few
more
steps
of
reconnaissance
that
we
might
be
able
to
do,
but
we
don't
have
too
much
time
here
so
so.
B
You'll
have
to
trust
me
that
we
fake
did
a
few
more
steps
of
reconnaissance,
but
what
I'm
trying
to
see
as
the
attacker
here
is,
can
I
affect
the
code.
Can
I
do
like
a
code
injection
attack
into
this
application,
so
essentially
will
I
be
able
to
pass
this
command
into
the
code
of
the
application?
Does
it
accept
user
input,
as
is
so
I'll?
B
Attach
this
and
I'll
say
this
is
my
CV
honest
and
let's
go
ahead
and
send
this
again
now
we're
not
gonna,
wait
5,000
seconds
to
see
that
we're
not
gonna
get
the
the
alert
back.
The
the
receipt
back
you're
gonna
have
to
trust
me
that
we
won't
because
the
function
will
time
out
so
once
I've
done
this
and
I
saw
that
okay
I
do
have
a
path
into
the
application.
B
So,
let's
say
again
my
CV-
and
here
let's
say
how
could
you,
let's
attach
another
one
of
these
files,
and
you
see
that
now
what
I'm
trying
to
do
is
I'm
trying
to
curl
a
script
from
paste
bin
into
this
application
and
essentially
what
this
script
will
do
is
it
will
try
to
read
the
application
code
and
send
it
back
to
me
over
email,
so
I'm
gonna
head
and
attach
this
let's
send
this
over.
We
can
actually
take
a
take
a
look
at
the
code
in
the
meantime,
so
this
is
that
code.
B
This
is
what
I'm
trying
to
do:
I'm
trying
to
read
the
application
code
and
then
I'm
trying
to
send
this
back
to
the
email
address.
Let's
see
if
we're
getting
anything
back
should
be
getting
something
in
a
little
bit,
and
here
we
see
that
that
we
did
get
first
another
receipt,
so
this
is
the
first
receipt
that
we
got
and
done
another
one,
and
second,
we
see
that
we
got
the
function
code,
let's
see
what
we
got
here.
So
this
is
the
actual
code
of
the
function.
B
This
is
really
what
I'm,
after
let's
say
that
I'm
gonna
exact
my
revenge
in
the
form
of
data
leakage,
I'm
gonna,
steal
the
data
from
the
other
candidates
and
I'm
gonna
I,
don't
know,
sell
I,
don't
know
what
you
do
with
it.
So
I
can
see
that
there
are
some
security
practices
in
here.
So,
for
example,
I
see
that
they're
checking
that
the
file
ends
with
dot
PDF,
which
is
okay,
but
I'm,
also
seeing
that
they
are
accepting
essentially
user
input
here.
B
So
everything
after
the
colon
like
it,
was
John
colon
and
then
I
curled
the
the
script.
There
is
essentially
accepted
into
this
code
and
and
I'm
able
to
execute
that.
So
this
is
what
I'm
interested
in
I
can
see
that
there's
a
dynamodb
table.
This
is
where,
if
all
the
permissions
that
this
function
really
had
was
to
just
put
items
in
this
dynamodb
table,
there
isn't
too
much
damage
that
I
would
have
been
able
to
do.
B
We
can
actually
take
a
look
at
that
script
as
well,
so
we
can
take
a
look
at
it
here.
Essentially,
what
I'm
trying
to
do
is
I'm
trying
to
scan
the
the
dynamodb
table
and
then
I'm
trying
I
want
to
exfiltrate
that
data
dump
it
back
into
the
email.
Send
it
back
to
me
here
and
we
see
that
we
actually
did
get
it.
So
I
got
a
DynamoDB
dump.
This
is
all
the
information
from
in
there
with
all
the
emails
and
personal
information
for
lots
and
lots
of
candidates
and
I.
B
Think
the
most
interesting
thing
here
is
that
this
is
not
a
vulnerability
of
of
AWS
or
Google
cloud
or
wherever
you
run
the
function.
This
is
a
vulnerability
in
the
code
that
that
the
developer
wrote
in
this
case
it's
us,
but
this
is
something
actually
pretty
common.
It's
because
the
code
is
running
directly
on
the
the
cloud
platform
and
the
vulnerability
in
the
code
itself
that
we
were
able
to
do
this.
B
So
if
you
think
about
it
in
this
case,
AWS
didn't
do
anything
wrong
right,
because
the
function
has
permissions
to
read
its
own
code
and
to
export
it,
and
it
has
the
permissions
to
do
and
it
had
the
permissions
to
read
the
dynamodb
table.
So
if
you
take
a
look
at
your
cloud,
watch
logs
or
cloud
trail
or
anything
really,
you're,
not
gonna
see
anything
out
of
the
ordinary.
B
So
it
just
illustrates
the
importance
of
having
type
permissions
around
your
functions
and
obviously
there
are
tools
out
there
that
you
can
use
to
take
security
to
the
next
step,
but
but
at
the
most
basic
level.
That
is
something
that
your
you're
able
to
leverage
as
well
as
just
being
aware
of
the
importance
of
having
strong
code
all
right.
So
just
the
last
thing
that
I
want
to
wrap
up
on
in
terms
of
taking
action
and
maybe
getting
more
familiar
with
this.
B
So
once
again,
I
cannot
recommend
enough
the
12
most
critical
risk
for
service
by
the
cloud
security
alliance-
great
great
white
paper,
very
educational-
for
you
to
go
over
read
what
are
the
risks
be
aware
of
them?
At
least
some
of
them
are
obviously
more
advanced,
but
the
first
few
ones
really
are
the
ones
that
you
need
to
watch
out
for,
and
you
can
also
take
a
look
at
the
OWASP
server
list.
Coat
application.
There's
a
link
for
that
up
here.
That
is
essentially
just
an
application
that
you
can
deploy.
B
Attack
play
around
with
impress
your
friends
at
parties
with
your
server
low
security
skills
and
finally,
there
is
a
least
privileged
CLI
tool.
It's
currently
still
available,
I'm,
not
sure
if
it's
gonna
be
there
for
long,
so
you
might
as
well
grab
it.
It's
not.
The
end-all
be-all
of
I
am
security,
but
it's
a
tool
that
you
can
use
in
order
to
generate
a
baseline
for
a
least
privileged
I
am
role.
B
A
A
B
So
it's
I
mean
you.
You
have
to
remember
that
unless
you
you
deny
something,
then
the
function
will
be
able
to
do
it.
So
in
terms
of
being
able
to
inspect
it's
its
own
code,
yeah,
that's
gonna,
be
the
default
behavior
and
those
are
going
to
be
the
the
things
that
you're
gonna
have
to
watch
for,
either
with
governing
them
with
iron
profiles
or
finding
other
ways
to
block
those
types
of
command.
Injection
attacks
got.
A
It
thanks
looks
like
Chris,
had
a
question
yeah.
B
B
The
planet
of
security
platform,
along
with
twist
lock
and
read
lock,
and
the
other
companies
that
got
acquired
recently
and
all
of
the
capabilities
in
there
are
all
the
capabilities
from
these
companies
are
have
already
been
integrated
into
this
tool
and
in
terms
of
service
security,
then
you
can
definitely
use
it
in
order
to
detect
and
block
the
command
injection
attacks.
Behavioral
protection
for
your
functions
to
prevent
it
from
running
processes.
It's
not
supposed
to,
as
well
as
getting
a
very
high
level
of
visibility
into
the
permissions
of
your
functions.
B
B
So
we
have
another
question:
how
does
the
security
policy
get
stored
and
applied?
Is
it
via
s3
bucket,
so
the
security
policy
for
individual
functions?
If
we're
talking
specifically
about
the
native
tools
that
you
have
out
there
with,
for
example,
with
AWS,
it
will
typically
be
an
iamb
profile
that
you
assign
to
the
the
function.
So
you
don't
you
don't
necessarily
have
to
store
it
in
an
s3
bucket.
B
If
you,
if
you're
talking
about
other
tools
like
prism
cloud
or
typically
or
other
other
security
tools,
then
it
will
typically
be
some
sort
of
wrapper
around
your
code.
So
when
your
function,
when
AWS
invokes
your
function,
so,
instead
of
calling
your
handler,
it
might
call
our
handler
so
we'll
be
able
to
inspect
the
event
data
so
that
will
typically
bring
part
of
it
and
the
other
part
will
be
an
offender
with
the
AWS
account
to
be
able
to
view
vulnerability,
stance
and
things
like
that.
B
If
I
can
give
it
a
thought,
another
question
is
that,
can
you
give
us
any
thoughts
about
security
as
it
relates
to
alternative
service
systems
like
open,
fast
and
I?
Think
so
personally,
I
don't
have
too
much
experience
with
with
open
fast,
but
I
think
that
it's
really
different
once
you're
talking
about
something
that
that
you're
essentially
deploying
I,
don't
know
if
on
Prem
is
the
the
right
word.
The
security
of
the
underlying
infrastructure
is
still
gonna,
be
something
that's
gonna,
be
your
responsibility
in.
B
A
Okay,
any
more
questions
I
think
that
about
wraps
it
up
so
great.
Thank
you,
Ron
for
a
great
presentation.
Thank
you.
Everyone
for
joining
us
today,
the
webinar
recording
and
the
slides
will
be
online
later
today,
we
look
forward
to
seeing
you
again
at
a
future.
Cnc
at
webinar
have
a
nice
day.
Goodbye
thanks.