usnistgov / OSCAL-DEFINE

Develop Enhancements, Future Implementations and New Education
Other
12 stars 6 forks source link

Spiral: Change Request creation for a qualifier assembly/tag in mapping. #27

Open Compton-US opened 1 year ago

Compton-US commented 1 year ago

Problem Statement

Belongs to https://github.com/usnistgov/OSCAL-DEFINE/issues/18

Prepare a feature request to add a qualifier assembly/tag as a part of the map assembly to describe requirements, incompatibilities and gaps that are identified between a target and source.

Compton-US commented 1 year ago

@nbg84 Spiral 2 of the mapping effort - Let's work on creating a change request for a qualifier assembly. We will initiate the document here, get details in it, then open the ticket in the OSCAL repo.

Compton-US commented 11 months ago

Screenshot 2023-08-04 at 3 42 26 PM

Compton-US commented 11 months ago

Screenshot 2023-08-04 at 3 43 03 PM

Compton-US commented 11 months ago

Very, very rough draft. What is needed at the moment is input on allowed values and terms used. Also input on cardinality.

Compton-US commented 11 months ago

Next week I will work on some examples using this assembly.

Compton-US commented 11 months ago

https://github.com/usnistgov/OSCAL/tree/compton-working-qualifier

iMichaela commented 11 months ago

Screenshot 2023-08-04 at 3 43 03 PM

The allowed values for predicate should probably be "be locally defined, or one of the following", since has-requirement and has-incompatibility might not provide enough coverage for all scenarios. has-requirement could be a parameter that might invalidate the relationship when set. How will such scenario best note the parameter's value assumed for the relationship.

The allowed values for the category should not be limited to listed values without having enough examples that demonstrate those values are sufficient. Also blocked value used to identify a mapping is blocked (not possible) is unclear when is applicable. The model allows to capture the non-mapped controls in the source and target gaps. Maybe an example illustrating a scenario when the is a blocked relation would help clarify the vision.

The category is envision to capture the resolvable nature of the relation. If renamed to resolvability , currently allowed values would make more sense:

 restricted 
addressable 
blocked 

I suggest defining them as:

restrictive 
addressable 

A property category could be used to define which aspect of the source, target or both is the predicate applicable to: requirement, parameter, objective, assessment method, evidence. Allowing to capture in the qualifier evidence discrepancies when such evidence is mentioned in the catalog of controls would address issue #30