Supports research effort #1

• Identify a few sources of test data sets to use for demonstration.
• Demonstrate the application of the outline from OSCAL/issues/722.
• Identify potential issues, or improvements that should be made to support modeling CRM content.
• This model needs a name that generally encompasses responsibilities, including shared responsibilities.
• At a minimum, this exported content should include customer responsibility statements associated with components and control definition statements.

https://github.com/usnistgov/OSCAL-Research/blob/prototype-candidate/spirals-example/2022-07-Customer-Responsibility-Model/2022-07-05.001.md. (Generally it would be expected that this ticket is created, then a commit referencing this ticket is made with the spiral template as the content of the commit. Would produce a link below)

This issue covers work for the spiral supporting Effort #5

Belongs to #18

• Relates to: usnistgov/OSCAL#1333
• All issues related to mapping requirements and feedback need to be consolidated and synthesized.
• Findings were produced at the end of 2022, but not shared. These need to be summarized as a part of the effort.
• A draft of updates to the model needs to be produced.

Problem Statement

High Value Targets (HVTs) are information systems for which unauthorized access, use, disclosure, disruption, modification, or destruction could cause a significant impact to an organization’s ability to perform its mission or conduct business. NIST 800-160 and MITRE CREF define a set of defensive controls (a subset of NIST 800-53, for which profiles are already in place) however they fail to be applied by the cybersecurity community because of their complexity and lack of regulator interest to mandate (possibly again due to complexity). For this reason, focusing on the assets that matter most to advanced cyber adversaries (i.e. High Value Targets), is the most important step of any organization wanting to define and execute a threat-informed and risk aware security strategy.

I have been collaborating with MITRE -as part of MITRE CREF- and ResilienCyCon from 2022 on the concept of High Value Target. From 2023 I have launched the concept of Cyber Resilience Officer, which is the role that would be in charge within an organization of such OSCAL-defined control profile for HVTs. The concept got endorced by NIST NICE and a Cyber Resiliency competency area is being added.
In addition, the HVT concept is part of the OASIS Indicators of Behavior work now and a proposal for addition of HVT attributes is on the table for STIX/TAXXI.

More about High Value Target: www.highvaluetarget.org
More about Cyber Resilience Officer: www.cyberresilienceofficer.org

As an example (please bear in mind I am not an OSCAL expert yet):

<oscal:profile xmlns="https://csrc.nist.gov/ns/oscal/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:highvaluetarget="http://www.highvaluetarget.org">
oscal:metadata
oscal:titleHigh-Value Target Protection Profile</oscal:title>
oscal:version1.0</oscal:version>
oscal:oscal_version1.0.0</oscal:oscal_version>
oscal:remarksThis profile aligns NIST 800-160 controls to protect against cyber attacks, with a focus on safeguarding the "stealthiness" asset from being used to bypass detection tools by adversaries.</oscal:remarks>
</oscal:metadata>
<oscal:import href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160.pdf" oscal:version="1.0.0" />
<oscal:import href="https://www.highvaluetarget.org/definitions" oscal:version="1.0.0" />
oscal:controls
<oscal:control id="stealthiness-defense">
oscal:titleStealthiness Asset Defense</oscal:title>
oscal:statementThe organization implements measures to defend the "stealthiness" asset from being exploited to bypass detection tools by adversaries.</oscal:statement>
oscal:control-improvement-idsstealthiness</oscal:control-improvement-ids>
oscal:references
<oscal:reference href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160.pdf">
oscal:citationNIST Special Publication 800-160</oscal:citation>
</oscal:reference>
</oscal:references>
</oscal:control>

</oscal:controls>
oscal:back-matter
oscal:resources
oscal:resource
oscal:titleHigh-Value Target Definition</oscal:title>
oscal:descriptionThe definition and criteria for identifying high-value targets are based on the information provided by www.highvaluetarget.org.</oscal:description>
<oscal:link href="https://www.highvaluetarget.org/definitions" />
</oscal:resource>
</oscal:resources>
</oscal:back-matter>
</oscal:profile>

A holding place for potential changes to the documentation and process as we encounter issues.

Problem Statement

The mapping model has been available through the development branch, and there are a number of requests to modify and improve the model before release.

• Relates to: usnistgov/OSCAL#1333
• All issues related to mapping requirements and feedback need to be consolidated and synthesized.
• Findings were produced at the end of 2022, but not shared. These need to be summarized as a part of the effort.
• A draft of updates to the model needs to be produced.

Summary of Issues

• #32 (ssp referencing)
• #30 (evidence)
• #29 (unmapped)
• #28 (provenance)
• #27 (qualifier)
• #18 (primary)

Reference Links

• Reference Prototype: https://pages.nist.gov/OSCAL-Reference/models/prototype-mapping-model/
• Working Branch: https://github.com/usnistgov/OSCAL/tree/prototype-mapping-model
• Previous Development Model: https://github.com/usnistgov/OSCAL/tree/feature-mapping
• Spiral Documents: https://github.com/usnistgov/OSCAL-DEFINE/tree/main/research-2023/effort-mapping-model

Note: The prototype builds on the previous development model.

OSCAL DEFINE Research Effort Link

#5

GitHub Project Link

https://github.com/usnistgov/OSCAL

Author(s)

Chris Compton

Focus

This is just a test

Requirements

• Test the issue

Background

Just for testing.

Analysis

No response

Recommendation

No response

Reference

No response

Current Spiral Sequence Number

No response

Previous Spiral Sequence Number

No response

Next Spiral Sequence Number

No response

Problem Statement

Belongs to #18

Prepare a feature request to add a required provenance assembly to document contextual information and responsibility for the mapping.

Problem Statement

Belongs to #18

OSCAL SSP authors need the ability to export content from a full SSP, suitable for customers to import into another SSP, without exposing all content of the full SSP. At a minimum, this exported content should include customer responsibility statements associated with components and control definition statements. When the SSP author uses optional syntax to define customer-consumable content about what is inherited, this content must also be included.

• Original Issue

• Informal discussion and feedback can be shared here: #13

Problem Statement

The mapping of controls or statements of controls is needed in the SSP and possibly Component Definition so the results of the assessment against one regulatory framework can be used to automatically infer the compliance status against other mapped frameworks.

For each control satisfaction, by-component, a mapping-record assembly is needed to document:

• the mapping relation (by uuid) to other control(s)
• the mapping document (by uuid) where the above mapping is to be found
• the locally tailored relation based on the control/statement implementation
• evidence requirements when different
• anything else?

This issue covers work for the spiral supporting Effort #5

This spiral supports research effort #1

• Identify any gaps in the current SSP model where existing data elements do not fit.
• Determine if the data elements in the SSP are exportable into a CRM by automated means.

Required Information

Title: Customer Responsibility Matrix, and Shared Responsibility Model

Problem Statement

We are interested in the creation of a model that supports the ability to export content from the System Security Plan (SSP) for customers to import/reference in a separate System Security Plan. This responsibility model is used to expose only the appropriate and necessary SSP content to a leveraging system, when the leveraging system owner is not entitled to see the entire SSP of the leveraged system.

Supporting Information

GitHub Project Link - https://github.com/usnistgov/OSCAL/
GitHub Issue # -
Impact - Not sure
Scope - Not sure
Audience - All OSCAL Users

Criticality

Significant - Places burden on operational use, workflow and/or velocity.

Constraints

• The solution should only contain information that the author wishes to share with others.

Requirements

• Should be able to use information from SSP or CD models without exposing sensitive information.
• Should be able to facilitate a system owner's desire to properly reference content from a leveraged SSP when the full SSP is available to the authorizing official.

Participants

• The team at Company A would be willing to support this effort as needed to develop an approach and model.

Problem Statement

Belongs to #18

Prepare a feature request to add a qualifier assembly/tag as a part of the map assembly to describe requirements, incompatibilities and gaps that are identified between a target and source.

Problem Statement

Belongs to #18

Consider evidence as an important dimension of equivalency in some contexts, particularly if an organization is using a mapping to prepare for meeting a new standard based on another framework. If this particular approach requires a more in-depth synthesis using profiles and SSP documents, we should produce a guide for this.

Problem Statement

Based on recent spiral completion, it's time to update documentation around the process and produce a diagram of the workflow so that others can follow. This will help others participate in the process, and help aid in decision-making when spirals end.

I would also like to compare this to https://sprint.usds.gov/ to see if we should make some adjustments to how we conduct spirals/efforts.

Mainly a todo for @Compton-NIST at this point.

Problem Statement

We are interested in reworking the System Security Plan (SSP)'s system characteristics to support categorization frameworks other then fips-199. Currently the system characteristics assemblies expect users to record categorization data for a given information-type following the CIA triad of impacts and expects the user to respond with fips-199-low, -moderate, or -high. This design does not allow for users to record impacts that do not fit into the CIA triad, such as having dedicated privacy impact values. Additionally, authors writing additional OSCAL constraints would benefit from a field communicating the system categorization framework.

This issue was originally raised during the OSCAL Workshop, and in the issue usnistgov/OSCAL#1795.