KSI-SVC-SINSecuring Information

These rules prove encryption is present, not which key backs it. Pass ENCRYPTED_VOLUMES and RDS_STORAGE_ENCRYPTED a kmsId/kmsKeyId parameter to additionally assert a specific CMK rather than any key. These three cover the dominant data stores; extend with the analogous rules for DynamoDB (dynamodb-table-encrypted-kms), EFS (efs-encrypted-check), SNS (sns-encrypted-kms), and other services you actually run — the recipe is the pattern, not the exhaustive list. The S3 rule was removed from this recipe: S3 has applied SSE-S3 to every bucket since 5 January 2023 and it cannot be disabled, so s3-bucket-server-side-encryption-enabled cannot fail and proved nothing. ENCRYPTED_VOLUMES sees attached volumes only, leaving detached volumes and every snapshot unproven, and no CMK is asserted — a human names the data stores in scope, confirms each has a rule, and reads key ownership for SC-28 (01), which is not claimed.

The SC-08.01 enhancement (cryptographic protection in transit) is the TLS requirement these rules assert. ELB_TLS_HTTPS_LISTENERS_ONLY covers Classic Load Balancers only — for Application/Network Load Balancers add elbv2-acm-certificate-required and alb-http-to-https-redirection-check, and pair with acm-certificate-expiration-check so the certs terminating TLS are valid. These three cover the dominant public data paths; extend to the services you actually run (e.g. api-gw-ssl-enabled, elasticsearch-node-to-node-encryption-check). ELB_TLS_HTTPS_LISTENERS_ONLY evaluates Classic Load Balancers only and returns NOT_APPLICABLE where there is no listener, so on an ALB/NLB estate that assertion passes having examined nothing; whether the TLS that terminates is FIPS-validated is carried by the listener's SslPolicy, which no command here reads, and a human confirms it — SC-08 (01) is not claimed.

Rated partial: these rules prove key management (rotation, retention) as telemetry, but SC-13's core requirement — that the cryptographic module itself is FIPS 140-2/3 validated — is satisfied by using AWS KMS FIPS endpoints (kms-fips.<region>.amazonaws.com) and validated modules, which is a documented configuration/architecture assertion the compliance result does not itself carry. Attach the KMS FIPS endpoint usage evidence and the CMP module certificate reference alongside these results. Rotation is not supported for asymmetric/HMAC/imported-material/custom-key-store keys — scope the rotation rule accordingly.

Private hosted zones cannot be DNSSEC-signed, which is why the first command narrows to Config.PrivateZone==false before the per-zone loop; asserting SIGNING over every hosted zone would fail on private zones for a reason that is not a finding. Drive the loop from list-hosted-zones rather than from whatever get-dnssec happens to return, so a zone that was never configured is a visible failure instead of an absent row. SC-20's second limb — the means to indicate the security status of child zones and enable verification of a chain of trust — is carried by KeySigningKeys[].DSRecord, which get-dnssec returns and the assertions cover. Whether that DS record has actually been published by the parent is a fact about the registrar, not about the zone: where the domain is registered with Route 53 Domains, get-domain-detail's DnssecKeys evidences it directly, and where it is registered elsewhere the registrar's own DS confirmation is the artifact to attach. No assertion is written against the third command for that reason — it is decisive for some tenants and inapplicable to others, and an assertion that silently does not apply is worse than a named gap. ACTION_NEEDED on either the zone status or a KSK is an outage risk, not a paperwork state; AWS recommends a CloudWatch alarm on DNSSECInternalFailure and DNSSECKeySigningKeysNeedingAction, and a collector that only samples weekly should not be the first thing to notice it. list-hosted-zones returning no public zones passes all three assertions vacuously — a human confirms this account is the authoritative DNS for the offering's names, and confirms registrar-side DS publication where the registrar is not Route 53 Domains. Partial for the second limb of SC-20.

Rated partial for a reason that is in AWS's own words rather than in our judgement of the control: ListResolverDnssecConfigs returns one element per DNSSEC validation configuration associated with the account and "doesn't contain disabled DNSSEC configurations for the resource". A VPC with validation off is therefore ABSENT from the array, not reported as DISABLED — so a check of the form "every returned entry is ENABLED" is vacuously true on an account that has enabled validation nowhere. That is the exact shape of a check that passes while proving nothing, so it is not written as an assertion. The decidable question is a set comparison: every VpcId from describe-vpcs must appear as a ResourceId in ResolverDnssecConfigs with ValidationStatus ENABLED. That spans two collections, and the assertion vocabulary compares a field against a constant rather than one command's output against another's, so the completeness half is a human read. The telemetry is real and specific; what it cannot do by itself is prove coverage. Two further limits worth attaching to the evidence. Validation is applied by the VPC Resolver when it performs recursive resolution, so if the VPC forwards to another resolver, that resolver is the one doing recursion and must validate — the AWS status says nothing about it. And the VPC Resolver ignores the DO and CD bits and does not set AD or return DNSSEC records, so a workload cannot perform its own validation downstream of it; where a system owes that, the artifact is the resolver it runs instead.

SC-23 says protect the authenticity of communications sessions, and authenticity has a floor and a ceiling. The floor is transport: a session that can be read or injected into on the wire is not authentic in any sense, and the floor is entirely in this output — which listeners terminate TLS, under which negotiated policy, with which certificate, and whether the HTTP door redirects instead of answering. The ceiling is session identity above the transport: regenerating a session identifier on privilege change, invalidating it at logout, binding it to the principal it was issued to, refusing one that was replayed. That lives in application code and emits no AWS telemetry, which is what keeps this partial. Say which half you are evidencing, or a reader will assume the larger one. Read SslPolicy as a version floor, not a checkmark. The policy name encodes the oldest protocol it will negotiate: ELBSecurityPolicy-TLS13-1-2-2021-06 admits TLS 1.3 and 1.2 only, while ELBSecurityPolicy-TLS13-1-0-2021-06 and the 2016-08 default still admit TLS 1.0. The FIPS families — listed by the describe-ssl-policies query above — use the AWS-LC FIPS validated module, and AWS marks ELBSecurityPolicy-TLS13-1-1-FIPS-2023-04 and ELBSecurityPolicy-TLS13-1-0-FIPS-2023-04 as legacy compatibility only, FIPS cryptography that, in AWS's own words, may not conform to the latest NIST guidance for TLS configuration. FIPS in the name is therefore not by itself the answer to a FIPS question. The redirection rule is narrower than it sounds: ALB_HTTP_TO_HTTPS_REDIRECTION_CHECK is NON_COMPLIANT both when an HTTP listener has no redirect and when it forwards to another HTTP listener instead of redirecting — but it covers Application Load Balancers only. Network Load Balancer TLS listeners, API Gateway, and anything terminating TLS on an instance are outside it and have to be enumerated by hand.

SC-22 asks two things of the systems that collectively provide name and address resolution: that they be FAULT-TOLERANT, and that they implement INTERNAL AND EXTERNAL ROLE SEPARATION. This output answers the second and cannot answer the first. Role separation is a field. Config.PrivateZone marks each hosted zone as serving internal or external resolution, and an architecture where internal names are served from private zones associated with VPCs while public names are served from public zones is exactly the separation the control describes — visible, enumerable, and reviewable on the cadence the indicator asks for. Resolver endpoints are collected beside the zones because they are where the two roles actually meet: an INBOUND endpoint lets on-premises resolvers query into the VPC, an OUTBOUND endpoint forwards VPC queries out, and each one is a crossing point that the zone list alone does not show. Fault tolerance is not a field and is not measurable from your account. Route 53's resilience is a property of AWS's anycast name server fleet, not of your configuration, and no call against your account returns it. It is inherited under the shared responsibility model and evidenced from AWS's own authorization package — say so in the assessment rather than presenting a zone list as though it spoke to availability. The one adjacent thing this output does show is whether YOUR crossing points are healthy, which is what the Status clause below asserts, and that is endpoint health rather than service fault tolerance. Conflating them would be the whole control's failure in one line. A scope edge that decides whether this evidence means anything: name resolution is only separated if the two zone sets actually differ. Two hosted zones for the same domain, one private and one public, is split-horizon DNS and is a legitimate and common pattern — but so is a single public zone answering internal names, which satisfies neither role separation nor the control, and the assertions below cannot tell those apart because the grammar compares a field to a constant rather than one zone's Name to another's. Reconcile the two zone sets by name as part of the review. A private hosted zone also cannot be DNSSEC-signed, which is why signing is a separate recipe and not folded in here. And LinkedService is worth reading before anything is concluded from a zone's presence: a zone created by another AWS service on your behalf is inventory rather than architecture. One KSI only. KSI-SVC-SIN — information secured from unwanted access — is what a private zone does, by keeping internal names off the public resolvers. The recipe does not claim the identity indicator that also reaches this control in the dataset: nothing in these two responses evaluates a permission.