By, Hillel Sollow, Serverless Security R&D

If you are an advocate of serverless, then it should come as no surprise that serverless application architectures actually improve security. You no longer need to patch servers. The ephemeral, stateless nature of serverless compute makes attackers’ lives harder to orchestrate attacks. And the fact that your application is now structured as a large number of small functions in the cloud enables you to see each unit of compute as a separate entity. However, threats to your apps will persist. They just won’t look and act the same way. Serverless apps are comprised of hundreds of functions, which means your attack surface has changed. Maintaining control and security requires a paradigm shift in your thinking. In this blog, we present 9 serverless security best practices.

Your Apps Just Went Serverless. Your Traditional Security Best Practices no longer apply. Now What?!

In this blog, we’ll outline 9 serverless security best practices you need to adopt as part of this paradigm shift.

1. Map Your App

With serverless apps being comprised of hundreds of functions, you must have a complete picture in order to understand your potential risk. Code reveals your business processes, which could be sensitive. Consider:

  • What data is involved in your app and how sensitive this is?
  • What is the value of that data i.e. what’s the impact if this data is exflitrated in a breach
  • What are the services (APIs) that access the data?

As your app propagates, this can be challenging to maintain. Consider services which help you fortify your entire application supply chain.

2. Apply Perimeter Security at The Function Level

The fragmentation of your application to smaller components that are callable, coupled with the use of triggers from diverse sources (such as storage, message queues, and databases) means attackers have more targets and more attack vectors.

Using your WAF and API Gateway maybe acceptable at a broad security control, but implementing security controls at the perimeter of the function or workload is a better best practice.

3. Create Suitable, Minimal Roles for Each Function

Serverless can substantially increase the number of resources that can act and be acted upon. You must consider the policies governing the interaction between hundreds of resources, with hundreds of possible permissions in each direction.

Spend time creating suitable, minimal access roles for each of your functions. Additionally, ensure that each of your functions executes with the smallest viable set of privileges – start narrow with your privileges and only widen privileges as needed to minimize the impact. Implement continuous assessment of these privileges on a frequent basis, and implement auto remediation to correct any privileges that drift outside of policy – In serverless, things that were once well configured can suddenly be sub-optimal, as others might have changed a role, policy, or function that makes some other part of your application vulnerable.

4. Secure Application Dependencies

Functions often include dependencies, pulled in from npm (Node.js), PyPI (Python), Maven (Java) or other relevant repositories. Application dependencies, especially open source, are prevalent and frequently vulnerable with new vulnerabilities disclosed regularly. The nature of serverless makes managing third party dependencies manually particularly challenging.

Securing application dependencies requires access to a good database and automated tools to continuously prevent new vulnerable packages from being used and getting alerted for newly disclosed issues. Source Composition Analysis (SCA) tools help to identify open source vulnerabilities, early in the development lifecycle. Additionally, minimize the impact of vulnerable libraries by ensuring proper segmentation of the app into disparate services, and scrupulously applying the principle of least privilege.

5. Stay Vigilant Against Bad Code

Serverless deployments, with their diverse triggers and infinite scaling can even mean that the smallest of code errors can quickly turn into a self-inflicted denial-of-service attack from within your application.

With a more exposed attack surface, bugs can more easily turn into security liabilities

Be sure developers are regularly, and adequately trained. Code reviews will help as well. Mostly, though, monitor your code and configuration using tools to test configuration.

6. Add Tests for Service Configuration to CI/CD & PROD

Serverless deployments invite increased product velocity, increasing the speed at which your applications create value, but also providing lots of opportunities to break security. Test and verify that what you thought you just did in configuration continues to be true. You must continue to test that what you’ve set up is what’s actually running in production.

7. Observe the Flow of Information

The impact of data flow is unique to serverless, due to the significantly larger number of components in your application. You must monitor the flow of information to make sure it’s only going between the services that you want, and the right info is ending up in the right place.

8. Continue to Mitigate for Denial-of-Service or Denial-of-Wallet

While serverless apps call easily, scaling is still not infinite. You are still susceptible to Denial-of-Service attacks if an attacker can saturate your limits. if you have set your concurrency limits high enough to avoid this issue, you now face the more modern fear of Denial-of-Wallet attacks, in which an attacker overwhelms your app to rack up your expenses. Enabling massive auto-scaling of your service when using serverless, can help mitigate some DoS attacks, but opens you up to DoW attacks.

Deploy proper mitigations for DoS attacks, such as Amazon’s API Gateway, in front of web endpoints. Also consider DoS and DoW via other triggers, such as Kinesis, and S3. Function self-protection can help detect these attacks, minimize their impacts, and dynamically adjust scaling choices to help mitigate.

9. Make FaaS Containers Refresh

Consider strategies to limit the lifetime of function instances (for example, on some platforms there are APIs to make an instance refresh). Some security solutions can do this for you. Furthermore, make sure you have a security solution that can detect things that try to hang around in your function instances, like extra code, hidden native process, etc., and then flush those things out of the container.

Concluding Serverless Security Best Practices

Like any facet of cybersecurity, securing your serverless application requires a variety of tactics throughout your entire application development lifecycle and supply chain. Stringent adherence to best practices will improve your security posture. However, proper development is not enough. To achieve ideal protection, you must leverage serverless security tools that provide continuous security assurance, attack prevention and detection, and deception.

Securing your serverless applications required a dedicated solution that will help developers do the right thing during build and integrate into your CI/CD pipeline, but also provide complete protection during runtime in live environments, continuously scanning your application’s code for potential risks that can be remediated on spot.

For more information about serverless security, please visit the Check Point What is Serverless Security page. You can also read our latest ebook, Top Serverless Security Risks and Mitigation Strategies.

You may also like