HIPAA compliance is a cornerstone for protecting sensitive patient data in hospital information systems. From a compliance management perspective, HIPAA can be a tedious framework to work with. Turning the requirements into hard rules isn’t always easy and we have a number of customers who are dealing with this challenge on an ongoing basis.
In Dome9’s Compliance Engine, we already have a number of pre-built rulesets (bundles) for security frameworks like PCI DSS and the CIS Benchmark for AWS. We’re always working to improve these rules and add on new compliance bundles for the most common needs of our customers, which is what led us to HIPAA.
One of the challenges with pre-built content, is that every environment is different. Because everyone does things differently, you might need to customize the rules to make sure that they are perfectly tailored to your specific infrastructure. Traditionally you would need to write JavaScript or Ruby code to make these changes, but with Dome9 there’s an easier way. The Dome9 Governance Specification Language (GSL) allows you to easily modify and create your own rules without any scripting. Instead, you can simply click through the Rules Engine to build the rules without any coding knowledge.
Below is a breakdown of our new HIPAA bundle, as well as a number of guidelines and sample rules that you can take and use as a framework for your HIPAA compliance.
The main sections that we’re testing within the bundle is 164.312. Within the bundle you can drill down on each section we’re testing on to see how our rules are aligned with the requirement.
In addition to showing the associated section, there is content around how to remediate the issues in the unfortunate event that you fail one of the compliance checks.
Beyond the pre built rules that we built out for HIPAA, these are some some sample rules that you can use to customize the bundle to your environment:
- EBS should be encrypted
- Rules engine example: Instance where tags contain [ key=’contains_phi’ and value=’true’ ]should have volumes with [ encrypted=true ]
- All EC2 instances need to be running in dedicated tenancy mode.
- Rules engine example: Instance should have vpc.instanceTenancy=true
- Run the Dome9 ‘Best Practices for AWS’ and CIS Benchmark rule bundles as well. It doesn’t pertain 100% to HIPAA but will give you extra coverage as you’re building a secure and compliant environment.
Examples from the best practices:
- S3Bucket should have logging.enabled=’true’
- S3Bucket should not have acl.grants with [uri=’http://acs.amazonaws.com/groups/global/AllUsers’]
- SecurityGroup where name != ‘default’ should not have networkAssetsStats contain-all [ count = 0 ]
- SecurityGroup where name=’default’ should have inboundRules isEmpty() and outboundRules isEmpty()
- SecurityGroup where not name=’default’ should have vpc
- Enforce tagging standards. If your PHI isn’t segregated by account, make sure that you can easily identify your most sensitive instances and assets.
Rules engine example: Instance should have tags with [ key=’has_PHI’ and value in(‘true’, ‘false’) ]
- Only use AMIs that have been preapproved by your team.
Rules engine example: Instance should have image=’ami-f173cc91′ or image=’ami-a58d0dc5′
After you pass the Rules Engine check, there is still more work to be done. There are other general guidelines and considerations that you should make sure you understand before putting PHI up in AWS:
- Not all of AWS’ services are approved for storing PHI. As of April 2017, here is the list of the services that are approved: DynamoDB, EBS, EC2, ELB, EMR, Glacier, Redshift, RDS for MySQL, RDS for Oracle, RDS for PostgreSQL, Aurora (MySQL-compatible version), S3, SQS, Import/Export Snowball.
- Data transmitted within a VPC must also be encrypted. It’s not enough to encrypt external web traffic to a load balancer with HTTPS. All servers within your VPC that could transmit PHI must have their traffic internally encrypted.
- Data must be highly available. This means you’ll need not only a minimum of two availability zones between your servers, but highly-available servers as well, with the option of backing up/failing over to another AWS region
- Master keys in KMS can be used to encrypt and decrypt keys that are used to encrypt actual PHI in customer applications or in AWS services that are integrated with KMS. Just do not send PHI directly to KMS using the Encrypt() or Decrypt() APIs. KMS is not an eligible service, but you can use it to generate and manage keys for applications running in other eligible services. For example, an application processing PHI in EC2 could use the GenerateDataKey API call to generate data encryption keys for encrypting and decrypting the PHI in the application. The data encryption keys would be protected by customer master keys (CMKs) stored in KMS, creating a highly auditable key hierarchy.
As requirements are added, and the best practices for running HIPAA compliant workloads on AWS evolve, we will continue to add content to the HIPAA bundle (and the others!). We want to always make sure that we can give you the best coverage possible for keeping your infrastructure secure.