Prerequisites

• Your AWS Organization

• The SecurityAudit account

The Lesson

AWS Security Hub is Amazon’s native… security… hub? I mean, it’s all right there in the name. But Security Hub can be a bit of a tricky beast to wrap your head around, since it combines a few different capabilities, and you might not want or need all of them. Some of its capabilities are awesome, some are okay, and some are really good at increasing your AWS invoice by the end of the second month.

I have a particular way I recommend getting started with Security Hub; then I decide which of its other capabilities to activate.

For simplicity I like to think of Security Hub as providing three primary capabilities:

• Security Hub collects events and results from nearly any other AWS security service, all in one place. So far we’ve only used one of those, GuardDuty, but we will continue to flip the switches on many of the other services as we explore their capabilities. What’s really cool is that Security Hub normalizes findings from those services into a standard format.

• Security Hub can work as a Cloud Security Posture Management (CSPM) tool. Think of CSPM as a vulnerability scanner for your cloud. These tools assess how you have things configured, such as your S3 buckets, and identify problems like public S3 buckets. CSPM is a big topic we will cover in future labs. In Security Hub the rules to check are called Security Standards. Also, by this point you’ve probably noticed that in the security industry we tend to use a lot of silly acronyms. You can blame Gartner for “CSPM” — they’re the ones who made it up.

• Security Hub is one of the only AWS services which can consolidate events and findings across accounts and regions in an Organization! This is one of the best things ever. Why? I can create a single security feed from all the AWS security tools, and track everything in one place, instead of having to change regions all the time like we just did with GuardDuty.

Now a bit of a caveat: when you aggregate findings, they are provided in a different format than the originating service. So for example GuardDuty findings will now be in the standard AWS Security Findings Format (ASFF), which is different than they look inside GuardDuty.

I want to be sure you understand why we are playing with Security Hub today, and why I recommend configuring it this way, even when working with large organizations.

CloudTrail is the main log we want for security, but it isn’t the only one. We started there, and it’s the most important one for seeing what’s going on. The next most important security tool is GuardDuty. CloudTrail tells us most of what’s going on in our account (at least in terms of API calls), and GuardDuty uses threat detection capabilities to identify potential malicious activity, like cryptocurrency mining and brute force attacks.

AWS offers a handful of other important security tools. For example, we can use Inspector to look for vulnerabilities in virtual machines and containers.

These tools are run by different teams in AWS, and each has its own user interface, APIs, and findings. Nearly all require you to turn them on and manage them in different regions — you can’t just set and forget them from one place. And then they only generate results in each region and account they are running in.

Yeah, that’s painful to manage.

Security Hub automagically includes findings from all of them, and aggregates them across accounts and regions. This provides one single place to tap into whatever else we’ve turned on. I like it for simplicity, because even if some random admin turns on some random security tool we don’t use by standard — I still get all the results and alerts, without having to ask them to configure anything.

I still need to manage all the settings in the particular tool and account/region, but Security Hub handles all the results. It even normalizes into a standard format so I can forward those findings someplace else (e.g., my very expensive security blinky light dashboard), and I don’t need to write custom parsers. Heck, Security Hub can even handle findings from third party security products! Like you can buy something else, and if Security Hub supports the Cloud Mutant Attack Detection Tool, you’ll get all those results in the same place too.

Pretty cool. It isn’t always how you want to handle findings, especially from commercial tools who have invested a lot in their user experience (I kid — security companies suck at UX), but it’s definitely worth enabling for the AWS security feeds alone.

Lesson Key Points

• Security Hub includes multiple capabilities, including Cloud Security Posture Management (CSPM) and aggregation of security events and findings from other AWS and third-party tools.

• CSPM is a kind of “vulnerability scanner for cloud” which looks for misconfigurations, such as public S3 buckets. In Security Hub the rules are called “Security Standards”.

• Security Hub is one of the only AWS services which works across accounts and regions. It can aggregate findings and events from all the other tools in all the other places, into a single account and region.

The Lab

In this lab we start in the management account to enable Security Hub and delegate administration to the SecurityAudit account. Then we go into SecurityAudit and configure Security Hub to work across our entire organization.

But an important point: we will disable all the Security Standards! Active Security Standards quickly increase costs, but using Security Hub as a central feed is pretty cheap, especially for small accounts.

Video Walkthrough

Step-by-Step

As usual, start in your Identity Center Sign In Portal. Before we log into anything else, get the account ID for SecurityAudit.

Then select CloudSLAW > AdministratorAccess.

Make sure you are in Oregon, then go to Security Hub, and Go to Security Hub. (Apparently going to Security Hub does not actually go to Security Hub?)

Don’t enable Config, even though it tells you to!!! Unless you like burning money. There’s a time and place for Config, but it is not today.

Then scroll down and disable the Security Standards! We will play with them later. Today we’re going to save money. Two will be checked by default — disable them:

Paste in your SecurityAudit account ID, then click Delegate, and after that’s done click Enable Security Hub:

Now sign out of the management account:

Next go into SecurityAudit and SecurityFullAdmin, then SecurityHub:

Oh, hey, 2 of the Security Standards are enabled anyway? Let’s fix that right away (don’t worry — without Config they don’t work anyway).

Go to Security standards and disable the two which are enabled. I think a step we take later would fix this, but I’m not certain and don’t want to take a chance, so do this now to be safe:

Now go to Configuration and Start central configuration:

The default settings should be right, but double-check your Home Region is Oregon, then Confirm and continue.

Wait for the little spinners in the user interface to catch up, and then set your Configuration type. Choose Customize my Security Hub configuration, or a bunch of those things we keep turning off will be turned back on. I don’t blame AWS — we are not setting things up normally.

Our first change is to disable the AWS Foundational Best Practices security standard. Click the X:

We will leave the rest of the defaults on this page, and click Next:

Nothing to change on the next page, but confirm it looks like this (with your own Account ID, of course):

Then keep scrolling and Create policy and apply:

Now everything is configured the way we want it. Hop over to the Integrations page and just scroll around to see all the tools now feeding their results to Security Hub:

That’s it for this week! Security Hub is now enabled using Delegated Administration, collecting all the findings and events from all the other AWS security tools and consolidating them into us-west-2 (Oregon) in the SecurityAudit account. We aren’t scanning for misconfigurations — we will cover that in future labs.

-Rich