Service-Managed Standard: Amazon Control Tower
This section provides information about Service-Managed Standard: Amazon Control Tower.
What is Service-Managed Standard: Amazon Control Tower?
This standard is designed for users of Amazon Security Hub and Amazon Control Tower. It lets you configure the proactive controls of Amazon Control Tower alongside the detective controls of Security Hub in the Amazon Control Tower service.
Proactive controls help ensure that your Amazon Web Services accounts maintain compliance because they flag actions that may lead to policy violations or misconfigurations. Detective controls detect noncompliance of resources (for example, misconfigurations) within your Amazon Web Services accounts. By enabling proactive and detective controls for your Amazon environment, you can enhance your security posture at different stages of development.
Tip
Service-managed standards differ from standards that Amazon Security Hub manages. For example, you must create and delete a service-managed standard in the managing service. For more information, see Service-managed standards.
In the Security Hub console and API, you can view Service-Managed Standard: Amazon Control Tower alongside other Security Hub standards.
Creating the standard
This standard is available only if you create the standard in Amazon Control Tower. Amazon Control Tower creates the standard when you first enable an applicable control by using one of the following methods:
-
Amazon Control Tower console
-
Amazon Control Tower API (call the
EnableControl
API) -
Amazon CLI (run the
enable-control
command)
Security Hub controls are identified in the Amazon Control Tower console as
SH.ControlID
(for example,
SH.CodeBuild.1).
When you create the standard, if you haven’t already enabled Security Hub, Amazon Control Tower also enables Security Hub for you.
If you haven't set up Amazon Control Tower, you can't view or access this standard in the Security Hub console, Security Hub API, or Amazon CLI. Even if you have set up Amazon Control Tower, you can't view or access this standard in Security Hub without first creating the standard in Amazon Control Tower using one of the preceding methods.
This standard is only available in the Amazon Web Services Regions where Amazon Control Tower is available, including Amazon GovCloud (US).
Enabling and disabling controls in the standard
After you've created the standard in the Amazon Control Tower console, you can view the standard and its available controls in both services.
After you first create the standard, it doesn't have any controls that are automatically enabled. In addition, when Security Hub adds new controls, they aren't automatically enabled for Service-Managed Standard: Amazon Control Tower. You should enable and disable controls for the standard in Amazon Control Tower by using one of the following methods:
-
Amazon Control Tower console
-
Amazon Control Tower API (call the
EnableControl
andDisableControl
APIs) -
Amazon CLI (run the
enable-control
and disable-control
commands)
When you change the enablement status of a control in Amazon Control Tower, the change is also reflected in Security Hub.
However, disabling a control in Security Hub that's enabled in Amazon Control Tower results in control
drift. The control status in Amazon Control Tower shows as Drifted
. You can resolve
this drift by selecting Re-register
OU in the Amazon Control Tower console, or by disabling and re-enabling the control in
Amazon Control Tower using one of the preceding methods.
Completing enablement and disablement actions in Amazon Control Tower helps you avoid control drift.
When you enable or disable controls in Amazon Control Tower, the action applies across accounts and Regions. If you enable and disable controls in Security Hub (not recommended for this standard), the action applies only to the current account and Region.
Note
Central configuration can't be used to manage Service-Managed Standard: Amazon Control Tower. If you use central configuration, you can use only the Amazon Control Tower service to enable and disable controls in this standard for a centrally managed account.
Viewing enablement status and control status
You can view the enablement status of a control by using one of the following methods:
-
Security Hub console, Security Hub API, or Amazon CLI
-
Amazon Control Tower console
-
Amazon Control Tower API to see a list of enabled controls (call the
ListEnabledControls
API) -
Amazon CLI to see a list of enabled controls (run the
list-enabled-controls
command)
A control that you disable in Amazon Control Tower has an enablement status of
Disabled
in Security Hub unless you explicitly enable that control in
Security Hub.
Security Hub calculates control status based on the workflow status and compliance status of the control findings. For more information about enablement status and control status, see Viewing details for a control.
Based on control statuses, Security Hub calculates a security score for Service-Managed Standard: Amazon Control Tower. This score is only available in Security Hub. In addition, you can only view control findings in Security Hub. The standard security score and control findings aren't available in Amazon Control Tower.
Note
When you enable controls for Service-Managed Standard: Amazon Control Tower, Security Hub may take up to 18 hours to generate findings for controls that use an existing Amazon Config service-linked rule. You may have existing service-linked rules if you've enabled other standards and controls in Security Hub. For more information, see Schedule for running security checks.
Deleting the standard
You can delete this standard in Amazon Control Tower by disabling all applicable controls using one of the following methods:
-
Amazon Control Tower console
-
Amazon Control Tower API (call the
DisableControl
API) -
Amazon CLI (run the
disable-control
command)
Disabling all controls deletes the standard in all managed accounts and governed Regions in Amazon Control Tower. Deleting the standard in Amazon Control Tower removes it from the Standards page of the Security Hub console, and you can no longer access it by using the Security Hub API or Amazon CLI.
Note
Disabling all controls from the standard in Security Hub doesn't disable or delete the standard.
Disabling the Security Hub service removes Service-Managed Standard: Amazon Control Tower and any other standards that you’ve enabled.
Finding field format for Service-Managed Standard: Amazon Control Tower
When you create Service-Managed Standard: Amazon Control Tower and enable controls for it, you'll start to receive
control findings in Security Hub. Security Hub reports control findings in the Amazon Security Finding Format (ASFF).
These are the ASFF values for this standard's Amazon Resource Name (ARN) and
GeneratorId
:
-
Standard ARN –
arn:aws-cn:us-east-1
:securityhub:::standards/service-managed-aws-control-tower/v/1.0.0 -
GeneratorId –
service-managed-aws-control-tower/v/1.0.0/
CodeBuild.1
For a sample finding for Service-Managed Standard: Amazon Control Tower, see Sample control findings.
Controls that apply to Service-Managed Standard: Amazon Control Tower
Service-Managed Standard: Amazon Control Tower supports a subset of controls that are part of the Amazon Foundational Security Best Practices (FSBP) standard. Choose a control from the following table to view information about it, including remediation steps for failed findings.
The following list shows available controls for Service-Managed Standard: Amazon Control Tower. Regional limits on
controls match Regional limits on the corollary controls in the FSBP standard. This list
shows standard-agnostic security control IDs. In the Amazon Control Tower console, control IDs are
formatted as SH.ControlID
(for example
SH.CodeBuild.1). In Security Hub, if consolidated control findings is
turned off in your account, the ProductFields.ControlId
field uses the
standard-based control ID. The standard-based control ID is formatted as
CT.ControlId
(for example,
CT.CodeBuild.1).
-
[Account.1] Security contact information should be provided for an Amazon Web Services account
-
[ACM.1] Imported and ACM-issued certificates should be renewed after a specified time period
-
[ACM.2] RSA certificates managed by ACM should use a key length of at least 2,048 bits
-
[APIGateway.1] API Gateway REST and WebSocket API execution logging should be enabled
-
[APIGateway.3] API Gateway REST API stages should have Amazon X-Ray tracing enabled
-
[APIGateway.4] API Gateway should be associated with a WAF Web ACL
-
[APIGateway.5] API Gateway REST API cache data should be encrypted at rest
-
[APIGateway.8] API Gateway routes should specify an authorization type
-
[APIGateway.9] Access logging should be configured for API Gateway V2 Stages
-
[AppSync.5] Amazon AppSync GraphQL APIs should not be authenticated with API keys
-
[AutoScaling.1] Auto Scaling groups associated with a load balancer should use ELB health checks
-
[AutoScaling.2] Amazon EC2 Auto Scaling group should cover multiple Availability Zones
-
[AutoScaling.9] Amazon EC2 Auto Scaling groups should use Amazon EC2 launch templates
-
[CloudTrail.2] CloudTrail should have encryption at-rest enabled
-
[CloudTrail.4] CloudTrail log file validation should be enabled
-
[CloudTrail.5] CloudTrail trails should be integrated with Amazon CloudWatch Logs
-
[CloudTrail.6] Ensure the S3 bucket used to store CloudTrail logs is not publicly accessible
-
[CodeBuild.1] CodeBuild Bitbucket source repository URLs should not contain sensitive credentials
-
[CodeBuild.2] CodeBuild project environment variables should not contain clear text credentials
-
[CodeBuild.4] CodeBuild project environments should have a logging Amazon Configuration
-
[DMS.1] Database Migration Service replication instances should not be public
-
[DocumentDB.1] Amazon DocumentDB clusters should be encrypted at rest
-
[DocumentDB.2] Amazon DocumentDB clusters should have an adequate backup retention period
-
[DocumentDB.3] Amazon DocumentDB manual cluster snapshots should not be public
-
[DynamoDB.1] DynamoDB tables should automatically scale capacity with demand
-
[DynamoDB.2] DynamoDB tables should have point-in-time recovery enabled
-
[DynamoDB.3] DynamoDB Accelerator (DAX) clusters should be encrypted at rest
-
[EC2.1] Amazon EBS snapshots should not be publicly restorable
-
[EC2.2] VPC default security groups should not allow inbound or outbound traffic
-
[EC2.3] Attached Amazon EBS volumes should be encrypted at-rest
-
[EC2.4] Stopped EC2 instances should be removed after a specified time period
-
[EC2.8] EC2 instances should use Instance Metadata Service Version 2 (IMDSv2)
-
[EC2.9] Amazon EC2 instances should not have a public IPv4 address
-
[EC2.15] Amazon EC2 subnets should not automatically assign public IP addresses
-
[EC2.16] Unused Network Access Control Lists should be removed
-
[EC2.18] Security groups should only allow unrestricted incoming traffic for authorized ports
-
[EC2.19] Security groups should not allow unrestricted access to ports with high risk
-
[EC2.20] Both VPN tunnels for an Amazon Site-to-Site VPN connection should be up
-
[EC2.21] Network ACLs should not allow ingress from 0.0.0.0/0 to port 22 or port 3389
-
[EC2.22] Unused Amazon EC2 security groups should be removed
-
[EC2.23] Amazon EC2 Transit Gateways should not automatically accept VPC attachment requests
-
[EC2.25] Amazon EC2 launch templates should not assign public IPs to network interfaces
-
[ECR.1] ECR private repositories should have image scanning configured
-
[ECR.2] ECR private repositories should have tag immutability configured
-
[ECR.3] ECR repositories should have at least one lifecycle policy configured
-
[ECS.1] Amazon ECS task definitions should have secure networking modes and user definitions.
-
[ECS.2] ECS services should not have public IP addresses assigned to them automatically
-
[ECS.3] ECS task definitions should not share the host's process namespace
-
[ECS.5] ECS containers should be limited to read-only access to root filesystems
-
[ECS.8] Secrets should not be passed as container environment variables
-
[ECS.10] ECS Fargate services should run on the latest Fargate platform version
-
[EFS.1] Elastic File System should be configured to encrypt file data at-rest using Amazon KMS
-
[EKS.1] EKS cluster endpoints should not be publicly accessible
-
[EKS.2] EKS clusters should run on a supported Kubernetes version
-
[ElastiCache.3] ElastiCache for Redis replication groups should have automatic failover enabled
-
[ElastiCache.4] ElastiCache for Redis replication groups should be encrypted at rest
-
[ElastiCache.5] ElastiCache for Redis replication groups should be encrypted in transit
-
[ElastiCache.6] ElastiCache for Redis replication groups before version 6.0 should use Redis AUTH
-
[ElasticBeanstalk.1] Elastic Beanstalk environments should have enhanced health reporting enabled
-
[ElasticBeanstalk.2] Elastic Beanstalk managed platform updates should be enabled
-
[ELB.1] Application Load Balancer should be configured to redirect all HTTP requests to HTTPS
-
[ELB.3] Classic Load Balancer listeners should be configured with HTTPS or TLS termination
-
[ELB.4] Application Load Balancer should be configured to drop http headers
-
[ELB.5] Application and Classic Load Balancers logging should be enabled
-
[ELB.6] Application, Gateway, and Network Load Balancers should have deletion protection enabled
-
[ELB.7] Classic Load Balancers should have connection draining enabled
-
[ELB.9] Classic Load Balancers should have cross-zone load balancing enabled
-
[ELB.10] Classic Load Balancer should span multiple Availability Zones
-
[ELB.13] Application, Network and Gateway Load Balancers should span multiple Availability Zones
-
[EMR.1] Amazon EMR cluster primary nodes should not have public IP addresses
-
[ES.1] Elasticsearch domains should have encryption at-rest enabled
-
[ES.2] Elasticsearch domains should not be publicly accessible
-
[ES.3] Elasticsearch domains should encrypt data sent between nodes
-
[ES.4] Elasticsearch domain error logging to CloudWatch Logs should be enabled
-
[ES.5] Elasticsearch domains should have audit logging enabled
-
[ES.6] Elasticsearch domains should have at least three data nodes
-
[ES.7] Elasticsearch domains should be configured with at least three dedicated master nodes
-
[ES.8] Connections to Elasticsearch domains should be encrypted using the latest TLS security policy
-
[EventBridge.3] EventBridge custom event buses should have a resource-based policy attached
-
[IAM.1] IAM policies should not allow full "*" administrative privileges
-
[IAM.3] IAM users' access keys should be rotated every 90 days or less
-
[IAM.5] MFA should be enabled for all IAM users that have a console password
-
[IAM.7] Password policies for IAM users should have strong configurations
-
[KMS.1] IAM customer managed policies should not allow decryption actions on all KMS keys
-
[KMS.3] Amazon KMS keys should not be deleted unintentionally
-
[Lambda.1] Lambda function policies should prohibit public access
-
[Lambda.5] VPC Lambda functions should operate in multiple Availability Zones
-
[MSK.1] MSK clusters should be encrypted in transit among broker nodes
-
[MQ.5] ActiveMQ brokers should use active/standby deployment mode
-
[Neptune.2] Neptune DB clusters should publish audit logs to CloudWatch Logs
-
[Neptune.4] Neptune DB clusters should have deletion protection enabled
-
[Neptune.4] Neptune DB clusters should have deletion protection enabled
-
[Neptune.5] Neptune DB clusters should have automated backups enabled
-
[Neptune.6] Neptune DB cluster snapshots should be encrypted at rest
-
[Neptune.7] Neptune DB clusters should have IAM database authentication enabled
-
[Neptune.8] Neptune DB clusters should be configured to copy tags to snapshots
-
[NetworkFirewall.3] Network Firewall policies should have at least one rule group associated
-
[NetworkFirewall.6] Stateless Network Firewall rule group should not be empty
-
[Opensearch.1] OpenSearch domains should have encryption at rest enabled
-
[Opensearch.2] OpenSearch domains should not be publicly accessible
-
[Opensearch.3] OpenSearch domains should encrypt data sent between nodes
-
[Opensearch.4] OpenSearch domain error logging to CloudWatch Logs should be enabled
-
[Opensearch.5] OpenSearch domains should have audit logging enabled
-
[Opensearch.6] OpenSearch domains should have at least three data nodes
-
[Opensearch.7] OpenSearch domains should have fine-grained access control enabled
-
[RDS.3] RDS DB instances should have encryption at-rest enabled
-
[RDS.4] RDS cluster snapshots and database snapshots should be encrypted at rest
-
[RDS.5] RDS DB instances should be configured with multiple Availability Zones
-
[RDS.6] Enhanced monitoring should be configured for RDS DB instances
-
[RDS.8] RDS DB instances should have deletion protection enabled
-
[RDS.9] RDS DB instances should publish logs to CloudWatch Logs
-
[RDS.10] IAM authentication should be configured for RDS instances
-
[RDS.11] RDS instances should have automatic backups enabled
-
[RDS.12] IAM authentication should be configured for RDS clusters
-
[RDS.13] RDS automatic minor version upgrades should be enabled
-
[RDS.15] RDS DB clusters should be configured for multiple Availability Zones
-
[RDS.17] RDS DB instances should be configured to copy tags to snapshots
-
[RDS.23] RDS instances should not use a database engine default port
-
[RDS.25] RDS database instances should use a custom administrator username
-
[Redshift.1] Amazon Redshift clusters should prohibit public access
-
[Redshift.2] Connections to Amazon Redshift clusters should be encrypted in transit
-
[Redshift.4] Amazon Redshift clusters should have audit logging enabled
-
[Redshift.6] Amazon Redshift should have automatic upgrades to major versions enabled
-
[Redshift.7] Redshift clusters should use enhanced VPC routing
-
[Redshift.8] Amazon Redshift clusters should not use the default Admin username
-
[Redshift.9] Redshift clusters should not use the default database name
-
[S3.1] S3 general purpose buckets should have block public access settings enabled
-
[S3.2] S3 general purpose buckets should block public read access
-
[S3.3] S3 general purpose buckets should block public write access
-
[S3.5] S3 general purpose buckets should require requests to use SSL
-
[S3.8] S3 general purpose buckets should block public access
-
[S3.9] S3 general purpose buckets should have server access logging enabled
-
[S3.12] ACLs should not be used to manage user access to S3 general purpose buckets
-
[S3.13] S3 general purpose buckets should have Lifecycle configurations
-
[S3.17] S3 general purpose buckets should be encrypted at rest with Amazon KMS keys
-
[SageMaker.1] Amazon SageMaker notebook instances should not have direct internet access
-
[SageMaker.2] SageMaker notebook instances should be launched in a custom VPC
-
[SageMaker.3] Users should not have root access to SageMaker notebook instances
-
[SecretsManager.1] Secrets Manager secrets should have automatic rotation enabled
-
[SecretsManager.4] Secrets Manager secrets should be rotated within a specified number of days
-
[SSM.1] Amazon EC2 instances should be managed by Amazon Systems Manager
-
[WAF.2] Amazon WAF Classic Regional rules should have at least one condition
-
[WAF.3] Amazon WAF Classic Regional rule groups should have at least one rule
-
[WAF.4] Amazon WAF Classic Regional web ACLs should have at least one rule or rule group
-
[WAF.10] Amazon WAF web ACLs should have at least one rule or rule group
For more information about this standard, see Security Hub controls in the Amazon Control Tower User Guide.