AWS Lambda Security Quick Guide

In January 2018, the world’s first Serverless Security Top 10 guide was published. The guide was an effort lead by PureSec together with industry thought leaders, and covered topics such as AWS Lambda Security and Azure Functions Security. These days, we’re also working on getting the guide refreshed, and finding a new public home for it within the OWASP Cloud-Native Top 10 project.
The guide lists the following risks & challenges for serverless applications:

  • SAS-1: Function Event Data Injection
  • SAS-2: Broken Authentication
  • SAS-3: Insecure Serverless Deployment Configuration
  • SAS-4: Over-Privileged Function Permissions & Roles
  • SAS-5: Inadequate Function Monitoring and Logging
  • SAS-6: Insecure 3rd Party Dependencies
  • SAS-7: Insecure Application Secrets Storage
  • SAS-8: Denial of Service & Financial Resource Exhaustion
  • SAS-9: Serverless Function Execution Flow Manipulation
  • SAS-10: Improper Exception Handling and Verbose Error Messages
Today we’d like to share a few insights, on what we believe is the best strategy to mitigate these risks, and also to prove that if you do it right – you’re going to end up with a much more resilient application, and with a lot less security controls to worry about.

THE AWS LAMBDA Security Model

The AWS Lambda Security Model was created to help organizations formulate and implement a strategy for AWS Lambda security, that is tailored to the specific risks related to cloud-native serverless applications, as described in the Top 10 guide. Here it is:

Serverless Application Security Model

Let’s see what each component of the model means, and then map it to the Serverless Security Top 10 list.


Governance & Visibility: the most basic pre-requisite for any effective security strategy is the ability to know your risks and to know when/where you are being targeted. There’s really no point in bolting on security solutions, if you are blind to your risks. In the context of serverless applications – having a 360-degrees view of your serverless assets, their risks and weaknesses, and the current state is key. 

Resilient Design: good security posture must always start with a good system design –  a design that accepts the fact that failures will happen, breaches will occur, and weaknesses will be found. That’s why we’re big fans of the “Swiss Cheese” security model. Apply multiple layers of mitigation controls, and make sure that weaknesses never align.

Security Testing: security issues should be identified and dealt with in the development phase. Doing this will reduce overall costs incurred in the development and security of applications. According to the WhiteHat Security Application Statistics Report “SAST (static application security testing) errors are still taking an average of 113 days to remediate”. See why you should be doing this automatically, frequently, and most importantly as early as possible?

Cloud Configuration Best-Practices: Ok, there are no servers to manage in serverless (at least not for you…), that doesn’t mean you’re off the hook when it comes to following best-practices when it comes to your cloud configurations. In fact, we recently conducted several penetration tests for customers who asked us to asses their security posture – and in most cases, many of the risks could have been much more contained by following simple configuration best-practices.

Secure Code: writing secure code is your first line of defense. You can think of it as the third edge in the golden triangle of security (design, code, configuration). Unfortunately, in modern software, it’s not enough to write secure code. You should also make sure that the code you import from 3rd party libraries is secure.

Cloud-Native Event Data Inspection (serverless application firewall): never assume anything about the validity of your input. In the case of serverless, cloud-native events come in many different shapes and formats. Keep in mind that some event data fields are encoded using URL-encoding, Base64, or even Zip-compressed. Moreover, unless you explicitly verify the invoker of your function – you can never be sure your functions are getting invoked by the expected entity. If you didn’t read our blog post as to why WAFs are not enough, take a moment to read it.

Function Behavior Enforcement: not all malicious activity can be spotted by inspecting event-data input. For some attacks, it will take more than that. To learn more, read our blog post on the need for behavioral protection.

Mapping to the SAS Top 10

The following image maps the different model’s component, to the SAS Top 10 issues:


Mapping To Actual Risks & Attack Vectors

Let’s go over a few real world risks & attacks to serverless applications, and see how each mitigating control would help:

Malicious injections through event-data fields (SQLi, XSS, RFI, LFI, …):

  1. Using a serverless application firewall to perform even-data input inspection, will reduce most of the risks involved.
  2. Applying automated behavioral protection will make sure that functions will never behave in an unintended and malicious manner
  3. Secure coding & static analysis of code and configurations will reduce the attack surface

‘Backdoored’ 3rd. party libraries:

  1. Profiling serverless function behavior, and then enforcing known good behavior is critical when using untrusted 3rd party libraries
  2. Static analysis of 3rd party packages can help detect bad code. In addition, checking for known vulnerable libraries will reduce the risk

Exploiting the business logic of an over-permissive function/role to access resources or invoke other functions:

  1. Following IAM best practices (least-privileged) will contain the blast radius in case an attacker manages to manipulate your business logic or abuse a vulnerability. Automated scanning for IAM issues through code & configuration analysis will help to detect and remediate such problems early on, before deploying functions to the cloud.
  2. Applying automated behavioral protection will make sure that functions will never behave in an unintended and malicious manner

Serverless Crypto-Jacking (link):

  1. Applying automated behavioral protection will make sure that functions will never behave in an unintended and malicious manner
  2. Cloud configuration best-practices can help with monitoring & alerting in case someone is abusing your functions for unauthorized activity

Application layer Denial-of-Service (e.g. ReDoS)

A few months ago, we published a relevant security advisory, which demonstrates how this vulnerability can be exploited. Read more here.

  1. Resilient serverless application design is critical for avoiding application layer denial of service attacks
  2. Applying automated behavioral protection will make sure that functions will never behave in an unintended and malicious manner
  3. Event-data inspection can help in detecting some malicious payloads related to application layer DoS
  4. Cloud configuration best-practices

Sensitive data leakage through outbound channels: 

  1. Applying automated behavioral protection will make sure that functions will never behave in an unintended and malicious manner, and will block abnormal outbound connections
  2. Even data inspection / serverless application firewall can detect and block relevant payloads such as command injection.


AWS Lambda helps teams to achieve rapid development, reduced costs and unparalleled scalability. As presented in this post, it’s also bringing with it a promise of unparalleled security for applications – when done right and with the relevant strategy, tools and processes of course.

*** This is a Security Bloggers Network syndicated blog from PureSec Blog (Launch) authored by PureSec Team. Read the original post at: