NIST and FedRAMP, and others do not have a shared understanding core OSCAL, RMF, and FedRAMP constraints

[aj-stein-gsa]

Risk Summary

As it pertains to #908, currently NIST, FedRAMP, and community stakeholders have significantly advanced the customization and extension mechanism in OSCAL model with props and implying ownership of a custom data element. Over the last few years, we have advanced to to the degree that we can build extensible rules around them with the Metaschema-based notion of individual constraints, grouped together as constraint sets. As it stands, there are notionally at least three layers of implicit and explicit types of implied ownership, with a possible fourth on the way.

1. The default "core" data model requirements belonging to the maintainers of the core OSCAL models (NIST)
2. Requirements that overlap or distinct from core requirements that pertains to OSCAL modeling the NIST SP 800-37 Risk Management Framework and SP 800-53A and 800-53B controls for it; NIST coincidentally owns extension values and custom data requirements separate of core OSCAL
3. The FedRAMP requirements that are distinct from core OSCAL and RMF requirements, but derive from 1 and 2. These are owned by FedRAMP's staff.
4. Notionally, there may be separate custom data elements and constraints for the Cybersecurity Framework, either versions 1.1 or 2.0. NIST coincidentally would own such an extension namespace. They have not intentionally made use of it, but see challenges around 1 and 2 with relaxing constraints because of CSF in the catalog model, such as Catalog constraint relax for CSF Data usnistgov/OSCAL#1949.

At this time there, is no clear sense of how an implicit or explicit owner of constraints can manage and disseminate constraints in a way that is flexible for the community. In particular, there are some constraints that may sit between categories 1, 2, and 3 above. FedRAMP must ascertain how to work with NIST to manage such constraints and shifting ownership in either direction, with usnistgov/OSCAL#2059 as such an example.

Risk Mitigation Strategy

Strategy: Accept

At this time, the FedRAMP Automation Team is accepting this risk until achieving key milestones in constraint development and goals in the Digital Authorization Pilot before revisiting a different mitigation strategy.