Today, we are happy to announce the release of a new whitepaper: AWS Key Management Service Best Practices. This whitepaper takes knowledge learned from some of the largest adopters of AWS Key Management Service (AWS KMS) and makes it available to all AWS customers. AWS KMS is a managed service that makes it easy for you to create and control the keys used to encrypt your data and uses hardware security modules to protect the security of your keys.
This new whitepaper is structured around the AWS Cloud Adoption Framework (AWS CAF) Security Perspective. The AWS CAF provides guidance to help organizations that are moving to the AWS Cloud and is broken into a number of areas of focus that are relevant to implementing cloud-based IT systems, which we call Perspectives. The Security Perspective organizes the principles that help drive the transformation of your organization’s security through Identity and Access Management, Detective Control, Infrastructure Security, Data Protection, and Incident Response. For each of the capabilities, the new whitepaper provides not only details about how your organization should use KMS to protect sensitive information across use cases but also the means of measuring progress.
Whether you have already implemented your key management infrastructure using KMS or are just starting to do so, this whitepaper provides insight into some of the best practices we recommend to our customers across industries and compliance regimes.
In case you missed any AWS Security Blog posts published so far in 2017, they are summarized and linked to below. The posts are shown in reverse chronological order (most recent first), and the subject matter ranges from protecting dynamic web applications against DDoS attacks to monitoring AWS account configuration changes and API calls to Amazon EC2 security groups.
March 22: How to Help Protect Dynamic Web Applications Against DDoS Attacks by Using Amazon CloudFront and Amazon Route 53
Using a content delivery network (CDN) such as Amazon CloudFront to cache and serve static text and images or downloadable objects such as media files and documents is a common strategy to improve webpage load times, reduce network bandwidth costs, lessen the load on web servers, and mitigate distributed denial of service (DDoS) attacks. AWS WAF is a web application firewall that can be deployed on CloudFront to help protect your application against DDoS attacks by giving you control over which traffic to allow or block by defining security rules. When users access your application, the Domain Name System (DNS) translates human-readable domain names (for example, www.example.com) to machine-readable IP addresses (for example, 192.0.2.44). A DNS service, such as Amazon Route 53, can effectively connect users’ requests to a CloudFront distribution that proxies requests for dynamic content to the infrastructure hosting your application’s endpoints. In this blog post, I show you how to deploy CloudFront with AWS WAF and Route 53 to help protect dynamic web applications (with dynamic content such as a response to user input) against DDoS attacks. The steps shown in this post are key to implementing the overall approach described in AWS Best Practices for DDoS Resiliency and enable the built-in, managed DDoS protection service, AWS Shield.
March 21: New AWS Encryption SDK for Python Simplifies Multiple Master Key Encryption
The AWS Cryptography team is happy to announce a Python implementation of the AWS Encryption SDK. This new SDK helps manage data keys for you, and it simplifies the process of encrypting data under multiple master keys. As a result, this new SDK allows you to focus on the code that drives your business forward. It also provides a framework you can easily extend to ensure that you have a cryptographic library that is configured to match and enforce your standards. The SDK also includes ready-to-use examples. If you are a Java developer, you can refer to this blog post to see specific Java examples for the SDK. In this blog post, I show you how you can use the AWS Encryption SDK to simplify the process of encrypting data and how to protect your encryption keys in ways that help improve application availability by not tying you to a single region or key management solution. (more…)
In June 2015, we introduced s2n, an open-source implementation of the TLS encryption protocol, making the source code publicly available under the terms of the Apache Software License 2.0 from the s2n GitHub repository. One of the key benefits to s2n is far less code surface, with approximately 6,000 lines of code (compared to OpenSSL’s approximately 500,000 lines). In less than two years, we’ve seen significant enhancements to s2n, with more than 1,000 code commits, plus the addition of fuzz testing and a static analysis tool, tis-interpreter.
Today, we’ve achieved another important milestone for securing customer data: we have replaced OpenSSL with s2n for all internal and external SSL traffic in Amazon Simple Storage Service (Amazon S3) commercial regions. This was implemented with minimal impact to customers, and multiple means of error checking were used to ensure a smooth transition, including client integration tests, catching potential interoperability conflicts, and identifying memory leaks through fuzz testing.
It was only last week that AWS CEO Andy Jassy reiterated something that’s been a continual theme for us here at AWS: “There’s so much security built into cloud computing platforms today, for us, it’s our No. 1 priority—it’s not even close, relative to anything else.” Yes, security remains our top priority, and our commitment to making formal verification of automated reasoning more efficient exemplifies the way we think about our tools and services. Making encryption more developer friendly is critical to what can be a complicated architectural universe. To help make security more robust and precise, we put mechanisms in place to verify every change, including negative test cases that “verify the verifier” by deliberately introducing an error into a test-only build and confirming that the tools reject it.
If you are interested in using or contributing to s2n, the source code, documentation, commits, and enhancements are all publicly available under the terms of the Apache Software License 2.0 from the s2n GitHub repository.
The following 10 posts were the most viewed AWS Security Blog posts that we published during 2016. You can use this list as a guide to catch up on your blog reading or even read a post again that you found particularly useful.
- How to Set Up DNS Resolution Between On-Premises Networks and AWS Using AWS Directory Service and Amazon Route 53
- How to Control Access to Your Amazon Elasticsearch Service Domain
- How to Restrict Amazon S3 Bucket Access to a Specific IAM Role
- Announcing AWS Organizations: Centrally Manage Multiple AWS Accounts
- How to Configure Rate-Based Blacklisting with AWS WAF and AWS Lambda
- How to Use AWS WAF to Block IP Addresses That Generate Bad Requests
- How to Record SSH Sessions Established Through a Bastion Host
- How to Manage Secrets for Amazon EC2 Container Service–Based Applications by Using Amazon S3 and Docker
- Announcing Industry Best Practices for Securing AWS Resources
- How to Set Up DNS Resolution Between On-Premises Networks and AWS Using AWS Directory Service and Microsoft Active Directory
Whether you want to review a Security and Compliance track session you attended at AWS re:Invent 2016 or you want to experience a session for the first time, videos from the Security and Compliance track and re:Source Mini Con for Security Services are now available.
Note: Slide decks also will be available in the coming days.
Security & Compliance track
SAC201: Lessons from a Chief Security Officer: Achieving Continuous Compliance in Elastic Environments
SAC303: Become an AWS IAM Policy Ninja in 60 Minutes or Less
SAC304: Predictive Security: Using Big Data to Fortify Your Defenses
SAC305: How AWS Automates Internal Compliance at Massive Scale using AWS Services
In case you missed any AWS Security Blog posts from June, July, and August, they are summarized and linked to below. The posts are shown in reverse chronological order (most recent first), and the subject matter ranges from a tagging limit increase to recording SSH sessions established through a bastion host.
August 16: Updated Whitepaper Available: AWS Best Practices for DDoS Resiliency
We recently released the 2016 version of the AWS Best Practices for DDoS Resiliency Whitepaper, which can be helpful if you have public-facing endpoints that might attract unwanted distributed denial of service (DDoS) activity.
August 15: Now Organize Your AWS Resources by Using up to 50 Tags per Resource
Tagging AWS resources simplifies the way you organize and discover resources, allocate costs, and control resource access across services. Many of you have told us that as the number of applications, teams, and projects running on AWS increases, you need more than 10 tags per resource. Based on this feedback, we now support up to 50 tags per resource. You do not need to take additional action—you can begin applying as many as 50 tags per resource today.
August 11: New! Import Your Own Keys into AWS Key Management Service
Today, we are happy to announce the launch of the new import key feature that enables you to import keys from your own key management infrastructure (KMI) into AWS Key Management Service (KMS). After you have exported keys from your existing systems and imported them into KMS, you can use them in all KMS-integrated AWS services and custom applications.
August 2: Customer Update: Amazon Web Services and the EU-US Privacy Shield
Recently, the European Commission and the US Government agreed on a new framework called the EU-US Privacy Shield, and on July 12, the European Commission formally adopted it. AWS welcomes this new framework for transatlantic data flow. As the EU-US Privacy Shield replaces Safe Harbor, we understand many of our customers have questions about what this means for them. The security of our customers’ data is our number one priority, so I wanted to take a few moments to explain what this all means.
August 2: How to Remove Single Points of Failure by Using a High-Availability Partition Group in Your AWS CloudHSM Environment
In this post, I will walk you through steps to remove single points of failure in your AWS CloudHSM environment by setting up a high-availability (HA) partition group. Single points of failure occur when a single CloudHSM device fails in a non-HA configuration, which can result in the permanent loss of keys and data. The HA partition group, however, allows for one or more CloudHSM devices to fail, while still keeping your environment operational. (more…)
How to Remove Single Points of Failure by Using a High-Availability Partition Group in Your AWS CloudHSM Environment
A hardware security module (HSM) is a hardware device designed with the security of your data and cryptographic key material in mind. It is tamper-resistant hardware that prevents unauthorized users from attempting to pry open the device, plug any extra devices in to access data or keys such as subtokens, or damage the outside housing. If any such interference occurs, the device wipes all information stored so that unauthorized parties do not gain access to your data or cryptographic key material. A high-availability (HA) setup could be beneficial because, with multiple HSMs kept in different data centers and all data synced between them, the loss of one HSM does not mean the loss of your data.
In this post, I will walk you through steps to remove single points of failure in your AWS CloudHSM environment by setting up an HA partition group. Single points of failure occur when a single CloudHSM device fails in a non-HA configuration, which can result in the permanent loss of keys and data. The HA partition group, however, allows for one or more CloudHSM devices to fail, while still keeping your environment operational. (more…)
In case you missed any of the AWS Security Blog posts from March and April, they are summarized and linked to below. The posts are shown in reverse chronological order (most recent first), and the subject matter ranges from the AWS Config Rules repository to automatically updating AWS WAF IP blacklists.
April 28, AWS WAF How-To: How to Import IP Address Reputation Lists to Automatically Update AWS WAF IP Blacklists
A number of organizations maintain reputation lists of IP addresses used by bad actors. Their goal is to help legitimate companies block access from specific IP addresses and protect their web applications from abuse. These downloadable, plaintext reputation lists include Spamhaus’s Don’t Route Or Peer (DROP) List and Extended Drop (EDROP) List, and Proofpoint’s Emerging Threats IP list. Similarly, the Tor project’s Tor exit node list provides a list of IP addresses currently used by Tor users to access the Internet. Tor is a web proxy that anonymizes web requests and is sometimes used by malicious users to probe or exploit websites.
April 27, Federated SSO How-To: How to Set Up Federated Single Sign-On to AWS Using Google Apps
Among the services offered to Google Apps for Work users is a Security Assertion Markup Language (SAML) 2.0–based SSO service. You can use this service to provide one-click SSO to your AWS resources by using your existing Google Apps credentials. For users to whom you grant SSO access, they will see an additional SAML app in your Google Apps account, as highlighted in the following screenshot. When your users click the SAML app, Google Apps authenticates and redirects them to the AWS Management Console. In this blog post, I will show you how you can use Google Apps to set up federated SSO to your AWS resources.
April 21, AWS WAF How-To: How to Prevent Hotlinking by Using AWS WAF, Amazon CloudFront, and Referer Checking
You can use AWS WAF to help prevent hotlinking. AWS WAF is a web application firewall that is closely integrated with Amazon CloudFront (AWS’s content delivery network [CDN]), and it can help protect your web applications from common web exploits that could affect application availability, compromise security, and consume excessive resources. In this blog post, I will show you how to prevent hotlinking by using header inspection in AWS WAF, while still taking advantage of the improved user experience from a CDN such as CloudFront. (more…)
What’s New in AWS Key Management Service: AWS CloudFormation Support and Integration with More AWS Services
We’re happy to make two announcements about what’s new in AWS Key Management Service (KMS).
First, AWS CloudFormation has added a template for KMS that lets you quickly create KMS customer master keys (CMK) and set their properties. Starting today, you can use the AWS::KMS::Key resource to create a CMK in KMS. To get started, you can use AWS CloudFormation Designer to drag-and-drop a KMS key resource type into your template, as shown in the following image.
To learn more about using KMS with CloudFormation, see the “AWS::KMS::Key” section of the AWS CloudFormation User Guide.
Second, AWS Import/Export Snowball, AWS CloudTrail, Amazon SES, Amazon WorkSpaces, and Amazon Kinesis Firehose now support encryption of data within those services using keys in KMS. As with other KMS-integrated services, you can use CloudTrail to audit the use of your KMS key to encrypt or decrypt your data in SES, Amazon WorkSpaces, CloudTrail, Import/Export Snowball, and Amazon Kinesis Firehose. To see the complete list of AWS services integrated with KMS, see KMS Product Details. For more details about how these services encrypt your data with KMS, see the How AWS Services Use AWS KMS documentation pages.
If you have questions or comments, please add them in the “Comments” section below or on the KMS forum.
Whether you want to review a Security and Compliance track session you attended at re:Invent 2015, or you want to experience a session for the first time, videos and slide decks from the Security and Compliance track are now available.
SEC201: AWS Security State of the Union: How Should We All Think About Security?
SEC202: If You Build It, They Will Come: Best Practices for Securely Leveraging the Cloud
SEC203: Journey to Securing Time Inc.’s Move to the Cloud