(hls401) architecting for hipaa compliance on aws | aws re:invent 2014

November 12, 2014 | Las Vegas, NV

HLS401

Architecting for HIPAA Compliance on AWS

Bill Shinn, AWS Dan Stover, Emdeon Jason McKay, LogicWorks

Frank Macreery, Aptible

AWS HIPAA ProgramAligning services and workloads to the HIPAA Security Rule

Bill Shinn, AWS Principal Security Solutions Architect

AWS HIPAA Program

Strong presence in healthcare and life

sciences from our roots

Business Associates & January, 2013

Omnibus Final Rule

Starting signing Business Associate

Agreements (BAA) in Q2 2013

Program is based on Shared Security

Responsibility Model

AWS HIPAA Program is aligned to

NIST 800-53 & FedRAMP

Authorizations

Alignment to HIPAA Security Rule

HIPAA Security Rule(45 CFR Part 160 and Subparts

A and C of Part 164)

NIST 800-66An Introductory Resource Guide

for Implementing the Health

Insurance Portability and

Accountability Act (HIPAA)

Security Rule

NIST 800-53 Moderate baseline + FedRAMP

Controls

AWS HIPAA Eligible Services

Customer may use all services within a “HIPAA Account”

Customers may process, store, or transmit ePHI using only Eligible

Services

Amazon EC2Elastic Load

Balancing

(TCP mode only)

Amazon S3Amazon EBS Amazon Glacier Amazon Redshift

AWS HIPAA configuration requirements

Customers must encrypt ePHI in transit and at rest

Customers must use EC2 Dedicated Instances for instances processing,

storing, or transmitting ePHI

Customers must record and retain activity related to use of and access to

ePHI

Office of Civil Rights Audit Protocol & Shared Security

Responsibility

Section

Established

Performance

Criteria Key ActivityCustomer

ResponsibilityAWS

Responsibility

AWS

Certification

Reference Additional Guidance

¤164.312(b):

Audit controls-

Implement

hardware,

software, and/or

procedural

mechanisms that

record and

examine activity

in information

systems that

contain or use

electronic

protected health

information.

Determine the

Activities that

Will be Tracked

or Audited

Inquire of management

as to whether audit

controls have been

implemented over

information systems

that contain or use

ePHI.

Obtain and review

documentation relative

to the specified criteria

to determine whether

audit controls have

been implemented

over … Yes Yes

NIST 800-53

AU-1, AU-2, AU-

3,

AU-4, AU-6, AU-

7

Customers processing, storing

or transmitting ePHI in AWS

must utilize a level of audit

logging sufficient to record all

activity related to use of and

access to protected health

information.

When using services such as

Amazon S3 or Amazon

Redshift, customers should

evaluate native logging

features such as Amazon S3

bucket logging to determine

how these features may assist

in meeting the implementation

specification.

(example – 45 CFR 164.312(b)

AWS HIPAA Web Tier Reference Architecture

VPC Public Subnet 10.40.1.0/24 VPC Public Subnet 10.40.2.0/24

AZ A AZ B

Public ELB in

TCP mode w/ Proxy Protocol

HAProxy tier – if needed, session state

managed via client-side cookie inserted by

HAProxy.

SSL termination/re-encryption. Keys stored in

Amazon S3, retrieved by AWS

CloudFormation at system launch using

entitlements of IAM role for Amazon EC2.

Support for Proxy Protocol & x-forwarded-for

HAProxy/

Public

SSL

HAProxy/

Public

SSL

HAProxy/

Public

SSL

HAProxy/

Public

SSL

Web

Server/

Private

SSL

Web

Server/

Private

SSL

Web

Server/

Private

SSL

Web

Server/

Private

SSL

VPC Private Subnet 10.40.3.0/24 VPC Private Subnet 10.40.4.0/24

HAProxy tier performs backend encryption

between HAProxy nodes and Web nodes.

Keys stored in Amazon S3, retrieved by AWS

CloudFormation at system launch using

entitlements of IAM role for Amazon EC2.

SG: WebSecurityGroup

SG: ELBSecurityGroup

SG: HAProxySecurityGroup

EmdeonA case study of automation and change management

Dan Stover, Emdeon

Emdeon on AWS

Automation and change management

Focus on the ability to make changes fearlessly

Build a culture that values experimentation and agility

Provide full auditability into the source of changes

Enable software architectures in a tangible way

Limit the ability to bypass security controls

Management VPC

Pre-Production VPC

Production VPC

Access controls (164.312(a)(1))

Template everything

CI/CD and testing

Assume roles

No human interaction with PHI

Audit controls (164.312(b))

AWS CloudTrail

High degree of transparency

Change control

Elegant patching

Integrity controls (164.312(c))

Limited production access

Debugging w/o PHI

All transactions persisted in Amazon

S3

Backup policy

Transmission security (164.312(e))

SSL everywhere with zero touch

Generate keystores

Build AMIs

Configure

passthrough

LogicWorksBuilding a cloud-based health information exchange

Jason McKay, VP of Engineering

Orion HIE overview

About LogicWorks

Existing private cloud solution

HIE project was well timed to integrate our healthcare and our AWS

focus with a good customer

Challenges

Unknown number of subscribers (had to be ready for scale).

Aggressive timelines aided by agility in AWS.

Dev/test

Day 1: Work begins on Dev/test AWS environments for HIE.

Day 1: AWS servers deployed, VPC configured, Dedicated instances used, EBS

volumes encrypted.

Day 3: Dev/test environments ready for Orion Application team. Alert Logic IDS and

Log Manager installed.

Stage/prod

Day 1: Logicworks received specs for stage/prod.

Day 2: Quote for Stage/Prod sent to Orion for review.

Day 21: Stage turned over to Orion developers.

Seized the opportunity to architect differently than we do in private cloud.

Solution

Availability enhancements (distribute app tiers across AZs)

Tools to achieve secure design (core services hub and SDLC environment spokes, VPC peering, use of

ACLs and security groups)

Encrypted EBS for PHI data

IAM roles for secure API interaction

Instances/EBS designed for performance (architecting performance for Oracle database tier)

IDS/Log analysis

AWS Cloudtrail reporting and alerting

Architecture overview

Dev DMZ Subnet

Dev Trusted Subnet

Test/Train/DemoDMZ Subnet 1

Test/Train/DemoTrusted Subnet 1

Dev Database SubnetTest/Train/Demo

Database Subnet 1

Test/Train/Demo DMZ Subnet 2

Test/Train/DemoTrusted Subnet 2

Test/Train/DemoDatabase Subnet 2

Availability Zone A Availability Zone B

StageDMZ Subnet 1

StageTrusted Subnet 1

StageDatabase Subnet 1

Stage DMZ Subnet 2

StageTrusted Subnet 2

StageDatabase Subnet 2

Availability Zone BAvailability Zone A

ProdDMZ Subnet 1

ProdTrusted Subnet 1

ProdDatabase Subnet 1

Prod DMZ Subnet 2




Prod DMZ Subnet 3



Availability Zone C

Non-Prod VPC Prod VPCStage VPC

Dev Shared DMZSubnet 1

Dev Shared InternalSubnet 1

Dev DB Subnet 1

Prod Shared DMZSubnet 1

Prod Shared InternalSubnet 1

Prod DB Subnet 1

Availability Zone A

Customer Specific Shared VPC

Dev Shared DMZSubnet 2

Dev Shared InternalSubnet 2

Dev DB Subnet 2

Prod Shared DMZSubnet 2

Prod Shared InternalSubnet 2

Prod DB Subnet 2

Availability Zone B

Prod CA DMZSubnet 1

Prod CATrusted Subnet 1

Prod CADatabase Subnet 1

Prod CA DMZ Subnet 2

Prod CATrusted Subnet 2

Prod CADatabase Subnet 2


Customer AgnosticShared Prod VPC

Stage CADMZ Subnet 1

Stage CATrusted Subnet 1

Stage CADatabase Subnet 1

Stage CA DMZ Subnet 2

Stage CATrusted Subnet 2

Stage CADatabase Subnet 2


Customer AgnosticShared Stage VPC

Non-ProdDMZ Subnet 1

Non-ProdTrusted Subnet 1

Non-ProdDatabase Subnet 1

Non-Prod DMZ Subnet 2

Non-ProdTrusted Subnet 2

Non-ProdDatabase Subnet 2


Customer AgnosticShared Non-Prod VPC

OrionDMZ Subnet 1

OrionTrusted Subnet 1

OrionDatabase Subnet 1

Orion DMZ Subnet 2

OrionTrusted Subnet 2

OrionDatabase Subnet 2


Orion Management VPC

VPC Peering Connection





VPC Peering ConnectionVPC Peering Connection


VPC Peering Connection VPC Peering Connection

Customer AWS Account

Orion AWS Account

Compliance and controls – access controls

164.312(a) Access control

Unique User Identification — SSO; MFA; actions in the console traceable through AWS

CloudTrail; utilize additional services and aggregate with log management system with

server logs; IAM for controlling access rights (clients are responsible for analyzing the

access needs of their users; enable their continued use of internal authentication

mechanisms where they’re already managing this — i.e., LDAP/AD).

Emergency Access Procedure — DR/BCP to provide continued access to ePHI; also,

resiliency in terms of having EBS snapshots, multi-AZ, and multi-region deployments.

Compliance and controls – access controls (con’t)

164.312(a) Access control

Automated logoff — for administrators connecting directly to servers already baked into the

hardened image (for the AWS console, this is handled with AD as the identity provider).

Terminating access no longer needed — handled through SSO integration with AD.

Encryption at rest — use of EBS volumes in AWS CloudFormation templates — automated

mounting of encrypted EBS volumes that store critical binaries and PHI.

Compliance and controls – audit controls

164.312(b) Audit controls — record and examine activity in systems that contain or

use ePHI

Alert Logic – use of Log Manager: on-instance deployment; roles are configured, and instances register

themselves with Alert Logic.

AWS CloudTrail use, reporting/alerts on specific types of actions. AWS Cloudtrail also logs to Alert Logic

Log Manager.

ACLs, security groups — standardized networking restrictions forcing administration through jump boxes

tracking administrators’ actions.

Automated snapshot with success/fail logging to an Amazon S3 bucket. Integrated with Amazon

CloudWatch for alerting on failed snaps.

Compliance and controls – additional controls

164.312(d) Person or Entity Authentication

MFA tokens for verification that the person connecting is the one claimed.

164.312(e) Transmission Security

Encryption — can talk about the hub-and-spoke model for the management environment for

their future growth; central location that they connect to using VPN.

Additional Application Controls

Automated updating of DNS on instance deployment replacement.

ASGs of 1/1/1 to preserve unique role in application stack while maintaining HA.

Results

Rapidly onboard new clients with minimal work.

More easily iterate on architecture and design. Continuous

improvement.

Readily reproducible in other regions as business needs dictate.

Architecting for HIPAA compliance:Dev Ops for HIPAA

Frank Macreery, Aptible

Layers of responsibility

Physical SafeguardsFacility management

Physical contingency plans

General

Technical Safeguards

Encryption

Backups

Instance access (SSH)

Application-Specific


Authentication

Access controls

PHI access logs

Physical Safeguards

General




Aptible architecture overview

+

Division of Responsibility

General




Division of responsibility

AWS CloudFormation template sets up secure network layout

Chef (OpsWorks) recipes + custom tools manage general security

functions like SSL termination, EBS volume encryption, and backups

Applications run within Docker containers and manage their own

framework-specific security/logging

General Safeguard: Unique SSH Identities

Regulatory requirement: "Assign a unique name and/or number for

identifying and tracking user identity."

Aptible implementation: AWS IAM + AWS OpsWorks

Other potential solutions: Custom Chef recipes + data bag for authorized

keys

AWS OpsWorks Deny by Default

SSH access is granted:

Only to IAM user

Only on a temporary basis

Chef-configured cron task locks down instances hourly

gem install opsworks-cli

opsworks allow frank --stack my-stack

opsworks lockdown --stack my-stack

General safeguard: auditing SSH access

Regulatory requirement: "Implement hardware, software, and/or

procedural mechanisms that record and examine activity in information

systems that contain or use electronic protected health information"

Aptible implementation: AWS OpsWorks + Deny by Default + AWS

CloudTrail

Other potential solutions: Authy, syslog + Logstash + Elasticsearch +

Kibana

Addressing application-specific safeguards

Challenge: Many frameworks, many libraries, many specific

implementation decisions

Solution: One "compliance API" to manage audit artifacts and mapping

from artifact type to requirements, many clients

Application-specific safeguard: authentication

gridiron.create_audit_log(

criterion: 'authentication_event',

timestamp: 1414368280,

uuid: 'f59c9a72-2f28-4b6b-93e…',

authentication_method: 'token',

…

)

Application-specific safeguard: authentication

Authentication audit log

(Satisfies requirements)

§ 164.312(a)(1): Access control

§ 164.312(a)(2)(i): Unique user identification

§ 164.312(d): Person or entity authentication

(…)

Please give us your feedback on this

presentation

(hls401) architecting for hipaa compliance on aws | aws re:invent 2014

Technology