[Update] 12 new check items have been added to Security Hub's security standards (2025/07/15)
Introduction
The Security Hub User Guide has been updated, and 12 new controls were added on July 15, 2025.
The revision history is as follows:
Document history for the AWS Security Hub User Guide - AWS Security Hub
In this entry, I will introduce information about the newly added controls with brief comments.
For each control, I will summarize the following information:
Item | Overview |
---|---|
Severity | Indicates the severity of findings as defined by Security Hub. Critical > High > Medium > Low in order of importance. |
Summary | Briefly summarizes what is checked by the control. |
Reference Documents | Compiles links to official documentation and blog sites that are helpful for understanding the control. |
The 12 controls added this time are:
- [CloudFront.15] CloudFront distributions should use the recommended TLS security policy
- [Cognito.2] Cognito identity pools should not allow unauthenticated identities
- [EC2.180] EC2 network interfaces should have source/destination checking enabled
- [ELB.18] Application and Network Load Balancer listeners should use secure protocols to encrypt data in transit
- [MSK.4] MSK clusters should have public access disabled
- [MSK.5] MSK connectors should have logging enabled
- [MSK.6] MSK clusters should disable unauthenticated access
- [RDS.45] Aurora MySQL DB clusters should have audit logging enabled* [Redshift.18] Redshift clusters should have Multi-AZ deployments enabled
- [S3.25] S3 directory buckets should have lifecycle configurations
- [SSM.6] SSM Automation should have CloudWatch logging enabled
- [SSM.7] SSM documents should have the block public sharing setting enabled
Let's look at each one.
CloudFront
[CloudFront.15] CloudFront distributions should use the recommended TLS security policy
Severity
Medium
Overview
This control checks whether Amazon CloudFront distributions are configured to use the recommended TLS security policy. The control fails if a CloudFront distribution is not configured to use the recommended TLS security policy.
When conducting HTTPS communication with CloudFront distributions, it's recommended to avoid using older SSL/TLS protocol versions or weak encryption suites and instead apply the latest security policies. This ensures strong encryption for communication between viewers and CloudFront, reducing security risks such as man-in-the-middle attacks and communication interception.
Reference Documentation
Cognito
[Cognito.2] Cognito identity pools should not allow unauthenticated identities
Severity
Medium
Overview
This control checks whether Amazon Cognito ID pools are configured to allow unauthenticated identities. The control fails if guest access is enabled in the ID pool (if the AllowUnauthenticatedIdentities
parameter is set to true).
Allowing unauthenticated users (guest users) access to Amazon Cognito ID pools creates a security risk because temporary authentication credentials are issued even to anonymous users for AWS resources. This control recommends disabling unauthenticated access or properly restricting permissions to ensure that only properly authenticated users can access AWS resources.
Reference Documentation
EC2### [EC2.180] EC2 network interfaces should have source/destination checking enabled
Severity
Medium
Overview
This control checks whether source/destination checking is enabled for Amazon EC2 Elastic Network Interfaces (ENIs) that you manage. The control fails if source/destination checking is disabled on a user-managed ENI.
This control checks only the following types of ENIs:
- aws_codestar_connections_managed
- branch
- efa
- interface
- lambda
- quicksight
By enabling source/destination checking on EC2 instances, AWS automatically verifies whether the instance is an appropriate source or destination of the traffic it receives. This control recommends consistently enabling this feature on all EC2 instances and ENIs to prevent IP spoofing attacks and unintended traffic routing.
Reference Documentation
ELB
[ELB.18] Application and Network Load Balancer listeners should use secure protocols to encrypt data in transit
Severity
Medium
Overview
This control checks whether Application Load Balancer or Network Load Balancer listeners are configured to use secure protocols for encrypting data in transit. The control fails if Application Load Balancer listeners are not configured to use the HTTPS protocol, or if Network Load Balancer listeners are not configured to use the TLS protocol.
Using encryption protocols (HTTPS for ALB, TLS for NLB) on Elastic Load Balancer listeners protects communication between clients and the load balancer. This control recommends appropriate encryption settings for all listeners to prevent risks of eavesdropping or tampering associated with plaintext communications. This is an important security measure, especially for applications handling sensitive data or environments with compliance requirements where encryption of data in transit is mandatory.
Reference Documentation
- Create an HTTPS listener for your Application Load Balancer
- Create a listener for your Network Load Balancer
MSK
[MSK.4] MSK clusters should have public access disabled
Severity
Critical#### Overview
This control checks whether public access is disabled for Amazon MSK clusters. The control fails if public access is enabled on an MSK cluster.
Disabling public access to Amazon MSK clusters and allowing only private connections from within a VPC reduces the risk of unauthorized access and data leakage. This control checks whether MSK clusters are directly accessible from the internet and recommends private access combined with appropriate authentication and authorization mechanisms.
Reference Documents
[MSK.5] MSK connectors should have logging enabled
Severity
Medium
Overview
This control checks whether logging is enabled for Amazon MSK connectors. The control fails if logging is disabled for MSK connectors.
By configuring log destinations (CloudWatch Logs, S3, Data Firehose) for MSK connectors, you can monitor and analyze the connector's operational status and error details. This control recommends appropriate logging configuration to enable troubleshooting and performance monitoring during operations.
Reference Documents
[MSK.6] MSK clusters should disable unauthenticated access
Severity
Medium
Overview
This control checks whether unauthenticated access is enabled for Amazon MSK clusters. The control fails if unauthenticated access is enabled on MSK clusters.
Enabling appropriate authentication mechanisms (IAM authentication, SASL/SCRAM, mutual TLS, etc.) for MSK clusters prevents unauthorized access by unauthenticated clients. This control detects configurations that allow unauthenticated access and recommends implementing proper access controls based on the principle of least privilege.
Reference Documents
- Update security settings of an Amazon MSK cluster
- Authentication and authorization for Apache Kafka APIs
RDS
[RDS.45] Aurora MySQL DB clusters should have audit logging enabled
Severity
Medium
Overview
This control checks whether audit logging is enabled for Amazon Aurora MySQL DB clusters.
The control fails in any of the following cases:
- The DB parameter group associated with the DB cluster is not synchronized
- The server_audit_logging parameter is not set to 1
- The server_audit_events parameter is set to an empty value
Enabling database audit logs allows for detection of unauthorized access, tracking of data changes, and meeting compliance requirements. This control verifies that important database activities such as login attempts, data manipulation, and schema changes are properly logged, and recommends security incident investigation and regulatory compliance.#### Reference Documentation
Redshift
[Redshift.18] Redshift clusters should have Multi-AZ deployments enabled
Severity
Medium
Overview
This control checks whether Amazon Redshift clusters have multiple Availability Zone (Multi-AZ) deployments enabled. This control fails if Multi-AZ deployment is not enabled for an Amazon Redshift cluster.
By enabling Multi-AZ deployment for your Redshift cluster, you can maintain data warehouse availability even during a single AZ failure. We recommend adopting Multi-AZ configurations for critical data warehouse workloads to ensure business continuity and high availability.
Reference Documentation
S3
[S3.25] S3 directory buckets should have lifecycle configurations
Severity
Low
Overview
This control checks whether lifecycle rules are configured for S3 directory buckets. This control fails if a directory bucket does not have lifecycle rules configured, or if the expiration settings specified in the bucket's lifecycle rules do not match the parameter value you optionally specify.
The parameter targetExpirationDays
can be set to a value from 1 to 2147483647.
Properly configuring lifecycle configurations for S3 directory buckets enables automatic deletion of unnecessary objects and cleanup of incomplete multipart uploads. This control checks whether rules for object expiration or deletion of incomplete uploads are set, and recommends proper lifecycle management to optimize storage costs and improve bucket management efficiency.
Reference Documentation
SSM
[SSM.6] SSM Automation should have CloudWatch logging enabled
Severity
Medium
Overview
This control checks whether Amazon CloudWatch logging is enabled for AWS Systems Manager (SSM) Automation. This control fails if CloudWatch logging is not enabled for SSM Automation.
Recording script execution output to CloudWatch Logs when using SSM Automation ensures you maintain an audit trail and troubleshooting information for automation processes. The control verifies that results from aws:executeScript actions are properly logged, and recommends log recording for compliance requirements and operational monitoring.#### Reference Documentation
[SSM.7] SSM documents should have the block public sharing setting enabled
Severity
Critical
Overview
This control checks whether the "Block public sharing" setting is enabled for AWS Systems Manager documents. If the "Block public sharing" setting is disabled for Systems Manager documents, this control fails.
By enabling the public sharing block setting at the account level for SSM documents, you can reduce the risk of unintended public exposure and unauthorized access. This control recommends enabling the setting to restrict public sharing in each region to prevent SSM documents from being accidentally made publicly available.
Reference Documentation
Finally
We have reviewed the 12 new controls added to Security Hub.
To summarize this update:
Summary of Each Section
- Ensuring robust encryption with recommended TLS security policies for CloudFront distributions
- Restricting unauthenticated access in Cognito ID pools to maintain proper authentication
- Preventing IP spoofing attacks by enabling source/destination checks on EC2 network interfaces
- Protecting data in transit by using encrypted protocols (HTTPS/TLS) for ELB listeners
- Enhancing security for MSK clusters by disabling public access, implementing authentication mechanisms, and enabling logging
- Enabling audit logging for RDS (Aurora MySQL) to track database activity
- Ensuring high availability for Redshift clusters through Multi-AZ deployments
- Optimizing storage costs with lifecycle configurations for S3 directory buckets
- Preventing unintended public exposure by enabling audit logs for SSM Automation and blocking public sharing of SSM documents