NIST SP 800-126 Rev. 4 日本語訳

SCAP Version 1.4

Dragos Prisaca Stephen D. Quinn Jack Vander Pol Daniel K. Harris

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-126r4

SCAP Version 1.4

Dragos Prisaca Stephen D. Quinn Computer Security Division Information Technology Laboratory

Jack Vander Pol Daniel K. Harris Naval Information Warfare Center (NIWC) Atlantic

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-126r4

June 2026

U.S. Department of Commerce Howard Lutnick, Secretary of Commerce

National Institute of Standards and Technology Arvind Raman, NIST Director and Under Secretary of Commerce for Standards and Technology

Certain equipment, instruments, software, or materials, commercial or non-commercial, are identified in this paper in order to specify the experimental procedure adequately. Such identification does not imply recommendation or endorsement of any product or service by NIST, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at https://csrc.nist.gov/publications.

Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

NIST Technical Series Policies Copyright, Use, and Licensing Statements NIST Technical Series Publication Identifier Syntax

Publication History Approved by the NIST Editorial Review Board on 2026-04-23

How to Cite this NIST Technical Series Publication Prisaca D, Quinn SD, Vander Pol J, Harris DK (2026) Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.4. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-126r4. https://doi.org/10.6028/NIST.SP.800-126r4

Dragos Prisaca: 0009-0007-7361-8433

Stephen D. Quinn: 0000-0003-1436-684X

scap@nist.gov

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930

Additional information about this publication is available at https://csrc.nist.gov/pubs/sp/800/126/r4/final, including related content, potential updates, and document history.

All comments are subject to release under the Freedom of Information Act (FOIA).

The Security Content Automation Protocol (SCAP) is a suite of specifications that standardize the format and nomenclature by which software flaw and security configuration information is communicated, both to machines and humans. This publication, along with its annex (NIST Special Publication 800-126Ar4) and a set of schemas, collectively define the technical composition of SCAP version 1.4 in terms of its component specifications, their interrelationships and interoperation, and the requirements for SCAP content.

checklists; patch verification; security automation; security checklists; security configuration; Security Content Automation Protocol (SCAP); software flaws; vulnerabilities.

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

Patent Disclosure Notice

NOTICE: ITL has requested that holders of patent claims whose use may be required for compliance with the guidance or requirements of this publication disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL calls for patents and ITL has not undertaken a patent search in order to identify which, if any, patents may apply to this publication.

As of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance or requirements of this publication, no such patent claims have been identified to ITL.

No representation is made or implied by ITL that licenses are not required to avoid patent infringement in the use of this publication.

The authors wish to thank all individuals who have contributed to this and prior revisions of SP 800-126. Specifically, the authors thank the co-authors of the previous revision: Harold Booth of NIST, David Waltermire formerly from NIST, and Karen Kent of the Trusted Cyber Annex.

The authors also offer a special thanks to the contributors to this revision, including Robert Byers, Jim Foti, Bob Gendler, Blair Heiserman, Gopi Katwala, and Isabel Van Wyk from NIST and Greg Witte from Palydin LLC.

Executive Summary

The Security Content Automation Protocol (SCAP) is a suite of specifications that standardize the format and nomenclature by which security configuration information is communicated to both machines and humans.¹ SCAP is a multi-purpose framework of specifications that support automated configuration, vulnerability and patch checking, technical and managerial control compliance activities, and security measurement. Goals for the development of SCAP include standardizing system security management, promoting the interoperability of security products, and fostering the use of standard expressions of security content.

Security configuration in SCAP format is curated and managed by the NIST National Checklist Program (NCP), which is described in NIST Special Publication (SP) 800-70r5 (Revision 5). This document, its annex [SP800-126Ar4], and a set of schemas collectively define the technical composition of SCAP version 1.4 in terms of its component specifications and requirements. The technical specification for SCAP describes the conventions for ensuring the consistent and accurate exchange of SCAP-conformant content and the ability to reliably use the content with SCAP-conformant products.

Organizations that develop SCAP 1.4-based content or products should adhere to the following recommendations:

Organizations should ensure that their implementation and use of SCAP 1.4 complies with the requirements detailed in each component specification, this document, its annex, and the set of schemas.

If requirements conflict between component specifications, this document will provide clarification. If a component specification conflicts with this document, the requirements in this document take precedence. If a component specification or this document conflicts with the annex, the requirements in the annex take precedence. If a specification and a schema conflict, the requirements in the specification take precedence.

Security products and checklist authors assemble content from SCAP data repositories to create SCAP-conformant security guidance. Organizations that produce SCAP content to be shared between tools should adhere to the conventions described in this specification to ensure the highest degree of interoperability.

This document, its annex [SP800-126A], and a set of schemas collectively provide the technical specification for version 1.4 of the Security Content Automation Protocol (SCAP). SCAP (pronounced /EHS-kap/) consists of a suite of specifications for standardizing the format and nomenclature by which software flaw and security configuration information is communicated to both machines and humans. This document defines requirements for creating and processing SCAP source content that build on the requirements defined within the individual SCAP component specifications. Each new requirement pertains to either using multiple component specifications together or further constraining one of the individual component specifications.²

To extend the contents of this document, [SP800-126A] has been created as an annex to specify additional entities that may be used in SCAP 1.4-conformant content creation and processing. It provides:

The scope of this document and its annex is limited to SCAP version 1.4. Other versions of SCAP and its component specifications are not addressed in these documents.

Future versions of SCAP will be defined in distinct revisions of this document and its annex, each clearly labeled with a document revision number and the appropriate SCAP version number.

This document is intended for:

The remainder of this document is organized into the following major sections and appendices:

In this document, the capitalized terms “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,” “SHOULD NOT,” “RECOMMENDED,” “MAY,” and “OPTIONAL” are to be interpreted as described in Request for Comment (RFC) 2119 [RFC2119]. When these words appear in lowercase (e.g., “should,” “may”), they are not intended to be interpreted as RFC 2119 key words.

Italicized single terms are defined and listed in Appendix C.

Some of the requirements and conventions used in this document reference Extensible Markup Language (XML) content [XMLS]. These references come in two forms: inline and indented.

An example of an inline reference is:

A <cpe2_dict:cpe-item> may contain <cpe2_dict:check> elements that reference OVAL definitions.

In this example, the notation <cpe2_dict:cpe-item> can be replaced by a more verbose equivalent: “The XML element whose qualified name is cpe2_dict:cpe-item.”

An example of an indented reference is:

References to OVAL definitions are expressed using the following format:

<cpe2_dict:check system= "http://oval.mitre.org/XMLSchema/oval-definitions-5" href="Oval_URL">[Oval_inventory_definition_id] </cpe2_dict:check>

When describing XML attributes within this document, the general convention is to reference the attribute and its associated element, including the namespace alias:

@attributeName for the <prefix:localName>

Indented references are intended to represent the form of actual XML content. Indented references represent literal content by the use of a fixed-length font and parametric (i.e., freely replaceable) content by the use of italics. Square brackets ‘[]’ are used to designate optional content. Thus, “[Oval_inventory_definition_id]” designates optional content.

Both inline and indented forms use qualified names to refer to specific XML elements. A qualified name associates a named element with a namespace. The namespace identifies the XML model, and the XML schema is a definition and implementation of that model. A qualified name declares this schema-to-element association using the format “prefix:element-name.” The association of prefix to namespace is defined in the metadata of an XML document and varies from document to document. In this specification, the conventional mappings listed in Table 1 are used.

Table 1. Conventional XML mappings³

In general, SCAP version 1.4 is comprised of 12 component specifications in five categories:

More specifically, the five categories for the component specifications included in SCAP 1.4 are:

Extensible Configuration Checklist Description Format (XCCDF) 1.2, a language for authoring security checklists/benchmarks and for reporting results of evaluating them [XCCDF]

Open Vulnerability and Assessment Language (OVAL) 5.12, a language for o representing system configuration information, assessing machine states, and reporting assessment results [OVAL]⁴

All references to these specifications within this document are to the minor version numbers listed in the annex.⁶ These versions represent the baseline of interoperability for all SCAP products that support SCAP 1.4. Support for older versions of these specifications may be included in an SCAP 1.4 product, but support for legacy SCAP versions should not interfere with the product’s ability to address the requirements in this specification and the annex. In some cases, support for specific legacy versions of these specifications is required by this specification, such as the requirements discussed in Sec. 4.1.

Combinations of these specifications can be used together for particular functions, such as security configuration checking. These functions, known as SCAP use cases, are ways in which a product can use SCAP. The collective XML content used for a use case is called an SCAP data stream, which is a specific instantiation of SCAP content. There are two types of SCAP data streams: an SCAP source data stream holds the input content, and an SCAP result data stream holds the output content. The major elements of a data stream (e.g., an XCCDF benchmark, a set of OVAL definitions) are referred to as stream components.

Products and source content may want to claim conformance to one or more of the SCAP use cases (see Sec. 5) for a variety of reasons. For example, a product may want to assert that it uses SCAP content properly and can interoperate with other products using valid SCAP content. Another example is a policy mandating that an organization use SCAP source content to perform vulnerability assessments and other security operations.

This section provides the high-level requirements that a product or source content must meet for conformance with the SCAP 1.4 specification. Such products and source content are referred to as SCAP-conformant. Most of the requirements listed in this section reference other sections that fully define the requirements.

If requirements are in conflict between component specifications, this document will provide clarification. If a component specification conflicts with this document, the requirements in this document SHALL take precedence. This document will be republished with errata as needed, and the errata SHALL take precedence over the original document content.

The requirements in [SP800-126A] SHALL take precedence over conflicting requirements in this document or the component specifications. If an SCAP specification or component specification and a schema are in conflict, the requirements in the specification SHALL take precedence over all conflicting requirements in the schema.

There are two types of SCAP-conformant products: content producers and content consumers. Content producers generate SCAP source data streams. Content consumers accept existing SCAP source data streams, process them, and (when required by the supported use cases) produce SCAP result data streams. Products that claim conformance with the SCAP 1.4 specification SHALL comply with the following requirements:

Adhere to the requirements in each applicable SCAP component specification, both for each component that the product implements and for each component required to implement the selected SCAP use cases. The authoritative references for component specifications are listed in [SP800-126A].

Adhere to the requirements in the errata for this document and SP 800-126A that are in effect as of the product’s release date.

For content producers, generate SCAP source data streams that are (a) XML well-formed, (b) schema-valid per the applicable component specifications, and (c) conformant to the source content conformance requirements in Sec. 2.2 and the use case requirements in Sec. 5.

For content consumers, accept and process SCAP source data streams and, when required by the supported use cases, generate SCAP result data streams that are XML well-formed and schema-valid. Content consumers SHALL follow all processing requirements in Sec. 4 for each selected SCAP component specification and each component specification required to implement the selected SCAP use cases and SHALL detect and report non-conformant input.

Make an explicit claim of conformance to this specification in documentation provided to end users. The claim SHALL identify at least (a) this specification and version (SCAP 1.4), (b) the implemented roles (e.g., producer, consumer), (c) the supported SCAP use cases (Sec. 5), and (d) the implemented SCAP component specifications and versions.

Source content (i.e., source data streams) that claim conformance with the SCAP 1.4 specification SHALL comply with the following requirements:

Adhere to the requirements specified in each applicable SCAP component specification. This includes both the component specifications explicitly selected for the content and any additional component specifications required to support the selected SCAP use cases. Authoritative references for each specification are provided in [SP800-126A].

Adhere to the requirements published in errata for this document and SP 800-126A. In the event of a conflict, the errata SHALL take precedence.

Follow all syntax, structural, and design requirements defined in Sec. 3 for each applicable component specification. In addition, follow all use case-specific requirements defined in Sec. 5.

This section defines the SCAP 1.4 content syntax, structure, and development requirements and recommendations for SCAP-conformant content and products. Organizations are encouraged to adopt the optional recommendations to promote stronger interoperability and greater content consistency. The first part of the section discusses SCAP source data streams. The middle of the section groups requirements and recommendations by specification: XCCDF, OVAL, OCIL, CPE, CCE, CVE, CVSS, and CCSS, in that order. Finally, the last part of the section discusses applying XML digital signatures to source data streams.

This subsection discusses SCAP source data streams only; SCAP result data streams are discussed in Sec. 4.4 as part of the requirements for SCAP processing.

An SCAP source data stream collection is composed of SCAP data streams and SCAP source components.⁷ The components section contains an unbounded number of SCAP source components, each consisting of data expressed using one or more of the SCAP specifications. The data streams section contains one or more source data streams, each of which references the source components that compose the data stream. This model allows source components to be reused across multiple data streams. Many data streams are allowed in a data stream collection to allow for the grouping of related or similar source data streams.

Figure 1 shows a possible relationship between data stream collections, data streams, and components.

Fig. 1. Notional SCAP data stream collection

In Fig. 1, data stream 1 points to xccdf1, xccdf2, oval1, oval3, cpe dict1, and cpe dict2. Data stream 2 points to xccdf2, oval2, oval3, and cpe dict2. Each data stream is a collection of links to the components it references, represented as <ds:component-ref>. Each component-ref encapsulates the information required to allow the content consumer to connect the components that are embedded in content with the data stream component that should be used. Content authors MAY place components in any order. For example, some authors might choose to place dictionary components first to help optimize data stream parsing.

Links in a <ds:component-ref> element serve two purposes: to indicate which component is being referred to and to provide a map to associate references within a component to other links within the data stream. The latter allows a data stream to define context for each component’s references within the bounds of the data stream’s own set of links. Figure 2 provides a conceptual example that illustrates how a data stream is constructed.

Fig. 2. SCAP data stream

The following XML is a stripped-down example of the source data stream depicted in Fig. 2.

In Fig. 2, the data stream links to three components. The OVAL component scap_id_comp_oval1 (see XML lines 31-33 above) does not reference external content, so there are no mappings captured for it. The XCCDF component (scap_id_comp_xccdf1) (see XML lines 21-30) and the CPE Dictionary component (scap_id_comp_dict1) (see XML lines 34-44) reference other components (e.g., scap_id_cref_ref3).

When referencing components within the example data stream, a mapping indicates that when scap_id_comp_xccdf1 references “sample-oval-comp,” the content is found through the link to the component identified as “scap_id_comp_oval1” (see XML lines 26, 13, and 18). Similarly, when the scap_id_comp_dict1 component references “dict-oval-comp,” the component reference is resolved through the link to the component identified as “scap_id_comp_oval1” (see XML lines 37, 6, and 18). This approach associates SCAP components within a data stream at the SCAP logical level, allowing components to be reused across data streams within the same data stream collection. This reuse can be accomplished irrespective of how references are made within a given component.

The design of the SCAP source data stream is important for the following reasons:

The tables in this section formalize the SCAP source data stream data model. The tables contain requirements and SHALL be interpreted as follows:

Table 2. ds:data-stream-collection

Table 3. ds:data-stream

Table 4. ds:dictionaries

Table 5. ds:checklists

Table 6. ds:checks

Table 7. ds:extended-components

Table 8. ds:component-ref

Table 9. cat:catalog

Table 10. cat:uri

Table 11. cat:rewriteURI

Table 12. ds:component

Table 13. ds:extended-component

The SCAP source data stream collection SHALL validate against the XML schema representation for the source data stream and all associated Schematron schemas. The SCAP components referenced by each <ds:component> and <ds:extended-component> element SHALL validate against the corresponding component schema and its embedded Schematron rules. All of the SCAP-related schemas are referenced at https://csrc.nist.gov/Projects/security-content-automation-protocol/scap-releases/scap-1-4. See Sec. 2 in [SP800-126A] for a list of SCAP component schema and Schematron schema locations. These XML and Schematron schemas will be updated if any errors are found. If the old schema links change, updated links will be provided in the annex as errors are corrected.

Each SCAP source data stream component SHALL use one of the elements specified in Table 14 as its document element.

Table 14. SCAP source data stream component document elements

SCAP source data stream components SHOULD NOT use any constructs that are deprecated in its associated specification. While Sec. 4.1 requires that products support deprecated constructs, these constructs should be avoided to minimize the impact to content use when the constructs are removed from future revisions of the associated specifications. Single data streams in a data stream collection SHALL NOT reference any component in the collection more than once.

If applicable, each component SHALL validate against its associated Schematron schema. For the SCAP source data stream collection, it SHALL validate against the version of the SCAP Schematron rules as specified on the <ds:data-stream-collection> element’s @schematron-version attribute, and it SHOULD also validate against the latest Schematron rules. NIST provides and maintains a set of Schematron rules to check well-formed SCAP content. The Schematron schemas for the SCAP specification and its applicable component specifications are located at https://csrc.nist.gov/Projects/security-content-automation-protocol/scap-releases/scap-1-4. Source content SHOULD pass all Schematron assertions in the Schematron rule files. When creating source content, failed assertions with a “WARNING” or “INFO” flag MAY be disregarded if the assertion discovers an issue in the content that is justifiable and expected based on the needs of the content author. When executing source content, all failed assertions with a “WARNING” or “INFO” flag SHALL be disregarded.

The Schematron schemas are interpretations of the specifications, and the implementations of their rules are subject to change. Whenever a change is made to a Schematron schema used for this SCAP version, the SCAP Schematron change log document will be updated, and the new Schematron schema will be posted. The latest Schematron schema SHOULD be used in place of any earlier versions. If the latest file is unavailable, the version specified on the <ds:data-stream-collection> element’s @schematron-version attribute SHALL be used instead.

The elements listed in Table 15 have special conventions for the format of their identifiers (@id attribute).

Table 15. Element identifier format convention

Authors SHALL follow these conventions because they preserve the global uniqueness of the resulting identifiers. In Table 15, namespace contains a valid reverse-DNS-style string (limited to letters, numbers, periods, and the hyphen character) that is associated with the content author. Examples include “com.acme.finance” and “gov.tla.” These namespace strings MAY have any number of parts, and SCAP content consumers processing them SHALL treat them as case-insensitive (e.g., com.ABC is considered identical to com.abc). The name in the format conventions SHALL be an NCName-compliant string [XMLS].

This section lists requirements and recommendations for using the Extensible Configuration Checklist Description Format (XCCDF) to express an XCCDF benchmark or tailoring component of an SCAP source data stream (see Table 14). They are organized by the following categories: general, <xccdf:Benchmark>, <xccdf:Profile>, <xccdf:Rule>, <xccdf:Value>, and <xccdf:Group>.

The @xml:base attribute SHALL NOT be allowed in XCCDF content. This attribute is not compatible with the SCAP data stream model.

Descriptive information within XCCDF MAY be used by SCAP products to assist in selecting the appropriate SCAP data stream, ensure that the most recent or correct version of an XCCDF document is used, and provide additional information about the document. The following requirements and conventions apply to the <xccdf:Benchmark>, <xccdf:Profile>, <xccdf:Value>, <xccdf:Group>, and <xccdf:Rule> elements:

XInclude elements SHALL NOT be included in XCCDF content [XINCLUDE].

All remaining OPTIONAL elements in the XCCDF schema MAY be included at the author’s discretion unless otherwise noted in this document.

The following requirements and recommendations apply to the <xccdf:Benchmark> element:

Table 16. Use of Dublin Core terms in <xccdf:metadata>

As stated in the XCCDF specification, the use of an <xccdf:Profile> element is not required, even though SCAP content commonly uses it.

Use of the <xccdf:set-complex-value> element within the <xccdf:Profile> element SHALL NOT be allowed. Use of complex values is disallowed because the behavior for mapping XCCDF complex values to OVAL variables is not defined.

The following requirements and recommendations apply to the <xccdf:Rule> element. The topics they address are <xccdf:ident> elements, <xccdf:check> elements, patching up-to-date rules, and CVSS and CCSS scores.

Each <xccdf:Rule> element SHALL include an <xccdf:ident> element that contains a CVE, CCE, or CPE identifier reference if an appropriate identifier exists. The meaning of the identifier SHALL be consistent with the recommendation implemented by the <xccdf:Rule> element. The <xccdf:ident> element content SHALL match the corresponding CVE, CCE, or CPE identifier found in the associated OVAL definitions if the rule references an OVAL definition, if an appropriate identifier exists, and if that OVAL definition is the only input to the rule’s final result.

When referencing a CVE, CCE, or CPE identifier, an <xccdf:Rule> element SHALL have a purpose consistent with one of the rows in Table 17.

Table 17. <xccdf:Rule> and <xccdf:ident> element values

Based on the purpose of the <xccdf:Rule> element, the <xccdf:Rule> SHALL define its <xccdf:ident> element’s @system attribute using the corresponding value from Table 17. Also, if the <xccdf:Rule> element references an OVAL definition, it SHALL reference an OVAL definition of the specified class.

Here is a partial example of a rule intended to check compliance with a configuration setting:

<xccdf:Rule id="xccdf_gov.nist.fdcc.xp_value_AuditAccountLogonEvents"> … <xccdf:ident system="http://cce.mitre.org">CCE-3867-0</xccdf:ident> … </xccdf:Rule>

See Sec. 4.5.1 for information on the meaning of a “pass/fail” rule result relating to each of the identifier types in Table 17. All rules that contain CCE, CPE, or CVE entries in their <xccdf:ident> elements SHALL obey these meanings. As a result, such <xccdf:ident> elements SHALL only be included if the recommendation is identical to these associated meanings or if they have a @con:negate attribute (as described in Sec. 4.5.1) set to comply with the intended meaning (by default, @con:negate is set to false). In SCAP, an <xccdf:ident> element is not simply a reference to related material — it is a declaration of exact alignment with the described meanings.

An <xccdf:ident> element referencing a CVE, CCE, or CPE identifier SHALL be ordered before other <xccdf:ident> elements referencing non-SCAP identifiers. Identifiers from previous revisions of CCE or CPE MAY also be specified following the SCAP identifiers.

The following requirements and recommendations apply to the <xccdf:check> element:

This version of SCAP supports the use of only OVAL and/or OCIL-checking systems in SCAP-conformant content. Use of these checking systems SHALL be restricted as follows:

OPTIONAL. If present, it SHALL reference an OCIL questionnaire in the designated OCIL source data stream component. Otherwise, see Sec. 4.5.2 for information on the use of the @multi-check attribute. v. All requirements in Appendix B of NIST Interagency Report (IR) 7692, Specifications for the Open Checklist Interactive Language (OCIL) Version 2.0 [OCIL], SHALL be followed.

A checking system that is not supported by SCAP MAY be used in XCCDF content. There is no guarantee that an SCAP implementation will be capable of processing any additional checking system data used in this content. To ensure interoperability, SCAP has standardized the use of OVAL and OCIL-checking systems. Content containing the use of checking systems other than the OVAL and OCIL-checking systems SHALL NOT be considered well-formed with regard to SCAP.

An OVAL source data stream component MAY be used to represent a series of checks to verify that patches have been installed. Historically, an XCCDF convention has been used to identify such a reference. An XCCDF benchmark MAY include a patches up-to-date rule that SHALL reference an OVAL source data stream component.

When implementing a patches up-to-date XCCDF rule that checks for patches via numerous OVAL patch class definitions, the following approach SHALL be used:

Use of this approach allows for the individual OVAL patch definitions to be easily identified along with the XCCDF rule checking whether patches are up to date.

The following example of a patches up-to-date rule references numerous OVAL patch class definitions:

<xccdf:Rule id="xccdf_gov.nist.usgcb.win_rule_security_patches_up_to_date" selected="true"> <xccdf:title>Security Patches Up-To-Date</xccdf:title> <xccdf:description>Keep systems up to current patch levels</xccdf:description> <xccdf:check system="http://oval.mitre.org/XMLSchema/oval-definitions-5" multi-check="true"> <xccdf:check-content-ref href="scap-windows-patches"/> </xccdf:check> </xccdf:Rule>

When implementing a patches up-to-date XCCDF rule that checks for patches via a single OVAL patch class definition, the following approach SHALL be used:

Use of a single OVAL patch definition provides for easier content maintenance and makes it easy to identify both the XCCDF rule and the patch class definition used for checking whether patches are up to date.

Here is a patches up-to-date rule example that references a single OVAL patch class definition:

<xccdf:Rule id="xccdf_gov.nist.usgcb.win_rule_security_patches_up_to_date" selected="true"> <xccdf:title>Security Patches Up-To-Date</xccdf:title> <xccdf:description>Keep systems up to current patch levels</xccdf:description> <xccdf:check system="http://oval.mitre.org/XMLSchema/oval-definitions-5" multi-check="false"> <xccdf:check-content-ref href="scap-windows-patches" name="oval:gov.nist.usgcb.win.patch:def:10101"/> </xccdf:check> </xccdf:Rule>

SCAP 1.0 required the inclusion of static CVSS scores in XCCDF vulnerability-related rules. However, CVSS base scores sometimes change over time (e.g., when more information is available about a particular vulnerability), and CVSS temporal and environmental scores are intended to change to reflect current threats, security controls, and other factors. As a result, the practice of embedding CVSS scores in XCCDF content was no longer required starting with SCAP 1.1.

During scoring, current CVSS scores acquired dynamically, such as from a data feed, SHOULD be used in place of the @weight attribute within XCCDF vulnerability-related rules. Section 3.8 contains additional requirements for CVSS usage.

CCSS scores are more stable than CVSS scores, but they still may change over time. Accordingly, during scoring, current CCSS scores acquired dynamically, such as from a data feed, MAY be used in place of the @weight attribute within XCCDF configuration setting-related rules. Section 3.9 contains additional requirements for CCSS usage.

For both the CVSS and CCSS cases, this specification encourages the use of data feeds that can be updated over time. The specifics around scoring provided in this and referenced sections are intended to prevent potential misuse of the XCCDF @weight attribute within an SCAP data stream.

SCAP 1.4 supports CVSS v3.1 and CVSS v4.0 as defined in [CVSS-3.1] and [CVSS-4.0] respectively, and continues to recognize CVSS v3.0 [CVSS-3.0] and CVSS v2.0 [CVSS-2.0] as legacy versions for pre-existing vulnerability data only. When more than one CVSS score is available for a given vulnerability from an authoritative source (such as the NIST National Vulnerability Database CVE feed referenced in Sec. 3.7), SCAP-conformant products SHOULD apply the version-precedence rule defined in Sec. 3.8 - that is, products SHOULD prefer a CVSS v4.0 score over a CVSS v3.1 score, SHOULD prefer a CVSS v3.1 score over a CVSS v3.0 score, and SHOULD prefer a CVSS v3.0 score over a CVSS v2.0 score. This further supports the use of updatable data feeds to provide current CVSS information. As acknowledged in prior revisions of this specification, XCCDF does not provide a means to indicate which CVSS version was used when calculating an XCCDF score; this is a recognized weakness in the XCCDF specification. As a result, tool developers are encouraged not to rely solely on the scoring information embedded in an SCAP checklist for downstream risk decisions, and SHOULD instead recompute or revalidate CVSS scores against the latest authoritative source at evaluation time.

Use of the <xccdf:source>, <xccdf:complex-value>, and <xccdf:complex-default> elements within the <xccdf:Value> element SHALL NOT be allowed. Within the <xccdf:choices> element of the <xccdf:Value> element, use of the <xccdf:complex-choice> element SHALL NOT be allowed. Use of complex values is disallowed because the behavior for mapping XCCDF complex values to OVAL variables is not defined.

One or more <xccdf:check-export> elements MAY be used to define the binding of <xccdf:Value> elements to OVAL variables. The format of the <xccdf:check-export> element is:

<xccdf:check-export value-id="XCCDF_Value_id" export-name="OVAL_External_Variable_id"/>

The following <xccdf:check> element example demonstrates the use of this convention:

<xccdf:check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> <xccdf:check-export value-id="xccdf_gov.nist.fdcc.xp_value_NoSlowLink" export-name="oval:gov.nist.fdcc.xp:var:66711"/> <xccdf:check-export value-id="xccdf_gov.nist.fdcc.xp_value_NoBackgroundPolicy" export-name="oval:gov.nist.fdcc.xp:var:66712"/> <xccdf:check-export value-id="xccdf_gov.nist.fdcc.xp_value_NoGPOListChanges" export-name="oval:gov.nist.fdcc.xp:var:66713"/> <xccdf:check-content-ref href="fdcc-winxp-oval.xml" name="oval:gov.nist.fdcc.xp:def:6671"/> </xccdf:check>

The type and value binding of the specified <xccdf:Value> is constrained to match the lexical representation of the indicated OVAL Variable data type. Table 18 summarizes the constraints regarding data type usage.

Table 18. XCCDF-OVAL data export matching constraints

Additional information regarding OVAL data types can be found in the OVAL language documentation and the XCCDF specification [XCCDF]. Additional information on OVAL data types may also be added to Sec. 4 of the SCAP 1.4 annex document [SP800-126A].

The XCCDF group extension SHALL NOT be allowed.

This section lists requirements and recommendations for using the Open Vulnerability and Assessment Language (OVAL) to express an OVAL component of an SCAP source data stream (see Table 14).⁹ Because SCAP 1.4 supports the use of multiple OVAL source data stream components, an SCAP content creator could choose to divide the OVAL definitions into multiple components. For example, a content creator could create one OVAL source data stream component that contains a set of OVAL definitions for one OVAL version (e.g., 5.10.1) and another set of OVAL definitions for a newer OVAL version (e.g., 5.12) if both versions are valid according to SCAP 1.4 requirements. SCAP 1.4 also supports multiple types of OVAL definitions within a single OVAL source data stream component. For example, a benchmark could reference OVAL compliance and vulnerability definitions contained in a single data stream component.

The version of any particular OVAL document instance SHALL be specified using the <oval:schema_version> content element of the <oval:generator> element, as in this example:

<oval:generator> <oval:product_name>The OVAL Repository</oval:product_name> <oval:schema_version>5.12</oval:schema_version> </oval:generator>

The versions that are specified using the <oval:schema_version> content element SHALL correspond to the versions specified by the @xsi:schemaLocation attribute value for the OVAL schema if an @xsi:schemaLocation attribute is specified.

Some OVAL interpreters make use of the OVAL variable format to allow variable values to be passed to the OVAL interpreter. While the OVAL variable format is not part of an SCAP data stream, this format can be used to carry variable information as part of an SCAP product for non-SCAP-related purposes.

If an <oval-var:oval_variables> element is used to carry variable values between an XCCDF processor and an OVAL processor, the <oval:schema_version> of the <oval-var:oval_variables> element SHALL be the same as that of the <oval-def:oval_definitions> element whose external variables are bound by the <oval-var:oval_variables> element.

Required values for the @class attribute of an OVAL definition are as follows:

The following requirements apply to particular classes of OVAL definitions:

<oval-def:reference source="http://cce.mitre.org" ref_id="CCE_identifier"/>

The source attribute SHALL be defined using either “http://cce.mitre.org” (preferred method) or “CCE.”

b. Definitions that are directly or indirectly extended SHALL be limited to inventory and compliance classes.

<oval-def:reference source="http://cpe.mitre.org" ref_id="CPE_identifier"/>

The source attribute SHALL be defined using either “http://cpe.mitre.org” (preferred method) or “CPE.”

b. Definitions that are directly or indirectly extended SHALL be limited to the inventory class.

<oval-def:reference source="www.microsoft.com/Patch" ref_id="KB912919"/>

<oval-def:reference source="http://cve.mitre.org" ref_id="CVE_identifier"/>

This recommendation is weaker than its counterparts for the other class definition types because a CVE identifier is not an identifier for a patch; it is more of an association. For example, one patch could fix multiple vulnerabilities, so it would map to multiple CVE identifiers.

The source attribute SHALL be defined using either “http://cve.mitre.org” (preferred method) or “CVE.”

c. Definitions that are directly or indirectly extended SHALL be limited to inventory and patch classes.

<oval-def:reference source="http://cve.mitre.org" ref_id="CVE_identifier"/>

The source attribute SHALL be defined using either “http://cve.mitre.org” (preferred method) or “CVE.”

b. Definitions that are directly or indirectly extended SHALL be limited to inventory and vulnerability classes.

This section lists recommendations for using the Open Checklist Interactive Language (OCIL) to express an OCIL component of an SCAP source data stream (see Table 14).

OCIL content SHOULD be used to check rules that cannot be fully automated with OVAL. For example, a particular software product may not have an application programming interface (API) that supports OVAL use. Another example is performing a check that requires user interaction, such as asking the user to look up information within a management console or to report a serial number affixed to a computing device. OCIL can also be used to collect a user’s own information, such as whether the user participated in a recent security training session.

If an <ocil:questionnaire> element maps to one or more CCE, CVE, and/or CPE identifiers, it SHOULD include <ocil:reference> elements that reference those identifiers using the corresponding following format:

<ocil:reference href="http://cce.mitre.org">CCE_identifier</ocil:reference>

<ocil:reference href="http://cve.mitre.org">CVE_identifier</ocil:reference>

<ocil:reference href="http://cpe.mitre.org">CPE_identifier</ocil:reference>

This section lists requirements and recommendations for using Common Platform Enumeration (CPE) to express a CPE component of an SCAP source data stream (see Table 14).

The Official CPE Dictionary data feed¹⁰ MAY be used by SCAP components to reference CPE names. If use of the Official CPE Dictionary is impractical, a subset of the dictionary MAY be used instead. Creating the reduced official dictionary involves first identifying every CPE in <xccdf:platform> and <cpe2:fact-ref> elements contained within referenced <cpe2:platform-specification> elements in every benchmark in the data stream. These CPEs SHALL then be matched against every entry in the Official CPE Dictionary using the CPE name matching algorithm [CPE-M]. All CPEs matched in the official dictionary with a result of EQUAL or SUPERSET SHALL be included in the reduced official dictionary.

One or more third-party dictionaries MAY be included in a data stream as well. All such third-party dictionaries SHOULD follow the requirements of the CPE Dictionary specification [CPE-D]. If including an entire third-party dictionary is impractical, a subset of the dictionary MAY be used instead. The reduced dictionary SHALL be created using the same procedure outlined for creating a subset of the official dictionary. In all cases, a dictionary component MAY be remote to the data stream collection.

Each CPE name [CPE-N] in an <xccdf:platform> or <cpe2:fact-ref> element within an XCCDF document SHALL match at least one CPE entry in a dictionary referenced by the data stream. A match is considered an EQUAL or SUPERSET result when matching the CPE name to a dictionary entry, as defined in the CPE Name Matching specification [CPE-M]. Only non-deprecated names SHOULD be used. Checklist authors SHOULD ensure that each CPE name [CPE-N] they specify in an <xccdf:platform> or <cpe2:fact-ref> element within an XCCDF document has a check associated with its CPE name. If a corresponding check does not exist, then it will not be possible to fully detect the presence of the product and determine platform applicability.

[CPE-D] provides the defining structure of a CPE dictionary. A <cpe2_dict:cpe-item> element MAY contain one or more <cpe2-dict:check> elements that reference OVAL inventory class definitions. The referenced OVAL inventory class definition SHALL specify the technical procedure for determining whether or not a specific target asset is an instance of the CPE name specified by the <cpe2_dict:cpe-item> element. This usage is encouraged for CPE components. If a <cpe2_dict:cpe-item> element contained in a CPE component references an OVAL inventory class definition, then that definition SHALL be resolved by an @href attribute that references an OVAL source data stream component in the same data stream.

Because there may be a lag between when a new product is available and when the Official CPE Dictionary is updated to include a CPE name for that product, third-party dictionaries may be needed to compensate. When creating a subset of the Official CPE Dictionary or a third-party dictionary, a <cpe2_dict:check> element on an entry MAY be added or modified if the existing check does not provide satisfactory content to test the presence of the CPE name.

To maintain consistency and accuracy, SCAP content that references a configuration setting SHALL use the official CCE identifier if a CCE entry for a particular configuration setting exists in the official CCE list. If no CCE entry exists for the configuration setting of interest, the content author SHOULD seek to have a CCE identifier issued for the configuration setting. See the OVAL compliance class definition requirements in Sec. 3.3 and the <xccdf:ident> requirements in Sec. 3.2.4.1 for additional requirements regarding CCE identifier references. The current official CCE list is available at https://ncp.nist.gov/cce, and new CCEs can be requested from NIST via email at cce@nist.gov.

Use of an official, dynamic data feed is preferred over the static coding of CCE-related supporting information in SCAP data sources. For example, NVD provides a data feed¹¹ that is the authoritative mapping between CCE identifiers and the control identifiers defined in SP 800-53. Embedding control identifiers within SCAP content is strongly discouraged due to the maintenance burden that it imposes on content maintainers when the control identifiers are revised. A preferred technique is to only embed CCE identifiers in SCAP content. When mappings to SP 800-53 control identifiers are needed, dynamically acquire them from the official data feed, and associate them with the SCAP content based on its embedded CCE identifiers.

CVE references in SCAP content MAY use any CVE identifier in any non-deprecated state recognized by the CVE Program, including identifiers in the RESERVED state and identifiers in the PUBLISHED state. CVE identifiers in the REJECTED state, and any other deprecated CVE identifiers, SHALL NOT be used.

If a CVE identifier exists for a particular vulnerability, the official CVE identifier SHALL be used. If no CVE exists for the software flaw, an alternate identifier MAY be used, but the content author SHOULD seek to have a CVE identifier issued for the vulnerability. Information on submitting unpublished vulnerabilities and obtaining CVE identifiers is available at https://cve.org.

NIST provides public access to current CVE data - including descriptions, CVSS metrics, CPE applicability statements, and weakness (CWE) mappings - through two complementary mechanisms maintained by the National Vulnerability Database (NVD). Both mechanisms emit data conforming to the same JSON 2.0 schema, available at https://csrc.nist.gov/schema/nvd/api/2.0/cve_api_json_2.0.schema.

CVSS metric fields. The CVE record returned by both the API and the JSON 2.0 feeds carries CVSS metric data in version-specific fields. The field names are ‘cvssMetricV2’ (for CVSS v2.0; the absence of a minor-version digit in this field name is a known irregularity in the NVD schema relative to the v3.x and v4.0 fields), ‘cvssMetricV30’ (CVSS v3.0), ‘cvssMetricV31’ (CVSS v3.1), and ‘cvssMetricV40’ (CVSS v4.0). Sect. 3.8 specifies the SCAP 1.4 version-precedence rule under which SCAP-conformant tools select among these fields when more than one is populated for the same CVE.

The NIST CVE data feed (see Sec. 3.7) is one source of CVSS base scores and vector data that MAY be used by SCAP-conformant products to support additional use cases built on SCAP, and MAY be used along with Threat, Temporal, Environmental, or Supplemental scores and vectors obtained from other authoritative sources.

SCAP 1.4 recognizes four CVSS versions, organized into two tiers:

Current versions (for new SCAP content):

Legacy versions (for pre-existing data only):

SCAP-conformant products SHALL identify the source CVSS version from the vector-string prefix where available - ‘CVSS:4.0/’, ‘CVSS:3.1/’, or ‘CVSS:3.0/’ - and SHALL NOT silently relabel a vector under a different version. Vectors lacking a ‘CVSS:’ prefix SHALL be treated as CVSS v2.0.

When more than one CVSS vector is available for the same vulnerability, SCAP-conformant products SHOULD select the version with the highest major number first, breaking ties on minor number. The resulting precedence is:

Products SHOULD record, alongside any CVSS score they emit, the CVSS version, the vector string, and the source (e.g., the NVD CVE feed entry identifier) so that downstream consumers can rederive or recompute the score against the authoritative source.

Products consuming CVSS v4.0 data SHOULD support the four metric groups defined by [CVSS-4.0] - Base, Threat, Environmental, and Supplemental - and SHOULD preserve any nomenclature qualifier (CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE) reported by the source. Products consuming CVSS v3.1 or v3.0 data SHOULD support the three metric groups defined by [CVSS-3.1] / [CVSS-3.0] - Base, Temporal, and Environmental. Products consuming CVSS v2.0 data SHOULD support the three metric groups defined by [CVSS-2.0] - Base, Temporal, and Environmental.

As noted in sect. 3.2.4.4, XCCDF does not provide a means to indicate which CVSS version was used when calculating an XCCDF score. SCAP-conformant tools that emit XCCDF results SHOULD therefore record the CVSS version and vector for each rule out-of-band (for example, in the corresponding ARF report or in tool-specific extensions) so that the version is recoverable by downstream consumers. This limitation is preserved from prior SCAP revisions and is not resolved by SCAP 1.4.

CCSS base, temporal, and environmental scores and vectors MAY be used by products. Adopters should consider CCSS data in the context of organizational security policies and dependencies among vulnerabilities. See [CCSS] for additional information.

Digitally signing source data streams helps ensure the integrity and trustworthiness of legitimate content by preventing unauthorized content from being processed. Leveraging the TMSAD specification [TMSAD] for SCAP improves the legitimacy of authoritative content. Content authors SHOULD digitally sign SCAP source data stream collections in accordance with [TMSAD] and the requirements provided in this section.

If a digital signature is included in a source data stream collection, it SHALL be placed as the last element within the source data stream collection root element.

Each digital signature SHALL be represented as a <ds:Signature> element and SHALL conform to the W3C XML Signature Syntax and Processing recommendation [DSIG]. The “ds” prefix is used in this section for clarity; any equivalent prefix bound to the XMLDSIG namespace MAY be used.

The <ds:Signature> element SHALL follow the recommendations in [TMSAD] and the following additional requirements:

a) Each <ds:Signature> SHALL cover exactly one target:

1) The source data stream collection root element

or

2) A single data stream.

b) If the <ds:Signature> element targets the source data stream collection root element, the <ds:SignedInfo> element contained within SHALL contain exactly one <ds:Reference>. The <ds:Reference> SHALL have a target URI of one of the following:

1) If the URI is an empty string otherwise represented as “”, the URI target SHALL be considered to refer to the source data stream collection root element.

2) If the URI is a defined ID, then it SHALL be a same-document reference (e.g., #id) that resolves to the source data stream collection root element.

c) If the <ds:Signature> element targets a single data stream, then the <ds:SignedInfo> element SHALL contain a same-document reference (e.g., #id) that resolves to the data stream collection being signed along with either:

1) A set of same-document references (e.g., #id) that resolve to each local component referenced by the data stream being signed

or

2) A same-document reference (e.g., #id) that resolves to a <ds:Manifest> element contained within the <ds:Signature> as a <ds:Object> element. The referenced <ds:Manifest> element SHALL have a <ds:Reference> element for each local component referenced by the data stream being signed. External components MAY be omitted from the <ds:Manifest> element. Each <ds:Reference> element referencing a <ds:component> or <ds:extended-component> SHALL point to the component being signed by identifying the component in the @URI attribute using “#” and the @Id of the component.

Cryptographic key information SHOULD be provided in the <ds:Signature> element through use of the <ds:KeyInfo> sub-element.

For example:

<scap-ds:source-data-stream-collection xml:id="sds-1" ...> <!-- data-streams and components --> <ds:Signature Id="sig-sds-1"> <ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-

exc-c14n#"/>

<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-

more#rsa-sha256"/>

<ds:Reference URI=""> <ds:Transforms> <ds:Transform

Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

</ds:Transforms> <ds:DigestMethod

Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <ds:DigestValue>...</ds:DigestValue>

</ds:Reference> </ds:SignedInfo> <ds:SignatureValue>...</ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>...</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </ds:Signature>

</scap-ds:source-data-stream-collection>

This section defines the processing requirements that SCAP content consumers SHOULD follow to correctly process SCAP 1.4 content. This section also provides recommendations that content producers and consumers are encouraged to adopt to promote stronger interoperability and greater consistency.

Content consumers that support SCAP 1.4 may be interested in supporting earlier version of SCAP (i.e., SCAP 1.3) if there is little difference between the two content streams.¹² Content consumers that process legacy SCAP content SHOULD be capable of outputting results in the current SCAP revision. Additionally, content consumers MAY output results in the same SCAP version as the source content. For producers of results in legacy formats, legacy results MAY also be converted into results based on the current SCAP revision.

Certain constructs can be deprecated in the SCAP component specifications.¹³ SCAP content consumers SHOULD support deprecated constructs unless specifically noted in the annex because they are still valid in SCAP 1.4 and supported legacy SCAP versions. This recommendation ensures that legacy SCAP content that uses these deprecated constructs will continue to be supported.

Content consumers that support OVAL SHOULD support OVAL definition documents written against all versions of OVAL component specifications listed in the annex.

Content consumers SHALL be capable of validating SCAP content against the appropriate schemas and Schematron stylesheets, detecting and reporting errors, and failing gracefully if there are errors. The relevant XML schemas and Schematron rule sets are available at https://csrc.nist.gov/Projects/security-content-automation-protocol/scap-releases/scap-1-4. See Sec. 3.1 for additional information on the Schematron rule sets.

Content consumers SHOULD validate XML digital signatures if they exist in the content. Validating a signature includes confirming that the signature value is valid, all of the reference hashes in the signature and manifest are correct, and the public key used to verify the signature is from a trusted source. A data stream with a signature that does not validate SHOULD NOT be evaluated by a content consumer.

When a <ds:extended-component> that is not recognized by the tool is referenced from a <ds:data-stream>, <ds:component>, or <ds:extended-component> element, the tool SHALL issue a warning.

If more than one <ds:data-stream> element is specified on the <ds:data-stream-collection>, the ID of the <ds:data-stream> to execute SHALL be indicated to the content consumer, and the content consumer SHALL use the specified <ds:data-stream>. If more than one <xccdf:Benchmark> is referenced by a <ds:data-stream>, the ID of the <xccdf:Benchmark> to execute SHALL be indicated to the content consumer, and the content consumer SHALL process the indicated <xccdf:Benchmark>. Because SCAP and its component specifications do not formally define how to designate a particular data stream or benchmark, it is expected that products will implement these capabilities in a proprietary way.

The following requirements and recommendations pertain to content consumers processing XCCDF benchmark and tailoring components from an SCAP source data stream.

CPEs referenced in an <xccdf:platform> element directly or by a <cpe2:fact-ref> contained within a referenced <cpe2:platform-specification> element SHALL be evaluated as follows to determine their presence on a machine:

If an XCCDF component has multiple <xccdf:check-content-ref> elements, then check processing SHOULD be performed according to [XCCDF:7.2.3.5.1] with the following changes:

Content consumers SHOULD implement checking systems that are supported by SCAP, as defined in Sec. 3.2.4.2. Content consumers MAY implement checking systems that are not supported by SCAP. If a tool encounters a checking system it does not support, it SHOULD issue a warning, and it SHOULD continue processing according to the [XCCDF] specification.

An SCAP result data stream contains the results of the evaluation of one or more SCAP source data streams by an SCAP content consumer. The following requirements and recommendations pertain to content consumers that generate SCAP result data streams.

An SCAP result data stream SHALL conform to the [ARF] specification. The following sections outline the details of the ARF report. In all situations, one or more component results (e.g., XCCDF, check results), the target asset, and/or the SCAP source data stream collection represented as a report request in ARF MAY be represented either as a local component in the ARF or as a remote resource, leveraging the remote resource capability built into ARF. The following is a stripped down ARF example:

<arf:asset-report-collection> <rc:relationships>

<rc:relationship type="arf-rel:isAbout" subject="xccdf1"> <rc:ref>asset1</rc:ref> </rc:relationship> <rc:relationship type="arf-rel:isAbout" subject="oval1"> <rc:ref>asset1</rc:ref> </rc:relationship> <rc:relationship type="scap-rel:checkContext" subject="oval1"> <rc:ref>xccdf1</rc:ref> </rc:relationship> <rc:relationship type="scap-rel:fromSource" subject="xccdf1"> <rc:ref>collection1</rc:ref> </rc:relationship> <rc:relationship type="scap-rel:fromSource" subject="oval1"> <rc:ref>collection1</rc:ref> </rc:relationship> </rc:relationships> <arf:report-requests> <arf:report-request id="collection1"> <arf:content> <ds:data-stream-collection>…</ds:data-stream-collection>

</arf:content> </arf:report-request> </arf:report-requests>

<arf:assets> <arf:asset id="asset1">

<ai:computing-device>…</ai:computing-device> </arf:asset>

</arf:assets> <arf:reports> <arf:report id="xccdf1"> <arf:content>

<xccdf:TestResult>…</xccdf:TestResult> </arf:content>

</arf:report> <arf:report id="oval1"> <arf:content>

<oval-res:oval_results>…</oval-res:oval_results> </arf:content>

</arf:report> </arf:reports> </arf:asset-report-collection>

The ARF report SHALL contain a report object for each XCCDF, OVAL, and OCIL component executed when a source data stream is evaluated against a target. It MAY contain additional report objects for other results, such as <oval-var:oval_variables> or extended component results. Each component result SHALL be captured as a separate <arf:report> element in the <arf:asset-report-collection> element.¹⁴ When reporting on XCCDF, OVAL, or OCIL, each component report SHALL use the element specified in Table 19 as its root element.

Table 19. SCAP result data stream component document elements

SCAP result data stream components SHOULD NOT use any deprecated constructs in their associated specifications. Validation of each component SHALL be done in accordance with the portions of this document that define requirements for the component. See Sec. 3.1.2 for more information on the SCAP Content Validation Tool, which can help validate the correctness of SCAP result data streams.

The target asset SHALL be represented in the ARF report using the <ai:assets> part of ARF. The <ai:asset> element populated about a target asset SHOULD include the fields specified in Table 20, where applicable.

Table 20. Asset identification fields to populate

Additional identification information MAY be captured in the <ai:asset> element (e.g., asset tag, system GUID). The guidelines specified in [AI] SHALL be followed when populating the asset identification information. Currently, only the target asset of the SCAP evaluation is identified.

The source data stream collection that was used to generate the results against the target SHOULD be included in the ARF report as an <arf:report-request>. If the source data stream collection is included in the ARF report, and an <xccdf:Tailoring> component was used during processing, the tailoring component SHALL be included as well. The following is a stripped-down example:

<arf:asset-report-collection> <arf:report-requests>

<arf:report-request id="request_0"> <arf:content>

<ds:data-stream-collection id="..." <!-- Source data stream collection which was tailored --> ... </ds:data-stream-collection> </arf:content>

</arf:report-request>

<arf:report-request id="request_1"> <arf:content>

<ds:data-stream-collection id="..." <!-- Source data stream collection with an <xccdf:Tailoring>

component -->

... </ds:data-stream-collection>

</arf:content> </arf:report-request> </arf:report-requests> <arf:assets>...</arf:assets> <arf:reports>...</arf:reports>

</arf:asset-report-collection>

Table 21 outlines the relationships that SHALL be specified in the ARF report if the stated condition is satisfied.

Table 21. ARF relationships

Figure 3 gives an example of how the resulting ARF report would look.

Fig. 3. Sample ARF report structure

The following requirements and recommendations pertain to content consumers that generate XCCDF result data stream components.

Each XCCDF result data stream component SHALL comply with the XCCDF Results schema.

XCCDF test results SHALL be documented as the contents of an <xccdf:TestResult> element. To be considered valid SCAP result content, the <xccdf:TestResult> element SHALL meet the following conditions:

Table 22. XCCDF fact descriptions

The following is a stripped-down example that illustrates the above requirements:

<arf:asset-report-collection> <rc:relationships>...</rc:relationships> <arf:report-requests>...</arf:report-requests> <arf:assets>...</arf:assets> <arf:reports>

<arf:report id="scap_gov.nist_comp_r3005-xccdf_01">

<arf:content>

<xccdf:TestResult start-time="2016-03-10T10:07:11" version="1-2.1.0.0" test-system="cpe:/a:vendor:product_name:version" end-time="2016-03-10T10:07:11" id="xccdf_gov.nist_testresult_...">

<xccdf:benchmark

href="file:r3005-ds-01.xml#scap_gov.nist_comp_r3005-xccdf_01" id="xccdf_gov.nist_benchmark_r3005_id_01"/>

<xccdf:tailoring-file href="#scap_gov.nist_comp_r3005-xccdf_tailoring_03" id="xccdf_gov.nist_tailoring_r3005_03" time="2016-01-22T14:00:00" version="1-2.1.0.0"/>

<xccdf:organization>...</xccdf:organization> <xccdf:identity

privileged="true" authenticated="true"> ...

</xccdf:identity> <xccdf:profile

idref="xccdf_gov.nist.val_profile_r3005_tailoring_03"/>

<xccdf:target>...</xccdf:target> <xccdf:target-address>...</xccdf:target-address> <xccdf:target-facts>...</xccdf:target-facts> <xccdf:target-id-ref

system="http://scap.nist.gov/schema/asset-identification/1.1" href="" name="..."

/> <xccdf:set-value

idref="xccdf_gov.nist_value_val.r3005_for_rule_6">test0</>

... <xccdf:rule-result

time="2016-03-10T10:07:11" idref="xccdf_gov.nist_rule_val.r3005_rule_1" weight="10" severity="medium" role="full"> <xccdf:result>pass</xccdf:result> <xccdf:check system="http://oval.mitre.org/XMLSchema/oval-definitions-5" selector="sel1"> <xccdf:check-content-ref href="#scap_gov.nist_comp_r3005-oval" name="oval:nist.validation.r3005:def:2"/> </xccdf:check>

</xccdf:rule-result> </xccdf:TestResult>

</arf:content> </arf:report>

<arf:report id="scap_gov.nist_comp_r3005-oval">

<arf:content>

<arf:oval-res:oval_results>...</oval-res:oval_results>

</arf:content>

</arf:report>

</arf:reports>

</arf:asset-report-collection>

The <xccdf:rule-result> element provides data that indicates the result of assessing a system using the identified <xccdf:Rule> element. If the target <xccdf:Rule> identified by the <xccdf:rule-result> element’s @idref attribute has one or more <xccdf:ident> elements with a @system attribute value listed in Sec. 3.2.4.1, then each <xccdf:ident> element SHALL also appear within the <xccdf:rule-result> element.

If the <xccdf:ident> element is included, it is important for tracking purposes that produced XCCDF results have specific meanings. If an <xccdf:ident> element is present, and it identifies a CVE, CCE, or CPE entry, then an <xccdf:rule-result> of “pass” SHALL indicate that the check content evaluated within the rule complied with one of the following:

These interpretations of <xccdf:ident> elements must be preserved. For example, consider two policy recommendations. One is that a particular piece of software be installed, and the second is that another piece of software should not be installed. Both rules for these policy recommendations could use the same CPE entry in their <xccdf:ident> elements. However, because the interpretation of a CPE entry is that a “pass” result indicates that software was installed, the second policy recommendation’s rule would violate this. This can be corrected by using the @con:negate attribute, which is a Boolean attribute that inverts the rule result. The second rule could check for the software being installed and then negate that result, thus giving a result that is consistent in meaning with the first rule. For rules that cannot have their interpretations preserved through the use of the @con:negate attribute, an alternative is to have a CCE entry correspond to the recommendation. Rules that do not use <xccdf:ident> elements have no such restrictions.

When evaluating an <xccdf:Rule> element that references an OVAL definition, the <xccdf:rule-result> element SHALL be used to capture the result of this evaluation. This result SHALL be determined by evaluating the referenced OVAL definition on a target host. The resulting value of an individual <xccdf:check> SHALL be mapped from the OVAL definition result produced during evaluation. The corresponding <xccdf:rule-result/xccdf:result> value is then computed based on the result values of all relevant <xccdf:check> elements.¹⁵ While the OVAL specification permits limiting result status reporting, SCAP-conformant content SHALL provide full status reporting, including error, unknown, not applicable, not evaluated, true, and false.

Content consumers SHALL apply the mapping illustrated in Table 23 when deriving <xccdf:check> results from OVAL definition processing.

Table 23. Deriving XCCDF check results from OVAL definition results

The corresponding result value SHALL be recorded based on the @class attribute of the OVAL definition and the @negate attribute of the <xccdf:check> element, where applicable.

The mappings in Table 23 are specific to each OVAL definition class. For example, if an OVAL compliance class definition is processed, and OVAL returns a result of “true,” the content consumer is conveying the fact that the system was found to be compliant with that check and therefore returns a “pass” result for that check. A similar definition for a vulnerable condition will return results of “false” if that vulnerability was not found on the examined devices, resulting in a “pass” from the XCCDF check. Negations of check results or their combination in complex checks may result in additional modification before the final corresponding <xccdf:rule-result/xccdf:result> value is known.

If the <xccdf:Rule> element under evaluation has an <xccdf:check-content-ref> element with the @name attribute omitted and an <xccdf:check> element with its @multi-check attribute set to “true,” then the result of each evaluated OVAL definition SHALL be recorded as a separate <xccdf:rule-result> element. In this case, the <xccdf:rule-result>/<xccdf:check-content-ref> element SHALL identify the specific check result of each evaluated OVAL definition using the @href and @name attributes, as described in Sec. 4.5, item 8.

According to [XCCDF:Table 9;Table 35;Table 39], if the <xccdf:Rule> element under evaluation is selected, and its @role attribute is set to ”unchecked,” then the rule result SHALL be set to “notchecked.” If the <xccdf:Rule> element under evaluation is selected, and its @role attribute is set to “unscored,” then the rule result SHALL be set to “informational.”

The following requirements and recommendations pertain to content consumers that generate OVAL result data stream components. See the annex for additional requirements and recommendations.

Each OVAL result data stream component SHALL validate against at least one version of the OVAL results schema that corresponds to an OVAL component specification version that was specified in Sect. 2 of the annex, regardless of the version of the OVAL definitions document that was evaluated.

An SCAP OVAL result data stream component SHALL include the results of every OVAL definition used to generate the reported results.

In order to be SCAP-conformant, an SCAP content consumer SHALL be able to produce all types of OVAL result outputs described below. The specific result output SHALL be configurable within the SCAP content consumer.

In order to support SCAP instances where OVAL thin content (i.e., only the ID of the definition and the results) is preferred, SCAP content consumers SHALL support all valid values for the <oval-res:directives> that control the expected content of the results file.

To support the ability for results to be consumed by appropriate products, data results SHALL be expressed as a single machine without system characteristics, single machine with system characteristics, or single machine with thin results as follows:

For this format, the values for the <oval-res:directives> element SHALL be:

<oval-res:directives include_source_definitions="false"> <oval-res:definition_true content="full" reported="true"/> <oval-res:definition_false content="full" reported="true"/> <oval-res:definition_unknown content="full" reported="true"/> <oval-res:definition_error content="full" reported="true"/> <oval-res:definition_not_evaluated content="full" reported="true"/> <oval-res:definition_not_applicable content="full" reported="true"/> </oval-res:directives>

When creating the OVAL system characteristics, as defined by the <oval-sc:oval_system_characteristics> element, the <oval-sc:collected_objects> and <oval-sc:system_data> elements SHALL NOT be provided.

For this format, the values for the <oval-res:directives> element SHALL be:

<oval-res:directives include_source_definitions="false"> <oval-res:definition_true content="full" reported="true"/> <oval-res:definition_false content="full" reported="true"/> <oval-res:definition_unknown content="full" reported="true"/> <oval-res:definition_error content="full" reported="true"/> <oval-res:definition_not_evaluated content="full" reported="true"/> <oval-res:definition_not_applicable content="full" reported="true"/> </oval-res:directives>

When creating the OVAL system characteristics, as defined by the <oval-sc:oval_system_characteristics> element, the <oval-sc:collected_objects> and <oval-sc:system_data> elements SHALL be provided.

For this format, the values for the <oval-res:directives> element SHALL be:

<oval-res:directives include_source_definitions="false"> <oval-res:definition_true content="thin" reported="true"/> <oval-res:definition_false content="thin" reported="true"/> <oval-res:definition_unknown content="thin" reported="true"/> <oval-res:definition_error content="thin" reported="true"/> <oval-res:definition_not_evaluated content="thin" reported="true"/> <oval-res:definition_not_applicable content="thin" reported="true"/> </oval-res:directives> When specifying OVAL system characteristics, a reference SHOULD be made to the target asset in the ARF report collection. Specifically, the <oval-sc:oval_system_characteristics>/<oval-sc:system_info> SHOULD be populated with a <con:asset-identification> element. That element SHALL be populated with a single <arf:object-ref> element that points to the <ai:asset> element in the ARF report collection pertaining to the OVAL result. See [ARF] for details on populating the <arf:object-ref> element.

When specifying OVAL system characteristics, a reference SHOULD be made to the target asset in the ARF report collection. Specifically, the <oval-sc:oval_system_characteristics>/<oval-sc:system_info> SHOULD be populated with a <con:asset-identification> element. That element SHALL be populated with a single <arf:object-ref> element that points to the <ai:asset> element in the ARF report collection pertaining to the OVAL result. See [ARF] for details on populating the <arf:object-ref> element.

The following requirements and recommendations pertain to content consumers that generate OCIL result data stream components.

An SCAP OCIL result data stream component SHALL include the results of every <ocil:questionnaire>, <ocil:question_test_action>, and <ocil:question> element used to generate the reported results.

Digitally signing SCAP result content is important for establishing integrity and provenance and for enabling content consumers to make trust decisions in accordance with [TMSAD]. Content consumers SHOULD digitally sign SCAP result content in accordance with [TMSAD] and the requirements in this section.

If a digital signature is included within a source data stream collection, it SHALL be placed in an <arf:extended-info> element within the ARF report.

Each digital signature SHALL be represented as a <ds:Signature> element and SHALL conform to the W3C XML Signature Syntax and Processing recommendation [DSIG]. The “ds” prefix is used in this section for clarity; any equivalent prefix bound to the XMLDSIG namespace MAY be used.

The <ds:Signature> element SHALL follow the recommendations in [TMSAD] along with the following additional requirements.

a) The <ds:Signature> SHALL cover exactly one target: the <arf:asset-report-collection> element (i.e., the ARF report).

b) The first <ds:Reference> element in a <ds:Signature> element SHALL be to the <arf:asset-report-collection> element. The element SHALL be referenced in the @URI attribute using the empty string convention “”.

c) Two XPath Filter 2 transforms SHALL exist on the first <dsig:Reference> element in a <dsig:Signature> element. Both SHALL specify a filter type of “subtract.” The first transform SHALL specify the XPath /arf:asset-report-collection/arf:extended-infos[count(arf:extended-info[dsig:Signature]) = count(*)]. The second transform SHALL specify the XPath /arf:asset-report-collection/arf:extended-infos/arf:extended-info[dsig:Signature]. In both cases, the namespace prefix “arf” SHALL map to the ARF namespace specified in this document.

d) The second <dsig:Reference> element MAY be to the <dsig:SignatureProperties> element captured in a <dsig:Object> element with the <dsig:Signature> element. The <dsig:SignatureProperties> element SHALL be referenced in the @URI attribute using “#” and the @Id of the <dsig:SignatureProperties> element.

Key information SHOULD be provided on the <dsig:Signature> element.

If countersigning the result is desired (e.g., a system signs automatically, and a human reviewer later adds a signature), the following SHALL apply:

a) The <arf:extended-info> element that contains the original signature SHALL be removed from the resulting document.

b) The original signature SHALL be captured as a <dsig:Object> element on the new <dsig:Signature> element.

c) The first <dsig:Reference> element in the new <dsig:Signature> element SHALL reference the <dsig:Object> element that contains the original signature. The <dsig:Object> element SHALL be referenced in the @URI attribute using “#” and the @Id of the <dsig:Object> element.

d) If the <dsig:SignatureProperties> element existed within the original signature, the second <dsig:Reference> element SHALL be to the <dsig:SignatureProperties> element captured in a <dsig:Object> element with the <dsig:Signature> element. The <dsig:SignatureProperties> element SHALL be referenced in the @URI attribute using “#” and the @Id of the <dsig:SignatureProperties> element.

e) A <dsig:SignatureProperties> element MAY be included in the <dsig:Signature> element. At least one <dsig:SignatureProperty> element MAY be populated with <dt:signature-info>, as specified in [TMSAD].

f) Key information SHOULD be provided on the <dsig:Signature> element in accordance with [TMSAD].

g) The new <dsig:Signature> element SHALL be placed in a new <arf:extended-info> element in the ARF report collection.

A signature that has countersigned another signature (also known as an enveloping signature) MAY be countersigned. When doing so, the requirements above SHALL apply to the new signature creation.

This section discusses additional requirements for the following SCAP-conformant content use cases: compliance checking, vulnerability scanning, and inventory scanning. As stated in Table 3, each data stream is required to have a @use-case attribute in its <ds:data-stream> element with a value that corresponds to either one of the content types defined in this section or to “OTHER” for data streams that do not correspond to a defined use case. The required value for each content type is specified in the following subsection.

Each use case is subject to the requirements presented in this section as well as all applicable requirements in Sec. 3 and 4.

SCAP content can be used to compare system characteristics and settings against an SCAP-conformant checklist in an automated fashion. This can verify that operating systems and applications comply with security checklists and identify any deviations from those checklists.

The SCAP source data stream component that SHALL be included for compliance checking is the XCCDF benchmark, which expresses the checklist. Each rule in the XCCDF benchmark SHALL reference one of the following:

Each XCCDF benchmark SHALL have at least one rule that references either an OVAL compliance class definition in an OVAL component or an OCIL questionnaire in an OCIL component.

All OVAL components and OCIL components referenced by the XCCDF benchmark SHALL be included in the SCAP source data stream.

If the XCCDF benchmark component references any CPE names, then the SCAP source data stream SHALL include a CPE component, which specifies the products or platforms of interest, and SHALL include one or more OVAL inventory class definitions in an OVAL component that contain the technical procedures for determining whether or not a specific target asset has a product or platform of interest.

The @use-case attribute in the <ds:data-stream> element SHALL be set to “CONFIGURATION.”

SCAP content can be used to scan operating systems and applications to look for known software flaws that introduce security exposures. The content enables the consistent detection and reporting of these flaws.

The SCAP source data stream component that SHALL be included for vulnerability scanning is the XCCDF benchmark, which expresses the checklist of the flaws to be checked for. Each rule in the XCCDF benchmark SHALL reference one of the following:

Each XCCDF benchmark SHALL have at least one rule that references either an OVAL vulnerability class definition in an OVAL component or an OCIL questionnaire in an OCIL component.

All OVAL components and OCIL components referenced by the XCCDF benchmark SHALL be included in the SCAP source data stream.

If the XCCDF benchmark component references any CPE names, then the SCAP source data stream SHALL include a CPE component, which specifies the products or platforms of interest, and SHALL include one or more OVAL inventory class definitions in an OVAL component that contain the technical procedures for determining whether or not a specific target asset has a product or platform of interest.

The @use-case attribute in the <ds:data-stream> element SHALL be set to “VULNERABILITY.”

SCAP content can be used to collect information on the software installed on systems. One example of how this could be used is to verify that a group of systems all have required security software programs installed. This could help verify compliance with technical security control requirements. Another example is to collect software inventory data on devices that are not directly connected to the enterprise network, such as smart phones.

Inventory scanning can also be applied to collect information on the presence of software artifacts on systems, such as malware or characteristics of malware that indicate its presence. SCAP content authored for this purpose can be used to detect classes or categories of malware based on system states that may be common across multiple malware instances. For example, it is a common practice to reuse malware code while making modifications to address available detection methods or change propagation characteristics. It is also possible to author content that detects a specific instantiation of malware. For example, the hashing of files can be used to identify a malicious executable or library.

The SCAP source data stream component that SHALL be included for inventory scanning is the XCCDF benchmark, which references the inventory checks and captures the results. Each rule in the XCCDF benchmark SHALL reference one of the following:

The @use-case attribute in the <ds:data-stream> element SHALL be set to “INVENTORY.”

Appendix A. Security Considerations

Major security considerations for this version of SCAP include the following:

Appendix B. List of Symbols, Abbreviations, and Acronyms

Selected acronyms and abbreviations used in the guide are defined below.

AI Asset Identification

API Application Programming Interface

ARF Asset Reporting Format

CCE Common Configuration Enumeration

CCSS Common Configuration Scoring System

CPE Common Platform Enumeration

CVE Common Vulnerabilities and Exposures

CVSS Common Vulnerability Scoring System

DHS Department of Homeland Security

DoD Department of Defense

DSIG Digital Signature

FISMA Federal Information Security Modernization Act

IR Interagency Report

IT Information Technology

ITL Information Technology Laboratory

NIST National Institute of Standards and Technology

NVD National Vulnerability Database

OASIS Organization for the Advancement of Structured Information Standards

OCIL Open Checklist Interactive Language

OMB Office of Management and Budget

OS Operating System

OVAL Open Vulnerability and Assessment Language

PCI Payment Card Industry

RFC Request for Comments

SCAP Security Content Automation Protocol

SP Special Publication

TMSAD Trust Model for Security Automation Data

URI Uniform Resource Identifier

URL Uniform Resource Locator

XCCDF Extensible Configuration Checklist Description Format

XML Extensible Markup Language

This appendix contains definitions for selected terms used within the document.

component schema — The schema for an SCAP component specification (e.g. XCCDF, CPE, CVSS). Within this document, this term is distinct from “OVAL component schema,” which is defined by the OVAL specification.

component specification — One of the individual specifications that comprises SCAP.

content consumer — A product that accepts existing SCAP source data stream content, processes it, and produces SCAP result data streams

content producer — A product that generates SCAP source data stream content.

globally unique identifier — An identifier formatted following special conventions to support uniqueness within an organization and across all organizations creating identifiers. See Sec. 3.1.3 for the conventions.

result content — Part or all of one or more SCAP result data streams.

Security Content Automation Protocol (SCAP) A suite of specifications that standardize the format and nomenclature by which software flaw and security configuration information is communicated to machines and humans.

SCAP component A logical unit of data expressed using one or more of the SCAP component specifications.

SCAP-conformant A product or SCAP data stream that meets the requirements of this specification.

SCAP content Part or all of one or more SCAP data streams.

SCAP data stream A specific instantiation of SCAP content.

SCAP data stream collection A container for SCAP data streams and components.

SCAP result data stream An SCAP data stream that holds output (result) content.

SCAP source data stream An SCAP data stream that holds input (source) content.

SCAP source data stream collection A container for SCAP data streams and components.

SCAP use case — A pre-defined way in which a product can use SCAP. See Sec. 5 for the definitions of the SCAP use cases.

source content — Part or all of SCAP source data streams.

stream component — A major element of a data stream, such as an XCCDF benchmark or a set of OVAL definitions.

well-formed — An SCAP-conformant data stream or stream component.

Appendix D. Normative References

This appendix provides normative references to the specifications that are required to implement the SCAP 1.4 components. See the annex for normative references to the XML and Schematron schema locations related to these specifications.

Table 24 lists the normative references to specifications.

Table 24. Specification locations