One component control definition to implement multiple standards controls?

[riskpeep]

In component.yaml, we define controls. Each control has a 'standard_key' and a 'control_key' and (among other things) a 'narrative' section.

Is it possible to have one component control definition to implement multiple standards' controls so that one narrative section could be used to satisfy the control requirements for multiple standards? Or one control that implements multiple required controls w/in one standard.

I've tried putting in multiple 'standard_key' and 'control_key' sections and that doesn't appear to work, I only get one section in the output document.

[shawndwells]

Have been playing with this too. For example to add PCI-DSS mappings to NIST 800-53 control responses... don't want to create entirely separate bodies of work for each standard.

Some example code of having PCI-DSS and NIST 800-53 in the same response:
https://github.com/opencontrol/schemas/blob/master/examples/component_v3.1.0.yaml

That approach still requires copy/pasting responses to map against multiple standards. Have been debating about restructuring a new component schema to something like this:

(answer for PCI-DSS control 1.1, but also maps answer to NIST 800-53 AU-5 and CM-6)

  - control_key: 1.1
    implementation_status: partial
    parameters:
      - key: "a"
        text: "Parameter A for 1.1"
      - key: "b"
        text: "Parameter B for 1.1"
    narrative:
      - key: "a"
        text: "Justification in narrative form A for 1.1"
      - key: "b"
        text: "Justification in narrative form B for 1.1"
    standard_key: PCI-DSS-MAY-2015
    standard_mappings:
      - control: AU-5
      - control: CM-6

[riskpeep]

I think that could work as a minimal change to the existing schema. I think that you'd need to have a standard_key in with the mappings though. Something more like this:

- control_key: 1.1
  implementation_status: partial
  parameters:
    - key: "a"
      text: "Parameter A for 1.1"
    - key: "b"
      text: "Parameter B for 1.1"
  narrative:
    - key: "a"
      text: "Justification in narrative form A for 1.1"
    - key: "b"
      text: "Justification in narrative form B for 1.1"
  standard_key: PCI-DSS-MAY-2015
  standard_mappings:
      - key: NIST-800-53
        control: AU-5
        control: CM-6

IMO, you probably need to go farther to have this work the way it should though. That would mean putting all of the mappings into a mapping array and move the parameters in there as well. Unless I misunderstand parameters (totally possible), they are meant to indicate values for 'selectable' items in the standard. Since different standard texts will have different parameters, you would want them to go w/ the standard mapping. If you did that, you'd end up w/ something more like this:

- narrative:
  - key: "a"
    text: "Justification in narrative form A for 1.1"
  - key: "b"
    text: "Justification in narrative form B for 1.1"
  implementation_status: partial
  standard_mappings:
    - standard: PCI-DSS-MAY-2015
      control: 1.1
      parameters:
          - key: "a"
             text: "Parameter A for 1.1"
          - key: "b"
             text: "Parameter B for 1.1"
    - standard: NIST-800-53
      control: AU-5
      control: CM-6

All of that is a pretty big shift though.

Control sharing starts to break down if you look at the keys in the narrative though. I don't have an idea for that yet other than to suggest avoiding modeling the control description too closely to the standard text and not use key references.

[its-a-lisa]

Is this still open or overcome by events?