DEV Community: Pablo Santamaria

Deshabilitar Security Hub controles en una organización en AWS

Pablo Santamaria — Wed, 11 Oct 2023 22:29:03 +0000

Objetivo

En este blog, exploraremos la automatización del proceso para habilitar o deshabilitar controles en AWS Security Hub a través de una organización que comprende múltiples cuentas y regiones. A pesar de que Security Hub proporciona una funcionalidad de administración de controles, no existe una solución nativa que permita habilitar o deshabilitar controles de manera global.

La solución descrita a continuación se encuentra basada en este AWS blog adicionado las mejoras descritas a continuación:

Facilitar la habilitación o deshabilitación de controles a través de múltiples estándares, aprovechando una vista consolidada y empleando un ControlId común.
Ofrecer flexibilidad para habilitar o deshabilitar controles de forma global o por regiones.
Habilitar o deshabilitar controles en toda la organización sin necesidad de listar todas las cuentas de AWS.
Tratar la cuenta administrativa de Security Hub como una cuenta miembro de la organización, garantizando una gestión unificada.
Integración con s3 para ejecutar la State Machine cuando se detecta una actualización o adición de un elemento en la base de datos de DynamoDB.
Uso de una tabla de DynamoDB que almacena información sobre regiones por cuenta de AWS, lo que resulta útil en organizaciones de gran envergadura con distintas necesidades de negocio que pueden involucrar habilitar diferentes regiones por cuenta.

Descripción

Esta solución consiste en lo siguiente:

cross-account IAM role que se establece en todas las cuentas de la organización, otorgando los permisos necesarios para activar o desactivar controles a través de diversos estándares.
AWS Step Function Machine que asume el rol en las cuentas miembro de la organización, gestionando la habilitación o deshabilitación de controles y garantizando el cumplimiento según los estándares configurados en la cuenta administrativa.
tabla DynamoDB que almacena todas las excepciones, incluyendo los controles que deben ser activados o desactivados en cada cuenta o región de la organización.
S3 Bucket donde se carga el archivo items.json, que contiene la lista de controles y su estado deseado.
process_ddb_lambda Función Lambda la cual se invoca cada vez que items.json se actualiza en el bucket de s3.
DynamoDB para cuentas y regions Tabla de datos que almacena la relación de regiones habilitadas por cuenta de AWS.
StateMachineLambdaTrigger Función Lambda encargada de iniciar la ejecución de la máquina de estado Step Function Machine.

Configuración

Requisitos

Para desplegar esta solución usted necesita:

Cuentas miembro

Despliegue cross-account IAM role definido en member-iam-role/template.yaml en todas las cuentas de la organización.

Despliegue

Reemplace my-stackset y AccountID con el valor deseado y cree el stack-set.

aws cloudformation create-stack-set \
--stack-set-name <my-stackset> \
--template-body file://member-iam-role/template.yaml \
--capabilities CAPABILITY_NAMED_IAM \
--call-as DELEGATED_ADMIN --permission-model SERVICE_MANAGED\ --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false \
--parameters ParameterKey=SecurityHubAdminAccountId,ParameterValue=<AccountID>

Parameters

Name	Description	Default
SecurityHubAdminAccountId	Account ID of SecurityHub administrator Account	None
IAMRolePath	Path for IAM Role - this must match the `MemberIAMRolePath` parameter in the `UpdateMembers` stack.	/
IAMRoleName	Name of IAM Role - this must match the `MemberIAMRoleName` parameter in the `UpdateMembers` stack.	securityhub-UpdateControl-role

Crear stack instances, reemplace ORG-ID con el OU en el cual desea desplegar, si desea desplegar el role a nivel de la organización use el root ID de su organización.

aws cloudformation create-stack-instances --stack-set-name my-stackset \
--deployment-targets OrganizationalUnitIds='["ORG-ID"]' \
--regions '["us-east-1"]'  --call-as DELEGATED_ADMIN \
--operation-preferences FailureTolerancePercentage=100,MaxConcurrentCount=20

Security Hub Administrator Account

SAM

Despliegue de la maquina de estado descrita en CFN/template.yaml.

Prerrequisitos

Debido a que template.yaml usa Serverless transformation, se require la creación de un artifact bucket en la cuenta administradora de Security Hub, el siguiente comando crea este bucket con el nombre :

aws s3 mb s3://<artifact-bucket>

Despliegue

sam package --template-file CFN/template.yaml --output-template-file CFN/template-out.yaml --s3-bucket <artifact-bucket>
aws cloudformation deploy --template-file CFN/template-out.yaml --capabilities CAPABILITY_IAM --stack-name <stack-name> --parameter-overrides SecurityHubAdminAccountId=<AccountID>

Parameters

Name	Description	Default
Schedule	The scheduling expression that determines when and how often the Security Hub Disabler runs.	rate(1 day)
MemberIAMRolePath	Path of IAM Role in member account - this must match the `IAMRolePath` parameter in the `memeber-iam-role` stack.	/
MemberIAMRoleName	Name of IAM Role in member account - this must match the `IAMRoleName` parameter in the `memeber-iam-role` stack.	securityhub-UpdateControl-role
Path	Path of IAM LambdaExecution Roles	/
EventTriggerState	The state of the SecurityHubUpdateEvent rule monitoring Security Hub control updates and triggering the state machine	DISABLED
NotificationEmail1	Optional - E-mail address to receive notification if the state machine fails.
NotificationEmail2	Optional - E-mail address to receive notification if the state machine fails.
NotificationEmail3	Optional - E-mail address to receive notification if the state machine fails.

Terraform

Despliegue la solución descrita en el folder terraform la cual se encargara de crear el bucket de s3 y la función lambda que se encargara de actualizar la base de datos cuando se sube un nuevo archivo json con los controles a deshabilitar o habilitar.

## Inicie terraform
terraform init

## Ejecute el plan para evaluar cambios
terraform plan

## Ejecute apply
terraform apply

Uso

Luego de desplegar esta solución, se ejecutara con base en los siguientes triggers:

Ejecución programada.

Este tipo de ejecución se inicia según un cronograma predefinido. Puede configurar el intervalo de tiempo utilizando el parámetro "Schedule," siendo un día el valor predeterminado. Puede hacer uso de las siguientes expresiones para personalizar el cronograma.

Esta ejecución está diseñada para mantener la organización en cumplimiento de los estándares habilitados y para propagar estos estándares junto con el estado de los controles a las nuevas cuentas en toda la organización.

Ejecución basada en eventos.

Esta modalidad de ejecución se dispara cada vez que se habilita o deshabilita un control en la cuenta administradora de Security Hub. Es importante tener en cuenta una limitación: si se realizan numerosos cambios en los controles en un corto período de tiempo, este evento puede generar múltiples ejecuciones paralelas, lo que podría llevar a la saturación de la API.

Para este proyecto en particular, hemos optado por mantener esta ejecución desactivada, ya que tenemos diversas necesidades de negocio que no requieren que el estado de los controles en la cuenta administradora se refleje en las cuentas miembro.

Ejecución basada en eventos de S3

Cada vez que se agrega o actualiza un nuevo archivo en el bucket de S3 después de actualizar las bases de datos, se inicia una ejecución de la State Machine.

Configurando excepciones

Para añadir elementos a la tabla de DynamoDB alojada en la cuenta administradora de Security Hub, cada elemento representará una excepción. Cada excepción contendrá, al menos, una cuenta de AWS. Cada vez que un archivo es añadido o actualizado en el bucket de S3, se desencadenará la ejecución de una función Lambda, la cual, a su vez, iniciará una ejecución de la State Machine. Esto garantizará la actualización de la(s) cuenta(s) relacionada(s) con dicha excepción.

Para agregar elementos se debe editar el archivo items.json, como ejemplo puede ver el archivo items.json.template.

  {
    "ControlId": "CloudTrail.5",
    "Disabled": [ "ALL" ],
    "DisabledReason": "We are not monitoring CT at Organization level, Jira Ticket XXX-01"
  },
  {
    "ControlId": "CloudTrail.6",
    "Disabled": ["123456789012", "123456789089", "123456789076"],
    "DisabledReason": "We are not monitoring CT at Organization level, Jira Ticket XXX-02"
  },
  {
      "ControlId": "IAM.9",
      "Enabled": ["ALL"],
      "DisabledReason": "Global resource control, should be enabled only in us-east-1, Jira Ticket XXX-03",
      "Region": ["us-east-1"]
  }

Para agregar una excepción a toda la organización incluyendo la cuenta administradora de Security Hub debe usar "ALL".

Para deshabilitar un control global, debe usar "Enabled" y la región donde desea que este control este habilitado. por ejemplo:

## Deshabilitar IAM.9 en todas las regiones a excepción de us-east-1
  {
      "ControlId": "IAM.9",
      "Enabled": ["ALL"],
      "DisabledReason": "Global resource control, should be enabled only in us-east-1, Jira Ticket XXX-03",
      "Region": ["us-east-1"]
  }

Adicionando o actualizando cuentas: para actualizar las cuentas o agregar una cuenta y sus regions se debe editar el archivo accounts.json. Luego de que una cuenta es adicionada o sus regiones actualizadas, una función lambda es invocada para luego de actualizar las bases de datos iniciar una ejecución de la State Machine.

[
    {
      "AccountId": "123456789012",
      "Regions": [
        "ap-northeast-1",
        "ap-northeast-2",
        "ap-northeast-3",
        "ap-south-1",
        "ap-southeast-1",
        "ap-southeast-2",
        "ca-central-1",
        "eu-central-1",
        "eu-north-1",
        "eu-west-1",
        "eu-west-2",
        "eu-west-3",
        "sa-east-1",
        "us-east-2",
        "us-west-1",
        "us-west-2",
        "us-east-1"
      ]
    },
    {
      "AccountId": "123456789012",
      "Regions": [
        "us-east-2",
        "us-west-1",
        "us-west-2",
        "us-east-1"
      ]
    }
  ]

Luego de agregar o actualizar un elemento en el archivo items.json para aplicar estos cambios debe ejecutar terraform plan y terraform apply.

Disable Security Hub controls in an AWS organization

Pablo Santamaria — Wed, 11 Oct 2023 22:28:53 +0000

Goal

In this blog, we will explore the process of enabling and disabling controls in AWS Security Hub across multiple accounts within an organization, with a dedicated Security Hub administrator account. Although AWS Security Hub offers control management, there is no native method to globally disable specific controls for all Security Hub member accounts. To address this gap, this project aims to streamline the process by propagating the action of enabling or disabling security standards and their controls from the Security Hub administrator account to all member accounts.

The solution presented in this blog builds upon an existing AWS blog post, enhancing it with the following key features:

Common ControlID: We introduce the concept of enabling or disabling controls using a common ControlID across enabled standards, effectively resolving the issue of control management.
Global Controls: We address the challenge of enabling or disabling controls based on regions.
Simplified Account Management: Instead of manually listing all account IDs, we provide a mechanism to enable or disable controls across the organization effortlessly.
Security Hub Admin Account: We recognize the Security Hub Admin account as a member account.
Integration with S3 and Lambda function: We implement S3 integration to initiate a State Machine execution whenever a new item is added to the DynamoDB table.
AccountIds DynamoDB table: For large organizations with different business units is common to use different regions across the account within the organization, for this case we implement a DynamoDB to control regions per account.

Overview

The proposed solution encompasses the following components:

Cross-Account IAM Role: Member accounts are equipped with a cross-account IAM role, granting the necessary Security Hub permissions to enable/disable Security standard controls.

AWS Step Function State Machine: This state machine assumes the cross-account IAM role and manages the enablement or disablement of controls in member accounts, ensuring alignment with the DynamoDB exceptions, ensuring the organization's compliance with the enabled standards in the Security Hub admin account.

DynamoDB Table for Exceptions: A DynamoDB table contains information about which controls should be enabled or disabled in specific accounts.

DynamoDB Table for Accounts-Region: A DynamoDB table contains information about which regions are enable per account.

S3 Bucket: An S3 bucket to upload of an items.json file containing exceptions to be added to the DynamoDB table.

Lambda Function: This function is triggered when the items.json file is updated in the S3 bucket, ensuring real-time updates to control exceptions in the DynamoDB table and initiating Step Function Machine executions in response to DynamoDB updates.

Setup

Requirements

To deploy this solution, you need:

Member Accounts

Deploy the cross-account IAM role defined in member-iam-role/template.yaml in all member accounts.
For SecurityHubAdminAccountId, set the Account ID of the Security Hub administrator account.

Deployment

Replace my-stackset and AccountID with the desired value and create the stack-set.

aws cloudformation create-stack-set \
--stack-set-name <my-stackset> \
--template-body file://member-iam-role/template.yaml \
--capabilities CAPABILITY_NAMED_IAM \
--call-as DELEGATED_ADMIN --permission-model SERVICE_MANAGED\ --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false \
--parameters ParameterKey=SecurityHubAdminAccountId,ParameterValue=<AccountID>

Parameters

Name	Description	Default
SecurityHubAdminAccountId	Account ID of SecurityHub administrator Account	None
IAMRolePath	Path for IAM Role - this must match the `MemberIAMRolePath` parameter in the `UpdateMembers` stack.	/
IAMRoleName	Name of IAM Role - this must match the `MemberIAMRoleName` parameter in the `UpdateMembers` stack.	securityhub-UpdateControl-role

Create the stack instances, replace the ORG-ID with the desired OU-ID, if you want to deploy at organization level use your root OU-ID.

aws cloudformation create-stack-instances --stack-set-name my-stackset \
--deployment-targets OrganizationalUnitIds='["ORG-ID"]' \
--regions '["us-east-1"]'  --call-as DELEGATED_ADMIN \
--operation-preferences FailureTolerancePercentage=100,MaxConcurrentCount=20

Security Hub Administrator Account

SAM

Deploy the state machine described in CFN/template.yaml.

Prerequisites

Before proceeding with the CFN/template.yaml file, which utilizes the Serverless transformation, it is essential to set up an artifact bucket within the Security Hub administrator account. To create this artifact bucket, you can use the following command, specifying your chosen name for the bucket as :

aws s3 mb s3://<artifact-bucket>

Deployment

sam package --template-file CFN/template.yaml --output-template-file CFN/template-out.yaml --s3-bucket <artifact-bucket>
aws cloudformation deploy --template-file CFN/template-out.yaml --capabilities CAPABILITY_IAM --stack-name <stack-name> --parameter-overrides SecurityHubAdminAccountId=<AccountID>

Parameters

Name	Description	Default
Schedule	The scheduling expression that determines when and how often the Security Hub Disabler runs.	rate(1 day)
MemberIAMRolePath	Path of IAM Role in member account - this must match the `IAMRolePath` parameter in the `memeber-iam-role` stack.	/
MemberIAMRoleName	Name of IAM Role in member account - this must match the `IAMRoleName` parameter in the `memeber-iam-role` stack.	securityhub-UpdateControl-role
Path	Path of IAM LambdaExecution Roles	/
EventTriggerState	The state of the SecurityHubUpdateEvent rule monitoring Security Hub control updates and triggering the state machine	DISABLED
SecurityHubAdminAccountId	Account ID of SecurityHub administrator Account	None
NotificationEmail1	Optional - E-mail address to receive notification if the state machine fails.
NotificationEmail2	Optional - E-mail address to receive notification if the state machine fails.
NotificationEmail3	Optional - E-mail address to receive notification if the state machine fails.

Terraform

To deploy this solution, navigate to the terraform folder, where you will find the necessary configurations to set up the solution. This includes the creation of an S3 bucket and a Lambda function, which plays a pivotal role in updating the DynamoDB table each time a new JSON file containing control status information is uploaded to the S3 bucket.

## terraform initialization
terraform init

## Execute the plan to evaluate changes
terraform plan

## execute apply
terraform apply

Usage

Once the deployment is complete, the solution operates automatically, driven by the following triggers:

Scheduled Trigger

The Scheduled Trigger operates based on a predefined schedule, which can be customized using the Schedule parameter. By default, it runs daily. You have the flexibility to employ scheduling expressions as detailed in the AWS documentation here.
The Scheduled Trigger serves a dual purpose: it ensures that newly added accounts are promptly updated as Security Hub member accounts and propagates the status of controls that were previously disabled even before the solution deployment to all existing member accounts.

Event Trigger

The Event Trigger activates each time a control is disabled or enabled in the Security Hub administrator account. The behavior of the Event Trigger can be controlled via the EventTriggerState parameter, which can be set during the deployment process.
Limitation: If a lot of controls are changed in a very short timeframe (e.g. when done programmatically via Security Hub Controls CLI), the Event Trigger causes multiple parallel executions which may lead to API throttling and thus failure of the execution.

For specific cases where reflecting the control status of the admin account in member accounts is unnecessary, we have chosen to disable this trigger.

S3 update events

The state machine is triggered after a file is updated or a new item or added in the S3 Bucket.

Setting exceptions

Exceptions are managed through the DynamoDB table deployed in the SecurityHub administrator account. Each individual element within this table represents an exception. Every exception should include at least one AWS account associated with it.

Here's how the process works:

Adding or Updating Exceptions: Whenever a new exception is added or an existing one is updated, a Lambda function is invoked. This Lambda function, in turn, initiates the execution of a new State Machine.

To add exceptions edit the json file items.json, for guidance and reference, you may consult the items.json.template file.

The following json object is an extraction of the items.json file:

  {
    "ControlId": "CloudTrail.5",
    "Disabled": [ "ALL" ],
    "DisabledReason": "We are not monitoring CT at Organization level, Jira Ticket XXX-01"
  },
  {
    "ControlId": "CloudTrail.6",
    "Disabled": ["123456789012", "123456789089", "123456789076"],
    "DisabledReason": "We are not monitoring CT at Organization level, Jira Ticket XXX-02"
  },
  {
      "ControlId": "IAM.9",
      "Enabled": ["ALL"],
      "DisabledReason": "Global resource control, should be enabled only in us-east-1, Jira Ticket XXX-03",
      "Region": ["us-east-1"]
  }

Adding Organization-Wide Exceptions: When adding an exception that applies to the entire organization, you can streamline the process by simply using the keyword "ALL". This eliminates the need to list individual accounts, making exception management more efficient and less error-prone.

Disabling Global Controls: To disable a global control, the key step is to use the "Enabled" parameter while specifying the region within which this control should be enabled. For example:

## Disable IAM.9 in all regions but us-east-1
  {
      "ControlId": "IAM.9",
      "Enabled": ["ALL"],
      "DisabledReason": "Global resource control, should be enabled only in us-east-1, Jira Ticket XXX-03",
      "Region": ["us-east-1"]
  }

Implementing exceptions: Once you've made updates to an element within the items.json file and wish to apply these alterations, follow these steps:

Save your modifications within the items.json file.
execute below terraform commands:

## Execute the plan to evaluate changes
terraform plan

## execute apply
terraform apply

Adding or Updating Accounts: Whenever a new account is added or an existing one is updated, a Lambda function is invoked. This Lambda function, in turn, initiates the execution of a new State Machine, to update or add accounts and regions update accounts.json file as described below.

[
    {
      "AccountId": "123456789012",
      "Regions": [
        "ap-northeast-1",
        "ap-northeast-2",
        "ap-northeast-3",
        "ap-south-1",
        "ap-southeast-1",
        "ap-southeast-2",
        "ca-central-1",
        "eu-central-1",
        "eu-north-1",
        "eu-west-1",
        "eu-west-2",
        "eu-west-3",
        "sa-east-1",
        "us-east-2",
        "us-west-1",
        "us-west-2",
        "us-east-1"
      ]
    },
    {
      "AccountId": "123456789012",
      "Regions": [
        "us-east-2",
        "us-west-1",
        "us-west-2",
        "us-east-1"
      ]
    }
  ]

After saving your changes run terraform plan and apply again.

Conclusion

In this blog, you learned how to disable some controls across multiple accounts within organization. we showed how the controls can quickly be disabled or enabled using the solution described. This project provide a solution to disable controls across different standards using a common controlID besides giving the option to disable controls for global resources.

We also introduced a DynamoDb table to control regions per account, this additional feature is useful for large organizations with multiple business unit that requires different enabled regions per account.

If you have feedback about this post, submit comments in the Comments section below. If you have trouble with the solution, please open an issue in GitHub.