Catalog constraint relax for CSF Data about oscal

[david-waltermire]

We started with a restrictive set of values to drive discussion like this with the intention that names will get expanded over time through subsequent OSCAL releases.

+1 for adding the allowed value example for catalog/group/control/part/@name. No concern.

In a control part, a statement has the associated meaning "a set of control implementation requirements." Allowing use of statement for catalog/group/part/@name does not make sense in the same way. Adding the allowed value statement here will change the semantics of what the term statement means. This makes other uses of statement more confusing and murky. I don't think making existing terms more confusing is desirable.

It would be better to create a new part name for this purpose. While I don't support the use of statement, I am open to any new term. Maybe something like description, explanation, or definition?

I would have no concern adding any of these terms to control parts or other similar places either, as there may be cases where descriptive text may be used in a control that isn't an overview, statement or guidance.

[iMichaela]

catalog/group/part/@name="statement"

The other recommendation, at face value, seems sensible. @iMichaela, what this is proposing is having parts that are statements that are not embedded with controls, and are free-form statements within groups this Metapath catalog/group/part/... is explicit/absolute, not a recursive descent with // in it.

Is that really what the CSF or other control frameworks expect? I want to make sure I understand. Is this the current CSF 2.x catalog we are referencing now? This is missing from the feature request and it is specific to the data cited in the issue.

@aj-stein-nist The catalog you are listing in not the one NIST is creating and plans to make available from the CPRT website.

[iMichaela]

In a control part, a statement has the associated meaning "a set of control implementation requirements." Allowing use of statement for catalog/group/part/@name does not make sense in the same way. Adding the allowed value statement here will change the semantics of what the term statement means. This makes other uses of statement more confusing and murky. I don't think making existing terms more confusing is desirable.

It would be better to create a new part name for this purpose. While I don't support the use of statement, I am open to any new term. Maybe something like description, explanation, or definition?

@david-waltermire-nist - Thank you for the +1 on 'example'.
I do not think catalog/group/part/@name must be a statement, so any other generic-enough term can be used but simplicity and reusability was in our minds. Here is the thinking process: to us, "Share the organization's mission (...) to provide a basis for identifying risks that may impede that mission" was 'implementable' function (a requirement) within the enterprise risk management. The only catch is in the pointer to control : "a set of control implementation requirements". Since ISO/IEC SC27 WG1 was very opinionated over the fact that controls and requirements are different things, can we keep the description as "a set of implementation requirements" (without control), and when applied to control/part@name, then will reflect implemented requirements for a control, when not associated with controls will be stand alone requirements, allowing a proper representation of CSF functions and ISO requirements (later on).

If this is OK, I can update the proposal and submit the PR. I am looking for reusability to make it easier adoptable.. Thoughts?

[aj-stein-nist]

Hi @nkeller08 👋. We will triage this issue and get back to you once it is prioritized, ready for work, and then completed.

[iMichaela]

In CSF, all functions are providing requirements type statements like: "Establish and monitor the organization's cybersecurity risk management strategy, expectations, and policy" , and are grouping categories and subcategories which makes them suitable fro OSCAL group element with a `part@name='statement' .

The commit: 76eec06 enforced very 800-53 specific constraints. To preserve the intent of not commit: "Removed allow-other="yes" from prop and part names in the OSCAL namespace to avoid namespace squatting on the official OSCAL namespace. Organizations using their own props will now be forced to use their own namespace, which was the original intention" but support NIST mission, the following values need to be added to the constraints:

catalog/group/part/@name="statement"
catalog/group/control/part/@name="example"

[aj-stein-nist]

catalog/group/part/@name="statement"

The other recommendation, at face value, seems sensible. @iMichaela, what this is proposing is having parts that are statements that are not embedded with controls, and are free-form statements within groups this Metapath catalog/group/part/... is explicit/absolute, not a recursive descent with // in it.

Is that really what the CSF or other control frameworks expect? I want to make sure I understand. Is this the current CSF 2.x catalog we are referencing now? This is missing from the feature request and it is specific to the data cited in the issue.

[iMichaela]

@aj-stein-nist The CSF (v1.1 and v2.0) defines Functions, that have categories and are broken down into subcategories. At each level there are requirements-like statements. This is , to some extend , the situation in ISO 27002 (if I remember correctly).

Here is a format (partial) that would reflect the description of the issue above:

<group class="function" id="GV">
      <title>GOVERN</title>
      <part name="statement" id="GV_stmt">
         <p>Establish and monitor the organization's cybersecurity risk management strategy, expectations, and policy</p>
      </part>
      <control class="category" id="GV.OC">
         <title>Organizational Context</title>
         <part name="statement" id="GV.OC_stmt">
            <p>The circumstances - mission, stakeholder expectations, and legal, regulatory, and contractual requirements - surrounding the organization's cybersecurity risk management decisions are understood (formerly ID.BE)</p>
         </part>
         <control class="subcategory" id="GV.OC-01">
            <title>GV.OC-01</title>
            <part name="statement" id="GV.OC-01_stmt">
               <p>The organizational mission is understood and informs cybersecurity risk management (formerly ID.BE-02, ID.BE-03)</p>
            </part>
            <part name="example" id="GV.OC-01.1">
               <p>Share the organization's mission (e.g., through vision and mission statements, marketing, and service strategies) to provide a basis for identifying risks that may impede that mission</p>
            </part>
         </control>

Current constraints would only allow for a name='overview' but the stmt is not an overview:

<part name="overview" id="GV_stmt">
         <p>Establish and monitor the organization's cybersecurity risk management strategy, expectations, and policy</p>
      </part>

As for the second constraint, example name is not allowed. Only overview, statements, guidance, implementation, assessment-methods, assessment-objectives: are allowed. One can argue 'guidance' is good enough for a name here, but in the reality a guidance and an example can coexist. FIPS 140 implementation guidance document is one of them that comes to mind, where each requirement can have guidance and examples of implementations accepted by the CMVP.

<part name="example" id="GV.OC-01.1">
               <p>Share the organization's mission (e.g., through vision and mission statements, marketing, and service strategies) to provide a basis for identifying risks that may impede that mission</p>
            </part>      

CSF calls those implementation examples, but specificity is the enemy of a broad adoption, so we propose to include example which will support other catalogs that have (few EU standards as I was told) or plan on having examples (e.g. FINOS).

[iMichaela]

@aj-stein-nist - The above proposal is in [1949-imichaela-catalog-part-name 7cf6920]. I will not submit a PR before this discussion concludes favorably. I am looking for consensus and not enforcement. I strongly believe that the current catalog/group/part/@name="overview" as the ONLY allowed value for the name is super restrictive for other NIST CPRT data. Other discussed catalogs (ISO) can use their own ns. Catering the allowed values to ONLY 800-53 (see 76eec06) and not support organically other NIST data sets in OSCAL is not strategically sound, and defeats the OSCAL pledge to our community.

[iMichaela]

@david-waltermire-nist - BTY - I thought of description and definition as well but concluded it is not a better match than overview, since they are not reflecting an implementable requirement like a CSF function.

[aj-stein-nist]

@aj-stein-nist The catalog you are listing in not the one NIST is creating and plans to make available from the CPRT website.

So to better understand this issue and refine it, can we confirm it is the one you sent via email for debugging/troubleshooting pairing we had last week? Is it ok we publish relevant snippets to understand the request and be certain of the proposed changes given feedback from others? Thanks.

[iMichaela]

@aj-stein-nist The catalog you are listing in not the one NIST is creating and plans to make available from the CPRT website.

So to better understand this issue and refine it, can we confirm it is the one you sent via email for debugging/troubleshooting pairing we had last week? Is it ok we publish relevant snippets to understand the request and be certain of the proposed changes given feedback from others? Thanks.

@aj-stein-nist -- Sure, we can post any snipper necessary. There is no secret. The latest draft is a little more polished, that is all. And I already provided snippets above. The group/part/@name="statement" is line 3, below
and the `control/part/part@name="example" is line 16.

1 <group class="function" id="GV">
2      <title>GOVERN</title>
3      <part name="statement" id="GV_stmt">
4         <p>Establish and monitor the organization's cybersecurity risk management strategy, expectations, and policy</p>
5      </part>
6      <control class="category" id="GV.OC">
7         <title>Organizational Context</title>
8         <part name="statement" id="GV.OC_stmt">
9            <p>The circumstances - mission, stakeholder expectations, and legal, regulatory, and contractual requirements - surrounding the organization's cybersecurity risk management decisions are understood (formerly ID.BE)</p>
10         </part>
11         <control class="subcategory" id="GV.OC-01">
12            <title>GV.OC-01</title>
13            <part name="statement" id="GV.OC-01_stmt">
14               <p>The organizational mission is understood and informs cybersecurity risk management (formerly ID.BE-02, ID.BE-03)</p>
15            </part>
16            <part name="example" id="GV.OC-01.1">
17               <p>Share the organization's mission (e.g., through vision and mission statements, marketing, and service strategies) to provide a basis for identifying risks that may impede that mission</p>
18            </part>
19         </control>

[Arminta-Jenkins-NIST]

On 10/19 Triage Meeting: Remove allowed values or require the use of namespace for their own values.
The best possible option is that the CSF team to use namespace as fast tracking this change isn't the best option.

[iMichaela]

On 10/19 Triage Meeting: Remove allowed values or require the use of namespace for their own values. The best possible option is that the CSF team to use namespace as fast tracking this change isn't the best option.

@Arminta-Jenkins-NIST - CSF namespace included in core OSCAL like the RMF namespace is not something we should encourage. Without a registry, the information under a new namespace is not useful for a GRC tool. The proposed change in the PR #1952 is useful to other data sets and makes core OSCAL easier to use. If allowing other values is something preferred (as the constraints were written until 10 months ago, then we can do that too. I personally believe the PR #1952 is a much better compromise (not only 800-53 constraints but not open to the entire universe either). Nobody is fast tracking any change! Unless there is a logical explanation and a reasonable justification for push back, the issue and its PR should be included in the sprint, and reviewed by the team and the interested community members as part of the normal track.

[david-waltermire]

I provided a logical explanation for why adding statement is not a good idea above and more comments in #1952.

As a community member, looking at this from a FedRAMP perspective, I don't believe PR #1952 is ready. IMHO, alternative approaches should to be considered.

According to @Arminta-Jenkins-NIST it looks like others on the NIST OSCAL team have suggested using a namespace approach. IMHO, this is a great way to experiment with a way forward, without committing to a more permanent change.