How to Use AWS Config to Help with Required HIPAA Audit Controls: Part 4 of the Automating HIPAA Compliance Series

In my previous posts in this series, I explained how to get started with the DevSecOps environment for HIPAA that is depicted in the following architecture diagram. In my second post in this series, I gave you guidance about how to set up AWS Service Catalog (#4 in the following diagram) to allow developers a way to launch healthcare web servers and release source code without the need for administrator intervention. In my third post in this series, I advised healthcare security administrators about defining AWS CloudFormation templates (#1 in the diagram) for infrastructure that must comply with the AWS Business Associate Agreement (BAA).

In today’s final post of this series, I am going to complete the explanation of the DevSecOps architecture depicted in the preceding diagram by highlighting ways you can use AWS Config (#9 in the diagram) to help meet audit controls required by HIPAA. Config is a fully managed service that provides you with an AWS resource inventory, configuration history, and configuration change notifications. This Config output, along with other audit trails, gives you the types of information you can use to meet your HIPAA auditing obligations. 

Auditing and monitoring are essential to HIPAA security. Auditing controls are a Technical Safeguard that must be addressed through the use of technical controls by anyone who wishes to store, process, or transmit electronic patient data. However, because there are no standard implementation specifications within the HIPAA law and regulations, AWS Config enables you to address audit controls  to use the cloud to protect the cloud.

Because Config currently targets only AWS infrastructure configuration changes, it is unlikely that Config alone will be able to meet all of the audit control requirements laid out in Technical Safeguard 164.312, the section of the HIPAA regulations that discusses the technical safeguards such as audit controls. However, Config is a cloud-native auditing service that you should evaluate as an alternative to traditional on-premises compliance tools and procedures.

Standard audit controls found in 164.312(b)(2) of the HIPAA regulations says: “Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic health information.” Config helps achieve this because it monitors the activity of both running and deleted AWS resources across time. In a DevSecOps environment in which developers have the power to turn on and turn off infrastructure in a self-service manner, using a cloud-native monitoring tool such as Config will help ensure that you can meet your auditing requirements. Understanding what a configuration looked like and who had access to it at a point in the past is something that you will need to do in a typical HIPAA audit, and Config provides this functionality.

For more about the topic of auditing HIPAA infrastructure in the cloud, the AWS re:Invent 2015 session, Architecting for HIPAA Compliance on AWS, gives additional pointers. To supplement the monitoring provided by Config, review and evaluate the easily deployable monitoring software found in the AWS Marketplace.

Get started with AWS Config

From the AWS Management Console, under Management Tools:

1. Click Config.
2. If this is your first time using Config, click Get started.
3. From the Set up AWS Config page, choose which types of resources that you want to track.

Config is designed to track the interaction among various AWS services. At the time of this post, you can choose to track your accounts in AWS Identity and Access Management (IAM), Amazon EC2–related services (such as Amazon Elastic Block Store, elastic network interfaces, and virtual private cloud [VPC]), and AWS CloudTrail.

All the information collected across these services is normalized into a standard format so that auditors or your compliance team may not need to understand the underlying details of how to audit each AWS service. They simply can review the Config console to ensure that your healthcare privacy standards are being met.

Because the infrastructure described in this post is designed for storing protected health information (PHI), I am going to select the check box next to All resources, as shown in the following screenshot. By choosing this option, I can ensure that not only will all the resources available for tracking be included, but also as new resource types get added to Config, they will automatically be added to my tracking as well.

Also, be sure to select the Include global resources check box if you would like to use Config to record and govern your IAM resource configurations.

Specify where the configuration history file should be stored

Amazon S3 buckets have global naming, which makes it possible to aggregate the configuration history files across regions or send the files to a separate AWS account with limited privileges. The same consolidation can be configured for Amazon Simple Notification Service (SNS) topics, if you want to programmatically extend the information coming from Config or be immediately alerted of compliance risks.

For this example, I create a new bucket in my account and turn off the Amazon SNS topic notifications (as shown in the following screenshot), and click Continue.

On the next page, create a new IAM role in your AWS account so that the Config service has the ability to read your infrastructure’s information. You can review the permissions that will be associated with this IAM role by clicking the arrow next to View Policy Document.

After you have verified the policy, click Allow. You should now be taken to the Resource inventory page. On the right side of the page, you should see that Recording is on and that inventory is being taken about your infrastructure. When the Taking inventory label (shown in the following image) is no longer visible, you can start reviewing your healthcare infrastructure.

Review your healthcare server

For the rest of this post, I use Config to review the healthcare web server that I created with AWS Service Catalog in How to Use AWS Service Catalog for Code Deployments: Part 2 of the Automating HIPAA Compliance Series.

From the Resource inventory page, you can search based on types of resources, such as IAM user, network access control list (ACL), VPC, and instance. A resource tag is a way to categorize AWS resources, and you can search by those tags in Config. Because I used CloudFormation to enforce tagging, I can quickly find the type of resources I am interested in by setting up search for these tags.

As an example of why this is useful, consider employee turnover. Most healthcare organizations need to have processes and procedures to deal with employee turnover in a regulated environment. Because our CloudFormation template forced developers to populate a tag with their email addresses, you can easily use Config to find all the resources the employee was using, if they decided to leave the organization (or even if they didn’t leave the company).

Search on the Resource inventory page for the employee’s email address along with the tag, InstanceOwnerEmail, and then click Look up, as shown in the following screenshot.

Click the link under Resource identifier to see the Config timeline that shows the most recent configuration recorded for the instance as well as previously recorded configurations. This timeline will show not only the configuration details of the instance itself, but also will provide the relationships to other AWS services and an easy-to-interpret Changes section. This section provides your auditing and compliance teams the ability to quickly review and interpret changes from a single interface without needing to understand the underlying AWS services in detail or jump between multiple AWS service pages.

Clicking View Details, as shown in the following image, will produce a JSON representation of the configuration, which you may consider including as evidence in the event of an audit.

The details contained in this JSON text will help you understand the structure of the configuration objects passed to AWS Lambda, which you interact with when writing your own Config rules. I discuss this in more detail later in this blog post.

Let’s walk through a quick example of one of the many ways of how an auditor or administrator may go about using Config. Let’s say that there was an emergency production issue. The issue required an administrator to add SSH access to production web servers temporarily so that he or she could log in and manually install a software patch. The patches then were installed and SSH access was revoked from all the security groups except for one instance’s security group, which was mistakenly forgotten. In Config, the compliance team is able to review the last change to any resource type by reviewing the Config Timeline (as show in the following screenshot) and clicking Change to verify exactly what was changed.

It is clear from the following screenshot that the opening of SSH on port 22 was the last change captured, so we need to close the port on this security group to block remote access to this server.

Extend healthcare-specific compliance with Config Rules

Though the SSH configuration I just walked through provided context about how Config works, in a healthcare environment we would ideally want to automate this process. This is what AWS Config Rules can do for us.

Config Rules is a powerful rule system that can target resources and then have those resources evaluated when they are created or changed or evaluated on a periodic basis (hourly, daily, and so forth).

Let’s look at how we could have used Config Rules to identify the same improperly opened SSH port discussed previously in this post.

At the time of this post, AWS Config Rules is available only in the US East (N. Virginia) Region, so to follow along, be sure you have the AWS Management Console set to that region. From the same Config service that we have been using, click Rules in the left pane and then click Add Rule.

You can choose from available managed rules. One of those rules is restricted-common-ports, which will fit our use case. I modify this rule to be limited to only those security groups I have tagged as PROD in the Trigger section, as shown in the following screenshot.

I then override the default ports of this rule and specify my own port under Rule parameters, which is 22.

Click Save and you will be taken back to the Rules page to have the rule run on your infrastructure. While the rule is running, you will see an Evaluating status, as shown in the following image.

When I return to my Resource inventory by clicking Resources in the left pane, I again search for all of my PROD environment resources. However, with AWS Config rules, I can quickly find which resources are noncompliant with the rule I just created. The following screenshot shows the Resource type and Resource identifier of the resource that is noncompliant with this rule.

In addition to this SSH production check, for a regulated healthcare environment you should consider implementing all of the managed AWS Config rules to ensure your AWS infrastructure is meeting basic compliance requirements set by your organization. A few examples are:

1. Use the encrypted-volumes rule to ensure that volumes tagged as PHI=”Yes” are encrypted.
2. Ensure that you are always logging API activity by using the cloudtrail-enabled rule.
3. Ensure you do not have orphaned Elastic IP addresses with eip-attached.
4. Verify that all development machines can only be accessed with SSH from the development VPC by changing the defaults in restricted-ssh.
5. Use required-tags to ensure that you have the information you need for healthcare audits.
6. Ensure that only PROD resources that are hardened for exposure to the public Internet are in a VPC that has an Internet gateway attached by taking advantage of managed rule, ec2-instances-in-vpc.

Create your own healthcare rules with Lambda

The managed rules just discussed will give you a jump-start to make sure your environment is meeting some of the minimum compliance requirements shared across many compliance frameworks. These rules can be configured quickly to make sure you are meeting some of the basic checks in an automated manner.

However, for deep visibility into your healthcare-compliant architecture, you might want to consider developing your own custom rules to help meet your HIPAA obligations. As a trivial, yet important, example of something you might want to check for to be sure you are staying compliant with the AWS Business Associates Agreement, you could create a custom AWS Config rule to check that all objects stored in your S3 buckets are encrypted. This can be done by creating a new rule as shown previously in this post, except this time click Add custom rule at the top of the Config Rules page.

For more details about working with Config Rules, see the AWS Config Developer Guide to learn how to develop your own rules.

In addition to digging deeper into the documentation, you may also want to explore the AWS Config Partners who have developed Config rules that you can simply take and use for your own AWS infrastructure. For companies that have HIPAA expertise and are interested in partnering with AWS to develop HIPAA-specific Config rules, feel free to email me or leave a comment in the “Comments” section below to discuss more.

Conclusion

In this blog post, I have completed my explanation of a DevSecOps architecture for the healthcare sector by looking at AWS Config Rules. I hope you have learned how compliance and auditing can use Config Rules to track the rapid, self service changes developers make to cloud infrastructure as well as how you can extend Config with customized compliance rules that allow auditing and compliance groups to gain deep visibility into a developer-centric AWS environment.

– Chris