CIS 4.1 remediation fails and is not remediate in v1.5.0

[andm1]

Describe the bug

After being v1.5.0 , CIS 4.1 remediation fails and is not remediate.
the workflow of SecurityHub has been changed to "NOTICED" and the following comments are displayed.
”update_text
Security Standard CIS v1.2.0 control 4.1 has no automated remediation.”

Also, there are some issues founded as follows;

• the execution log of StepFunction says that the document cannot be found.
  ChoiceStateEnteredAutomation Doc Active
  　　"AutomationDocument": {
  "ResourceRegion": "ap-northeast-1",
  "DocState": "NOTFOUND",
  "SecurityStandardVersion": "1.2.0",
  "AccountId": "XXXXXXXXXXXX",
  "Message": "Document SHARR-CIS_1.2.0_4.1 does not exist.",
  "AutomationDocId": "SHARR-CIS_1.2.0_4.1",
  "RemediationRole": "SO0111-Remediate-CIS-1.2.0-4.1",
  "ControlId": "4.2",
  "SecurityStandard": "CIS",
  "SecurityStandardSupported": "True"

• There are no CIS 4.1 SSM parameters in the resources deployed in CloudFormation (solutions/SO0111/CIS/4.1/remap)

Please complete the following information about the solution:

• Version: v1.5.0
• Region: ap-notheast-1
• Was the solution modified from the version published on this repository? - No
• If the answer to the previous question was yes, are the changes available on GitHub?
• Have you checked your service quotas for the sevices this solution uses? - Yes
• Were there any errors in the CloudWatch Logs? Troubleshooting - No

Screenshots

[hearde]

Can you please start with these troubleshooting steps:

1. Confirm the member stack is deployed in the admin account and the account where the remediation is being attempted
2. Confirm the control parameter is "available" in the member stack parameters for CIS - it's a nested stack so you'll need to navigate to the nested stack in cloudformation rather than the top-level member stack

If both of those are true, then this sounds like a bug.

As a side note, it's not unexpected for there not to be a parameter solutions/SO0111/CIS/4.1/remap since the original finding was under control CIS v1.2.0 4.2, which gets remapped to 4.1 with the parameter solutions/SO0111/CIS/4.2/remap.

[andm1]

Appreciated for your quick response.

1. Confirm the member stack is deployed in the admin account and the account where the remediation is being attempted

For the admin account, the following templates have been deployed. This is the state as shown in the screenshot image.
https://solutions-reference.s3.amazonaws.com/aws-security-hub-automated-response-and-remediation/latest/aws-sharr-deploy.template

Also, for the member account where the remediation is being attempted, the following two templates are deployed in Stacksets.
https://solutions-reference.s3.amazonaws.com/aws-security-hub-automated-response-and-remediation/latest/aws-sharr-member-roles.template
https://solutions-reference.s3.amazonaws.com/aws-security-hub-automated-response-and-remediation/latest/aws-sharr-member.template

Are these steps correct and enough?

2.Confirm the control parameter is "available" in the member stack parameters for CIS - it's a nested stack so you'll need to navigate to the nested stack in cloudformation rather than the top-level member stack

In the CIS parameter list, I found the "Enable41" is "available".
These are screenshots of parameter tab and templetes tab of member account:

[hearde]

If I'm understanding correctly, you're saying that the admin account has the stack aws-sharr-deploy.template deployed (and its nested stacks), and the member accounts have aws-sharr-member.template and aws-sharr-member-roles.template deployed (and their nested stacks).

The problem is that all three stacks need to be deployed into the admin account for any remediation to complete - not just for this control (CIS 4.1). So the admin account should have these three stacks (and their nested stacks):

• aws-sharr-deploy.template
• aws-sharr-member.template
• aws-sharr-member-roles.template

And the member accounts should only have the member templates deployed (and their nested stacks):

• aws-sharr-member.template
• aws-sharr-member-roles.template

I realize this is not obvious from the template names. Sorry for the confusion. I also reviewed our implementation guide and it does not make this very clear either. I'll add an item for us to clarify this in a future update to our documentation.

If you continue to run into errors after installing those templates, please continue to update this bug.

[hearde]

To correct my earlier comment, deploying the member and member-roles stacks in the admin account is only necessary if you want to remediate issues in the admin account. What you described is a correct way to set up the solution.

We will try to reproduce this and figure out what's going on.

[hearde]

We have been unable to reproduce this issue. Please reopen this if you can provide steps to reproduce this in the latest version.