The big shift to serverless computing is imminent. According to a 2019 survey, 21% of enterprises have already adopted serverless technology, while 39% are considering it. Serverless technology appeals to many enterprises as it allows them to concentrate on creating better code for their applications, as opposed to managing and securing the infrastructure needed to run the applications.
Serverless computing refers to the technology that supports back-end services and allows enterprises to take advantage of shifting certain responsibilities to cloud service providers (CSPs) such as Amazon Web Services (AWS), including capacity management, patching, and availability. With serverless computing, enterprises can build back-end applications without being directly involved in availability and scalability. The term “serverless,” however, doesn’t mean that this computing model doesn’t use servers at all, because it does. It’s just that enterprises no longer need to be directly involved in maintaining and securing servers.
The security of serverless architectures is ensured for the most part by CSPs, which handle the security of the infrastructural computing components of serverless technology. This is why serverless technology is regarded as relatively more secure than other cloud computing models. But like any other existing technology, it’s not immune to risks and threats.
Our research paper “Securing Weak Points in Serverless Architectures: Risks and Recommendations” aims to shed light on the security considerations in serverless environments and help adopters in keeping their serverless deployments as secure as possible. It focuses on services offered by AWS, which has the widest range of offerings available in the serverless services market.
Understanding how a serverless architecture operates entails understanding the different services involved in it. Here we discuss the connected services in an AWS serverless architecture.
Examples of interconnected services in an AWS serverless architecture
Amazon Simple Storage Service (Amazon S3) is an object storage service for a scalable amount of data that supports a variety of use cases, such as mobile applications, big data analytics, and internet-of-things (IoT) devices. Amazon S3 enables enterprises to manage objects, which are then stored in buckets via APIs.
One of the most popular serverless services today, AWS Lambda allows enterprises to run code without the hassle of server provisioning and maintenance. With it, developers can run code and pay only for the number of instances when the code is triggered. AWS Lambda enables them to focus on their tasks without having to manage hardware or ensuring that the operating system and all of the installed applications are up to date.
Amazon API Gateway enables the easy and efficient creation, publishing, maintenance, monitoring, and securing of APIs. It acts as a portal for applications, allowing them to access back-end service functionalities or data using RESTful APIs and WebSocket APIs.
AWS Identity and Access Management (AWS IAM) enables developers to manage security credentials and permissions to confirm the access to serverless services and resources.
Major CSPs like AWS encourage users to follow the least-privilege principle in granting permissions for particular tasks. They also provide ways for users to apply the default-deny approach, which ensures that each service cannot communicate or is not accessible to another unless the necessary permissions are granted. Manually assigning and checking privileges makes for better security, but this might prove difficult for users especially given a complex mix of connected services. Consequently, users might introduce or overlook misconfigurations and risks such as the following when securing serverless services.
Amazon S3 buckets that are left open or publicly accessible could provide an opening for malicious actors to look for sensitive data. Critical data or parts of code that should not be publicly visible could also be exposed when Amazon S3 buckets are used to host types of content that they’re not meant to host in the first place.
AWS Lambda functions could be exploited by malicious actors through injection techniques used on bad or vulnerable code. Meanwhile, sensitive data could be exposed if the code of an AWS Lambda function is designed to return variables and is accessible from outside services. Malicious actors could also take advantage of credentials saved inside AWS Lambda functions as variables to gain access to a user’s account. Furthermore, malicious actors could exploit bad code to save their malicious tools and scripts inside an AWS Lambda execution environment’s /tmp folder, in which files could be persistent enough to launch attacks or exfiltrate sensitive data.
When an Amazon API Gateway endpoint is left open and exposed, it could be abused to trigger a denial-of-service (DoS) attack in an attempt to compromise or shut down the service behind it. Malicious actors looking to inflict financial damage on an enterprise could also abuse an open Amazon API Gateway endpoint to query an AWS Lambda function nonstop, which would cause the enterprise’s bill to go up.
Possibly due to time constraints, developers sometimes opt to make policies overly permissive so as to ensure the communication between system components, which is facilitated by AWS IAM. But this loosening of permissions of course affects the security of the serverless services that AWS IAM is used with.
To further highlight the risks of implementing bad code on a serverless system, we created a proof of concept that involves an AWS Lambda function granted with high permissions. Through this video, we show how poor coding practices could allow malicious actors to successfully alter the AWS Lambda function timeout and subsequently perform other activities such as privilege escalation and data exfiltration.
Because serverless services have stateless functions, the data in these services remains cached and is not stored in memory. When moving data from serverless services to external locations, enterprises must be mindful of how the data is moved to avoid leakage. This is what happened when a database containing half a million sensitive legal and financial documents was exposed because of a misconfiguration that occurred when access policies were changed.
It is also important to know where data is stored to ensure that it doesn’t run into compliance issues, such as when over 36,000 inmate records from various correctional facilities in the US were leaked because a data repository associated with a cloud-based application was left open. The compromise of an enterprise’s application or service could very well result in business disruption and reputational damage.
Serverless services are not above risks and threats. In fact, our research provides a comprehensive discussion of the possible compromise and attack scenarios involving serverless services. But there are ways to keep serverless services and deployments secure.
Users must understand that the shared responsibility model, in which both the CSP and the user maintain zones of responsibility to keep the cloud environment secure, also applies to serverless computing. In our research paper, we provide ways in which serverless services and deployments can be protected against risks and threats through best practices and security solutions. We also also give recommendations on how to create secure serverless applications.
As more enterprises switch to serverless technology and as more applications are built on it, keeping serverless services and deployments secure becomes more critical. Our research paper “Securing Weak Points in Serverless Architectures: Risks and Recommendations” provides vital information and guidance that enterprises can use to keep their serverless environments safe against misconfigurations, errors, and unsecure coding practices — whether they’re already using serverless technology or are just planning to shift to it.
Like it? Add this infographic to your site:
1. Click on the box below. 2. Press Ctrl+A to select all. 3. Press Ctrl+C to copy. 4. Paste the code into your page (Ctrl+V).
Image will appear the same size as you see above.