I’m a developer, or at least that’s what I tell myself while coming to terms with being a manager. I’m definitely not an infosec expert. I’ve been paged more than once in my career because something I wrote or configured caused a security concern. When systems enable frequent deploys and remove gatekeepers for experimentation, sometimes a non-compliant resource is going to sneak by. That’s why I love tools like AWS Security Hub, a service that enables automated compliance checks and aggregated insights from a variety of services. With guardrails like these in place to make sure things stay on track, I can experiment more confidently. And with a single place to view compliance findings from multiple systems, infosec feels better about letting me self-serve.

With cloud computing, we have a shared responsibility model when it comes to compliance and security. AWS handles the security of the cloud: everything from the security of our data centers up to the virtualization layer and host operating system. Customers handle security in the cloud: the guest operating system, configuration of systems, and secure software development practices.

Today, AWS Security Hub is out of preview and available for general use to help you understand the state of your security in the cloud. It works across AWS accounts and integrates with many AWS services and third-party products. You can also use the Security Hub API to create your own integrations.

Getting Started

When you enable AWS Security Hub, permissions are automatically created via IAM service-linked roles. Automated, continuous compliance checks begin right away. Compliance standards determine these compliance checks and rules. The first compliance standard available is the Center for Internet Security (CIS) AWS Foundations Benchmark. We’ll add more standards this year.

The results of these compliance checks are called findings. Each finding tells you severity of the issue, which system reported it, which resources it affects, and a lot of other useful metadata. For example, you might see a finding that lets you know that multi-factor authentication should be enabled for a root account, or that there are credentials that haven’t been used for 90 days that should be revoked.

Findings can be grouped into insights using aggregation statements and filters.

Integrations

In addition to the Compliance standards findings, AWS Security Hub also aggregates and normalizes data from a variety of services. It is a central resource for findings from Amazon GuardDuty, Amazon Inspector, Amazon Macie, and from 30 AWS partner security solutions.

AWS Security Hub also supports importing findings from custom or proprietary systems. Findings must be formatted as AWS Security Finding Format JSON objects. Here’s an example of an object I created that meets the minimum requirements for the format. To make it work for your account, switch out the AwsAccountId and the ProductArn . To get your ProductArn for custom findings, replace REGION and ACCOUNT_ID in the following string: arn:aws:securityhub:REGION:ACCOUNT_ID:product/ACCOUNT_ID/default .

{ "Findings": [{ "AwsAccountId": "12345678912", "CreatedAt": "2019-06-13T22:22:58Z", "Description": "This is a custom finding from the API", "GeneratorId": "api-test", "Id": "us-east-1/12345678912/98aebb2207407c87f51e89943f12b1ef", "ProductArn": "arn:aws:securityhub:us-east-1:12345678912:product/12345678912/default", "Resources": [{ "Type": "Other", "Id": "i-decafbad" }], "SchemaVersion": "2018-10-08", "Severity": { "Product": 2.5, "Normalized": 11 }, "Title": "Security Finding from Custom Software", "Types": [ "Software and Configuration Checks/Vulnerabilities/CVE" ], "UpdatedAt": "2019-06-13T22:22:58Z" }] }

Then I wrote a quick node.js script that I named importFindings.js to read this JSON file and send it off to AWS Security Hub via the AWS JavaScript SDK.

const fs = require('fs'); // For file system interactions const util = require('util'); // To wrap fs API with promises const AWS = require('aws-sdk'); // Load the AWS SDK AWS.config.update({region: 'us-east-1'}); // Create our Security Hub client const sh = new AWS.SecurityHub(); // Wrap readFile so it returns a promise and can be awaited const readFile = util.promisify(fs.readFile); async function getFindings(path) { try { // wait for the file to be read... let fileData = await readFile(path); // ...then parse it as JSON and return it return JSON.parse(fileData); } catch (error) { console.error(error); } } async function importFindings() { // load the findings from our file const findings = await getFindings('./findings.json'); try { // call the AWS Security Hub BatchImportFindings endpoint response = await sh.batchImportFindings(findings).promise(); console.log(response); } catch (error) { console.error(error); } } // Engage! importFindings();

A quick run of node importFindings.js results in { FailedCount: 0, SuccessCount: 1, FailedFindings: [] } . And now I can see my custom finding in the Security Hub console:

Custom Actions

AWS Security Hub can integrate with response and remediation workflows through the use of custom actions. With custom actions, a batch of selected findings is used to generate CloudWatch events. With CloudWatch Rules, these events can trigger other actions such as sending notifications via a chat system or paging tool, or sending events to a visualization service.

First, we open Settings from the AWS Security Console, and select Custom Actions. Add a custom action and note the ARN.

Then we create a CloudWatch Rule using the custom action we created as a resource in the event pattern, like this:

{ "source": [ "aws.securityhub" ], "detail-type": [ "Security Hub Findings - Custom Action" ], "resources": [ "arn:aws:securityhub:us-west-2:123456789012:action/custom/DoThing" ] }

Our CloudWatch Rule can have many different kinds of targets, such as Amazon Simple Notification Service (SNS) Topics, Amazon Simple Queue Service (SQS) Queues, and AWS Lambda functions. Once our action and rule are in place, we can select findings, and then choose our action from the Actions dropdown list. This will send the selected findings to Amazon CloudWatch Events. Those events will match our rule, and the event targets will be invoked.

Important Notes

AWS Config must be enabled for Security Hub compliance checks to run.

AWS Security Hub is available in 15 regions: US East (N. Virginia) , US East (Ohio) , US West (Oregon) , US West (N. California) , Canada (Central) , South America (São Paulo) , Europe (Ireland) , Europe (London) , Europe (Paris) , Europe (Frankfurt) , Asia Pacific (Singapore) , Asia Pacific (Tokyo) , Asia Pacific (Sydney) , Asia Pacific (Seoul) , and Asia Pacific (Mumbai) .

is available in 15 regions: , , , , , , , , , , , , , , and . AWS Security Hub does not transfer data outside of the regions where it was generated. Data is not consolidated across multiple regions.

AWS Security Hub is already the type of service that I’ll enable on the majority of the AWS accounts I operate. As more compliance standards become available this year, I expect it will become a standard tool in many toolboxes. A 30-day free trial is available so you can try it out and get an estimate of what your costs would be. As always, we want to hear your feedback and understand how you’re using AWS Security Hub. Stay in touch, and happy building!