Table of Contents
1. Help us manage security controls in one place
2. The caveats
2.1. Don't forget to enable AWS Config if you want to get findings
2.2. Use the right template
3. Painful experiment
In my previous post, I've mentioned the new AWS Security Hub Central Configuration feature. I thought AWS finally solved the headache we face when managing Security Hub in cross-account, cross-region environments. It's kind of true, but not a lot.
Help us manage security controls in one place
Let's talk about the good first. Security Hub central configuration helps us manage the security controls on different accounts, different regions.
When we enable central configuration, we can pick the regions, and the policy we create later will be deployed to the selected regions.
We can then create different policies on the following:
What security standards to deploy
What controls to enable/disable
Customize control parameters
These policies can be deployed to all accounts or the accounts we specify so that we can configure different accounts differently.
The caveats
OK, we've finished talking about the good part. Let's talk about the dark side.
Don't forget to enable AWS Config if you want to get findings
So the AWS blog post claimed we can "using a single action to enable Security Hub across your organization"
Right, but it only turns on Security Hub. If we want to get findings, we still need to enable AWS Config on all the accounts, ... manually.
OK, fine!! So I scrolled down a little bit and found this.
"if AWS Config is not yet enabled in an account, the policy will have a failed status."
I then tried to deploy Security Hub on my AWS Organization, which I only turned on Config on 1 account.
Guess what? I got the green lights for all 3 accounts.
Maybe I forgot that I had enabled Config on these accounts, or maybe Security Hub helped me turn them on?
So, I waited 2 days for the findings to come. But then, the account that had Config enabled already had many findings, but the 2 without Config only got 17 findings.
So I went on and used CloudFormation StackSet to enable AWS Config for these 2 accounts.
At that point, I was pretty sure AWS Config was not enabled because the StackSet wouldn't succeed if so.
I don't know what's going wrong, but after enabling AWS Config, the findings finally came.
I still don't understand why the error message didn't come.
But the main takeaway is: Make sure you have AWS Config enabled on all relevant accounts if you want to get findings from AWS Security Hub.
Use the right template
Another interesting point (but not related to this new feature) is the template we use to enable AWS Config.
The CloudFormation StackSet console has a sample template called "Enable AWS Config".
But if you only want to get AWS Security Hub findings, DON'T use it.
There is another StackSet template here.
This template only enables configuration recording on resource types that Security Hub cares about.
Using this one could help you save money by not recording resources that Security Hub doesn't look at.
Painful experiment
So, now I still can't figure out why my child accounts could pass the checking even though AWS Config was not enabled.
I'll need to create another clean AWS Organization to test out.
Experimenting with things on Cloud Governance is really a painful task.
I can't simply nuke the resources to restart because what I'm testing is the Organizations; the accounts.
And now, I need to restart everything again.
In my previous post, I've mentioned the new AWS Security Hub Central Configuration feature. I thought AWS finally solved the headache we face when managing Security Hub in cross-account, cross-region environments. It's kind of true, but not a lot.
Help us manage security controls in one place
Let's talk about the good first. Security Hub central configuration helps us manage the security controls on different accounts, different regions.
When we enable central configuration, we can pick the regions, and the policy we create later will be deployed to the selected regions.
We can then create different policies on the following:
What security standards to deploy
What controls to enable/disable
Customize control parameters
These policies can be deployed to all accounts or the accounts we specify so that we can configure different accounts differently.
The caveats
OK, we've finished talking about the good part. Let's talk about the dark side.
Don't forget to enable AWS Config if you want to get findings
So the AWS blog post claimed we can "using a single action to enable Security Hub across your organization"
Right, but it only turns on Security Hub. If we want to get findings, we still need to enable AWS Config on all the accounts, ... manually.
OK, fine!! So I scrolled down a little bit and found this.
"if AWS Config is not yet enabled in an account, the policy will have a failed status."
I then tried to deploy Security Hub on my AWS Organization, which I only turned on Config on 1 account.
Guess what? I got the green lights for all 3 accounts.
Maybe I forgot that I had enabled Config on these accounts, or maybe Security Hub helped me turn them on?
So, I waited 2 days for the findings to come. But then, the account that had Config enabled already had many findings, but the 2 without Config only got 17 findings.
So I went on and used CloudFormation StackSet to enable AWS Config for these 2 accounts.
At that point, I was pretty sure AWS Config was not enabled because the StackSet wouldn't succeed if so.
I don't know what's going wrong, but after enabling AWS Config, the findings finally came.
I still don't understand why the error message didn't come.
But the main takeaway is: Make sure you have AWS Config enabled on all relevant accounts if you want to get findings from AWS Security Hub.
Use the right template
Another interesting point (but not related to this new feature) is the template we use to enable AWS Config.
The CloudFormation StackSet console has a sample template called "Enable AWS Config".
But if you only want to get AWS Security Hub findings, DON'T use it.
There is another StackSet template here.
This template only enables configuration recording on resource types that Security Hub cares about.
Using this one could help you save money by not recording resources that Security Hub doesn't look at.
Painful experiment
So, now I still can't figure out why my child accounts could pass the checking even though AWS Config was not enabled.
I'll need to create another clean AWS Organization to test out.
Experimenting with things on Cloud Governance is really a painful task.
I can't simply nuke the resources to restart because what I'm testing is the Organizations; the accounts.
And now, I need to restart everything again.
Top comments (0)