When embarking on a cloud journey to AWS and considering how security fits into the picture, there are endless resources to turn to. You’ll find everything from the Well-Architected Framework to the Cloud Adoption Framework to AWS security best practices. While these scattered guides and many more can help inform you of AWS security services and best practices, having a standard to measure yourself against can be very helpful and give you more of an assurance that you haven’t forgotten something critical. It may also help in demonstrating to an auditor that you’ve aligned yourself to something that’s been sanctioned.
CIS
A number of standards or frameworks exist for AWS security. One of the most popular is the CIS Amazon Web Services Foundations Benchmark. Produced by the Center for Internet Security, it provides “prescriptive guidance for configuring security options for a subset of Amazon Web Services with an emphasis on foundational, testable, and architecture agnostic settings.” Services in scope include IAM, Config, CloudTrail, CloudWatch, SNS, S3, and VPC. This benchmark was developed through a process involving subject matter experts in consulting, audit and compliance, software development, and more.
Its recommendations include, for example: ensuring that the root user has multi-factor authentication (MFA) enabled, using a complex IAM password policy, and enabling CloudTrail in all regions.
The popularity of this benchmark led to the creation of a code repository on GitHub by AWS labs containing CloudFormation templates and other tools that assist with an automated implementation. It was then later included as one of the supported standards in a new AWS service called Security Hub.
AWS Foundational Security Best Practices Standard
In April of this year, AWS announced a standard of its own, known as the AWS Foundational Security Best Practices standard. This standard consists of 31 fully automated security controls that “detect when AWS accounts and deployed resources do not align with security best practices defined by AWS security experts”.
The controls cover the most popular and foundational services in AWS, and Security Hub findings are generated when deviations from best practices are identified. Accounts and workloads are continuously evaluated. With its availability, AWS now recommends that Security Hub and this standard be enabled in all accounts and regions you use.
The controls are broken down into categories and subcategories:
| Category | Description | Subcategories |
| Identify | Develop the organizational understanding to manage cybersecurity risk to systems, assets, data, and capabilities. | Inventory |
| Logging | ||
| Protect | Develop and implement the appropriate safeguards to ensure delivery of critical infrastructure services and secure coding practices. | Secure access management |
| Secure network configuration | ||
| Data protection | ||
| API protection | ||
| Protective services | ||
| Secure development | ||
| Detect | Develop and implement the appropriate activities to identify the occurrence of a cybersecurity event. | Detection services |
| Respond | Develop and implement the appropriate activities to take action regarding a detected cybersecurity event. | Response actions |
| Forensics | ||
| Recover | Develop and implement the appropriate activities to maintain plans for resilience and to restore any capabilities or services that were impaired due to a cybersecurity event. | Resilience |
So what do these “controls” look like? Here are a few examples, ranging from the familiar to the more nuanced and obscure:
- [CloudTrail.1] CloudTrail should be enabled and configured with at least one multi-Region trail
- [Config.1] AWS Config should be enabled
- [S3.1] S3 Block Public Access setting should be enabled
- [GuardDuty.1] GuardDuty should be enabled
- [EC2.3] Attached EBS volumes should be encrypted at-rest
- [IAM.1] IAM policies should not allow full “*” administrative privileges
- [ELBv2.1] Application Load Balancer should be configured to redirect all HTTP requests to HTTPS
- [Lambda.1] Lambda functions should prohibit public access by other accounts
- [ACM.1] Imported ACM certificates should be renewed within 90 days of expiration
- [CodeBuild.1] CodeBuild GitHub or Bitbucket source repository URLs should use OAuth
The full list can be found here.
Each control is assigned a severity (Low, Medium, High, etc.), applies to a specific resource type, and has a managed Config rule that is used to verify compliance. Instructions for remediation are also provided.
Getting Started
To get started using this new standard, you’ll want to ensure that the Config service is turned on. For the moment, we’ll assume that you’re only using one account and region.
Next, go to the Security Hub service in the console. You’ll see a page like this:
Click on the button that says “Go to Security Hub”. You’ll then see the welcome page:
Click the check box next to “Enable AWS Foundational Security Best Practices” and click “Enable Security Hub”. You’ll then be taken to the summary page which looks something like this:
It’ll take some time for findings to appear. Once they do, you’ll start seeing results listed on this page and you’ll see a security score on the Security standards page:
If you click on view results you’ll see details for each control:
Multiple Accounts
If you’re using multiple accounts, it’s often best to select one as the “master” account. This is frequently a security account of some kind. You can then invite other “member” accounts to be associated with the master in order to see Security Hub findings in a consolidated place. Also, if you’re using multiple regions, you’ll need to make sure you enable the service in each region.
Automation
Security Hub is relatively new at the time of this writing, so its CloudFormation support is pretty minimal, but some does exist. There’s also a great GitHub repo that helps automate the process of enabling the service across multiple accounts, sending invitations to member accounts, and accepting them. I have found it helpful when dealing with a large number of accounts.
Pricing
The cost of using Security Hub and this security standard is pretty minimal and is based on the quantity of security checks and “finding ingestion events”. The pricing page provides some example scenarios, with a “large organization” possibly seeing a cost of something around $20/month. Note that there are some associated Config costs as well.
Conclusion
You really can’t go wrong enabling Security Hub and turning on this standard. You’ll get some instant insight into how your AWS security posture is looking and things that may need attention. It’s nice seeing a standard that comes from AWS itself, and baking it into a service makes it instantly usable.
