4.3 System Security and Privacy Plan (SSP/SSPP) Development

4.3 System Security and Privacy Plan (SSP/SSPP) Development

Within the NIST Risk Management Framework (RMF) and the ISC2 CGRC body of knowledge, Step 3 (Implement) transitions organizational risk decisions from strategic planning into operational reality. The central, mandatory deliverable of this lifecycle step is the System Security Plan (SSP), or in contemporary implementations incorporating privacy controls, the System Security and Privacy Plan (SSPP).

Governed primarily by NIST SP 800-18 Rev. 1 (Guide for Developing Security Plans for Federal Information Systems), NIST SP 800-37 Rev. 2 (Task I-1 and Task I-2), and OMB Circular A-130, the SSP serves as the definitive blueprint and single source of truth regarding how an information system is architected, bounded, operated, and defended against technical and environmental threats.

---

The SSP as a Living Authorization Artifact

A critical tenet tested on the CGRC examination is that an SSP is never a static, one-time document produced merely to satisfy a compliance checklist for an initial Authority to Operate (ATO). Instead, it is a living artifact that must be continuously maintained and updated throughout the system's operational lifecycle whenever:

1. Significant technical, architectural, or environmental modifications occur (e.g., cloud migration, major software upgrades, boundary alterations).
2. New hardware, software, or network interconnections are integrated.
3. Changes occur in system categorization (FIPS 199), risk tolerance, or applicable regulatory mandates.
4. Vulnerability assessments or continuous monitoring activities reveal control deficiencies requiring alternative implementations or compensating controls.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     THE SSP AS THE RMF SINGLE SOURCE OF TRUTH               │
│                                                                             │
│   System Security & Privacy Plan (SSP/SSPP)                                 │
│   ├── System Identification & Categorization (FIPS 199 / SP 800-60)         │
│   ├── System Environment, Boundary & Architecture (SP 800-37)               │
│   ├── Control Allocations: Common, Hybrid & System-Specific                 │
│   └── Control Implementation Statements (CIS) (SP 800-53 Rev. 5)            │
│             │                                                               │
│             ▼                                                               │
│   Security Assessment Plan (SAP) & Security Assessment Report (SAR)         │
│             │                                                               │
│             ▼                                                               │
│   Plan of Action and Milestones (POA&M) ──► Continuous Monitoring (ISCM)    │
└─────────────────────────────────────────────────────────────────────────────┘

---

Required Components of an Assessor-Ready SSP

According to NIST SP 800-18 Rev. 1, a comprehensive, assessor-ready SSP must be structured into standardized sections to provide the Authorizing Official (AO) and the Security Control Assessor (SCA) with complete visibility into system safeguards:

1. System Identification and Categorization

• System Unique Identifier & Acronym: Formal name and registration tracking ID (e.g., eMASS ID, CSAM ID).
• FIPS 199 Security Categorization: The high-water mark impact ratings for Confidentiality, Integrity, and Availability (e.g., SC = {(Confidentiality, Moderate), (Integrity, Moderate), (Availability, Low)}).
• System MAC / Criticality Level: Information system sensitivity, national security designation, or privacy threshold categorization.

2. System Operational Status

• Explicit identification of the system's current lifecycle state: Operational, Under Development, or Undergoing Major Modification.

3. Key Personnel and Contact Information

• Formally documented points of contact with assigned RMF roles:
  • Authorizing Official (AO) / Authorizing Official Designated Representative (AODR)
  • Information System Owner (ISO) / Program Manager
  • Information System Security Officer (ISSO) and Information System Security Manager (ISSM)
  • Senior Agency Official for Privacy (SAOP) / Chief Privacy Officer (CPO)
  • System Custodians and Technical Points of Contact (TPOC)

4. General System Description and Architecture

• Comprehensive narrative detailing the system's purpose, functional capabilities, and mission support role.
• Detailed system data flows, indicating ingress/egress points, trust boundaries, processing pipelines, and data storage repositories.

5. System Environment and Authorization Boundary

• Complete hardware, software, and firmware inventory (OS versions, database engines, commercial off-the-shelf [COTS] packages, custom software modules).
• System Boundary Diagrams (SBD) clearly marking components inside vs. outside the authorization perimeter.
• Physical and logical hosting environment (on-premises government facility, co-located data center, or FedRAMP-authorized Cloud Service Provider [IaaS/PaaS/SaaS]).

6. System Interconnections and External Dependencies

• Documentation of all external connections, supported by active Interconnection Security Agreements (ISAs), Memoranda of Understanding/Agreement (MOU/MOA), or Service Level Agreements (SLAs).
• Approved Ports, Protocols, and Services Management (PPSM) tables detailing listening ports, communication protocols (e.g., HTTPS/443, SSH/22, IPsec), and traffic directionality.

7. Related Security Plans and Governance Documents

• Direct cross-references to the system's Incident Response Plan (IRP), Information System Contingency Plan (ISCP), Configuration Management Plan (CMP), and Continuous Monitoring Strategy.

8. Control Implementation Statements (CIS)

• The core technical narrative of the SSP, detailing how each selected control from NIST SP 800-53 Rev. 5 (and applicable privacy controls) is satisfied.

---

Control Allocation and Inheritance Models

Controls documented in the SSP are categorized by their implementation responsibility. Accurately scoping control allocation prevents redundant assessment testing and ensures clear accountability:

┌─────────────────────────────────────────────────────────────────────────────┐
│                     CONTROL ALLOCATION HIERARCHY                            │
├─────────────────────────────────────────────────────────────────────────────┤
│  1. COMMON CONTROLS (Inherited)                                             │
│     • Provided by enterprise GSS, physical security office, or CSP          │
│     • System Owner inherits 100% of the safeguard without configuring it    │
│     • Example: Physical data center access (PE-2, PE-3), enterprise HR (PS) │
├─────────────────────────────────────────────────────────────────────────────┤
│  2. HYBRID CONTROLS (Shared Responsibility)                                 │
│     • Split between Common Control Provider (CCP) and System Owner          │
│     • Example: Incident Response (IR-4) - Enterprise SOC detects/escalates; │
│       System Owner handles application-level investigation & remediation    │
├─────────────────────────────────────────────────────────────────────────────┤
│  3. SYSTEM-SPECIFIC CONTROLS (Dedicated)                                    │
│     • Implemented solely and specifically within the system boundary        │
│     • System Owner bears 100% technical and operational responsibility     │
│     • Example: Application role-based access control (AC-2, AC-3, AC-6)      │
└─────────────────────────────────────────────────────────────────────────────┘

---

Writing Assessor-Ready Control Implementation Statements (CIS)

A major focus of the CGRC examination is evaluating the rigor, specificity, and quality of Control Implementation Statements (CIS). Assessors require concrete, reproducible, and auditable descriptions of how a control is implemented.

The 5 Standard Implementation Status Designations

When authoring the SSP, every baseline control and control enhancement must be assigned an explicit status:

1. Implemented: The control is fully operational, actively enforced, tested, and meeting all specification requirements.
2. Partially Implemented: Specific technical or procedural components of the control are operational, but remaining aspects are undergoing deployment (must be linked to a tracked Plan of Action and Milestones [POA&M] item).
3. Planned: The control has been identified, architectural designs are approved, and resources are allocated, but operational execution has not yet commenced (must have a committed completion date in the POA&M).
4. Alternative Implementation: The standard control cannot be implemented due to technical or operational constraints, but an approved compensating control provides equivalent or superior risk mitigation (requires formal AO approval and risk justification).
5. Not Applicable (N/A): The control does not apply to the system environment (e.g., wireless controls on a system with no wireless network cards or physical interfaces; requires explicit, documented rationale).

Anatomy of an Assessor-Ready Implementation Statement

To withstand rigorous Security Control Assessor (SCA) scrutiny, each statement must answer the Five Core Technical Questions:

• WHAT: What specific tool, mechanism, script, or configuration setting satisfies the requirement?
• WHO: Which specific organizational role (not individual person name) is responsible for executing and administering the control?
• HOW: How does the mechanism function under normal operations, error conditions, and administrative maintenance?
• WHERE: Where is the supporting evidence, audit artifact, standard operating procedure (SOP), or system log stored for assessor validation?
• WHEN / FREQUENCY: How frequently is the control executed, reviewed, audited, or renewed?

Deficient vs. Assessor-Ready Comparison Matrix

[!IMPORTANT] Assessor Scrutiny Rule: Never use passive voice, aspirational language ("The team intends to..."), or vague generalizations. If a control is partially implemented, write what is currently active, mark the status as Partially Implemented, and cite the exact POA&M Weakness ID for the remaining scope.

---

Machine-Readable Security Plans: NIST OSCAL

Traditional System Security Plans often span 500 to 1,500 pages of static Word or PDF documents, leading to severe synchronization lag, high administrative overhead, and human error. To modernize this process, NIST developed the Open Security Controls Assessment Language (OSCAL).

┌─────────────────────────────────────────────────────────────────────────────┐
│                     NIST OSCAL COMPLIANCE-AS-CODE LAYERS                    │
│                                                                             │
│   Control Layer:       Catalog Model ────► Profile Model (Tailored Baseline)│
│                                                  │                          │
│   Implementation:                                ▼                          │
│                        Component Definition ──► System Security Plan (SSP)  │
│                                                  │                          │
│   Assessment Layer:                              ▼                          │
│                        Assessment Plan (AP) ──► Assessment Results (AR)     │
│                                                  │                          │
│   Remediation Layer:                             ▼                          │
│                        Plan of Action & Milestones (POA&M)                  │
└─────────────────────────────────────────────────────────────────────────────┘

OSCAL Architecture and Models

OSCAL is a standardized, machine-readable data format (available in JSON, XML, and YAML) that provides end-to-end representation of control catalogs, baselines, system plans, and assessment data:

1. Catalog Model: Defines structured collections of security controls (e.g., the complete NIST SP 800-53 Rev. 5 catalog in JSON format).
2. Profile Model: Expresses tailored baseline selections and overlays (e.g., FedRAMP Moderate baseline profile referencing the 800-53 catalog).
3. Component Definition Model: Describes how specific software, hardware, or cloud services satisfy control requirements across various environments.
4. System Security Plan (SSP) Model: Represents the comprehensive SSP in structured JSON/XML, binding components, system boundary metadata, and control implementation statements together.
5. Assessment Plan (AP) & Assessment Results (AR) Models: Automates the ingestion of scan outputs, manual assessment findings, and test results from automated tools directly against the SSP baseline.
6. Plan of Action and Milestones (POA&M) Model: Tracks open weaknesses, remediation owners, scheduled milestones, and resolution dates in a machine-parsable format.

Benefits of OSCAL for GRC Practitioners

• Continuous Authorization: Enables automated validation of compliance state directly within DevSecOps CI/CD pipelines.
• Inheritance Mapping: Allows cloud consumers to automatically ingest CSP component definitions (e.g., AWS or Azure OSCAL SSPs) into their application SSPs.
• Elimination of Audit Redundancy: Assessors can run automated validation scripts against OSCAL JSON files rather than manually reading thousands of static document pages.

---

Real-World RMF Scenario: The Deficient Control Audit

Scenario: An agency undergoes an independent Security Control Assessment (SCA) for a newly modernized claims processing portal. The System Security Plan states for control AC-12 (Session Termination): "The system terminates sessions after inactivity." During testing, the SCA discovers that while web frontend sessions expire after 15 minutes, database direct management consoles (used by remote DBAs) remain open indefinitely without timeout.

GRC Action: The SCA issues a formal Other Weakness / Non-Compliance Finding in the Security Assessment Report (SAR). The ISSO is required to update the SSP with explicit parameters (specifying 15-minute inactivity timeouts across both web application and database management sessions), adjust the status to Partially Implemented, and open a formal POA&M ticket to configure database idle timeout parameters before the Authorizing Official will issue an ATO.

---

Common Exam Traps

• ⚠️ Trap: Confusing the System Security Plan (SSP) with the Security Assessment Report (SAR). The SSP is written by the system owner/ISSO describing how controls are implemented; the SAR is written by the independent assessor (SCA) describing the findings and effectiveness of those controls.
• ⚠️ Trap: Believing that an SSP only needs to be updated every 3 years. Federal standards (OMB A-130 and NIST SP 800-37 Rev. 2) require ongoing, continuous updates whenever significant system changes occur.
• ⚠️ Trap: Listing named individuals rather than roles in control implementation descriptions. Always specify roles (e.g., Database Administrator, ISSO) so the SSP remains valid through personnel turnover.