Assessment Plan Templates (#2)

[brian-comply0]

User Story

As an Agency CIO, I need to be able to assess many industry partners using the exact same assessment approach, and before system details are available, and where the industry partners typically do not have any form of SSP (OSCAL or otherwise).

Historically, the Agency sends out the same data gathering requests/questions to all industry partners, and accepts/scores their responses.

The requirements can be modeled as an OSCAL catalog. The questions can be modeled as OSCAL assessment-plan interviews and the data gathering can be modeled as AP inspections.

The questionnaire typically collects very little system information. Typically system name, description, owning organization, and points of contact. Even if we wanted to model this information in an SSP it wouldn't meet an OSCAL SSP's minimum enforced data requirements, and wouldn't be known until after the AP was generated and published.

In this case, the AP would need to connect directly to a profile/catalog and would typically not have an SSP to import at any point in the process, even though an AR would be generated individually for each system.

While I've heard this most recently from an Agency CIO and with explicit reference to OSCAL, I am aware of commercial entities using a very similar approach to perform due diligence on new business partners were systems will be connected. Again with the assessment questions being formulated the same for all industry partners - before any one specific system is known.

Goals

• Enable an AP to be created and linked directly to a profile/catalog without the context of an OSCAL SSP.
• Enable an AR to be created in the context of an above AR, but without the context of an OSCAL SSP.
• Enable a reduced set of system information to be captured as part of performing an assessment instead of it being required to be know ahead of the assessment.

Dependencies

None immediately identified.

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.

[iMichaela]

@brian-easyd - Thank you for documenting the use case. To me, this use case is a clear example of OSCAL research topic, and subject of community sponsorship/endorsement at the proposal level before NIST team is able to prioritize it. We will have an OSCAL-DEFINE meeting on Feb 16, 2023 at 11:00 AM ET and we will introduce the OSCAL research process to interested parties. The OSCAL DEFINE Meetings will take place on the third Thursday of every month to discuss the research and educational pursuits of OSCAL using an iterative and collaborative approach with the community. The meeting page has meeting information as well as slides and notes from past sessions. A calendar invitation will be sent out today got the first meeting in the series.

[sunstonesecure-robert]

I think the idea is to get away from generic surveys and have instead a system-specific AP and AR which has specific assessment tests for a specific SSP/system. I would rather solve this user's story (pain) by generating the discovery questions from the catalog so that the answers can be fed into an SSP template and then use that completed SSP to drive the AP. Admittedly, it's a nomenclature sleight of hand...during the collection of the required info for a complete SSP, it's not an "assessment", it's "discovery" of basic system facts and control implementations. I can't "assess" something by definition of this pedantry if I don't know what to test, examine, or interview about the system, ie the SSP.

But overall I agree with the concept of using the catalog to drive what I'll call pre-AP discovery.