AWS Lambda Security Quick Guide

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:

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

Overview

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: