AWS securityhub documentation change
Summary
Removed two security controls: ELB.21 (encrypted health check protocols) and ELB.22 (encrypted transport protocols for target groups) from the documentation
Security assessment
The change removes documentation about existing security controls but doesn't provide evidence of addressing a specific vulnerability. While the removed content described security features (encrypted health checks and transport protocols), the deletion itself doesn't indicate a security incident or weakness. The change appears to be a documentation cleanup rather than a response to a security issue.
Diff
diff --git a/securityhub/latest/userguide/elb-controls.md b/securityhub/latest/userguide/elb-controls.md index 0a78559cd..0c62c58b4 100644 --- a//securityhub/latest/userguide/elb-controls.md +++ b//securityhub/latest/userguide/elb-controls.md @@ -5 +5 @@ -[ELB.1] Application Load Balancer should be configured to redirect all HTTP requests to HTTPS[ELB.2] Classic Load Balancers with SSL/HTTPS listeners should use a certificate provided by AWS Certificate Manager[ELB.3] Classic Load Balancer listeners should be configured with HTTPS or TLS termination[ELB.4] Application Load Balancer should be configured to drop invalid 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.8] Classic Load Balancers with SSL listeners should use a predefined security policy that has strong AWS Configuration[ELB.9] Classic Load Balancers should have cross-zone load balancing enabled[ELB.10] Classic Load Balancer should span multiple Availability Zones[ELB.12] Application Load Balancer should be configured with defensive or strictest desync mitigation mode[ELB.13] Application, Network and Gateway Load Balancers should span multiple Availability Zones[ELB.14] Classic Load Balancer should be configured with defensive or strictest desync mitigation mode[ELB.16] Application Load Balancers should be associated with an AWS WAF web ACL[ELB.17] Application and Network Load Balancers with listeners should use recommended security policies[ELB.18] Application and Network Load Balancer listeners should use secure protocols to encrypt data in transit[ELB.21] Application and Network Load Balancer target groups should use encrypted health check protocols[ELB.22] ELB target groups should use encrypted transport protocols +[ELB.1] Application Load Balancer should be configured to redirect all HTTP requests to HTTPS[ELB.2] Classic Load Balancers with SSL/HTTPS listeners should use a certificate provided by AWS Certificate Manager[ELB.3] Classic Load Balancer listeners should be configured with HTTPS or TLS termination[ELB.4] Application Load Balancer should be configured to drop invalid 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.8] Classic Load Balancers with SSL listeners should use a predefined security policy that has strong AWS Configuration[ELB.9] Classic Load Balancers should have cross-zone load balancing enabled[ELB.10] Classic Load Balancer should span multiple Availability Zones[ELB.12] Application Load Balancer should be configured with defensive or strictest desync mitigation mode[ELB.13] Application, Network and Gateway Load Balancers should span multiple Availability Zones[ELB.14] Classic Load Balancer should be configured with defensive or strictest desync mitigation mode[ELB.16] Application Load Balancers should be associated with an AWS WAF web ACL[ELB.17] Application and Network Load Balancers with listeners should use recommended security policies[ELB.18] Application and Network Load Balancer listeners should use secure protocols to encrypt data in transit @@ -480,44 +479,0 @@ For information about configuring security protocols for listeners, see the foll -## [ELB.21] Application and Network Load Balancer target groups should use encrypted health check protocols - -**Category:** Protect > Data Protection > Encryption of data-in-transit - -**Severity:** Medium - -**Resource type:** `AWS::ElasticLoadBalancingV2::TargetGroup` - -**AWS Config rule:** [elbv2-targetgroup-healthcheck-protocol-encrypted](https://docs.aws.amazon.com/config/latest/developerguide/elbv2-targetgroup-healthcheck-protocol-encrypted.html) - -**Schedule type:** Change triggered - -**Parameters:** None - -This control checks whether the target group for application and network load balancer health checks use an encrypted transport protocol. The control fails if the health check protocol does not use HTTPS. This control is not applicable to Lambda target types. - -Load Balancers send health check requests to registered targets to determine their status and route traffic accordingly. The health check protocol specified in the target group configuration determines how these checks are performed. When health check protocols use unencrypted communication such as HTTP, the requests and responses can be intercepted or manipulated during transmission. This allows attackers to gain insights into infrastructure configuration, tamper with health check results, or conduct man-in-the-middle attacks that affect routing decisions. Using HTTPS for health checks provides encrypted communication between the load balancer and its targets, protecting the integrity and confidentiality of health status information. - -### Remediation - -To configure encrypted health checks for your Application Load Balancer target group, see [Update the health check settings of an Application Load Balancer target group](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/modify-health-check-settings.html) in the _Elastic Load Balancing User Guide_. To configure encrypted health checks for your Network Load Balancer target group, see [Update the health check settings of an Network Load Balancer target group](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/modify-health-check-settings.html) in the _Elastic Load Balancing User Guide_. - -## [ELB.22] ELB target groups should use encrypted transport protocols - -**Category:** Protect > Data Protection > Encryption of data-in-transit - -**Severity:** Medium - -**Resource type:** `AWS::ElasticLoadBalancingV2::TargetGroup` - -**AWS Config rule:** [elbv2-targetgroup-protocol-encrypted](https://docs.aws.amazon.com/config/latest/developerguide/elbv2-targetgroup-protocol-encrypted.html) - -**Schedule type:** Change triggered - -**Parameters:** None - -This control checks whether an Elastic Load Balancing target group uses an encrypted transport protocol. This control does not apply to target groups with a target type of Lambda or ALB, or target groups using the GENEVE protocol. The control fails if the target group does not use HTTPS, TLS, or QUIC protocol. - -Encrypting data in transit protects it from interception by unauthorized users. Target groups that use unencrypted protocols (HTTP, TCP, UDP) transmit data without encryption, making it vulnerable to eavesdropping. Using encrypted protocols (HTTPS, TLS, QUIC) ensures that data transmitted between load balancers and targets is protected. - -### Remediation - -To use an encrypted protocol, you must create a new target group with HTTPS, TLS, or QUIC protocol. Target group protocol cannot be modified after creation. To create Application Load Balancer target group, see [Create a target group for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-target-group.html) in the _Elastic Load Balancing User Guide_. To create Network Load Balancer target group, see [Create a target group for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-target-group.html) in the _Elastic Load Balancing User Guide_. -