SC-8 (01)—Transmission Confidentiality and Integrity | Cryptographic Protection
>Control Description
>FedRAMP Baseline Requirements
Parameter Values
Additional Requirements and Guidance
SC-8 (1) Requirement: Please ensure SSP Section 10.3 Cryptographic Modules Implemented for Data At Rest (DAR) and Data In Transit (DIT) is fully populated for reference in this control. SC-8 (1) Guidance: See M-22-09, including "Agencies encrypt all DNS requests and HTTP traffic within their environment" SC-8 (1) applies when encryption has been selected as the method to protect confidentiality and integrity. Otherwise refer to SC-8 (5). SC-8 (1) is strongly encouraged. SC-8 (1) Guidance: Note that this enhancement requires the use of cryptography which must be compliant with Federal requirements and utilize FIPS validated or NSA approved cryptography (see SC-13.) SC-8 (1) Guidance: When leveraging encryption from the underlying IaaS/PaaS: While some IaaS/PaaS services provide encryption by default, many require encryption to be configured, and enabled by the customer. The CSP has the responsibility to verify encryption is properly configured.
>Discussion
Encryption protects information from unauthorized disclosure and modification during transmission. Cryptographic mechanisms that protect the confidentiality and integrity of information during transmission include TLS and IPSec. Cryptographic mechanisms used to protect information integrity include cryptographic hash functions that have applications in digital signatures, checksums, and message authentication codes.
>Kubernetes Implementation Guidance
What This Control Means in Practice
FedRAMP SC-8(1) requires cryptographic protection for all data in transit, with FIPS 140-2 validated modules (per SC-13). Per M-22-09 (Zero Trust Architecture), agencies must encrypt all DNS requests and HTTP traffic within their environment. In Kubernetes, this means: • Service mesh mTLS using FIPS-validated cryptographic libraries for pod-to-pod encryption • TLS 1.2+ with FIPS-approved cipher suites at all ingress points • Encrypted DNS (DNS-over-TLS or DNS-over-HTTPS) within the cluster where feasible • FIPS-enabled container base images for applications handling cryptographic operations • Certificate management with automated rotation (cert-manager with approved CAs) Per FedRAMP guidance: 'When leveraging encryption from the underlying IaaS/PaaS: While some services provide encryption by default, many require encryption to be configured and enabled by the customer. The CSP has the responsibility to verify encryption is properly configured.'
Implementation Examples
Automated certificate management addresses FedRAMP's requirement to verify encryption is properly configured. cert-manager handles issuance, rotation, and renewal automatically, reducing the risk of expired certificates causing transmission protection gaps. For FedRAMP systems, use a CA that issues certificates with FIPS-validated key generation.
# Automate TLS certificate issuance and rotation
# Supports Let's Encrypt, Venafi, HashiCorp Vault, and private CAs
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: security@agency.gov
privateKeySecretRef:
name: letsencrypt-prod-key
solvers:
- http01:
ingress:
class: nginx
---
# Certificate request with automatic renewal
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: app-tls
namespace: production
spec:
secretName: app-tls-cert
issuerRef:
name: letsencrypt-prod
kind: ClusterIssuer
dnsNames:
- app.agency.gov
duration: 2160h # 90 days
renewBefore: 360h # Renew 15 days before expiryHow to Validate
# FedRAMP SC-8(1) Cryptographic Compliance Checklist # 1. Document all cryptographic modules (for SSP Section 10.3) echo '=== Ingress Controller ===' kubectl exec -n ingress-nginx deploy/ingress-nginx-controller -- nginx -V 2>&1 | grep -i openssl echo '=== Service Mesh Proxy ===' kubectl exec <proxy-pod> -c istio-proxy -- envoy --version 2>/dev/null || \ kubectl exec <proxy-pod> -c istio-proxy -- openssl version echo '=== etcd ===' kubectl exec -n kube-system <etcd-pod> -- etcd --version # 2. Verify minimum TLS 1.2 everywhere for port in 443 6443 2379; do echo "Port $port: $(echo | openssl s_client -connect localhost:$port -tls1_1 2>&1 | grep -c 'handshake failure') (1=TLS1.1 rejected, good)" done # 3. Check FIPS mode in proxy containers kubectl exec <proxy-pod> -c istio-proxy -- cat /proc/sys/crypto/fips_enabled 2>/dev/null || echo 'FIPS status check not available (container OS may not expose this)'
>Assessment Interview Topics
Questions assessors commonly ask
Process & Governance:
- •What policies govern the implementation of cryptographic protection?
- •How are system and communications protection requirements defined and maintained?
- •Who is responsible for configuring and maintaining the security controls specified in SC-8(1)?
- •What is your cryptographic key management policy?
Technical Implementation:
- •How is cryptographic protection technically implemented in your environment?
- •What systems, tools, or configurations enforce this protection requirement?
- •How do you ensure that cryptographic protection remains effective as the system evolves?
- •What encryption mechanisms and algorithms are used to protect data?
Evidence & Documentation:
- •What documentation demonstrates the implementation of SC-8(1)?
- •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 demonstrate that FIPS 140-2 validated cryptography is used?
Ask AI
Configure your API key to use AI features.