NIST 800-53 REV 5 • SYSTEM AND SERVICES ACQUISITION

SA-8(18)Trusted Communications Channels

Implement the security design principle of trusted communications channels in {{ insert: param, sa-08.18_odp }}.

CMMC Practice Mapping

No direct CMMC mapping

NIST 800-171 Mapping

No direct NIST 800-171 mapping

Related Controls

Supplemental Guidance

The principle of trusted communication channels states that when composing a system where there is a potential threat to communications between components (i.e., the interconnections between components), each communication channel is trustworthy to a level commensurate with the security dependencies it supports (i.e., how much it is trusted by other components to perform its security functions). Trusted communication channels are achieved by a combination of restricting access to the communication channel (to ensure an acceptable match in the trustworthiness of the endpoints involved in the communication) and employing end-to-end protections for the data transmitted over the communication channel (to protect against interception and modification and to further increase the assurance of proper end-to-end communication).

Practitioner Notes

Trusted communications channels means that data moving between components must be protected against interception, modification, and replay. All network communication should use encrypted, authenticated channels.

Example 1: Enforce TLS 1.2 or higher for all network communications. Disable TLS 1.0 and 1.1, SSL v3, and weak cipher suites across all systems. Use Group Policy to set minimum TLS versions on Windows systems and configure web servers to present only strong cipher suites.

Example 2: For internal service-to-service communication, implement mutual TLS (mTLS) where both sides authenticate with certificates. In Kubernetes, use a service mesh like Istio to automatically enforce mTLS between all pods without requiring application-level changes.