myctrl.tools
Compare

SC-8(2)Pre- And Post-Transmission Handling

>Control Description

Maintain the confidentiality; integrity of information during preparation for transmission and during reception.

>Kubernetes Implementation Guidance

What This Control Means in Practice

SC-8(2) addresses protecting information during preparation for transmission and during reception — the moments before data enters and after it exits the encrypted transport channel. In Kubernetes, this applies to: • Sidecar proxy data handling — information is decrypted at the Envoy/Linkerd proxy before reaching the application container (the "last mile" within the pod) • Container-to-sidecar communication within a pod (over localhost) • Data serialization/deserialization at API boundaries • Secret injection into containers (environment variables vs. mounted volumes) • Init container data preparation before the main container starts The key risk is that even with mTLS between pods, data is in plaintext within the pod between the sidecar proxy and the application container. Mitigations include pod security policies, read-only filesystems, and memory-only secret mounts.

Implementation Examples

Restricting container capabilities and using read-only root filesystems prevents attackers from intercepting or modifying data during pre/post-transmission handling within a pod. Memory-backed volumes (emptyDir with medium: Memory) ensure sensitive data like TLS certificates are never written to disk, reducing the window of exposure.

# Restrict container capabilities to protect data during
# pre/post-transmission handling within the pod
apiVersion: v1
kind: Pod
metadata:
  name: secure-app
  namespace: production
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: registry.example.gov/app:latest
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]
    volumeMounts:
    # Mount secrets in memory-only tmpfs (not written to disk)
    - name: tls-certs
      mountPath: /etc/tls
      readOnly: true
    - name: tmp
      mountPath: /tmp
  volumes:
  - name: tls-certs
    secret:
      secretName: app-tls
  - name: tmp
    emptyDir:
      medium: Memory
      sizeLimit: 64Mi
Source: Kubernetes Documentation — Pod Security Standards

How to Validate

# Verify pre/post-transmission handling protections # 1. Check that secrets are not exposed as environment variables kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}: {range .spec.containers[*].env[*]}{.name}={.valueFrom.secretKeyRef.name} {end}{"\n"}{end}' | grep -v '^$' # Prefer: secrets mounted as files, not env vars # 2. Verify Pod Security Standards enforcement kubectl get ns -o jsonpath='{range .items[*]}{.metadata.name}: {.metadata.labels.pod-security\.kubernetes\.io/enforce}{"\n"}{end}' # Should show: restricted or baseline # 3. Check for read-only root filesystems kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}: readOnlyRootFilesystem={.spec.containers[0].securityContext.readOnlyRootFilesystem}{"\n"}{end}' # 4. Verify memory-backed volumes for sensitive data kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}: {range .spec.volumes[*]}{.name}(medium={.emptyDir.medium}) {end}{"\n"}{end}' | grep Memory

>Cross-Framework Mappings

>Supplemental Guidance

Information can be unintentionally or maliciously disclosed or modified during preparation for transmission or during reception, including during aggregation, at protocol transformation points, and during packing and unpacking. Such unauthorized disclosures or modifications compromise the confidentiality or integrity of the information.

>Assessment Interview Topics

Questions assessors commonly ask

Process & Governance:

  • What policies govern the implementation of pre- and post-transmission handling?
  • How are system and communications protection requirements defined and maintained?
  • Who is responsible for configuring and maintaining the security controls specified in SC-8(2)?

Technical Implementation:

  • How is pre- and post-transmission handling technically implemented in your environment?
  • What systems, tools, or configurations enforce this protection requirement?
  • How do you ensure that pre- and post-transmission handling remains effective as the system evolves?

Evidence & Documentation:

  • What documentation demonstrates the implementation of SC-8(2)?
  • Can you provide configuration evidence or system diagrams showing this protection control?
  • What logs or monitoring data verify that this control is functioning correctly?

Ask AI

Configure your API key to use AI features.