👮AWS Security Automation: Remediate Weak S3 Bucket Policies

Amazon S3 has become the quintessential object storage mechanism for lot of businessess. But weak S3 policies have been the been of many many business.

Ever wondered how to solve this problem and do this efficiently at cloud scale?

• What if you can automatically validate any changes to S3 Bucket policies?

• What if, You can automatically approve the change if it is compliant to security standards?

• What if, You can revoke the change change and notify SecOps if it is non compliant?

  That is exactly what we are going to do right now using, AWS CloudTrail, AWS EventBridge, AWS StepFunctions and AWS Config.

  

  Follow this article in Youtube

  For every PutBucketPolicy event, we will check if the Principal is * and Effect is Allow. If it is the case, we remove this policy statement and restore the previous bucket policy from AWS Config.

1. Prerequisites

   This demo, instructions, scripts and cloudformation template is designed to be run in us-east-1. With few modifications you can try it out in other regions as well(Not covered here).

   • AWS CLI pre-configured - Get help here
   • AWS Config must be enabled and recording
   • Optional AWS CDK Installed & Configured - Get help here

2. Environment Setup

   In this repo, I have included a cloudformation template that provisions the resources to setup a fully automatic policy remedation engine.

   • S3 Bucket: We will use this bucket to modify its policy
   • Cloudtrail(regional): Monitor all S3 Put API Events
   • StepFunction:
     • Evaluate new bucket policy compliance
     • If NON COMPLIANT retrieve previous bucket policy from AWS Config
     • Restore previous bucket policy
   • EventBridge Rule: Receives PutBucketPolicy events & triggers stepfuction
   • IAM Roles: For lambda and step functions with restrictive permissions

   Note: Sample bucket policies to test the solution can be found in the output section of the cloudformation template

3. Deployment

   You have couple of options to set this up in your account, You can use AWS CDK or use the cloudformation template generated by CDK. All the necessary steps are baked into the templates, you can launch it and try it out.

4. Method 1: Using AWS CDK

   If you have AWS CDK installed you can close this repository and deploy the stack with,

   # If you DONT have cdk installed
   npm install -g aws-cdk
   
   git clone https://github.com/miztiik/security-automation-remediate-weak-s3-policy.git
   cd security-automation-remediate-weak-s3-policy
   source .env/bin/activate
   pip install -r requirements.txt

   The very first time you deploy an AWS CDK app into an environment (account/region), you’ll need to install a bootstrap stack, Otherwise just go aheadand deploy using cdk deploy

   cdk bootstrap
   cdk deploy

5. Method 2: Using AWS CloudFormation

   Look for the cloudformation template here: cdk.out directory, From the CLI,

   aws cloudformation deploy \
       --template-file ./cdk.out/security-automation-remediate-weak-s3-policy.template.json \
       --stack-name "MiztiikAutomationStack" \
       --capabilities CAPABILITY_IAM

6. Testing the solution

   In the Outputs section of the cloudformation template we have,

   • S3 bucket link for updating policy,
   • SampleWeakS3Policy
   • sampleRestrictiveS3Policy

   This is what, we are going to do now,

   1. Check & Confirm that AWS Config had begun tracking our bucket. You can check that in the console, and verify the bucket policy. There is usually a delay of 3~4 minutes for changes to appear on the console.

      • Wait until it shows up, before proceeding to next step

   2. Add the sampleRestrictiveS3Policy to the S3 Bucket - Check the state function execution results - It should evaluate successfully and permits the use of this policy

   3. Now add the SampleWeakS3Policy - Wait for the state function to complete its evaluation, We should see the policy being NON COMPLIANT and reverts back to the sampleRestrictiveS3Policy

      

   4. If you want to repeat the test again, Wait until the new policy shows up in AWS Config.

   NOTE: Be careful not to set off an infinite step function loop. Every lambda remediation with previous policy will trigger PutBucketPolicy event, If the previous happens to be NON COMPLIANT this automation has built-in safe guards, It will trigger remediation failure

   

   If you happen to set off infinite loop, one easy way to break the loop is to DISABLE the event rule or stop the state machine Execution, until you fix your non compliances.

   Now that we have confirmed the solution is working, you can extend the solution as required.

7. Next Steps: Do Try This

   • Trigger notification to InfoSec team for every weak policy remediation failure
   • Quarantine User/Role triggering multiple failures
   • Monitor against infinite loops

8. Additional Comments

   As AWS Config is not real time, this automation should not be the primary means of defence against weak policies. You should consider,

   • Who has permissions to change bucket permissions?
   • Are those permissions restricted only the resources they own? - Refer Attribute Based Access Control - ABAC
   • Are you auditing those privileges automatically?
   • If all else fails, do you have mechanisms that will automatically respond to events?

9. CleanUp

   If you want to destroy all the resources created by the stack, Execute the below command to delete the stack, or you can delete the stack from console as well

   1. Delete CloudTrail S3 Buckets - as required,
      • The bucket names begin with: security-automation-remed*
   2. Delete CloudWatch Lambda LogGroups
   3. Disable AWS Config - as required
   4. Delete the stack[s],

   # Delete the CF Stack
   aws cloudformation delete-stack \
       --stack-name "MiztiikAutomationStack" \
       --region "${AWS_REGION}"

   This is not an exhaustive list, please carry out other necessary steps as maybe applicable to your needs.

Buy me a coffee

Buy me a coffee ☕ through Paypal, or You can reach out to get more details through here.

References

1. Controlling Access to S3 Resources
2. Bucket Policy Examples
3. Configure a CloudWatch events rule for GuardDuty

Metadata

Level: 400