Support satisfying a control only if multiple other controls are satisfied

[yruss972]

Assuming a certification mapping alternate standards like this:

name: TSC
standards:
  TSC:
    CC6.1:
      mapping:
        MY-TSC:
          - CC6.1.1
          - CC6.1.2

This is interpreted so that any of the MY-TSC controls can satisfy the parent TSC control.

It would be cool if we could use a syntax like:

name: TSC
standards:
  TSC:
    CC6.1:
      mapping:
        MY-TSC:
          - [CC6.1.1, CC6.1.2]
          - CC6.1.3
          - CC6.1.4

to say we if we satisfy (CC6.1.1 AND CC6.1.2) OR CC6.1.3 OR CC6.1.4), then we satisfy CC6.1

I'm not sure if there are any accepted patterns for how to do this in the YAML world- might be nice to specify the operator ie:

name: TSC
standards:
  TSC:
    CC6.1:
      mapping:
        MY-TSC:
          - AND: [CC6.1.1, CC6.1.2]
          - OR: [CC6.1.3, CC6.1.4]
          - XOR: [CC6.1.0, CC6.1.1]

The AND would be very useful in rolling up controls which have been broken down. The XOR would be useful in alternate exclusive controls, ie. MFA vs Two man rule, etc.

[yruss972]

An additional thought- the AND mappings could be used to enhance the completion status report so that a component implementing a subset of the required controls would get a partial status vs complete, etc.

[jenglish]

Control mappings are a somewhat fuzzy concept. The introductory paragraphs in SP 800-171 Appendix D state that the mapping tables are for informational purposes only, and (paraphrasing) that mapped controls are not in strict correspondence with requirements. CMMC has similar language.

My current thinking is that ssptool should split the satisfies relation into two separate relations:

• a Component completely or partially satisfies a Control based on satisfies and implementation_status
• a Component is relevant to a Control if it satisfies any control to which the first is mapped
• the Completion report lists all relevant Components, for purposes of gap analysis and progress reports
• the final determination of whether a Control is satisfied is done by an auditor, perhaps based on verifications (which ssptool does not currently use).

[yruss972]

Firstly, thanks for all the hard work :) Regarding control mappings, I see multiple use cases:

1. The common use case which you mentioned- using various mappings between ISO, SOC, NIST, etc. I agree that this is just a starting point which is why I'm thinking that the 'AND' functionality would let an org fill in the gaps without having to start from scratch.
2. The example I gave above is really not mapping between two standards but mapping between two resolutions of the same standard which lets some systems provide more detailed answers than others and then roles them up for the report.
3. Similarly, I think mapping a very low-resolution standard like ASVS to a higher level standard should be very useful.

About the auditor's role and the split between relevant/satisfying, maybe another implementation status would be good, ie. in_review, proposed, or proposed complete, meaning the organization thinks it is sufficient, and then completed would only be used once the auditor accepts the proposals.

I see the verification keys as all the pieces of evidence to be provided to the auditor and I'm working to have those all automatically collected continuously using pipelines running on our opencontrol repos. I would definitely like to see them included.