As a user, I want to know what inherited controls are still my responsibility

[afeld]

There was some discussion in the 18F Slack, which boils down to the following example:

Suppose you are building System X on top of cloud.gov. Let's take an arbitrary control family, like contingency planning. cloud.gov may have its own contingency plan, but that doesn't mean that System X does. We need a way to indicate what controls (or control family? or control implementation?) family can be inherited and thus take care of the requirement for System X, and which System X is required to fulfill on top of cloud.gov.

@cmc333333 ran into this problem when trying to do gap analysis, almost immediately after setting up an opencontrol.yml in 18F/epa-notice#424:

that leaves only

Number of missing controls: 1
NIST-800-53@SC-12 (1)

When diffing with LATO. does that seem right?

[mogul]

Going to revisit this once the SSP and CIS/CRM are solid.

[afeld]

@mogul This issue is actually about the schema supporting the ability to mark controls as inheritable or not. That being said, now that I understand controls better, it seems that this is what control originations are for. The downside, however, is that the control_origins are arbitrary strings, rather than something more structured 😕

[mogul]

Sorry, totally missed which repository this was in and just looked at the summary. :)

[afeld]

Also worth noting that the possible values for control_origins can vary from control to control, and (I believe) from certification to certification. It's probably the case that there is a fixed set per certification (or standard?), but I don't know enough here.

/cc @brittag @JJediny

[JJediny]

For overall reusability of an SSP/FEDRAMP package it would seem cleanest to have all Customer Responsibilities of a given system as its own certification in OpenControl. As that allows multiple SaaS to target/tailor their IaaS/PaaS semi-inherited control write ups. Using control_orgins would seem to co-mingle SaaS/IaaS/PaaS and make it overcomplicated for what should be a one to one response.

Within the SaaS component.yaml they would then just have to respond to their IaaS-PaaS CRM certification with their component.yml.

|  NIST-800-53  | <--- component.yml *IaaS-PaaS using certification_key: NIST-800-53
| IaaS-PaaS-CRM | <--- component.yml *SaaS using certification_key: IaaS-PaaS-CRM

By both using standard NIST 800 keys means they could be rendered together into the same sections of the document output.

[git-ingham]

I was asking nearly the same thing over here:
opencontrol/discuss#59
I notice that the last comment was in 2016. Has nothing happened in this area since then?