AWS & HIPAA Compliance

An ecfirst Case Study:

AWS & HIPAA Compliance
Amazon Provides the Tool, You Are Responsible for Compliance

© 2014 All Rights Reserved | ecfirst

An ecfirst Case Study: AWS & HIPAA Compliance

TABLE OF CONTENTS
EXECUTIVE SUMMARY ..................................................................................... 3
WHAT IS AMAZON WEB SERVICE (AWS)? ..................................................................................... 3
WHY DO PEOPLE DEPLOY AWS? ................................................................................................... 3
WHAT IS THE PRIMARY COMPLIANCE CONCERN WHEN USING AWS? ........................................ 3
UNDER THE AWS “SHARED RESPONSIBILITY MODEL” WHO IS RESPONSIBLE FOR WHAT? ......... 3
Administrative Safeguards ........................................................................................................ 4
Physical Safeguards .................................................................................................................. 4
Technical Safeguards ................................................................................................................ 5
Policy & Procedures, Business Associates Agreement .............................................................. 5

DRILL DOWNS ON AWS AND COMPLIANCE ...................................................... 6
AWS “SHARED RESPONSIBILITY MODEL” ..................................................................................... 6
Compliance Governance ........................................................................................................... 6
Infrastructure Management ..................................................................................................... 7
IT Controls ................................................................................................................................. 7
ENCRYPTION ................................................................................................................................. 8
AWS ACCESS TO CLIENT EPHI ....................................................................................................... 9
CONTINGENCY PLANNING ............................................................................................................ 9
AUDITING .................................................................................................................................... 10
BUSINESS ASSOCIATES AGREEMENT .......................................................................................... 10

AWS HIPAA COMPLIANCE DETAILS ................................................................ 11
BIBLIOGRAPHY .............................................................................................. 29

© 2014 All Rights Reserved | ecfirst

2

An ecfirst Case Study: AWS & HIPAA Compliance

EXECUTIVE SUMMARY
What is Amazon Web Service (AWS)?
AWS is an ―Infrastructure as a Service‖ (IaaS) partner utilized by some
Healthcare Entities (HCE) and their Business Associates (BA). In other words,
customers lease virtual servers and storage from AWS; customers no longer
need to house and secure servers and data storage on their own premises. In
some cases, it is possible to move nearly 100% of and entities IT Infrastructure
to AWS.

Why do people deploy AWS?
AWS replaces upfront capital cost with ongoing operational expenses, along
with no longer needing to house and secure servers and storage. Time to
implement new solutions, expand capacity, and increase scalability are greatly
reduced as servers and storage capacity can be stood up in hours, rather than
days or weeks.

What is the primary compliance concern when using
AWS?
AWS is not compliant out of the box. Misunderstanding of AWS ―Shared
Responsibility Model‖ presents the primary concern. Many entities overestimate
the actual compliance responsibilities that will be offset by utilizing AWS,
equating it to an outsourcing model, which is vastly different from a compliance
perspective. Understand that AWS requires customers sign the AWS BAA
without revision.
HCEs and BAs must also be aware that AWS storage comes in more than one
option, each with its own compliance ramifications.

Under the AWS “Shared Responsibility Model” who is
responsible for what?
AWS provides the tools for entities to build their own compliant solution. To
build fully compliant solutions, HCEs and BAs bear the entire responsibility.
They should be prepared to utilize third party expertise and potentially third
party products as well. More detail is provided in the Drill Down section as we
break down two AWS instances (tools) in more detail.

© 2014 All Rights Reserved | ecfirst

3

An ecfirst Case Study: AWS & HIPAA Compliance

High Level HIPAA-specific Areas
Administrative Safeguards
Risk Analysis
The sole responsibility lies with the HCE or BA, who must be aware of how
EPHI is flowing through the AWS infrastructure in their implemented
configuration. The HCE must determine if the AWS configuration it has
implemented within AWS infrastructure is reasonable and appropriate for their
own organization.

Risk Management
This is addressed in the BAA. The AWS portion will be sufficient for their
responsibilities only. The HCE or BA bears the overall responsibility.

Workforce Security (Can AWS access my data?)
This depends on customers chosen configuration. The HCE or BA must have
the skills to design, insure, and test that compliance is reasonable and
appropriate for their implementation.

Security Incident Procedures
This is addressed in the BAA. The AWS portion will be sufficient for their
responsibilities only. The HCE or BA bears the overall responsibility.

Contingency Planning (Business Continuity Planning or BCP)
Again, AWS offers multiple configurations and recoverability options. The HCE
or BA must have the skills to design, insure, and test that compliance is
reasonable and appropriate for their implementation.

Physical Safeguards
Facility Security Plan, Access Control
This is addressed in the BAA. The AWS portion will be sufficient for their
responsibilities only. The HCE or BA bears the overall responsibility.

Maintenance Records

© 2014 All Rights Reserved | ecfirst

4

An ecfirst Case Study: AWS & HIPAA Compliance

This is addressed in the BAA. The AWS portion will be sufficient. However,
AWS Maintenance Records do not eliminate the need for the HCE to maintain
records of its own maintenance of systems within the AWS environment.

Technical Safeguards
Auditing
As noted earlier, AWS provides the tools only. It is the HCE’s or BA’s
responsibility to build and implement a compliance auditing program. Be
prepared to utilize third party tools in this area.

Encryption of Data at Rest and In-transit
Depending on the AWS configuration, most organizations should be prepared
to acquire external expertise, and potentially third party products, to encrypt
EPHI housed with the AWS domain. More detailed info is provided in the Drill
Down section.

Policy & Procedures, Business Associates Agreement
Policies and procedures must be complete. Many times it is tempting to skip a
policy or procedure because another entity such as AWS handles that
component. A policy detailing the responsibility, delegating the responsibility to
the other entity, and stating the expectations of HIPAA compliance is required.
Reference the BAA in the policy.

© 2014 All Rights Reserved | ecfirst

5

An ecfirst Case Study: AWS & HIPAA Compliance

DRILL DOWNS ON AWS AND COMPLIANCE
AWS “Shared Responsibility Model”
AWS is neither compliant nor non-compliant. Achieving compliance with any
standard, be it HIPAA, PCI, SOX, FedRAMP, FIPS, or ISO, is termed a ―shared
responsibility.‖ AWS provides the tools, flexibility, and customer control to
permits rapid deployment of fast, scalable, and more reliable solutions than
most companies have ability to do in-house. These components, configured
properly by the client to meet industry‐specific security and compliance
requirements, are solely the HCE’s or BA’s responsibility. Per the AWS BAA,
―You are responsible for implementing appropriate privacy and security
safeguard in order to protect your PHI compliance with HIPAA.‖ The same skills
needed to build compliant solutions in-house, and knowledge of AWS
infrastructure, are needed to build compliant solutions utilizing AWS.
Depending on needs and design, third party add-on products or third partyprovided knowledge may be needed as well to ensure regulatory compliance.

Compliance Governance
AWS customers are required to maintain governance over the entire IT control
environment regardless of how the client’s information technology is deployed
in AWS. Customers must have an understanding of required compliance
objectives and requirements, establish a control environment that meets those
objectives and requirements, an understanding of the validation required based
on the organization’s risk tolerance, and verification of the operating
effectiveness of that control environment.
Strong customer compliance and governance might include the following basic
approach:
1. Understand as much of the entire IT environment, including technical
aspects of AWS, and document all compliance requirements.
2. Confirm/develop and implement control objectives to meet compliance
requirements.
3. Identify and document controls owned or provided by third parties.
4. Enter into an appropriately detailed Business Associate Agreement (BAA)
with AWS. (Since AWS does not allow revisions to its BAA, you may find
this not to be possible and must choose either Risk Avoidance by not doing
business with AWS or Risk Acceptance by documenting the shortcoming
along with any mitigation efforts, and then completing the process with
executive signoff)

© 2014 All Rights Reserved | ecfirst

6

An ecfirst Case Study: AWS & HIPAA Compliance

5. Conduct annual Risk Assessments, Technical Vulnerability Assessments,
and periodic Penetration Tests to verify that all control objectives are
designed and operating effectively.

Infrastructure Management
Moving IT infrastructure to AWS services relieves the HCE or BA of the
operational burden of operating, managing, controlling, and physically securing
hardware servers, storage devices and the communications between them.
Customers still have the responsibility and management of the operating
system (including updates and security patches), associated application
software as well as network design and configuration of the AWS security
group firewall. Overall responsibilities will vary depending on the services used,
the integration of those services into the IT environment, and applicable laws
and regulations. It is possible for customers to enhance security and/or meet
their more stringent compliance requirements by leveraging technology such as
host-based firewalls, host-based intrusion detection/prevention, encryption, and
key management. Again, third party components may be needed.

IT Controls
The shared responsibility also includes IT controls. The responsibility of
operating the IT environment is shared, as is the management, operation, and
verification of IT controls. AWS relieves customer burden of operating controls
by managing those controls associated with the physical infrastructure
deployed in the AWS environment. Every customer is deployed differently in
AWS; customers can take advantage of shifting management of certain IT
controls to AWS which results in a (new) distributed control environment. AWS
control and compliance documentation is available (described in the AWS
Certifications and Third‐party Attestations) to perform their control evaluation
and verification procedures as required. It should be noted that the customer,
not AWS, is responsible for the overall design and implementation of a
reasonable and appropriate controls environment.
From AWS’ whitepaper: ―AWS provides a wide range of information regarding
its IT control environment through white papers, reports, certifications, and
other third‐party attestations. This assists customers in understanding the
controls in place relevant to the AWS services they use and how those controls
have been validated. This information also assists customers in their efforts to
account for and to validate that controls in their extended IT environment are
operating effectively.‖

© 2014 All Rights Reserved | ecfirst

7

An ecfirst Case Study: AWS & HIPAA Compliance

Note in the paragraph above that AWS assists customers in their ―extended IT
environment.‖ The ultimate responsibility for insuring compliance, even within
the AWS environment, is on customer.
Per the AWS BAA, ―You are responsible for implementing appropriate privacy
and security safeguards in order to protect your PHI in compliance with HIPAA
and this Addendum. Without limitation, you will CI) not include protected health
information (as defined in 45 CFR 160.103) in any Services that are not HiPAA
Eligible Services, (ii) utilize the highest level of audit logging in connection with
your use of all HIPAA Eligible Services, and (iii) maintain the maximum
retention of logs in connection with your use of all HIPAA Eligible Services.‖

Encryption
Just as all data is not equal in protection needed, all AWS data storage is not
equal. Two storage facilities are offered: EC2 (Elastic Compute Cloud) and S3
(Simple Storage Service). The customer must know the difference. To further
complicate matters the two can be used in combination with each other. Per
AWS BAA, ―You must encrypt all PHI stored In or transmitted using the
Services in accordance with the Secretary of HHSs Guidance to Render
Unsecured Protected Health.‖
EC2. The same data encryption mechanisms used in in-house computing
environments and operational systems can be used in EC2. The customer has
full root access and administrative control over the virtual server. It is possible
to create an encrypted Elastic Block Store (EBS) volume and attach it to EC2
instances. Data on the volume, disk I/O, and snapshots created from the
volume are all encrypted. The encryption occurs on the servers that host the
EC2 instances, providing encryption for data as it moves between EC2
instances and EBS storage.
A complete firewall solution can be created utilizing EC2’s default deny-all
mode, which automatically denies all inbound traffic unless the customer
explicitly opens an EC2 port.
S3. You, as the customer, can encrypt data on the client side and upload the
encrypted data to S3. In this case, you manage encryption process, the
encryption keys, and related tools. Optionally, you can use the server-side
encryption feature in which S3 encrypts your object data before saving it on
disks in the AWS data centers and decrypts it when you download the objects,
freeing you from the tasks of managing encryption, encryption keys, and
related tools. You can also use your own encryption keys with S3 server-side
encryption. AWS recommends S3 be encrypted prior to transmission. AWS

© 2014 All Rights Reserved | ecfirst

8

An ecfirst Case Study: AWS & HIPAA Compliance

recommends against putting any PHI or other sensitive data in S3 storage. S3
can be accessed via encrypted endpoints over the Internet and from within
Amazon EC2. One good practice is to use HTTPS whenever possible to
protect your data in transit.

AWS Access to Client EPHI
EC2. From the AWS Whitepaper, ―AWS employees do not look at customer
data, do not have access to customer EC2 instances, and cannot log into the
operating system. AWS internal security controls limit data access.‖
S3. From the AWS Whitepaper, ―For Amazon S3, AWS employees’ access to
customer data is highly restricted and not necessary for customer support or
maintenance. Despite these internal AWS controls, AWS strongly suggest that
customers encrypt all sensitive data.‖
Amazon’s answers above, while similar are not the same. When customers
read between the lines, the difference between the statements ―do not have
access‖ (EC2) and ―highly restricted‖ (S3) speaks volumes. And despite
Amazon’s recommendation to not place sensitive data in S3, some customers
do utilize third party products, such as TwinStrata (http://www.twinstrata.com/)
to do just that in a secure fashion. As noted earlier, where Amazon may not
have answers, tools, or solutions, a wide selection of third party products often
fills in many gaps. The need for, cost of, and proper implementation of such
products must be accounted for in building a compliant solution.

Contingency Planning
Disaster recovery is typically one of the more expensive HIPAA requirements to
comply with. It involves maintaining highly available systems, keeping both the
data and system replicated off-site, and enabling continuous access to both
environments.
EC2. From the AWS Whitepaper ―As a virtual server environment,
administrators can start instances very quickly. An elastic IP address (a static
IP address for the cloud computing environment) offers seamless failure from
one machine to another. EC2 offers Availability Zones. Administrators can
launch Amazon EC2 instances in multiple Availability Zones to create
geographically diverse, fault-tolerant systems that are highly resilient in the
event of network failures, natural disasters, and most other probable sources of
downtime.‖
These are wonderful features; however, realize each feature may have a
separate cost associated with it.

© 2014 All Rights Reserved | ecfirst

9

An ecfirst Case Study: AWS & HIPAA Compliance

S3. From the AWS Whitepaper, ―Data is replicated and automatically stored in
separate data centers to provide reliable data storage with a service level of
99.9% availability and no single points of failure.‖
Notice, the word was ―data‖, not ―systems‖, ―applications‖, etc. S3 is raw data
storage. You as the customer will have to handle applications on your own.

Auditing
From the AWS Whitepaper, ―HIPAA’s Security Rule also requires in-depth
auditing capabilities. The services in AWS contain many features that help
customers address these requirements.‖
Again, Amazon clearly states that it helps customers meet their compliance
requirements. Although AWS continues to tout the ―Shared Responsibility
Model‖ and gently state where the ultimate responsibility lies, it is clear that
Amazon puts the sole end responsibility about compliance on customers,
which, per compliance standards, is right where that responsibility lies in this
type of arrangement. AWS provides the world-class infrastructure and tools;
the design, implementation, management, and auditing for compliance is solely
the HCE’s or BA’s responsibility. AWS does provide some guidance in this
respect, ―Auditing Security Checklist for Use of AWS‖

Business Associate Agreement
AWS has an impressive set of attestations for its implementation and controls
in providing world-class virtual infrastructure and in providing that assistance.
Again, this is a small part in the overall compliance realm. AWS provides the
building blocks for customers to create secure and compliant solutions. AWS
does not assume responsibility in any way—shared or otherwise—for the
HCE’s or BA’s regulatory compliance. Most HCEs and BAs have their own BAA
that include significant obligations for their service providers, however AWS
requires customers sign the AWS BAA without revision. Only you can
determine if AWS BAA is reasonable and appropriate for your entity.

© 2014 All Rights Reserved | ecfirst

10

An ecfirst Case Study: AWS & HIPAA Compliance

AWS HIPAA Compliance Detail
Business Associate Contracts and Other Arrangements 164.308(b)(1) §
164.314(a)(1)
AWS enables covered entities and their business associates subject to the
U.S. Health Insurance Portability and Accountability Act (HIPAA) to
leverage the secure AWS environment to process, maintain, and store
protected health information and AWS will be signing Business Associate
Agreements with such customers.
Covered entities and their business associates subject to HIPAA and HITECH
can utilize the secure, scalable, low-cost, IT infrastructure provided by Amazon
Web Services (AWS) as part of building applications designed to promote
compliance with HIPAA and HITECH. AWS offers a complete set of
infrastructure and application services that enable businesses to deploy
applications and services cost-effectively and with flexibility, scalability, and
reliability.

AWS IT Control Information
WS provides IT control information to customers in the following two ways:
1.

Specific control definition. AWS customers are able to identify key
controls managed by AWS. Key controls are critical to the customer’s
control environment and require an external attestation of the operating
effectiveness of these key controls in order to comply with compliance
requirements such as the annual financial audit. For this purpose, AWS
publishes a wide range of specific IT controls in its Service Organization
Controls 1 (SOC 1) Type II report. The SOC 1 report, formerly the
Statement on Auditing Standards (SAS) No. 70, Service Organizations
report and commonly referred to as the Statement on Standards for
Attestation Engagements No. 16 (SSAE 16) report, is a widely
recognized auditing standard developed by the American Institute of
Certified Public Accountants (AICPA). The SOC 1 audit is an in-depth
audit of both the design and operating effectiveness of AWS’s defined
control objectives and control activities (which include control objectives
and control activities over the part of the infrastructure AWS manages).
―Type II‖ refers to the fact that each of the controls described in the
report are not only evaluated for adequacy of design, but are also
tested for operating effectiveness by the external auditor. Because of
the independence and competence of AWS’s external auditor, controls
identified in the report should provide customers with a high level of
confidence in AWS’s control environment. AWS’s controls can be
considered designed and operating effectively for many compliance
purposes, including Sarbanes Oxley (SOX) Section 404 financial
statement audits. Leveraging SOC 1 Type II reports is also generally

© 2014 All Rights Reserved | ecfirst

11

An ecfirst Case Study: AWS & HIPAA Compliance

permitted by other external certifying bodies (e.g., ISO 27001 auditors
may request a SOC 1Type II report in order to complete their
evaluations for customers).
Other specific control activities relate to AWS’s Payment Card Industry
(PCI) and Federal Information Security Management Act (FISMA)
compliance. As discussed below, AWS is compliant with FISMA
Moderate standards and with the PCI Data Security Standard. These
PCI and FISMA standards are very prescriptive and require
independent validation that AWS adheres to the published standard.
2.

General control standard compliance. If an AWS customer requires a
broad set of control objectives to be met, evaluation of AWS’s industry
certifications may be performed. With the AWS ISO 27001 certification,
AWS complies with a broad, comprehensive security standard and
follows best practices in maintaining a secure environment. With the
PCI Data Security Standard (PCI DSS), AWS complies with a set of
controls important to companies that handle credit card information.
With AWS’s compliance with the FISMA standards, AWS complies with
a wide range of specific controls required by US government agencies.
Compliance with these general standards provides customers with in‐
depth information on the comprehensive nature of the controls and
security processes in place and can be considered when managing
compliance.

AWS Global Regions
Data centers are built in clusters in various global regions. As of this writing,
there are nine regions: US East (Northern Virginia), US West (Oregon), US
West (Northern California), AWS GovCloud (US) (Oregon), EU (Ireland), Asia
Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific (Sydney), and South
America (Sao Paulo).

AWS Risk & Compliance Program
Risk Management
Risk Management (R) § 164.308(a)(1)(ii)(B)
AWS management has developed a strategic business plan which includes risk
identification and the implementation of controls to mitigate or manage risks.
AWS management re‐evaluates the strategic business plan at least biannually.
This process requires management to identify risks within its areas of
responsibility and to implement appropriate measures designed to address
those risks.

© 2014 All Rights Reserved | ecfirst

12

An ecfirst Case Study: AWS & HIPAA Compliance

In addition, the AWS control environment is subject to various internal and
external risk assessments. AWS’s Compliance and Security teams have
established an information security framework and policies based on the
Control Objectives for Information and related Technology (COBIT) framework
and have effectively integrated the ISO 27001 certifiable framework based on
ISO 27002 controls, American Institute of Certified Public Accountants (AICPA)
Trust Services Principles, the PCI DSS v2.0, and the National Institute of
Standards and Technology (NIST) Publication 800‐53 Rev 3 (Recommended
Security Controls for Federal Information Systems). AWS maintains the
security policy, provides security training to employees, and performs
application security reviews. These reviews assess the confidentiality, integrity,
and availability of data, as well as conformance to the information security
policy.
AWS Security regularly scans all Internet facing service endpoint IP addresses
for vulnerabilities (these scans do not include customer instances). AWS
Security notifies the appropriate parties to remediate any identified
vulnerabilities. In addition, external vulnerability threat assessments are
performed regularly by independent security firms. Findings and
recommendations resulting from these assessments are categorized and
delivered to AWS leadership. These scans are done in a manner for the health
and viability of the underlying AWS infrastructure and are not meant to replace
the customer’s own vulnerability scans required to meet their specific
compliance requirements. Customers can request permission to conduct scans
of their cloud infrastructure as long as they are limited to the customer’s
instances and do not violate the AWS Acceptable Use Policy.
Advance approval for these types of scans can be initiated by submitting a requ
est via the AWS Vulnerability / Penetration Testing Request Form.

Auditing Use of AWS Concepts
Audit Controls § 164.312(b)
The following concepts should be considered during a security audit of an
organization’s systems and data on AWS:
1.

Understand the AWS ―Shared Responsibility‖ model - To effectively
evaluate assets residing in AWS, customers should understand which
categories of assets they control versus which categories of assets
AWS controls.
o

AWS provides a secure global infrastructure and services for which
AWS operates, manages, and controls the components from the

© 2014 All Rights Reserved | ecfirst

13

An ecfirst Case Study: AWS & HIPAA Compliance

host operating system and virtualization layer down to the physical
security of the facilities in which the services operate. These parts
of the system can be validated by the customer through the AWS
certifications and reports (e.g., Service Organization Control (SOC)
reports, ISO 27001 certification, PCI assessments, etc.). The
applicable AWS compliance certifications and reports can be
requested at https://aws.amazon.com/compliance/contact/.
o

2.

Customers are responsible for the security of anything their
organization puts on their AWS assets or connect to their AWS
assets, such as the guest operating system and applications on
their virtual machine instance, the data and objects in their S3
buckets or RDS database, etc.

Define the organization’s AWS assets - A customer’s AWS assets can
be instances, data stores, applications, the data itself, etc. Auditing the
use of AWS usually starts with asset identification. Assets on a public
cloud infrastructure are not categorically different than in-house
environments, and in some situations can be less complicated to

© 2014 All Rights Reserved | ecfirst

14

An ecfirst Case Study: AWS & HIPAA Compliance

inventory because AWS provides visibility into the assets under
management.
3.

Manage security holistically - The AWS infrastructure should be an
integral part of an organization’s information security management
program. Security control objectives should remain consistent
regardless of where the systems and data reside, however, controls
and audit plans can be modified according to the guidelines in this
paper.

© 2014 All Rights Reserved | ecfirst

15

An ecfirst Case Study: AWS & HIPAA Compliance

Features of AWS for Clients

Manage IT Security
Manage IT Assets
Using AWS, there are multiple features available for you to quickly and easily
obtain an accurate inventory of your AWS IT resources.
o

Account Activity page

o

Amazon Glacier vault inventory

o

AWS CloudHSM

o

AWS Data Pipeline Task Runner

o

AWS Management Console

o

AWS Storage Gateway APIs

Control IT Costs
Using AWS, there are multiple features available for you to easily and
accurately understand and control your IT resource costs.
o

Account Activity page

o

Amazon EC2 idempotency instance launch

o

Amazon EC2 resource tagging

o

AWS Account Billing

o

AWS Management console

o

AWS service pricing

o

AWS Trusted Advisor

o

Billing Alarms

o

Consolidated billing

Manage IT Security
Using AWS, you can easily and effectively outsource controls related to
physical security of your AWS infrastructure to AWS specialists with the skillsets and resources needed to secure the physical environment. AWS has
multiple different, independent auditors validate the data center physical
security throughout the year, attesting to the design and detailed testing of the
effectiveness of our physical security controls.
o

AWS SOC1 physical access control

o

AWS SOC2 security physical access controls

o

AWS PCI DSS physical access controls

o

AWS ISO 27001 physical access controls

© 2014 All Rights Reserved | ecfirst

16

An ecfirst Case Study: AWS & HIPAA Compliance

o

AWS FedRAMP physical access controls

Control Logical access to IT Resources
There are multiple control features AWS offers you effectively manage your
logical access based on a matrix of use cases anchored in least-privilege.
o

Amazon S3 Access Control Lists (ACLs)

o

Amazon S3 Bucket Policies

o

Amazon S3 Query String Authentication

o

AWS IAM Multi-factor Authentication (MFA)

o

AWS IAM password-policy

o

AWS IAM Permissions

o

AWS IAM Policies

o

AWS Trusted Advisor

Secure IT Resources
AWS provides multiple security features that enable you to easily and
effectively secure your IT resources.
o

Amazon Linux AMIs

o

Amazon EC2 Dedicated instances

o

Amazon EC2 instance launch wizard

o

Amazon EC2 security groups

o

Amazon Glacier archives

o

Amazon S3 Client-side Encryption

o

Amazon S3 Server-side Encryption

o

Amazon VPC

o

Amazon VPC Logical isolation

o

Amazon VPC network ACLs

o

Amazon VCP private IP addresses

o

Amazon VCP security groups

o

AWS CloudFormation templates

o

AWS Direct Connect

o

On-premise hardware/software VPN connections

Manage Logging around IT resources
Using AWS, there are multiple logging features that enable you to effectively
log and track the use of your IT resources.

© 2014 All Rights Reserved | ecfirst

17

An ecfirst Case Study: AWS & HIPAA Compliance

o

Amazon CloudFront access logs

o

Amazon RDS database logs

o

Amazon S3 Object Expiration

o

Amazon S3 server access logs

o

AWS CloudTrail

Manage IT Performance
Monitor and respond to events
Using AWS, there are multiple monitoring features that enable you to easily
and effectively monitor and manage your IT resources.
o

Amazon CloudWatch

o

Amazon CloudWatch alarms

o

Amazon EC2 instance status

o

Amazon Incident Management Team

o

Amazon S3 TCP selective acknowledgment

o

Amazon Simple Notification Service

o

AWS Elastic Beanstalk

o

Elastic Load Balancing

Achieve Resiliency
Cloud computing’s server virtualization enables the quality resiliency programs
to be feasible and cost-effective. Using AWS, there are multiple features that
enable you to easily and effectively achieve resiliency for your IT resources.
o

Amazon EBS snapshots

o

Amazon RDS Multi-AZ deployment

o

AWS Import/Export

o

AWS Storage Gateway

o

AWS Trusted Advisor

o

Extensive 3rd Party Solutions

o

Managed AWS No-SQL/SQL Database Services

o

Multi-region deployment

o

Route 53 health checks and DNS failover

Creating HIPAA Compliant Medical Data Applications with AWS

© 2014 All Rights Reserved | ecfirst

18

An ecfirst Case Study: AWS & HIPAA Compliance

Healthcare businesses subject to HIPAA can utilize the secure, scalable, lowcost, IT infrastructure provided by Amazon Web Services (AWS) as part of
building HIPAA compliant applications.
Amazon Elastic Compute Cloud (Amazon EC2) provides resizable compute
capacity in the cloud.
Amazon Simple Storage Service (Amazon S3) provides a virtually unlimited
cloud-based data object store.

Methodology
Security Controls: Encrypting Data in the Cloud
Encryption and Decryption (A) - § 164.312(a)(2)(iv)
Encryption (A) § 164.312(e)(2)(ii)
•

Encryption of PHI in transmission (―in-flight‖) and in storage (―at-rest‖)
can be accomplished in a virtual computing environment such as
Amazon EC2 and Amazon S3.

•

Amazon EC2 provides the customer with full root access and
administrative control over virtual servers.

•

Using AWS, customer’s system administrators can utilize token or keybased authentication to access their virtual servers. Amazon EC2
creates a 2048-bit RSA key pair, with private and public keys and a
unique identifier for each key pair to help facilitate secure access.
Administrators also can utilize a command-line shell interface, Secure
Shell (SSH) keys, or sudo to enable additional security and privilege
escalation.

•

A complete firewall solution can be created in the cloud by utilizing
Amazon EC2’s default deny-all mode, which automatically denies all
inbound traffic unless the customer explicitly opens an EC2 port.
Administrators can create multiple security groups to enforce different
ingress policies as needed. They can control each security group with
a PEM- encoded X.509 certificate and restrict traffic to each EC2
instance by protocol, service port, or source IP address.

•

Amazon S3 can be accessed via Secure Socket Layer (SSL)encrypted endpoints over the Internet and from within Amazon EC2.
This ensures that PHI and other sensitive data remain highly secure

Security Controls: High-Level Data Protection
Access Authorization (A) § 164.308(a)(4)(ii)(B)

© 2014 All Rights Reserved | ecfirst

19

An ecfirst Case Study: AWS & HIPAA Compliance

Person or Entity Authentication § 164.312(d)
•

For Amazon EC2, AWS employees do not look at customer data, do
not have access to customer EC2 instances, and cannot log into the
guest operating system. AWS internal security controls limit data
access

•

For Amazon S3, AWS employees’ access to customer data is highly
restricted and not necessary for customer support or maintenance.
Despite these internal AWS controls, we strongly suggest that
customers encrypt all sensitive data.

Access Control Processes
Access Authorization (A) § 164.308(a)(4)(ii)(B)
Person or Entity Authentication § 164.312(d)
•

Using Amazon EC2, SSH network protocols can be used to
authenticate remote users or computers through public-key
cryptography.

•

The administrator can also allow or block access at the account or
instance level and can set security groups, which restrict network
access from instances not residing in that same group.

•

In Amazon S3, the system administrator maintains full control over who
has access to the data at all times and the default setting only permits
authenticated access to the creator. Read, write and delete
permissions are controlled by an Access Control List (ACL) associated
with each object.

© 2014 All Rights Reserved | ecfirst

20

An ecfirst Case Study: AWS & HIPAA Compliance

Auditing, Back-Ups, & Disaster Recovery
Information System Activity Review (R) § 164.308(a)(1)(ii)(D)
Audit Controls § 164.312(b)
•

Using Amazon EC2, customers can run activity log files and audits
down to the packet layer on their virtual servers. They also can track
any IP traffic that reaches their virtual server instance.

Data Backup Plan (R) § 164.308(a)(7)(ii)(A)
•

Customer’s administrators can back up the log files into Amazon S3
for long-term, reliable storage.

•

To implement a data back-up plan on AWS, Amazon Elastic Block
Store (EBS) offers persistent storage for Amazon EC2 virtual server
instances. Customers can create point-in-time snapshots of EBS
volumes that automatically are stored in Amazon S3 and are
replicated across multiple Availability Zones, which are distinct
locations engineered to be insulated from failures in other zones
(Availability Zones). These snapshots can be accessed at any time
and can protect data for long-term durability.

•

Amazon S3 also provides a highly available solution for data storage
and automated back-ups. By loading a file or image into Amazon S3,
multiple redundant copies are automatically created and stored in
separate data centers. These files can be accessed at any time, from
anywhere (based on permissions) and are stored until intentionally
deleted by the customer’s system administrator.

Disaster Recovery Plan (R) § 164.308(a)(7)(ii)(B)
•

With Amazon EC2, administrators can start server instances very
quickly and can use an Elastic IP address (a static IP address for the
cloud computing environment) for elegant failure from one machine to
another.

•

Amazon EC2 also offers Availability Zones. Administrators can launch
Amazon EC2 instances in multiple Availability Zones to create
geographically diverse, fault tolerant systems that are highly resilient
in the event of network failures, natural disasters, and most other
probable sources of downtime.

•

Using Amazon S3, a customer’s data is replicated and automatically
stored in separate data centers to provide reliable data storage with a
service level of 99.9% availability and no single points of failure.

Physical and Environmental Security
Facility Access Controls § 164.310(a)(1)

© 2014 All Rights Reserved | ecfirst

21

An ecfirst Case Study: AWS & HIPAA Compliance

AWS data centers are housed in nondescript facilities. Physical access is
strictly controlled both at the perimeter and at building ingress points by
professional security staff utilizing video surveillance, intrusion detection
systems, and other electronic means. Authorized staff must pass two-factor
authentication a minimum of two times to access data center floors. All visitors
and contractors are required to present identification and are signed in and
continually escorted by authorized staff.
AWS only provides data center access and information to employees and
contractors who have a legitimate business need for such privileges. When an
employee no longer has a business need for these privileges, his or her access
is immediately revoked, even if they continue to be an employee of Amazon or
Amazon Web Services. All physical access to data centers by AWS employees
is logged and audited routinely.

Fire Detection and Suppression
Automatic fire detection and suppression equipment has been installed to
reduce risk. The fire detection system utilizes smoke detection sensors in all
data center environments, mechanical and electrical infrastructure spaces,
chiller rooms and generator equipment rooms. These areas are protected by
either wet-pipe, double-interlocked pre-action, or gaseous sprinkler systems.
Power
The data center electrical power systems are designed to be fully redundant
and maintainable without impact to operations, 24 hours a day, and seven days
a week. Uninterruptible Power Supply (UPS) units provide back-up power in
the event of an electrical failure for critical and essential loads in the facility.
Data centers use generators to provide back-up power for the entire facility.
Climate and Temperature
Climate control is required to maintain a constant operating temperature for
servers and other hardware, which prevents overheating and reduces the
possibility of service outages. Data centers are conditioned to maintain
atmospheric conditions at optimal levels. Personnel and systems monitor and
control temperature and humidity at appropriate levels.

© 2014 All Rights Reserved | ecfirst

22

An ecfirst Case Study: AWS & HIPAA Compliance

Business Continuity Management
Emergency Mode Operations Plan (R) § 164.308(a)(7)(ii)(C)
Amazon’s infrastructure has a high level of availability and provides customers
the features to deploy a resilient IT architecture. AWS has designed its systems
to tolerate system or hardware failures with minimal customer impact. Data
center Business Continuity Management at AWS is under the direction of the
Amazon Infrastructure Group
Availability
Data centers are built in clusters in various global regions. All data centers are
online and serving customers; no data center is ―cold.‖ In case of failure,
automated processes move customer data traffic away from the affected area.
Core applications are deployed in an N+1 configuration, so that in the event of
a data center failure, there is sufficient capacity to enable traffic to be loadbalanced to the remaining sites.
AWS provides customers with the flexibility to place instances and store data
within multiple geographic regions as well as across multiple availability zones
within each region. Each availability zone is designed as an independent failure
zone. This means that availability zones are physically separated within a
typical metropolitan region and are located in lower risk flood plains (specific
flood zone categorization varies by Region). In addition to discrete
uninterruptable power supply (UPS) and onsite backup generation facilities,
they are each fed via different grids from independent utilities to further reduce
single points of failure. Availability zones are all redundantly connected to
multiple tier-1 transit providers.
Customers should architect AWS usage to take advantage of multiple regions
and availability zones. Distributing applications across multiple availability
zones provides the ability to remain resilient in the face of most failure modes,
including natural disasters or system failures.
Incident Response
Security Incident Procedures § 164.308(a)(6)
The Amazon Incident Management team employs industry-standard diagnostic
procedures to drive resolution during business-impacting events. Staff
operators provide 24x7x365 coverage to detect incidents and to manage the
impact and resolution.

© 2014 All Rights Reserved | ecfirst

23

An ecfirst Case Study: AWS & HIPAA Compliance

Network Security
The AWS network has been architected to permit customers to select the level
of security and resiliency appropriate for their workload. To enable customers
to build geographically dispersed, fault-tolerant web architectures with cloud
resources, AWS has implemented a world-class network infrastructure that is
carefully monitored and managed
Secure Network Architecture
Protections of Malicious Software (A) § 164.308(a)(5)(ii)(B)
Access Control § 164.312(a)(1)
Network devices, including firewall and other boundary devices, are in place to
monitor and control communications at the external boundary of the network
and at key internal boundaries within the network. These boundary devices
employ rule sets, access control lists (ACL), and configurations to enforce the
flow of information to specific information system services.
ACLs, or traffic flow policies, are established on each managed interface, which
manage and enforce the flow of traffic. ACL policies are approved by Amazon
Information Security. These policies are automatically pushed using AWS’s
ACL-Manage tool, to help ensure these managed interfaces enforce the most
up-to-date ACLs.
Secure Access Points
Access Control § 164.312(a)(1)
AWS has strategically placed a limited number of access points to the cloud to
allow for a more comprehensive monitoring of inbound and outbound
communications and network traffic. These customer access points are called
API endpoints, and they allow secure HTTP access (HTTPS), which allows
customers to establish a secure communication session with their storage or
compute instances within AWS. To support customers with FIPS 140-2
requirements, the Amazon Virtual Private Cloud VPN endpoints and SSLterminating load balancers in AWS GovCloud (US) operate using FIPS 140-2
level 2-validated hardware.
In addition, AWS has implemented network devices that are dedicated to
managing interfacing communications with Internet service providers (ISPs).
AWS employs a redundant connection to more than one communication
service at each Internet-facing edge of the AWS network. These connections
each have dedicated network devices.

© 2014 All Rights Reserved | ecfirst

24

An ecfirst Case Study: AWS & HIPAA Compliance

Transmission Protection
Transmission Security § 164.312(e)(1)
Customers can connect to an AWS access point via HTTP or HTTPS using
Secure Sockets Layer (SSL), a cryptographic protocol that is designed to
protect against eavesdropping, tampering, and message forgery.
For customers who require additional layers of network security, AWS offers
the Amazon Virtual Private Cloud (VPC), which provides a private subnet within
the AWS cloud, and the ability to use an IPsec Virtual Private Network (VPN)
device to provide an encrypted tunnel between the Amazon VPC and data
center.
Amazon Corporate Segregation
Access Control § 164.312(a)(1
Logically, the AWS Production network is segregated from the Amazon
Corporate network by means of a complex set of network security / segregation
devices. AWS developers and administrators on the corporate network who
need to access AWS cloud components in order to maintain them must
explicitly request access through the AWS ticketing system. All requests are
reviewed and approved by the applicable service owner.
Approved AWS personnel then connect to the AWS network through a bastion
host that restricts access to network devices and other cloud components,
logging all activity for security review. Access to bastion hosts require SSH
public-key authentication for all user accounts on the host.
Fault-Tolerant Design
Contingency Plan § 164.308(a)(7)
Amazon’s infrastructure has a high level of availability and provides customers
with the capability to deploy a resilient IT architecture. AWS has designed its
systems to tolerate system or hardware failures with minimal customer impact.
Network Monitoring and Protection
Information System Activity Review (R) § 164.308(a)(1)(ii)(D)
AWS utilizes a wide variety of automated monitoring systems to provide a high
level of service performance and availability. AWS monitoring tools are
designed to detect unusual or unauthorized activities and conditions at ingress
and egress communication points. These tools monitor server and network
© 2014 All Rights Reserved | ecfirst

25

An ecfirst Case Study: AWS & HIPAA Compliance

usage, port scanning activities, application usage, and unauthorized intrusion
attempts. The tools have the ability to set custom performance metrics
thresholds for unusual activity.
Systems within AWS are extensively instrumented to monitor key operational
metrics. Alarms are configured to automatically notify operations and
management personnel when early warning thresholds are crossed on key
operational metrics. An on-call schedule is used so personnel are always
available to respond to operational issues. This includes a pager system so
alarms are quickly and reliably communicated to operations personnel.
AWS Security Updates
As on April 16, 2014, AWS has reviewed all of their services for impact for the
issue described in CVE-2014-0160 (also known as the Heartbleed bug). With
the exception of the services listed below, they have either determined that the
services were unaffected or have been able to apply mitigations that do not
require customer action.
Elastic Load Balancing: AWS has confirmed that all load balancers affected
by the issue described in CVE-2014-0160 have now been updated in all
Regions. If customers are terminates their SSL connections on their Elastic
Load Balancer, they are no longer vulnerable to the Heartbleed bug.
Amazon EC2: Customers using OpenSSL on their own Linux images should
update their images in order to protect themselves from the Heart bleed bug
described in CVE-2014-0160.
AWS OpsWorks: To update OpsWorks-managed instances, run the
update_dependencies command for each of stacks to pick up the latest
OpenSSL packages for Ubuntu and Amazon Linux. Newly created OpsWorks
instances will install all security updates at boot by default.
AWS Elastic Beanstalk: We are working with a small number of customers to
assist them in updating their SSL enabled Single Instance Environments that
are affected by this bug.
Amazon CloudFront: AWS have mitigated this issue

© 2014 All Rights Reserved | ecfirst

26

An ecfirst Case Study: AWS & HIPAA Compliance

AWS Access
Access Control § 164.312(a)(1)
The AWS Production network is segregated from the Amazon Corporate
network and requires a separate set of credentials for logical access. The
Amazon Corporate network relies on user IDs, passwords, and Kerberos, while
the AWS Production network requires SSH public-key authentication through a
bastion host.
AWS developers and administrators on the Amazon Corporate network who
need to access AWS cloud components must explicitly request access through
the AWS access management system. All requests are reviewed and approved
by the appropriate owner or manager.

Account Review and Audit
Access Establishment and Modification (A) § 164.308(a)(4)(ii)(C)
Accounts are reviewed every 90 days; explicit re-approval is required or access
to the resource is automatically revoked. Access is also automatically revoked
when an employee’s record is terminated in Amazon’s Human Resources
system. Windows and UNIX accounts are disabled and Amazon’s permission
management system removes the user from all systems.
Requests for changes in access are captured in the Amazon permissions
management tool audit log. When changes in an employee’s job function
occur, continued access must be explicitly approved to the resource or it will be
automatically revoked.
Background Checks
Workforce Clearance Procedures (A) § 164.308(a)(3)(ii)(B)
AWS has established formal policies and procedures to delineate the minimum
standards for logical access to AWS platform and infrastructure hosts. AWS
conducts criminal background checks, as permitted by law, as part of preemployment screening practices for employees and commensurate with the
employee’s position and level of access. The policies also identify functional
responsibilities for the administration of logical access and security.
Credentials Policy

© 2014 All Rights Reserved | ecfirst

27

An ecfirst Case Study: AWS & HIPAA Compliance

Password Management § 164.308(a)(5)(ii)(D)
AWS Security has established a credentials policy with required configurations
and expiration intervals. Passwords must be complex and are forced to be
changed every 90 days.
Secure Design Principles
AWS’s development process follows secure software development best
practices, which include formal design reviews by the AWS Security Team,
threat modeling, and completion of a risk assessment. Static code analysis
tools are run as a part of the standard build process, and all deployed software
undergoes recurring penetration testing performed by carefully selected
industry experts. AWS’s security risk assessment reviews begin during the
design phase and the engagement lasts through launch to ongoing operations.
Change Management
Routine, emergency, and configuration changes to existing AWS infrastructure
are authorized, logged, tested, approved, and documented in accordance with
industry norms for similar systems. Updates to AWS’s infrastructure are done
to minimize any impact on the customer and their use of the services. AWS will
communicate with customers, either via email, or through the AWS Service
Health Dashboard (http://status.aws.amazon.com/) when service use is likely to
be adversely affected.

© 2014 All Rights Reserved | ecfirst

28

An ecfirst Case Study: AWS & HIPAA Compliance

BIBLIOGRAPHY
Note – The Information in the White Papers below, even those recently done,
may no longer be accurate. Changes to the AWS environment are constant,
some as recent as 30 days within the publication of this report are included
above. Also, Amazon has chosen not to reveal publicly certain information,
such as their BAA template.
1.
2.
3.
4.
5.
6.

AWS: Compliance Web Page
AWS: Overview of Security Processes, November 2014
AWS: Securing Data at Rest with Encryption, November 2013
AWS: Risk and Compliance Whitepaper, November 2013
AWS: Auditing Security Checklist for Use of AWS, June 2013
Amazon Web Services: Creating Healthcare Data Applications to Promote
HIPAA and HITECH Compliance, August 2012

Corporate Office
295 NE Venture Drive
Waukee, IA 50263
Toll Free: 877.899.9974 x17
Phone: 515.987.4044 x17
Fax: 515.978.2323
www.ecfirst.com

© 2014 All Rights Reserved | ecfirst

29