Supercharging AWS Security Hub: 4 Part Series
Part 1   |  Part 2   |  Part 3  |  Part 4

AWS infrastructure security

Supercharging AWS Security Hub: Part 2, Get a Running Start

Continuing our dive into AWS Security hub let’s jump into setting up. Don’t worry, I won’t just rehash the AWS documentation; this post will cover our recommended configuration, how to push findings and events back into your security infrastructure, and some of the tradeoffs of enabling the supported underlying services. We’ll also discuss how the multi-account features work and the benefits and limitations.

Getting Started: Should You Use Security Standards?

Enabling Security Hub in the console is pretty much a 1-click process. Most of you will really want to enable it using CloudFormation or Terraform… but we’ll get there. I always like to walk through the console options first since it makes things easier to understand.

First the bad news! Security Hub is region-specific, which means you need to turn it on and configure it separately for every region in your account. This is why we strongly recommend you automate the process. This post will walk through the details for educational purposes, but you most definitely don’t want to spend a few weeks clicking through every region and account you manage!

AWS Security Hub is still useful even without the Security standards. If you are already using an alternative assessment or CSPM tool you might skip this setting, but running it through Security Hub and Config does provide one potential benefit, depending on what alternate tooling you use. The Config checks behind the Security standards setting run on either a scheduled basis or on resource modification. Modifications, such as changing a security group, are detected in real time and immediately generate findings. If your scanner runs on a scheduled interval, there will obviously gaps between changes and detection & finding creation. That’s enough reason for me to recommend enabling these checks. You’ll also need to turn them on if you want to use Security Hub as a dashboard, or feed compliance findings to tools like ours.

AWS infrastructure security

Security Hub is still useful even without turning on the Security Standards. If you are already using an alternative assessment or CSPM tool you might skip this setting but running it through Security Hub and Config does provide one potential benefit depending on what alternate tooling you use. The Config checks behind the Security Standards setting run on either a scheduled basis or on a detected modification to the resource. Those detected modifications, such as changing a security group, happen in real time and will generate a finding immediately. If you use a time-based scanner there will obviously be a time gap from the change to a finding. I generally recommend enabling these checks for that reason alone. You’ll also need to turn them on if you want to use Security Hub as the dashboard, or feed compliance findings to tools like ours.

One important point- as of this writing third party tools can’t feed into the Security Standards. They can feed their findings into Security Hub but those findings won’t show up on the dashboards unless you create your own custom Insights.

Integration Magic

Aside from the Security Standards, which enables Config, none of the other integrations are managed through Security Hub, but Security Hub will pick up their findings once you turn them on. It’s a little internal magic for all the AWS services that Security Hub works with.

AWS infrastructure security

Now you might think I’m currently getting Firewall Manager events based on the screenshot above but I’m not. The integration is all up and running but I don’t have anything configured within Firewall Manager.

You see, Security Hub will gracefully connect to all enabled services but still relies on proper configuration of the underlying services. This leads to a few important points:

  1. Remember, Security Hub is region locked and each region will only see the security findings for the other services enabled in the same region. AWS will fix this eventually, but as of this writing it’s where we are for now.
  2. Findings and events from other services feed into Security Hub in pretty much real time. We’ve found no significant delay when we pull in GuardDuty events, for example, via Security Hub. In other news, AWS could use some standards on when how they intercap their service names.
  3. If you set up multi-account aggregation this doesn’t automatically standardize the configurations of the underlying services in the different accounts. This can be an advantage if you want to treat different environments differently, such as skipping the Security Standards for development accounts but keeping them for production accounts.

Now keep scrolling down and you will see all the Security Hub Partner Integrations. These fall into three categories:

  • Findings partners that send findings into Security Hub. These all use the ASFF and are not limited to AWS configuration findings. You can, for example, integrate with vulnerability assessment tools for your operating system/application findings.
  • Take action partners that act on the findings. These can be as simple as accepting notifications or as complex as user-guided or automated remediation, like we do at DisruptOps.
  • Partners, again like DisruptOps, that both send and act on findings.
AWS infrastructure security

Now when I say “findings” remember that every finding is an event. It’s up to the partner to decide when to send their findings in and you will see a spread between time-based batch updates and individual events. Batch updates tend to be used for assessments and individual events for change or trigger based findings, like a potential misuse of a credential. This holds true for AWS integrations as well.

Every partner will have their own configuration instructions. For DisruptOps, it’s under the Integrations tab of our console or you can automate integration with Infrastructure as Code. An advantage of tools like ours is that we can correlate the findings across all accounts and regions, which become especially important as you start manually taking action or enabling automations.

Multiple Accounts, but Not Regions

Although Security Hub does not yet support cross-region aggregation and configuration, it does support multiple accounts. Security Hub uses the Master/Member Account structure. This is (unfortunately) outside of AWS Organizations. To use the Master/Member structure start with a desired Master account, which we recommend is your security operations account. Then issue invitations to all your member accounts by entering the account IDs or uploading a spreadsheet of the IDs.

AWS infrastructure security

It’s a pain to handle in the console, and CloudFormation does not support configuring Master/Member accounts. There are two options to reduce the overhead for those of you with many accounts and regions:

  • Script up a Lambda function or command line tool to automate via API. As painful as this sounds, some of you with large account infrastructures already have some of these capabilities in place. This is even what AWS Control Tower has to do to wire things up, so you aren’t alone.
  • Use a third-party tool (yes, like DisruptOps) that configures Security Hub and aggregates and manages all findings centrally.
  • Tools like ours get to skip the whole Master/Member issue entirely if we need to and just collect findings from the individual accounts and regions.

Forward Those Findings and Events

If you recall from our first post, the secret weapon in Security Hub is the aggregation of all these different kinds of findings and events into a single hub using a single format (the Amazon Security Findings Format, ASFF) and creating CloudWatch Events for the findings. In our next post we will get into the nuances of findings and managing findings, but many of you will want to pull or push these into other tools.

Pulling findings is a single API call using the GetFindings operation (get-findings on the CLI). but generally you will want to use the push method so you get them in near real time.

Every finding is a CloudWatch Event and you can define a CloudWatch Rule to trigger and forward findings using the usual menagerie of CloudWatch actions like sending to SNS or a Lambda function. But Security Hub actually supports three different kinds of CloudWatch Events:

  • Findings, which are triggered by the BatchUpdateFindings and BatchImportFindings events. These are the complete findings in the ASFF.
  • Custom action events for findings. We will talk more about custom actions in a future post, but essentially in the console or via API you can apply a custom action to a finding which creates a new CloudWatch event with the finding and the tag for the action. Thus you can create a CloudWatch Rule that only looks for a “remediate with DisruptOps” custom action which then forwards that event.
  • Custom action events for Insights. We haven’t talked about Insights yet, but they are filtering rules (e.g. all resources with a finding of port 22 open to 0.0.0.0/0). These custom actions create a new CloudWatch Event with the Insight and all the associated resources, but not the findings themselves.

The sweet spot for external integrations like ours is to just send everything. Custom actions are used if you use Security Hub as your console. Sending all events is a simple CloudWatch Rule:

{
"source": [
"aws.securityhub"
] }

The best part? This includes all findings from Guard Duty, Macie, and the other AWS and third party integrations… all in the ASFF for easy parsing.

(For those of you using DisruptOps, we handle this automatically during the integration process).

That’s it for your basic configuration. In the next post we will review the different features in the console to finish up the fundamentals, then we will go more into detail on how to integrate Security Hub into your security operations by getting events and findings into the right hands and taking actions to respond and remediate.

Supercharging AWS Security Hub: 4 Part Series
Part 1   |  Part 2   |  Part 3  |  Part 4

Leave A Comment

About the Author: Rich Mogull

With twenty years of experience in information security, physical security, and risk management, Rich is one of the foremost experts on cloud security, having driven development of the Cloud Security Alliance’s V4 Guidance and the associated CCSK training curriculum. In addition to his role at D-OPS, Rich currently serves as Analyst & CEO of Securosis.

Sign-up for Updates!


Categories