The value of the href can be an internet resource, or a local reference using a fragment e.g. #fragment that points to a back-matter resource in the same document.
If a local reference using a fragment is used, this will be indicated by a fragment "#" followed by an identifier which references an identified resource in the document's back-matter or another object that is within the scope of the containing OSCAL document.
If an internet resource is used, the href value will be an absolute or relative URI pointing to the location of the referenced resource. A relative URI will be resolved relative to the location of the document containing the link.
This value may be one of:
+back-matter resource in this or an imported document (see linking to another OSCAL object).The value of the href can be an internet resource, or a local reference using a fragment e.g. #fragment that points to a back-matter resource in the same document.
If a local reference using a fragment is used, this will be indicated by a fragment "#" followed by an identifier which references an identified resource in the document's back-matter or another object that is within the scope of the containing OSCAL document.
If an internet resource is used, the href value will be an absolute or relative URI pointing to the location of the referenced resource. A relative URI will be resolved relative to the location of the document containing the link.
This value may be one of:
+back-matter resource in this or an imported document (see linking to another OSCAL object).This value must be an absolute URI that serves as a naming system identifier.
+This value may be one of:
+back-matter resource in this or an imported document (see linking to another OSCAL object).This value must be an absolute URI that serves as a naming system identifier.
+Provides a means to segment the value space for the name, so that different organizations and individuals can assert control over the allowed names and associated text used in a part. This allows the semantics associated with a given name to be defined on an organization-by-organization basis.
An organization MUST use a URI that they have control over. e.g., a domain registered to the organization in a URI, a registered uniform resource names (URN) namespace.
+This value must be an absolute URI that serves as a naming system identifier.
When a ns is not provided, its value should be assumed to be http://csrc.nist.gov/ns/oscal and the name should be a name defined by the associated OSCAL model.
The value of the href can be an internet resource, or a local reference using a fragment e.g. #fragment that points to a back-matter
- resource in the same document.
If a local reference using a fragment is used, this will be indicated by a fragment "#" followed by an identifier which references an identified resource in the document's back-matter or another object that is within the scope of the containing OSCAL document.
If an internet resource is used, the href value will be an absolute or relative URI pointing to the location of the referenced resource. A relative URI will be resolved relative to the location of the document containing the link.
This value may be one of:
+back-matter resource in this or an imported document (see linking to another OSCAL object).The OSCAL Control Catalog format can be used to describe a collection of security controls and related control enhancements, along with contextualizing documentation and metadata. The root of the Control Catalog format is catalog.
-
The OSCAL Control Catalog format can be used to describe a collection of security controls and related control enhancements, along with contextualizing documentation and metadata. The root of the Control Catalog format is catalog.
uuid of the source profile from which the catalog was produced by profile resolution.uuid of the profile from which the catalog was produced by profile resolution.Catalogs may use one or more group objects to subdivide the control contents of a catalog.
An OSCAL catalog model provides a structured representation of control information.
Catalogs can use a group to collect related controls into a single grouping. That can be useful to group controls into a family or other logical grouping.
A group may have its own properties, statements, parameters, and references, which are inherited by all members of that group.
Catalogs can use the catalog group construct to organize related controls into a single grouping, such as a family of controls or other logical organizational structure.
A group may have its own properties, statements, parameters, and references, which are inherited by all controls of that are a member of the group.
A class can be used in validation rules to express extra constraints over named items of a specific class value.
A class can also be used in an OSCAL profile as a means to target an alteration to control content.
A class can be used in validation rules to express extra
+ constraints over named items of a specific class
+ value.
A class can also be used in an OSCAL profile as a means to
+ target an alteration to control content.
control. For example, a value of 'withdrawn' can indicate that the control has been withdrawn and should no longer be used.control. For example, a
+ value of 'withdrawn' can indicate that the control has
+ been withdrawn and should no longer be used.Nested statement parts are "item" parts.
Objectives can be nested.
Assessment objects appear on assessment methods.
Controls may be grouped using group, and controls may be partitioned using part or further enhanced (extended) using control.
A control must have a part with the name "statement", which represents the textual narrative of the control. This "statement" part must occur only once, but may have nested parts to allow for multiple paragraphs or sections of text.
+Each security or privacy control within the catalog is defined by a distinct control instance. Controls may be as complex or as simple as a catalog defines them. They may be decomposed or further specified into child control objects, for example to represent control enhancements or specific breakouts of control functionality, to be maintained as discrete requirements. Controls may also contain structured parts (using part) and they may be grouped together in families or classes with group.
Control structures in OSCAL will also exhibit regularities and rules that are not codified in OSCAL but in its applications or domains of application. For example, for catalogs describing controls as defined by NIST SP 800-53, a control must have a part with the name "statement", which represents the textual narrative of the control. This "statement" part must occur only once, but may have nested parts to allow for multiple paragraphs or sections of text. This organization supports addressability of this data content as long as, and only insofar as, it is consistently implemented across the control set. As given with these model definitions, constraints defined and assigned here can aid in ensuring this regularity; but other such constraints and other useful patterns of use remain to be discovered and described.
The OSCAL Component Definition Model can be used to describe the implementation of controls in a component or a set of components grouped as a capability. A component can be either a technical component, or a documentary component. A technical component is a component that is implemented in hardware (physical or virtual) or software. A documentary component is a component implemented in a document, such as a process, procedure, or policy.
The root of the OSCAL Implementation Component format is component-definition.
-
NOTE: This documentation is a work in progress. As a result, documentation for many of the information elements is missing or incomplete.
+The OSCAL Component Definition Model can be used to describe the implementation of controls in a component or a set of components grouped as a capability. A component can be either a technical component, or a documentary component.
A technical component is a component that is implemented in hardware (physical or virtual) or software. Suppliers may document components in an OSCAL component definition that describes the implementation of controls in their hardware and software.
+A documentary component is a component implemented for a documented process, procedure, or policy. Suppliers may document components in an OSCAL component definition that describes the implementation of controls in their process, procedure, or policy.
+The information provided by a technical or documentary component can be used by component consumers to provide starting narratives for documenting control implementations in an OSCAL SSP.
+The root of the OSCAL Implementation Layer Component Definition model is component-definition.
component definition can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.This value may be one of:
+back-matter resource in this or an imported document (see linking to another OSCAL object).component can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.capability can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance).This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.A given component must not be referenced more than once within the same capability.
control implementation set can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.A URL reference to the source catalog or profile for which this component is implementing controls for.
+This value may be one of:
+back-matter resource in this or an imported document (see linking to another OSCAL object).control implementation can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance).This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.Implemented requirements within a component or capability in a component definition provide a means to suggest possible control implementation details, which may be used by a different party when authoring a system security plan. Thus, these requirements defined in a component definition are only a suggestion of how to implement, which may be adopted wholesale, changed, or ignored by a person defining an information system implementation.
+Implemented requirements within a component or capability in a component definition provide a means for component suppliers to suggest possible control implementation details, which may be used by a different party (e.g., component consumers) when authoring a system security plan. Thus, these requirements defined in a component definition are only a suggestion of how to implement, which may be adopted wholesale, changed, or ignored by a person defining an information system implementation.
Use of set-parameter in this context, sets the parameter for the referenced control and any associated statements.
While a part is not required to have an id, it is often desirable for an identifier to be provided, which allows the part to be referenced elsewhere in OSCAL document instances. For this reason, it is RECOMMENDED to provide a part identifier.
+ns.name. This allows different organizations to associate distinct semantics with the same name.Provides a means to segment the value space for the name, so that different organizations and individuals can assert control over the allowed names and associated text used in a part. This allows the semantics associated with a given name to be defined on an organization-by-organization basis.
An organization MUST use a URI that they have control over. e.g., a domain registered to the organization in a URI, a registered uniform resource names (URN) namespace.
+This value must be an absolute URI that serves as a naming system identifier.
When a ns is not provided, its value should be assumed to be http://csrc.nist.gov/ns/oscal and the name should be a name defined by the associated OSCAL model.
name. This can be used to further distinguish or discriminate between the semantics of multiple parts of the same control with the same name and ns.
- name, or a category to which the part belongs.One use of this flag is to distinguish or discriminate between the semantics of multiple parts of the same control with the same name and ns (since even within a given namespace it can be useful to overload a name).
A class can be used in validation rules to express extra constraints over named items of a specific class value.
A class can also be used in an OSCAL profile as a means to target an alteration to control content.
A part provides for logical partitioning of prose, and can be thought of as a grouping structure (e.g., section). A part can have child parts allowing for arbitrary nesting of prose content (e.g., statement hierarchy). A part can contain prop objects that allow for enriching prose text with structured name/value information.
A part can be assigned an optional id, which allows for internal and external references to the textual concept contained within a part. A id provides a means for an OSCAL profile, or a higher layer OSCAL model to reference a specific part within a catalog. For example, an id can be used to reference or to make modifications to a control statement in a profile.
A part can be assigned an optional id, which allows references to this part from within a catalog, or within an instance of another OSCAL model that has a need to reference the part. Examples of where part referencing is used in OSCAL include:
Use of part and prop provides for a wide degree of extensibility within the OSCAL catalog model. The optional ns provides a means to qualify a part's name, allowing for organization-specific vocabularies to be defined with clear semantics. Any organization that extends OSCAL in this way should consistently assign a ns value that represents the organization, making a given namespace qualified name unique to that organization. This allows the combination of ns and name to always be unique and unambiguous, even when mixed with extensions from other organizations. Each organization is responsible for governance of their own extensions, and is strongly encouraged to publish their extensions as standards to their user community. If no ns is provided, the name is expected to be in the "OSCAL" namespace.
To ensure a ns is unique to an organization and naming conflicts are avoided, a URI containing a DNS or other globally defined organization name should be used. For example, if FedRAMP and DoD both extend OSCAL, FedRAMP will use the ns http://fedramp.gov/ns/oscal, while DoD might use the ns https://defense.gov for any organization specific name.
Tools that process OSCAL content are not required to interpret unrecognized OSCAL extensions; however, OSCAL compliant tools should not modify or remove unrecognized extensions, unless there is a compelling reason to do so, such as data sensitivity.
A class can be used in validation rules to express extra constraints over named items of a specific class value.
value if no value is assigned.The label value should be suitable for inline display in a rendered catalog.
+The label value is intended use when rendering a parameter in generated documentation or a user interface when a parameter is referenced. Note that labels are not required to be distinctive, which means that parameters within the same control may have the same label.
A set of values provided in a catalog can be redefined at any higher layer of OSCAL (e.g., Profile).
+A set of values provided in a catalog can be redefined in OSCAL's profile or system-security-plan models.
A set of parameter value choices, that may be picked from to set the parameter value.
+The OSCAL parameter value construct can be used to prescribe a specific parameter value in a catalog or profile. In cases where a prescriptive value is not possible in a catalog or profile, it may be possible to constrain the set of possible values to a few options. Use of select in a parameter instead of value is a way of defining value options that may be set.
A set of allowed parameter values expressed as a set of options which may be selected. These options constrain the permissible values that may be selected for the containing parameter. When the value assignment is made, such as in an OSCAL profile or system security plan, the actual selected value can be examined to determine if it matches one of the permissible choices for the parameter value.
+When the value of how-many is set to "one-or-more", multiple values may be assigned reflecting more than one choice.
A set of parameter value choices, that may be picked from to set the parameter value.
@@ -267,7 +270,10 @@id value. When referencing an externally defined control, the Control Identifier Reference must be used in the context of the external / imported OSCAL instance (e.g., uri-reference).id value. When referencing an externally defined control, the Control Identifier Reference must be used in the context of the external / imported OSCAL instance (e.g., uri-reference).system identification, the system identification must be used in the context of the external / imported OSCAL instance (e.g., uri-reference). This string should be assigned per-subject, which means it should be consistently used to identify the same system across revisions of the document.This value must be an absolute URI that serves as a naming system identifier.
+An organization MUST use a URI that they have control over. e.g., a domain registered to the organization in a URI, a registered uniform resource names (URN) namespace.
+This value must be an absolute URI that serves as a naming system identifier.
When a ns is not provided, its value should be assumed to be http://csrc.nist.gov/ns/oscal and the name should be a name defined by the associated OSCAL model.
The value of the href can be an internet resource, or a local reference using a fragment e.g. #fragment that points to a back-matter
- resource in the same document.
If a local reference using a fragment is used, this will be indicated by a fragment "#" followed by an identifier which references an identified resource in the document's back-matter or another object that is within the scope of the containing OSCAL document.
If an internet resource is used, the href value will be an absolute or relative URL pointing to the location of the referenced resource. A relative URL will be resolved relative to the location of the document containing the link.
This value may be one of:
+back-matter resource in this or an imported document (see linking to another OSCAL object).While published, last-modified, and oscal-version are not required, values for these entries should be provided if the information is known. A link with a rel of source
should be provided if the information is known.
Permissible values to be determined closer to the application (e.g. by a receiving authority).
+OSCAL has defined a set of standardized roles for consistent use in OSCAL documents. This allows tools consuming OSCAL content to infer specific semantics when these roles are used. These roles are documented in the specific contexts of their use (e.g., responsible-party, responsible-role). When using such a role, it is necessary to define these roles in this list, which will then allow such a role to be referenced.
+The physical address of the location, which will provided for physical locations. Virtual locations can omit this data item.
+A contact email associated with the location.
+A phone number used to contact the location.
+This data field is deprecated in favor of using a link with an appropriate relationship.
+class can be used to indicate the sub-type of data-center as primary or alternate.An address might be sensitive in nature. In such cases a title, mailing address, email-address, and/or phone number may be used instead.
+person individuals with a specific purpose.This value must be an absolute URI that serves as a naming system identifier.
+This is a contact email associated with the party.
+A phone number used to contact the party.
+party by UUID, typically an organization, that this subject is associated with.Since the reference target of an organizational affiliation must be another party (whether further qualified as person or organization) as inidcated by its uuid. As a machine-oriented identifier with uniqueness across document and trans-document scope, this uuid value is sufficient to reference the data item locally or globally across related documents, e.g., in an imported OSCAL instance.
Parties of both the person or organization type can be associated with an organization using the member-of-organization.
A party can be optionally associated with either an address or a location. While providing a meaningful location for a party is desired, there are some cases where it might not be possible to provide an exact location or even any location.
+While published, last-modified, oscal-version, and version are not required, values for these entries should be provided if the information is known. For a revision entry to be considered valid, at least one of the following items must be provided: published, last-modified, version, or a link with a rel of source
.
location can be used to reference the data item locally or globally (e.g., from an importing OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.Typically, the physical address of the location will be used here. If this information is sensitive, then a mailing address can be used instead.
-This is a contact email associated with the location.
-A phone number used to contact the location.
+The combination of scheme and the field value must be unique.
class can be used to indicate the sub-type of data-center as primary or alternate.All OSCAL documents use the same metadata structure, that provides a consistent way of expressing OSCAL document metadata across all OSCAL models. The metadata section also includes declarations of individual objects (i.e., roles, location, parties) that may be referenced within and across linked OSCAL documents.
+The metadata in an OSCAL document has few required fields, representing only the bare minimum data needed to differentiate one instance from another. Tools and users creating OSCAL documents may choose to use any of the optional fields, as well as extension mechanisms (e.g., properties, links) to go beyond this minimum to suit their use cases.
+A publisher of OSCAL content can use the published, last-modified, and version fields to establish information about an individual in a sequence of successive revisions of a given OSCAL-based publication. The metadata for a previous revision can be represented as a revision within this object. Links may also be provided using the predecessor-version and successor-version link relations to provide for direct access to the related resource. These relations can be provided as a link child of this object or as link within a given revision.
A responsible-party entry in this context refers to roles and parties that have responsibility relative to the production, review, publication, and use of the containing document.
location defined in the metadata section of this or another OSCAL instance. The UUID of the location in the source OSCAL instance is sufficient to reference the data item locally or globally (e.g., in an imported OSCAL instance).
- location defined in the metadata section of this or another OSCAL instance. The UUID of the location in the source OSCAL instance is sufficient to reference the data item locally or globally (e.g., in an imported OSCAL instance).
- See the Concepts - Identifier Use page for additional information about the referenced identifier's scope.
-party can be used to reference the data item locally or globally (e.g., from an importing OSCAL instance). This UUID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.This is a contact email associated with the party.
-A phone number used to contact the party.
-party (person or organization) that this subject is associated with. The UUID of the party in the source OSCAL instance is sufficient to reference the data item locally or globally (e.g., in an imported OSCAL instance).
- Parties of both the person or organization type can be associated with an organization using the member-of-organization.
party defined in metadata. The UUID of the party in the source OSCAL instance is sufficient to reference the data item locally or globally (e.g., in an imported OSCAL instance).
- See the Concepts - Identifier Use page for additional information about the referenced identifier's scope.
-Role from the imported OSCAL instance must be referenced in the context of the containing resource (e.g., import, import-component-definition, import-profile, import-ssp or import-ap). This ID should be assigned per-subject, which means it should be consistently used to identify the same subject across revisions of the document.Permissible values to be determined closer to the application (e.g. by a receiving authority).
-OSCAL has defined a set of standardized roles for consistent use in OSCAL documents. This allows tools consuming OSCAL content to infer specific semantics when these roles are used. These roles are documented in the specific contexts of their use (e.g., responsible-party, responsible-role). When using such a role, it is necessary to define these roles in this list, which will then allow such a role to be referenced.
-roles served by the user.This value may be either:
+href, which can be used to verify the resource was not changed since it was hashed.When appearing as part of a resource/rlink, the hash applies to the resource referenced by the href.
-
The hash value can be used to confirm that the resource referenced by the href is the same resources that was hashed by retrieving the resource, calculating a hash, and comparing the result to this value.
This construct is different from link, which makes no provision for a hash or formal title.
Multiple rlink can be included for a resource. In such a case, all provided rlink items are intended to be equivalent in content, but may differ in structure. A media-type is used to identify the format of a given rlink, and can be used to differentiate a items in a collection of rlinks. The media-type also provides a hint to the OSCAL document consumer about the structure of the resource referenced by the rlink.
+
Multiple rlink objects can be included for a resource. In such a case, all provided rlink items are intended to be equivalent in content, but may differ in structure or format.
A media-type is used to identify the format of a given rlink, and can be used to differentiate items in a collection of rlinks. The media-type provides a hint to the OSCAL document consumer about the structure of the resource referenced by the rlink.
resource. This is the name that will be assigned to the file when the file is decoded.rlink or base64 object.Ensures that each rlink item references a unique resource.
-filename.Ensures that all base64 resources have a unique filename.
-
A title is required when a citation is provided.
title is required when a citation is provided.A resource can be used in two ways. 1) it may point to an specific retrievable network resource using a rlink, or 2) it may be included as an attachment using a base64. A resource may contain multiple rlink and base64 entries that represent alternative download locations (rlink) and attachments (base64) for the same resource. Both rlink and base64 allow for a media-type to be specified, which is used to distinguish between different representations of the same resource (e.g., Microsoft Word, PDF). When multiple rlink and base64 items are included for a given resource, all items must contain equivalent information. This allows the document consumer to choose a preferred item to process based on a the selected item's media-type. This is extremely important when the items represent OSCAL content that is represented in alternate formats (i.e., XML, JSON, YAML), allowing the same OSCAL data to be processed from any of the available formats indicated by the items.
A resource can be used in two ways. 1) it may point to an specific retrievable network resource using a rlink, or 2) it may be included as an attachment using a base64. A resource may contain multiple rlink and base64 entries that represent alternative download locations (rlink) and attachments (base64) for the same resource.
Both rlink and base64 allow for a media-type to be specified, which is used to distinguish between different representations of the same resource (e.g., Microsoft Word, PDF). When multiple rlink and base64 items are included for a given resource, all items must contain equivalent information. This allows the document consumer to choose a preferred item to process based on a the selected item's media-type. This is extremely important when the items represent OSCAL content that is represented in alternate formats (i.e., XML, JSON, YAML), allowing the same OSCAL data to be processed from any of the available formats indicated by the items.
When a resource includes a citation, then the title and citation properties must both be included.
Provides a collection of identified resource objects that can be referenced by a link with a rel value of "reference" and an href value that is a fragment "#" followed by a reference to a reference identifier. Other specialized link "rel" values also use this pattern when indicated in that context of use.
Provides a collection of identified resource objects that can be referenced by a link with a rel value of "reference" and an href value that is a fragment "#" followed by a reference to a reference's uuid. Other specialized link "rel" values also use this pattern when indicated in that context of use.
Provides a means to segment the value space for the name, so that different organizations and individuals can assert control over the allowed names and associated values used in a property. This allows the semantics associated with a given name/value pair to be defined on an organization-by-organization basis.
An organization MUST use a URI that they have control over. e.g., a domain registered to the organization in a URI, a registered uniform resource names (URN) namespace.
+This value must be an absolute URI that serves as a naming system identifier.
When a ns is not provided, its value should be assumed to be http://csrc.nist.gov/ns/oscal and the name should be a name defined by the associated OSCAL model.
name. This can be used to further distinguish or discriminate between the semantics of multiple properties of the same object with the same name and ns.
- name.A class can be used in validation rules to express extra constraints over named items of a specific class value.
This can be used to further distinguish or discriminate between the semantics of multiple properties of the same object with the same name and ns, or to group properties into categories.
A class can be used in validation rules to express extra constraints over named items of a specific class value. It is available for grouping, but unlike group is not expected specifically to designate any group membership as such.
The value of the href can be an internet resource, or a local reference using a fragment e.g. #fragment that points to a back-matter
- resource in the same document.
If a local reference using a fragment is used, this will be indicated by a fragment "#" followed by an identifier which references an identified resource in the document's back-matter or another object that is within the scope of the containing OSCAL document.
If an internet resource is used, the href value will be an absolute or relative URI pointing to the location of the referenced resource. A relative URI will be resolved relative to the location of the document containing the link.
This value may be one of:
+back-matter resource by UUID expressed as a bare URI fragment.The media-type provides a hint about the content model of the referenced resource. A valid entry from the IANA Media Types registry SHOULD be used.
Since both link and back-matter/resource both allow specification of a media-type, the media-type on link may conflict with the any media-type entries on a resource's rlink or base64 objects. This constraint prevents this from occurring.
roles served by the user.role performed by a party.role.Specifies one or more parties that are responsible for performing the associated role.
-
A responsible-party requires one or more party-uuid references creating a strong relationship arc between the referenced role-id and the reference parties. This differs in semantics from responsible-role which doesn't require that a party-uuid is referenced.
The scope of use of this object determines if the responsibility has been performed or will be performed in the future. The containing object will describe the intent.
+roles responsible for the business function.role performed.role.A responsible-role allows zero or more party-uuid references, each of which creates a relationship arc between the referenced role-id and the referenced party. This differs in semantics from responsible-party, which requires that at least one party-uuid is referenced.
The scope of use of this object determines if the responsibility has been performed or will be performed in the future. The containing object will describe the intent.
+Any other value used MUST be a value defined in the W3C XML Security Algorithm Cross-Reference Digest Methods (W3C, April 2013) or RFC 6931 Section 2.1.5 New SHA Functions.
+Any other value used MUST be a value defined in the W3C XML Security Algorithm Cross-Reference Digest Methods (W3C, April 2013) or RFC 6931 Section 2.1.5 New SHA Functions.
A hash value can be used to authenticate that a referenced resource is the same resources as was pointed to by the author of the reference.
-The IANA Media Types Registry should be used, but currently there is no official media type for YAML. OSCAL documents should specify application/yaml for general YAML content, or application/oscal+yaml for YAML-based OSCAL content. This approach aligns with use of a structured name suffix, per RFC 6838 Section 4.2.8.
The Internet Assigned Numbers Authority (IANA) Media + Types Registry defines a standardized set of media types, which may be used + here.
+The application/oscal+xml, application/oscal+json or application/oscal+yaml media types SHOULD be used when referencing OSCAL XML, JSON, or YAML resources respectively.
**Note: There is no official media type for YAML at this time.** OSCAL documents should specify application/yaml for general YAML content, or application/oscal+yaml for YAML-based OSCAL content. This approach aligns with use of a structured name suffix, per RFC 6838 Section 4.2.8.
Some earlier OSCAL content incorporated the model into the media type. For example: application/oscal.catalog+xml. This practice SHOULD be avoided, since the OSCAL model can be detected by parsing the initial content of the referenced resource.
The remarks field SHOULD not be used to store arbitrary data. Instead, a prop or link should be used to annotate or reference any additional data not formally supported by OSCAL.
This value represents the point in time when the OSCAL document was published. Typically, this date value will be machine generated at the time the containing document is published.
-In some cases, an OSCAL document may be derived from some source material in a different format. In such a case, the published value should indicate when the OSCAL document was published, not the source material. Where necessary, the publication date of the original source material can be captured as a named property or custom metadata construct.
A publisher of OSCAL content can use this data point along with its siblings last-modified and version to establish a sequence of successive revisions of a given OSCAL-based publication. The metadata for previous revisions can be represented as a revision in this object.
Typically, this date value will be machine-generated at the time the containing document is published.
+In some cases, an OSCAL document may be derived from some source material provided in a different format. In such a case, the published value should indicate when the OSCAL document instance was last published, not the source material.
This value represents the point in time when the OSCAL document was last updated, or at the point of creation the creation date. Typically, this date value will be machine generated at time of creation or modification.
-In some cases, an OSCAL document may be derived from some source material in a different format. In such a case, the last-modified value should indicate the modification time of the OSCAL document, not the source material.
A publisher of OSCAL content can use this data point along with its siblings published and version to establish a sequence of successive revisions of a given OSCAL-based publication. The metadata for previous revisions can be represented as a revision in this object.
This value represents the point in time when the OSCAL document was last updated, or at the point of creation the creation date. Typically, this date value will be machine generated at time of creation or modification. Ideally, this field will be managed by the editing tool or service used to make modifications when storing the modified document.
+The intent of the last modified timestamp is to distinguish between significant change milestones when the document may be accessed by multiple entities. This allows a given entity to differentiate between mutiple document states at specific points in time. It is possible to make multiple modifications to the document without storing these changes. In such a case, the last modified timestamp might not be updated until the document is finally stored.
+In some cases, an OSCAL document may be derived from some source material in a different format. In such a case, the last-modified value should indicate the last modification time of the OSCAL document instance, not the source material.
A version string may be a release number, sequence number, date, or other identifier suffcient to distinguish between different document versions. This version is typically set by the document owner or by the tool used to maintain the content.
-While not required, it is recommended that OSCAL content authors use Semantic Versioning as a format for version strings. This allows for the easy identification of a version tree consisting of major, minor, and patch numbers.
-A publisher of OSCAL content can use this data point along with its siblings published and last-modified to establish a sequence of successive revisions of a given OSCAL-based publication. The metadata for previous revisions can be represented as a revision in this object.
A version may be a release number, sequence number, date, or other identifier sufficient to distinguish between different document revisions.
+While not required, it is recommended that OSCAL content authors use Semantic Versioning as the version format. This allows for the easy identification of a version tree consisting of major, minor, and patch numbers.
+A version is typically set by the document owner or by the tool used to maintain the content.
Indicates the version of the OSCAL model to which this data set conforms, for example 1.1.0
or 1.0.0-M1
. That can be used as a hint by a tool to indicate which version of the OSCAL XML or JSON schema to use for validation.
Indicates the version of the OSCAL model to which the document conforms, for example 1.1.0
or 1.0.0-milestone1
. That can be used as a hint for a tool indicating which version of the OSCAL XML or JSON schema to use for validation.
The OSCAL version serves a different purpose from the document version and is used to represent a different concept. If both have the same value, this is coincidental.
Providing a country code provides an international means to interpret the phone number.
+scheme. A document identifier provides a globally unique identifier with a cross-instance scope that is used for a group of documents that are to be treated as different versions of the same document. If this element does not appear, or if the value of this element is empty, the value of "document-id" is equal to the value of the "uuid" flag of the top-level root element.scheme.This value must be an absolute URI that serves as a naming system identifier.
+This element is optional, but it will always have a valid value, as if it is missing the value of "document-id" is assumed to be equal to the UUID of the root. This requirement allows for document creators to retroactively link an update to the original version, by providing a document-id on the new document that is equal to the uuid of the original document.
+A document identifier provides a globally unique identifier with a cross-instance scope that is used for a group of documents that are to be treated as different versions, representations or digital surrogates of the same document.
+A document identifier provides an additional data point for identifying a document that can be assigned by a publisher or organization for purposes in a wider system, such as a digital object identifier (DOI) or a local content management system identifier.
+Use of a document identifier allows for document creators to associate sets of documents that are related in some way by the same document-id.
An OSCAL document always has an implicit document identifier provided by the document's UUID, defined by the uuid on the top-level object. Having a default UUID-based identifier ensures all documents can be minimally identified when other document identifiers are not provided.
A profile designates a selection and configuration of controls from one or more catalogs, along with a series of operations over them. The topmost element in the OSCAL profile XML schema is profile.
In OSCAL a profile represents a set of selected controls from one or more control catalogs. Such a set of controls can + be referenced by an OSCAL system security plan (SSP) to establish a control baseline. This effective set of controls is produced from an OSCAL + profile using a deterministic, predictable process called profile resolution.
+A profile references one or more OSCAL catalogs or profiles to import controls for control selection and tailoring. A profile can also describe how a resulting catalog is structured. When the profile is resolved, these selections and modifications are processed to produce a resulting OSCAL catalog.
+OSCAL profiles have uses beyond establishing control baselines, such as documentation + generation or as reference tables for validations.
profile
+ element.profile can be used to reference the data item locally or globally (e.g., in an imported OSCAL instance).This identifier should be assigned per-subject, which means it should be consistently used to identify the same profile across revisions of the document.An OSCAL document that describes a tailoring of controls from one or more catalogs, with possible modification of multiple controls. It provides mechanisms by which controls may be selected (import), merged or (re)structured (merge), and amended (modify). OSCAL profiles may select subsets of controls, set parameter values for them in application, and even adjust the representation of controls as given in and by a catalog. They may also serve as sources for further modification in and by other profiles, that import them.
See the Concepts - Identifier Use page for additional information regarding this identifier's uniqueness and scope.
import designates a catalog or profile to be included (referenced and potentially modified) by this profile. The import also identifies which controls to select using the include-all, include-controls, and exclude-controls directives.The value of the href can be an internet resource, or an internal reference using a fragment e.g. #fragment that points to a back-matter
- resource in the same document.
If a local reference using a fragment is used, this will be indicated by a fragment "#" followed by an identifier which references the uuid value of a resource in the document's back-matter.
If an internet resource is used, the href value will be an absolute or relative URL pointing to the location of the referenced resource. A relative URL will be resolved relative to the location of the document containing the link.
This value may be one of:
+back-matter resource in this or an imported document (see linking to another OSCAL object).A profile must be based on an existing OSCAL catalog or another OSCAL profile. An import indicates such a source whose controls are to be included (referenced and modified) in a profile. This source will either be a catalog whose controls are given (by value
), or a profile with its own control imports.
The contents of the import element indicate which controls from the source will be included. Controls from the source catalog or profile may be either selected, using the include-all or include-controls directives, or de-selected (using an exclude-controls directive).
Whenever combining controls from multiple (import) pathways, an issue arises of what to do with clashing invocations (multiple competing versions of a control).
-This setting permits a profile designer to apply a rule for the resolution of such cases. In a well-designed profile (e.g. one that uses mapping), such collisions would ordinarily be avoided, but this setting can be useful for defining what to do when it occurs.
-If no combine element appears, it is considered equivalent to providing a combine element with a method of value keep
.
The custom element represents a custom arrangement or organization of controls in the resolution of a catalog.
While the as-is element provides for a restitution of a control set's organization (in one or more source catalogs), this element permits the definition of an entirely different structure.
The custom element represents a custom arrangement or organization of controls in the resolution of a catalog. This structuring directive gives the profile author the ability to define an entirely different organization of controls as compared to their source catalog(s).
The contents of the merge element may be used to reorder
or restructure
controls by indicating an order and/or structure in resolution.
Implicitly, a merge element is also a filter: controls that are included in a profile, but not included (implicitly or explicitly) in the scope of a merge element, will not be merged into (will be dropped) in the resulting resolution.
This optional data element is available to support hyperlinking to formal groups or families as defined in control catalogs, among other operations.
+title or proptitle or
+ prop.The value of the href can be an internet resource, or a local reference using a fragment e.g. #fragment that points to a back-matter
- resource in the same document.
If a local reference using a fragment is used, this will be indicated by a fragment "#" followed by an identifier which references an identified resource in the document's back-matter or another object that is within the scope of the containing OSCAL document. The identified resource will be used instead as the target resource.
If an internet resource is used, the href value will be an absolute or relative URI pointing to the location of the target resource. A relative URI will be resolved relative to the location of the document containing the link.
If the resource is an OSCAL profile, it is expected that a tool will resolve the profile according to the OSCAL [profile resolution specification](https://pages.nist.gov/OSCAL/concepts/processing/profile-resolution/) to produce a resolved profile for use when processing the containing system security plan. This allows a system security plan processor to use the baseline as a catalog of controls.
+This value may be one of:
+back-matter resource in this or an imported document (see linking to another OSCAL object).If the resource is an OSCAL profile, it is expected that a tool will resolve the profile according to the OSCAL profile resolution specification to produce a resolved profile for use when processing the containing system security plan. This allows a system security plan processor to use the baseline as a catalog of controls.
While it is possible to reference a previously resolved OSCAL profile as a catalog, this practice is discouraged since the unresolved form of the profile communicates more information about selections and changes to the underlying catalog. Furthermore, the underlying catalog can be maintained separately from the profile, which also has maintenance advantages for distinct maintainers, ensuring that the best available information is produced through profile resolution.
Since system-name-short is optional, if the system-name-short is not provided, the system-name can be used as a substitute.
This value must be an absolute URI that serves as a naming system identifier.
+