Securing Serverless Systems

Copyright 2018 Vincent Lau
Securing Serverless Systems
a sharing by Vincent Lau

Agenda
2
Introduction
● What is Serverless or FaaS
● IaaS vs CaaS vs PaaS vs FaaS
● How is Serverless Used
● Examples of Serverless Architecture for IoT & AI
3
Security Impact of Going Serverless
● Change in the Shared Responsibility Model
● From Denial-of-Service to Denial-of-Wallet
● Increased Attack Surface & System Complexity
10
Top 10 Serverless Security Risks & How to Mitigate Them 14

Introduction
What is Serverless or FaaS?
3
Apps where server-side logic written by the app
developer is running in stateless compute containers
that are event-triggered, ephemeral (may only last for
one invocation), and fully managed by a 3rd party
(e.g. AWS Lambda).
It is also known as “Functions as a Service” or "FaaS".

Introduction
Top FaaS Providers
4
Others
● IBM OpenWhisk
● Alibaba Function
Compute
● Iron Functions
● Auth0 Webtask
● Oracle Fn Project
● Kubeless

Introduction
Top Serverless Frameworks
5
Serverless Framework Languages
● Serverless Framework (Javascript,
Python, Golang)
● Apex (Javascript)
● ClaudiaJS (Javascript)
● Sparta (Golang)
● Gordon (Javascript)
● Zappa (Python)
● Up (Javascript, Python, Golang, Crystal)

Introduction
6
https://medium.com/@nnilesh7756/what-are-cloud-computing-services-iaas-caas-paas-faas-saas-ac0f6022d36e

Introduction
How is Serverless Used
7
Occasional Requests
• If a server app only processes one request
per minute
• It will take 50ms to process each request
• So the CPU usage over an hour is 0.1%
• If this app is deployed to its own dedicated
host, it would be very inefficient
Inconsistent Traffic
• If your traffic profile is very spiky
○ baseline traffic is 20 requests/second
○ but every 5 minutes you receive 200
requests/second for 10 seconds
• Auto-scaling is not a good option; by the time
your new instances have spun up, the spike
phase will be over.
Horizontal scaling is completely automatic, elastic, and managed by the provider, but
the biggest benefit is that you only pay for the compute that you need.
https://martinfowler.com/articles/serverless.html#FaasScaling
Costs

Introduction
Serverless Architecture of IoT
8
Jogging Lap Counter
● The IoT button is connected to a local wifi
network or a mobile hotspot.
● Button can record different types of presses:
Single click – add a lap
Double click – reset the counter
Long press – reset the counter
● A DynamoDB table counts the number of
laps per button.
https://www.thinkahead.com/blog/using-aws-iot-running-buddy/

Introduction
Serverless Architecture of AI
9
https://chatbotsmagazine.com/a-serverless-event-driven-architecture-for-
chatbots-3095eb40cbb7

Change in the Shared Responsibility Model
10
https://aws.a
mazon.com/
compliance/
shared-
responsibilit
y-model/

From Denial-of-Service to Denial-of-Wallet
11
A serverless platform would just scale to continue handling all the requests it needed to,
and would be near impossible to DDoS.
BUT… Somebody still has to pay!
Even with the microbilling structure of FaaS, being hit with a few thousand requests per
second will still give you a hefty bill.
Hence, this is now known as a Denial of Wallet attack.
DOS (usually malicious) is an interruption in an authorized user's access to a cloud
service. It is often accomplish by flooding the target with traffic, or sending it information
that triggers a crash.

Increased Attack Surface
12
Serverless functions consume data from multiple
event sources:
● HTTP APIs
● message queues
● cloud storage
● IoT device communications
Attack surface induces protocols and complex
message structures, which are hard to inspect by a
typical web application firewall.
Attack surface is complex, and the architecture is
relatively new to developers, hence the chances of
misconfiguration is very high.

Overall System Complexity
13
Apps developed with serverless
architecture are:
● Difficult to visualize and monitor
● Difficult to run automated security
scans
● Difficult to test locally
Units of integration with FaaS are a lot
smaller than with other architectures,
resulting with higher reliance on
integration testing.
FaaS also takes DevOps out of the
picture!

Top 10 Serverless Security Risks & How to
Mitigate Them
14
Function Event Data Injection
• Occurs when an untrusted input is passed
directly to an interpreter and gets
executed or evaluated
• Multiple event sources increases the
potential attack surface and introduces
complexities
• E.g. Cloud storage events, Stream
processing events, Message queue events
Broken Authentication
• Serverless apps architected in microservices-
like system design often contain many distinct
functions with their own purpose
• Some may expose public web APIs, while
others may serve as a proxy to different
functions or processes
• E.g. Exposing Unauthenticated Entry Point via
S3 Bucket with Public Access
https://dzone.com/articles/top-10-security-risks-in-serverless

Mitigate Them
15
Insecure Serverless Deployment
Configuration
• Serverless architecture is relatively new, the
probability of misconfiguring critical
configuration settings are quite high
• Make functions stateless while designing
serverless architectures
• Do not expose sensitive data to any
unauthorized personnel
Over-Privileged Function Permissions and
Roles
• Follow the principle of “Least Privilege”,
functions should only be given necessary
privileges to perform the intended logic
• Provisioning over privileges to a function could
end up being abused to perform unintended
operations, such as “Executing System
Functions”

Mitigate Them
16
Inadequate Function Monitoring and
Logging
• To achieve adequate real-time security
event monitoring with proper audit trail:
○ Collect real-time logs from different
functions and cloud services
○ Push these logs to a remote security
information and event management
(SIEM) system
Insecure 3rd Party Dependencies
• Serverless function is required to depend on
3rd party software packages, open source
libraries, and consume 3rd party remote web
services through API calls
• Look at 3rd party dependencies before
importing their code as they could be
vulnerable and can make the serverless
application susceptible to cyber attacks

Mitigate Them
17
Insecure Application Secrets Storage
• Need for storing and maintaining app
secrets such as :
○ API keys
○ Database credentials
○ Encryption keys
○ Sensitive configuration settings
• Encrypt environment variables and don’t
store plaintext secrets (e.g. AWS Key
Management Service)
Denial of Service and Financial Resource
Exhaustion (a.k.a Denial of Wallet)
• Define execution limits:
○ Per-execution memory allocation
○ Per-execution ephemeral disk capacity
○ Per-execution number of processes and threads
○ Maximum execution duration per function
○ Maximum payload size
○ Per-account concurrent execution limit
○ Per-function concurrent execution limit
• Use an API Management Gateway

Mitigate Them
18
Functions Execution Flow Manipulation
• Functions are chained; invoking a specific
function may invoke another function, thus
the order of invocation is critical for
achieving the desired logic
• Manipulating an application's flow will help
an attacker to subvert the application logic
in bypassing access controls, elevating user
privileges or even cause DoS attacks
Improper Exception Handling and Verbose
Error Messages
• Line-by-line debugging is more complicated
and limited for serverless apps
• Verbose error messages, such as stack traces
or syntax errors, expose internal logic of the
serverless function, revealing potential
weakness, flaws, or sensitive data
• Developers must remember to clean up

Q & A
Thank you
19
Let’s connect via
http://sg.linkedin.com/in/vincentktlau

Securing Serverless Systems

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (19)

Semelhante a Securing Serverless Systems

Semelhante a Securing Serverless Systems (20)

Mais de Vincent Lau

Mais de Vincent Lau (7)

Último

Último (20)

Securing Serverless Systems