How to represent Group Ids starting with numeric value (E.g. NIST SP 800-171-R2)

[SParekh]

As per latest Schema changes, Group Id has been restricted by Pattern, that requires it to have starting characters to be letters (A-Za-z)

OSCAL/json/schema/oscal_catalog_schema.json

Line 51 in 81f0315

"pattern" : "^[_A-Za-z\\u00C0-\\u00D6\\u00D8-\\u00F6\\u00F8-\\u02FF\\u0370-\\u037D\\u037F-\\u1FFF\\u200C-\\u200D\\u2070-\\u218F\\u2C00-\\u2FEF\\u3001-\\uD7FF\\uF900-\\uFDCF\\uFDF0-\\uFFFD][_A-Za-z\\u00C0-\\u00D6\\u00D8-\\u00F6\\u00F8-\\u02FF\\u0370-\\u037D\\u037F-\\u1FFF\\u200C-\\u200D\\u2070-\\u218F\\u2C00-\\u2FEF\\u3001-\\uD7FF\\uF900-\\uFDCF\\uFDF0-\\uFFFD\\-\\.0-9\\u00B7\\u0300-\\u036F\\u203F-\\u2040]*$" },

However, for Frameworks like NIST SP 800-171-R2, the 14 Group and corresponding Ids (Document term is "families") does not match the pattern

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r2.pdf

Though the above 14 families look similar to "Groups" in NIST 800-53, these 14 are referenced as "Families" in the NIST SP 800-171r2 documentation and have different Ids (Numeric). Additionally, it does not map exactly 1:1 with 800-53 Groups
E.g. "3.12 Security Assessment" in 800-171 though matches the title of "CA" in 800-53 , it includes control mapping from both CA and PL

Question:
As OSCAL schema is expected to be scalable across different compliance requirements, is the assumption accurate that Group.Id will always start with letters ?

[wendellpiez]

@SParekh so the lexical requirement around the nominal 'ID' type are derived from the requirements for the XML ID type, which must conform to the Name production, which forbids spaces, most punctuation ... and initial numerals.

https://www.w3.org/TR/REC-xml/#id

Since in OSCAL the 'id' property is intended as a machine-readable token and not part of the "legible" text -- and you are free to devise any ID you like (whether or not embedding a numeration) -- we think this restriction is worth the cost, since what we get in return on the XML side is considerable leverage. (XML tools come with specialized capabilities and functions relating to IDs, which we can use and not rebuild around a different ID syntax.) Unfortunately this does mean that there is a cost in expressiveness on the JSON side, which is paid for only on the XML side. This is part of the compromise we undertake to support both.

Note that the "ID" used commonly as a label -- such as "AC(10)" in SP 800-53 -- is a different thing and should be captured in a different data point (probably a prop).

Short version is that if you make your ID syntax look like fam1 and not 1fam, you will be fine. (Or even give them 'semantic' IDs, such as physical_protection. I am not sure their numeration is canonical in quite the same way as it is in SP 800-53.)

[iMichaela]

@SParekh - There are two fundamental aspects here: 1) a strictly technical aspect related to the pattern and 2) a more important one, related to the use of OSCAL Catalog model to represent the SP 800-171r2 requirements.

1. there are important reasons for the pattern that restricts the IDs - we need to maintain consistency between XML , JSON and YAML. Nothing prevents you or anybody else, from making the group ID r3.1 and all requirements after that r3.1.1. You can see the catalog tutorial that does exactly the same thing to the control form ISO 27002 we picked for this sample.
   You can use the prop with the name="label" to preserve the numeric value as is in the document, but have the ID start with a letter.

<group id="s1.1">
    <title>Internal Organization</title>
    <prop name="label">1.1</prop>
    <part id="s1.1_smt" name="objective">
      <p>To establish a management framework to initiate and control the implementation and
        operation of information security within the organization.</p>
    </part>
    <!-- controls go here -->
  </group>
</group>

2. The SP 800-171r2 is not a catalog of controls but rather a collection of requirements mapped to security controls in a many-to-many pattern. We planned for OSCAL 1.1.0 the development of an OSCAL model that would support a mapping between standards and/or requirements. Catalog model is mot considered by us suitable for the representation of 800-171r2, NIST's CSF, or other similar guidelines because it will not serve well the security automation, as it will be difficult if not impossible to properly, automatically track and adjudicate the control implementation's and assessment's findings onto the 800-171r2 requirements. The many-to-many relation and support for traceability and aggregation of findings are not modeled in the OSCAL Catalog model. We acknowledge the community's need of such model and scheduled its development as part of OSCAL 1.1.0.

[wendellpiez]

@SParekh I should add to the above, that we are also moving away from XML-based restrictions in general (especially ones that seem arbitrary) and the ID format might arguably be on this list. In other words, we are open to loosening the rule in a later version of OSCAL if we learn that the burden is onerous or the advantages (described above) are negligible.

Since it is a backward-incompatible change it would have to be a major revision i.e. OSCAL 2.0.

Thanks for the question!