Security Hub: CIS controls not disabled

[ghost]

Describe the bug In the security config if you try to disable CIS controls using the syntax specified in the best practice files the control will not be disabled. The "AWS Security Best Practice" and "PCI-DSS" standards are unaffected and work as intended.

The format that does not work is using the CIS prefix, e.g:

    controlsToDisable:
      - CIS.1.17
      - CIS.1.16

A format that does work is passing a string of just the control number (as it appears in SH), e.g:

    controlsToDisable:
      - "1.17"
      - "1.16"

To Reproduce Edit the security config and use the format as described as above. Run the LZA pipeline. Once complete review Security Hub, the control will still display "enabled".

Expected behavior The control should be disabled in Security Hub.

Please complete the following information about the solution:

• [ ] Version: v1.3.0
• [ ] Region: eu-west-2
• [ ] 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? N/A
• [ ] Have you checked your service quotas for the sevices this solution uses? N/A
• [ ] Were there any errors in the CloudWatch Logs? No. There are also no API calls made to "UpdateStandardsControl".

[crissupb]

Thank you for your feedback. We will look into this issue.

[msambol]

@juujii: One follow-up question. Can you confirm the control is or isn't disabled on the control's details page? I've seen the Console show 0 disabled on the main Security Hub page:

But clicking on the control, it's actually disabled:

Please let me know what you see, using the config that you first tried:

    controlsToDisable:
      - CIS.1.17
      - CIS.1.16

[ghost]

Hey @msambol,

I have confirmed my shows "Enabled" via the Security Hub GUI. I also checked via the CLI, screenshots attached.

SH:

CLI:

CC:

[msambol]

@juujii Thanks for confirming that! I'm wasn't able to replicate the error. Do you mind looking in one more spot for me? There is a Lambda that disables controls. Can you check the log group and let me know if you see something that doesn't look right? It will be named as follows: /aws/lambda/AWSAccelerator-SecuritySt-CustomSecurityHubBatchEn.... and you can look for updateStandardsControl.

[ghost]

Hey @msambol - that's weird! So yours works with the normal syntax?

I had a look at what you mentioned and took the following steps:

1) Starting with a clean slate (no CIS controls disabled) I ran the pipeline with the following config:

    controlsToDisable:
      - CIS.1.17
      - CIS.1.16
      - "1.4"
      - "1.5"

Once deployed I could validate that only 1.4 and 1.5 were disabled via CLI:

I could also see API hits for UpdateStandardControl but only for CIS 1.4 and 1.5:

I can also see this reflected in the Lambda logs:

The only other thing to mention is that I can see the JSON object being processed in the Lambda that includes all the controls (1.16, 1.17, 1.4, 1.5):

If yours definitely works then maybe I'll spin up another clean LZA to test.

[bo1984]

Hello @juujii , thank you for utilizing the Landing Zone Accelerator on AWS solution.

I believe this issue may be related to how Security Hub has mapped some of controls to the respective Security Standards that it supports - https://github.com/awslabs/landing-zone-accelerator-on-aws/issues/229

As this issue has been open for a while, please let me know if the documentation in the referenced GitHub issue helps. I will keep this issue open for the time being in the event further investigation is needed.

[RyanGhavidel]

we have the same problem! Lambda logs indicates the list of controls to disable with no errors. But, simply nothing happens in Security Hub. i.e. it does not disable them.

[bo1984]

Hi @RyanGhavidel !

We have noticed inconsistent issues across the supported security standards within AWS Security Hub. I am investigating this on my end and will provide further updates as they become available.

[schnipseljagd]

We are running into the issue that controls are not disabled too. The Cloudformation change set clearly states the list of controls to be disabled by the custom resource:

The Lambda logs also state that the controls should have been disabled:

2024-07-16T12:53:24.456Z    dbda182f-62b0-48ae-99d9-2ac211bc02a2    INFO    [AWS securityhub 200 0.61s 0 retries] updateStandardsControl({
  StandardsControlArn: 'arn:aws:securityhub:us-east-1:xxxxxxxxx:control/aws-foundational-security-best-practices/v/1.0.0/Inspector.4',
  ControlStatus: 'DISABLED',
  DisabledReason: 'Control disabled by Accelerator'
})

And the interesting thing is that in our home region eu-central-1 they were deactivated as expected. In us-east-1 (the screenshot above is from the us-east-1 Cloudformation change set) the custom resource Lambda run successfully but the controls are still enabled.