Least Privilege for AWS Lambda Security

By, Hillel Sollow, Serverless Security R&D

If you are a security professional or at least someone who cares enough about security you will appreciate the importance of restricting privilege access to resource as a means to maximize security. More so, if you are familiar with AWS serverless technology, you should also be familiar with the principle of least privilege for AWS Lambda security tools. The renowned computer science pioneer Jerome Saltzer stated it as:

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 idea is so fundamental to our security thinking that it is probably almost instinct to all of you. It is also one that is rarely achieved. There are several reasons for this.

1. The effort required to pare down permissions to the minimum necessary is significant.
2. As developers add features, policy enforcement just gets in their way, and using a relaxed set of permissions is the quickest way to get their code working.
3. Often the tools provided to you to set and enforce policy lack the granularity to allow you to properly limit permissions.
4. Finally, even when the will and the tools exist, often the complexity involved in getting the configuration right makes it virtually impossible.

AWS Lambda Security Tools

Serverless takes these difficulties to the next level, primarily because the number of resources that can act and be acted upon can grow by one or two orders of magnitude. Suddenly you need to consider the policies governing the interaction between hundreds of resources, with hundreds of possible permissions in each direction.

This issue compounds even more when permissions live in several places. For instance, the AWS Documentation for AWS Lambda states “Instead of using a Lambda function policy, you can create another IAM role that grants the event sources (for example, Amazon S3 or DynamoDB) permissions to invoke your Lambda function. However, you might find that resource policies are easier to set up and they make it easier for you to track which event sources have permissions to invoke your Lambda function.”

Universal Recipients

One more complicating factor, is that we are constantly encouraged to not reinvent the wheel. Reuse is king; there is no problem for which a solution cannot be imported or required. Applications like the Serverless Application Repository allows you to bring in someone else’s solution into your application with a few simple clicks – this is taking a huge security leap of faith.

While sharing is convenient, it also means you may be using code and configurations you have never even validated, in particular vulnerable third-party libraries. As an example, GitHub hosts over 5,500 projects designed for AWS Lambda and AWS Lambda security tools. Many of the deployment scripts in these libraries can create functions with a very wide set of privileges. As an example, these privileges could allow the functions to do anything in ElasticSearch, Rekognition, CloudWatch, and S3. This in turn means an attacker can find a way to exploit any of these functions, and then exfiltrate, encrypt, or destroy your entire data store.

AWS Lambda Security Tools – The Alternatives

The upside of serverless designs are that if you have been convinced to spend the time crafting minimal roles for each of your functions, these functions are often simple enough that this is not an impossible task. While reviewing the code and configuration of each function, it may be possible to enumerate all the possible actions taken by your code, and craft a suitable role for the function. Rinse and repeat of these principles apply.

Of course, that can be a painful, and error prone process. So your second ray of light is an emerging set of technologies that can help craft these policies for you, decreasing both your workload and you anxiety levels. Some tools, such as a nifty plugin for the Serverless.com framework, can try and figure out the permissions your function needs without your help. If you use the Chalice framework, it too tries to infer the permissions your function needs. Unfortunately, each is only useful if you already use their respective frameworks, and both are far too prone to false positives and negatives to really be used automatically.

Check Point’s CloudGuard serverless security solution takes a different approach, continuously analyzing your functions as they change and detecting and helping you remedy any policy promiscuity that makes its way into your environments. As the CloudGuard serverless security solution is not limited in scope to acting only during deployment, the solution has the unfair advantage of monitoring the function’s behavior as its being used, and fine-tuning its understanding of the function as time goes on. This means that the recommendations that solution provided can be significantly more accurate. It also has the advantage of being framework agnostic, so it can avoid the common contention between security decisions and software engineering decisions.

Bottom Line

Least Privilege management in AWS Lambda is not all roses, but it is not all thorns either. Serverless applications can present an almost endless set of opportunities to get permissions configured incorrectly, and there are a lot of forces pulling your application in that direction. But serverless applications are also built in a way that makes the secure configuration possible, especially if you leverage the right tools to keep you ahead of the game, and for that you need AWS lambda security tools that automate least privileged and the entire security cycle.

One last point: some serverless application frameworks, such as Chalice and Zappa have their own set of challenges when it comes to privilege. I will circle back to those in a future post.

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.