Assessment Models: Timing and Expiration

[brian-ruf]

User Story:

In an effort to more fully support activities such as continuous assessment, the assessment plan and assessment results models must have the ability to support timing of collection and expiration of results.

The assessment plan model must enable a security practitioner to define a frequency of collection on a per-test basis. It may be necessary to modify the catalog and profile models to support testing frequency as an expansion of the assessment objective/methods modeling.

The assessment plan and assessment results models must also support the ability to assign an expiration date to the results. OSCAL should enable both an implicitly derived expiration date based on the frequency of collection above, and an explicitly defined expiry period. Regardless, individual results must have the ability to reflect the period of time within which the results are valid or trusted.

It is worth noting that the assessment results model already supports time-date stamps on each individual finding. This equates to a date of information collection, and may be used by tools to make decisions as to the "freshness" of the results information in a particular context.

Goals:

• Define clear OSCAL data requirements for frequency of testing at the individual test level.
• Define clear OSCAL data requirements for results expiration and/or freshness.
• Identify the models to update and plan the changes.
• Implement the changes.

Dependencies:

None.

Acceptance Criteria

• All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
• A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

[david-waltermire]

This issue has received no feedback since its creation. As a result I am pushing this to OSCAL 1.2.

[aj-stein-nist]

Given the questions around core requirements for this issue and existing comments and labels, I will align the status with "DEFINE Research Needed."

(Also I unassigned you off the issue @brian-ruf only because we are trying to make it a habit not to assign issues unless a team member is actively working on it, meaning the status is "In Progress," during the sprint. Thanks for opening and any work that has occurred since)