Check system's operational date in SSP

[aj-stein-gsa]

Constraint Task

As a digital package author, in order to know my package meets FedRAMP requirements regarding system information and not get a passback, I want to know that I properly defined the fully operational date in a correct way.

Intended Outcome

Goal

A FedRAMP SSP MUST have a date it is fully operational.

Syntax

• A matches constraint can check the /system-security-plan/system-characteristics/prop[@ns="https://fedramp.gov/ns/oscal" and @name="fully-operational-date"]/@value conforms to the date-with-timezone type for prop. If not, it is @level="ERROR"
• A expect constraint can check the /system-security-plan/system-characteristics/prop[@ns="https://fedramp.gov/ns/oscal" and @name="fully-operational-date"]/@value can check it is <= current-date(). (NOTE: If oscal-cli 2.3.0 is not released before this PR is merged and our infrastructure updated, please submit the PR and mark blocked with a NOTE; a pre-release will be provided by technical leads when requested by developer who picks up this task.)

VALID:

<system-security-plan>
  <system-characteristics>
    <prop ns="https://fedramp.gov/ns/oscal" name="fully-operational-date" value="2023-01-01+00:00"/>
  </system-characteristics>
</system-security-plan>

INVALID:

<system-security-plan>
  <system-characteristics>
    <prop ns="https://fedramp.gov/ns/oscal" name="fully-operational-date" value="2023"/> <!-- Just a year not a full date -->
  </system-characteristics>
</system-security-plan>

<system-security-plan>
  <system-characteristics>
    <prop ns="https://fedramp.gov/ns/oscal" name="fully-operational-date" value="2023-01-01"/> <!-- observe no timezone -->
  </system-characteristics>
</system-security-plan>

<system-security-plan>
  <system-characteristics>
    <!-- no prop whatsoever -->
  </system-characteristics>
</system-security-plan>

Syntax Type

This is optional core OSCAL syntax.

Allowed Values

There are no relevant allowed values.

Metapath(s) to Content

/system-security-plan/system-characteristics/prop[@ns="https://fedramp.gov/ns/oscal" and @name="fully-operational-date"]
/system-security-plan/system-characteristics/prop[@ns="https://fedramp.gov/ns/oscal" and @name="fully-operational-date"]/@value

Purpose of the OSCAL Content

Check the operational date of a SSP, if there is no date or it is not valid, a reviewer cannot review the package and a passback must occur.

Dependencies

• New release of oscal-cli

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

Part of #804 epic

[aj-stein-gsa]

@brian-ruf, just to confirm, there is no requirement around fully-operational-date and staleness. It can be yesterday or ten years ago, as long as it is not in the future? I have found no contradicting documents, but want to confirm re syntax guidance other developers in the group said were helpful.

[brian-ruf]

The requirement is relative to assessment date in the SAR. It better have been operational at the time of assessment. There is no freshness of operational date relative to this data point.

The only freshness requirement I know of is for assessment data. We'll need to circle back to this requirement when we get to SAR checks.

[aj-stein-gsa]

The only freshness requirement I know of is for assessment data. We'll need to circle back to this requirement when we get to SAR checks.

Ackwnowledged and this is why the path on the constraint is tighter and not all artifacts (or really the same prop).

We feel this is good to go? I would like to bump this one to the top of the constraint and dev work queue. 😄

[Rene2mt]

Note - for unit testing, the ssp-all-valid.xml was updated. @brian-ruf is in parallel holistically updating the documentation example SSP (aka formerly ssp template).