Going Serverless on AWS Lambda? Recognize Potential Risks
Serverless computing allows developers to build and run applications without worrying about infrastructures. Serverless computing services eliminate infrastructure management tasks like capacity provisioning and patching, and offer automatic scalability, high availability and a granular pay-for-use billing model.
Amazon Web Services (AWS) Lambda is a popular event-driven serverless computing platform that allows users to run code without the need to manage infrastructure. Within Lambda, code is stored in a code deployment package. All interaction with the code occurs through the Lambda API (application programming interfaces) and there is no direct invocation of functions from outside of the service. Lambda functions have many use cases, but the main one is to respond to and process events. While it is popular among the DevOps community for the many benefits it offers, it comes with a spectrum of security risks that are too often neglected.
Why Consider Security When Using AWS Lambda?
Security is a key consideration when using AWS Lambda for three primary reasons.
- AWS Lambda functions are used to build applications: AWS Lambda provides a highly reliable service, allowing users to deploy serverless applications with confidence. Lambda is suitable for mission critical applications in many industries, offering a wide range of Lambda use cases. A broad variety of customers, from media, retail, and consumer services to banking and financial services and other regulated industries, take advantage of Lambda. The managed runtime environment model enables Lambda to manage much of the implementation complexity of running serverless workloads. A security incident that compromises your Lambda functions can result in widespread disruption to several mission-critical aspects of your business.
- AWS Lambda functions process sensitive data: Sensitive data includes personal identifiable information (PII) such as customer names, social security numbers, driver’s license numbers, financial information and medical records that can identify an individual. If this data were to be accessed or modified by an unauthorized party, it could result in serious harm to individuals and your business.
- AWS uses a shared responsibility model for security: Security and compliance is a shared responsibility between AWS and the customer. What this means is that Amazon Web Services (AWS) owns “security of the cloud” and handles protecting the infrastructure that runs all the services offered in the AWS Cloud. On the other hand, “security in the cloud” is always customer’s responsibility. As an example, for abstracted services, such as Amazon S3 and Amazon DynamoDB, AWS runs the infrastructure layer, the operating system, and platforms, and customers access the endpoints to store and retrieve data while customers handle managing their data (including encryption options), classifying their assets and using identity and access management (IAM) tools to apply the right permissions. When it comes to Lambda, the data integrity and confidentiality is the responsibility of the AWS customer. Therefore, AWS and its customers have a shared responsibility to ensure the continuous security of Lambda implementations, ensuring that they are protected from potential security threats.
What Security Risks Could Be at Work Here?
Let’s examine some security risks that your unsecured Lambda functions could be exposed to:
Authentication and Access Control
An application built using serverless functions contains numerous AWS Lambda functions. Each programmatic function is distinct and serves a specific purpose. When spliced together and orchestrated, the functions create the overall business logic where the configuration and management of servers are invisible to the end user. Some functions collect, store and dynamically display real-time data, while other functions connect payment and API gateways to automate transactions.
Additionally, some functions “consume events” or subscribe to an event that triggers your functions to run. An event triggering a Lambda function could be almost anything, from an HTTP request through API Gateway, a schedule managed by an EventBridge rule, an IoT (Internet of Things) event or an S3 event.
In other words, when using AWS as your cloud provider, an “event” is any occurrence in AWS that triggers a Lambda function, like an S3 bucket upload, an SNS topic or HTTP endpoints created via API Gateway. You can imagine the security complexity arising from each function having different expected outcomes, triggered from a different event and with no notion of the other moving parts.
Broken authentication in serverless architectures results from poor application of identity and access controls management especially with multiple services, events, triggers and no continuous flow.
Any unauthenticated and unauthorized access to functions can break the system’s business logic and flow of execution. Applying rigorous AuthN+AuthZ schemes that provide robust access controls to every function, event types and triggers must be managed carefully to close the door on the possibility of a security breach.
Function Event-Data Injection
On AWS, Lambda functions must be connected to events from several sources that trigger their execution. The overabundance of event sources expands the attack surface. Securing Lambda functions from event-data injections then becomes a complex task. The type of event and its source determines whether the event input is controlled by an attacker. Some types of event data are resistant to corruption by an attacker.
Identity Access Management
For Lambda functions, AWS manages the underlying infrastructure and application platform, the operating system, and the execution environment. The DevOps team handles continuous security in the SDLC (software development life cycle), starting from code security, as well as identity and access management to the Lambda service and within their serverless functions.
As a rule of thumb, granting permissions and access should follow the “principle of least privilege,” which essentially means that the Lambda functions should only be assigned those privileges that are essential to performing their intended logic.
In a real-world scenario, this is easier said than done. For example, if you need to write an IAM policy for a Lambda function that needs access to the DynamoDB service, you need to work through over 50 different DynamoDB permissions and give least-privilege access to exactly those sets of permissions that the Lambda function would need to execute on its intended logic and nothing else. You must also work through the condition keys that allow granting of access under certain conditions.
Now consider another very realistic scenario where your serverless application is made up of dozens, if not hundreds, of different Lambda functions. The sheer number makes managing function permissions and roles a daunting task. If you lean on a single permission model or security role for all Lambda functions, you will inadvertently grant all functions full access, thereby creating a security risk.
Another issue to note is the possibility of an IAM credential leak due to an IAM policy misconfiguration. Lambda functions use temporary security credentials when they are granted an IAM role. When the function executes, it receives access tokens from the AWS security token service. An attacker who maliciously gains access to the tokens can remotely impersonate the function from outside the Lambda environment and retrieve any resources available to it.
Logging and Monitoring
Serverless monitoring allows developers to gain important insights on each execution and event. AWS provides the logging service CloudTrail and the monitoring service CloudWatch. AWS CloudTrail is enabled by default on every AWS account once the account is created. When a supported event activity occurs in AWS Lambda, that activity is stored in a CloudTrail event, along with other AWS service events in the “Event History” console.
Lambda automatically monitors the functions on your behalf and reports metrics through Amazon CloudWatch. From a security standpoint, it’s critical to log and monitor security related events to detect and mitigate risks in real time. While it’s true that both tools are extremely valuable, for some developers the tools’ out-of-the-box configurations aren’t always conducive in capturing the entire security event audit trail that is bespoke to your application.
Ensuring Security Is a Shared Responsibility
AWS provides a robust set of security controls for its users. But it is up to the users to make the most of these built-in capabilities. The AWS Lambda console helps secure your Lambda functions by allowing you to view and manage your Lambda functions, including their configuration files and IAM roles. However, to eliminate the possibility of inheriting vulnerabilities in your Lambda functions, it’s important to ensure that only verified code from trusted publishers is deployed within Amazon Lambda and vulnerable functions are weeded out. These are key to a safer deployment.
Panoptica Secures AWS Lambda Serverless Functions
It’s evident that AWS Lambda is undoubtedly at the heart of serverless applications. The “stateless” nature of Lambda functions, with no affinity to the underlying infrastructure, allows you to focus solely on what you love doing most — developing code.
Cisco Panoptica scans serverless functions in AWS accounts and evaluates them for security issues and vulnerabilities. After connecting it to your AWS account, Panoptica scans your serverless functions for security issues and vulnerabilities and assigns them a risk score, ranking them based on the score. The risk scoring is based on the function’s code and the cloud configuration metadata and takes the following into account:
- Authentication and authorization of functions, verifying identified and authorized function triggers.
- Code vulnerabilities in open source packages or dependencies.
- The presence of secrets, such as keys and passwords, in the function’s code or environment variables.
- Inappropriate or excessive permissions granted to functions.
- Functions with public-access exposure and access to data sources that might be targets for exfiltration.
- Dead or inactive functions.
You can manually trigger a scan at any time, or you can schedule scans to be run at regular intervals. What else? Configure the policies, customizing the types of risks that apply to your environment. If Panoptica’s risk score rises to an unacceptable level, you can set it to kill the process and alert you — letting you know exactly which serverless function triggered the alert.
For signing and verification of core cloud function artifacts, such as images or code, use our open source tool FunctionClarity. Its code-signing capabilities ensure the trust and integrity of your functions, allowing for tamper proofing and nonrepudiation.