In this website post, you’ll find out about an automated process for disabling or enabling selected AWS Security Hub controls across multiple accounts and multiple regions. You know how exactly to disable Security Hub controls through the Security Hub console, or utilizing the Security Hub update-standards-control API . However, these procedures focus on a per account and per region basis. If you wish to tune your posture by disabling some controls across multiple accounts, this automated approach helps it be easier.

The update Security Hub controls script provided in this article uses cross account access to disable or enable several controls across multiple accounts and multiple Regions on an random basis, and never have to maintain resources in each Region. These accounts could be individual accounts where Security Hub is managed independently per account, section of a Security Hub administrator setup, or perhaps a combination of these. You need to execute this script in newly added AWS accounts again to help keep the controls status consistent for new accounts.

 

This website also describes another solution which automates updating Security Hub controls on a schedule for just about any new AWS accounts which are added, and keeps the control status in member accounts in keeping with the controls status in the Security Hub administrator account. The alternate solution is only going to work if you are using Security Hub administrator setup, and should be deployed on a per Region basis.

Why disable controls?

Security Hub generates findings from continuous checks against a couple of rules from supported security standards. These checks give a readiness score and identify specific accounts and resources that want attention.

It could be useful to switch off security checks for controls that aren’t highly relevant to your environment. Disabling irrelevant controls helps it be simpler to identify the important findings you could do something on.

Reasons to disable controls

There are many reasons you may elect to disable controls:

• Controls for unused services
• Controls using global resources
• Controls with compensating controls

Unused services

If you’re not utilizing the specific AWS service that a control is enabled, you might like to disable controls which have periodic checks connected with that ongoing service.

Note: Periodic checks run every 12 hours automatically, whereas change-triggered checks run once the associated resource changes state. Change-triggered checks usually do not run if the associated in scope resource will not exist, so you don’t need to disable controls that use change-triggered checks explicitly.

For instance, SageMaker.1 is really a control which has a periodic check and is area of the AWS Foundational Security GUIDELINES standard. If you don’t use Amazon SageMaker in your environment, it is possible to temporarily disable this check. In the event that you disable an unused check and begin using the service in the foreseeable future later, you need to again enable the check. You need to perform regular analysis of services used across your AWS Accounts.

Global resources

Global resources, such as for example AWS Identity and Access Management (IAM), generate findings in each region where you have Security Hub enabled. To target only on meaningful findings, it is possible to disable controls for global resources in every but one Region. You shall need to align the required region to function as same Region in AWS Config where global recording is enabled. A summary of all such controls for every standard are the following:

Compensating controls

You might disable a Security Hub control that a compensating control is set up. For instance, the AWS Foundational Security GUIDELINES control CloudTrail.5 checks to see if AWS CloudTrail is configured to send logs to Amazon CloudWatch logs. It is possible to disable this check if you’re sending CloudTrail to some other destination, such as for example Amazon Simple Storage Service (Amazon S3) or partner tools like a SIEM solution. Another example is CIS 3.x controls. GuardDuty can be viewed as a compensating control of CloudWatch alarms for CIS 3 instead.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10, 3.11, 3.12, 3.13, and 3.14

Solution overview:

The update Security Hub controls script shown below is written in Python. It uses AWS SDK for Python (Boto3) to assume a cross account IAM role in the accounts passed in the script, and uses the update-standards-control Security Hub API make it possible for or disable controls. You need to deploy this solution in one AWS Region.

We shall review the prerequisites within the next section to understand certain requirements for successfully by using this solution. We will then walk through the instructions for deploying this automation via an Amazon Elastic Compute Cloud (Amazon EC2) instance alongside examples of how exactly to utilize the script.

Note: You can even use your neighborhood machine (customer device) or AWS Cloudshell if the prerequisites are met by you described below.

Prerequisites:

The update Security Hub controls script shown below requires:

• An IAM role for cross-account access. You ought to have an IAM principal in a position to assume an IAM role in accounts where Security Hub controls must be disabled or enabled. This role must have securityhub:UpdateStandardsControl permission.
  

  Note: If the &lt was utilized by you;a href=”https://github.com/awslabs/aws-securityhub-multiaccount-scripts” target=”_blank” rel=”noopener noreferrer”>Security Hub multiaccount scripts from awslabs make it possible for Security Hub for multiple accounts you should use the role provided in the repository for the purpose of this blog since it gets the necessary permissions.

• AWS CLI
• Python
• Boto3

Update security hub controls script

Let’s review the arguments the script successfully uses to perform. You can find both required arguments and optional arguments:

Required arguments

-input-file
Way to a CSV file containing a summary of the 12 digit AWS account IDs whose controls you intend to disable or enable. If you work with Security Hub administrator account, utilize the list-members API to create a summary of all accounts where security hub is enabled. Store this list in a CSV file, one account ID per line.

-assume-role
Role name of the execution role in each account. This role must have the securityhub:UpdateStandardsControl permission. In the event that you shall be utilizing the sample execution role CloudFormation provided in Part B-Execution role, the real name of the role is ManageSecurityHubControlsExecutionRole.

-regions
Comma separated set of Regions to update SecurityHub controls. Usually do not add any spaces after every comma. Specify ALL to take into account all Regions where Security Hub can be acquired. If you list an area where you haven’t enabled Security Hub, the script shall skip this Region and log the failure.

-standard
Enter the typical code (AFSBP, CIS, PCIDSS).
AFSBP for AWS Foundational Security Best Practices
CIS for CIS AWS Foundations
PCIDSS for Payment Card Industry Data Security Standard (PCI DSS)

The script works together with one Security Hub Standard at a right time. For example, it is possible to only disable AFSBP controls in the initial run of the script. If you wish to disable multiple controls across CIS and AFSBP standards you need to run the script twice, for AFSBP as soon as for CIS controls once.

-control-id-list
Comma separated set of controls, example for CIS, enter – (1.1,1.2) or for PCIDSS enter – (PCI.AutoScaling.1,PCI.CloudTrail.4)

Usually do not add any spaces after every comma. Control IDs are available from the Security Hub console: Security Standards > View results > ID column in the enabled controls table. You’ll find the control IDs in the Security Hub controls &lt also;a href=”https://docs.aws.amazon.com/securityhub/latest/userguide/standards-available.html” target=”_blank” rel=”noopener noreferrer”>documentation for every standard.

-control-action
For enabling controls use ENABLED; for disabling controls use DISABLED.

-disabled-reason
Reason behind disabling the controls. This text shall come in the Security Hub console for the disabled controls, it is used to comprehend why the control is disabled for reviews in the foreseeable future. If your script uses different known reasons for disabling controls, you will need to perform the script multiple times, for every disable reason once. This argument is not needed (or used) for enabling controls.

Optional arguments

-h, -help
shows the help exit&lt and message;/p>

-profile
If this argument isn’t given, the default profile will undoubtedly be used. Utilize this argument to parse the named profile. The credentials in this profile must have permissions to assume the execution role in each account.

Solution deployment

We have been utilizing an Amazon EC2 instance with Amazon Linux 2 (AL2) to perform this automation. We will create the instance role for the EC2 partly A, create the execution role partly B, and launch the EC2 instance to perform the Update Security Hub controls script partly C.

Note: For the purpose of this blog, we are creating the EC2 instance and the instance role in the Security Hub administrator account, this isn’t a requirement however. When you have existing cross account roles with the required permissions, you should use these existing roles aswell.

This role must have permission to assume (sts:AssumeRole) the execution role described partly B.

An example policy because of this role below is provided. This policy limits the Security Hub controls manager EC2 role to assume just a specific execution role in the downstream accounts:

"Version": "2012-10-17",
"Statement": [

    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::*:role/ManageSecurityHubControlsExecutionRole"

]

To generate the SHControlsManagerEC2 role

1. 1. Demand IAM console of the Security Hub administrator account. You’ll want permission to launch an EC2 instance in this account.

 

1. 1. Develop a new policy using JSON policy editor, and name it SHAssumeRolePolicy.

 

1. 1. Copy the sample policy shown above and paste it into your brand-new policy in the JSON editor. The resource in the policy may be the execution role, as will undoubtedly be described in Part B-Execution role below.
      

      Note: If you work with an existing role because the execution role, than developing a new role as shown in Steps 1-4 rather, then you should change the resource portion of the sample code in Figure 2 to utilize the ARN of the prevailing execution role.

       

 

1. 1. In the IAM console, Create an IAM role for EC2 and name it SHControlsManagerEC2. Assign the next policies:
      1. 1. The SHAssumeRolePolicy policy you created in step two 2.

       

      1. 1. The AmazonSSMManagedInstanceCore managed policy for managing the instance using AWS Systems Manager.

       

      1. 1. The AWSSecurityHubReadOnlyAccess managed policy for allowing read only usage of Security Hub.

       

       

      

      Figure 3: IAM policies mounted on Amazon EC2 Instance role

       

 

1. 1. If you are finished creating the role, note the Amazon Resource Name (ARN) – you’ll be using it partly B. The ARN can look like Figure 4: arn:aws:iam::111111222222:role/SHControlsManagerEC2

      

      Figure 4: ARN of the Amazon EC2 instance role

       

 

Part B-Execution role

The execution role should be created in every accounts where you will be disabling or enabling controls. This role must have securityhub:UpdateStandardsControl permission. The execution role trust relationship should permit the Security Hub controls manager role to assume the execution role.

Important: The name of the execution role should be identical in each account (like the Security Hub administrator account), the script won’t work otherwise.

If you work with AWS Organizations, it is possible to use CloudFormation StackSets to deploy this execution role across all your accounts easily. The stack set runs over the organization at the main or organizational units (OUs) degree of your decision. The CloudFormation use the ARN you noted from Security Hub controls manager EC2 role as a parameter.

Sample execution role policy

An example policy for the execution role is provided below:

"Version": "2012-10-17",
"Statement": [

    "Effect": "Allow",
    "Action": "securityhub:UpdateStandardsControl",
    "Resource": "arn:aws:securityhub:::hub/default"

]

Sample execution role trust policy

Note: the ARN in the principal section below ought to be the ARN you noted in step 5 of Part A: Security Hub controls manager EC2 role .

“Version”: “2012-10-17”,
“Statement”: [

  "Effect": "Allow",
  "Principal": 
    "AWS": "arn:aws:iam::111111222222:role/SHControlsManagerEC2"
  ,
  "Action": "sts:AssumeRole"

]

To launch the stack set for creating cross account IAM Roles

1. Login to the console of the Organizations management account or CloudFormation delegated administrator account.
2. Select StackSet and choose Create StackSet
3. Choose template is ready, and choose template source as Amazon S3 URL
4. Enter the next URL, then click next: https://awsiammedia.s3.amazonaws.com/public/sample/1083-disabling-security-hub-controls-multi-account/aws-securityhub-updatecontrols-executionrole.yml

   

   Figure 5: Develop a AWS CloudFormation StackSet

5. Enter a stack name, update description as needed and under parameters enter the ARN of the Security Hub controls manager EC2 role found in step 5 of Part A-Security Hub controls manager EC2 role, choose Next then.

   

   Figure 6: AWS CloudFormation StackSet parameters for creating cross account IAM role

6. (Optional) On the Configure StackSet options page, head to Tags and add tags to recognize and organize your stack set.

   

   Figure 7: Optionally define tags for the stacks made out of AWS CloudFormation StackSet

7. On the Set deployment options page, choose the desired Region. Because the resource being created is IAM, you shall just need to specify one Region. Choose Next .

   

   Figure 8: Specify target regions where in fact the CloudFormation stacks have to be created

8. Review the select&nbsp and definition; I acknowledge that AWS CloudFormation might create IAM resources . Choose  Submit .
9. It is possible to monitor the creation of the stack set from the  Operations  tab to make sure that deployment is prosperous.

 

Note: StackSets will not deploy stack instances to the organization’s management account, even though the management account is in your company or within an OU in your company. You need to create the execution role in the business management account manually.

 

Part C-Launch EC2

We will be utilizing a t2.micro EC2 instance with Amazon Linux 2 (AL2) image which comes preinstalled with AWS CLI and Python. This instance size and image &lt are;a href=”https://aws.amazon.com/free/?all-free-tier.sort-by=item.additionalFields.SortRank&all-free-tier.sort-order=asc&awsf.Free%20Tier%20Types=*all&awsf.Free%20Tier%20Categories=*all” target=”_blank” rel=”noopener noreferrer”>free tier eligible.

To launch the EC2 instance for executing securityhub-updatecontrols-script

1. Launch EC2 instance in the Security Hub administrator account within a Region. You should use any Region.
2. Attach the IAM role to the instance as created partly A.
3. Confirm instance is in a running state.
4. Login to the instance CLI using AWS Systems Manager Session Manager. Go directly to the EC2 console, choose the instance and choose Connect.

   

   Figure 9: Access newly launched Amazon EC2 instance using session manager

   Note: You need to allow outbound access to the internet to systems manager endpoints for session manager to work. See session manager documentation to find out more.

5. On another page, choose Connect again.

   

   Figure 10: Hook up to Amazon EC2 instance

6. A fresh window with session manager shall open.
7. Set the working directory to home directory.

    cd /home/ssm-user

8. Install Git:

    yum install git&lt sudo;/code>

9. Clone the UpdateSecurityHubControls code repository.

    git clone https://github.com/aws-samples/SecurityHub-Multiaccount-UpdateControls.git

10. Take up a virtual environment.

     python3 -m venv SecurityHub-Multiaccount-UpdateControls/env
         

    source SecurityHub-Multiaccount-UpdateControls/env/bin/activate

11. Upgrade pip and Install boto3

          pip install pip --upgrade
    

    pip install boto3

12. You’re prepared to run the script now.

     

    Example 1-Disabling Controls

    Let’s assume you have Config global recording enabled in us-east-1 and desire to disable controls connected with global resources (IAM.1, IAM.2, IAM.3, IAM.4, IAM.5, IAM.6, IAM.7) for AWS Foundational Security GUIDELINES standard in Regions us-west-1, us-east-2 in every accounts. The real name of our execution role in every accounts is ManageSecurityHubControlsExecutionRole

    1. Change to the right directory
       $ cd SecurityHub-Multiaccount-UpdateControls
    2. Develop a file with the set of account IDs. That is passed with the input-file argument.
       $ nano accounts.csv
    3. Enter account IDs one account per line, save the file then.

       

       Figure 11: CSV file with AWS account IDs

    4. Run the script:

        python SH-UpdateControls.py 
            

       –input-file accounts.csv
       –assume-role ManageSecurityHubControlsExecutionRole
       –regions us-east-2,us-west-1
       –standard AFSBP
       –control-id-list IAM.1,IAM.2,IAM.3,IAM.4,IAM.5,IAM.6,IAM.7
       –control-action DISABLED
       –disabled-reason ‘Disabling IAM checks in every regions aside from us-east-1, as global recording is enabled in us-east-1’

• Because the script runs, it creates a listing of disabled controls. If you can find failures, the good reason behind failures will undoubtedly be listed in the summary. A log file is saved in the directory with execution logs also.

  

  Figure 12: Execution Summary showing successful updates and failure information

Example 2-Enabling Controls

Let’s say you have disabled Control IDs PCI.CodeBuild.1 and PCI.CodeBuild.2 from the PCI standard in your accounts, as before, you didn’t use AWS CodeBuild in your PCI environment.

Following a recent architecture review, you made a decision to choose CodeBuild in your accounts in us-west-1, eu-west-1, ap-southeast-1 . The name of our execution role in every accounts is ManageSecurityHubControlsExecutionRole .

• Confirm all steps have already been completed by you partly C.

• Change to the right directory.
  $ cd SecurityHub-Multiaccount-UpdateControls

• Develop a file with the set of account IDs. This is passed with the input-file argument.
  $ nano accounts.csv
  Enter account IDs one account per line, then save the file.

  

  Figure 13: CSV file with AWS account IDs

• Run the script make it possible for controls

        python SH-UpdateControls.py 
  --input-file accounts.csv 
  --assume-role ManageSecurityHubControlsExecutionRole 
  --regions us-west-1,eu-west-1,ap-southeast-1 
  --standard PCIDSS 
  --control-id-list PCI.CodeBuild.1,PCI.CodeBuild.2 
  --control-action ENABLED 
       

• Because the script runs, it creates a listing of enabled controls. If you can find failures the reason behind failures will undoubtedly be listed in the summary A log file can be saved in the directory with execution logs.

  

  Figure 14: Execution Summary showing controls enabled

Alternative Solution

Look at a case where participant accounts are being put into the Security Hub administrator of the business. In that scenario, you would need to manually disable the controls, or by re-running the update Security Hub controls script in each new account.

This alternative solution addresses this nagging problem by automating the procedure with AWS Step Functions and a scheduled EventBridge event. An ongoing state machine is triggered every a day, which updates the status of the typical controls in every AWS accounts registered as members in the Security Hub administrator account. This solution maintains a summary of account IDs inside a DynamoDB table, that exceptions could be made. For information on how exactly to deploy and utilize this solution, make reference to this GitHub repository. This alternative solution and the update SecurityHub controls script are independent of every other.

Conclusion

In this website, you learned a number of the good reasons you may disable Security Hub controls. We showed the way the controls could be disabled or enabled utilizing the &lt quickly;span>update Security Hub controls script provided. This script can save you time if you wish to update controls across multiple accounts and multiple Regions on an as needed basis.

We also introduced another solution which uses AWS Step Functions and a scheduled CloudWatch event to update Security Hub controls in new accounts frequently. You could utilize either of both solutions with regards to the scenario.

When you have feedback concerning this post, submit comments in the Comments section below. When you have trouble with the scripts, please open a concern in GitHub.

When you have feedback concerning this post, submit comments in the Comments section below.

Want more AWS Security news? Follow us on Twitter.