For consideration - I would like to suggest that OSCAL model and documentation could evidence some functional capabilities that our teams could run to extract or consist data from the model.
As an example, assuming that OSCAL has multiple data representations (JSON, XML) for NIST SP800-53 catalog model and data, and users could build Profile views of that data from combined catalogs, one ideal function that should be available is "CheckIntegrity()"as a Profile/Catalog API that could offer base validation ( maybe to be part of the standard definition)
The idea is that the initial "checkIntegrity()" function may be syntax-oriented, or even allow higher-level functions to detect semantical (user-defined) checks that are called as part of the integrity check superclass.
The proposal of functions would be beneficial to enhance the model usage, and also test different use cases that models were not originally designed, but it should allow such enhancements at some point.
Candidate functions could include:
AddCatalog( fields ): This should be able to build a catalog object using base information. Other CRUD functions that relate to Catalog, Profile, SSP, Assessment may be defined to instantiate such objects.
DefineContext() : This could be a profiling functionality to "extract" concepts that are available in the Catalog, so that it could help determining the minimum list of relevant items (e.g., keyword, labels, tags)
showLineage(): This function should demonstrate the dependencies that a given item came from, As an example, a profile object would be able to show the catalog lineages, an SSP object would be able to show profile and catalog lineage, Assessment object would show lineage for all previous layers if needed.
CrossWalk(): A set of functions that can show when a given requirement is linked to other catalog/profile/assessment data and details.
checkIntegrity(): as the first syntax-check function, that can be expanded to all objects, so that if someone creates a representation of the model, this function would be the first one to be called as enforced rule or optional function that users can do before using the data for correlation.
defineDataMapping(): Enables user-defined tags/labels that can be linked to catalog/profile items to explain why they are applicable/relevant to assessment and other higher level functions.
For consideration - I would like to suggest that OSCAL model and documentation could evidence some functional capabilities that our teams could run to extract or consist data from the model.
As an example, assuming that OSCAL has multiple data representations (JSON, XML) for NIST SP800-53 catalog model and data, and users could build Profile views of that data from combined catalogs, one ideal function that should be available is "CheckIntegrity()"as a Profile/Catalog API that could offer base validation ( maybe to be part of the standard definition)
The idea is that the initial "checkIntegrity()" function may be syntax-oriented, or even allow higher-level functions to detect semantical (user-defined) checks that are called as part of the integrity check superclass.
The proposal of functions would be beneficial to enhance the model usage, and also test different use cases that models were not originally designed, but it should allow such enhancements at some point.
Candidate functions could include: