AWS Security Automation - MFA Compliance (Audit, Report and Auto-Remediate) - Part 3

Hi folks!!!

Hope everyone's good and eager to proceed. This is the last part of MFA Compliance setup in AWS.  Feel free to visit the previous post to follow along. 

So, let's dive deep into the architecture flow where we left off. I have modified some aspects to provide a better picture for how the flow will work.

Architecture Flow:

1. CloudWatch Scheduled Rule calls the Lambda after a pre-defined period (say 2 minutes) to check for the MFA Compliance.

2. Lambda will inspect the IAM users for MFA compliance.

3, 4. Non MFA users will get caught by Lambda.

5. Lambda will update the CloudWatch Logs Log Group associated with all the happenings inside of Lambda function.

6, 7. SNS will publish the incident to Security Team

Here, we have managed to introduce an extra step of remediation which says that, 

"If a NON COMPLIANT IAM-User is found, disable the user console login at the earliest."

R1, R2. Remediate the suspicious user console login by disabling it with the help of Lambda.

Lambda Code: 

The code logic is already explained in the previous post. Additional will be the remediation which uses delete_login_profile(malicious_username) function from Python Boto3 SDK.

Deployment Strategy:

As mentioned in the previous post, we will not follow the traditional manual approach to setup everything in AWS account. Instead, we look forward to operate this as IaaC - Infrastructure As A Code. It will be easy to manage the following setup with AWS IaaC i.e. CloudFormation. 

Let's create a template to get all the Resources accommodated. As we are clear with the architecture, note what all resources are required,

1. Lambda Function - "SecOpsRemediationUWM"

2. Role attached to Lambda Function - "SecOpsRemediationUWMRole"

3. Cloudwatch Scheduled Rule - "SecOpsRemediationUWMScheduleTarget"

4. Cloudwatch Rule Premission for Lambda Invocation - "SecOpsUWMInvokeLambdaPermission"

Final Deployment:

1. Create an SNS topic and confirm the Pending subscription with a valid email address. Feel free to visit here for any reference. Remember to update SNS Topic ARN in Lambda code.

2. Zip the Lambda code with the same name as the python file mentioned in the CloudFormation Lambda Handler.

3. Create an S3 bucket as "secopsremediationlambdas" and upload the zipped Lambda folder.

4. After upload run the command to create a CloudFormation Stack from the template created. (Refer the last command in below image.)

Compliance Testing:

We have created 4 users to test the scenario.

When deployment in CloudFormation will complete, you will see logs appearing in CloudWatch Logs LogGroup associated with our Lambda function. Notice that only the malicious user got disabled by our script and the Exception user remain unaltered. Also, the compliance check will take place in every 2 minutes (can be altered in CloudFormation Template) while the notification will be sent to Security Team only when the compliance will fail.

After completing this, please delete the CloudFormation Stack so that it won't cost for any AWS resources.

Scope Of Improvement:

1. Use of "logging" module to get well defined logs out of Lambda execution.
2. Try to complete the SNS setup within CloudFormation Stack itself.
3. Use DynamoDB to manage exceptions, if present in large number or dynamic in nature.

Security Constraints:

1. Do not attach complete EC2-Access/Admin-Access to final Lambda function going for prod deployment. See limited permissions defined by SecOpsRemediationUWMRole.
2. Test well before deploying Lambda function.
3. Utilize CloudFormation Change Sets for any future changes to this architecture.

We have seen AWS CloudFormation helped us to deploy the architecture with a reusable template. In the upcoming posts, we will learn about AWS Config and Compliance as a Code using AWS Lambdas and other related services.