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

Special Publication 800-126 Revision 2

NIST Special Publication 800-126 Revision 2

Recommendations of the National Institute of Standards and Technology

David Waltermire

Stephen Quinn

Karen Scarfone

Adam Halbardier

Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930

September 2011

U.S. Department of Commerce

Rebecca M. Blank, Acting Secretary

National Institute of Standards and Technology

Patrick D. Gallagher, Under Secretary for Standards and Technology and Director

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 analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations.

National Institute of Standards and Technology Special Publication 800-126, Revision 2 58 pages (Sep. 2011)

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

原本PDFの抜粋画像

The authors, David Waltermire and Stephen Quinn of the National Institute of Standards and Technology (NIST) Karen Scarfone of Scarfone Cybersecurity, and Adam Halbardier of Booz Allen Hamilton wish to thank their colleagues who reviewed drafts of this document and contributed to its technical content.

The authors would like to acknowledge the following contributors for their keen and insightful assistance with developing the current and previous versions of this specification: John Banghart, Harold Booth, Paul Cichonski, and Blair Heiserman of NIST; Christopher Johnson of HP Enterprise Services; Paul Bartock of the National Security Agency (NSA); Jeff Ito, Matt Kerr, Shane Shaffer, and Greg Witte of G2, Inc.; Andy Bove of SecureAcuity; Jim Ronayne of Varen Technologies; Kent Landfield of McAfee, Inc.; Christopher McCormick, Rhonda Farrell, Angela Orebaugh, and Victoria Thompson of Booz Allen Hamilton; Alan Peltzman of the Defense Information Systems Agency (DISA); and Jon Baker, Drew Buttner, Maria Casipe, and Charles Schmidt of the MITRE Corporation.

Trademark Information

OVAL and CVE are registered trademarks, and CCE, CPE, and OCIL are trademarks, of The MITRE Corporation.

Windows XP and Windows Server 2003 are registered trademarks of Microsoft Corporation.

All other registered trademarks or trademarks belong to their respective organizations.

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.¹ SCAP is a multi-purpose framework of specifications that support automated configuration, vulnerability and patch checking, technical control compliance activities, and security measurement. Goals for the development of SCAP include standardizing system security management, promoting interoperability of security products, and fostering the use of standard expressions of security content.

SCAP version 1.2 is comprised of eleven component specifications in five categories:

SCAP utilizes software flaw and security configuration standard reference data. This reference data is provided by the National Vulnerability Database (NVD),² which is managed by NIST and sponsored by the Department of Homeland Security (DHS).

This publication defines the technical composition of SCAP version 1.2 in terms of its component specifications, their interrelationships and interoperation, and the requirements for SCAP content. The technical specification for SCAP in this publication describes the requirements and conventions that are to be employed to ensure the consistent and accurate exchange of SCAP-conformant content and the ability to reliably use the content with SCAP-conformant products.

The U.S. Federal Government, in cooperation with academia and private industry, is adopting SCAP and encourages its use in support of security automation activities and initiatives.³ SCAP has achieved widespread adoption by major software manufacturers and has become a significant component of large information security management and governance programs. The protocol is expected to evolve and expand in support of the growing needs to define and measure effective security controls, assess and monitor ongoing aspects of that information security, and successfully manage systems in accordance with risk management frameworks such as NIST Special Publication 800-534, Department of Defense (DoD) Instruction 8500.2, and the Payment Card Industry (PCI) framework.

By detailing the specific and appropriate usage of the SCAP 1.2 components and their interoperability, NIST encourages the creation of reliable and pervasive SCAP content and the development of a wide array of products that leverage SCAP.

Organizations that develop SCAP 1.2-based content or products should comply with the following recommendations:

Organizations should ensure that their implementation and use of SCAP 1.2 is compliant with the requirements detailed in each component specification and this document.

If requirements are in conflict between component specifications, this document will provide clarification. If a component specification is in conflict with this document, the requirements in this document take precedence.

Security products and checklist authors assemble content from SCAP data repositories to create SCAP-conformant security guidance. For example, a security configuration checklist can document desired security configuration settings, installed patches, and other system security elements using a standardized SCAP format. Such a checklist would use XCCDF to describe the checklist, CCE to identify security configuration settings to be addressed or assessed, and CPE to identify platforms for which the checklist is valid. The use of CCE and CPE entries within XCCDF checklists is an example of an SCAP convention—a requirement for valid SCAP usage. These conventions are considered part of the definition of SCAP 1.2. Organizations producing SCAP content should adhere to these conventions to ensure the highest degree of interoperability. NIST provides an SCAP Content Validation Tool that organizations can use to help validate the correctness of their SCAP content. The tool checks that SCAP source and result content is well-formed, all cross references are valid, and required values are appropriately set.⁵

The National Institute of Standards and Technology (NIST) developed this document in furtherance of its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347.

NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets; but such standards and guidelines shall not apply to national security systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), “Securing Agency Information Systems,” as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in A-130, Appendix III.

This guideline has been prepared for use by Federal agencies. It may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright, though attribution is desired.

Nothing in this document should be taken to contradict 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 document provides the definitive technical specification for version 1.2 of the Security Content Automation Protocol (SCAP). SCAP (pronounced ess-cap) consists of a suite of specifications for standardizing the format and nomenclature by which software flaw and security configuration information is communicated, both to machines and humans. This document defines requirements for creating and processing SCAP source content. These requirements build on the requirements defined within the individual SCAP component specifications. Each new requirement pertains either to using multiple component specifications together or to further constraining one of the individual component specifications. The requirements within the individual component specifications are not repeated in this document; see those specifications to view their requirements.

The scope of this document is limited to SCAP version 1.2. Other versions of SCAP and its component specifications, including emerging specifications, are not addressed here. Future versions of SCAP will be defined in distinct revisions of this document, each clearly labeled with a document revision number and the appropriate SCAP version number. SCAP revisions are managed through a coordinated process defined within the SCAP Release Cycle.⁶ The release cycle workflow manages changes related to SCAP specifications and validation processes including the addition of new specifications or updates to existing specifications. This process encourages community involvement, promotes transparency and awareness regarding proposed changes, and affords ample lead time to prepare for pending changes.

This document is intended for three primary audiences:

This document assumes that readers already have general knowledge of SCAP and reasonable familiarity with the SCAP component specifications that their content, products, or services use. Individuals without this level of knowledge who would like to learn more about SCAP should consult NIST Special Publication (SP) 800-117, Guide to Adopting and Using the Security Content Automation Protocol.⁷

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

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in Request for Comment (RFC) 2119 [RFC2119]. When these words appear in regular case, such as “should” or “may”, they are not intended to be interpreted as RFC 2119 key words.

When a single term within a sentence is italicized, this indicates that the term is being defined. These terms and their definitions also appear 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 the 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>.

The general convention used when describing XML attributes within this document is to reference the attribute as well as its associated element including the namespace alias, employing the general form "@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 (freely replaceable) content by the use of an italic font. Square brackets ‘[]’ are used to designate optional content. Thus "[Oval_inventory_definition_id]" designates optional parametric 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

The component specifications included in SCAP 1.2 are as follows:

• Reporting formats
o Asset Reporting Format (ARF) 1.1, a format for expressing the transport format of information about assets and the relationships between assets and reports [ARF]
o Asset Identification 1.1, a format for uniquely identifying assets based on known identifiers and/or known information about the assets [AI]

• Enumerations
o Common Platform Enumeration (CPE) 2.3, a nomenclature and dictionary of hardware, operating systems, and applications [CPE]
o Common Configuration Enumeration (CCE) 5, a nomenclature and dictionary of software security configurations [CCE]
o Common Vulnerabilities and Exposures (CVE), a nomenclature and dictionary of security-related software flaws⁹ [CVE]

• Measurement and scoring systems
o Common Vulnerability Scoring System (CVSS) 2.0, a system for measuring the relative severity of software flaw vulnerabilities [CVSS]
o Common Configuration Scoring System (CCSS) 1.0, a system for measuring the relative severity of system security configuration issues [CCSS]

All references to these specifications within this document are to the version numbers listed above unless otherwise explicitly specified.

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, such as an XCCDF benchmark or 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, which are defined in Section 5 of this document, 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 for performing 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.2 specification. Such products and source content are referred to as SCAP conformant. Most of the requirements listed in this section reference other sections in the document that fully define the requirements.

If requirements are in conflict between component specifications, this document will provide clarification. If a component specification is in conflict with this document, the requirements in this document SHALL take precedence. If requirements are in conflict between this document and the errata for this document, the errata SHALL take precedence.

There are two types of SCAP-conformant products: content producers and content consumers. Content producers are products that generate SCAP source data stream content, while content consumers are products that accept existing SCAP source data stream content, process it, and produce SCAP result data streams. Products claiming conformance with the SCAP 1.2 specification SHALL comply with the following requirements:

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

This section defines the SCAP 1.2 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 section discusses SCAP source data streams only; SCAP result data streams are discussed in Section 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. See http://scap.nist.gov/revision/1.2/#example for a sample of an SCAP source data stream collection and its sections. 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 in the components section 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 grouping of related or similar source data streams. For example, NIST currently distributes the United States Government Configuration Baseline (USGCB)¹⁰ as a series of SCAP bundles. Source data streams that are similar or related (e.g., Microsoft Windows 7 content and Microsoft Windows 7 Firewall content) may be bundled into the same source data stream collection. Figure 1 shows the relationship between data stream collections, data streams, and components.

Figure 1 - SCAP Data Stream Collection

In Figure 1, data stream1 points to xccdf1, xccdf2, oval1, oval3, cpe dict1, and cpe dict2. data stream2 points to xccdf2, oval2, oval3, and cpe dict2. Each data stream is a collection of links to the components that they reference; each logical link encapsulates the information required to allow the content consumer to connect the components together within the data stream. 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 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.

Figure 2 - SCAP Data Stream

In Figure 2, the data stream links to three components. The OVAL component does not reference out to external content, so there are no mappings captured for it. The XCCDF and CPE Dictionary components reference other components (e.g., oval1). When referencing components within the example data stream, a mapping indicates that when xccdf1 references “sample-oval.xml”, the content is found through the link to the component identified as “oval1”. Similarly, when the cpe dict1 component references “dict-oval.xml” the component reference is resolved through the link to the component identified as “oval1”. 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 following is a stripped down example of the source data stream. The details are covered later in this specification.

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 MUST be interpreted as follows:

• The “Properties” field is broken into four subfields:
o The “Name” column indicates the name of a property that MAY, SHOULD, or MUST be included in the described element, in accordance with the cardinality indicated in the “Count” column and any [RFC2119] requirement words in the “Property Definition” column.
o The “Type” column indicates the REQUIRED data type for the value of the property. There are two categories of types: literal and element. A literal type indicates the type of literal as defined in [XMLS]. An element type references the name of another element that ultimately defines that property.
o The “Count” column indicates the cardinality of the property within the element. The property MUST be included in the element in accordance with the cardinality. If a range is given, and “n” is the upper bound of the range, then the upper limit SHALL be unbounded.
o The “Property Definition” column defines the property in the context of the element. The definition MAY contain key words as indicated in [RFC2119].

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 – ds:component

Table 11 – ds:extended-component

The SCAP source data stream collection SHALL validate against the XML schema representation for the source data stream, as well as all Schematron rules embedded within that schema. 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 http://scap.nist.gov/revision/1.2/#schema. See Table 22 in Appendix C for a list of SCAP component schema and Schematron file locations.

Each SCAP source data stream component SHALL use one of the elements specified in Table 12 as its document element. Each SCAP source data stream component SHOULD NOT use any constructs that are deprecated in its associated specification. While Section 4.1 requires that products support deprecated constructs, these constructs should be avoided to minimize the impact to content use when these constructs are removed from future revisions of the associated specifications. Any component in a data stream collection SHALL be referenced not more than once by any data stream in that collection.

Table 12 - SCAP Source Data Stream Component Document Elements

NIST provides an SCAP Content Validation Tool, which is designed to help validate the correctness of SCAP data streams.¹² The SCAP Content Validation Tool is a command-line tool that will check that SCAP source and result content is well-formed, cross references are valid, and required values are appropriately set. Errors and warnings are returned in both XML and Hypertext Markup Language (HTML) formats. Validation of each SCAP source data stream component SHALL be done in accordance with the portions of this document that define requirements for the associated component specification.

If applicable, each component MUST validate against its associated Schematron stylesheet. For the SCAP source data stream collection, it MUST 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 files for the SCAP specification and its applicable component specifications are located at http://scap.nist.gov/revision/1.2/#schematron. Source content SHOULD pass all Schematron assertions in the Schematron rule files. When creating source content, failed assertions with a “warning” 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” flag MUST be disregarded.

The Schematron rule sets are interpretations of the specifications, and the implementations of their rules are subject to change. Whenever a change is made to a Schematron file, the SCAP errata document will be updated and the new Schematron file will be posted. The latest Schematron file 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. Also, for the component specifications, the Schematron file on the SCAP website SHALL be used in place of any corresponding Schematron file available elsewhere. For example, a particular specification may have an official Schematron file available on a different website. In most cases, the copy on the SCAP website will be the same, but if issues in a Schematron file are discovered, the SCAP website may address these before the individual specification’s maintainers do.

The elements listed in Table 13 have special conventions around the format of their identifiers (@id attribute). Authors MUST follow these conventions because they preserve the global uniqueness of the resulting identifiers. In Table 13, 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 MUST be an NCName-compliant string [XMLS].

Table 13 – Element Identifier Format Convention

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 12). 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 the selection of 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 14 - Use of Dublin Core Terms in <xccdf:metadata>

As stated in the XCCDF specification, the use of an <xccdf:Profile> element is not required. SCAP content commonly includes <xccdf:Profile> elements, so people tend to assume that they are required, but they are optional.

Use of the <xccdf:set-complex-value> element within the <xccdf:Profile> element SHALL NOT be allowed.

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

Each <xccdf:Rule> element SHALL include an <xccdf:ident> element containing a CVE, CCE, or CPE identifier reference if an appropriate identifier exists. The meaning of the identifier MUST be consistent with the recommendation implemented by the <xccdf:Rule> element. If the rule references an OVAL Definition, then <xccdf:ident> element content SHALL match the corresponding CVE, CCE, or CPE identifier found in the associated OVAL Definition(s) 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 MUST have a purpose consistent with one of the rows in Table 15. 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 15. Also, if the <xccdf:Rule> element references an OVAL Definition, it SHALL reference an OVAL Definition of the specified class.

Table 15 – <xccdf:Rule> and <xccdf:ident> Element Values

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 Section 4.5.1 for information on the meaning of a “pass/fail” rule result relating to each of the identifier types in Table 15. All rules that contain CCE, CPE, or CVE entries in their <xccdf:ident> elements MUST obey these meanings. As a result, such <xccdf:ident> elements MUST only be included either if the recommendation is identical to these associated meanings or if they have a @con:negate attribute (as described in Section 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 OVAL and OCIL check systems. Use of these check systems SHALL be restricted as follows:

iv. Use of the @name attribute in the <xccdf:check-content-ref> element is OPTIONAL. If present, it MUST reference an OCIL questionnaire in the designated OCIL source data stream component, otherwise see Section 4.5.2 for information on use of the @multi-check attribute.
v. Follow the additional requirements in Appendix B of NIST Interagency Report (IR) 7692, Specifications for the Open Checklist Interactive Language (OCIL) Version 2.0 [OCIL].
If a check system that is not supported by SCAP is used in XCCDF content, this content SHALL NOT be considered well-formed with regards 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 MUST reference an OVAL source data stream component. When implementing a patches up-to-date XCCDF rule, the following approach SHALL be used:

Here is a patches up-to-date rule example:

<xccdf:Rule id="xccdf_gov.nist.fdcc.xp_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-win2000-patches.xml"/> </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, such as 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. 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.

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.

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 that lexical representation of the indicated OVAL Variable data type. Table 16 summarizes the constraints regarding data type usage. Additional information regarding OVAL and XCCDF data types can be found in the OVAL Common Schema documentation¹³ and the XCCDF specification [XCCDF].

Table 16 - XCCDF-OVAL Data Export Matching Constraints

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 12).

While the default version¹⁴ of OVAL used in SCAP 1.2 SHALL be OVAL version 5.10, SCAP content SHOULD utilize the earliest SCAP-supported version of OVAL that includes all required tests and is necessary to properly address the SCAP content’s purpose or use case. This approach, often referred to as the “least version principle”, allows SCAP content to remain viable over a longer period of time by enabling the broadest support within products, while reducing the content maintenance burden that would be required to maintain revisions of content for multiple specification versions. The minimum supported OVAL version for SCAP 1.2 SHALL be OVAL version 5.3.

Because SCAP 1.2 supports the use of multiple OVAL source data stream components, an SCAP content creator could choose to divide the OVAL Definitions into multiple components based on the “least version” of each definition. For example, if some OVAL Definitions only required OVAL 5.3 while others required OVAL 5.10, then the content creator could create one OVAL source data stream component for the OVAL 5.3 definitions and another for the OVAL 5.10 definitions. SCAP 1.2 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.10</oval:schema_version> </oval:generator>

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”.

a. If an OVAL inventory class definition maps to one or more CPE identifiers, the definition SHOULD include <oval-def:reference> elements that reference those identifiers using the following format:

<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”.

a. If an OVAL patch class definition is associated with a source specific identifier (for example, Knowledge Base numbers for Microsoft patches), these identifiers SHOULD be included in <oval-def:reference> elements contained by the definition. For example:

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

b. If an OVAL patch class definition maps to one or more CVE identifiers, the definition MAY include <oval-def:reference> elements that reference those identifiers using the following format:

<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”.

a. If an OVAL vulnerability class definition maps to one or more CVE identifiers, the definition SHOULD include <oval-def:reference> elements that reference those identifiers using the following format:

<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”.

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 12).

OCIL content SHOULD be used for checking 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 12).

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. Then these CPEs MUST 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 MUST 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 MUST 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. Because there may be a lag between the time that a new product is available and the Official CPE Dictionary is updated to include a CPE name for that product, third-party dictionaries would need to be used to compensate for the lag.

[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 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>

For example:

<cpe2_dict:cpe-list xmlns="http://cpe.mitre.org/dictionary/2.0" xmlns:cpe2_dict="http://cpe.mitre.org/dictionary/2.0"> <cpe2_dict:cpe-item name="cpe:/a:sun:java_system_messaging_server:6.2:-:sparc"> <cpe2_dict:title>Sun Java System Messaging Server 6.2 sparc</title> <cpe2_dict:check system=http://oval.mitre.org/XMLSchema/oval-definitions-5 href="example-sunjavamsg62-oval.xml">oval:org.mitre.oval:def:128 </cpe2_dict:check> <cpe2-dict-ext:cpe23-item name="cpe:2.3:a:sun:java_system_messaging_server:6.2:-:-:-:-:-:sparc:-"/> </cpe2_dict:cpe-item> </cpe2_dict:cpe-list>

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.

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.

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 referencing an OVAL source data stream component in the same data stream.

To maintain consistency and accuracy, SCAP content referencing 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 Section 3.3 and the <xccdf:ident> requirements in Section 3.2.4.1 for additional requirements involving CCE identifier references.

The current official CCE list is available at http://cce.mitre.org/lists/cce_list.html and new CCEs can be requested from the CCE Content Team. Submitters should review the information provided at http://cce.mitre.org/lists/creation_process.html regarding CCE core concepts and design constraints before submitting proposals for new CCE entries. Use of an official, dynamic data feed is preferred to 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 NIST 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 embed only the CCE identifiers within SCAP content; when mappings to NIST SP 800-53 control identifiers are needed, dynamically acquire them from the official data feed and associate them to the SCAP content based on its embedded CCE identifiers.

CVE references in SCAP content MAY include both “candidate” and “entry” status identifiers. 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 user SHOULD seek to have a CVE identifier issued for the vulnerability. The process for submitting unpublished vulnerabilities and obtaining CVE identifiers is available at http://cve.mitre.org/cve/obtain_id.html.

NIST provides a CVE data feed to support dynamic and current vulnerability information and associated metadata (e.g., CVSS values). The current schema is available at http://nvd.nist.gov/download.cfm.

The NIST CVE data feed, discussed in Section 3.7, is one source of CVSS base score and vector data that MAY be used by products to support additional use cases built on SCAP usage. In support of these additional use cases, CVSS base scores and vectors from this data feed MAY be used by products along with temporal and environmental scores and vectors from other sources.

CCSS base, temporal, and environmental scores and vectors MAY be used by products. Adopters of CCSS should be aware that it has significant differences from CVSS. Unlike CVSS data, which can be used by itself to aid in prioritizing vulnerability remediation efforts, CCSS data is not directly useful in the same way. Instead, CCSS data needs to be considered in the context of each organization’s security policies and in the context of dependencies among vulnerabilities. See [CCSS] for additional information.

Digitally signing source data streams is important to ensuring the integrity and trustworthiness of legitimate content, while preventing rogue content from being executed. Leveraging the Trust Model for Security Automation Data (TMSAD) specification [TMSAD] for SCAP can improve the legitimacy of authoritative content and create a more secure environment. As such, content authors MAY digitally sign source content following the guidelines in [TMSAD], along with the following requirements.

One or more XML digital signatures MAY be included as the last elements in the SCAP source data stream collection root element. Each signature MUST be represented as a <dsig:Signature> element and follow the W3C recommendation [DSIG]. Each <dsig:Signature> element MUST sign only one data stream.

The <dsig:Signature> element MUST follow the recommendations in [TMSAD] and these additional requirements:

This section defines the processing requirements that SCAP content consumers MUST follow in order to correctly process SCAP 1.2 content. This section also provides recommendations that are not mandatory; organizations are encouraged to adopt them to promote stronger interoperability and greater consistency. The topics covered in the first part of this section are legacy support, source data streams, and XCCDF processing. The end of the section covers result-related topics: SCAP result data streams, XCCDF results, OVAL results, OCIL results, and result data stream signing.

Content consumers supporting SCAP 1.2 SHALL process SCAP 1.2 content and SCAP 1.0 content. Content consumers SHALL process SCAP content as defined under the corresponding version of NIST SP 800-126 (for SCAP 1.2, this revision; for SCAP 1.0, the original release).¹⁷ Content consumers that process legacy SCAP content MUST be capable of outputting results in the same SCAP version as the source content, and MAY convert the legacy SCAP results into SCAP 1.2 results.

Within the SCAP component specifications, certain constructs may be deprecated.¹⁸ SCAP content consumers MUST support all deprecated constructs because they are still valid. This requirement ensures that legacy content that made use of these deprecated constructs continues to be supported.

Content consumers supporting OVAL SHALL support OVAL Definition documents written against OVAL versions 5.3, 5.4, 5.5, 5.6, 5.7, 5.8, 5.9, and 5.10.

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 are located at http://scap.nist.gov/revision/1.2/#schema, and the relevant Schematron rule sets at http://scap.nist.gov/revision/1.2/#schematron. See Section 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.

Whenever 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 MUST be indicated to the content consumer, and the content consumer MUST 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 MUST be indicated to the content consumer, and the content consumer MUST process the indicated <xccdf:Benchmark>. Because SCAP and its component specifications do not formally define how to designate a particular data stream, benchmark, etc. in these cases, 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 SHALL be performed according to [XCCDF:7.2.3.5.1] with the following changes:

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

When processing a patches-up-to-date rule, only OVAL patch class definitions SHALL be evaluated; all other classes of definitions (e.g., inventory class definitions) SHALL NOT be evaluated except when they serve, directly or indirectly, as criteria (extended definitions) of patch definitions.

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 generating 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. This 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> <xccdf-res:oval-results>…</xccdf-res:oval-results> </arf:content> </arf:report> </arf:reports> </arf:asset-report-collection>

The ARF report MUST 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 MUST be captured as a separate <arf:report> element in the <arf:asset-report-collection> element, and when reporting on XCCDF, OVAL or OCIL, each component report SHALL use the element specified in Table 17 as its root element.

Table 17 - SCAP Result Data Stream Component Document Elements

Each SCAP result data stream component SHOULD NOT use any constructs that are deprecated in its associated specification. Validation of each component SHALL be done in accordance with the portions of this document that define requirements for the component. See Section 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 MUST 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 18, where applicable.

Table 18 – Asset Identification Fields to Populate

Additional identification information MAY be captured in the <ai:asset> element (asset tag, system GUID, etc.) The guidelines specified in [AI] MUST 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>.

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

Table 19 – ARF Relationships

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

Figure 3 – Sample ARF Report Structure

The following requirements and recommendations pertain to content consumers generating 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:

<arf:asset-report-collection> <rc:relationships>...</rc:relationships> <arf:report-requests>...</arf:report-requests> <arf:assets>...</arf:assets> <arf:reports> <arf:report id="xccdf1"> <arf:content> <xccdf:TestResult> <xccdf:rule-result> <xccdf:check> <xccdf:check-content-ref href="#oval1" name="oval:gov.nist:def:2"/> </xccdf:check> </xccdf:rule-result> </xccdf:TestResult> </arf:content> </arf:report> <arf:report id="oval1"> <arf:content> <arf:xccdf-res:oval-results>...</xccdf-res:oval-results> </arf:content> </arf:report> </arf:reports> </arf:asset-report-collection>

Table 20 - XCCDF Fact Descriptions

The <xccdf:rule-result> element provides data indicating 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 Section 3.2.4.1, then each <xccdf:ident> element SHALL also appear within the <xccdf:rule-result> element.

Here is an example for a CVE entry:

<xccdf:rule-result idref="java-upgrade-278" weight="10.0"> <xccdf:result>pass</xccdf:result> … <xccdf:ident system="http://cve.mitre.org">CVE-2006-0614</xccdf:ident> … </xccdf:rule-result>

If the <xccdf:ident> element is included, for tracking purposes it is important 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:

• For a CPE entry, the target platform was identified on the system.

It is important that these interpretations of <xccdf:ident> elements be preserved. For example, consider two policy recommendations. One is that a particular piece of software be installed, and the second that another piece of software 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 software was installed, the second policy recommendation’s rule would violate this. This can be corrected by using the @con:negate attribute, 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 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 corresponding 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 result 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. (Normally only a single <xccdf:check> element is needed, but where an <xccdf:complex-check> element is used, there may be multiple results that must be combined, as outlined in the XCCDF specification.) While the OVAL specification permits limiting result status reporting, SCAP-conformant content SHALL include full status reporting, including Error, Unknown, Not Applicable, Not Evaluated, True, and False.

Content consumers SHALL apply the mapping illustrated in Table 21 when deriving <xccdf:check> results from OVAL Definition processing. The corresponding result value SHALL be recorded based on the @class attribute of the OVAL Definition where applicable.

Table 21 - Deriving XCCDF Check Results from OVAL Definition Results

The mappings in Table 21 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 Section 4.5, item 8.

The following requirements and recommendations pertain to content consumers generating OVAL result data stream components.

Each OVAL result data stream component SHALL validate against version 5.10 of the OVAL Results schema¹⁹ 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 the types of OVAL Results output described below. The specific result output SHALL be configurable within the SCAP content consumer.

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

To support the ability for results to be consumed by the appropriate product(s), data results SHALL be expressed as 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>/##any SHOULD be populated with a <con:asset-identification> element. That element MUST 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 generating 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 result data stream content is important to ensuring the integrity and trustworthiness of results. Leveraging [TMSAD] for SCAP can improve the legitimacy of results of SCAP content and create a more secure environment. As such, content consumers MAY digitally sign result content following the guidelines in [TMSAD], along with the following requirements.

One XML digital signature MAY be included in an <arf:extended-info> element in the ARF report. The signature MUST be represented as a <dsig:Signature> element and MUST follow the W3C recommendation [DSIG]. The <dsig:Signature> element MUST sign the ARF report collection root element.

The <dsig:Signature> element MUST follow the recommendations in [TMSAD] and these additional requirements:

In situations where it is desirable to countersign a result data stream (e.g., when a content consumer automatically signs a result data stream and then a person also wants to sign the results), the following requirements apply.

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.

When signing a result data stream, the source data stream collection SHOULD be captured in the ARF report being signed.

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

Each use case is subject not only to the requirements presented in this section, but also to all applicable requirements in Sections 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 MUST 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 MUST include a CPE component, which specifies the products or platforms of interest, and MUST 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 MUST 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 consistent detection and reporting of these flaws.

The SCAP source data stream component that MUST 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 MUST include a CPE component, which specifies the products or platforms of interest, and MUST 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 MUST 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 state that may be common across multiple malware instances. For example, it is a common practice to reuse malware code, making modifications to address available detection methods, change propagation characteristics, etc. It is also possible to author content that detects a specific instantiation of malware. For example, hashing of files can be used to identify a malicious executable or library.

The SCAP source data stream component that MUST 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 MUST be set to “INVENTORY”.

Appendix A—Security Considerations

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

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

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

FISMA — Federal Information Security Management Act

IR — Interagency Report

IT — Information Technology

ITL — Information Technology Laboratory

NIST — National Institute of Standards and Technology

NVD — National Vulnerability Database

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 — Service Pack

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 Section 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, both 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 Section 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.

The following normative references are pointers to the specifications, schema, dictionaries, and other information that are required to implement the SCAP 1.2 components:

[AI] Asset Identification http://scap.nist.gov/revision/1.2/#ai

[ARF] ARF http://scap.nist.gov/revision/1.2/#arf

[CCE] CCE http://scap.nist.gov/revision/1.2/#cce

[CCSS] CCSS http://scap.nist.gov/revision/1.2/#ccss

[CPE] CPE http://scap.nist.gov/revision/1.2/#cpe

[CPE-D] CPE Dictionary http://scap.nist.gov/specifications/cpe/#dictionary

[CPE-L] CPE Applicability Language http://scap.nist.gov/specifications/cpe/#language

[CPE-M] CPE Name Matching http://scap.nist.gov/specifications/cpe/#matching

[CPE-N] CPE Naming http://scap.nist.gov/specifications/cpe/#naming

[CVE] CVE http://scap.nist.gov/revision/1.2/#cve

[CVSS] CVSS http://scap.nist.gov/revision/1.2/#cvss

[DCES] Dublin Core metadata version 1.1 http://dublincore.org/documents/dces/

[DSIG] DSIG specification http://www.w3.org/TR/xmldsig-core/

[ERRATA] SCAP 1.2 (SP 800-126) errata http://scap.nist.gov/revision/1.2/#errata

[OCIL] OCIL http://scap.nist.gov/revision/1.2/#ocil

[OVAL] OVAL http://scap.nist.gov/revision/1.2/#oval

[RFC2119] RFC 2119 http://www.ietf.org/rfc/rfc2119.txt

[TMSAD] TMSAD http://scap.nist.gov/revision/1.2/#tmsad

[XCCDF] XCCDF http://scap.nist.gov/revision/1.2/#xccdf

[XINCLUDE] XInclude specification http://www.w3.org/TR/xinclude/

[XLINK] XLink specification http://www.w3.org/TR/xlink/

[XMLCAT] XML Catalog specification http://www.oasis-open.org/committees/download.php/14809/xml-catalogs.html

[XMLS] W3C XML Schema http://www.w3.org/XML/Schema.html

Table 22 lists the schema file locations (and Schematron file locations, when applicable) for the SCAP component specifications. Table 22 - SCAP Schema and Schematron File Locations

Revision 2 Release 0 – 12 July 2011
• Complete draft specification for version 1.2 released for public comment.
• Made editorial changes throughout the document.
• Added the following component specifications to SCAP: ARF 1.1, Asset Identification 1.1, CCSS 1.0, and TMSAD 1.0. Updated the following component specifications from SCAP 1.1: XCCDF from 1.1.4 to 1.2; OVAL from 5.8 to 5.10; and CPE from 2.2 to 2.3. Added and revised requirements throughout the specification to use these component specification versions.
• In Section 2, rewrote the conformance requirements and defined “content producer” and “content consumer” terms.
• Section 3:
◦ Added an SCAP source data stream subsection and a subsection on digitally signing source data stream content.
◦ Added identifier use requirements for <xccdf:Rule> and <xccdf:ident> elements.
◦ Added requirements for the <xccdf:Value> element.
◦ Added requirements related to Schematron rules.
• Section 4:
◦ Revised legacy support requirements for SCAP content and OVAL definition documents.
◦ Added an SCAP result data stream subsection. Added source and result data stream requirements throughout the section. Also added a subsection on digitally signing result data stream content.
◦ Added a declaration of the FDCC Reporting Format.
• In Section 5, added malware detection material to the Inventory Scanning use case.
• Updated the normative references.
• Added Appendix C (change log).

• Section 3.2 (XCCDF):
o Prohibited use of XInclude elements in XCCDF content, use of the <xccdf:set-complex-value> element within the <xccdf:Profile> element, and use of XCCDF group extension.
o Clarified use of <xccdf:ident> elements and added the @con:negate attribute.
o Clarified use of <xccdf:check-content-ref> elements.

• Section 4.1 (Legacy Support):
o Added explicit information and requirements regarding deprecated constructs in SCAP component specifications.

The following table contains clarifications and corrections for Special Publication (SP) 800-126, Revision 2 as of the date indicated in the table.