AWS Cloud Operations Blog

Enhance Evidence Collection with AWS Config and Audit Manager

AWS Audit Manager is a fully-managed service that provides prebuilt frameworks for common industry standards and regulations, and that automates the continual collection of evidence to help you prepare for an audit. The continuous and automated gathering of evidence related to your AWS resource usage helps simplify risk assessment and compliance with regulations and industry standards. Moreover, this helps you maintain a continuous, audit-ready posture to provide a faster and less disruptive preparation process.

AWS Config enables customers to evaluate the configuration settings of AWS resources. This is done by AWS Config rules, which evaluate the current state against the desired state. Customers can use AWS-managed rules or custom rules. Although AWS Config continuously tracks the configuration changes that occur among your resources, it checks whether these changes violate any of the conditions in your rules. If a resource violates a rule, then AWS Config flags the resource and the rule as noncompliant.

You can use Audit Manager to capture AWS Config evaluations as evidence for audits. When you create or edit a custom control, you can specify one or more AWS Config rules as a data source for evidence collection. AWS Config performs compliance checks based on these rules, and Audit Manager reports the results as compliance-check evidence.

Gathering configuration evidence for an audit can be a challenging process if done manually, as it’s error prone and slow. With the recent release of Audit Manager’s support for AWS Config custom rules, customers can now point to evidence using AWS Config custom rules, thereby automating an otherwise manual process, making it continuous, less error prone, and more efficient.

In this post, we introduce a solution that leverages AWS Lambda backed AWS Config custom rules to extend AWS Config and collect configuration evidence.

How does it work?

AWS Config custom rules are core to this solution. When you add a rule to your account, you can specify when you want AWS Config to run the rule. This is called a trigger. AWS Config evaluates your resource configurations against the rule when the trigger occurs. There are two types of triggers: configuration changes, and periodic. Configuration changes rules trigger when certain types of resources are created, changed, or deleted. You choose which resources trigger the evaluation by defining the rule’s scope, which can be the resource ID, resource type, resource tag, or any recorded resource activity. On the other hand, periodic rules are triggered at a frequency that you choose (for example, every 24 hours). When an AWS Config custom rule runs, it has the required configuration evidence, as it must evaluate the configuration against the desired state. Knowing that, we added some code (which can be used in other AWS Config custom rules) to collect the evidence and store them in an Amazon Simple Storage Service (Amazon S3) bucket. Then, the Amazon S3 location is posted as an annotation of the rule evaluation. To make sure that the evidence isn’t modified, it’s possible to use S3 Object Lock.

To include AWS Config custom rules in your Audit Manager assessment, you must create a custom control set and a custom framework. Then, you can create an assessment selecting those.

In this post, we use an existing AWS Config rule from AWS Config Rules Repository called AMI_NOT_PUBLIC_CHECK, and extended it to push the evidence to a designated S3 bucket. To enable this solution to work at scale, the S3 bucket name is stored in Parameter Store, a capability of AWS Systems Manager and Lambda functions can retrieve the parameter when they’re invoked. Then, we used the annotation field when sending the evaluation to AWS Config to point to the exact location in Amazon S3 where the evidence can be found. With that, when looking at the AWS Config rule in the console, you can see the annotation there. The Amazon S3 folder structure differs between CI-based rules and periodic rules. For periodic rules, the structure is RULE_NAME/ACCOUNT/DATE/TIME/EVIDENCE_FILE. For CI-based rules, the structure is RULE_NAME/ACCOUNT/RESOURCE_ID/DATE/TIME/EVIDENCE_FILE. This structure supports multi-account deployments.

Note that this post demonstrates how to deploy enhanced evidence collection for Audit Manager using a AWS Config custom rule in a single AWS account. This can be customized to support a multi-account deployment using Organizational Config rules by changing the ASSUME_ROLE_MODE parameter in the Lambda function to TRUE. In this mode, the Lambda function will assume the role in the target account. You must make sure that the Lambda can assume the role.

Prerequisites

The following prerequisites are required before continuing:

  • An S3 bucket to which the AWS Config custom rule can write evidence.
  •  AWS Config must be enabled and have an AWS Config Recorder (Setup AWS Config).
  • Permissions to deploy the provided AWS CloudFormation template.
  • Permissions to access Audit Manager.
  • An AMI (public or private) in the account (see how to create an AMI).

Deployment steps

  1. Copy the CloudFormation template from GitHub locally (or clone the repository).
  2. Log in to your AWS account and go to CloudFormation. Choose “Create stack” followed by “With new resources (standard)”. In the “Specify template” section, choose “Upload a template file” and upload the template you saved in Step 1. Choose “Next”.
  3. Enter the requested information and choose “Next”.
Figure 1. Enter CloudFormation stack details

Figure 1. Enter CloudFormation stack details

  1. Choose “Next”, then check the Capabilities checkbox, and choose “Create stack“. Wait until the stack is in the ”CREATE_COMPLETE“ state.
Figure 2. Create stack

Figure 2. Create stack

  1. To create a custom control in Audit Manager that will use your new AWS Config Custom rule as a data source, follow these instructions and notice the following steps to properly attach your AWS Config custom rule as a data source.
Figure 3. Add custom AWS Config Rule based data source in AWS Audit Manager

Figure 3. Add custom AWS Config Rule based data source in AWS Audit Manager

  1. Now that a custom control is defined that is leveraging the AWS Config custom rule that you built, it’s time to create a framework to use the custom control. Note that you could modify any existing framework and add the custom control. However, for the purpose of this post, we’ll create a custom framework and add the control that you previously created.
  2. Navigate to Audit Manager.
  3. Choose ‘Framework Library’.
Figure 4 - Click on framework library

Figure 4. Click on framework library

  1. Choose ‘Custom frameworks’, followed by ‘Create custom framework’
Figure 5. Create custom framework

Figure 5. Create custom framework

  1. The ‘Framework name’ field is the only required field. However, you may complete the fields that are suitable for your use. You may also tag the framework with the key/value pairs in any way you wish (tagging can help with automation and analysis in the future).
  2. Choose ‘Next’.
  3. Here you must define a ‘control set’ name. Choose ‘Custom controls’ from the ‘Select control type’ dropdown. Under ‘Available custom controls, check the box next to the custom control that you defined in the previous step, and choose ‘Add to control set’.
Figure 6. Define custom control set details

Figure 6. Define custom control set details

  1. Confirm the choices, then choose ‘Next’.
  2. Review your choices and choose ‘Create custom framework’.
  3. Follow the instructions to Create an assessment and use your custom framework in Step 1, your account in Step 2 and AWS Config as the service in Step 3. In Step 4, gyou will assign access to the assessment to users/roles.
  4. Go to the AWS Config dashboard, and choose “Rules” in the left navigation pane. Choose the rule created by the stack. Choose “Actions”, then “Re-evaluate”. The last successful evaluation should change within a few minutes and reflect the latest evaluation.
Figure 7. Re-evaluate the custom rule

Figure 7. Re-evaluate the custom rule

  1. Set “Resources in scope” to display compliant and non-compliant resources. When your resource shows up, it will have an annotation which leads to the evidence report stored in Amazon S3. Choose the link and view the report. Generate an assessment report and download it.
  2. Unzip the report zip file, go to the unzipped folder, and open the AssessmentReportSummary PDF file. Scroll down to the” Assessment report selection” section and choose the collected evidence. This will open another PDF file (which can also be found separately in the folder structure in the same folder).
  3. Scroll down to the “annotation” field where you should find the link to the evidence in the designated S3 bucket. Open the link in a browser, and download the evidence file. Open it and you will find the collected configuration evidence.

Cleanup

To avoid incurring charges, delete the resource you created as part of this post:

  1. Navigate to Audit Manager’s assessments page. Select the assessment you created, then select delete.
  2. Navigate to Audit Manager’s assessment reports page. Select the report you created, then select delete.
  3. Navigate to Audit Manager’s Framework library page. Under Custom frameworks tab, select the custom framework you created. Select action, then select delete.
  4. Navigate to Audit Manager’s Control library. Under Custom controls tab, select the custom control you created, then select delete.
  5. Delete the CloudFormation stack you created.

Conclusion

In conclusion, this post demonstrated how to create an AWS Config custom rule which gathers configuration evidence automatically, stores them in Amazon S3, and provides the link to the evidence with the Audit Manager assessment report. Using this solution, customers can reduce the manual effort of importing evidence to their Audit Manager Assessments. The automation in this solution also helps in reducing errors during evidence collection and expediting the evidence collection process.

About the authors:

Avi Harari

Avi is a Technical Account Manager at AWS supporting Enterprise customers with the adoption and use of AWS services. He is part of the AWS Cloud Operations technical community, focusing on Configuration, Compliance and Auditing on AWS. Outside of work, he enjoys spending time with his family and mixology.

John Fischer

John Fischer is a Senior Assurance Consultant for the AWS Security Assurance Services team and is a product specialist for AWS Audit Manager. In his spare time, John enjoys performing in his wedding band and spending time with his wife and kids.