Skip to content

Risk Documentation Requirements

This document outlines the requirements for documenting security risks and compliance deviations when using alternative container scanning approaches in environments with strict compliance requirements.

Risk Documentation Purpose

When using approaches that deviate from compliance frameworks or security best practices, proper risk documentation serves several purposes:

  1. Transparency: Clearly acknowledges known deviations from requirements
  2. Risk Management: Demonstrates understanding and management of security implications
  3. Authorization: Documents formal approval for the deviation
  4. Mitigation: Outlines additional controls implemented to address risks
  5. Traceability: Provides an audit trail for compliance assessments

Debug Container Approach Risk Documentation

If using the Debug Container Approach as an interim solution, document the following:

1. Security Control Deviation

Document that this approach deviates from standard access interfaces:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
## Security Control Deviation

This implementation deviates from the following security controls:

1. **DoD 8500.01 Section 4.b.(1)(b)** - Standard, vendor-supported interfaces
   - **Deviation**: Uses ephemeral debug containers which may be considered non-standard
   - **Justification**: Required for scanning distroless containers without shell access

2. **SRG-APP-000142** - Least privilege implementation
   - **Deviation**: Requires permissions to create ephemeral containers
   - **Justification**: Necessary for accessing distroless container filesystem

2. Risk Assessment

Document the additional attack surface introduced:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
## Risk Assessment

The Debug Container Approach introduces the following risks:

1. **Temporary Container Isolation Breaking**
   - **Risk Level**: Medium
   - **Description**: Ephemeral debug container has access to target container filesystem
   - **Mitigation**: Debug container is temporary and automatically removed after scanning

2. **Elevated Permission Requirements**
   - **Risk Level**: Medium
   - **Description**: Requires permissions to create ephemeral containers
   - **Mitigation**: Strict RBAC limiting which pods can have debug containers attached

3. Authorization

Obtain formal approval:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
## Authorization

This implementation has been reviewed and approved as an interim solution until the Kubernetes API Approach supports distroless containers.

| Role | Name | Signature | Date |
|------|------|-----------|------|
| Information System Security Officer | [Name] | [Signature] | [Date] |
| System Owner | [Name] | [Signature] | [Date] |

This approval expires on [Date] or when the Kubernetes API Approach is enhanced to support distroless containers, whichever comes first.

4. Enhanced Monitoring

Document additional monitoring:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
## Enhanced Monitoring

The following additional monitoring has been implemented:

1. **Debug Container Creation Alerting**
   - Alert on any ephemeral debug container creation
   - Daily review of all debug container activity logs

2. **Debug Container Duration Monitoring**
   - Alert on debug containers lasting longer than 15 minutes
   - Automatic termination of containers exceeding 30 minutes

Sidecar Container Approach Risk Documentation

If using the Sidecar Container Approach, more extensive risk documentation is required:

1. Security Control Deviation

Document explicit deviations:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
## Security Control Deviation

This implementation deviates from the following security controls:

1. **CIS Benchmark 5.2.4** - Minimize the admission of containers sharing process namespaces
   - **Deviation**: Explicitly requires shared process namespaces
   - **Justification**: Required to access distroless container filesystem

2. **DoD 8500.01 Section 4.b.(1)(b)** - Standard, vendor-supported interfaces
   - **Deviation**: Uses process namespace sharing for cross-container access
   - **Justification**: Necessary for accessing distroless container filesystem

3. **STIG V-242432** - Namespace isolation
   - **Deviation**: Breaks process isolation within pod
   - **Justification**: Required technical approach for distroless containers

2. Technical Risk Assessment

Document shared process namespace security implications:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
## Technical Risk Assessment

The Sidecar Container Approach introduces the following risks:

1. **Process Namespace Sharing**
   - **Risk Level**: High
   - **Description**: Sidecar container has complete visibility into target container processes
   - **Mitigation**: Strict security context, non-privileged execution, read-only filesystem

2. **Container Isolation Breaking**
   - **Risk Level**: High
   - **Description**: Violates "one process per container" principle
   - **Mitigation**: Enhanced container hardening, network isolation, minimal sidecar container

3. **Persistent Access**
   - **Risk Level**: Medium-High
   - **Description**: Sidecar exists for pod lifetime, not just scanning duration
   - **Mitigation**: Consider dedicated short-lived scanning pods instead of persistent sidecars

3. Implementation Controls

Document strict limitations:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
## Implementation Controls

The following additional security measures have been implemented:

1. **Strict Sidecar Container Hardening**
   - Minimal base image with only required tools
   - No shell access where possible
   - Read-only filesystem
   - Non-root user execution
   - No additional capabilities

2. **Enhanced Network Isolation**
   - Egress filtering limited to Kubernetes API only
   - No ingress traffic allowed
   - Pod-specific network policies

3. **Container Security Policies**
   - SecComp profile: RuntimeDefault
   - No privileged operation
   - No host resource access
   - CPU and memory limits

4. Formal Approval Chain

Document a more extensive approval chain:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
## Formal Approval

This implementation has been reviewed by the security review board and approved with the understanding that it represents a temporary deviation from security best practices.

| Role | Name | Signature | Date |
|------|------|-----------|------|
| Chief Information Security Officer | [Name] | [Signature] | [Date] |
| Information System Security Officer | [Name] | [Signature] | [Date] |
| System Owner | [Name] | [Signature] | [Date] |
| Security Review Board Chair | [Name] | [Signature] | [Date] |

This approval is valid until [Date] and requires quarterly review and reauthorization.

5. Migration Plan

Document timeline for migration:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
## Migration Plan

The organization will migrate from the Sidecar Container Approach to the Kubernetes API Approach according to the following timeline:

| Milestone | Target Date | Responsible Party | Status |
|-----------|-------------|-------------------|--------|
| Kubernetes API Approach Enhancement Design | [Date] | [Team] | [Status] |
| Implementation and Testing | [Date] | [Team] | [Status] |
| Pilot Deployment | [Date] | [Team] | [Status] |
| Full Migration | [Date] | [Team] | [Status] |

Progress will be reviewed monthly and reported to the security review board.

Risk Documentation Template

Below is a general template for risk documentation that can be adapted for either approach:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# Security Risk Documentation for [Approach Name]

## 1. Implementation Overview
[Brief description of the implementation]

## 2. Security Control Deviations
[List all security controls or best practices that this implementation deviates from]

## 3. Risk Assessment
[Detailed assessment of security risks introduced]

## 4. Mitigation Strategy
[Controls implemented to mitigate identified risks]

## 5. Residual Risk
[Assessment of remaining risk after mitigations]

## 6. Monitoring and Detection
[Additional monitoring implemented for this approach]

## 7. Authorization
[Formal approval documentation]

## 8. Expiration and Review
[Expiration date and review schedule]

## 9. Migration Plan
[Plan to transition to a more compliant solution]

Updating Risk Documentation

Risk documentation should be reviewed and updated:

  1. Quarterly, or according to organizational policy
  2. When changes are made to the implementation
  3. When new vulnerabilities or attack vectors are discovered
  4. When compliance requirements change
  5. When the risk assessment changes

Risk Documentation Storage

Risk documentation should be:

  1. Stored in a secure, version-controlled repository
  2. Accessible to security assessors and auditors
  3. Protected from unauthorized modification
  4. Referenced in system security documentation
  5. Included in authorization packages