Auto Remediation of Non-Compliant Resources Using Config Rules & SSM Documents

What is this Blog About?

This blog is about meeting and maintaining your AWS resources according to AWS security compliance standards or custom standards created by the organization.

For example, consider whether an organization wants all its Elastic Load Balancers ( ELB ) to have Deletion Protection Enabled, or the organization wants its Users to comply with a particular IAM Password Policy.

In these scenarios, we can use config rules to know which resources are non-compliant and then remediate the non-compliant resources with the help of System Manager (SSM) Documents.

Similar to this, there are many compliance policies that you can set and remediate with the help of Config Rule Auto remediation.

For demonstration purposes, in this blog, we will remediate ELBs that have deletion protection disabled. The blog will be divided into the following steps:

1. Developing SSM Document for Enabling ELB Deletion Protection.
2. Creating Config Rule for Non-Compliant ELB which have deletion protection disabled.
3. Auto Remediating Non-Compliant ELB Resource.

Developing SSM Document:

1. So getting started with, open your AWS account console and search for System Manager and open the Documents dashboard.
2. Now, click on the Create Document button and select create Automation. Name the document based on the use case you are going to remediate. In our case, it is enabling deletion protection on ELB.
3. Next, add a Description to your document on what the document does, what are the parameters required for the document to work properly and what is the output/response of the document whether the document is successful in remediating the non-compliant resource.
4. Adding required Input Parameters: Providing input parameters that are necessary for the remediation to work, such as providing IAM Role, which permits the SSM Document to execute remediation on your behalf, providing ID/Arn/Name of the resource, providing other required resources such as s3 bucket for logging purposes, etc.
   In most cases, for remediation, we mandatorily need to provide IAM Role and Resource ID/Name (AutomationAssumeRole and LoadBalancerArn in our case). As you can see in the above picture, we have provided the required input parameters, wherein you can also specify the parameter type and whether it is required or not. If you select “required as “No,” you can also add the default value for that parameter.
   The IAM Role will have the following permissions:
   Particular Resource Permission for which you are performing remediation(in our case, elb).
   IAM Passrole for the account
5. Select the Target Resource from dropdown
6. Adding Step in document:
   Providing Name for the step, selecting Action type such executing a script or executing an API, adding Step Description.Adding Input (Script for remediation), Input Payload (Parameters that are needed for the step to execute) and Output (the output payload response returned from the script).
   In the following picture, we have used boto3 python script for enabling ELB Deletion Protection, and in Input Payload, we have passed the LoadBalancerArn as an event; in Output, we have returned the StringMap response from the script. You can also configure additional and common properties per your requirements; we have kept it default in our blog.
7. Now click Create Document, and you will have your Automation Document ready! After editing, you can always edit the document by creating its new version and setting it as the default version.

Creating Config Rule:

1. Creating config rules which will detect non-compliant resources. Open AWS console, search Config, select Rules, and then select Add Rule.
2. Now select Aws Managed Rules or Custom Lambda Rule if your use case does not exist in Aws managed rules. Our use case falls under Aws-managed rules as elb-deletion-protection-enabled.
3. Add Name and Description.
4. Add a Trigger on which basis the config rule must evaluate the non-compliant resources.
5. You can also add additional Parameters if the remediation requires it, such as a required tag or a s3 bucket. After reviewing, create the rule. Search for the same rule you have created and click on Actions, then Manage Remediation.
   Select remediation method:
   a. Auto-Remediation: If you want AWS Config to directly initiate remediation of the non-compliant resources on your behalf when they come in scope.
   b. Manual Remediation: If you want to remediate each non-compliant resource on your own through the console when they come in scope.
6. In Remediation Action, select the ssm document we created for remediation.
7. Select which input parameter in your document acts as a Resource Id and mention the values for other parameters if necessary. You can also provide a rate limit for the rule.
8. Save changes and move on to the next step, the remediation of resources.

Remediation of Non-Compliant Resources:

1. Click on the config rule that we created, and under Resources in scope, select non-compliant, and you have all resources that do not comply with the rule we have set. In our case, only one ELB resource does not comply with the rule.
2. Select the resource and click on Remediate. After you click on remediation, you can see the status has changed from null to Action Executed Successfully.
3. We can also confirm by going to the mentioned ELB dashboard and checking the details of the resource.
4. Also, after reloading resources in scope, the particular resource will move to compliant resources.
5. Well done! Now you know how to remediate non-compliant resources as per AWS or organization-specific defined standards.

Closing words

Hope this blog has made you understand how to create Config Rule and SSM Automation Document to remediate non-compliant resources in your AWS Account. For more info, you can check out AWS docs.

For further help regarding solutions around security standards for resources, you can always reach out to us.

Happy reading 🙂 

Written by – Mohammed Shahid Adoni