Actually Getting to Least Privilege in AWS Lambda

Least Privilege is kind of like the Holy Grail of security. Everyone wants it, but it remains elusive. Those that have mounted serious efforts to achieve it have had varying degrees of success

"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

Peter J. Denning, in his paper "Fault Tolerant Operating Systems", set it in a broader perspective among four fundamental principles of fault tolerance.

Dynamic assignments of privileges was earlier discussed by Roger Needham in 1972.^1,2


Okay so luminaries have written about it and that means it's probably a thing. But how to achieve it with AWS Lambda?

Let's start with facing the biggest challenges in general:

• The effort required to pare down permissions to the minimum necessary is significant.
• 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.
• Often the tools provided to you to set and enforce policy lack the granularity to allow you to properly limit permissions.
• Finally, even when the will and the tools exist, often the complexity involved in getting the configuration right makes it virtually impossible.

Going Serverless takes these difficulties to the next level. This is because the number of resources that can call and be acted upon grows by one or two orders of magnitude. Now you need to examine  the policies governing the interaction between hundreds of resources, with hundreds of possible permissions in each direction.

So this means that in addition to trying to limit which resources your Lambda function can access. You now also have to limit which resources can trigger your Lambda function!

Compounding this problem is not only the explosion of functions your organization can create from scratch, but the rapidly growing number of shared functions available from places like Github and AWS. Github has almost 12,000 projects for AWS Lambda alone as of the date of this post. And AWS recently went one step further, releasing the AWS Serverless Application Repository making it a matter of a few clicks to import code into your application that may or may not have been vetted for least privilege.

With an over-permissive IAM role assigned to a function, an attacker may leverage an application layer vulnerability in your function to perform lateral movement into other resources in your AWS account.

Consider this snippet from the setup from awslabs/serverless-photo-recognition/blob/master/setup/setupEnvironment.sh

aws iam create-role --role-name ${ROLE_NAME} --assume-role-policy-document file://s3-to-es-role-trust-relationship.json --region ${REGION}
aws iam attach-role-policy --role-name ${ROLE_NAME} --policy-arn arn:aws:iam::aws:policy/AmazonESFullAccess --region ${REGION}
aws iam attach-role-policy --role-name ${ROLE_NAME} --policy-arn arn:aws:iam::aws:policy/AmazonRekognitionFullAccess --region ${REGION}
aws iam attach-role-policy --role-name ${ROLE_NAME} --policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess --region ${REGION}
aws iam attach-role-policy --role-name ${ROLE_NAME} --policy-arn arn:aws:iam::aws:policy/CloudWatchLogsFullAccess --region ${REGION}

These functions can do anything in ElasticSearch, Rekognition, CloudWatch, and S3. That means an attacker that finds a way to exploit any of these functions, can exfiltrate, encrypt, or destroy your entire data store.

As a security professional, of course this is a risk that should not be tolerated. As a developer, is satisfying the pressures you are under really worth taking this risk? At the very least, you meed to understand the risks of your decision and also be sure that your Product and Business Managers know that this risk exists so that they can decide if the benefits of releasing now is worth the risk and if remediating the risk is ever worth the expense.

The upside in all this is that most AWS Lambda functions are simple and compact enough that an analysis should allow at least a tightening of permissions if not outright least privilege. Also, there are tools emerging to help with this process. The most widely-adopted toolkit for building serverless applications from serverless.com has least privileged scanning tool that attempts to generate least privileged policies from existing functions. The Chalice framework has a similar tool. But these tools only work if you have been using these frameworks.

Protego Serverless Security Platform 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 we’re not limited in scope to acting only during deployment, we have the unfair advantage of monitoring the function’s behavior as it’s being used, and fine tuning our understanding of the function as time goes on. It also has the advantage of being platform agnostic.

No matter how you do it, manual code reviews and policy tuning or using an automated tool, you need to seriously consider the risks you expose your organization to when you don't implement least privilege.

¹ Roger Needham, Protection systems and protection implementations, "Proc. 1972 Fall Joint Computer Conference, AFIPS Conf. Proc., vol. 41, pt. 1, pp. 571-578"
² Fred B. Schneider. "Least Privilege and More" (PDF).