|Assessment Plan Schema||Assessment Plan Converters|
|XML Schema||JSON to XML Converter|
(How do I use this?)
|JSON Schema||XML to JSON Converter|
(How do I use this?)
The OSCAL assessment plan model represents the information contained within an assessment plan, and is typically used by anyone planning to perform an assessment or continuous monitoring activities on an information system to determine the degree to which that system complies with a given control baseline used by the system.
It was designed to use identical syntax to the assessment results model, for overlapping assemblies (Objectives, Assessment Subject, Assets, and Assessment Activities).
Authors and Consumers
The OSCAL assessment plan model is useful to the following authors and consumers.
Assessment Plan Authors
Assessors develop the assessment plan to clearly identify the intended scope, target, and activities for an assessment.
Assessment Plan Consumers
Assessment practitioners consume an assessment plan as they execute the assessment to ensure the intended scope, target, and activities are being honored.
Authorizing Officials consume an assessment plan in the adjudication of a system as part of approving an authorization to operate.
Continuous assessment implementers consume an assessment plan when establishing automated continuous assessment mechanisms.
An OSCAL profile is organized as follows:
- Metadata: Metadata syntax is identical and required in all OSCAL models. It includes information such as the document's title, publication version, publication date, and OSCAL version. Metadata is also used to define roles, parties (people, teams and organizations), and locations.
- Import SSP: Identifies the OSCAL-based SSP of the system being assessed. Several pieces of information about a system that normally appear in an assessment plan are now referenced via this import statement, eliminating the need to duplicate and maintain the same information in multiple places.
- Local Definitions: Normally other aspects of the assessment plan point to content in the linked SSP. When the AP must reference information that is missing from linked SSP, assessors define it here instead.
- Terms and Conditions: Identifies the rules of engagement, disclosures, limitation of liability statements, assumption statements, methodology, and other explanatory content as needed.
- Reviewed Controls: Identifies the controls to be included within the scope of the assessment, as well as the control objectives and assessment methods.
- Assessment Subject: Identifies the elements of the system that are in scope for the assessment, including locations, components, inventory items, and users.
- Assessment Assets: Identifies the assessor's assets used to perform the assessment, including the teams, tools, and rules of engagement.
- Assessment Action: Describes the manual and automated activities that are intended to be as part of the assessment. This includes the steps required to perform the action.
- Task: Identifies the intended schedule of milestones and assessment actions.
- Back Matter: Back matter syntax is identical in all OSCAL models. It is used for attachments, citations, and embedded content such as graphics.
The OSCAL assessment plan model defines the information contained within an assessment plan.
This model is typically used by anyone planning to perform an assessment or continuous monitoring activities on a system to determine the degree to which that system complies with one or more frameworks.
This model allows an assessor to express all details associated with a classic "snapshot in time" assessment, including the scope of the assessment, schedule, intended activities, and the rules of engagement. It also allows organizations to specify clear continuous monitoring parameters, such as frequency and method of monitoring, as well as the roles responsible monitoring various aspects of the system.
An OSCAL assessment plan is always defined in the context of a specific system, and must always be associated with an OSCAL System Security Plan (SSP).
The current version of this model was created based on the information requirements of a FedRAMP Security Assessment Plan, and was expanded to include continuous monitoring capabilities. It was designed to use syntax identical to the assessment results model, for overlapping assemblies (Objectives, Assessment Subject, Assets, and Assessment Activities).
The figure below expresses represents the portion of the OSCAL stack as it relates to an OSCAL Assessment Plan.
Important Note to Developers
Every time the content of an OSCAL file changes, the following must also change:
- A new UUID value must be generated and assigned to the root element's
last-modifiedfield in metadata must be assigned with the date and time at the moment the file is saved with the modified content.
These are two mechanisms by which tools can quickly "know" if a file has changed since it was last encountered. This document level UUID is the only UUID in OSCAL associated with version control.
When converting between formats, such as XML to JSON, these values should remain the same. This enables tools to know the content within the two formats is equivalent.