Control Tower update to Landing Zone 3.0 causes failure in Security Hub AWS Foundational Security Best Practices rule Config.1

Question

I have an organization that's updating its accounts to Control Tower Landing Zone 3.0. As we do so, we're finding that the upgraded accounts fail Security Hub AWS Foundational Security Best Practices rule Config.1 "AWS Config should be enabled". The failure appears to be caused by a change to Config where global resource recording only happens in the home Control Tower region. The Config.1 failures we see are in secondary regions, and we confirmed that the failing accounts don't have global resource recording active in the secondary regions.

My question is: is there a plan to update the Security Hub rule to reflect the Control Tower change? Control Tower has it right, we only need to record global resources in one region. It's also very annoying to undo the change in Landing Zone 3.0 as we have to move accounts out of CT-managed OUs or log in as the CT role to change Config.

Accepted Answer

I have been seeing this issue as well. At re:Invent this year I had many discussions around this and am working with an SA to demonstrate the problem.
The SH Check Lags behind Control Tower protect that setting on Config in all regions that are not your primary/home.
The alternative I am looking at currently is to globally disable the check with a description using this solution:
https://github.com/aws-samples/aws-security-hub-cross-account-controls-disabler

Let me know if you have any questions on that. I have successfully deployed it and testing CIS checks currently.

Answer

Thanks, good to know that I'm not seeing things. The global enabler/disabler solution is interesting but I wish the SH team would make this a feature of delegated management.

Control Tower update to Landing Zone 3.0 causes failure in Security Hub AWS Foundational Security Best Practices rule Config.1

関連するコンテンツ