Security Hub is a Cloud Security Posture Management (CSPM) service that you can use to perform security best practice checks, aggregate alerts, and enable automated remediation in Amazon Web Services (AWS).
This post comes from our Introduction to AWS Security course, where we look at a few ways that we can find and remediation security issues in AWS accounts and resources, but a lot of it is decentralized which can make it very difficult to manage and keep an eye on as you scale. Security Hub can help us with that.
The service currently works with:
- Systems Manager
- Firewall Manager
- AWS IAM Access Analyzer
- AWS Health
- Amazon Macie
- Integrated partner solutions
It can take findings from all of those sources to aggregate them and prioritize them.
It can also run security best practice configuration checks with something called the AWS Foundation Security Best Practices standard, as well as other industry benchmarks like CIS and PCI.
As Security Hub aggregates and prioritizes findings, it can then work with other services to enable automated remediation, or alerting, so that someone or something can take action.
For example, if you use a SOAR solution, Security Hub can automatically enrich findings and send them to a ticketing system to initiate your SOAR workflows. The same is true if you run a SIEM solution.
So Security Hub’s aim is not to replace SIEMs, but it does act as a sort of mini-SIEM. Again, this is referred to as a CSPM.
Prefer watching videos to reading? This blog post is in video format!
Enable Security Hub
Let’s take a look at how it works by enabling Security Hub’s 30-day free trial.
The good news is that Security Hub pricing is quite reasonable if you’re running small workloads on AWS. Even very large organizations wouldn’t end up paying all that much as you can see from their examples on the pricing page (towards the bottom of the page, they have examples for different size organizations).
Go to Security Hub. Right away we’ll see that we need to enable AWS Config in order to enable Security Hub Standards and controls.
If you have Config enabled, then you should be good to go. Otherwise, you may want to do that as you may otherwise experience issues.
Next, we can select the
Security standards that we’re interested in enabling. Here’s a page in the AWS documentation that describe security standards in more detail if you’re interested: https://docs.aws.amazon.com/securityhub/latest/userguide/standards-view-manage.html
The main reason this is important is because you will get a security score calculated by Security Hub over time, and the score will depend on the standards you’ve selected.
It’s definitely worth spending some time looking up these standards if you’re not already familiar with them. I’ll leave the defaults selected and then
Enable Security Hub.
Once enabled, it can take up to 2 hours to see results from security checks. While that’s working behind the scenes, we can take a look around the console.
Right up-front, we’ll see the security standards that we enabled and how many checks were passed, failed, and the % score.
We then have a table for the “resources with the most failed security checks,” “findings by region,” and more information about findings for various services.
If we scroll all the way at the bottom, we’ll see findings from the AWS integrations that we talked about at the beginning like GuardDuty, Inspector, Macie, etc…
In the left menu, we can click on
Controls to view a dashboard that provides more detailed information about failed controls. Initially you won’t see anything, but if you have any failures, you would see them here.
Next if we click on
Security standards, we’ll again see a breakdown of the standards we’ve enabled and any others that we could enable if we wanted to.
Insights, by default, you’ll see a list of multiple pre-created insights which are Security Hub managed insights.
This helps organize and group important findings, but you could also create your own insights if you wanted to.
We can then go to a list of all the
Findings where we can filter, select, set a
Workflows Status for a finding, which helps you track the progress of your investigation for a specific finding.
Next we have
Integrations where we can either control integrations into Security Hub from AWS services or from third-party integrations, or we can send findings from Security Hub to other integrations.
There’s AWS Chatbot, for example that could send findings to Amazon Chime, Microsoft Teams, or Slack.
You could even auto create tickets in Jira through their third-party integration…
…and so on.
There’s quite a significant amount of integrations as you can see here.
We then have
Automations. Automation rules are used to update findings in Security Hub.
This is useful when you want to automatically suppress a type of findings, change the severity level from the default to a custom one, or even add your own notes to findings.
Security Hub can only infer so much about these findings based on what it knows, but one finding could be a low severity for a non-critical workload, while it could be a critical finding for a business-critical workload.
We won’t go into automations for this lesson, but be aware that it exists!
Finally, we have settings. Here we can manage multiple accounts if you use Organizations. We can also turn on Region aggregation if we’re enabling Security Hub for multiple regions.
We can configure custom actions with sending insights and findings to Amazon EventBridge.
We can get an overview of our usage of this service to get a sense of costs for the month.
And we can view or edit general settings, which is also where you can
Disable AWS Security Hub if you want to.
Now that some time has passed, let’s go back to the main
Summary dashboard to see if we have a security score yet.
If you don’t, then give it another hour or so, and come back later.
As you can see, we have a calculated score which isn’t great! We can definitely do better.
We can see a breakdown of information, and we can dive deeper to start remediating some of these issues.
Let’s go through one just as an example. If we go back to
Findings and sort the
Severity from most critical to least, we can see what’s most urgent to address. Let’s look for one that says
Ensure IAM password policy requires minimum password length of 14 or greater and let’s click on that title.
This will open a side tab that shows
Details and a
History. The details provide a
Finding ID as well as the
Severity label, affected
Resources if any, the ability to investigate in
Detective if you still have that enabled, and
You can click on the provided link and it will take you to Security Hub documentation, like this: https://docs.aws.amazon.com/securityhub/latest/userguide/iam-controls.html#iam-15
Here it says that:
To change your password policy, see Setting an account password policy for IAM users in the IAM User Guide. For Password minimum length, enter 14 or a larger number.
If we navigate to the provided link (https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) we can go down to Setting a password policy (console) and see exactly how to fix the issue which I’ll do by going to
Account Settings →
Edit and change the default from 6 characters to 20 (or whatever you want, as long as it’s more than 14).
Save changes, and now if we go back to
Security Hub, we can mark this as resolved by scrolling back up, clicking on
Workflow status and
If you now click on the
History tab, you’ll see a trail of when this was initially detected, the workflow changes, and exactly who change it and on what date/time, which leaves a paper trail.
That’s it! We’ve now learned what Security Hub can be used for, and we’ve learned how to get started with it. We also saw that there are quite a few integrations available, so feel free to play around with it!