Is your AWS account shared across departments in your organization? Do you monitor the permissions of your users? If you have multiple accounts, used by different business entitites, keeping track of IAM privileges can become a challenge as the number of users grows. For example, Can you answer these questions definitively?

• Do you who can create new user in your AWS Account[s]?
• Do you monitor create new user IAM events?
• Do you monitor modify user/group IAM events?
• Do you have mechanisms to revoke privileges in case of a security incident?

That is exactly what we are going to do right now using, AWS IAM, AWS CloudWatch, AWS StepFunctions & SNS

Follow this article in Youtube

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
   • Optional AWS CDK Installed & Configured - Get help here

2. Solution Overview

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

   • DENY-IAM-Policy: A customer managed policy that denies iam permissions.
     • Deny policy takes precedance over other policies^Ref#1
   • Lambda:
     • EXTREME REMEDIATION ACTION: Quarantines the IAM user with DENY-IAM policy
       • As this is a demo, This automation will revoke IAM privileges for the user with the deny iam policy. You can modify this lambda to suit your needs
       • Will quarantine user ONLY when user is NOT part of admins group
   • EventBridge Rule: Triggers the Lambda function
     • The event will trigger ONLY when the IAM event is triggered by an IAM User
   • CloudTrail: To monitor all IAM API Events
   • IAM Roles: For lambda and step functions with restrictive permissions

   Note: Sample commands to trigger ssh failures 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.

1. 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-unintended-iam-access.git
   cd security-automation-remediate-unintended-iam-access
   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 ahead and deploy using cdk deploy

   cdk bootstrap
   cdk deploy

2. 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-unintended-iam-access.template.json \
       --stack-name "MiztiikAutomationStack" \
       --capabilities CAPABILITY_IAM

3. Testing the solution

   1. Create IAM Admin Group(for example admins), if you do not have one.
   2. Goto Lambda Console>Update the Environment variable ADMIN_GROUP_NAME to your admin group name
      • The default is set to admins. Warning You will deny iam privileges to any user triggering this automation who is not part of this group.
   3. Create IAM User(for example baduser), with IAM Access but NOT part of admins group.
   4. Try to create a new user or modify an user(sample commands in cloudformation outputs)
   5. Wait for minute and check if the user(baduser) has a new DENY-IAM policy attached.
      • You can also check the lambda execution logs for more details

   Now that we have confirmed the solution is working, you can extend the solution as required. From now on, whenever a user who was given unintended access to IAM APIs makes an API call against IAM, this automation will detect those events and revoke the user’s IAM access.

   NOTE: The new IAM policy might not take effect for a few minutes after you create it, because of eventual consistency. Therefore, it is possible that a user will continue to be able to make successive calls to IAM for a short time after the first detection.

4. Next Steps: Do Try This

   • Break down the lambda into a step function
   • Add more remediation actions,
     • Notify InfoSecOps
     • Reverse actions carried out by user.

5. Additional Comments

   As mentioned earlier, this is a reactive solution. This automation should not be the primary means of defence against weak policies. You should consider,

   • Who has permissions to create, modify user permissions?
   • Are you auditing those privileges automatically?
   • If all else fails, do you have mechanisms that will automatically respond to events?

6. 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 (any)Quarantine Deny Policy
   2. Delete (any)user/groups created - as required
   3. 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 ☕ through Paypal, or You can reach out to get more details through here.

1. IAM Policy Evaluation Logic
2. Detect Unintended IAM Access

Level: 200