SC-8(1)—Cryptographic Protection

MODERATE

HIGH

>Control Description

Implement cryptographic mechanisms to ☑prevent unauthorized disclosure of information; detect changes to information during transmission.

>Kubernetes Implementation Guidance

What This Control Means in Practice

SC-8(1) requires cryptographic mechanisms to prevent unauthorized disclosure and detect changes during transmission. In Kubernetes, this maps to specific cryptographic implementations across all communication layers. Key cryptographic requirements in Kubernetes: • Service mesh mTLS with X.509 certificates (Istio Citadel / Linkerd identity) for pod-to-pod encryption • TLS 1.2+ at ingress controllers with FIPS-validated cipher suites • etcd TLS for cluster state protection • Kubelet-to-API-server TLS with client certificate authentication • FIPS 140-2/140-3 validated cryptographic modules where required (use FIPS-enabled container images) For FedRAMP systems, cryptographic implementations must use FIPS 140-2 validated modules (see SC-13). Service meshes should be configured with FIPS-compliant cipher suites, and container base images should include FIPS-validated OpenSSL or BoringCrypto libraries.

Implementation Examples

DestinationRules configure TLS settings for outbound traffic from the sidecar proxy. ISTIO_MUTUAL mode uses Istio's built-in certificate authority (Citadel) for automatic mTLS. For FIPS compliance, deploy Istio with FIPS-enabled proxy images (e.g., Tetrate's FIPS builds) to ensure all cryptographic operations use validated modules.

# Enforce specific TLS settings for service-to-service communication
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: enforce-tls-settings
  namespace: production
spec:
  host: "*.production.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
      # For FIPS compliance, restrict to approved cipher suites
    connectionPool:
      http:
        h2UpgradePolicy: DEFAULT

Source: Istio Documentation — Destination Rules

How to Validate

# Comprehensive cryptographic verification for SC-8(1) # 1. Verify service mesh mTLS mode kubectl get peerauthentication -A -o yaml | grep -A2 'mtls:' # Should show: mode: STRICT # 2. Check TLS versions on ingress echo | openssl s_client -connect <ingress-ip>:443 2>/dev/null | grep 'Protocol\|Cipher' # Should show: TLSv1.2 or TLSv1.3 with approved ciphers # 3. Verify no plaintext services are exposed kubectl get svc -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}: {range .spec.ports[*]}port={.port} target={.targetPort} {end}{"\n"}{end}' # 4. Check for FIPS-enabled container images (if required) kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | sort -u | head -20 # 5. Verify Istio proxy uses FIPS crypto (Tetrate/FIPS builds) kubectl exec <istio-proxy-pod> -c istio-proxy -- openssl version # Should show FIPS-enabled OpenSSL or BoringCrypto # 6. Test mutual TLS between services kubectl exec <client-pod> -- curl -v https://<service>.<namespace>.svc.cluster.local 2>&1 | grep -E 'SSL|TLS|certificate'

>Cross-Framework Mappings

SCF

>Programmatic Queries

Beta

Related Services

ACM

KMS

CloudFront

CLI Commands

Request or import SSL/TLS certificate from AWS Certificate Manager

aws acm request-certificate --domain-name example.com --validation-method DNS --tags Key=Environment,Value=Production

Create KMS key for encryption of data in transit

aws kms create-key --description 'KMS key for transmission encryption' --key-usage ENCRYPT_DECRYPT

Configure CloudFront distribution with encryption enforcement

aws cloudfront create-distribution --distribution-config file://cloudfront-config.json --requires-https-on-origin

Enable TLS version enforcement for API Gateway

aws apigateway update-stage --rest-api-id api-12345678 --stage-name prod --patch-operations op=replace,path=/*/securityPolicy,value=TLS_1_2

Open AWS Console Documentation

>Relevant Technologies

Technology-specific guidance with authoritative sources and verification commands.

Istio Linkerd Consul Connect

>Supplemental Guidance

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.

>Related Controls

SC-12

SC-13

>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.