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~OVAL Definition Result~XCCDF Check Result~~error~error~~unknown~unknown~~not applicable~notapplicable~~not evaluated~notchecked~~Definition Class~Definition Result~~compliance~true~~vulnerability~false~~inventory~true~~patch~false~~~Pass~~Definition Class~Definition Result~~compliance~false~~vulnerability~true~~inventory~false~~patch~true~~~Fail~~
The @start-time and @end-time attributes SHALL be provided to indicate when the scan started and completed, respectively.
Derived Requirement # | Summary | Result |
---|---|---|
RES-133-1 | The @start-time and @end-time attributes SHALL be provided to indicate when the scan started and completed, respectively. | Not Tested |
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.
Derived Requirement # | Summary | Result |
---|---|---|
RES-134-1 | The @test-system attribute SHALL be provided with a CPE Name value indicating the product that evaluated the checklist. | Not Tested |
Each IP address associated with the <xccdf:target> SHALL be enumerated using the <xccdf:target-address> element.
Derived Requirement # | Summary | Result |
---|---|---|
RES-136-1 | The <xccdf:target> and <xccdf:target-address> elements SHALL be provided. | Not Tested |
RES-136-2 | The <xccdf:target-address> SHALL contain an IP address | Not Tested |
Where applicable to the target system, each of the <xccdf:fact> elements in Table 20 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 20 - 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.
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 MUST have an @id attribute specified.
Derived Requirement # | Summary | Result |
---|---|---|
RES-253-1 | If the <xccdf:TestResult> is the root XCCDF element, then it will include an <xccdf:benchmark> element [XCCDF:6.6.2]. The <xccdf:benchmark> element MUST have an @id attribute specified. | Not Tested |
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.
Derived Requirement # | Summary | Result |
---|---|---|
RES-258-1 | This requirement was not tested but the user should check their content for adherence. | Not Tested |
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 check 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.
Derived Requirement # | Summary | Result |
---|---|---|
RES-271-1 | 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. | Not Tested |
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
Derived Requirement # | Summary | Result |
---|---|---|
RES-299-1 | 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 | Not Tested |
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>.
Derived Requirement # | Summary | Result |
---|---|---|
RES-300-1 | 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>. | Not Tested |
Table 19 outlines the relationships that MUST be specified in the ARF report if the stated condition is satisfied.
Derived Requirement # | Summary | Result |
---|---|---|
RES-301-1 | Table 19 outlines the relationships that MUST be specified in the ARF report if the stated condition is satisfied. | Not Tested |
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>/##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.
One XML digital signature MAY be included in an <arf:extended-info> element in the ARF report.
Derived Requirement # | Summary | Result |
---|---|---|
RES-307-1 | One XML digital signature MAY be included in an <arf:extended-info> element in the ARF report. | Not Tested |
The <dsig:Signature> element MUST sign the ARF report collection root element.
Derived Requirement # | Summary | Result |
---|---|---|
RES-309-1 | The <dsig:Signature> element MUST sign the ARF report collection root element. | Not Tested |
A <dsig:SignatureProperties> element MUST be included in the <dsig:Signature> element. At least one <dsig:SignatureProperty> element MUST be populated with <dt:signature-info> as specified in [TMSAD].
Derived Requirement # | Summary | Result |
---|---|---|
RES-311-1 | A <dsig:SignatureProperties> element MUST be included in the <dsig:Signature> element. At least one <dsig:SignatureProperty> element MUST be populated with <dt:signature-info> as specified in [TMSAD]. | Not Tested |
The first <dsig:Reference> element in a <dsig:Signature> element MUST be to the <arf:asset-report-collection> element. The element MUST be referenced in the @URI attribute using the empty string convention "".
Derived Requirement # | Summary | Result |
---|---|---|
RES-312-1 | The first <dsig:Reference> element in a <dsig:Signature> element MUST be to the <arf:asset-report-collection> element. The element MUST be referenced in the @URI attribute using the empty string convention "". | Not Tested |
Two XPath Filter 2 transforms MUST exist on the first <dsig:Reference> element in a <dsig:Signature> element. Both MUST specify a filter type of "subtract". The first transform MUST specify the XPath "/arf:asset-report-collection/arf:extended-infos[count(arf:extended-info[dsig:Signature]) = count(*)]". The second transform MUST specify the XPath "/arf:asset-report-collection/arf:extended-infos/arf:extended-info[dsig:Signature]". In both cases, the namespace prefix "arf" MUST map to the ARF namespace specified in this document.
Key information SHOULD be provided on the <dsig:Signature> element.
Derived Requirement # | Summary | Result |
---|---|---|
RES-315-1 | Key information SHOULD be provided on the <dsig:Signature> element. | Not Tested |
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 MUST 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 MUST be to the <dsig:SignatureProperties> element captured in a <dsig:Object> element with the <dsig:Signature> element. The <dsig:SignatureProperties> element MUST 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 MUST be included in the <dsig:Signature> element. At least one <dsig:SignatureProperty> element MUST 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 MUST 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.
Derived Requirement # | Summary | Result |
---|---|---|
RES-323-1 | When signing a result data stream, the source data stream collection SHOULD be captured in the ARF report being signed. | Not Tested |
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.
Derived Requirement # | Summary | Result |
---|---|---|
RES-365-1 | It MAY contain additional report objects for other results, such as <oval-var:oval_variables> or extended component results. | Not Tested |
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.
Each SCAP result data stream component SHOULD NOT use any constructs that are deprecated in its associated specification.
Derived Requirement # | Summary | Result |
---|---|---|
RES-367-1 | Each SCAP result data stream component SHOULD NOT use any constructs that are deprecated in its associated specification. | Not Tested |
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.
Derived Requirement # | Summary | Result |
---|---|---|
RES-369-1 | 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. | Not Tested |
The @href attribute SHALL contain "#" + the @id of the <arf:report> containing the check result. This approach provides traceability between XCCDF and check results.
Derived Requirement # | Summary | Result |
---|---|---|
RES-370-1 | The @href attribute SHALL contain "#" + the @id of the <arf:report> containing the check result. This approach provides traceability between XCCDF and check results. | Not Tested |
RES-370-2 | Depending on the checking engine used (OVAL or OCIL), the the <arf:report> element should contain the relevant (OVAL or OCIL) content. | Not Tested |
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.
Derived Requirement # | Summary | Result |
---|---|---|
RES-371-1 | 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. | Not Tested |
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.
Derived Requirement # | Summary | Result |
---|---|---|
RES-42-1 | At least one <xccdf:identity> element SHALL be provided and SHALL contain text to identify the security principal. | Not Tested |
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.
Derived Requirement # | Summary | Result |
---|---|---|
RES-68-1 | SCAP-conformant content SHALL include full status reporting, including Error, Unknown, Not Applicable, Not Evaluated, True, and False. | Not Tested |
An SCAP OVAL result data stream component SHALL include the results of every OVAL Definition used to generate the reported results.
Derived Requirement # | Summary | Result |
---|---|---|
RES-69-1 | An SCAP OVAL result data stream component SHALL include the results of every OVAL Definition used to generate the reported results. | Not Tested |
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 MUST contain a text value that describes the purpose of the containing element.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-10-1 | For each <xccdf:Benchmark>, <xccdf:Profile>, <xccdf:Value>, <xccdf:Group>, and <xccdf:Rule> element, a <xccdf:description> SHALL be provided. | Pass |
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:~~OVAL check system~Use of the OVAL check 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:~~This version of SCAP supports the OVAL and OCIL check systems. Use of these check systems SHALL be restricted as follows:~~OCIL check system~Use of the OCIL check 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"/>
XCCDF test results SHALL be documented as the contents of an <xccdf:TestResult> element.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-131-1 | XCCDF test results SHALL be documented as the contents of an <xccdf:TestResult> element. | Not Tested |
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.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-15-1 | Every <xccdf:platform> or <cpe2:fact-ref> MUST match as EQUAL or SUPERSET to a CPE in a CPE dictionary component of this data stream. | Pass |
CVE references in SCAP content MAY include both "candidate" and "entry" status identifiers.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-150-1 | CVE references in SCAP content MAY include both "candidate" and "entry" status identifiers. | Not Tested |
Deprecated CVE identifiers SHALL NOT be used.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-151-1 | Deprecated CVE identifiers SHALL NOT be used. | Not Tested |
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 12 as its document element.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-154-1 | Each SCAP source data stream component SHALL use one of the elements specified in Table 12 as its document element. | Not Tested |
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:~The source data stream MUST 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 MUST reference an OVAL source data stream component. When implementing a patches up-to-date XCCDF rule, 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 MUST be provided for each <xccdf:check>
Derived Requirement # | Summary | Result |
---|---|---|
SRC-175-1 | At least one <xccdf:check-content-ref> element MUST be provided in each <xccdf:check> | Pass |
The following requirements and recommendations apply to the <xccdf:Benchmark> element:~The <xccdf:Benchmark> element SHALL have an @xml:lang attribute.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-2-1 | @xml:lang attribute SHALL be provided on <xccdf:Benchmark> elements. | Pass |
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.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-206-1 | During scoring, current CVSS scores acquired dynamically, such as from a data feed, SHOULD be used in place of the @weight attribute within XCCDF vulnerability-related rules. | Not Tested |
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".
Derived Requirement # | Summary | Result |
---|---|---|
SRC-207-1 | OVAL definitions of class 'compliance' should include a reference to a CCE, where applicable. | Pass |
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.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-208-1 | For OVAL definitions of @class 'compliance', only definitions of class 'compliance' or 'inventory' can be extended. | Pass |
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".
Derived Requirement # | Summary | Result |
---|---|---|
SRC-209-1 | OVAL definitions of class 'inventory' should include a reference to a CPE, where applicable. | Pass |
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.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-210-1 | For OVAL definitions of @class 'inventory', only definitions of class 'inventory' can be extended. | Pass |
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".
Derived Requirement # | Summary | Result |
---|---|---|
SRC-211-1 | OVAL patch class MAY reference a CVE. This requirement changed from "SHOULD" to "MAY" in SCAP Schematron version 1.1 | Not Tested |
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.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-213-1 | For OVAL definitions of @class 'patch', only definitions of class 'patch' or 'inventory' can be extended. | Pass |
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".
Derived Requirement # | Summary | Result |
---|---|---|
SRC-214-1 | OVAL definitions of class 'vulnerability' should include a reference to a CVE, where applicable. | Pass |
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.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-215-1 | For OVAL definitions of @class 'vulnerability', only definitions of class 'inventory' or 'vulnerability' can be extended. | Pass |
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.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-216-1 | OVAL documents must be written in one of the following versions: 5.3, 5.4, 5.5, 5.6, 5.7, 5.8, 5.9, 5.10, or 5.10.1 from errata | Pass |
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.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-228-1 | 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. | Not Tested |
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.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-229-1 | 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. | Not Tested |
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.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-230-1 | 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. | Not Tested |
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:~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 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:~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, such as giving a system administrator step-by-step directions for manually examining a system for a vulnerability that cannot be detected with OVAL, and then collecting information on the results of that 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 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:~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.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-25-1 | A XCCDF document SHALL NOT contain an <xccdf:check-content> element | Pass |
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.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-251-1 | An xccdf:Rule should include an xccdf:ident containing a CVE, CCE, or CPE | Pass |
SRC-251-2 | If an XCCDF 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). | Pass |
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.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-257-1 | An <xccdf:ident> element referencing a CVE, CCE, or CPE identifier (using the @system value specified in the 800-126) SHALL be ordered before other <xccdf:ident> elements referencing non-SCAP identifiers. | Pass |
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.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-263-1 | All OVAL components and OCIL components referenced by the XCCDF benchmark SHALL be included in the SCAP source data stream. | Not Tested |
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.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-265-1 | Each XCCDF Benchmark SHALL have at least one rule that references either an OVAL vulnerability definition in the an OVAL component or an OCIL questionnaire in the OCIL Questionnaire component. | Pass |
All OVAL components and OCIL components referenced by the XCCDF benchmark SHALL be included in the SCAP source data stream.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-266-1 | All OVAL components and OCIL components referenced by the XCCDF benchmark SHALL be included in the SCAP source data stream. | Not Tested |
Each SCAP source data stream component SHOULD NOT use any constructs that are deprecated in its associated specification.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-267-1 | Each SCAP source data stream component SHOULD NOT use any constructs that are deprecated in its associated specification. | Not Tested |
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:~The @multi-check attribute of the <xccdf:check> element SHOULD be set to "true". This causes a separate <xccdf:rule-result> to be generated for each OVAL Definition. See Section 4.5.2 for more information.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-275-1 | If a rule is doing a "patches up-to-date" check, then the @multi-check attribute on each xccdf:check in that rule SHOULD be set to "true". This requirement was removed in SCAP Schematron version 1.1. | Not Tested |
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 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.
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 MUST be represented as a <dsig:Signature> element and follow the W3C recommendation [DSIG].
Derived Requirement # | Summary | Result |
---|---|---|
SRC-281-1 | Each signature MUST be represented as a <dsig:Signature> element and follow the W3C recommendation [DSIG]. | Not Tested |
Each <dsig:Signature> element MUST sign only one data stream
Derived Requirement # | Summary | Result |
---|---|---|
SRC-282-1 | Each <dsig:Signature> element MUST sign only one data stream | Not Applicable |
A <dsig:Manifest> element MUST be included within the <dsig:Signature> element as a <dsig:Object> element. The <dsig:Manifest> element MUST have a <dsig:Reference> element for each local component referenced by the data stream being signed. External components MAY be omitted from the <dsig:Manifest> element. Each <dsig:Reference> element referencing a <ds:component> or <ds:extended-component> element MUST point to the component being signed by identifying the component in the @URI attribute using "#" + @Id of the component.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-284-1 | A <dsig:Manifest> MUST be included in the <dsig:Signature> as a <dsig:Object> | Not Applicable |
SRC-284-2 | The <dsig:Manifest> MUST have a <dsig:Reference> for each local component referenced by the data stream being signed. | Not Applicable |
A <dsig:SignatureProperties> element MUST be included within the <dsig:Signature> element as a <dsig:Object> element. At least one <dsig:SignatureProperty> element MUST be populated with <dt:signature-info> as specified in [TMSAD]
Derived Requirement # | Summary | Result |
---|---|---|
SRC-285-1 | A <dsig:SignatureProperties> MUST be included in the <dsig:Signature> as a <dsig:Object> with a dsig:SignatureProperty populated with tmsad:signature-info | Not Applicable |
The first <dsig:Reference> element in a <dsig:Signature> element MUST be to the <ds:data-stream> element being signed. The <ds:data-stream> element MUST be referenced in the @URI attribute using "#" + @Id of the <ds:data-stream>
Derived Requirement # | Summary | Result |
---|---|---|
SRC-286-1 | The first <dsig:Reference> element in a <dsig:Signature> element MUST be to the <ds:data-stream> element being signed. The <ds:data-stream> element MUST be referenced in the @URI attribute using "#" + @Id of the <ds:data-stream> | Not Applicable |
The second <dsig:Reference> element in a <dsig:Signature> element MUST be to the <dsig:SignatureProperties> element captured in a <dsig:Object> element within the <dsig:Signature> element. The <dsig:SignatureProperties> element MUST be referenced in the @URI attribute using "#" + @Id of the<dsig:SignatureProperties> element.
The third <dsig:Reference> element MUST be to the <dsig:Manifest> element captured in a <dsig:Object> element with the <dsig:Signature> element. The <dsig:Manifest> element MUST be referenced in the @URI attribute using "#" + @Id attribute of the <dsig:Manifest>
<dsig:Reference> elements on the <dsig:Manifest> element SHOULD be in the same order as the <ds:component-ref> elements on the data stream being signed
Derived Requirement # | Summary | Result |
---|---|---|
SRC-289-1 | <dsig:Reference> elements on the <dsig:Manifest> element SHOULD be in the same order as the <ds:component-ref> elements on the data stream being signed | Not Tested |
Key information SHOULD be provided on the <dsig:Signature> element.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-290-1 | Key information SHOULD be provided on the <dsig:Signature>. | Not Applicable |
The following requirements and recommendations apply to the <xccdf:Benchmark> element:~The <xccdf:version> element and the @id attribute SHALL be used together to uniquely identify all revisions of a benchmark.~Multiple revisions of a single benchmark SHOULD have the same @id attribute value and different <xccdf:version> element values, so that someone who reviews the revisions can readily identify them as multiple versions of a single benchmark. ~Multiple revisions of a single benchmark SHOULD have <xccdf:version> element values that indicate the revision sequence, so that the history of changes from the original benchmark can be determined. ~The @time attribute of the <xccdf:version> element SHOULD be used for a timestamp of when the benchmark was defined.
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.
When evaluating an <xccdf:check-content-ref> element within an <xccdf:check> element, its @href attribute either MUST contain a "#" + @id of a <ds:component-ref> element or MUST be resolved in the context of the XML Catalog specified as part of the <ds:component-ref> element that is referencing this benchmark. In either case, the @href attribute MUST ultimately resolve to a <ds:component-ref> element in the data stream referencing the benchmark containing this <xccdf:check-content-ref> element. See Section 3.1.1 for additional information on <ds:component-ref> resolution.
The second <dsig:Reference> element MUST be to the <dsig:SignatureProperties> element captured in a <dsig:Object> element with the <dsig:Signature> element. The <dsig:SignatureProperties> element MUST 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.~The original signature SHALL be captured as a <dsig:Object> element on the new <dsig:Signature>
The @use-case attribute in the <ds:data-stream> element MUST be set to "CONFIGURATION".
Derived Requirement # | Summary | Result |
---|---|---|
SRC-324-1 | The @use-case attribute in the <ds:data-stream> element MUST be set to "CONFIGURATION", "VULNERABILITY", "INVENTORY" or "OTHER" | Pass |
The @use-case attribute in the <ds:data-stream> element MUST be set to "VULNERABILITY".
The @use-case attribute in the <ds:data-stream> element MUST be set to "INVENTORY".
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.
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.
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.
# | Test Result | Message | Context (Line/Column) |
---|---|---|---|
1 | Warning | 'Warning: The 'Benchmark' element has no platform specified, which implies the benchmark applies to all platforms. Applicable platforms should be indicate if possible. See the XCCDF 1.2.1 specification, Section 6.2.5. - TEST: false()' | 25 : 345 |
|
|||
2 | Informational | ' DEPRECATED ATTRIBUTE VALUE IN: variable_test ATTRIBUTE VALUE: none exist - TEST: @check='none exist'' | 847 : 246 |
|
|||
3 | Informational | ' DEPRECATED ATTRIBUTE VALUE IN: variable_test ATTRIBUTE VALUE: none exist - TEST: @check='none exist'' | 866 : 258 |
|
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~Purpose of the <xccdf:Rule>~OVAL Definition Class~Identifier Type~Value for <xccdf:ident> @system attribute~~Check compliance with a configuration setting~compliance~CCE~http://cce.mitre.org~~Perform a software inventory check~inventory~CPE~http://cpe.mitre.org~~Check for a software flaw vulnerability~vulnerability~CVE~http://cve.mitre.org~~
Content authors MAY place components in any order.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-332-1 | Content authors MAY place components in any order. | Not Tested |
Any component in a data stream collection SHALL be referenced not more than once by any data stream in that collection.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-333-1 | Any component in a data stream collection SHALL be referenced not more than once by any data stream in that collection. | Pass |
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. Schema validation is covered under requirement A-10. Schematron validation is covered under SRC-330.
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].
XInclude elements SHALL NOT be included in XCCDF content [XINCLUDE].
Derived Requirement # | Summary | Result |
---|---|---|
SRC-339-1 | XInclude elements SHALL NOT be included in XCCDF content [XINCLUDE]. | Pass |
The following requirements and recommendations apply to the <xccdf:Benchmark> element:~The @update attribute of the <xccdf:version> element SHOULD be used for a URI that specifies where updates to the benchmark can be obtained.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-341-1 | @update on <xccdf:version> SHOULD be specified | Pass |
Use of the <xccdf:set-complex-value> element within the <xccdf:Profile> element SHALL NOT be allowed.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-343-1 | Use of the <xccdf:set-complex-value> element within the <xccdf:Profile> element SHALL NOT be allowed. | Pass |
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:~~OVAL check system~The @href attribute in the <xccdf:check-content-ref> element MUST reference an OVAL source data stream component using the <ds:component-ref> approach defined above.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-345-1 | <xccdf:check-content-ref> in an OVAL <xccdf:check> MUST reference an OVAL component. If your content contains external references, SCAPVal will attempt to resolve it in -online mode. | Pass |
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:~~OVAL check system~Use of the @name attribute in the <xccdf:check-content-ref> element is OPTIONAL. If present, it MUST reference an OVAL Definition in the designated OVAL source data stream component, otherwise see Section 4.5.2 for information on use of the @multi-check attribute.
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:~~OCIL check system~The @href attribute in the <xccdf:check-content-ref> element MUST reference an OCIL source data stream component using the <ds:component-ref> approach defined above.
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:~~OCIL check system~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.
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.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-351-1 | Only OVAL and OCIL are supported check systems | Pass |
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.
One or more XML digital signatures MAY be included as the last elements in the SCAP source data stream collection root element.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-360-1 | One or more XML digital signatures MAY be included as the last elements in the SCAP source data stream collection root element. | Not Tested |
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 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~OVAL Variable Data Type~Matching XCCDF Data Type~~int~number~~float~number~~boolean~boolean~~string, evr_string, version, ios_version, fileset_revision, binary~string~~
The following requirements and recommendations apply to the <xccdf:Benchmark> element:~The @style attribute SHOULD have the value "SCAP_1.2".
Derived Requirement # | Summary | Result |
---|---|---|
SRC-4-1 | The style attribute of the <xccdf:Benchmark> element SHOULD contain the value "SCAP_1.2". | Pass |
The following requirements and recommendations apply to the <xccdf:Benchmark> element:~The <xccdf:status> element SHALL indicate the current status of the benchmark document. The associated text value SHALL be "draft" for documents released in public draft state and "accepted" for documents that have been officially released by an organization. The @date attribute SHALL be populated with the date of the status change. Additional <xccdf:status> elements MAY be included to indicate historic status transitions.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-5-1 | The <xccdf:status> element SHALL have value 'draft' or 'accepted' | Pass |
SRC-5-2 | The "date" attribute of the <xccdf:status> element SHALL be populated with the date of the last status change. | Pass |
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.
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>
Derived Requirement # | Summary | Result |
---|---|---|
SRC-52-1 | OVAL content SHALL include the <oval:generator> and <oval:schema_version> elements. | Not Tested |
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.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-54-1 | All SCAP OVAL variables content that does not match the <oval-var:schema_version> of it corresponding OVAL definitions source it shall be considered in error. | Not Tested |
The referenced OVAL inventory class definition SHALL specify the technical procedure for determining whether or not a specific target asset is an instance of the CPE name specified by the <cpe2_dict:cpe-item> element. This usage is encouraged for CPE components.
If a <cpe2_dict:cpe-item> element contained in a CPE component references an OVAL inventory class definition, then that definition SHALL be resolved by an @href attribute referencing an OVAL source data stream component in the same data stream.
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.
Derived Requirement # | Summary | Result |
---|---|---|
SRC-74-1 | All CCE references SHOULD be in the official CCE dictionary. | Pass |
The following requirements and recommendations apply to the <xccdf:Benchmark> element:~The <xccdf:metadata> element SHALL be provided and SHALL, at minimum, contain the Dublin Core [DCES] terms from Table 14. If provided, additional Dublin Core terms SHALL follow the required terms within the element sequence.~Table 14 - Use of Dublin Core Terms in <xccdf:metadata>~Dublin Core Term~Description of Use~~<dc:creator>~The person, organization, and/or service that created the benchmark~~<dc:publisher>~The person, organization, and/or service that published the benchmark~~<dc:contributor>~The person, organization, and/or service that contributed to the creation of the benchmark~~<dc:source>~An identifier that indicates the organizational context of the benchmark's @id attribute. An organizationally specific URI SHOULD be used.~~
Derived Requirement # | Summary | Result |
---|---|---|
SRC-8-1 | xccdf:Benchmark/xccdf:metadata SHALL contain, at minimum, one of each of the Dublin Core terms <dc:creator>, <dc:publisher>, <dc:contributor>, <dc:source> | Pass |
SRC-8-2 | The <xccdf:metadata> element SHALL be provided in the <xccdf:Benchmark> element. | Pass |
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:title> element SHALL be provided. Each instance MUST contain a text value that briefly indicates the purpose of the containing element.
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).
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.
Derived Requirement # | Summary | Result |
---|---|---|
TOOL-141-1 | 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. | Not Tested |
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.
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.
Derived Requirement # | Summary | Result |
---|---|---|
TOOL-218-1 | 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. | Not Tested |
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:~For each <xccdf:check-content-ref> element, a content consumer either MUST attempt to retrieve the document referenced by the <ds:component-ref> element that is referenced directly by the <xccdf:check-content-ref> element's @href attribute, or it MUST resolve the @href attribute within the context of the XML Catalog specified as part of the <ds:component-ref> element used to reference this benchmark. If not resolvable, the next available <xccdf:check-content-ref> element SHALL be evaluated. If none of the <xccdf:check-content-ref> elements are resolvable, then the result of the rule evaluation SHALL be the XCCDF "notchecked" status and processing of the check SHALL end
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:~Once a resolvable <xccdf:check-content-ref> element is found, then check system processing SHALL proceed. When evaluating a rule, an <xccdf:rule-result/xccdf:message> with the @severity attribute value of "info" SHALL be generated, indicating the <xccdf:check-content-ref> @href attribute and @name attribute, if provided.
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.
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.
Derived Requirement # | Summary | Result |
---|---|---|
TOOL-269-1 | 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. | Not Tested |
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.
The <dsig:Signature> element MUST follow the recommendations in [TMSAD]
Derived Requirement # | Summary | Result |
---|---|---|
TOOL-283-1 | The <dsig:Signature> element MUST follow the recommendations in [TMSAD] SCAPVal runs the tmsad.1.0.sch schematron against SCAP content along with XML schema validation. | Not Tested |
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.
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>
Derived Requirement # | Summary | Result |
---|---|---|
TOOL-294-1 | 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> | Not Tested |
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:~The CPE SHALL be matched against all CPEs in all of the dictionaries referenced by the <ds:data-stream> element. All CPEs that return an EQUAL or SUPERSET result as defined in CPE Name Matching [CPE-M] SHALL be used in evaluating the <xccdf:platform> or <cpe2:fact-ref>.
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:~Either a list of CPEs found on the target asset MUST be known before the scan, or a list SHALL be generated. If a previously known list is used, it MUST be equivalent to a newly generated list. To generate the list, the <cpe2_dict:check> element data associated with the found <cpe2_dict:cpe-item> elements SHALL be evaluated against the target using the referenced OVAL inventory class definition. If a <cpe2_dict:check> returns "pass", then the corresponding CPE SHALL be added to the list of CPEs found on the target.
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:~The list of CPEs found on the target asset, along with the <xccdf:platform> or <cpe2:platform-specification> SHALL be used as input to the CPE Applicability Language [CPE-L] algorithm to determine the XCCDF Benchmark applicability to the target asset.
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
Derived Requirement # | Summary | Result |
---|---|---|
TOOL-298-1 | 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 | Not Tested |
The signature MUST be represented as a <dsig:Signature> element and MUST follow the W3C recommendation [DSIG].
Derived Requirement # | Summary | Result |
---|---|---|
TOOL-308-1 | The signature MUST be represented as a <dsig:Signature> element and MUST follow the W3C recommendation [DSIG]. SCAPVal runs the tmsad.1.0.sch schematron against SCAP content along with XML schema validation. | Not Tested |
The <dsig:Signature> element MUST follow the recommendations in [TMSAD]
Derived Requirement # | Summary | Result |
---|---|---|
TOOL-310-1 | The <dsig:Signature> element MUST follow the recommendations in [TMSAD] SCAPVal runs the tmsad.1.0.sch schematron against SCAP content along with XML schema validation. | Not Tested |
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 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.
Derived Requirement # | Summary | Result |
---|---|---|
TOOL-336-1 | 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. | Not Tested |
Also, for the component specifications, the Schematron file on the SCAP website SHALL be used in place of any corresponding Schematron file available elsewhere.
Derived Requirement # | Summary | Result |
---|---|---|
TOOL-337-1 | Also, for the component specifications, the Schematron file on the SCAP website SHALL be used in place of any corresponding Schematron file available elsewhere. | Not Tested |
All remaining OPTIONAL elements in the XCCDF schema MAY be included at the author's discretion unless otherwise noted in this document.
Derived Requirement # | Summary | Result |
---|---|---|
TOOL-340-1 | All remaining OPTIONAL elements in the XCCDF schema MAY be included at the author's discretion unless otherwise noted in this document. | Not Tested |
As stated in the XCCDF specification, the use of an <xccdf:Profile> element is not required.
Derived Requirement # | Summary | Result |
---|---|---|
TOOL-342-1 | As stated in the XCCDF specification, the use of an <xccdf:Profile> element is not required. | Not Tested |
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.
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:~~OCIL check system~OCIL questionnaires SHOULD NOT be used if OVAL can perform the same check correctly.
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:~~OCIL check system~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].
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:~The <xccdf:Rule> element that references an OVAL source data stream component SHALL have the @id attribute value of "xccdf_NAMESPACE_rule_security_patches_up_to_date", where NAMESPACE is the reverse DNS format namespace associated with the content maintainer.
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.
XCCDF group extension SHALL NOT be allowed.
Derived Requirement # | Summary | Result |
---|---|---|
TOOL-354-1 | XCCDF group extension SHALL NOT be allowed. SCAPVal does not implement this. | Not Tested |
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.
OCIL content SHOULD be used for checking rules that cannot be fully automated with OVAL.
Derived Requirement # | Summary | Result |
---|---|---|
TOOL-356-1 | OCIL content SHOULD be used for checking rules that cannot be fully automated with OVAL. | Not Tested |
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>_x000B__x000B_<ocil:reference href="http://cve.mitre.org">CVE_identifier</ocil:reference>_x000B__x000B_<ocil:reference href="http://cpe.mitre.org">CPE_identifier</ocil:reference>
As such, content authors MAY digitally sign source content following the guidelines in [TMSAD], along with the following requirements.
Derived Requirement # | Summary | Result |
---|---|---|
TOOL-359-1 | As such, content authors MAY digitally sign source content following the guidelines in [TMSAD], along with the following requirements. | Not Tested |
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.
Derived Requirement # | Summary | Result |
---|---|---|
TOOL-361-1 | 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. | Not Tested |
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.
Derived Requirement # | Summary | Result |
---|---|---|
TOOL-362-1 | 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. | Not Tested |
Validation of each component SHALL be done in accordance with the portions of this document that define requirements for the component.
Derived Requirement # | Summary | Result |
---|---|---|
TOOL-368-1 | Validation of each component SHALL be done in accordance with the portions of this document that define requirements for the component. | Not Tested |
The SCAP content must conform to all associated XML schemas. This requirement covers SCAP Component schema validation. SCAP Source Data Stream schema validation is covered under requirement SRC-329-1 SCAP Result Data Stream schema validation is covered under requirement RES-363-1
Derived Requirement # | Summary | Result |
---|---|---|
A-10-1 | XML content failed schema validation. | Not Tested |
Content failed validation against schematron validation.
Derived Requirement # | Summary | Result |
---|---|---|
A-14-1 | Content failed validation against schematron validation. | Not Tested |
Check for unused OVAL definitions.
Derived Requirement # | Summary | Result |
---|---|---|
A-15-1 | Unused OVAL definitions exist. | Pass |
This is an additional, common-sense check.
Derived Requirement # | Summary | Result |
---|---|---|
A-16-1 | CCE number is expected, but missing as a reference | Pass |
This is an additional, common-sense check.
Derived Requirement # | Summary | Result |
---|---|---|
A-17-1 | CCE number is in an invalid format or the check-digit does not match. It should be of format CCE-XXXX-X or CCE-XXXXX-X where each X is a digit, and the final X is a check-digit. | Pass |
This is an additional, common-sense check.
This requirement is intended to help the end-user, but it isn't required for content to pass validation.
Derived Requirement # | Summary | Result |
---|---|---|
A-21-1 | The OVAL test type is not checked in the NIST SCAP Validation Program. | Informational |
This requirement is intended to help the end-user, but it isn't required for content to pass validation.
Derived Requirement # | Summary | Result |
---|---|---|
A-22-1 | A custom XPath function is not available | Informational |
The content contains an XML element in a namespace that is not governed by one of the officially supported SCAP specifications.
This is an extension of requirement 300-1. If the arf-report does not include a source data stream it will print a warning to the user stating that they can manually specify a source data-stream with a command.
This requirement for unique xccdf:Profile @id cannot be handled by the XCCDF schema in SCAP source data streams. There is no direct reference to the req in 800-126r2 but this still needs to be checked.
Derived Requirement # | Summary | Result |
---|---|---|
A-25-1 | The @id attribute of all <xccdf:Profile> elements in a SCAP source data stream must be unique. | Pass |
Some parsers automatically fill in the values of default attributes before signing content, so if default attributes are not provided, signature verification will fail for other parsers that do not automatically fill in the values. If all default attributes are not explicitly defined when digitally signing SCAP content, certain parsers may fail to process the data stream signing correctly. This could lead to processing errors or a failure to recognize the legitimacy of signed content.
Derived Requirement # | Summary | Result |
---|---|---|
A-26-1 | Explicitly provide values for all default attributes instead of assuming the default value. | Warning |
# | Test Result | Message | Context (Line/Column) |
---|---|---|---|
1 | Fail | ' - TEST: exists(@selected) and exists(@weight) and exists(@role) and exists(@severity)' | 76 : 84 |
|
|||
2 | Fail | ' - TEST: exists(@selected) and exists(@weight) and exists(@role) and exists(@severity)' | 84 : 84 |
|
|||
3 | Fail | ' - TEST: exists(@selected) and exists(@weight) and exists(@role) and exists(@severity)' | 92 : 84 |
|
|||
4 | Fail | ' - TEST: exists(@selected) and exists(@weight) and exists(@role) and exists(@severity)' | 100 : 84 |
|
|||
5 | Fail | ' - TEST: exists(@selected) and exists(@weight) and exists(@role) and exists(@severity)' | 108 : 84 |
|
|||
6 | Fail | ' - TEST: exists(@selected) and exists(@weight) and exists(@role) and exists(@severity)' | 116 : 84 |
|
|||
7 | Fail | ' - TEST: exists(@selected) and exists(@weight) and exists(@role) and exists(@severity)' | 124 : 84 |
|
|||
8 | Fail | ' - TEST: exists(@selected) and exists(@weight) and exists(@role) and exists(@severity)' | 132 : 84 |
|
|||
9 | Fail | ' - TEST: exists(@selected) and exists(@weight) and exists(@role) and exists(@severity)' | 140 : 84 |
|
|||
10 | Fail | ' - TEST: exists(@selected) and exists(@weight) and exists(@role) and exists(@severity)' | 148 : 85 |
|
|||
Omitting 25 additional results. |