AWS Config: Checking for Compliance with New Managed Rule Options

Change is the inherent nature of the Cloud. New ideas can immediately take shape through the provisioning of resources, projects will iterate and evolve, and sometimes we must go back to the drawing board. Amazon Web Services accelerates this process by providing the ability to programmatically provision and de-provision resources. However, this freedom requires some responsibility on the part the organization in implementing consistent business and security policies.

AWS Config enables AWS resource inventory and change management as well as Config Rules to confirm that resources are configured in compliance with policies that you define. New options are now available for AWS Config managed rules, providing additional flexibility with regards to the type of rules and policies that can be created.

• AWS Config rules can now check that running instances are using approved Amazon Machine Images, or AMIs. You can specify a list of approved AMI by ID or provide a tag to specify the list of AMI Ids.
• The Required-Tag managed rule can now require up to 6 tags with optional values in a single rule. Previously, each rule accepted only a single tag/value combo.
• Additionally, the Required-Tag managed rule now accepts a comma-separated list of values for each checked tag. This allows for a rule to be compliant if any one of a supplied list of tags is present on the resource.

A Sample Policy

Let’s explore how these new rule options can be incorporated into a broader compliance policy. A typical company’s policy might state that:

• All data must be encrypted at rest.
• The AWS IAM password policy must meet the corporate standard.
• Resources must be billed to the correct cost center.
• We want to know who owns a resource in case there is an issue or question about the resource.
• We want to identify whether a resource is a part of Dev, QA, Production, or staging so that we can apply the correct SLAs and make sure the appropriate teams have access.
• We need to identify any systems that handled privileged information such as Personally Identifiable Information (PII) or credit card data (PCI) as a part of our compliance requirements.
• Our Ops teams regularly provides hardened images with the latest patches and required software (e.g. security and/or configuration management agents). We want to ensure that all Linux instances are built with these images. We do regular reviews to ensure our images are up to date.

We see organizations implementing a variety of strategies like the one we have defined. Tagging is typically used to categorize and identify resources. We will be using tags and AWS Config managed rules to satisfy each of our policy requirements. In addition to the AWS Config managed rules, custom compliance rules can be developed using AWS Lambda functions.

Implementation

In the AWS Management console, we have built 5 rules.

• strong_password_policy – Checks that we have a Strong Password policy for AWS IAM Users
• only_encrypted_volumes – Checks that all attached EBS volumes are encrypted
• approved_ami_by_id – Checks that approved AMI IDs have been used
• approved_ami_by_tag – Check that AMIs tagged as sec_approved have been used
• ec2_required_tags – Check that all required tags have been applied to EC2 instances:
  

  Tag Name (Key)	Tag Value(s)	Description
  Environment	Prod / Dev / QA / Staging	The environment in which the resource deployed
  Owner	Joe, Steve, Anne	Who is responsible?
  CostCenter	General / Ops / Partner / Marketing	Who is paying for the resource?
  LastReviewed	Date (e.g. 09272016)	Last time this instance was reviewed for compliance
  AuditLevel	Normal / PII / PCI	The required audit level for the instance

Strong Password Policy

AWS Config has pre-built rules to check against the configured IAM password Policy. We have implemented this rule using the default configurations.

We can see that our IAM password policy is Compliant with our managed rule.

Approved AMIs

We have our hardened AMI from the Ops team. The image also includes encrypted EBS volumes. We have added a tag called sec_approved that we will use to test our image.

We will create two additional rules to check that EC2 instances are launched with our approved AMIs. One will check that our sec_approved tag is present on the AMI. A second rule checks that the AMI ID (ami-1480c503) is included in a comma-separated list of approved images. Now we will launch two instances. One with a standard Amazon Linux AMI (i-019b0e790a67dd7f1) and one instance with our approved AMI (i-0caf40fcb4f48517c).

If we look at the details of the approved_amis_by_tag and approved_amis_by_id rules, we see that the instance that was launched with the unapproved image (i-019b0e790a67dd7f1) has been marked Noncompliant. Our hardened instance (i-0caf40fcb4f48517c) is Compliant.

Encrypted EBS Volumes

In the EC2 Console we see the volumes attached to our instances. We can see that the EBS volumes created by our hardened AMI have been encrypted as configured. They are attached to instance i-0caf40fcb4f48517c.

If we look at the details of the only_encrypted_volumes rule, we see that the instance that was launched with the unapproved image (i-019b0e790a67dd7f1) has been marked Noncompliant. Our hardened instance is Compliant.

Required Tags

Finally, let’s take a look at the ec2_required_tags rule. We have defined our required tags in our AWS Config Rule. Specific tag values are optional, but will be required if specified. Our hardened instance was configured with all required tags.

We can see that our tagged instance is compliant with our Required Tags Rule as well.