KSI-SVC-VCMValidating Communications

The strong claim here is narrow and worth stating precisely. validate-logs is real cryptography — SHA-256 hashing with SHA-256/RSA signing, an hourly digest file that references the last hour's log files and carries the signature of the previous digest — so a clean run positively asserts that the delivered log files were not modified or deleted, and can even assert that no log files were delivered in a window you believed was empty. What it will not do: validate files you moved, since they must stay where CloudTrail put them; and it cannot report tampering across a gap — disable validation for an hour and no digest exists for that hour, so the chain simply breaks. Enabling the feature is not the same as checking it, which is why both the Config rule and the CLI run belong here: the rule proves digests are being produced, the run is the only thing that verifies them. Object Lock and Vault Lock are prevention, not detection — they make a deletion fail rather than proving none happened, and Object Lock only counts if the mode and period match your policy: the rule's optional mode parameter is what pins GOVERNANCE versus COMPLIANCE, and unset it passes either. Vault Lock in governance mode can be removed by anyone holding the IAM permission, so read Locked together with LockDate — before that date even a compliance-mode lock is still removable. The honest gap is the host: SI-7 asks for integrity verification of software, firmware and information, and nothing above watches a filesystem. ECR tag immutability stops a tag being repointed at a different image but says nothing about drift inside a running instance; file integrity monitoring is third-party or self-built on AWS, and SI-7(1)'s ‘defined frequency’ is a policy number you compare against, not an API result. Finally, a NON_COMPLIANT-only query returns an empty array on success and says nothing about resources Config never evaluated — join it against recorder coverage before reading emptiness as compliance.

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.