Service-Managed Standard: AWS Control Tower
What is Service-Managed Standard: AWS Control Tower?
If you use AWS Control Tower and create this standard, you can configure the proactive controls of AWS Control Tower alongside the detective controls of Security Hub in the AWS Control Tower console.
Proactive controls help ensure that your AWS 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 AWS accounts. By enabling proactive and detective controls for your AWS environment, you can enhance your security posture at different stages of development.
Service-managed standards differ from standards that AWS Security Hub manages. For example, you must create and delete a service-managed standard in the managing service. However, you may configure controls for the standard in both the managing service and Security Hub. For more information about service-managed standards, see Service-managed standards.
In the Security Hub console and API, you can view Service-Managed Standard: AWS Control Tower alongside other Security Hub standards.
Creating the standard
This standard is available only if you create the standard in the
AWS Control Tower console. AWS Control Tower creates the standard for you when you enable the first Security Hub
control in the AWS Control Tower console. Security Hub controls are identified in the AWS Control Tower console as SH.ControlID
(for example, SH.CodeBuild.1). You're asked to confirm the control's enablement and the creation of the standard.
At this time, if you haven’t already enabled Security Hub, AWS Control Tower also enables Security Hub for you.
If you haven't set up AWS Control Tower, you aren't able to view or access this standard in the Security Hub console, Security Hub API, or AWS CLI. Even if you have set up AWS Control Tower, you aren't able to access this standard in the Security Hub console, Security Hub API, or AWS CLI without first creating the standard in the AWS Control Tower console.
This standard is only available in the AWS Regions where AWS Control Tower is available, including AWS GovCloud (US).
Enabling and disabling controls in the standard
After you've created the standard in the AWS 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: AWS Control Tower. You should enable and disable controls for the standard in the AWS Control Tower console. When you change the enablement status of a control in AWS Control Tower, the change is also reflected in Security Hub. However, enablement and disablement actions taken in Security Hub won't be reflected in AWS Control Tower.
When you enable or disable controls in AWS 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.
Viewing control status
You can view control status only in the Security Hub console, Security Hub API, and AWS CLI. Security Hub calculates control status based on the workflow and compliance status of the control findings. For more information about control status, see Determining the overall status of a control from its findings.
A control that you disable in AWS Control Tower has a control status of Disabled
in Security Hub unless you explicitly
enable that control in Security Hub.
Based on control statuses, Security Hub calculates a security score for Service-Managed Standard: AWS Control Tower. This score is only available in Security Hub. In addition, you can only view control findings in Security Hub. The control status, standard security score, and control findings aren't available in AWS Control Tower.
When you enable controls for Service-Managed Standard: AWS Control Tower, Security Hub may take up to 18 hours to generate findings for controls that use an existing AWS 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 the AWS Control Tower console by disabling all controls in the standard. This deletes the standard for all managed accounts and governed Regions in AWS Control Tower. Deleting the standard in AWS Control Tower removes it from the Standards page of the Security Hub console, and it's no longer accessible by the Security Hub API or AWS CLI.
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: AWS Control Tower and any other standards that you’ve enabled.
Finding field format for Service-Managed Standard: AWS Control Tower
When you create Service-Managed Standard: AWS Control Tower and enable controls for it, you'll start to receive control findings in Security Hub.
Security Hub reports control findings in the AWS Security Finding Format (ASFF).
These are the ASFF values for this standard's Amazon Resource Name (ARN) and GeneratorId
:
Standard ARN –
arn:aws:us-east-1
:securityhub:::standards/service-managed-aws-control-tower/v/1.0.0GeneratorId –
service-managed-aws-control-tower/v/1.0.0/
CodeBuild.1
For a sample finding for Service-Managed Standard: AWS Control Tower, see Sample control findings.
Controls that apply to Service-Managed Standard: AWS Control Tower
Service-Managed Standard: AWS Control Tower supports a subset of controls that are part of the AWS 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: AWS 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 AWS 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).
[ACM.1] Imported and ACM-issued certificates should be renewed after a specified time period
[APIGateway.1] API Gateway REST and WebSocket API execution logging should be enabled
[APIGateway.3] API Gateway REST API stages should have AWS 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
[AutoScaling.2] Amazon 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
[CodeBuild.1] CodeBuild GitHub or Bitbucket source repository URLs should use OAuth
[CodeBuild.2] CodeBuild project environment variables should not contain clear text credentials
[CodeBuild.4] CodeBuild project environments should have a logging AWS Configuration
[CodeBuild.5] CodeBuild project environments should not have privileged mode enabled
[DMS.1] Database Migration Service replication instances 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
[EC2.1] Amazon EBS snapshots should not be publicly restorable
[EC2.2] The VPC default security group should not allow inbound and outbound traffic
[EC2.3] Attached Amazon EBS volumes should be encrypted at-rest
[EC2.4] Stopped Amazon EC2 instances should be removed after a specified time period
[EC2.8] Amazon 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 AWS 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
[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 AWS KMS
[EKS.2] EKS clusters should run on a supported Kubernetes version
[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 Load Balancer deletion protection should be 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 Elastic MapReduce cluster master nodes should not have public IP addresses
[ES.1] Elasticsearch domains should have encryption at-rest enabled
[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 TLS 1.2
[ElasticBeanstalk.1] Elastic Beanstalk environments should have enhanced health reporting enabled
[ElasticBeanstalk.2] Elastic Beanstalk managed platform updates should be enabled
[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 AWS Configurations
[KMS.1] IAM customer managed policies should not allow decryption actions on all KMS keys
[Lambda.1] Lambda function policies should prohibit public access
[Lambda.5] VPC Lambda functions should operate in more than one Availability Zone
[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.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
[Opensearch.8] Connections to OpenSearch domains should be encrypted using TLS 1.2
[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.10] IAM authentication should be configured for RDS instances
[RDS.11] RDS instances should have automatic backups enabled
[RDS.13] RDS automatic minor version upgrades should be enabled
[RDS.17] RDS DB instances should be configured to copy tags to snapshots
[RDS.19] An RDS event notifications subscription should be configured for critical cluster events
[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.4] S3 buckets should have server-side encryption enabled
[S3.5] S3 buckets should require requests to use Secure Socket Layer
[S3.6] S3 permissions granted to other AWS accounts in bucket policies should be restricted
[S3.8] S3 Block Public Access setting should be enabled at the bucket-level
[S3.10] S3 buckets with versioning enabled should have lifecycle policies configured
[S3.12] S3 access control lists (ACLs) should not be used to manage user access to buckets
[S3.13] S3 buckets should have lifecycle policies configured
[SageMaker.1] Amazon SageMaker notebook instances should not have direct internet access
[SecretsManager.1] Secrets Manager secrets should have automatic rotation enabled
[SecretsManager.4] Secrets Manager secrets should be rotated within a specified number of days
[SNS.1] SNS topics should be encrypted at-rest using AWS KMS
[SNS.2] Logging of delivery status should be enabled for notification messages sent to a topic
[SSM.1] Amazon EC2 instances should be managed by AWS Systems Manager
[WAF.2] A WAF Regional rule should have at least one condition
[WAF.3] A WAF Regional rule group should have at least one rule
[WAF.4] A WAF Regional web ACL should have at least one rule or rule group
For more information about this standard, see Security Hub controls in the AWS Control Tower User Guide.