Category: Compliance

Today, we continue a series of AWS cloud compliance FAQs by focusing on the Health Insurance Portability and Accountability Act (HIPAA) and protected health information (PHI). AWS’s Healthcare and Life Science customers are doing important things for their customers in the AWS cloud, and we are excited to work with our partners to help tackle medical advancements at scale.

In this blog post, I will share some of the broader questions we hear from customers about HIPAA compliance and PHI in the cloud. (more…)

Every month, AWS Compliance fields thousands of questions about how to achieve and maintain compliance in the cloud. Among other things, customers are eager to take advantage of the cost savings and security at scale that AWS offers while still maintaining robust security and regulatory compliance. Because regulations across industries and geographies can be complex, we thought it might be helpful to share answers to some of the frequently asked questions we hear about compliance in the AWS cloud, as well as to clear up potential misconceptions about how operating in the cloud might affect compliance.

Is AWS compliant with [Program X]?

Context is required to answer this question. In all cases, customers operating in the cloud remain responsible for complying with applicable laws and regulations, and it is up to you to determine whether AWS services meet applicable requirements for your business. To help you make this determination, we have enacted assurance programs across multiple industries and jurisdictions to inform and support AWS customers. We think about these assurance programs across the following three broad categories. (more…)

To celebrate 10 years of AWS, qwikLABS is offering 95 free online labs through the end of March 2016. Here are some of the labs related to security and compliance that you can take for free while the offer is live:

• Introduction to AWS Identity and Access Management (IAM)
• Introduction to AWS Key Management Service
• Performing a Basic Audit of Your AWS Environment
• Auditing Changes to Amazon EC2 Security Groups
• Auditing Your Security with AWS Trusted Advisor
• Microsoft ADFS and AWS IAM

These self-paced labs let you learn at your own pace from this AWS training partner. Start today!

– Craig

Today, we’re happy to release the AWS Config Rules repository, a community-based source of custom AWS Config Rules. This new repository gives you a streamlined way to automate your assessment and compliance against best practices for security of AWS resources. AWS Config Rules is a service that provides automated, periodic security and compliance checking of AWS resources, and affords customers the ability to forego manual inspection of security configurations.

The AWS Config Rules repository accelerates automated compliance checking by allowing customers to tap in to the collective ingenuity and expertise of the AWS community. Additionally, the repository is free, public, and hosted on an independent platform, and it contains full source code for each rule, allowing you to learn and contribute. We look forward to working together to leverage the combined wisdom and lessons learned by our security experts and the security experts in the broader AWS user base.

As I mentioned in my previous post, we have partnered with the Center for Internet Security to establish industry best practices for securing AWS accounts. The repository has been seeded with rules that will help you maintain alignment with these best practices. Here’s a sample of the Custom Rules you now have access to:

1. Ensure CloudTrail is enabled in all regions.
2. Ensure all accounts have multi-factor authentication (MFA) enabled.
3. Ensure no access keys exist for the root account.
4. Ensure an AWS Identity and Access Management (IAM) password policy exists.
5. Ensure access keys are rotated.

To get started using these rules in your AWS account, see the readme file on GitHub. I encourage you to use this repository to share with the AWS community the Custom Rules you have written.

– Chad

Today, we are happy to announce that the Center for Internet Security (CIS) has published the CIS AWS Foundations Benchmark, a set of security configuration best practices for AWS. These industry-accepted best practices go beyond the high-level security guidance already available, providing AWS users with clear, step-by-step implementation and assessment procedures. This is the first time CIS has issued a set of security best practices specific to an individual cloud service provider.

This is good news for a number of key reasons:

1. CIS Benchmarks are technical industry best practices. This removes guesswork for security professionals about how to implement foundational security measures in your AWS account. The prescribed best practices make implementation of core AWS security measures straightforward for security teams and AWS account owners.
2. Audit teams can consistently evaluate the security of an AWS account. The best practices greatly reduce complexity when managing risk and auditing the use of AWS for critical, audited, and regulated systems.
3. These security checks can be integrated into the security and audit ecosystem. CIS Benchmarks are incorporated into products developed by 20 security vendors, are referenced by PCI 3.1 and FedRAMP, and are included in the National Vulnerability Database (NVD) National Checklist Program (NCP). AWS security best practices can now be integrated into these audit processes and will integrate seamlessly into these security vendor tools and solutions.

For 16 years, CIS Benchmarks have been the de facto standard for prescriptive, industry-accepted best practices for securely configuring traditional IT components. The release of the CIS AWS Foundations Benchmark into this existing ecosystem marks one of many milestones for the maturation of the cloud and its suitability for sensitive and regulated workloads.

Please contact us with questions about using AWS products in alignment with CIS Benchmarks, or if you’d like to learn more about compliance in the cloud, see our AWS Cloud Compliance page.

– Chad

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.  (more…)

In my previous post, I walked through the setup of a DevSecOps environment that gives healthcare developers the ability to launch their own healthcare web server. At the heart of the architecture is AWS CloudFormation, a JSON representation of your architecture that allows security administrators to provision AWS resources according to the compliance standards they define. In today’s post, I will share examples that provide a Top 9 List of CloudFormation code snippets that you can consider when trying to map the requirements of the AWS Business Associates Agreement (BAA) to CloudFormation templates.

The example CloudFormation template I use as an example in today’s post is the same template I used in my previous post to define a healthcare product in AWS Directory Service. The template creates a healthcare web server that follows many of the contractual obligations outlined in the AWS BAA. The template also allows healthcare developers to customize their web server according to the following parameters:

• FriendlyName – The name with which you tag your server.
• CodeCommitRepo – The cloneUrlHttp field for the Git repository that you would like to release on the web server.
• Environment – A choice between PROD and TEST. TEST will create a security group with several secure ports open, including SSH, from within a Classless Inter-Domain Routing (CIDR) block range. Choosing PROD will create a security group with HTTPS that is only accessible from the public Internet. (Exposing production web servers directly to the public Internet is not a best practice and is shown for example purposes only).
• PHI – If you need to store protected health information (PHI) on the server. Choosing YES will create an encrypted EBS volume and attach it to the web server.
• WebDirectory – This is the name of your website. For example, DNS-NAME/WebDirectory.
• InstanceType – This is the Amazon EC2 instance type on which the code will be deployed. The available instances are restricted to the list of EC2 instances that support EBS encryption.

I will forego CloudFormation tutorials in this post because an abundance of material for learning CloudFormation is easily accessible in AWS documentation. Instead, I will jump right in to share the Top 9 List of CloudFormation code snippets. If you are new to CloudFormation, you might find value in first understanding the capabilities it offers.  (more…)

In my previous blog post, I discussed the idea of using the cloud to protect the cloud and improving healthcare IT by applying DevSecOps methods. In Part 2 today, I will show an architecture composed of AWS services that gives healthcare security administrators necessary controls, allows healthcare developers to interact with the system using familiar tools (such as Git), and leverages AWS managed services without the need for advanced coding or complex configuration.

Along the way, I hope to dispel the myth that healthcare security administrators lose control in a DevSecOps environment, and show that healthcare developers can still rely on their administrators without having their development cycles affected adversely. (more…)

The United States healthcare ecosystem is highly complex. It is composed of review boards, regulating bodies, government agencies, pharmaceutical companies, insurance payers, and a mix of public and private provider entities, all of which intersect and overlap. Underlying this system lays highly sensitive patient data, which is governed by the U.S. Health Insurance Portability and Accountability Act (HIPAA). This law and its implementing regulations, much like the system they protect, can be complex. Automating and improving a typical HIPAA compliance process can improve the security, speed, and reliability of an entity’s application of the healthcare rules.

Where, though, should you start with such process improvements? As AWS Principal Security Consultant Hart Rossman said at AWS re:Invent 2015 during the breakout session, Architecting for End-to-End Security in the Enterprise: “You’ve got to use the cloud to protect the cloud. Our most successful customers who are security conscious are leveraging all of the features and functions that are available to them through AWS and our partner ecosystem.” The model of security diligence that Rossman and his colleague Bill Shinn detail in their session is one that is modeled after DevOps, a methodology created by the software development community as a way to speed the deployment of mission-critical code. The goal of Bill and Hart’s session is to evangelize the need to make security an essential part of the DevOps process—this combination of development, operations, and security is known as DevSecOps.

In a series of blog posts on the AWS Security Blog this month, I will provide prescriptive advice and code samples to developers, system administrators, and security specialists who wish to improve their healthcare IT by applying the DevSecOps methods that the cloud enables. I will also demonstrate AWS services that can help customers meet their AWS Business Associate Agreement obligations in an automated fashion. Consider this series a getting started guide for DevSecOps strategies you can implement as you migrate your own compliance frameworks and controls to the cloud.

In upcoming posts, I will show how to use the cloud to protect the cloud in the following areas:

• February 16: Use the AWS Service Catalog for Code Deployments
• February 22: How to Translate HIPAA Controls to AWS CloudFormation Templates
• February 23: Use AWS Config to Help with Required HIPAA Audit Controls

Although the examples in these posts will focus on how you can meet your AWS Business Associate Agreement obligations, the examples will be applicable to many compliance programs because they provide avenues for helping to ensure the security of your programs.

– Christopher

I’m pleased to announce a newly created resource for usage of the Federal Cloud—after successfully completing the testing phase of the FedRAMP-Trusted Internet Connection (TIC) Overlay pilot program, we’ve developed Guidance for TIC Readiness on AWS. This new way of architecting cloud solutions that address TIC capabilities (in a FedRAMP moderate baseline) comes as the result of our relationships with the FedRAMP Program Management Office (PMO), Department of Homeland Security (DHS) TIC PMO, GSA 18F, and FedRAMP third-party assessment organization (3PAO), Veris Group. Ultimately, this approach will provide US Government agencies and contractors with information assisting in the development of “TIC Ready” architectures on AWS.   (more…)