Defining Automated Assessment Parameters in OSCAL Component with Extension Fields

[ohsh6o]

Hello, I am back and decided to go public now that #524 and finally #857 is going to come up in this development team's sprint.

I participate in a working group and we want to evaluate the idea of embedding assessment data in a component using the TBD component model defined in #825 (so system owners and vendors can document their self-assessment procedure) and expose it to others in a structured way so that self-assessment and third-party assessments can reference them.

Specifically, we want to focus on how to align control parameters and align often (but not always) with parameter statements, and how to seed assessment of compliance capabilities with automated testing with tools that test concrete implementations. Many times, we will authorizing agencies (and technical advisory teams) to encode how this will work.

I have built an extension model schema to attempt this and focus on cross-referencing variables (inputs in their parlance) to reference the actual parameter or value or just reference them. The desired outcome: is InSpec will have a plugin built (this is alpha software) that will read a component (internal self assessment) or SAP (3rd party later assessment) to know to map certain key parameters to organizationally defined baselines.

I would love feedback on my extension modal and if this is a prudent way to do it.

Schema: https://gitlab.com/atarc/orion/-/tree/main/extensions
Component: https://gitlab.com/atarc/orion/-/blob/main/components/ubuntu_inspec_extensions.json
InSpec Plugin: https://github.com/tohch4/inspec-oscal/
InSpec Profile: https://github.com/mitre/canonical-ubuntu-16.04-lts-stig-baseline/