AWS Security Compliance Cheat Sheet

AWS may seem like a black box to many compliance managers and auditors. After all, AWS has over 200 products and services! This article is an attempt to help demystify some security and compliance aspects of Amazon Web Services (AWS). Here’s what we’ll cover:

Myth: Compliance Is Automatic When Using AWS

Myth: AWS Takes Automatic Backups

Myth: AWS Has Automatic Redundancy / Never Fails

What Do I Look For In AWS From a Compliance Standpoint?

Identity: The New Perimeter

Identity Security Pitfalls

Logging

Networking

Intrusion Detection

Storage

Securing S3

How Do I Assess The Compliance Posture Of My Aws Environments?

AWS Native Tools

Conclusion

Let’s start off with some myths:

Myth: Compliance Is Automatic When Using AWS

While AWS itself is compliant and secure, anything you create and deploy is not automatically compliant. This means that the datacenters and hardware that run AWS are secure, but, for example, when you create a virtual machine (EC2) you must configure security and enforce compliance controls yourself. This is referred to as the Shared Responsibility Model. The best example is that a car you buy is considered safe and compliant with manufacturing standards, but how you (or your teenage child) drive and operate the car is up to you and your responsibility.

Myth: AWS Takes Automatic Backups

There is no “undo” in AWS. When EC2 instances are terminated, they cannot be restored. Versioning of S3 Buckets must be enabled. Backups and snapshots of EC2 instances must be enabled. Even then, you would need a DR account, and even offline/3rd party storage to ensure full redundancy.

Myth: AWS Has Automatic Redundancy/Never Fails

As with any technology, there is always a chance of failure. Although AWS provides multiple regions with multiple availability zones (data centers at least 50 miles apart in a single region), you still must design your architecture and application to be redundant. Although rare, entire AWS regions/availability zones or services have gone down or been partially unavailable in the past. Of course, it’s up to you to decide what level of tolerance you’re comfortable with. On the positive side, it’s sometimes comforting to know you’re not the only one down when a cloud provider service is not available.

What Do I Look for In AWS from a Compliance Standpoint? 

AWS has over 200 products and services. Ensuring the compliance and security of all of these services can be very daunting. Below are some of the most important items to consider when evaluating your AWS Environments:

Identity: The New Perimeter

We at Cloud Security Labs have been saying this for a long time, but it’s something that needs to be repeated: Identity is the new perimeter. Gone are the days where securing your network with a “strong” firewall was all that you had to do. Now you can do almost anything with an API Key from anywhere, depending on the permissions associated with the key and user.

For example, with an AWS Key associated with an Administrator User, one can make a web request from anywhere in the world and do the following:

• Create thousands of EC2 instances in any region of the world costing tens of thousands of dollars. These can be used to mine cryptocurrency, run a botnet, or simply run up your bill for no reason.
• Delete all backups and snapshots in all regions of your account. There is no “undo” in AWS.

Identity Security Pitfalls

You want to look for excessive permissions in your AWS accounts, these include:

• *:*
• ec2:*
• sc3:*
• iam:*
• iam:PassRole

Basically, anything with a “*” in it, means “All” or “Everything”; so ec2:*, for example, means all permissions associated with EC2, which include terminations and shutdowns.

Here is an article with more detailed questions to ask of your security team.

Best practice would be to create various roles that have limited permissions for what your engineers require. For example, not everyone will need “ec2:terminateInstances”, which completely deletes an instance (because, remember, there is no way to undo that). However some people may need “shutdown” or ec2:stopinstamces capabilities for example.

On an almost daily basis, we at Cloud Security Labs hears of a company that had a breach due to a leaked API key stored in public repo.

Logging

An essential component in virtually all security compliance frameworks is logging. If you have multiple AWS accounts we strongly recommend enabling AWS Cloudtrail logs from the AWS Organizational root and for all AWS Accounts.

Networking

Although identity is the most important thing to consider in an AWS Account, Networking is still very important. AWS workloads live in  Virtual Private Clouds (VPCs). Each VPC can have multiple networking subnets, with each subnet located in a different availability zone within a single region. Although important, the network configuration of the VPC is outside the scope of this article. However, you should know   that subnets can be configured into private subnets and public subnets. This setting determines how workloads can access the internet and be accessed from the internet. EC2 instances living in public subnets can have Public IP’s.

Intrusion Detection

One item that comes up in some compliance frameworks (like SOC2) is the ability to detect malicious activity in your environments. There are multiple ways to enable threat detection, but AWS does have a native feature that fills this requirement known as AWS GuardDuty, which supports AWS Organizations with Delegated Administrator and can be auto-enabled for all new accounts. We at Cloud Security Labs love to use AWS Organizations to simplify the deployment of services. Although AWS GuardDuty is by no means a complete or top-tier IDS System, it does help fulfill the requirement above.

Another way you can meet these requirements is to take your Cloudtrail logs and send them to a SIEM that has automatic parsing for AWS Cloudtrail events. Ideally it will include pre-configured security controls.

Storage

This guide wouldn’t be complete without mentioning the primary storage mechanism in AWS: S3 Buckets. Billions of records have been leaked online due to insecurely configured S3 buckets over the years. There are so many leaks that someone created a GitHub repo to track them; and these are just the ones we know about,

AWS has come a long way towards notifying users and creating controls for administrators to protect S3 buckets from accidental public exposure. There are several warnings and indicators for console users when making a bucket public. Keep in mind, sometimes it’s ok to have a public bucket. For instance, if your application is storing public files, a public bucket would make sense.

Securing S3

There are a few ways AWS could improve though; for example, all access to S3 buckets allows HTTP requests. If you want to require HTTPS access to all buckets, you  must add a policy to require ssl.

If your bucket does not plan to have any public data in it ever, the main recommendation would be to enable Blocking Public Access on your S3 buckets. This is an additional preventative control that will limit the ability for the S3 bucket to be public.

The easiest way to fulfill any encryption compliance requirements would be to enable Server-Side Encryption with S3 Managed Keys (SSE-S3). This provides encryption at rest on the backend without impacting access to objects.

If you have sensitive data in your bucket, a slightly more advanced but robust protection would be to encrypt your data with a KMS key (SSE-KMS or SSE-C). This adds an additional layer of security to your objects, so if someone were to access your data they would also need access to your KMS key to decrypt the file. Access to the KMS key would typically be more restricted.

How Do I Assess the Compliance Posture of My AWS Environments?

There are a variety of tools out there that can help you understand the compliance posture of your AWS environments. 

Here are the top factors to look for when selecting a tool:

• Does the tool automatically sync and collect information from my AWS Accounts?
• How deep does it collect information? Below are some important types of information to collect:
  • IAM
  • EC2 & EBS Settings
  • S3 Storage and Encryption Settings
• Can the tool map this information to standard compliance frameworks like SOC2, PCI, or the AWS CIS Framework?

AWS Native Tools

AWS Audit Manager is a relatively new service from AWS that also supports AWS Organizations. It works by running “assessments” aligned to a number of frameworks.

Of course, as with many services from AWS they will not be as polished as many other 3rd party tools. For instance, Hyperproof has built a set of integrations to AWS services (e.g., EC2, IAM, RDS, S3, VPC) so users of Hyperproof and AWS services can automatically gather evidence of AWS settings and review all evidence in Hyperproof.

Conclusion

Compliance in AWS leverages the same fundamentals as compliance in the Datacenter days—and paying attention to access control, network segregation, availability, and data storage and handling are just as important as ever. However, now it’s about finding that Rosetta stone to translate to the cloud. The ubiquity of APIs and keys have expanded how access control is managed, and it’s made the  threat landscape more complex.

AWS and Public Clouds provide an enormous amount of power to engineers and developers. As a result, you have many “cooks” in the kitchen, making managing security real-time unwieldy. Investing in preventative controls and guardrails will reduce the surface area for attackers and make security more manageable.