AWS Config Overview
When it comes to AWS services, in my mind, I generally divide them into two classes. You have the operative services such as Lambda, S3, and the rest of the TLAs starting and ending with the letter “S”, and then the second class of services are helper/utility services such as CloudWatch and CloudTrail.
AWS config belongs to the latter and is among the most useful AWS services that can dramatically improve your ability to govern your serverless applications. Governance and visibility are among the most critical component in any effective security strategy.
With AWS Config, you can automatically record and track changes to the configuration of your AWS Lambda based applications as well as many other AWS services. Whether you need to comply with certain industry regulations, or abide by custom corporate policies, Config rules are the right tool for you. Simply put, AWS Config rules enable you to implement security policies as code.
AWS Config Benefits for AWS Lambda Security:
- Continuous monitoring: monitor and record configuration or code changes of your AWS Lambda functions
- Continuous assessment: audit and assess the overall compliance of your AWS Lambda functions’ configurations with your organization’s policies and guidelines
- Change management: track relationships between functions and resources
Since each organization has its own set of security policies and regulations, AWS offers you the ability to create custom rules, associated with an AWS Lambda function. The Lambda function will contain the logic that evaluates whether your AWS resources (e.g. Lambda function) comply with the rule. Custom rules can be invoked either in response to configuration changes or periodically (e.g. once every 24hrs), allowing them to review resources that were previously deployed to the account.
Bonus: 4 AWS Lambda Security Rules
In this blog post, we will show you how to create 4 simple Config rules, that will boost your AWS Lambda security posture. As a bonus to our readers, we already implemented the rules and uploaded them as a project to Github, including a SAM application so that you will be able to deploy them quickly.
Project Github: https://github.com/puresec/lambda-config-rules
In the spirit of following security best-practices, we also added FunctionShield into the Lambda functions, so that they will be hardened. Make sure to register for a token in order to make it effective.
The steps for the installation are described below (and also in the Github project):
Install the dependencies:
npm install --prefix src/
Create a deployment bucket:
aws s3 mb s3://DEPLOYMENT_BUCKET_NAME
Package your application:
aws cloudformation package
Deploy the Config rules:
aws cloudformation deploy
`# optionally add FunctionShield token to enable protection (http://bit.ly/2AaBJ3x)`
Rule 1 – Detect AWS Lambda functions that are created directly through the AWS web console:
Using the AWS Lambda web console saves time when you need to experiment. We’ve all done that and still do it when we need to test or prototype something quickly. Having said that, that’s not the proper way deploy serverless applications. Before you know it, you end up with numerous functions deployed, with no ability to restore older versions and to understand why code changed. If your organization follows CI/CD best practices, deploying new functions shouldn’t be done through the web console, and this rule will keep track of this.
Rule 2 – Detect multiple AWS Lambda functions that are using the same single IAM role:
You should always try to ensure that your Lambda functions don’t share the same AWS IAM execution role in order to comply with the principle of least privilege by providing each individual function the minimal amount of access required to perform its tasks. In general, this means that there should always be a 1-to-1 relationship between your AWS Lambda functions and their IAM roles.
Rule 3 – Detect AWS Lambda functions with multiple different event triggers configured:
When prototyping or experimenting with Lambda functions, you will sometimes enable invocation through multiple cloud-native event trigger types. However, if your function will eventually get triggered by a single event type, you should remove the inessential triggers, as they increase your attack surface.
If your design deliberately allows a function to get invoked by multiple triggers, you should re-consider this design, as it violates the ‘single responsibility principle‘.
Rule 4 – Detect AWS Lambda functions with wildcard (*) IAM permissions:
When you create IAM policies (on AWS, and in general), you should always follow the standard security concept of granting the least required privileges – i.e. granting only the permissions required to perform a task successfully. In the case of AWS Lambda functions, the role you assign to a function will dictate the permissions the function will have while it executes. Under certain conditions, this permissions model, might be the thing that will save your sensitive data. With an over-permissive IAM role assigned to a function, an attacker my leverage an application layer vulnerability in your function to perform lateral movement into other resources in your AWS account. You can read more about this topic in the following blog post.
Two important things to keep in mind with regards to IAM policies:
- While it is sometimes impossible to avoid using a wildcard on a resource, that’s never the case for the action part of the IAM policy – you should always be able to specify the exact (least-privileged) actions on resources your function interacts with.
- Another important reason for avoiding wildcards (*) on an action, is future-proofing your IAM policy – just imagine what would happen if AWS will add a new action for that resource in the future. A wildcard means that you automatically allow all future actions, which can have unexpected implications on your security posture.
AWS Lambda Security: Sample Compliance Report
Once we have the rules deployed in our account, we will start receiving our compliance reports. Let’s have a look at the AWS Config dashboard:
The rules are deployed, working and already brought their first catch of the day! Drilling into the functions that failed the ‘wildcard’ IAM check, we can see a lot of useful data, including the insecure IAM permissions:
We also notice that there’s a function with multiple event triggers configured. Let’s see the details:
Seems like someone forgot to remove the ‘s3’ event trigger, which we never use.
We can also see a few Lambda functions that were created and deployed directly in the AWS Lambda console:
And last but not least, we’re also warned about multiple functions that share the same IAM role:
The project was designed and developed by Yuri Shapira, Principal researcher from the PureSec threat research team.
*** This is a Security Bloggers Network syndicated blog from PureSec Blog (Launch) authored by Ory Segal, PureSec CTO. Read the original post at: https://www.puresec.io/blog/aws-security-best-practices-config-rules-lambda-security