Security Controls - SSP has all parameters

[Rene2mt]

Constraint Task

As a consumer of FedRAMP automated completeness checks, I want to make sure that every control parameter in the FedRAMP baseline is addressed.

Intended Outcome

• Every parameter in the FedRAMP baseline is addressed in the SSP

Syntax Type

This is a mix of required, optional, and/or extended syntax.

Allowed Values

There are no relevant allowed values.

Metapath(s) to Content

- EXPECT
- target='./param'
- count(/system-security-plan/control-implementation/implemented-requirement/set-parameter[@param-id=./@id]/value) = 1
 - NOTE: I would prefer to also ensure this parameter is correctly aligned under the correct implemented requirement, but am unsure how to reflect that in metaschema. In other words, it would be better if this looked something like this: count(/system-security-plan/control-implementation/implemented-requirement[@control-id='ac-1']/set-parameter[@param-id='ac-01_odp.01']/value) = 1
- ERROR: A parameter is defined for the [Control Label] in the [//metaschema/title] baseline, but its value is not set in the SSP.

Purpose of the OSCAL Content

This validation check helps reviewers ensure that submitted SSPs address every control parameter in the FedRAMP baseline.

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

See #810 (comment) for additional details.

[aj-stein-gsa]

Re discussion today earlier during the contstraints backlog meeting, I had an opportunity to talk to @david-waltermire about the choice between the following.

1. Using the "classic," less-granular control parameters from 800-53 that end up in the 800-53B baselines and FedRAMP baselines that predate the publication of 800-53A and specific organizationally defined parameters (ODPs, infixed thusly in OSCAL with odp) released with assessment criteria.
2. Using the more granular 800-53A ODP parameters that are cross-mapped into 1 with the prop[@name="aggregates"] annotation.

Note: to those observing our issues publicly: FedRAMP baselines select and tailor both variations in our baselines, even if they are redundant. Below is a decision on how we will process them in SSPs in published documentation and constraints to match.

We are good to move forward with this work to filter on 2 in SSP parameter processing, and drop 1 from processing in the requirements for this constraint in a SSP, even if we continue to provide them in the FedRAMP baselines as a convenience.

I will coordinate adding document updates to SRTM in the long-term to align these changes, if necessary, in an internal FedRAMP backlog.

/cc @brian-ruf @Rene2mt

[wandmagic]

do we want to forbid agregated controls in the SSP much like extraneous implimented requirements constraint?