Today I would like to write about AWS Security Hub Central configuration, a feature announced at AWS re:Invent 2023.

At the company called Kaminashi I work for, we already have a Security Hub in operation. However, we are halfway to the ideal situation where developers themselves understand the risks and proactively respond to them.
That being the case, Security Hub Central configuration is a highly recommended feature that may help.

AWS Security Hub Operational Issues and Central configuration

I was unaware that this feature had been added until recently.
But this feature is indispensable for operating Security Hub. The reason for this is that in Automation rules, it is not possible to write rules by OU or by identifying tags, etc. attached to an account. However, when AWS accounts are managed by Organization, there are various cases such as Sandbox OUs, accounts for prototype implementation, accounts for personal verification (which may be included in Sandbox OUs), etc. How do you control these accounts? You need to think about that.
Because when you want to try out a workshop and Security Hub detects something that is not so dangerous, you may think, “Forgive me, it's only temporary”.
And because of this, there are times when you might want to disable Security Hub itself for such accounts, or loosen the rules. Central configuration can be used for this purpose.

Notes on activating AWS Security Hub Central configuration

Note that enabling Central configuration while Security Hub is already enabled will cause AWS Config to be redetected.

the image attached below is what you will see after activating the Central configuration.

In this state, the policy is self-managed, but the account owner is configuring it individually.
If that is what you intended, fine, but if you want total control and it is happening, you need to be careful.
However, there are times when Self-managed is effective, and those are when an account has already been suspended and cannot be excluded from Organization. In such a situation, the new policy cannot be applied. If that happens, the policy status of that higher OU will be failure. In such a case, please try to change the policy status to Self-Managed to make the policy status successful.

Yes, so let's start by creating a default policy. Then apply it to the Root OU. By doing so, the rule is applied to all accounts under the OU to which it belongs. The same policy will also be automatically applied to any accounts created thereafter.

Now let's look at policy creation.

This is how it looks like, the recommended setting type is "Use the AWS recommended Security Hub configuration across my entire organization", but if you choose this, only the "AWS Foundational Security Best Practices v1.0.0" security criteria are in effect and cannot be changed.

So, although it is recommended, do not use this, but select "Customize my Security Hub configuration" and choose the minimum security criteria to be used by your organization.

Incidentally, if you choose "Use the AWS recommended Security Hub configuration across my entire organization" without customization, you will not be able to change the policy name, and a policy with the very subtle name “configuration-policy-01” will be created initially.(It can be changed later)

Confirmation of configuration

Once successfully configured, you will see the following on Security Hub overview page for each AWS account.

And if you try to activate the security criteria on this page, you will get the following error message.

In the account to which the administration of Security Hub has been transferred with the Central configuration set up, you will see that the policy has been applied as shown in the image below upon success.

Furthermore, if a strict policy is applied to the Security OU, which sets all security criteria, the following image shows that only the Security OU has the restrict-policy while the other OUs remain in the general-policy.

Very good points about Central configuration

As you may already know from what we have seen so far, what is good about this Central configuration is that you can centrally manage whether or not to activate Security Hub in the first place. As you can see when you do an AWS workshop with a personal verification account, resources that are out of compliance are usually created. I don't want to be notified of alerts in those situations.
And it is not hard to imagine that it would be very noisy in a workshop with all the developers participating. So the first good thing is that you can choose to disable Security Hub only for such OUs and accounts. Also, since security standards can be changed flexibly, you can choose PCI DSS only for services that handle credit cards, or choose a security standard that meets your organization's guidelines if you do not handle credit cards. In other words, you can set stricter standards for production and staging environments, and slightly looser standards for development environments, and so on, depending on the environment.
Oh, how wonderful!

And, as before, you can choose which of these controls to activate, adjust the parameters of the controls, and make other flexible settings!

Conclusion

Personally, I am really happy to be able to do better what I could not do with Automation rules. This is exactly what I have been waiting for.
This is a good opportunity for everyone to rethink the operation of Security Hub.

Thank you for reading to the end.