Additionally, there is no assurance that SSP authors have access to linked external data, so these references cannot be validated. These external references do not provide enough contextual information to know the format and/or structure of data in the referenced resource. This could include cases where an OSCAL SSP component has a reference to a component in a component definition. If the component definition is resolvable, this scenario supports enforcement of referential integrity between the SSP and components in the component definition.įinally, OSCAL supports references to (non-OSCAL) external resources through use of the link field. Links to component definitions (CDEFs) provide lineage from an SSP's implemented system component back to a relevant source of transferred content.Some of the information in the leveraged SSP may be referenced if the leveraged SSP is also in OSCAL format. If the leveraging SSP author has access to the leveraged system SSP, this scenario supports validation of constraints on the leveraging SSP to enforce the referential integrity of cross-references to leveraged system SSP details. In this scenario an OSCAL SSP has leveraged authorization(s), which reference a leveraged SSP. Use of links to SSP leveraged authorizations, established through the use of the leveraged-authorization field, present another cross-instance scoped identifier scenario.In this case, the controls and parameters referenced from the SSP can be verified to exist in the resolved profile. This scenario supports validation and enforcement of constraints, provided the imported OSCAL profile or resolved profile is accessible. OSCAL uses the import-profile field to reference an OSCAL profile or catalog representing the system's control baseline.
The following are examples of cross-instance references in an OSCAL SSP. Cross InstanceĪ cross-instance scoped identifier reference is used to reference information imported from another OSCAL instance. This scenario supports enforcement of constraints since all of the information required to check the validity of the reference is readily available in the SSP. InstanceĪn instance scoped identifier reference is used to reference information in the same OSCAL SSP instance. The following summarizes the scenarios where an OSCAL SSP may have references to other content. Identifier ReferencesĪn OSCAL SSP may contain references to information that is instance scoped (e.g., in the SSP model), cross-instance scoped (e.g., in a referenced profile, catalog, or component definition model), or external (e.g., references to non-OSCAL resources). This enables tools to know the content within the two formats is equivalent. When converting between formats, such as XML to JSON, these values should remain the same. This document level UUID is the only UUID in OSCAL associated with version control. These are two mechanisms by which tools can quickly "know" if a file has changed since it was last encountered. The last-modified field in metadata must be assigned with the date and time at the moment the file is saved with the modified content.A new UUID value must be generated and assigned to the root element's uuid.Authors and Consumers SSP AuthorsĮvery time the content of an OSCAL file changes, the following must also change: Control satisfaction can be defined for the system as a whole or for individual implemented components. In terms of control satisfaction, it models control parameter values, responsible roles, implementation status, control origination, and a description of control satisfaction at a level of granularity down to a specific control statement. At a more detailed level, this includes the system's authorization boundary, information types and categorization, inventory, and attachments.
SSP EXCEL OTOMATIS FULL
The OSCAL SSP model enables full modeling of highly granular SSP content, including points of contact, system characteristics, and control satisfaction descriptions. The SSP model is part of the OSCAL implementation layer. The OSCAL system security plan (SSP) model represents a description of the control implementation of an information system. OSCAL Implementation Layer: System Security Plan (SSP) Model SSP Schema
0 kommentar(er)
