Serverless applications hold the ability to build and run applications in the cloud without having to manage cloud server infrastructure and even containers. This is hailed as the gold standard of digital development, especially on web-based applications. Amazon Web Services (AWS) API Gateway and Lambda offer a best-in-class solution. We’ve helped many of the nation's highest profile digital systems transition to serverless. Infrastructure overheads are reduced, productivity and agility improved, and business value delivery accelerated. However, serverless applications can create unique challenges in highly regulated sectors such as health and financial services. We’ve learnt the need to apply extra security controls to protect projects, devising ways to harden serverless applications without hindering speed of delivery. In this article, we share three of these. Each one is an actionable defence measure that you can take, matched for ease and useability to each of the three industry-standard cyber security pillars - confidentiality, integrity and availability (CIA).
First, some detail on how the AWS serverless applications work and their appeal. Under the AWS shared responsibility model, traditional infrastructure operations tasks such as patching operating systems, provisioning virtual machines, and even the notorious complexity of container orchestration (such as Kubernetes) have fallen into their bucket as the cloud provider. Businesses only need to focus on selecting the relevant application runtime (Java, Python, NodeJS, just to name a few) and deploy the working source code from the designated pipeline. This approach significantly reduces the volume of work it takes to release working code. It also becomes a natural choice to build microservices. It’s easy to see why this serverless model has been greatly welcomed by business stakeholders, as well as the digital developer community.
Serverless applications can, however, lead to concerns during security reviews and audits, especially in highly regulated industries such as financial services and health. If not designed, built and operated properly, they can be more prone to cyber attacks.
We would like to share three ways to boost security and fully unleash the benefit of serverless applications. We have aligned them to the CIA triad:
1. Confidentiality: put your Lambda functions into a VPC with traffic controls.
Lambda functions can run in a virtual private cloud (VPC, effectively a customer-controlled private network space) or outside of a VPC (over the internet). Some practitioners see perimeter-based network control as a legacy approach which only applies to virtual machines or container workloads. We disagree with this view. Instead, when possible, Lambda functions should be deployed within a VPC. To protect data confidentiality, VPC has traffic control technologies based on source and destination. More importantly, all of the digital footprint - traces of network traffic - are retained for real-time threat detection and future analysis.
2. Integrity: sign your code deployed to Lambda to avoid malicious code injection
To reduce the risk of malicious code injection and software integrity failure (major threats are listed in the OWASP Top 10 list), AWS Signer can ensure the code that is deployed to the Lambda function run-time is the intended code and hasn't been tampered. The code signing process and its configuration can be part of the DevSecOps pipeline to create, test and release Lambda code.
3. Availability: ensure you configure the gateway to contain hot spots of traffic.
Although API Gateway and Lambda are AWS-managed services, the resilience of the digital service, especially under load, is the customer's responsibility. When combining API Gateway and Lambda, look out for the following:
- Make sure you manage service quotas at both the account and instance levels.
- Rate-limiting can be further applied to different endpoints at API Gateway - this is critical to avoiding the classical “noisy neighbour” issue: when one Lambda gets too busy with excessive volume of transactions, the throttle should be managed within the channel of that Lambda service and gateway endpoint. Other endpoints should be intact.
- A reminder to check the number of usable IP addresses in your VPC and subnet to ensure your Lambda function can spawn a sufficient number of instances and does not exhaust the IP addresses.
Culture and process changes matter too
It’s not enough to just turn on some tools. Consider the following:
- Embed your application security function to people in your delivery squad. This should be a cybersecurity analyst or engineer, or a developer trained in application security, threats and defence and is willing to drive better security postures.
- Continuously manage and monitor software supply chain risks especially with open source software.
- Cultivate healthy debates about architecture and involve subject matter experts from other areas such as network and operations early in the design and build process.
- Review incident response procedures so they match the attributes of serverless applications.
In summary, as with any innovation, we urge you to review your security posture with serverless applications. Plan early, engage continuously and consider applying the steps we’ve outlined above to get the full transformative effect.
If you would like to learn more about AWS serverless applications within your organisation, please contact Binqi Zhang or Tim Wang.
