trestle rules extension

[degenaro]

Issue description / feature objectives

1. trestle rules must support multiple checks per rule-id for a validation component, and rule_ids need not be unique across components (validation and non-validation)
   a) for non-validation component, the tuple that uniquely identifies rule is: component-id + rule-id
   b) for validation component
   i) add a new column called "target-component" that identifies component for which rule is being checked
   ii) the tuples that uniquely identifies the check: component-id + target-component-id + rule-id + check-id

   Note: "target-component is optional, but key must still be unique when target component is null.
   

---

2. support multiple profiles for a component
   • similar to how multiple parameters are supported by adding parameter_N columns add multiple profiles by specifying
     a) Profile_Source_N
     b) Profile_Description_N
     c) Control_Id_List_N

For example: In the CIS benchmarks we have mappings from benchmark rules to both CIS controls v8 and v7. To fully capture this in Comp def. we need to support mappings to both v7 and v8.

For each triplet, there should be a corresponding control implementation stanza in the json. For example, prof-A triplet and prof-B triplet would result in two ctl-impl stanzas in the OSCAL json.

The config file will support control checking for: warn, fail, off. "on" will be backwards compatible.

Caveats / Assumptions

Completion Criteria

[degenaro]

Be sure documentation https://oscal-compass.github.io/compliance-trestle/tutorials/task.csv-to-oscal-cd/transformation/ is updated.