Content consumers SHALL apply the mapping illustrated in Table 23 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 and the @negate attribute of the <xccdf:check> element where applicable. ~Table 23: Deriving XCCDF Check Results from OVAL Definition Results~OVAL Definition Result~XCCDF Check Result~(@negate is set to "false")~XCCDF Check Result~(@negate is set to "true")~~error~error~error~~unknown~unknown~unknown~~not applicable~notapplicable~notapplicable~~not evaluated~notchecked~notchecked~~Definition Class~Definition Result~~compliance~true~~vulnerability~false~~inventory~true~~patch~false~~~pass~fail~~Definition Class~Definition Result~~compliance~False~~vulnerability~true~~inventory~false~~patch~true~~~fail~pass~~

The following requirements and recommendations pertain to content consumers generating XCCDF result data stream components.~~To be considered valid SCAP result content, the <xccdf:TestResult> element SHALL meet the following conditions~The @start-time and @end-time attributes SHALL be provided to indicate when the scan started and completed, respectively.

The following requirements and recommendations pertain to content consumers generating XCCDF result data stream components.~~To be considered valid SCAP result content, the <xccdf:TestResult> element SHALL meet the following conditions~The @test-system attribute SHALL be provided, and it SHALL be a CPE name value indicating the product that was responsible for generating the results.

The following requirements and recommendations pertain to content consumers generating XCCDF result data stream components.~~To be considered valid SCAP result content, the <xccdf:TestResult> element SHALL meet the following conditions~Each IP address(es) associated with the <xccdf:target> SHALL be enumerated using the <xccdf:target-address> element.

The following requirements and recommendations pertain to content consumers generating XCCDF result data stream components.~~To be considered valid SCAP result content, the <xccdf:TestResult> element SHALL meet the following conditions~Where applicable to the target system, each of the <xccdf:fact> elements in Table 22 SHALL be provided. Previous versions of SCAP required additional facts; these have been incorporated into the use of the Asset Identification specification, as discussed in Section 4.4.2.~~Table 22: XCCDF Fact Descriptions~XCCDF Fact~Description of Use~~urn:scap:fact:asset:identifier:ein~Equipment identification number or other inventory tag number~~urn:scap:fact:asset:identifier:guid~Globally unique identifier for the asset, if assigned~~urn:scap:fact:asset:environmental_information:owning_organization~Organization that tracks the asset on its inventory~~urn:scap:fact:asset:environmental_information:current_region~Geographic region where the asset is located~~urn:scap:fact:asset:environmental_information:administration_unit~Name of the organization that does system administration for the asset~~

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 CVE entry, the target platform satisfies all the conditions of the XCCDF rule and is unaffected by the vulnerability or exposure referenced by the CVE.~For a CCE entry, the target platform complies with the configuration setting guidance expressed in the XCCDF rule.~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.

data results SHALL be expressed as Single Machine Without System Characteristics, Single Machine With System Characteristics, or Single Machine With Thin Results

Single Machine Without System Characteristics – A single result file that includes the results of all OVAL Definitions evaluated and "full" results types as described in the <oval-res:ContentEnumeration> element, without system characteristics. ~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.

Single Machine With System Characteristics – A single result file that includes the results of all OVAL Definitions evaluated and "full" results types as described in the <oval-res:ContentEnumeration> element and the System Characteristics of the target evaluated.~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.

Single Machine With Thin Results – A single result file that includes the results of all OVAL Definitions evaluated and "thin" results types as described in the OVAL Results schema. A value of "thin" means only the minimal amount of information will 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"/>

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.

The following requirements and recommendations pertain to content consumers generating XCCDF result data stream components.~~To be considered valid SCAP result content, the <xccdf:TestResult> element SHALL meet the following conditions~When the <xccdf:TestResult> is the root XCCDF element, then it will include an <xccdf:benchmark> element [XCCDF:6.6.2]. ~The <xccdf:benchmark> element SHALL have an @id attribute specified. The @id attribute SHALL match the value of the <xccdf:Benchmark> element's @id attribute that was processed. ~The <xccdf:benchmark> element SHALL have an @href attribute specified. The @href attribute SHALL hold the URI referencing the XCCDF component (either local to the data stream collection or remote) that was processed. The URI SHALL be in the form specified for the @href attribute in Table 8.

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.

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.

The following requirements and recommendations pertain to content consumers generating XCCDF result data stream components.~~To be considered valid SCAP result content, the <xccdf:TestResult> element SHALL meet the following conditions~~The <xccdf:rule-result> elements report the result of the application of each selected rule [XCCDF:6.6.2].~The <xccdf:check/xccdf:check-content-ref> element SHALL record the reference to the checking system specific result component report ID and check name within the result file using the @href and @name attributes, respectively.

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

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.

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

The following requirements and recommendations pertain to content consumers generating XCCDF result data stream components.~~To be considered valid SCAP result content, the <xccdf:TestResult> element SHALL meet the following conditions~An <xccdf:target-id-ref> SHALL be specified with a @system attribute of "http://scap.nist.gov/schema/asset-identification/1.1", an @href attribute value of "", and a @name attribute value of the ID of the <ai:asset> element in the ARF that this <xccdf:TestResult> is about.

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.

One XML digital signature MAY be included in an <arf:extended-info> element in the ARF report.

The <dsig:Signature> element SHALL sign the ARF report collection root element.

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

The first <dsig:Reference> element in a <dsig: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 "".

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.

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

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.~The <arf:extended-info> element containing the original signature SHALL be removed from the resulting document.

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.~The first <dsig:Reference> element on the new <dsig:Signature> element SHALL reference the <dsig:Object> element containing the original signature. The <dsig:Object> element SHALL be referenced in the @URI attribute using "#" + @Id of the <dsig:Object>

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.~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 "#" + @Id of the <dsig:SignatureProperties>

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 <dsig:SignatureProperties> element SHALL be included in the <dsig:Signature> element. At least one <dsig:SignatureProperty> element SHALL be populated with <dt:signature-info> as specified in [TMSAD].

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.~Key information SHOULD be provided on the <dsig:Signature> element in accordance with [TMSAD].

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.~The new <dsig:Signature> element SHALL be placed in a new <arf:extended-info> element in the ARF report collection.

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

An SCAP result data stream SHALL conform to the [ARF] specification.

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.

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, and when reporting on XCCDF, OVAL, or OCIL, each component report SHALL use the element specified in Table 19 as its root element.

Each SCAP result data stream component SHOULD NOT use any deprecated constructs in its associated specification.

Additional identification information MAY be captured in the <ai:asset> element (asset tag, system GUID, etc.) The guidelines specified in [AI] SHALL be followed when populating the asset identification information.

The following requirements and recommendations pertain to content consumers generating XCCDF result data stream components.~~To be considered valid SCAP result content, the <xccdf:TestResult> element SHALL meet the following conditions~~The <xccdf:rule-result> elements report the result of the application of each selected rule [XCCDF:6.6.2].~The @href attribute SHALL contain "#" + the @id of the <arf:report> containing the check result. This approach provides traceability between XCCDF and check results.

The following requirements and recommendations pertain to content consumers generating XCCDF result data stream components.~~To be considered valid SCAP result content, the <xccdf:TestResult> element SHALL meet the following conditions~~The <xccdf:rule-result> elements report the result of the application of each selected rule [XCCDF:6.6.2].~Note that if @multi-check is not set to "true" and the <xccdf:rule-result> represents a group of checks, then the @name attribute SHALL be omitted.

The following requirements and recommendations pertain to content consumers generating XCCDF result data stream components.~~To be considered valid SCAP result content, the <xccdf:TestResult> element SHALL meet the following conditions~If a child profile of an <xccdf:Tailoring> element was applied during processing, then the <xccdf:tailoring-file> element SHALL be present and SHALL provide the following information about the <xccdf:Tailoring> element: @href, @id, @version, and @time. The @href attribute SHALL hold the URI to the XCCDF Tailoring component and SHALL comply with the format described above (item 3).

The following requirements and recommendations pertain to content consumers generating XCCDF result data stream components.~~To be considered valid SCAP result content, the <xccdf:TestResult> element SHALL meet the following conditions~The <xccdf:Profile> element SHALL be included if a profile was applied during processing. This is also applicable to selected profiles part of <xccdf:Tailoring>.

The following requirements and recommendations pertain to content consumers generating XCCDF result data stream components.~~To be considered valid SCAP result content, the <xccdf:TestResult> element SHALL meet the following conditions~Regarding the definition and use of <xccdf:Profile> elements, reported <xccdf:set-value> elements SHALL include all those values that are exported by the reported rules. The specific settings are those determined by the reported <xccdf:Profile>.

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 generating XCCDF result data stream components.~~To be considered valid SCAP result content, the <xccdf:TestResult> element SHALL meet the following conditions~~The <xccdf:rule-result> elements report the result of the application of each selected rule [XCCDF:6.6.2].~The @role, @severity, and @weight attributes of the <xccdf:rule-result> element SHALL be provided to indicate their values used during assessment.

The following requirements and recommendations pertain to content consumers generating XCCDF result data stream components.~~To be considered valid SCAP result content, the <xccdf:TestResult> element SHALL meet the following conditions~The <xccdf:identity> element SHALL identify the security principal used to access rule evaluation on the target(s). This will include the identity name or username used to perform the evaluation.

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.

SCAP-conformant content SHALL include full status reporting, including Error, Unknown, Not Applicable, Not Evaluated, True, and False.

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

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.

The following requirements and conventions apply to the <xccdf:Benchmark>, <xccdf:Profile>, <xccdf:Value>, <xccdf:Group>, and <xccdf:Rule> elements:~One or more instances of the <xccdf:description> element SHALL be provided. Each instance SHALL contain a text value that describes the purpose of the containing element.

The following requirements and recommendations apply to the <xccdf:check> element:~~Content containing the use of checking systems other than the OVAL and OCIL checking systems SHALL NOT be considered well-formed with regards to SCAP.~~OVAL checking system~Use of the OVAL checking system SHALL be indicated by setting the <xccdf:check> element's @system attribute to "http://oval.mitre.org/XMLSchema/oval-definitions-5 ".

The following requirements and recommendations apply to the <xccdf:check> element:~~Content containing the use of checking systems other than the OVAL and OCIL checking systems SHALL NOT be considered well-formed with regards to SCAP.~~OCIL checking system~Use of the OCIL checking system SHALL be indicated by setting the <xccdf:check> element's @system attribute to "http://scap.nist.gov/schema/ocil/2".

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" _x000B_ export-name="OVAL_External_Variable_id"/>

The following requirements and recommendations pertain to content consumers generating XCCDF result data stream components.~XCCDF test results SHALL be documented as the contents of an <xccdf:TestResult> element.

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>

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.

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.

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

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:~The source data stream SHALL include the OVAL source data stream component referenced by the patches up-to-date rule, which contains one or more OVAL patch class definitions.

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:~Each <xccdf:check-content-ref> element SHALL omit the @name attribute.

The following requirements and recommendations apply to the <xccdf:check> element:~At least one <xccdf:check-content-ref> element SHALL be provided for each <xccdf:check>

The following requirements and recommendations apply to the <xccdf:Benchmark> element:~The <xccdf:Benchmark> element SHALL have an @xml:lang attribute.

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.

Required values for the @class attribute of an OVAL Definition are as follows:~"compliance" if it represents a check for the system's configuration complying with policy requirements (for example, having the required value for a specific configuration setting).~"vulnerability" if it represents a check for the presence of a particular software flaw vulnerability on a system.~"patch" if it represents a check for whether a discrete patch needs to be installed on the system.~"inventory" if it represents a check for the presence of a product of interest on the system.~The following requirements apply to particular classes of OVAL Definitions:~~For compliance class definitions:~If an OVAL compliance class definition maps to one or more CCE identifiers, the definition SHOULD include <oval-def:reference> elements that reference those identifiers using the following format: ~<oval-def:reference source="http://cce.mitre.org" ref_id="CCE_identifier"/>_x000B__x000B_The source attribute SHALL be defined using either "http://cce.mitre.org" (preferred method) or "CCE".

Required values for the @class attribute of an OVAL Definition are as follows:~"compliance" if it represents a check for the system's configuration complying with policy requirements (for example, having the required value for a specific configuration setting).~"vulnerability" if it represents a check for the presence of a particular software flaw vulnerability on a system.~"patch" if it represents a check for whether a discrete patch needs to be installed on the system.~"inventory" if it represents a check for the presence of a product of interest on the system.~The following requirements apply to particular classes of OVAL Definitions:~~For compliance class definitions:~Definitions that are directly or indirectly extended SHALL be limited to inventory and compliance classes.

Required values for the @class attribute of an OVAL Definition are as follows:~"compliance" if it represents a check for the system's configuration complying with policy requirements (for example, having the required value for a specific configuration setting).~"vulnerability" if it represents a check for the presence of a particular software flaw vulnerability on a system.~"patch" if it represents a check for whether a discrete patch needs to be installed on the system.~"inventory" if it represents a check for the presence of a product of interest on the system.~The following requirements apply to particular classes of OVAL Definitions:~~For inventory class definitions:~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: _x000B__x000B_<oval-def:reference source="http://cpe.mitre.org" ref_id="CPE_identifier"/>_x000B__x000B_The source attribute SHALL be defined using either "http://cpe.mitre.org" (preferred method) or "CPE".

Required values for the @class attribute of an OVAL Definition are as follows:~"compliance" if it represents a check for the system's configuration complying with policy requirements (for example, having the required value for a specific configuration setting).~"vulnerability" if it represents a check for the presence of a particular software flaw vulnerability on a system.~"patch" if it represents a check for whether a discrete patch needs to be installed on the system.~"inventory" if it represents a check for the presence of a product of interest on the system.~The following requirements apply to particular classes of OVAL Definitions:~~For inventory class definitions:~Definitions that are directly or indirectly extended SHALL be limited to the inventory class.

Required values for the @class attribute of an OVAL Definition are as follows:~"compliance" if it represents a check for the system's configuration complying with policy requirements (for example, having the required value for a specific configuration setting).~"vulnerability" if it represents a check for the presence of a particular software flaw vulnerability on a system.~"patch" if it represents a check for whether a discrete patch needs to be installed on the system.~"inventory" if it represents a check for the presence of a product of interest on the system.~The following requirements apply to particular classes of OVAL Definitions:~~For patch class definitions:~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:_x000B__x000B_<oval-def:reference source="http://cve.mitre.org" ref_id="CVE_identifier"/>_x000B__x000B_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._x000B__x000B_The source attribute SHALL be defined using either "http://cve.mitre.org" (preferred method) or "CVE".

Required values for the @class attribute of an OVAL Definition are as follows:~"compliance" if it represents a check for the system's configuration complying with policy requirements (for example, having the required value for a specific configuration setting).~"vulnerability" if it represents a check for the presence of a particular software flaw vulnerability on a system.~"patch" if it represents a check for whether a discrete patch needs to be installed on the system.~"inventory" if it represents a check for the presence of a product of interest on the system.~The following requirements apply to particular classes of OVAL Definitions:~~For patch class definitions:~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:_x000B__x000B_<oval-def:reference source="www.microsoft.com/Patch" ref_id="KB912919"/>

Required values for the @class attribute of an OVAL Definition are as follows:~"compliance" if it represents a check for the system's configuration complying with policy requirements (for example, having the required value for a specific configuration setting).~"vulnerability" if it represents a check for the presence of a particular software flaw vulnerability on a system.~"patch" if it represents a check for whether a discrete patch needs to be installed on the system.~"inventory" if it represents a check for the presence of a product of interest on the system.~The following requirements apply to particular classes of OVAL Definitions:~~For patch class definitions:~Definitions that are directly or indirectly extended SHALL be limited to inventory and patch classes.

Required values for the @class attribute of an OVAL Definition are as follows:~"compliance" if it represents a check for the system's configuration complying with policy requirements (for example, having the required value for a specific configuration setting).~"vulnerability" if it represents a check for the presence of a particular software flaw vulnerability on a system.~"patch" if it represents a check for whether a discrete patch needs to be installed on the system.~"inventory" if it represents a check for the presence of a product of interest on the system.~The following requirements apply to particular classes of OVAL Definitions:~~For vulnerability class definitions:~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:_x000B__x000B_<oval-def:reference source="http://cve.mitre.org" ref_id="CVE_identifier"/>_x000B__x000B_The source attribute SHALL be defined using either "http://cve.mitre.org" (preferred method) or "CVE".

Required values for the @class attribute of an OVAL Definition are as follows:~"compliance" if it represents a check for the system's configuration complying with policy requirements (for example, having the required value for a specific configuration setting).~"vulnerability" if it represents a check for the presence of a particular software flaw vulnerability on a system.~"patch" if it represents a check for whether a discrete patch needs to be installed on the system.~"inventory" if it represents a check for the presence of a product of interest on the system.~The following requirements apply to particular classes of OVAL Definitions:~~For vulnerability class definitions:~Definitions that are directly or indirectly extended SHALL be limited to inventory and vulnerability classes.

Within the SCAP component specifications, certain constructs can be deprecated. SCAP content consumers SHALL support all deprecated constructs, unless specifically noted in the annex, because they are still valid within SCAP 1.3 and supported legacy SCAP versions. This requirement ensures that legacy SCAP content making use of these deprecated constructs continues to be supported.~Content consumers supporting OVAL SHALL support OVAL Definition documents written against all versions of OVAL component specifications listed in the annex.

Required values for the @class attribute of an OVAL Definition are as follows:~"compliance" if it represents a check for the system's configuration complying with policy requirements (for example, having the required value for a specific configuration setting).

Required values for the @class attribute of an OVAL Definition are as follows:~"vulnerability" if it represents a check for the presence of a particular software flaw vulnerability on a system.

Required values for the @class attribute of an OVAL Definition are as follows:~"patch" if it represents a check for whether a discrete patch needs to be installed on the system.

Required values for the @class attribute of an OVAL Definition are as follows:~"inventory" if it represents a check for the presence of a product of interest on the system.

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:~An OVAL compliance definition. This definition SHALL be contained in an OVAL component, which holds definitions of compliance checks used by the checklist. An XCCDF benchmark's rules MAY reference one or more OVAL compliance class definitions in an OVAL component.~An OCIL questionnaire. This questionnaire SHALL be contained in an OCIL component, which holds questionnaires that collect information that OVAL is not being used to collect, such as posing questions to users or harvesting configuration information from an existing database. An XCCDF benchmark's rules MAY reference one or more OCIL questionnaires in an OCIL component.~An OVAL patch definition. This definition SHALL be contained in an OVAL component, which holds definitions for patch compliance checks. These checks may be needed if an organization includes patch verification in its compliance activities. An XCCDF benchmark MAY reference an OVAL patch definition through a patches up-to-date rule in a manner consistent with Section 3.2.4.3.

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:~An OVAL vulnerability definition. This definition SHALL be contained in an OVAL component, which holds definitions of vulnerability checks used by the checklist. An XCCDF benchmark's rules MAY reference one or more OVAL vulnerability class definitions in an OVAL component.~An OCIL questionnaire. This questionnaire SHALL be contained in an OCIL component, which holds questionnaires that collect information that OVAL is not being used to collect. An example of OCIL use is to give step-by-step directions for manually examining a system for a vulnerability that cannot be detected with OVAL. In such a case, OCIL is used for capturing information collected using manual examination. An XCCDF benchmark's rules MAY reference one or more OCIL questionnaires in an OCIL component. ~An OVAL patch definition. This definition SHALL be contained in an OVAL component, which holds definitions for patch compliance checks. These checks may be needed if an organization includes patch verification in its vulnerability scanning activities. An XCCDF benchmark MAY reference an OVAL patch definition through a patches up-to-date rule in a manner consistent with Section 3.2.4.3.

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:~An OVAL inventory definition. This definition SHALL be contained in an OVAL component, which holds definitions of technical procedures for determining whether or not a specific target asset has software (product, platform, malware, etc.) of interest. An XCCDF benchmark's rules MAY reference one or more OVAL inventory class definitions in an OVAL component. ~An OCIL questionnaire. This questionnaire SHALL be contained in an OCIL component, which holds questionnaires that collect information that OVAL is not being used to collect, such as posing questions to users or harvesting inventory information from an existing database. An XCCDF benchmark's rules MAY reference one or more OCIL questionnaires in an OCIL component.

The following requirements and recommendations apply to the <xccdf:check> element:~The <xccdf:check-content> element SHALL NOT be used to embed check content directly into XCCDF content.

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

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.

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.

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.

Each SCAP source data stream component SHOULD NOT use any constructs that are deprecated in its associated specification.

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:~The @multi-check attribute of the <xccdf:check> element SHALL be set to "true". This causes a separate <xccdf:rule-result> to be generated for each OVAL Patch Definition. See Section 4.5.2 for more information.

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.

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. Then these CPEs SHALL 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.

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.

Each signature SHALL be represented as a <dsig:Signature> element and follow the W3C recommendation [DSIG].