Skip to main content

OSCAL Implementation Layer: System Security Plan (SSP) Model

SSP SchemaSSP ConvertersReference
JSON SchemaXML to JSON Converter
(How do I use this?)
Outline
Reference
Index
XML SchemaJSON to XML Converter
(How do I use this?)
Outline
Reference
Index

Purpose

The OSCAL system security plan (SSP) model represents a description of the control implementation of an information system. The SSP model is part of the OSCAL implementation layer.

The OSCAL SSP model enables full modeling of highly granular SSP content, including points of contact, system characteristics, and control satisfaction descriptions. At a more detailed level, this includes the system's authorization boundary, information types and categorization, inventory, and attachments. In terms of control satisfaction, it models control parameter values, responsible roles, implementation status, control origination, and a description of control satisfaction at a level of granularity down to a specific control statement. Control satisfaction can be defined for the system as a whole or for individual implemented components.

Authors and Consumers

SSP Authors

System Owners and System Security Plan Authors

Through delegation, system owners create and maintain SSP content to document the implementation of controls within their system.

SSP Consumers

Assessors, Customers, Authorizing Officials, Leveraging System Owners

Assessors consume SSPs in the planning and execution of a system assessment relative to an established control baseline and compliance framework. Authorizing Officials consume SSPs in the adjudication of a system as part of approving an authorization to operate.

Model Overview

An OSCAL profile is organized as follows:

  • Metadata: Metadata syntax is identical and required in all OSCAL models. It includes information such as the document's title, publication version, publication date, and OSCAL version. Metadata is also used to define roles, parties (people, teams and organizations), and locations.
  • Import Profile: Identifies the applicable control baseline for the system. This baseline is represented as an OSCAL profile.
  • System Characteristics: Represents attributes of the system, such as its name, description, models, and information processed.
  • System Implementation: Represents relevant information about the system's deployment, including user roles, interconnections, services, and system inventory.
  • Control Implementation: Describes how each control in the baseline is implemented within the system.
  • Back Matter: Back matter syntax is identical in all OSCAL models. It is used for attachments, citations, and embedded content such as graphics.
A diagram depicting the system security plan model. As described in the text, within the larger system security plan model box, it shows a metadata at the top, followed by an import profile box, system characteristics box, system implementation box, control implementation box, and finally a back matter box.

Key Concepts

The OSCAL system security plan (SSP) model represents a description of the control implementation of an information system. The SSP model is part of the OSCAL implementation layer.

The OSCAL SSP model enables full modeling of highly granular SSP content, including points of contact, system characteristics, and control satisfaction descriptions. At a more detailed level, this includes the system's authorization boundary, information types and categorization, inventory, and attachments. In terms of control satisfaction, it models control parameter values, responsible roles, implementation status, control origination, and a description of control satisfaction at a level of granularity down to a specific control statement. Control satisfaction can be defined for the system as a whole or for individual implemented components.

The figure below expresses represents the portion of the OSCAL stack as it relates to an OSCAL SSP. A diagram representing the OSCAL stack from a system security plan's perspective.

Important Note to Developers

Every time the content of an OSCAL file changes, the following must also change:

  • A new UUID value must be generated and assigned to the root element's uuid.
  • The last-modified field in metadata must be assigned with the date and time at the moment the file is saved with the modified content.

These are two mechanisms by which tools can quickly "know" if a file has changed since it was last encountered. This document level UUID is the only UUID in OSCAL associated with version control.

When converting between formats, such as XML to JSON, these values should remain the same. This enables tools to know the content within the two formats is equivalent.

Identifier References

An OSCAL SSP may contain references to information that is instance scoped (e.g., in the SSP model), cross-instance scoped (e.g., in a referenced profile, catalog, or component definition model), or external (e.g., references to non-OSCAL resources). The following summarizes the scenarios where an OSCAL SSP may have references to other content.

Instance

An instance scoped identifier reference is used to reference information in the same OSCAL SSP instance.  This scenario supports enforcement of constraints since all of the information required to check the validity of the reference is readily available in the SSP.

Cross Instance

A cross-instance scoped identifier reference is used to reference information imported from another OSCAL instance. The following are examples of cross-instance references in an OSCAL SSP.

  • OSCAL uses the import-profile field to reference an OSCAL profile or catalog representing the system's control baseline. This scenario supports validation and enforcement of constraints, provided the imported OSCAL profile or resolved profile is accessible. In this case, the controls and parameters referenced from the SSP can be verified to exist in the resolved profile.
  • Use of links to SSP leveraged authorizations, established through the use of the leveraged-authorization field, present another cross-instance scoped identifier scenario. In this scenario an OSCAL SSP has leveraged authorization(s), which reference a leveraged SSP. Some of the information in the leveraged SSP may be referenced if the leveraged SSP is also in OSCAL format. If the leveraging SSP author has access to the leveraged system SSP, this scenario supports validation of constraints on the leveraging SSP to enforce the referential integrity of cross-references to leveraged system SSP details.
  • Links to component definitions (CDEFs) provide lineage from an SSP's implemented system component back to a relevant source of transferred content. This could include cases where an OSCAL SSP component has a reference to a component in a component definition. If the component definition is resolvable, this scenario supports enforcement of referential integrity between the SSP and components in the component definition.

External

Finally, OSCAL supports references to (non-OSCAL) external resources through use of the link field. These external references do not provide enough contextual information to know the format and/or structure of data in the referenced resource. Additionally, there is no assurance that SSP authors have access to linked external data, so these references cannot be validated.

Reference Constraints

The following table summarizes constraints for identifier references in an OSCAL SSP:

ReferenceTarget ScopeTarget ElementTarget ID TypeReferential Constraint Description
@component-uuid
(XML | JSON)
instance scoped, leveraged authorizationcomponent
(XML | JSON)
UUIDReference to a component that is implementing a control. A single target component must be found in target SSP instance. Component must be defined in local SSP or leveraged SSP.
@control-id
(XML | JSON)
import-profilecontrol
(XML | JSON)
TokenA single target control with the matching id must be found in the baseline, which may be nested within groups and/or controls within the baseline.
@provided-uuid
(XML | JSON)
leveraged authorizationprovided/@uuid
(XML | JSON)
UUIDReference to a provided control implementation which is inherited by a leveraging system. A single matching target provided control implementation statement must be found in the leveraged SSP.
party-uuid*
(XML | JSON)
instance scoped, import-profile, leveraged authorizationparty
(XML | JSON)
party
(XML | JSON)
UUIDThis is a reference to a party (person or organization). A single target party with a matching UUID must be found in the SSP, imported baseline, or leveraged SSP.
@role-id*
(XML | JSON)
role-id*
(XML | JSON)
role-ids*
(JSON)
instance scoped, import-profile, leveraged authorizationrole
(XML | JSON)
role
(XML | JSON)
TokenThis is a reference to a role. A single target role with a matching id must be found in the SSP, imported baseline, or leveraged SSP.
@param-id*
(XML | JSON)
import-profileparam
(XML | JSON)
TokenThis is a reference to a parameter defined in (resolved) baseline. A single target parameter with the matching id must be found in the baseline, which may be nested within groups and/or controls within the baseline.
@statement-id
(XML | JSON)
import-profilestatement
(XML | JSON)
TokenThis is a reference to a statement defined in (resolved) baseline. A single target statement with the matching id must be found in a control in the baseline.

* Note: Some elements have multiple references.

Modeling Validation Information

OSCAL is designed to allow the capture of relevant details related to independent validation of components. See the Validation Modeling tutorial for details.

Content Examples

Multiple examples of SSP expressed using the OSCAL SSP model can be found in the OSCAL GitHub repository in XML, JSON, and YAML formats.

The following tutorial is provided related to the catalog model.

This page was last updated on July 5, 2022.