Check for control-origination in SSP

[aj-stein-gsa]

Constraint Task

As a maintainer of a digital authorization package, in order to ensure that the origin of controls is correctly defined, I would like to ensure the origin of the control implementation is properly defined.

Intended Outcome

Goal:

Define whether a control implementation is one of the following:

• Service Provider Corporate
• Service Provider System Specific
• Service Provider Hybrid (Corporate and System Specific)

Syntax:

Make an allowed-values constraint that allows the following values and no others (allow-other="no"):

            <enum value="sp-corporate">Service Provider (Corporate)</enum>
            <enum value="sp-system">Service Provider (System Specific)</enum>

Syntax Type

This is a FedRAMP constraint in the FedRAMP-specific namespace.

Allowed Values

There are no relevant allowed values.

Metapath(s) to Content

/system-security-plan/control-implmentation/implemented-requirement/prop[@name='control-origination'][@ns='http://fedramp.gov/ns/oscal']/@value

Purpose of the OSCAL Content

Determine proper control origination

Dependencies

No response

Acceptance Criteria

• [ ] All OSCAL adoption content affected by the change in this issue have been updated in accordance with the Documentation Standards.
  • [ ] Explanation is present and accurate
  • [ ] sample content is present and accurate
  • [ ] Metapath is present, accurate, and does not throw a syntax exception using oscal-cli metaschema metapath eval -e "expression".
• [ ] All constraints associated with the review task have been created
• [ ] The appropriate example OSCAL file is updated with content that demonstrates the FedRAMP-compliant OSCAL presentation.
• [ ] The constraint conforms to the FedRAMP Constraint Style Guide.
  • [ ] All automated and manual review items that identify non-conformance are addressed; or technical leads (David Waltermire; AJ Stein) have approved the PR and “override” the style guide requirement.
• [ ] Known good test content is created for unit testing.
• [ ] Known bad test content is created for unit testing.
• [ ] Unit testing is configured to run both known good and known bad test content examples.
• [ ] Passing and failing unit tests, and corresponding test vectors in the form of known valid and invalid OSCAL test files, are created or updated for each constraint.
• [ ] A Pull Request (PR) is submitted that fully addresses the goals section of the User Story in the issue.
• [ ] This issue is referenced in the PR.

Other information

No response

[aj-stein-gsa]

@brian-ruf I wanted to know if I can get a JIT analysis of this to know if it can go from backlog to ready, so a few questions for your consideration:

1. FedRAMP values (legacy variant) allowed a few values not in the Rev 5 templates and I cannot tell if that is from advancement in core models or my/others misunderstanding at one point it allowed: customer-configured; customer-provided; and inherited. That is abusing this implementation metadata to mean something?
2. Should the target stay at the control-implementation layer per #802 analysis or should we propose granularity here as well? It would seem that this is different, but similar, in consequences.

[brian-ruf]

@aj-stein-gsa these are valid for other than dash-one controls. They are not valid for dash-one controls.

Here is what is in the template for other-than-dash-one controls: Control Origination (check all that apply): ☐ Service Provider Corporate (sp-corporate) ☐ Service Provider System Specific (sp-system) ☐ Service Provider Hybrid (Corporate and System Specific) (in OSCAL both of the above are checked) ☐ Configured by Customer (Customer System Specific) (customer-configured) ☐ Provided by Customer (Customer System Specific) (customer-provided) ☐ Shared (Service Provider and Customer Responsibility) (in OSCAL provide two or more of the above) ☐ Inherited from pre-existing FedRAMP Authorization for [Click here to enter text], Date of Authorization (inherited)

There is a nuance to this in that FedRAMP requires each org must have their own policies. They cannot be inherited from an underlying provider, nor passed along to the customer. For this reason, the dash-one controls have a reduced list as follows: Control Origination (check all that apply): ☐ Service Provider Corporate (sp-corporate) ☐ Service Provider System Specific (sp-system) ☐ Service Provider Hybrid (Corporate and System Specific) (in OSCAL both of the above are checked)

Yes, I believe this could benefit from analysis similar to implementation-status as the two go hand-in-hand. We can often derive this information from the by-components if present, but not always.

[aj-stein-gsa]

OK thanks, we can noodle on this and bring up this constraint for work soon enough. I will workshop requirements in the issue, update them and ask for re-review so we can be happy with them and move it from Backlog to Ready to work.