Moving to serverless, including AWS Lambda, makes security both easier and harder, as I outlined in our Serverless Security Scorecard. In deploying serverless apps, you cede control over most of the stack to your cloud provider, for better and for worse. You no longer own OS hardening, admin rights, SSH, and segmentation. The exception where you retain control is configuration and the application, and that is where security must be applied. Least privilege, in particular, is a key component to AWS Lambda security best practices.
So, What Can You Do for AWS Lambda Security?
You must ensure security is tightly wrapped around your application and applied correctly, specifically to each resource, function, S3 bucket, etc. Those IAM roles are critical in ensuring your app is as secure as possible.
“Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job.”
— Jerome Saltzer, Communications of the ACM
This definition presupposes there’s something that enforces a differentiation of privilege within each part of the application in a way that limits what they can do. Assuming that infrastructure exists, least privilege dictates that we apply the smallest possible privilege so that it can function correctly, but can do nothing else.
While least privilege is critical, it is rarely achieved, making it the unicorn of security configuration.
Let us look at the following function as an example.
A ‘quick-and-dirty’ development implementation might look something like this:
This allows all actions on S3 to all buckets on S3. That gets the job done. The code will run, and not fail or give errors because of lack of permission. However, a slightly better, more secure version might be:
But a least privilege version of this would allow only GetObject, and only for this particular bucket.
In the last case, an injection attack into this area of the code could only read files from this particular bucket. The function cannot read files from any other bucket, and cannot write to or delete the bucket. Minimizing the scope of the attack through the right least privilege settings, minimized the impact of an attack.
Why Least Privilege is Hard
Perhaps most critically, security is, in a way, the opposite of development. This is because security is the process of applying checks and restrictions, whereas development is the process of creating flexibility, ease of use and enabling cool end user capabilities – no one likes a limited app. A developer’s instinct is to enable and remove obstacles, and it can therefore be challenging to ask them to apply security restrictions at the same time. However, part of AWS Lambda security best practices includes having developers consider what they do not need, and what they can therefore carve away.
Here are some additional reasons least privilege is always hard:
- Security takes time to analyze and implement, and developers don’t have time
- Security gets in the way, and when application development comes first, the the easiest thing to do is wildcard it for now.
- Lack of visibility, to even know what permissions you need slow development down.
- Lack of granularity of access controls limits developers to being able to meet security requirements while still making it practical for them to develop their applications.
- Lack of awareness or mindfulness to the problem
While it is always hard, least privilege is even harder in serverless. Have a look at one of my previous posts, “Least Privilege for AWS Lambda Security”, for further details. The key issues here are:
- You have many (many) more resources
- Your developers are updating them more frequently
The Upside
While serverless requires a complete shift in your security approach, it also brings to the table a large number of opportunities for creating better, more granular and in-context security. Let us compare serverless to containers. If a large container executes many functions, then you must enable it to do many things.
Moving to smaller microservices enables you to do more fine-grained IAM around them all. More importantly, it means, that if there is a vulnerability in one of your functions, an attacker will only get access to the limited capabilities of that function, not the large set of permissions each container had.
You have the opportunity to apply security policies to each of those small things, but the challenge, as we previously mentioned is that there is a lot of small things to apply security to AWS Lambda, along with most of the cloud providers, enables you to significantly shrink the attack surface. The opportunity for least privilege to be meaningful and mitigate a tremendous number of attacks is much more powerful with AWS Lambda than in a monolithic app.
Training Developers in AWS Lambda Security Best Practices
While security may be difficult for developers, I do not advocate that we take the whole thing out of their hands so that someone else owns it. Automatic tools, such as our own Check Point CloudGuards serverless solution, play an important role. But at the end of the day, it remains important to train developers to think about security. I recommend the following best practices:
- Look for low-hanging fruit for implementation security best practices.
- Embrace secure coding principles and try to do adopt these principles as you develop
- Easier in tandem with the development process
- Run tools
- All the training in the world won’t will close the gap as much as running a few tools, so definitely do both
- Focus on permissions from the bottom up
- Start from the assumption that the function needs nothing
Lastly, if you would like to see a demo of our automated security solution, request a 1-1 demo.
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.