GRC334 - Build an effective security compliance program that continuously evaluates and remediates your security posture

In this session learn how to build a solution that will continuously evaluate your AWS resources for security compliance using AWS Config Rules, Amazon CloudWatch Events, and AWS Lambda. You will also learn how to improve your security posture by correcting or eliminating non-compliant resources.

Prerequisites

  • AWS Account
  • IAM Account with Full Access
  • Set the region to us-east-1

Instructions

Log into your AWS Account and run the Cloud Formation template provided below

In this section, we will create AWS resources uses for this session.

  1. Go to the CloudFormation Console, and click Create stack. For Prerequisite - Prepare template, select Template is ready.
  2. Download the template from here to your machine.
  3. Under Specify template, select Upload a template file and click Choose file button and select CloudFormation template downloaded from the previous step.
  4. Enter Stack name. Keep the setting with the default value and click Next.
  5. On the Review Test step, in the Capabilities section, check the check box I acknowledge that AWS CloudFormation might create IAM resources with custom names. and complete the Stack creation.

Enable AWS Config to track configuration changes

We will enable AWS Config to begin change tracking of your resources.

  1. Go to the AWS Config Console. If this is your first time using AWS Config, select Get started. If you’ve already used AWS Config, select Settings.
  2. In the Settings page, under Resource types to record, select Record all resources supported in this region checkbox. Also check the checkbox for global resources.
  3. Under Amazon S3 bucket, select Create a bucket.
  4. Under Amazon SNS topic, check the box for Stream configuration changes and notifications to an Amazon SNS topic, and then select the radial button, Create a topic.
  5. Under AWS Config role, choose Create AWS Config service-linkded role. (unless you already have a role you want to use).
  6. If this is the first time using AWS Config, Click Next to Create Rule. Click Skip to go to Review page. Click Confirm
  7. Go to CloudTrail console, click Trails.
  8. Click Create trail. Enter Trail name. Go to Storage location section, select to create a new S3 bucket and enter the name. Click Create.

Create another SNS Topic for Config Rule violation notification.

  1. In another browser tab, go to SNS Console. Click Topics in the left menu and click Create topic.
  2. Enter the Topic Name then click Create Topic. Take note of SNS topic ARN.
  3. Optional Click Create subscription, select Email for Protocol and enter an email address for Endpoint. You will receive and email with an instruction to confirm the subscription.

AWS Config Rule

Scenario I: Detecting and remediating S3 World Public Read Access with AWS Config and AWS System Manager Automation Document

In this section, we will create a Config rule to detect S3 Bucket with Public Read access permission and remediate the noncompliant.

s3-bucket-public-read-prohibited Checks that your Amazon S3 buckets do not allow public read access. The rule checks the Block Public Access settings, the bucket policy, and the bucket access control list (ACL).

  1. Go to the AWS Config Console and click Rule from the left menu. Click + Add Rule.
  2. In the AWS Config rules page, Search and select s3-bucket-public-read-prohibited. Leave the settings in Trigger section with default value.
  3. In Choose remediation action section, select AWS-PubishSNSNotification, and don't change the drop down selection. Provide SNS TopicArn from the previous section and Message, message is freetext and can be anything.
  4. Click Save. Wait a few minutes for the rule to apply. Examine the compliant and non-compliant S3 resource. There are two bucket that has Public Read permission. Let's fix one.
    AWS Config Rule
  5. Under Noncompliant status, click the resource, awsconfig-configbucket1bucket1xxxxxxx. We will ensure that this bucket can only be accessible from a specific network address. Click Manage resource button which will take you to S3 console.
  6. Under Permission Tab, Bucket Policy, replace the existing policy with the following policy. Replace Resources's value with your S3 ARN and click Save. Alternatively, add the Condition value below to the existing Bucket Policy.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::awsconfiglabstack-configbucket1bucket1xxxxxxxxxxxxx/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "54.240.143.0/24"
                }
            }
        }
    ]
}
  1. Return to AWS Config console, s3-bucket-public-read-prohibited Rule then click **Re-evaluate**. It will take a few minutes for the rule to detect the change. Now there is only one bucket that is noncompliant.

AWS Config Rule

  1. Under Compliance status, select Complaint from the dropdown menu to filter the list. Select S3 bucket resource that we made Bucket Policy changed earlier. Click Configuration timeline to see the configuration change history. Click Compliance timeline to see the Compliance history for this resource.

AWS Config Rule

Configuration Timeline

Compliance Timeline

Let's prevent Public Acess Configuration

  1. Click Manage Resource to Go to S3 console, S3 bucket. In Permission tab, click Bucket Policy and click delete to remove the existing Bukcet Policy.
  2. Click Block public access, click Edit. Select Block all public access checkbox, click Save and confirm the change.
  3. Now go back to Bucket Policy, enter the policy below which give Public Read Access to the world. Replace the Resource's value with your S3 Bucket Arn.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::awsconfiglabstack-configbucket1bucket1xxxxxxxxxxx/*"
        }
    ]
}

You get Access Denied!!
4. Now try the policy in step 6. You are able to add policy that does not give Public Read Access to the world

Let's use System Manager Document to remediate the noncompliant.

  1. Go back to S3 bucket in Permission tab, click Bucket Policy. Click Block public access, click Edit. uncheck Block all public access and click Save amd confirm the change. For Bucket Policy, remove the Conditon for IP Address from the policy. Now this bucket has Read access and noncompliant. Go to AWS Config rule and re-evaluate the rule.
  2. Go to System Manager Console, click Documents under Shared Resources on the left menu.
  3. Click Create Document, type Name: My-DisableS3ReadAccess and select Document type: Automation document
  4. Under Content, select YAML and copy the code below. Click Create document.
---
description: Disable S3-Bucket's public WriteRead access via private ACL
schemaVersion: "0.3"
assumeRole: "{{ AutomationAssumeRole }}"
parameters:
  S3BucketName:
    type: String
    description: (Required) S3 Bucket subject to access restriction
  AutomationAssumeRole:
    type: String
    description: (Optional) The ARN of the role that allows Automation to perform the actions on your behalf.
    default: ""
mainSteps:
- name: DisableS3BucketPublicReadWrite
  action: aws:executeAwsApi
  inputs:
    Service: s3
    Api:  PutPublicAccessBlock
    Bucket: "{{S3BucketName}}"
    PublicAccessBlockConfiguration: 
      BlockPublicAcls: true
      IgnorePublicAcls: true
      BlockPublicPolicy: true
      RestrictPublicBuckets: true
  isEnd: true
...

Now we are going to add this document to AWS Config rule Remediation.
5. Go back to AWS Config console, select the radio button for rule s3-bucket-public-read-prohibited and click Manage remediation button.
6. Click Delete remediation action to delete the existing one (AWS-PubishSNSNotification).
7. For Remediation action dropdown, find the System Mananger Document created earlier, My-DisableS3Access. 8. For Resource ID parameter, select S3BucketName. Click Save.
9. Re-evaluate the rule and you should see this bucket has Noncompliant status.
10. Select the resource and click Remediate. When complete, click Re-evaluate the rule.
11. Go back to the S3 Bucket and go to Permissions tab. Check to see if Block public access settings are all On.

Scenario II: Detecting and automatically remediating S3 World Public Read/Write Access with AWS Config and CloudWatch Event and Lambda function

In this section, we continue to use AWS Config Rule to detect S3 Public Read/Write Acess configuration. We will use CloudWatch Event and Lambda Function to automate the remediation.

  1. Go to AWS Config Console and click Rule from the left menu.
  2. Click + Add Rule, search and select s3-bucket-public-write-prohibited. Leave everything with default value in Trigger section.
  3. In Choose remediation action section, select AWS-PubishSNSNotification and provide SNS TopicArn and Message.
  4. Click Save. Wait a few minutes for the rule to apply. Examine the compliance and non-compliance S3 resource. Go to the non-compliance S3 Bucket and see why it is opened to the world. Hint Take a look at its Bucket Policy. Next, we are going to use AWS CloudWatch event and AWS Lambda to automatically remediate the noncompliant.
  5. Go to AWS CloudWatch console. On the left menu, click Rules under Events.
  6. Click Create rule button to creat a new rule. On Step 1: Create rule, under Event Source, select Event Pattern radio button. In the dropdown, select Build cutomer event pattern. Enter the following json text. The CloudWatch Event rule will look for Event emitted from AWS Config that is from S3_BUCKET_PUBLIC_WRITE_PROHIBITED with NON_COMPLIANT type.
{
  "source": [
    "aws.config"
  ],
  "detail": {
    "requestParameters": {
      "evaluations": {
        "complianceType": [
          "NON_COMPLIANT"
        ]
      }
    },
    "additionalEventData": {
      "managedRuleIdentifier": [
        "S3_BUCKET_PUBLIC_WRITE_PROHIBITED"
      ]
    }
  }
}

Now let's setup the event action.
7. Under Targets, select Lambda function in the first dropdown. For Function name, search for AWSConfgLab and choose function name. This function was created with the Cloudformation in the earlier step. Click Configure Detail
CloudWatch Event 8. Under Step 2 : Configure rule details, Rule definition, enter the rule name. Click Create rule.
9. Go to AWS Lambda Console, search and select the Lambda function in the earlier step. You can see that this function is triggered by CloudWatch Events.
CloudWatch Event 10. Go to AWS Config Console and click s3-bucket-public-write-prohibited rule. Click Re-evaluate button to manually trigger the rule.
11. Examine Lambda function Monitoring tab to see if the function has invoked. Click View logs in CloudWatch to see the logs generated from Lambda function. This step can take a few minutes. 12. Go back to AWS Config rule and re-evaluate the Rule. Go back to S3 Bucket and see if Bucket Policy is removed.
13. Let's look at the Lambda function code. This function accept CloudWatch Event as its parameter and look for the Bucket name with "NON_COMPLIANT" complianceType. Then it removes the Bucket Policy from this S3 Bucket.

var AWS = require('aws-sdk');

exports.handler = function(event) {
  console.log("request:", JSON.stringify(event, undefined, 2));

  // create AWS SDK clients
    var s3 = new AWS.S3({apiVersion: '2006-03-01'});
    var resource = event['detail']['requestParameters']['evaluations'];
    console.log("evaluations:", JSON.stringify(resource, null, 2));

for (var i = 0, len = resource.length; i < len; i++) {
  if (resource[i]["complianceType"] == "NON_COMPLIANT")
  {
      console.log(resource[i]["complianceResourceId"]);
      var params = {
        Bucket: resource[i]["complianceResourceId"]
      };

      s3.deleteBucketPolicy(params, function(err, data) {
        if (err) console.log(err, err.stack); // an error occurred
        else     console.log(data);           // successful response
      });
  }
}


};

Scenario III, Detecting Blacklisted application with AWS Config and AWS System Manager, Inventory.

We will be using Inventory in AWS System Manager combine with AWS Config Rule to detect the unwanted application installed on EC2 instances.

  1. In the AWS Management Console, go to the AWS Systems Manager console and choose Managed Instances on the left navigation pane. This should list all EC2 instances or on-premises managed instances in your account.
  2. Click Setup Inventory and select the EC2 instance you want to collect inventory from. In this exercise, select Specifying a tag and enter Name for Tag key and AwsconfigLabStack/ec2fleet/ASG for Tag value.
  3. Click Setup Inventory to complete the action. Verify that the instance has collected an inventory of applications installed on the instance.
  4. On the AWS Systems Manager console, choose Managed Instances, and then choose Edit AWS Config recording for the EC2 instance. It will talk you to AWS Config Console, under Settings.
  5. Under Settings, click Turn on button to enable the Configuration Recording.
  6. Let's install Java on one of these managed instances. Go to System Manager Console, Inventory.
  7. Note one of the Instance ID from the managed instances list.
  8. Go to Session Manager, and click Start session. Search and select the Instance ID from the previous step and click Start Session.
  9. In the prompt, enter these follow command.
sudo yum install java-1.8.0-openjdk-devel
sudo alternatives --config java

Enter 2 to select JRE 1.8. Confirm it by typing this command.

java -version

We can wait for the next schedule for inventory to be re-evaluate but we can't. Let do it manually.
10. Go to State Manager in System Manager console.
11. Under Associations, select the assosication for the Inventory created earlier then click Apply association now. 12. When it completes, in the resource tab, select the instance that we installed java 1.8.
13. Click Inventory tab, search for Name : Bgin with : j
14. Go to Inventory and schroll down to the Corresponding managed instances. At the instance that we installed JRE 1.8, click the link to AWS Config. Examine the Configurtion timeline, the "Changes" on the latest one. It will take you to the detail what the changes were.
15. Let's apply AWS Config rule to detect the prohibited or blacklisted applications. Go to AWS Config console and click Rules.
16. Click Add rule and search and select ec2-managedinstance-applications-blacklisted. Under Rule parameters, enter "java-1.7.0-openjdk" as the value for the applicationNames key as the application to be prohibited.
17. For remediation action, choose AWS-PublishSNSNotification and provide TopicArn and Message Value. You can use the same configuration as in Scenario I. Click Save. The rule will start to apply immediately. Wait until it complete and examine the result.

Challenge

  1. Fix the compliance error.
  2. Use AWS Config Dashbord to monitor the compliance. Keep it Green!!