In some ways, serverless application architectures improve security. You no longer need to patch servers. The ephemeral, stateless nature of serverless compute makes attackers’ lives harder. 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.
In this blog, we’ll outline 9 serverless security best practices you need to adopt as part of this paradigm shift.
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:
As your app propagates, this can be challenging to maintain. Consider services which help you fortify your entire application supply chain.
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.
Keep using your WAF and API Gateway, but another serverless security best practice is to be prepared to apply perimeter security at the function level as well.
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 crafting suitable, minimal roles for each of your functions. Additionally, ensure that each of your functions executes with the smallest viable set of privileges, so the damage from any holes that slip through is minimal. Review this as often as you can. 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.
Consider emerging technologies that can help craft these policies for you, and alert you any time things change.
Functions often include dependencies, pulled in from npm (Node.js), PyPI (Python), Maven (Java) or other relevant repositories. Application dependencies 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. 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.
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.
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.
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.
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.
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.
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.