Security Hub now supports Custom AWS Config Rules
3 min read
AWS recently announced an integration that I'm a little excited about!
AWS Security Hub now receives AWS Config managed and custom rule evaluation results
This post provides a summary of what it looks like and a little about its potential.
For those that follow AWS service releases you'll know it's not unusual for services to overlap in functionality or potential functionality might be a better term....
We started out with AWS Config back in 2015, then Macie, then GuardDuty
Then along came Security Hub.
Security Hub promised to be the one stop place all these services would report to as quoted in the announcement.
AWS Security Hub also automatically aggregates, normalizes, and prioritizes findings from AWS services, including Amazon GuardDuty, Amazon Inspector, and Amazon Macie, and from 30 AWS partner security solutions. Security Hub brings these findings together in a single dashboard that consolidates them into easy-to-understand and actionable graphs and tables and correlates findings across providers to help prioritize which resources require remediation actions.
However, this fell a little short as those who had taken AWS Config by the horns and deployed standard and custom near real-time complaince rules still had to create bespoke automation to properly report on these across multiple accounts.
We had the CIS Security Standard that used AWS Config Rules to drive Security Hub which seemed to set the direction, but then we got AWS Config Compliance Packs... which really didn't make much sense and seemed to muddy the waters on which way things were going...
Setting the direction
Finally the ship seemed to be steered back on course with the release of AWS Security Hub Foundational Security Best Practices standard.
This seemed to get the AWS Config team excited also and since then we have seen a stream of managed AWS Config rules developed and the Foundational Security Best Practices standard has been increasing ever since. Not that I agree with every single one of those best practises however....
But something was still missing...
What about those custom rules that we had developed using the awesome AWS Config Rule Development Kit? We still had to either use an AWS Config Aggregator or some bespoke solution to report or act on these across multiple accounts.
What about the custom policy rules we can now create with the new cfn-guard AWS Config integration, see my post here?
That's why I'm excited, but enough what does it look like?
The User Experience
We create a custom rule that checks if point-in-time recovery (PITR) is enabled on active Amazon DynamoDB tables.
Next, we create a non-compliant DynamoDb table.
When we check the status of the rule we can see the table has been picked up.
As per the documentation here, to view our findings in Security Hub we need to
Choose Findings from the Security Hub navigation pane. To filter the findings to display only AWS Config findings, choose Product name in the search bar drop down. Enter Config, and choose Apply.
Note: When AWS Config creates a new finding, you can usually view the finding in Security Hub within five minutes.
And here we have our findings in Security Hub!
As with all things in Security Hub we can click the finding to get more information.
As you can see above we now have much better integration for our custom rules.
If you have a multi-account setup within your organization all these findings will be passed to the central account where you can either alert on or feed this information into ticketing systems for resolution.
For me this has been a long time coming and I'm pleased to see this now enabled.
Hope this helps someone else!
Did you find this article valuable?
Support Stephen Jones by becoming a sponsor. Any amount is appreciated!