SC-8—Transmission Confidentiality and Integrity
>Control Description
>FedRAMP Baseline Requirements
Additional Requirements and Guidance
SC-8 Guidance: For each instance of data in transit, confidentiality AND integrity should be through cryptography as specified in SC-8 (1), physical means as specified in SC-8 (5), or in combination. For clarity, this control applies to all data in transit. Examples include the following data flows: - Crossing the system boundary - Between compute instances - including containers - From a compute instance to storage - Replication between availability zones - Transmission of backups to storage - From a load balancer to a compute instance - Flows from management tools required for their work - e.g. log collection, scanning, etc. The following applies only when choosing SC-8 (5) in lieu of SC-8 (1). FedRAMP-Defined Assignment / Selection Parameters SC-8 (5)-1 [a hardened or alarmed carrier Protective Distribution System (PDS) when outside of Controlled Access Area (CAA)] SC-8 (5)-2 [prevent unauthorized disclosure of information AND detect changes to information] SC-8 Guidance: SC-8 (5) applies when physical protection has been selected as the method to protect confidentiality and integrity. For physical protection, data in transit must be in either a Controlled Access Area (CAA), or a Hardened or alarmed PDS. Hardened or alarmed PDS: Shall be as defined in SECTION X - CATEGORY 2 PDS INSTALLATION GUIDANCE of CNSSI No.7003, titled PROTECTED DISTRIBUTION SYSTEMS (PDS). Per the CNSSI No. 7003 Section VIII, PDS must originate and terminate in a Controlled Access Area (CAA). Controlled Access Area (CAA): Data will be considered physically protected, and in a CAA if it meets Section 2.3 of the DHS's Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies. CSPs can meet Section 2.3 of the DHS' recommended practice by satisfactory implementation of the following controls PE-2 (1), PE-2 (2), PE-2 (3), PE-3 (2), PE-3 (3), PE-6 (2), and PE-6 (3). Note: When selecting SC-8 (5), the above SC-8(5), and the above referenced PE controls must be added to the SSP. CNSSI No.7003 can be accessed here: https://www.dcsa.mil/Portals/91/documents/ctp/nao/CNSSI_7003_PDS_September_2015.pdf
>Discussion
Protecting the confidentiality and integrity of transmitted information applies to internal and external networks as well as any system components that can transmit information, including servers, notebook computers, desktop computers, mobile devices, printers, copiers, scanners, facsimile machines, and radios. Unprotected communication paths are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of information can be accomplished by physical or logical means.
Physical protection can be achieved by using protected distribution systems. A protected distribution system is a wireline or fiber-optics telecommunications system that includes terminals and adequate electromagnetic, acoustical, electrical, and physical controls to permit its use for the unencrypted transmission of classified information. Logical protection can be achieved by employing encryption techniques.
Organizations that rely on commercial providers who offer transmission services as commodity services rather than as fully dedicated services may find it difficult to obtain the necessary assurances regarding the implementation of needed controls for transmission confidentiality and integrity. In such situations, organizations determine what types of confidentiality or integrity services are available in standard, commercial telecommunications service packages. If it is not feasible to obtain the necessary controls and assurances of control effectiveness through appropriate contracting vehicles, organizations can implement appropriate compensating controls.
>Kubernetes Implementation Guidance
What This Control Means in Practice
FedRAMP SC-8 explicitly calls out container-to-container communication as a data-in-transit path requiring protection. Per FedRAMP additional requirements, this control applies to all data in transit including 'between compute instances - including containers.' In Kubernetes environments authorized under FedRAMP, the following transmission paths must be protected with cryptography (SC-8(1)) or physical means (SC-8(5)): • Pod-to-pod communication (east-west traffic) — typically via service mesh mTLS • Ingress controller to backend services (north-south traffic) • API server, etcd, kubelet, and control plane component communication • Container image pulls from approved registries • Load balancer to compute instance communication • Log collection, vulnerability scanning, and monitoring tool data flows Service meshes (Istio, Linkerd) with strict mTLS provide the most comprehensive approach to satisfying SC-8 for east-west container traffic in FedRAMP-authorized systems. All cryptographic implementations must use FIPS 140-2 validated modules per SC-13.
Implementation Examples
FedRAMP SC-8 additional requirements explicitly list 'between compute instances - including containers' as a data flow requiring protection. Setting PeerAuthentication to STRICT mode enforces mTLS for all pod-to-pod communication, satisfying this requirement. For FedRAMP authorization, use FIPS-enabled Istio builds (e.g., Tetrate Istio Distro) to ensure FIPS 140-2 compliance per SC-13.
# Enforce mTLS for all pod-to-pod communication
# Satisfies FedRAMP SC-8 requirement for data in transit
# between compute instances including containers
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: default
namespace: istio-system
spec:
mtls:
mode: STRICTHow to Validate
# FedRAMP SC-8 Kubernetes Compliance Verification # 1. Verify mTLS enforcement (east-west / container-to-container) kubectl get peerauthentication -A # Expected: STRICT mode in istio-system or all application namespaces # 2. Identify pods without service mesh sidecar (mTLS gaps) kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}: {range .spec.containers[*]}{.name} {end}{"\n"}{end}' | grep -v istio-proxy | grep -v kube-system # 3. Verify NetworkPolicies in all namespaces for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do count=$(kubectl get networkpolicies -n $ns --no-headers 2>/dev/null | wc -l) echo "$ns: $count policies" done # 4. Check Ingress TLS configuration kubectl get ingress -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}: TLS={.spec.tls[*].hosts[*]}{"\n"}{end}' # 5. Verify FIPS-enabled crypto in service mesh proxies kubectl exec <istio-proxy-pod> -c istio-proxy -- openssl version # Should show FIPS-enabled build # 6. Check container registry TLS (image pull over TLS) kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | sort -u | grep -v '^$' # All images should use registry URLs with TLS (no http:// prefixes) # 7. Verify log collection uses TLS kubectl get configmap -n logging fluentd-config -o yaml | grep -i tls
>Cross-Framework Mappings
>Programmatic Queries
Related Services
CLI Commands
aws acm list-certificatesaws acm describe-certificate --certificate-arn ARNaws elbv2 describe-listeners --load-balancer-arn ARNaws s3api get-bucket-encryption --bucket BUCKET_NAME>Relevant Technologies
Technology-specific guidance with authoritative sources and verification commands.
>Assessment Interview Topics
Questions assessors commonly ask
Process & Governance:
- •What policies govern the implementation of transmission confidentiality and integrity?
- •How are system and communications protection requirements defined and maintained?
- •Who is responsible for configuring and maintaining the security controls specified in SC-8?
- •What is your cryptographic key management policy?
Technical Implementation:
- •How is transmission confidentiality and integrity technically implemented in your environment?
- •What systems, tools, or configurations enforce this protection requirement?
- •How do you ensure that transmission confidentiality and integrity remains effective as the system evolves?
- •What network boundary protections are in place (firewalls, gateways, etc.)?
- •What encryption mechanisms and algorithms are used to protect data?
Evidence & Documentation:
- •What documentation demonstrates the implementation of SC-8?
- •Can you provide configuration evidence or system diagrams showing this protection control?
- •What logs or monitoring data verify that this control is functioning correctly?
- •Can you provide network architecture diagrams and firewall rulesets?
- •Can you demonstrate that FIPS 140-2 validated cryptography is used?
Ask AI
Configure your API key to use AI features.