Validation Details
Target:
file:/z:/utilities/scapval-1.3.0-SNAPSHOT-scapval/r2920-datastream.xml
Start:
September 12th, 2017 15:33:30 GMT-4
End:
September 12th, 2017 15:33:35 GMT-4
Type:
SCAP 1.2 Source
Version:
scapval-1.3.0-SNAPSHOT
Notes:
  • Validation occurred while in OFFLINE mode.
Validation Overview
Validation Summary
Total Requirements:
62
Applicable Requirements:
54
Requirements Passed:
52 of 52
Requirements Failed:
0 of 52
Tests Failed:
35
Overall Result:
Pass

Validation Result Summary

Requirement # Summary Result
SRC-10 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. Pass
SRC-118 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 ". Pass
SRC-15 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. Pass
SRC-169 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. Pass
SRC-175 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> Pass
SRC-2 The following requirements and recommendations apply to the <xccdf:Benchmark> element:~The <xccdf:Benchmark> element SHALL have an @xml:lang attribute. Pass
SRC-207 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". Pass
SRC-208 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. Pass
SRC-209 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". Pass
SRC-210 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. Pass
SRC-213 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. Pass
SRC-214 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". Pass
SRC-215 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. Pass
SRC-216 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. Pass
SRC-236 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. Pass
SRC-242 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. Pass
SRC-248 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. Pass
SRC-25 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. Pass
SRC-251 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. Pass
SRC-257 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. Pass
SRC-262 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. Pass
SRC-265 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. Pass
SRC-276 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 Pass
SRC-282 Each <dsig:Signature> element MUST sign only one data stream Not Applicable
SRC-284 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. Not Applicable
SRC-285 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] Not Applicable
SRC-286 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
SRC-287 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. Not Applicable
SRC-288 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> Not Applicable
SRC-290 Key information SHOULD be provided on the <dsig:Signature> element. Not Applicable
SRC-3 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. Pass
SRC-30 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. Pass
SRC-31 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. Pass
SRC-324 The @use-case attribute in the <ds:data-stream> element MUST be set to "CONFIGURATION". Pass
SRC-329 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. Pass
SRC-33 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. Pass
SRC-330 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. Pass
SRC-331 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~~ Pass
SRC-333 Any component in a data stream collection SHALL be referenced not more than once by any data stream in that collection. Pass
SRC-339 XInclude elements SHALL NOT be included in XCCDF content [XINCLUDE]. Pass
SRC-341 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. Pass
SRC-343 Use of the <xccdf:set-complex-value> element within the <xccdf:Profile> element SHALL NOT be allowed. Pass
SRC-345 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. Pass
SRC-346 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. Pass
SRC-348 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. Pass
SRC-349 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. Pass
SRC-351 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. Pass
SRC-38 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~~ Pass
SRC-4 The following requirements and recommendations apply to the <xccdf:Benchmark> element:~The @style attribute SHOULD have the value "SCAP_1.2". Pass
SRC-5 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. Pass
SRC-72 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. Pass
SRC-74 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. Pass
SRC-8 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.~~ Pass
SRC-9 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. Pass
A-15 Check for unused OVAL definitions. Pass
A-16 This is an additional, common-sense check. Pass
A-17 This is an additional, common-sense check. Pass
A-18 This is an additional, common-sense check. Not Applicable
A-21 This requirement is intended to help the end-user, but it isn't required for content to pass validation. Informational
A-22 This requirement is intended to help the end-user, but it isn't required for content to pass validation. Informational
A-25 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. Pass
A-26 Explicitly specify all default attributes when creating content that will be signed. Warning
Not Tested

RES-126  

Requirement

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

Section 4.5.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Derived Requirement # Summary Result
RES-126-1 If the <xccdf:result> value for a <xccdf:rule-result> is 'error', 'unknown', 'notapplicable', or 'notchecked', then the result of at least one OVAL definition referenced by that rule SHALL be 'error', 'unknown', 'not applicable', or 'not evaluated', respectively. If the <xccdf:result> value is 'fail' then the result of at least one of the OVAL definitions referenced SHALL match the fail category as defined in the SCAP table. If the <xccdf:result> value is 'pass' then the result of all of the OVAL definitions referenced SHALL match the pass category as defined in the SCAP table. Not Tested
RES-126-2 The @class attribute of an OVAL definition used in a check cannot be found. scapval may not be able to properly verify OVAL result to XCCDF result mapping. If you have the source content containing the OVAL definition, try the -sourceds option to include it. Not Tested
RES-126-3 If the <xccdf:result> value for a <xccdf:rule-result> is 'notapplicable' and OVAL definitions apply, then the OVAL definition referenced by that rule is expected to be 'not applicable' or 'not evaluated'. Not Tested
RES-126-4 If OVAL results component contain multiple instances of the same OVAL definition, SCAPVal cannot verify the mappings between OVAL results to XCCDF results. Not Tested
RES-126-5 If <xccdf:check-content-ref> @name is not present, the <xccdf:Rule> referenced should also contain no @name reference and should not contain @multi-check="true". Not Tested
Not Tested

RES-126-1   If the <xccdf:result> value for a <xccdf:rule-result> is 'error', 'unknown', 'notapplicable', or 'notchecked', then the result of at least one OVAL definition referenced by that rule SHALL be 'error', 'unknown', 'not applicable', or 'not evaluated', respectively. If the <xccdf:result> value is 'fail' then the result of at least one of the OVAL definitions referenced SHALL match the fail category as defined in the SCAP table. If the <xccdf:result> value is 'pass' then the result of all of the OVAL definitions referenced SHALL match the pass category as defined in the SCAP table.

Not Tested

RES-126-2   The @class attribute of an OVAL definition used in a check cannot be found. scapval may not be able to properly verify OVAL result to XCCDF result mapping. If you have the source content containing the OVAL definition, try the -sourceds option to include it.

Not Tested

RES-126-3   If the <xccdf:result> value for a <xccdf:rule-result> is 'notapplicable' and OVAL definitions apply, then the OVAL definition referenced by that rule is expected to be 'not applicable' or 'not evaluated'.

Not Tested

RES-126-4   If OVAL results component contain multiple instances of the same OVAL definition, SCAPVal cannot verify the mappings between OVAL results to XCCDF results.

Not Tested

RES-126-5   If <xccdf:check-content-ref> @name is not present, the <xccdf:Rule> referenced should also contain no @name reference and should not contain @multi-check="true".

Not Tested

RES-133  

Requirement

The @start-time and @end-time attributes SHALL be provided to indicate when the scan started and completed, respectively.

Section 4.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-133-1   The @start-time and @end-time attributes SHALL be provided to indicate when the scan started and completed, respectively.

Not Tested

RES-134  

Requirement

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.

Section 4.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-134-1   The @test-system attribute SHALL be provided with a CPE Name value indicating the product that evaluated the checklist.

Not Tested

RES-136  

Requirement

Each IP address associated with the <xccdf:target> SHALL be enumerated using the <xccdf:target-address> element.

Section 4.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

RES-137  

Requirement

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

Section 4.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-137-1   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~~

Not Tested

RES-138  

Requirement

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.

Section 4.5.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Derived Requirement # Summary Result
RES-138-1 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. Not Tested
Not Tested

RES-138-1   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.

Not Tested

RES-179  

Requirement

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

Section 4.6 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-179-1   The <oval-res:directives> element SHALL be:<definition_true content="full" reported="true"/>~<definition_false content="full" reported="true"/>~<definition_unknown content="full" reported="true"/>~<definition_error content="full" reported="true"/>~<definition_not_evaluated content="full" reported="true"/>~<definition_not_applicable content="full" reported="true"/> or <definition_true reported="true"/>~<definition_false reported="true"/>~<definition_unknown reported="true"/>~<definition_error reported="true"/>~<definition_not_evaluated reported="true"/>~<definition_not_applicable reported="true"/> or <definition_true content="thin" reported="true"/>~<definition_false content="thin" reported="true"/>~<definition_unknown content="thin" reported="true"/>~<definition_error content="thin" reported="true"/>~<definition_not_evaluated content="thin" reported="true"/>~<definition_not_applicable content="thin" reported="true"/>

Not Tested

RES-180  

Requirement

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.

Section 4.6 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-181  

Requirement

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.

Section 4.6 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-181-1   Error if oval-res directives definitions have @content='full' or @content is not provided and oval-res:oval_system_characteristics does not have both oval-res:collected_objects and oval-res:system_data. In that case it is Single Machine Without System Characteristics.

Not Tested

RES-182  

Requirement

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

Section 4.6 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-235  

Requirement

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.

Section 4.7 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-235-1   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.

Not Tested

RES-253  

Requirement

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.

Section 4.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

RES-255  

Requirement

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.

Section 4.5.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-255-1   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.

Not Tested

RES-258  

Requirement

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.

Section 4.5.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Derived Requirement # Summary Result
RES-258-1 This requirement was not tested but the user should check their content for adherence. Not Tested
Not Tested

RES-258-1   This requirement was not tested but the user should check their content for adherence.

Not Tested

RES-260  

Requirement

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.

Section 4.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-260-1   Every <xccdf:rule-result> other than 'notapplicable', 'notchecked', or 'notselected' must have a <xccdf:check>/<xccdf:check-content-ref> that has attributes @href and @name. One exception is when the referenced <xccdf:Rule> contains @multi-check=false(the default) and has no @name.

Not Tested

RES-271  

Requirement

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.

Section 4.5.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

RES-299  

Requirement

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

Section 4.4.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

RES-300  

Requirement

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

Section 4.4.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

RES-301  

Requirement

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

Section 4.4.4 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

Not Tested

RES-304  

Requirement

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.

Section 4.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-304-1   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.

Not Tested

RES-304-2   NIST SP800-126 errata has updated the "arf-rel" namespace to http://scap.nist.gov/specifications/arf/vocabulary/relationships/1.0# The original namespace of http://scap.nist.gov/vocabulary/arf/relationships/1.0# has been detected.

Not Tested

RES-306  

Requirement

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.

Section 4.6 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-306-1   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.

Not Tested

RES-307  

Requirement

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

Section 4.8 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

Not Tested

RES-309  

Requirement

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

Section 4.8 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Derived Requirement # Summary Result
RES-309-1 The <dsig:Signature> element MUST sign the ARF report collection root element. Not Tested
Not Tested

RES-309-1   The <dsig:Signature> element MUST sign the ARF report collection root element.

Not Tested

RES-311  

Requirement

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

Section 4.8 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

RES-312  

Requirement

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

Section 4.8 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

RES-313  

Requirement

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.

Section 4.8 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-313-1   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.

Not Tested

RES-315  

Requirement

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

Section 4.8 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Derived Requirement # Summary Result
RES-315-1 Key information SHOULD be provided on the <dsig:Signature> element. Not Tested
Not Tested

RES-315-1   Key information SHOULD be provided on the <dsig:Signature> element.

Not Tested

RES-316  

Requirement

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.

Section 4.8 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-316-1   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.

Not Tested

RES-318  

Requirement

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>

Section 4.8 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-318-1   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>

Not Tested

RES-319  

Requirement

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>

Section 4.8 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-319-1   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>

Not Tested

RES-320  

Requirement

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

Section 4.8 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-320-1   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].

Not Tested

RES-321  

Requirement

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

Section 4.8 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-321-1   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].

Not Tested

RES-322  

Requirement

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.

Section 4.8 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-322-1   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.

Not Tested

RES-323  

Requirement

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

Section 4.8 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

RES-363  

Requirement

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

Section 4.4 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-363-1   An SCAP result data stream SHALL conform to the [ARF] specification. SCAPVal performs the Schema validation against SCAP results [ARF] content.

Not Tested

RES-363-2   An SCAP result data stream SHALL conform to the [ARF] specification. SCAPVal performs the Schematron validation against SCAP results [ARF] content. SCAP schematrons have their own associated IDs and will be used in the results.

Not Tested

RES-364  

Requirement

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.

Section 4.4 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-364-1   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.

Not Tested

RES-365  

Requirement

It MAY contain additional report objects for other results, such as <oval-var:oval_variables> or extended component results.

Section 4.4.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-365-1   It MAY contain additional report objects for other results, such as <oval-var:oval_variables> or extended component results.

Not Tested

RES-366  

Requirement

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.

Section 4.4.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-366-1   This requirement was not tested. The user should visually inspect SCAP results to verify that the ARF report contains a report object for each XCCDF, OVAL, and OCIL component executed when a source data stream is evaluated against a target. Each component result SHALL be captured as a separate <arf:report> element in the <arf:asset-report-collection> element.

Not Tested

RES-367  

Requirement

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

Section 4.4.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-367-1   Each SCAP result data stream component SHOULD NOT use any constructs that are deprecated in its associated specification.

Not Tested

RES-369  

Requirement

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.

Section 4.4.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

RES-370  

Requirement

The @href attribute SHALL contain "#" + the @id of the <arf:report> containing the check result. This approach provides traceability between XCCDF and check results.

Section 4.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

RES-371  

Requirement

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.

Section 4.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

RES-42  

Requirement

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.

Section 4.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-42-1   At least one <xccdf:identity> element SHALL be provided and SHALL contain text to identify the security principal.

Not Tested

RES-44  

Requirement

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.

Section 4.5.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

RES-44-1   If the target <xccdf:Rule> identified by the <xccdf:rule-result idref=""> attribute has one or more <ident> elements with the "http://cve.mitre.org" or "http://cpe.mitre.org" or "http://cpe.mitre.org" system identifier, then each <xccdf:ident> element SHALL also appear within the <xccdf:rule-result> element.

Not Tested

RES-68  

Requirement

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

Section 4.5.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

Not Tested

RES-69  

Requirement

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

Section 4.6 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

RES-70  

Requirement

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.

Section 4.6 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

Pass

SRC-10  

Requirement

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.

Section 3.2.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-10-1   For each <xccdf:Benchmark>, <xccdf:Profile>, <xccdf:Value>, <xccdf:Group>, and <xccdf:Rule> element, a <xccdf:description> SHALL be provided.

Pass

SRC-118  

Requirement

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

Section 3.2.4.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-118-1   @system on <xccdf:check> MUST be "http://oval.mitre.org/XMLSchema/oval-definitions-5" or "http://scap.nist.gov/schema/ocil/2"

Pass

SRC-118-2   @system on <cpe-dict:check> MUST be "http://oval.mitre.org/XMLSchema/oval-definitions-5" or "http://scap.nist.gov/schema/ocil/2"

Not Applicable

SRC-118-3   @system on <cpe-lang:check-fact-ref> MUST be "http://oval.mitre.org/XMLSchema/oval-definitions-5" or "http://scap.nist.gov/schema/ocil/2"

Not Tested

SRC-119  

Requirement

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

Section 3.2.4.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-125  

Requirement

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

Section 3.2.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-125-1   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"/>

Not Tested

SRC-131  

Requirement

XCCDF test results SHALL be documented as the contents of an <xccdf:TestResult> element.

Section 4.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Derived Requirement # Summary Result
SRC-131-1 XCCDF test results SHALL be documented as the contents of an <xccdf:TestResult> element. Not Tested
Not Tested

SRC-131-1   XCCDF test results SHALL be documented as the contents of an <xccdf:TestResult> element.

Not Tested

SRC-149  

Requirement

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>

Section 3.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-149-1   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>

Pass

SRC-15  

Requirement

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.

Section 3.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

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.

Not Tested

SRC-150  

Requirement

CVE references in SCAP content MAY include both "candidate" and "entry" status identifiers.

Section 3.7 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-150-1   CVE references in SCAP content MAY include both "candidate" and "entry" status identifiers.

Not Tested

SRC-151  

Requirement

Deprecated CVE identifiers SHALL NOT be used.

Section 3.7 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Derived Requirement # Summary Result
SRC-151-1 Deprecated CVE identifiers SHALL NOT be used. Not Tested
Not Tested

SRC-151-1   Deprecated CVE identifiers SHALL NOT be used.

Not Tested

SRC-152  

Requirement

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.

Section 3.7 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-152-1   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.

Not Tested

SRC-154  

Requirement

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

Section 3.1.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-154-1   Each SCAP source data stream component SHALL use one of the elements specified in Table 12 as its document element.

Pass

SRC-169  

Requirement

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.

Section 3.2.4.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-169-1   An xccdf:Rule with @id "xccdf_NAMESPACE_rule_security_patches_up_to_date" MUST reference an OVAL component that contains an oval definition of class 'patch'. If your content contains external references, SCAPVal will attempt to resolve it in -online mode.

Not Tested

SRC-171  

Requirement

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.

Section 3.2.4.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-171-1   If a <xccdf:check-content-ref> is in a security patches up-to-date rule then the @name SHALL be omitted from the <xccdf:check-content-ref>. This requirement was removed in SCAP Schematron version 1.1. Note: Nothing to enforce based on Errata E4.

Pass

SRC-175  

Requirement

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>

Section 3.2.4.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-175-1   At least one <xccdf:check-content-ref> element MUST be provided in each <xccdf:check>

Pass

SRC-2  

Requirement

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

Section 3.2.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Derived Requirement # Summary Result
SRC-2-1 @xml:lang attribute SHALL be provided on <xccdf:Benchmark> elements. Pass
Pass

SRC-2-1   @xml:lang attribute SHALL be provided on <xccdf:Benchmark> elements.

Not Tested

SRC-206  

Requirement

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

Section 3.2.4.4 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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.

Pass

SRC-207  

Requirement

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

Section 3.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-207-1   OVAL definitions of class 'compliance' should include a reference to a CCE, where applicable.

Pass

SRC-208  

Requirement

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.

Section 3.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-208-1   For OVAL definitions of @class 'compliance', only definitions of class 'compliance' or 'inventory' can be extended.

Pass

SRC-209  

Requirement

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

Section 3.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-209-1   OVAL definitions of class 'inventory' should include a reference to a CPE, where applicable.

Pass

SRC-210  

Requirement

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.

Section 3.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-210-1   For OVAL definitions of @class 'inventory', only definitions of class 'inventory' can be extended.

Not Tested

SRC-211  

Requirement

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

Section 3.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

SRC-212  

Requirement

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

Section 3.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-212-1   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"/>

Pass

SRC-213  

Requirement

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.

Section 3.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-213-1   For OVAL definitions of @class 'patch', only definitions of class 'patch' or 'inventory' can be extended.

Pass

SRC-214  

Requirement

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

Section 3.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-214-1   OVAL definitions of class 'vulnerability' should include a reference to a CVE, where applicable.

Pass

SRC-215  

Requirement

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.

Section 3.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-215-1   For OVAL definitions of @class 'vulnerability', only definitions of class 'inventory' or 'vulnerability' can be extended.

Pass

SRC-216  

Requirement

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.

Section 4.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

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

Not Tested

SRC-227  

Requirement

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

Section 3.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-227-1   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).

Not Tested

SRC-228  

Requirement

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.

Section 3.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

SRC-229  

Requirement

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.

Section 3.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

SRC-230  

Requirement

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.

Section 3.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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.

Pass

SRC-236  

Requirement

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.

Section 5.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-236-1   For this CONFIGURATION @use-case, unable to find at least one <xccdf:Benchmark> element referenced in the <ds:checklists> child elements. Check your <ds:component-ref> @xlink:href values for validity. If your content contains external references, SCAPVal will attempt to resolve it in -online mode.

Pass

SRC-236-2   Each xccdf:Rule must reference at least one of the follow items: OVAL compliance class, OCIL Questionnaire, OVAL patch class

Pass

SRC-242  

Requirement

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.

Section 5.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-242-1   For this VULNERABILITY @use-case, unable to find at least one <xccdf:Benchmark> element referenced in the <ds:checklists> child elements. Check your <ds:component-ref> @xlink:href values for validity. If your content contains external references, SCAPVal will attempt to resolve it in -online mode.

Pass

SRC-242-2   Each xccdf:Rule must reference at least one of the follow components: OVAL vulnerability class, OCIL Questionnaire, OVAL patch class

Pass

SRC-248  

Requirement

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.

Section 5.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-248-1   For this INVENTORY @use-case, unable to find at least one <xccdf:Benchmark> element referenced in the <ds:checklists> child elements. Check your <ds:component-ref> @xlink:href values for validity. If your content contains external references, SCAPVal will attempt to resolve it in -online mode.

Pass

SRC-248-2   Each xccdf:Rule must reference at least one OVAL definition in CPE_INVENTORY

Pass

SRC-25  

Requirement

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.

Section 3.2.4.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Derived Requirement # Summary Result
SRC-25-1 A XCCDF document SHALL NOT contain an <xccdf:check-content> element Pass
Pass

SRC-25-1   A XCCDF document SHALL NOT contain an <xccdf:check-content> element

Pass

SRC-251  

Requirement

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.

Section 3.2.4.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

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

SRC-257  

Requirement

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.

Section 3.2.4.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

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

SRC-262  

Requirement

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.

Section 5.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-262-1   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 Questionnaire component. If your content contains external references, SCAPVal will attempt to resolve it in -online mode.

Not Tested

SRC-263  

Requirement

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

Section 5.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

Pass

SRC-265  

Requirement

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.

Section 5.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

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.

Not Tested

SRC-266  

Requirement

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

Section 5.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

SRC-267  

Requirement

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

Section 3.1.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

Not Tested

SRC-275  

Requirement

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.

Section 3.2.4.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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.

Pass

SRC-276  

Requirement

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

Section 3.2.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-276-1   The 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, the use of the <xccdf:complex-choice> element SHALL NOT be allowed

Not Tested

SRC-278  

Requirement

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

Section 3.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-279  

Requirement

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.

Section 3.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-280  

Requirement

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.

Section 3.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-281  

Requirement

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

Section 3.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-281-1   Each signature MUST be represented as a <dsig:Signature> element and follow the W3C recommendation [DSIG].

Not Applicable

SRC-282  

Requirement

Each <dsig:Signature> element MUST sign only one data stream

Section 3.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Derived Requirement # Summary Result
SRC-282-1 Each <dsig:Signature> element MUST sign only one data stream Not Applicable
Not Applicable

SRC-282-1   Each <dsig:Signature> element MUST sign only one data stream

Not Applicable

SRC-284  

Requirement

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.

Section 3.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Applicable

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

SRC-285  

Requirement

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]

Section 3.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Applicable

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

SRC-286  

Requirement

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>

Section 3.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Applicable

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

SRC-287  

Requirement

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.

Section 3.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Applicable

SRC-287-1   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.

Not Applicable

SRC-288  

Requirement

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>

Section 3.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Applicable

SRC-288-1   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>

Not Tested

SRC-289  

Requirement

<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

Section 3.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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 Applicable

SRC-290  

Requirement

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

Section 3.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Derived Requirement # Summary Result
SRC-290-1 Key information SHOULD be provided on the <dsig:Signature>. Not Applicable
Not Applicable

SRC-290-1   Key information SHOULD be provided on the <dsig:Signature>.

Pass

SRC-3  

Requirement

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.

Section 3.2.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-3-1   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.

Pass

SRC-3-2   The @time attribute of the <xccdf:version> element SHOULD be used for a timestamp of when the benchmark was defined.

Pass

SRC-3-3   The @id and <xccdf:version> together MUST uniquely identify an xccdf:Benchmark in a <scap:data-stream-collection>

Pass

SRC-30  

Requirement

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.

Section 5.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-30-1   If an XCCDF referenced from a data stream contains an <xccdf:platform> or <cpe-lang:fact-ref>, then a CPE dictionary component must be reference from the same data stream, and an OVAL component with a definition of class "inventory" must also be referenced.

Pass

SRC-31  

Requirement

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.

Section 3.2.4.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-31-1   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. If your content contains external references, SCAPVal will attempt to resolve it in -online mode.

Not Tested

SRC-314  

Requirement

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>

Section 4.8 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-314-1   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>

Not Tested

SRC-317  

Requirement

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>

Section 4.8 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-317-1   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>

Pass

SRC-324  

Requirement

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

Section 5.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-324-1   The @use-case attribute in the <ds:data-stream> element MUST be set to "CONFIGURATION", "VULNERABILITY", "INVENTORY" or "OTHER"

Not Tested

SRC-325  

Requirement

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

Section 5.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-327  

Requirement

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

Section 5.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-329  

Requirement

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.

Section 3.1.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-329-1   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. SCAPVal performs the Schema validation against source data streams. Result Schema issues are reported under requirement ID RES-363 Component Schema issues are reported under requirement ID A-10

Pass

SRC-33  

Requirement

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.

Section 5.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-33-1   If an XCCDF referenced from a data stream contains an <xccdf:platform> or <cpe-lang:fact-ref>, then a CPE dictionary component must be reference from the same data stream, and an OVAL component with a definition of class "inventory" must also be referenced.

Pass

SRC-330  

Requirement

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.

Section 3.1.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-330-1   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. SCAPVal performs the schematron rules validation.

Pass

SRC-330-2   For the SCAP source data stream collection, it SHOULD also validate against the latest Schematron rules. SCAPVal will always validate with the latest rules per SCAP version.

Pass

SRC-330-3   If applicable, each component MUST validate against its associated Schematron stylesheet. SCAPVal will run the appropriate schematron against the components.

Test Details

# 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()' 24 : 345  
<data-stream-collection id="scap_gov.nist_collection_r2920-datastream.zip" schematron-version="1.2" xsi:schemaLocation="http://scap.nist.gov/schema/scap/source/1.2 http://scap.nist.gov/schema/scap/1.2/scap-source-data-stream_1.2.xsd">
...
<component id="scap_gov.nist_comp_r2920-xccdf.xml" timestamp="2017-05-15T14:00:00">
...
<xccdf:Benchmark id="xccdf_gov.nist_benchmark_r2920" style="SCAP_1.2" xml:lang="en" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.2 http://scap.nist.gov/schema/xccdf/1.2/xccdf_1.2.xsd http://cpe.mitre.org/dictionary/2.0 http://scap.nist.gov/schema/cpe/2.3/cpe-dictionary_2.3.xsd">
<xccdf:status date="2017-05-15">
</xccdf:status>
<xccdf:title>
</xccdf:title>
<xccdf:description>
</xccdf:description>
<xccdf:version time="2017-05-15T14:00:00" update="http://scap.nist.gov/validation/resources.html">
</xccdf:version>
<xccdf:metadata>
...
</xccdf:metadata>
<xccdf:Profile id="xccdf_gov.nist.validation_profile_r2920" prohibitChanges="1">
...
</xccdf:Profile>
<xccdf:Rule id="xccdf_gov.nist_rule_validation.r2920_rule_1" selected="true">
...
</xccdf:Rule>
<xccdf:Rule id="xccdf_gov.nist_rule_validation.r2920_rule_2" selected="true">
...
</xccdf:Rule>
<xccdf:Rule id="xccdf_gov.nist_rule_validation.r2920_rule_3" selected="true">
...
</xccdf:Rule>
<xccdf:Rule id="xccdf_gov.nist_rule_validation.r2920_rule_4" selected="true">
...
</xccdf:Rule>
... [other children omitted for brevity]
</xccdf:Benchmark>
</component>
</data-stream-collection>
2 Informational ' DEPRECATED ATTRIBUTE VALUE IN: variable_test ATTRIBUTE VALUE: none exist - TEST: @check='none exist'' 880 : 246  
<data-stream-collection id="scap_gov.nist_collection_r2920-datastream.zip" schematron-version="1.2" xsi:schemaLocation="http://scap.nist.gov/schema/scap/source/1.2 http://scap.nist.gov/schema/scap/1.2/scap-source-data-stream_1.2.xsd">
...
<component id="scap_gov.nist_comp_r2920-oval.xml" timestamp="2017-05-15T14:00:00">
...
<oval_definitions xsi:schemaLocation="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows http://oval.mitre.org/language/download/schema/version5.8/ovaldefinition/complete/windows-definitions-schema.xsd http://oval.mitre.org/XMLSchema/oval-definitions-5#independent http://oval.mitre.org/language/download/schema/version5.8/ovaldefinition/complete/independent-definitions-schema.xsd http://oval.mitre.org/XMLSchema/oval-definitions-5 http://oval.mitre.org/language/download/schema/version5.8/ovaldefinition/complete/oval-definitions-schema.xsd http://oval.mitre.org/XMLSchema/oval-common-5 http://oval.mitre.org/language/download/schema/version5.8/ovaldefinition/complete/oval-common-schema.xsd">
...
<tests>
...
<variable_test check="none exist" check_existence="none_exist" comment="Test to see that the value equals foo.bar." id="oval:nist.validation.r2920:tst:8" version="2">
<object object_ref="oval:nist.validation.r2920:obj:13"/>
</variable_test>
...
</tests>
</oval_definitions>
</component>
</data-stream-collection>
3 Informational ' DEPRECATED ATTRIBUTE VALUE IN: variable_test ATTRIBUTE VALUE: none exist - TEST: @check='none exist'' 899 : 258  
<data-stream-collection id="scap_gov.nist_collection_r2920-datastream.zip" schematron-version="1.2" xsi:schemaLocation="http://scap.nist.gov/schema/scap/source/1.2 http://scap.nist.gov/schema/scap/1.2/scap-source-data-stream_1.2.xsd">
...
<component id="scap_gov.nist_comp_r2920-oval.xml" timestamp="2017-05-15T14:00:00">
...
<oval_definitions xsi:schemaLocation="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows http://oval.mitre.org/language/download/schema/version5.8/ovaldefinition/complete/windows-definitions-schema.xsd http://oval.mitre.org/XMLSchema/oval-definitions-5#independent http://oval.mitre.org/language/download/schema/version5.8/ovaldefinition/complete/independent-definitions-schema.xsd http://oval.mitre.org/XMLSchema/oval-definitions-5 http://oval.mitre.org/language/download/schema/version5.8/ovaldefinition/complete/oval-definitions-schema.xsd http://oval.mitre.org/XMLSchema/oval-common-5 http://oval.mitre.org/language/download/schema/version5.8/ovaldefinition/complete/oval-common-schema.xsd">
...
<tests>
...
<variable_test check="none exist" check_existence="none_exist" comment="Test to see that the var_ref is not equal to foo.bar." id="oval:nist.validation.r2920:tst:13" version="2">
<object object_ref="oval:nist.validation.r2920:obj:1"/>
</variable_test>
...
</tests>
</oval_definitions>
</component>
</data-stream-collection>
Pass

SRC-331  

Requirement

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

Section 3.2.4.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-331-1   If an <xccdf:Rule> has an <xccdf:ident> with a CCE and that rule reference an OVAL definition, the definition SHALL have @class 'compliance'.

Pass

SRC-331-2   If an <xccdf:Rule> has an <xccdf:ident> with a CVE and that rule reference an OVAL definition, the definition SHALL have @class 'vulnerability'.

Pass

SRC-331-3   If an <xccdf:Rule> has an <xccdf:ident> with a CPE and that rule reference an OVAL definition, the definition SHALL have @class 'inventory'.

Not Tested

SRC-332  

Requirement

Content authors MAY place components in any order.

Section 3.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Derived Requirement # Summary Result
SRC-332-1 Content authors MAY place components in any order. Not Tested
Not Tested

SRC-332-1   Content authors MAY place components in any order.

Pass

SRC-333  

Requirement

Any component in a data stream collection SHALL be referenced not more than once by any data stream in that collection.

Section 3.1.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-333-1   Any component in a data stream collection SHALL be referenced not more than once by any data stream in that collection.

Not Tested

SRC-334  

Requirement

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.

Section 3.1.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-338  

Requirement

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

Section 3.1.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-338-1   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].

Pass

SRC-339  

Requirement

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

Section 3.2.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Derived Requirement # Summary Result
SRC-339-1 XInclude elements SHALL NOT be included in XCCDF content [XINCLUDE]. Pass
Pass

SRC-339-1   XInclude elements SHALL NOT be included in XCCDF content [XINCLUDE].

Pass

SRC-341  

Requirement

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.

Section 3.2.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Derived Requirement # Summary Result
SRC-341-1 @update on <xccdf:version> SHOULD be specified Pass
Pass

SRC-341-1   @update on <xccdf:version> SHOULD be specified

Pass

SRC-343  

Requirement

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

Section 3.2.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

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

Pass

SRC-345  

Requirement

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.

Section 3.2.4.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

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

SRC-346  

Requirement

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.

Section 3.2.4.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-346-1   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.

Pass

SRC-348  

Requirement

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.

Section 3.2.4.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-348-1   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.

Pass

SRC-349  

Requirement

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.

Section 3.2.4.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-349-1   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.

Pass

SRC-351  

Requirement

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.

Section 3.2.4.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Derived Requirement # Summary Result
SRC-351-1 Only OVAL and OCIL are supported check systems Pass
Pass

SRC-351-1   Only OVAL and OCIL are supported check systems

Not Tested

SRC-358  

Requirement

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.

Section 3.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-360  

Requirement

One or more XML digital signatures MAY be included as the last elements in the SCAP source data stream collection root element.

Section 3.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

SRC-376  

Requirement

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.

Section 5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-376-1   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.

Pass

SRC-38  

Requirement

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

Section 3.2.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-38-1   Values of XCCDF datatype 'number', when bound to OVAL variables, the OVAL variables must be of the following OVAL types: int, float

Pass

SRC-38-2   Values of XCCDF datatype 'boolean', when bound to OVAL variables, the OVAL variables must be the following OVAL type: boolean

Pass

SRC-38-3   Values of XCCDF datatype 'string', when bound to OVAL variables, the OVAL variables must be of the following OVAL types: string, evr_string, version, ios_version, fileset_revision, binary

Pass

SRC-4  

Requirement

The following requirements and recommendations apply to the <xccdf:Benchmark> element:~The @style attribute SHOULD have the value "SCAP_1.2".

Section 3.2.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-4-1   The style attribute of the <xccdf:Benchmark> element SHOULD contain the value "SCAP_1.2".

Pass

SRC-5  

Requirement

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.

Section 3.2.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

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.

Not Tested

SRC-51  

Requirement

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.

Section 3.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-51-1   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.

Not Tested

SRC-52  

Requirement

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>

Section 3.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Derived Requirement # Summary Result
SRC-52-1 OVAL content SHALL include the <oval:generator> and <oval:schema_version> elements. Not Tested
Not Tested

SRC-52-1   OVAL content SHALL include the <oval:generator> and <oval:schema_version> elements.

Not Tested

SRC-54  

Requirement

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.

Section 3.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

SRC-71  

Requirement

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.

Section 3.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

SRC-71-1   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.

Pass

SRC-72  

Requirement

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.

Section 3.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-72-1   For all SCAP <cpe-dict:cpe-item>'s specified the CPE dictionary component of an SCAP datastream that contain a cpe-dict:check element, that cpe-dict:check element SHALL refer to an OVAL inventory definition in the same SCAP data stream

Pass

SRC-74  

Requirement

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.

Section 3.6 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Derived Requirement # Summary Result
SRC-74-1 All CCE references SHOULD be in the official CCE dictionary. Pass
Pass

SRC-74-1   All CCE references SHOULD be in the official CCE dictionary.

Pass

SRC-8  

Requirement

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

Section 3.2.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

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

SRC-9  

Requirement

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.

Section 3.2.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Pass

SRC-9-1   For all <xccdf:Benchmark>, <xccdf:Profile>, <xccdf:Value>, <xccdf:Group>, and <xccdf:Rule>, check for the existence of <xccdf:title>; if not found, the content shall be considered to be in error.

Pass

SRC-9-2   For all <xccdf:Benchmark>, <xccdf:Profile>, <xccdf:Value>, <xccdf:Group>, and <xccdf:Rule>, check for the existence of <xccdf:title>; if not found, the content shall be considered to be in error.

Pass

SRC-9-3   For all <xccdf:Benchmark>, <xccdf:Profile>, <xccdf:Value>, <xccdf:Group>, and <xccdf:Rule>, check for the existence of <xccdf:title>; if not found, the content shall be considered to be in error.

Not Tested

TOOL-110  

Requirement

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

Section 4.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-110-1   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).

Not Tested

TOOL-141  

Requirement

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.

Section 4.6 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

TOOL-202  

Requirement

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.

Section 4.6 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-202-1   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.1 of the OVAL Results schema regardless of the version of the OVAL Definitions document that was evaluated. This has been updated to 5.10.1 per 800-126 errata and SCAPVal implements this.

Not Tested

TOOL-218  

Requirement

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.

Section 4.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

TOOL-232  

Requirement

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

Section 4.3.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-232-1   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

Not Tested

TOOL-233  

Requirement

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.

Section 4.3.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-233-1   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.

Not Tested

TOOL-254  

Requirement

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.

Section 4.5 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-254-1   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. SCAPVal validates XCCDF content with the XCCDF schema

Not Tested

TOOL-269  

Requirement

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.

Section 3.6 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

TOOL-270  

Requirement

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.

Section 4.3.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-270-1   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.

Not Tested

TOOL-283  

Requirement

The <dsig:Signature> element MUST follow the recommendations in [TMSAD]

Section 3.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

TOOL-291  

Requirement

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.

Section 4.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-291-1   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.

Not Tested

TOOL-293  

Requirement

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>

Section 4.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-293-1   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>

Not Tested

TOOL-294  

Requirement

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>

Section 4.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

TOOL-295  

Requirement

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

Section 4.3.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-295-1   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>.

Not Tested

TOOL-296  

Requirement

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.

Section 4.3.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-296-1   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.

Not Tested

TOOL-297  

Requirement

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.

Section 4.3.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-297-1   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.

Not Tested

TOOL-298  

Requirement

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

Section 4.4.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

TOOL-308  

Requirement

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

Section 4.8 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

TOOL-310  

Requirement

The <dsig:Signature> element MUST follow the recommendations in [TMSAD]

Section 4.8 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

TOOL-335  

Requirement

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.

Section 3.1.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-335-1   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.

Not Tested

TOOL-336  

Requirement

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.

Section 3.1.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

TOOL-337  

Requirement

Also, for the component specifications, the Schematron file on the SCAP website SHALL be used in place of any corresponding Schematron file available elsewhere.

Section 3.1.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

TOOL-340  

Requirement

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

Section 3.2.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

TOOL-342  

Requirement

As stated in the XCCDF specification, the use of an <xccdf:Profile> element is not required.

Section 3.2.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-342-1   As stated in the XCCDF specification, the use of an <xccdf:Profile> element is not required.

Not Tested

TOOL-344  

Requirement

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.

Section 3.2.4.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-344-1   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.

Not Tested

TOOL-347  

Requirement

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.

Section 3.2.4.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-347-1   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.

Not Tested

TOOL-350  

Requirement

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

Section 3.2.4.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-350-1   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]. SCAPVal performs the Schematron rules and Schema validation.

Not Tested

TOOL-352  

Requirement

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.

Section 3.2.4.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-352-1   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.

Not Tested

TOOL-353  

Requirement

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

Section 3.2.4.4 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-353-1   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.

Not Tested

TOOL-354  

Requirement

XCCDF group extension SHALL NOT be allowed.

Section 3.2.6 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Derived Requirement # Summary Result
TOOL-354-1 XCCDF group extension SHALL NOT be allowed. SCAPVal does not implement this. Not Tested
Not Tested

TOOL-354-1   XCCDF group extension SHALL NOT be allowed. SCAPVal does not implement this.

Not Tested

TOOL-355  

Requirement

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.

Section 3.3 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-355-1   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.

Not Tested

TOOL-356  

Requirement

OCIL content SHOULD be used for checking rules that cannot be fully automated with OVAL.

Section 3.4 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Derived Requirement # Summary Result
TOOL-356-1 OCIL content SHOULD be used for checking rules that cannot be fully automated with OVAL. Not Tested
Not Tested

TOOL-356-1   OCIL content SHOULD be used for checking rules that cannot be fully automated with OVAL.

Not Tested

TOOL-357  

Requirement

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>

Section 3.4 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-357-1   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>

Not Tested

TOOL-359  

Requirement

As such, content authors MAY digitally sign source content following the guidelines in [TMSAD], along with the following requirements.

Section 3.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

TOOL-359-1   As such, content authors MAY digitally sign source content following the guidelines in [TMSAD], along with the following requirements.

Not Tested

TOOL-361  

Requirement

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.

Section 4.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

TOOL-362  

Requirement

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.

Section 4.2 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

TOOL-368  

Requirement

Validation of each component SHALL be done in accordance with the portions of this document that define requirements for the component.

Section 4.4.1 of The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
Not Tested

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

A-10  

Requirement

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

Section N/A of
Derived Requirement # Summary Result
A-10-1 XML content failed schema validation. Not Tested
Not Tested

A-10-1   XML content failed schema validation.

Not Tested

A-14  

Requirement

Content failed validation against schematron validation.

Section N/A of
Derived Requirement # Summary Result
A-14-1 Content failed validation against schematron validation. Not Tested
Not Tested

A-14-1   Content failed validation against schematron validation.

Pass

A-15  

Requirement

Check for unused OVAL definitions.

Section N/A of
Derived Requirement # Summary Result
A-15-1 Unused OVAL definitions exist. Pass
Pass

A-15-1   Unused OVAL definitions exist.

Pass

A-16  

Requirement

This is an additional, common-sense check.

Section N/A of
Derived Requirement # Summary Result
A-16-1 CCE number is expected, but missing as a reference Pass
Pass

A-16-1   CCE number is expected, but missing as a reference

Pass

A-17  

Requirement

This is an additional, common-sense check.

Section N/A of
Pass

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.

Not Applicable

A-18  

Requirement

This is an additional, common-sense check.

Section N/A of
Not Applicable

A-18-1   The attribute @content-type on <scap:check-system-content> must match the content as such: OVAL_COMPLIANCE, OVAL_PATCH, CPE_INVENTORY, OVAL_VULNERABILITY must contain an <oval-def:oval_definitions> element; OCIL_QUESTIONS must contain an <ocil:ocil> element.

Informational

A-21  

Requirement

This requirement is intended to help the end-user, but it isn't required for content to pass validation.

Section N/A of
Derived Requirement # Summary Result
A-21-1 The OVAL test type is not checked in the NIST SCAP Validation Program. Informational
Informational

A-21-1   The OVAL test type is not checked in the NIST SCAP Validation Program.

Informational

A-22  

Requirement

This requirement is intended to help the end-user, but it isn't required for content to pass validation.

Section N/A of
Derived Requirement # Summary Result
A-22-1 A custom XPath function is not available Informational
Informational

A-22-1   A custom XPath function is not available

Not Tested

A-23  

Requirement

The content contains an XML element in a namespace that is not governed by one of the officially supported SCAP specifications.

Section N/A of
Not Tested

A-23-1   The content contains an XML element in a namespace that is not governed by one of the officially supported SCAP specifications. This tool will not load external XML schemas, so XML schema validation errors may be produced. The namespace is {0}

Not Tested

A-24  

Requirement

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.

Section N/A of
Not Tested

A-24-1   The source data stream collection SHOULD be included in the ARF report as an <arf:report-request>. The user should run SCAPVal using the -sourceds argument to specify the source data stream collection that was used to generate the results.

Pass

A-25  

Requirement

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.

Section N/A of
Pass

A-25-1   The @id attribute of all <xccdf:Profile> elements in a SCAP source data stream must be unique.

Warning

A-26   Explicitly specify all default attributes when creating content that will be signed.

Requirement

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.

Section 4.8 of Security Content Automation Protocol (SCAP) Version 1.2 Content Style Guide (Draft): Best Practices for Creating and Maintaining SCAP 1.2 Content
Warning

A-26-1   Explicitly provide values for all default attributes instead of assuming the default value.

Test Details

# Test Result Message Context (Line/Column)
1 Fail ' - TEST: exists(@selected) and exists(@weight) and exists(@role) and exists(@severity)' 74 : 84  
<data-stream-collection id="scap_gov.nist_collection_r2920-datastream.zip" schematron-version="1.2" xsi:schemaLocation="http://scap.nist.gov/schema/scap/source/1.2 http://scap.nist.gov/schema/scap/1.2/scap-source-data-stream_1.2.xsd">
...
<component id="scap_gov.nist_comp_r2920-xccdf.xml" timestamp="2017-05-15T14:00:00">
...
<xccdf:Benchmark id="xccdf_gov.nist_benchmark_r2920" style="SCAP_1.2" xml:lang="en" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.2 http://scap.nist.gov/schema/xccdf/1.2/xccdf_1.2.xsd http://cpe.mitre.org/dictionary/2.0 http://scap.nist.gov/schema/cpe/2.3/cpe-dictionary_2.3.xsd">
...
<xccdf:Rule id="xccdf_gov.nist_rule_validation.r2920_rule_1" selected="true">
<xccdf:title>
</xccdf:title>
<xccdf:description>
</xccdf:description>
<xccdf:ident system="http://cve.mitre.org">
</xccdf:ident>
<xccdf:check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
...
</xccdf:check>
</xccdf:Rule>
...
</xccdf:Benchmark>
</component>
</data-stream-collection>
2 Fail ' - TEST: exists(@selected) and exists(@weight) and exists(@role) and exists(@severity)' 82 : 84  
<data-stream-collection id="scap_gov.nist_collection_r2920-datastream.zip" schematron-version="1.2" xsi:schemaLocation="http://scap.nist.gov/schema/scap/source/1.2 http://scap.nist.gov/schema/scap/1.2/scap-source-data-stream_1.2.xsd">
...
<component id="scap_gov.nist_comp_r2920-xccdf.xml" timestamp="2017-05-15T14:00:00">
...
<xccdf:Benchmark id="xccdf_gov.nist_benchmark_r2920" style="SCAP_1.2" xml:lang="en" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.2 http://scap.nist.gov/schema/xccdf/1.2/xccdf_1.2.xsd http://cpe.mitre.org/dictionary/2.0 http://scap.nist.gov/schema/cpe/2.3/cpe-dictionary_2.3.xsd">
...
<xccdf:Rule id="xccdf_gov.nist_rule_validation.r2920_rule_2" selected="true">
<xccdf:title>
</xccdf:title>
<xccdf:description>
</xccdf:description>
<xccdf:ident system="http://cve.mitre.org">
</xccdf:ident>
<xccdf:check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
...
</xccdf:check>
</xccdf:Rule>
...
</xccdf:Benchmark>
</component>
</data-stream-collection>
3 Fail ' - TEST: exists(@selected) and exists(@weight) and exists(@role) and exists(@severity)' 90 : 84  
<data-stream-collection id="scap_gov.nist_collection_r2920-datastream.zip" schematron-version="1.2" xsi:schemaLocation="http://scap.nist.gov/schema/scap/source/1.2 http://scap.nist.gov/schema/scap/1.2/scap-source-data-stream_1.2.xsd">
...
<component id="scap_gov.nist_comp_r2920-xccdf.xml" timestamp="2017-05-15T14:00:00">
...
<xccdf:Benchmark id="xccdf_gov.nist_benchmark_r2920" style="SCAP_1.2" xml:lang="en" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.2 http://scap.nist.gov/schema/xccdf/1.2/xccdf_1.2.xsd http://cpe.mitre.org/dictionary/2.0 http://scap.nist.gov/schema/cpe/2.3/cpe-dictionary_2.3.xsd">
...
<xccdf:Rule id="xccdf_gov.nist_rule_validation.r2920_rule_3" selected="true">
<xccdf:title>
</xccdf:title>
<xccdf:description>
</xccdf:description>
<xccdf:ident system="http://cve.mitre.org">
</xccdf:ident>
<xccdf:check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
...
</xccdf:check>
</xccdf:Rule>
...
</xccdf:Benchmark>
</component>
</data-stream-collection>
4 Fail ' - TEST: exists(@selected) and exists(@weight) and exists(@role) and exists(@severity)' 98 : 84  
<data-stream-collection id="scap_gov.nist_collection_r2920-datastream.zip" schematron-version="1.2" xsi:schemaLocation="http://scap.nist.gov/schema/scap/source/1.2 http://scap.nist.gov/schema/scap/1.2/scap-source-data-stream_1.2.xsd">
...
<component id="scap_gov.nist_comp_r2920-xccdf.xml" timestamp="2017-05-15T14:00:00">
...
<xccdf:Benchmark id="xccdf_gov.nist_benchmark_r2920" style="SCAP_1.2" xml:lang="en" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.2 http://scap.nist.gov/schema/xccdf/1.2/xccdf_1.2.xsd http://cpe.mitre.org/dictionary/2.0 http://scap.nist.gov/schema/cpe/2.3/cpe-dictionary_2.3.xsd">
...
<xccdf:Rule id="xccdf_gov.nist_rule_validation.r2920_rule_4" selected="true">
<xccdf:title>
</xccdf:title>
<xccdf:description>
</xccdf:description>
<xccdf:ident system="http://cve.mitre.org">
</xccdf:ident>
<xccdf:check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
...
</xccdf:check>
</xccdf:Rule>
...
</xccdf:Benchmark>
</component>
</data-stream-collection>
5 Fail ' - TEST: exists(@selected) and exists(@weight) and exists(@role) and exists(@severity)' 106 : 84  
<data-stream-collection id="scap_gov.nist_collection_r2920-datastream.zip" schematron-version="1.2" xsi:schemaLocation="http://scap.nist.gov/schema/scap/source/1.2 http://scap.nist.gov/schema/scap/1.2/scap-source-data-stream_1.2.xsd">
...
<component id="scap_gov.nist_comp_r2920-xccdf.xml" timestamp="2017-05-15T14:00:00">
...
<xccdf:Benchmark id="xccdf_gov.nist_benchmark_r2920" style="SCAP_1.2" xml:lang="en" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.2 http://scap.nist.gov/schema/xccdf/1.2/xccdf_1.2.xsd http://cpe.mitre.org/dictionary/2.0 http://scap.nist.gov/schema/cpe/2.3/cpe-dictionary_2.3.xsd">
...
<xccdf:Rule id="xccdf_gov.nist_rule_validation.r2920_rule_5" selected="true">
<xccdf:title>
</xccdf:title>
<xccdf:description>
</xccdf:description>
<xccdf:ident system="http://cve.mitre.org">
</xccdf:ident>
<xccdf:check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
...
</xccdf:check>
</xccdf:Rule>
...
</xccdf:Benchmark>
</component>
</data-stream-collection>
6 Fail ' - TEST: exists(@selected) and exists(@weight) and exists(@role) and exists(@severity)' 114 : 84  
<data-stream-collection id="scap_gov.nist_collection_r2920-datastream.zip" schematron-version="1.2" xsi:schemaLocation="http://scap.nist.gov/schema/scap/source/1.2 http://scap.nist.gov/schema/scap/1.2/scap-source-data-stream_1.2.xsd">
...
<component id="scap_gov.nist_comp_r2920-xccdf.xml" timestamp="2017-05-15T14:00:00">
...
<xccdf:Benchmark id="xccdf_gov.nist_benchmark_r2920" style="SCAP_1.2" xml:lang="en" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.2 http://scap.nist.gov/schema/xccdf/1.2/xccdf_1.2.xsd http://cpe.mitre.org/dictionary/2.0 http://scap.nist.gov/schema/cpe/2.3/cpe-dictionary_2.3.xsd">
...
<xccdf:Rule id="xccdf_gov.nist_rule_validation.r2920_rule_6" selected="true">
<xccdf:title>
</xccdf:title>
<xccdf:description>
</xccdf:description>
<xccdf:ident system="http://cve.mitre.org">
</xccdf:ident>
<xccdf:check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
...
</xccdf:check>
</xccdf:Rule>
...
</xccdf:Benchmark>
</component>
</data-stream-collection>
7 Fail ' - TEST: exists(@selected) and exists(@weight) and exists(@role) and exists(@severity)' 122 : 84  
<data-stream-collection id="scap_gov.nist_collection_r2920-datastream.zip" schematron-version="1.2" xsi:schemaLocation="http://scap.nist.gov/schema/scap/source/1.2 http://scap.nist.gov/schema/scap/1.2/scap-source-data-stream_1.2.xsd">
...
<component id="scap_gov.nist_comp_r2920-xccdf.xml" timestamp="2017-05-15T14:00:00">
...
<xccdf:Benchmark id="xccdf_gov.nist_benchmark_r2920" style="SCAP_1.2" xml:lang="en" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.2 http://scap.nist.gov/schema/xccdf/1.2/xccdf_1.2.xsd http://cpe.mitre.org/dictionary/2.0 http://scap.nist.gov/schema/cpe/2.3/cpe-dictionary_2.3.xsd">
...
<xccdf:Rule id="xccdf_gov.nist_rule_validation.r2920_rule_7" selected="true">
<xccdf:title>
</xccdf:title>
<xccdf:description>
</xccdf:description>
<xccdf:ident system="http://cve.mitre.org">
</xccdf:ident>
<xccdf:check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
...
</xccdf:check>
</xccdf:Rule>
...
</xccdf:Benchmark>
</component>
</data-stream-collection>
8 Fail ' - TEST: exists(@selected) and exists(@weight) and exists(@role) and exists(@severity)' 130 : 84  
<data-stream-collection id="scap_gov.nist_collection_r2920-datastream.zip" schematron-version="1.2" xsi:schemaLocation="http://scap.nist.gov/schema/scap/source/1.2 http://scap.nist.gov/schema/scap/1.2/scap-source-data-stream_1.2.xsd">
...
<component id="scap_gov.nist_comp_r2920-xccdf.xml" timestamp="2017-05-15T14:00:00">
...
<xccdf:Benchmark id="xccdf_gov.nist_benchmark_r2920" style="SCAP_1.2" xml:lang="en" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.2 http://scap.nist.gov/schema/xccdf/1.2/xccdf_1.2.xsd http://cpe.mitre.org/dictionary/2.0 http://scap.nist.gov/schema/cpe/2.3/cpe-dictionary_2.3.xsd">
...
<xccdf:Rule id="xccdf_gov.nist_rule_validation.r2920_rule_8" selected="true">
<xccdf:title>
</xccdf:title>
<xccdf:description>
</xccdf:description>
<xccdf:ident system="http://cve.mitre.org">
</xccdf:ident>
<xccdf:check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
...
</xccdf:check>
</xccdf:Rule>
...
</xccdf:Benchmark>
</component>
</data-stream-collection>
9 Fail ' - TEST: exists(@selected) and exists(@weight) and exists(@role) and exists(@severity)' 138 : 84  
<data-stream-collection id="scap_gov.nist_collection_r2920-datastream.zip" schematron-version="1.2" xsi:schemaLocation="http://scap.nist.gov/schema/scap/source/1.2 http://scap.nist.gov/schema/scap/1.2/scap-source-data-stream_1.2.xsd">
...
<component id="scap_gov.nist_comp_r2920-xccdf.xml" timestamp="2017-05-15T14:00:00">
...
<xccdf:Benchmark id="xccdf_gov.nist_benchmark_r2920" style="SCAP_1.2" xml:lang="en" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.2 http://scap.nist.gov/schema/xccdf/1.2/xccdf_1.2.xsd http://cpe.mitre.org/dictionary/2.0 http://scap.nist.gov/schema/cpe/2.3/cpe-dictionary_2.3.xsd">
...
<xccdf:Rule id="xccdf_gov.nist_rule_validation.r2920_rule_9" selected="true">
<xccdf:title>
</xccdf:title>
<xccdf:description>
</xccdf:description>
<xccdf:ident system="http://cve.mitre.org">
</xccdf:ident>
<xccdf:check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
...
</xccdf:check>
</xccdf:Rule>
...
</xccdf:Benchmark>
</component>
</data-stream-collection>
10 Fail ' - TEST: exists(@selected) and exists(@weight) and exists(@role) and exists(@severity)' 146 : 85  
<data-stream-collection id="scap_gov.nist_collection_r2920-datastream.zip" schematron-version="1.2" xsi:schemaLocation="http://scap.nist.gov/schema/scap/source/1.2 http://scap.nist.gov/schema/scap/1.2/scap-source-data-stream_1.2.xsd">
...
<component id="scap_gov.nist_comp_r2920-xccdf.xml" timestamp="2017-05-15T14:00:00">
...
<xccdf:Benchmark id="xccdf_gov.nist_benchmark_r2920" style="SCAP_1.2" xml:lang="en" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.2 http://scap.nist.gov/schema/xccdf/1.2/xccdf_1.2.xsd http://cpe.mitre.org/dictionary/2.0 http://scap.nist.gov/schema/cpe/2.3/cpe-dictionary_2.3.xsd">
...
<xccdf:Rule id="xccdf_gov.nist_rule_validation.r2920_rule_10" selected="true">
<xccdf:title>
</xccdf:title>
<xccdf:description>
</xccdf:description>
<xccdf:ident system="http://cve.mitre.org">
</xccdf:ident>
<xccdf:check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
...
</xccdf:check>
</xccdf:Rule>
...
</xccdf:Benchmark>
</component>
</data-stream-collection>
Omitting 25 additional results.