Healthcare organizations are discovering the many benefits of using Amazon Web Services (AWS) public cloud. AWS provides a development environment for creating your own web-based healthcare applications, and a scalable storage platform for electronic medical records and data.
The AWS public cloud also has great potential as a hosting platform for health information exchanges and doctor-patient telehealth applications. AWS's subscription-based "pay-as-you-go" model gives healthcare organizations significant cost savings over buying and maintaining their own servers, and AWS's cloud-based software tools provide lower-cost access to a suite of technology resources.
But with the ease of AWS access and use, some healthcare organizations have become careless in maintaining data and application security. AWS offers many services that are compliant with the Health Information Portability and Accountability Act (HIPAA) laws, but just because AWS has met those requirements on their end does not absolve your organization from upholding them on yours, as cloud security is a shared responsibility.
If your healthcare organization uses AWS to store, process, or transmit Protected Health Information (PHI), it’s your responsibility to ensure that PHI is safe and secure against unauthorized access or accidental exposure.
Setting Your HIPAA Policies
There are two things that your organization must do initially in order to ensure that you meet HIPAA standards on AWS.
First, you need to have a set of policies for HIPAA compliance on AWS in place. These policies should be documented, and should cover the best practices for which employees create servers, store records, and tag PHI appropriately. Any employee in your organization who works on AWS should understand that these policies are not optional, but are required to ensure data and application security.
Next, you must ensure that your architecture is up to code with HIPAA and that you only use HIPAA eligible services. This AWS Landing Zone Accelerator for Healthcare is a good place to start.
Finally, you should do regular assessments of your organization's AWS account to identify and correct any HIPAA compliance issues, and to evaluate application and data security. We'll talk about how to do these assessments later in this article.
Here are the 10 most common HIPAA compliance issues in AWS and how to prevent them.
The Top 10 AWS HIPAA Compliance Issues
1. Public vs. Private Resources
To begin with, your employees should know which of your AWS resources are public and which are (or should be) private resources. For example, you may create a Virtual Private Network on AWS to handle medical processing, but your employees may create one or more public sub-networks that connect to that VPN. If an employee deploys an Elastic Compute Cloud (EC2) server on the public sub-network, that server will be accessible to people outside of your organization.
To achieve HIPAA compliance, you must set up your systems to prevent even the opportunity for access by unauthorized personnel. Even if a server on a public sub-network contains no PHI, it's still a security risk, because outside hackers can use that server as an entrance point for the rest of the network. Employees should understand the importance of setting up security protocols, such as a firewall, to limit access to that server.
2. Tagging Resources
All AWS resources must be properly tagged to effectively manage and meet HIPAA compliance. For example, if an AWS S3 bucket is used to store PHI, it should be tagged "PHI."
Proper resource tagging can sometimes help you to identify security issues. If an S3 bucket tagged "PHI" is also tagged "DEV," that's a problem. There's never a need to use PHI in a development environment, which often has fewer security protocols in place and may be more vulnerable to unauthorized access.
3. Auditing and Logging
HIPAA regulations require that you must be able to establish an audit trail for any of your resources. On AWS, you can use CloudTrail, the auditing tool that monitors all actions in your account, and issues regular audit reports.
You need to properly configure CloudTrail to ensure HIPAA compliance. You should:
- Configure CloudTrail to send audit reports to secure, encrypted S3 buckets.
- Enable "Validation" in CloudTrail, which puts an algorithm on each log entry, giving you a way to ensure the entry hasn't been changed or altered.
- Enable "MFA delete" in CloudTrail, which requires multi-factor authentication in order to delete an audit report.
- In the S3 bucket, make sure that versioning has been enabled so if a log has been removed or tampered with, there will still be a copy available for review by security personnel.
Also, to establish an audit trail, you need to set up proper logging. One way to do this is to turn on the logging feature for S3 buckets, which records every action (i.e. adding, reading, or deleting a record) in that storage space. Be aware, however, that AWS charges for this type of logging, and S3 buckets that have higher access rates will incur higher logging fees.
4. Rotating Passwords and Tokens/Keys
Your organization should have a secure password policy, which covers password age and complexity, and restricts password reuse on AWS. It's recommended that you set AWS passwords to expire after 90 days, with automatic notifications sent to users when their password is about to expire.
Likewise, your AWS users may use tokens or access keys to create or delete resources, pull or copy data, etc. You should set up a requirement with automatic notifications that every 180 days, users must access their account, create a new set of keys, and disable the old set, so they can't be used anymore.
5. Multi-Factor Authentication
Multi-Factor Authentication (MFA) adds an extra layer of security to the sign-on procedure. Although MFA isn't required for HIPAA compliance, the U.S. Department of Health and Human Services strongly recommends its use. You should enable MFA for any user in your organization who has administrative rights on AWS and any users that have access to PHI.
6. Storage Encryption
As of 2020, AWS started providing an “Enforce Default Encryption” policy, so when you create an EC2 instance (i.e. a server), AWS automatically encrypts the storage drive which stores the operating system.
However, there are still legacy issues. If your employees previously created an EC2 server on AWS and did not encrypt its root volume, you may need to rebuild the entire server. Any data that passes through that root volume will be unencrypted, even if additional encrypted storage was added later.
Also, legacy S3 storage buckets may not have been encrypted by default, causing the same issue. You should audit your S3 buckets to make sure they’re encrypted and ensure that any medical records stored in that S3 will be encrypted.
7. Secure Transport Encryption
When you create an EC2 server or other device on AWS, you should enable Secure Socket Layer (SSL) and Transport Layer Security (TLS) protocols, so that any data transmitted across your virtual networks by applications on that server will be encrypted in transit.
8. Storage Backups
HIPAA compliance requires that you do storage backups of PHI every 30 days. But your frequency of backups is as much operational as compliance based. If a database on your AWS account is processing thousands of healthcare transactions per hour like an EHR system, you should configure transaction logs for hourly full backups from daily ones.
Some AWS services do automatic backups, while others, such as EC2, require backups to be enabled. You should configure all your AWS instances for regular backups, based on operational requirements. The configuration tools let you control the backup frequency, and how long you retain the information which, to meet HIPAA retention requirements, has to be a minimum of six years after the data was last effective.
9. System Availability
High availability is a chief requirement for HIPAA compliance. If an AWS server goes down, you need to make sure that any healthcare information and applications stored on that server are available for access on other servers.
You should create multiple versions of each of your AWS servers, and spread those versions across multiple geographic locations. Also, your servers should be located behind a load balancer, which spreads traffic out across many servers. If you lose one server, the load balancer will transfer workloads to the other servers, so you don't lose any information or applications.
10. Risk Analysis
One final step to take is to run frequent, ongoing risk analyses of your AWS account, to search for HIPAA compliance issues. Many healthcare organizations fail to do this, and are often unaware of the potential HIPAA violations in their environment.
One easy way to do this is to use Cloudticity's free, automated AWS Technical Assessment tool, which scans your account according to HIPAA, HISTRUST, and other security standards, and gives you a list of issues that may be possible violations. Once you know what those issues are, your healthcare organization can take steps to correct them.
CLICK HERE TO TRY THE AWS ASSESSMENT TOOL TODAY!
Or schedule a free consultation to learn how we can help keep your healthcare cloud secure and compliant today.
