System Security Plan
6 minute read
A System Security Plan is an OSCAL-specific model to represent a system as a whole. In Lula, the generate system-security-plan
command creates an oscal-system-security-plan
object to explain the system as a whole by using the compliance data provided by the component-definition
. The System Security Plan will detail each contributor and groups of contributors that play any part in the system’s lifecycle. It will also include every component
that make up the system with each implemented-requirement
that details the controls each tools helps to satisfy and how.
flowchart TD
catalog1["Catalog/Profile 1"] --> component1["Component Definition 1"]
catalog2["Catalog/Profile 2"] --> component2["Component Definition 2"]
catalog3["Catalog/Profile 3"] --> component3["Component Definition 3"]
component1 --> ssp["System Security Plan (SSP)"]
component2 --> ssp["System Security Plan (SSP)"]
component3 --> ssp["System Security Plan (SSP)"]
Metadata
Includes all responsible parties
, parties
, and roles
that play a part in the system. Responsible parities are the collection of contributors who are responsible for the maintenance and development of the system. Parties includes any internal or external collection of contributors that contribute to the system or the lifecycle of the system. Roles are the designated positions contributors take within the system and system’s lifecycle.
Version
is the specific revision of the document. Revision
is a sequential list of revisions such as predecessor-version
, successor-version
, and version-history
. These fields track the history of the document as changes are made.
System Characteristics
Describes the system and the systems security requirements. This includes the security-sensitivity-level
which is the overall system’s sensitivity categorization as defined by FIPS-199. The system’s overall level of expected impact resulting from unauthorized disclosure, modification, or loss of access to information through security-impact-level
children items of security-objective-confidentiality
, security-objective-integrity
, and security-objective-availability
.
The System Characteristics also outline the impacts to risk specifically based on confidentiality-impact
, integrity-impact
, and availability-impact
with the supporting data.
The system characteristics also includes the authorization-boundary
, network-architecture
, and data-flow
diagrams or links to the location of the diagrams. The authorization-boundary
diagram outlines everything within the environment and is in scope for the system’s compliance framework. The network-architecture
focuses on the network connections made within the system to include port and protocol. Lastly the data-flow
diagram shows the flow of data within the system as it moves.
The system-information
field contains all of the details about the type of data stored, processed, and transmitted by the system. The possible options are fips-199-low
, fips-199-moderate
, and fips-199-high
. Consult NIST 800-60 for help defining the system.
System Implementation
Contains any leveraged-authorizations
, if used, all components
used to build the system, all users
with their type and access levels listed, and inventory-items
detailing how the overall system is configured. The inventory-items
is a large collection of everything that lives within the system such as operating systems and infrastructure. In addition the responsible-parties
are listed and connected to each piece they are responsible for.
Control Implementation
Contains all of the compliance controls the system must adhere to as outlined within the profile
. Each implemented-requirement
is listed detailing the control and the information of how the system meets the control on a by-component
instance. The component will outline all export
, inherited
, and satisfied
indications for each control the component represents.
System Security Plan Generation
NOTE: This command is in an active research phase.
To generate a system security plan, you need the following context:
- The component definition
- The profile source or catalog source
The following command could generate a system security plan with the above context:
lula generate system-security-plan --component .src/test/unit/valid-component.yaml --catalog https://raw.githubusercontent.com/usnistgov/oscal-content/main/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_HIGH-baseline-resolved-profile_catalog.json
There are optional flags that can be added to the command to generate a system security plan:
- The output file of the component
-o
or--output
;oscal-system-security-plan.yaml
System Security Plan Generate Context
The system-security-plan
can be generated using the upstream catalog and/or profile in conjunction with the component-definition
. There are net new fields that are apart of the system-security-plan
that are not within the component-definition
or catalog/profile that currently do not make sense to add as props. Those items are under the section Elements in SSP Not in Component Definition
. There are items that are not in the system-security-plan
but also not in the component-definition
that currently do make sense to create as props. Those items are under the section Elements NOT in Component Definition that need added for SSP Generate
. Lastly as a note there are items within the component-definition
that are not used in the system-security-plan
that can be found under the section Elements NOT in Component Definition that need added for SSP Generate
.
The items in Elements in SSP Not in Component Definition
need further context to fill in the missing elements as well as establish data across OSCAL models. Some examples of the data fields are within the metadata
fields such as responsible-roles
, responsible-parties
, and parties
that can be added to the system-security-plan
that do not directly map from the component-definition
field. Additional context can be added through common OSCAL fields such as props
, links
, and remarks
.
Further Research Fields
The following fields need further research to further enhance generating an SSP.
inherited
export
Elements in Component Definition Not in SSP
import-component-definitions
capabilities
uuid
name
description
props
links
incorporates-components
component-uuid
description
Elements in SSP Not in Component Definition
system-characteristics
system-ids
identifier-type
id
system-name
system-name-short
description
security-sensitivity-level
system-information
information-types
id
title
description
security-objective-confidentiality
security-objective-integrity
security-objective-availability
security-impact-level
security-objective-confidentiality
security-objective-integrity
security-objective-availability
status
state
remarks
authorized-boundary
description
props
links
diagrams
uuid
description
props
links
caption
remarks
remarks
network-architecture
description
props
links
diagrams
uuid
description
props
links
caption
remarks
remarks
data-flow
description
props
links
diagrams
uuid
description
props
links
caption
remarks
remarks
props
links
remarks
system-implementation
users
uuid
title
short-name
description
props
links
role-ids
authorized-privileges
title
description
functions-performed
remarks
leveraged-authorizations
uuid
title
props
links
party-uuid
date-authorized
remarks
inventory-items
uuid
description
props
links
remarks
control-implementation
implemented-requirements
statements
satisfied
uuid
responsibility
description
props
links
responsible-roles
role-id
props
links
party-uuid
remarks
role-ids
by-components
satisfied
uuid
responsibility
description
props
links
responsible-roles
role-id
props
links
party-uuid
remarks
role-ids
Elements NOT in Component Definition that need added for SSP Generate
control-implementation
implemented-requirements
by-components
implementation-status
state
remarks
statements
by-components
implementation-status
state
remarks
Component Definition to SSP Transferable Fields
NOTE: repetitive children elements have been truncated to reduce bloat
metadata
title
published
last-modified
version
oscal-version
revisions
document-ids
props
links
roles
locations
actions
control-implementation
description
set-parameters
param-id
values
remarks
implemented-requirements
uuid
control-id
props
links
set-parameters
param-id
values
remarks
statements
statement-id
props
responsible-roles
links
by-components
by-components
component-uuid
description
props
links
set-parameters
param-id
values
remarks
system-implementation
(Contains Fields from Component Definition)components
uuid
type
title
description
purpose
props
links
status
protocols
implemented-components
component-uuid
props
links
Feedback
Was this page helpful?