AWS infrastructure security

Supercharging Security Hub: Part 3, Taming the Console

In our last post we covered getting started with Security Hub and how to set up an optimized configuration, including prepping forward findings for alerting or remediation. Now although we’ve introduced the core capabilities, in this post we’ll walk through the different parts of the console and how the set them up to be most effective.

Keep in mind that many Security Hub users skip the console completely, especially if you are responsible for multiple regions and prefer to work with aggregated data. Even so we think you can learn more about the capabilities with a good old fashioned walkthrough.

Summary

This is a dashboard. You do not get to configure it. If you click on things they take you into other sections, like… a dashboard. There really isn’t much to say here except… dashboard.

AWS automation

Security Standards

Consider this the compliance section. As of this writing Security Hub supports assessing for three different standards- AWS Best Practices, the CIS Benchmarks, and PCI. I’d say it’s a good bet they will add more. Under the hood most of the assessments are handled with Config. Although there are a bunch of third party tools in the Security Hub Integrations that perform compliance checks, those tools can’t feed this section. This means the results here are always based on an AWS-provided assessment. If your compliance needs fit the provided standards this is a very AWS-native and effective way to assess them.

Within this section there are a few tricks to get more value. Aside from the big trick of turning the standards on and meeting probably 90% of most of your AWS basic compliance assessment needs. This is also one of those services worth keeping an eye on since AWS appears to be well down the path of continuously adding the major standards. For our walkthrough let’s check out the AWS Best Practices results:

AWS infrastructure security

The one trick is that you can disable any single requirements check. This is important because Config can only confirm you are exactly compliant exactly as Config expects, and it is unable to account for alternative ways of complying with the requirement or for compensating controls. Or, and let’s be honest here, some requirements just don’t apply to your org.

AWS governance

Click on any of the requirements and it brings you to a drill down of the Findings. This is where a really useful feature appears — workflow status.

AWS governance

Every finding has a status and these can be set via the console or API. You can then filter findings based on status. It isn’t as robust as a full workflow management tool, but since it’s supported natively and universally in Security Hub it can be very useful when writing your own automations or integrating with third party tools since it then provides a single source of truth on status.

Just another example of AWS putting the Hub in Security Hub.

Once you click on a finding the details open up on the right, and there are two non-obvious parts I think are interesting:

AWS governance

Clicking on Rules takes you right to the Config rule that created the finding so you can understand what it’s really looking at. Remediation is always just text or a link, but is a good shortcut to better understand the issue.

As a reminder, Security Hub is single region even when you set it up for multiple accounts (for now). You will need to use other products or your own automation to aggregate these results across regions.

Insights

Think of Insights as the real meat of the console version of Security Hub. Unlike Security Standards, which are there to check the compliance box, Insights supports full customization. And as you can see in the screenshot, it comes with a bunch of interesting ways of slicing the findings data and track trends over time.

AWS automation

But the real power of insights is that they aren’t just for pretty dashboards, they are an API-enabled feature! This means you can create Insights in the console or via API and then use the results in your own automations.

In this screenshot I’ve created a custom insight for high and critical severity events with a status of New. I also clicked on the filter bar just to show how easy it is to add filtering and grouping options (I could have grouped my findings by Account ID, for example.

AWS governance

And here are the results using the command line interface (with additional commands I could list out all the findings):

AWS automation

To me this makes Insights far more useful. I can let AWS do all the heavy lifting of querying and grouping. Sure, I can write it all in code myself but this is more efficient for the kinds of filtering that Insights supports. Once you get the results the drill-down looks nearly identical to a Finding in the Security Standards section.

And remember, since Insights are fully API accessible and the filters are based off the ASFF that means two important things:

Insights will work across any product or service integrated into Security Hub, including third party tools.
External tools and automations can directly access Insights. You aren’t restricted to using them in the portal.

Findings

This section is the raw firehose of findings and events. But notice those buttons up at the top?

AWS automation

This is a slick little portal feature; as you are filtering and looking through your Findings you can save the results as a new Insight.

Some of you may be wondering why I keep skipping over the Actions button that appears in a few spots. Actions is a bigger discussion worthy of a dedicated post, so we’ll get there.

Clicking on any finding opens up the details panel that we previously discussed, so there isn’t much more to talk about here.

Integrations

It’s pretty important to understand some of the nuance of integrations. Integrations fall into four different categories:

  • Tools that send findings to Security Hub.
  • Tools that receive findings from Security Hub.
  • Tools that can take action on Security Hub findings.
  • Tools that combine two or more of these categories. For example, DisruptOps can send findings, receive findings, and take action on findings.

There are three ways to enable an integration, depending on the type of integration:

  • If it is an AWS service, click “Accept Findings”.
  • If it is a third-party service that sends to Security hub, first follow the product’s configuration instructions and then click “Accept Findings”.
  • If it is a third-party service that only receives findings you configure that completely in the service and there isn’t anything to manage in Security Hub.
AWS infrastructure security

There may be additional setup for event-driven tools, which I covered in our last post.

Settings

I am mostly going to skip the Settings since everything in here is pretty obvious except Actions, which we will dive into separately. There is one nice surprise in there though:

AWS automation

This post is far from a full walkthrough of every little widget and knob; there is no reason to duplicate the AWS documentation. Instead I highlighted some cool capabilities that might not be obvious, and tried to bring in some context that I personally found confusing when I was first getting started with Security Hub.

That’s it for the console, and in our next post we will get into the meat of using Security Hub to take action and turn it into a powerful tool for automation and remediation.

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.
free- trail

Sign-up for Updates!


Categories