![](media/image1.png){width="2.214583333333333in" height="1.24375in"}

Peter Mell

Stephen Quinn\
John Banghart

David Waltermire

![](media/image2.wmf){width="0.0in" height="0.0in"}

**Reports on Computer Systems Technology**

The Information Technology Laboratory (ITL) at the National Institute of
Standards and Technology (NIST) promotes the U.S. economy and public
welfare by providing technical leadership for the nation's measurement
and standards infrastructure. ITL develops tests, test methods,
reference data, proof of concept implementations, and technical analysis
to advance the development and productive use of information technology.
ITL's responsibilities include the development of technical, physical,
administrative, and management standards and guidelines for the
cost-effective security and privacy of sensitive unclassified
information in Federal computer systems. This Interagency Report
discusses ITL's research, guidance, and outreach efforts in computer
security and its collaborative activities with industry, government, and
academic organizations.

Acknowledgments

The authors would like to thank the many people that reviewed and
contributed to this document. In particular, the following individuals
provided invaluable feedback: Dawn Adams (EWA-Canada), Stephen Allison
(Booz Allen Hamilton), Scott Armstrong (Secure Elements), Andrew Bove
(Secure Elements), Scott Carpenter (Secure Elements), Mark Cox (Red
Hat), Jonathan Frazier (Gideon Technologies), Robert Hollis
(Threatguard), Kent Landfield (McAfee), Ken Lassesen (Lumension), and
Joseph Wolfkiel (Department of Defense).

Abstract

This document describes the requirements that must be met by products in
order to achieve SCAP Validation. Validation is awarded based on a
defined set of SCAP capabilities and/or individual SCAP components by
independent laboratories that have been accredited through the program.

Table of Contents

[1. Introduction 1](#introduction)

[2. Versions and Definitions 4](#versions-and-definitions)

[2.1 Versions 4](#versions)

[2.2 Document Conventions 6](#document-conventions)

[2.3 Common Definitions 6](#common-definitions)

[3. Vendor Product Validation Testing Requirements
11](#vendor-product-validation-testing-requirements)

[4. Derived Test Requirements for Specific SCAP Components
12](#derived-test-requirements-for-specific-scap-components)

[4.1 Common Vulnerability Enumeration (CVE)
12](#common-vulnerability-enumeration-cve)

[4.2 Common Configuration Enumeration (CCE)
15](#common-configuration-enumeration-cce)

[4.3 Common Platform Enumeration 18](#common-platform-enumeration)

[4.4 Common Vulnerability Scoring System (CVSS)
21](#common-vulnerability-scoring-system-cvss)

[4.5 eXtensible Configuration Checklist Document Format (XCCDF)
25](#extensible-configuration-checklist-document-format-xccdf)

[4.6 Open Vulnerability Assessment Language (OVAL)
28](#open-vulnerability-assessment-language-oval)

[5. SCAP Derived Test Requirements 32](#scap-derived-test-requirements)

[5.1 Federal Desktop Core Configuration (FDCC)
32](#federal-desktop-core-configuration-fdcc)

[5.2 General SCAP Requirements 33](#general-scap-requirements)

[5.3 XCCDF + OVAL (Input) 35](#xccdf-oval-input)

[5.4 XCCDF + OVAL (Output) 36](#xccdf-oval-output)

[5.5 XCCDF + CCE 36](#xccdf-cce)

[5.6 XCCDF + OVAL + CPE 37](#xccdf-oval-cpe)

[5.7 CVSS + CVE 37](#cvss-cve)

[5.8 SCAP Data Stream Import 38](#scap-data-stream-import)

[5.9 Compliance Mapping Output 38](#compliance-mapping-output)

[6. Derived Test Requirements for Specific Capability
40](#derived-test-requirements-for-specific-capability)

# Introduction

**Background**

The Security Content Automation Protocol (SCAP), pronounced "Ess-Cap",
is a method for using specific standards to enable automated
vulnerability management, measurement, and policy compliance evaluation
(e.g., FISMA compliance). More specifically, SCAP is a suite of open
standards that: enumerates software flaws, security related
configuration issues, and product names; measures systems to determine
the presence of vulnerabilities; and provides mechanisms to rank (score)
the results of these measurements in order to evaluate the impact of the
discovered security issues. SCAP defines how these standards are used in
unison to accomplish these capabilities.

The United States (U.S.) National Vulnerability Database (NVD), operated
by the U.S. National Institute of Standards and Technology (NIST),
provides a repository and data feeds of content that utilize the SCAP
standards. It is also the repository for certain official SCAP standards
data. Thus, NIST defines open standards within the SCAP context and
defines the mappings between the SCAP enumeration standards. However,
NIST does not control the underlying standards that are used within
SCAP. SCAP includes the following standards:

• Common Vulnerabilities and Exposures (CVE®)

• Common Configuration Enumeration (CCE™)

• Common Platform Enumeration (CPE™)

• Common Vulnerability Scoring System (CVSS)

• eXtensible Configuration Checklist Description Format (XCCDF)

• Open Vulnerability and Assessment Language (OVAL™)

Section 2 contains versioning information for each of the above
requirements and other important information.

These open standards were created and are maintained by a number of
different institutions including: the MITRE Corporation, the National
Security Agency (NSA), the National Institute of Standards and
Technology (NIST), and a special interest group within the Forum of
Incident Response and Security Teams (FIRST). These standards are
cooperatively developed and maintained with industry input and
participation. NIST recommends the use of SCAP for the integration of
security products, the automation of policy compliance, and
vulnerability management activities.

**Purpose and Scope**

The SCAP Validation Program is designed to test the ability of products
to use the features and functionality available through SCAP and its
component standards.

This document lists the test requirements for seven (7) distinct but
related validations. It includes the test requirements for the SCAP
validation program and the test requirements for validation of six (6)
individual standards that are used within SCAP. Relative to each
validation, a product may be validated for a specific set of
capabilities. Note that SCAP validation for a particular capability may
not require all the tests that are applicable to each of the six
standards used by SCAP.

1)  An information technology (IT) security product vendor can obtain
    validations from NIST for specific SCAP Capabilities using the tests
    within this document. . Please note that the overall validation is
    listed first followed by the set of available capabilities, if any.
    The following SCAP Capability validations are defined in this
    document:

    a.  Federal Desktop Core Configuration (FDCC) Scanner

    b.  Authenticated Configuration Scanner

    c.  Authenticated Vulnerability Scanner

    d.  Unauthenticated Vulnerability Scanner

    e.  Intrusion Detection and Prevention

    f.  Patch Remediation

    g.  Mis-configuration Remediation

    h.  Asset Management

    i.  Asset Database

    j.  Vulnerability Database

    k.  Mis-configuration Database

    l.  Malware Tool

2)  CVE validation

3)  CCE validation

4)  CPE validation

5)  CVSS validation

6)  XCCDF validation

7)  OVAL validation

This validation program is run by the NIST SCAP Validation Program in
the NIST Information Technology Laboratory.

Under the SCAP Validation Program, independent laboratories are
accredited by the NIST National Voluntary Laboratory Accreditation
Program (NVLAP). Accreditation requirements are defined in NIST Handbook
150, and NIST Handbook 150-17. Independent laboratories conduct the
tests contained in this document on information technology (IT) security
products and deliver the results to NIST. Based on the independent
laboratory test report, the SCAP Validation Program then validates the
product under test based on the independent laboratory test report. The
validation certificates awarded to vendor products will be publicly
posted on the NIST SCAP Validated Tools web page
(http://nvd.nist.gov/tools.cfm). Vendors of validated products will be
provided with a logo that can be used to indicate a products validation
status.

SCAP validation will focus on evaluating specific versions of vendor
products based on the platforms they support. Validation certificates
will be awarded on a platform-by-platform basis for the version of the
product that was validated. Currently, official SCAP content is
primarily focused on Windows operating systems. Thus, vendors seeking
validation will be evaluated based on the ability of the product to
operate on the Windows target platform. Windows test files, used for
conducting specific validation tests will be available to labs in
January 2008 and UNIX/Linux test files will be developed and released in
2008.

**Superseded Compatibility Programs**

Prior to this formal NIST SCAP validation program, NIST published a beta
compatibility document that allowed vendors to self-assert that they
were SCAP compatible. It required a vendor to assert compliance with
three (3) or more of the SCAP standards. This self-assertion beta
compatibility program terminates on February 1^st^, 2008 and is being
replaced by the tests and validation program described within this
document.

The MITRE Corporation also maintains compatibility programs for both CVE
and OVAL. These compatibility programs will remain operational until
superseded by the NIST CVE and OVAL validations programs, which are not
yet operational. MITRE has been working closely with NIST to ensure that
this transition goes smoothly.

# Versions and Definitions

## Versions

For all Derived Test Requirements that reference specific
specifications, the versions indicated in the following section should
be used.

**[SCAP (Security Content Automation Protocol)]{.underline}**

> **Definition:** SCAP is a method for using specific standards in
> concert to enable automated vulnerability management, measurement, and
> policy compliance evaluation. The SCAP version allows the versions of
> the SCAP component standards to be referred to as a collection.
>
> **Version:** 1.0 or later minor revisions
>
> **Specification:** [http://scap.nist.gov](http://scap.nist.gov/)
>
> SCAP 1.0 includes:

-   CVE 1.2

-   CCE 4.0

-   CPE 2.0

-   CVSS 2.0

-   XCCDF 1.1.4

-   OVAL 5.3

**[CVE (Common Vulnerability Enumeration)]{.underline}**

> **Definition:** CVE is a format to describe publicly known information
> security vulnerabilities and exposures. Using this format, new CVE Ids
> will be created, assigned, and referenced in content on an as-needed
> basis without a version change.
>
> **Version:** 1.2 or later minor revisions
>
> **Specification:** [http://cve.mitre.org](http://cve.mitre.org/)
>
> **Dictionary: http://nvd.nist.gov/**

**[CCE (Common Configuration Enumeration)]{.underline}**

> **Definition:** CCE is a format to describe system configuration
> issues in order to facilitate correlation of configuration data across
> multiple information sources and tools.
>
> **Version:** 4.0 or later minor revisions
>
> **Specification:** [http://cce.mitre.org](http://cce.mitre.org/)
>
> **Schema Location: http://cce.mitre.org**

**[CPE (Common Platform Enumeration)]{.underline}**

> **Definition:** CPE is a structured naming scheme for IT platforms
> (hardware, operating systems, and applications) for the purpose of
> identifying specific platform types.
>
> **Version:** 2.0 or later minor revisions
>
> **Specification:** [http://cpe.mitre.org](http://cpe.mitre.org/)
>
> **Schema Location:** http://cpe.mitre.org/specification/index.html
>
> **Dictionary:** http://nvd.nist.gov/cpe.cfm

**[CVSS (Common Vulnerability Scoring System)]{.underline}**

> **Definition:** CVSS is a scoring system that provides an open
> framework for determining the impact of information technology
> vulnerabilities and a format for communicating vulnerability
> characteristics.
>
> **Version:** 2.0 or later minor revisions
>
> **Specification:**
> <http://csrc.nist.gov/publications/nistir/ir7435/NISTIR-7435.pdf>
>
> **SCAP CVSS Base Scores:** [http://nvd.nist.gov](http://nvd.nist.gov/)

**[XCCDF: (eXtensible Configuration Checklist Document
Format)]{.underline}**

> **Definition**: XCCDF is an XML-based language for representing
> security checklists, benchmarks, and related documents in a
> machine-readable form.  An XCCDF document represents a structured
> collection of security configuration rules for one or more
> applications and/or systems.
>
> **Version**: 1.1.4 or later minor revisions.
>
> **Specification:** http://nvd.nist.gov/xccdf.cfm
>
> **Schema Location:** **http://nvd.nist.gov/xccdf.cfm**

**[OVAL (Open Vulnerability Assessment Language)]{.underline}**

> **Definition:** OVAL is a XML-based language used for communicating
> the details of vulnerabilities, patches, security configuration
> settings, and other machine states in a machine-readable form.
>
> **Version:** 5.3 or later minor revisions.
>
> **Specification:** [http://oval.mitre.org](http://oval.mitre.org/)
>
> **Schema Location:**
> <http://oval.mitre.org/language/download/schema/version5.3/index.html>

**[FDCC (Federal Desktop Core Configuration)]{.underline}**

> **Definition:** The FDCC is a security configuration policy developed
> for use on all non-classified government Windows XP and Windows Vista
> systems.
>
> **Version:** Currently Beta
>
> **Specification:** http://fdcc.nist.gov
>
> **Schema Location:** **NA**

## Document Conventions

**Key words**

For consistency, the following document conventions have been used
throughout this document.

The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL
NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and
\"OPTIONAL\" in this document are to be interpreted as described in RFC
2119[^1]. For more information please refer to:
http://www.ietf.org/rfc/rfc2119.txt?number=2119.

**Internet Connectivity**

The availability of an Internet connection during the evaluation of each
test requirement will be indicated by the statements "*permitted*" or
"*not-permitted*". When "permitted" is indicated, a product may make
full use of any available network connection to access Internet based
resources. If "not-permitted" is indicated, then no Internet network
connectivity shall be provided during evaluation of the test procedure.
Every effort has been made in the proceeding test requirements to avoid
mandating that the capability to run in the presence or absence of
Internet connectivity be supported by a product. Use of an Internet
connection in some test procedures is disallowed to insure that the
functionality being evaluated in the tool exists directly within the
tool and not as the result of utilizing an Internet based capability.
Access to a local area network (LAN) shall be allowed in all tests to
support client-server based implementations.

## Common Definitions

The following definitions represent key terms used in this document. The
use of these terms will be indicated throughout this document using
*italicized text*.

**[Authenticated Scanner]{.underline}**

> **Definition:** A scanning product that runs with privileges on a
> target system in order to conduct its assessment.

**[CCE ID]{.underline}**

> **Definition:** An identifier for a specific configuration defined
> within the official CCE dictionary and that conforms to the CCE
> specification. For more information please see the CCE specification
> reference in section 2.1.

**[Comparison Utility]{.underline}**

> **Definition:** A utility provided to the accredited laboratory
> testers by NIST for use in the validation of *product* data sets as
> defined by certain testing requirements.

**[CPE Name]{.underline}**

> **Definition:** An identifier for a unique URI given to a specific
> platform type that conforms to the CPE specification. For more
> information please see the CPE specification reference in section 2.1.

**[CVE ID]{.underline}**

> **Definition:** An identifier for a specific vulnerability defined
> using the *CVE* specification. For more information please see the CVE
> specification reference in section 2.1.

**[Derived Test Requirement/Test Requirement]{.underline}**

> **Definition:** A statement of requirement, needed information, and
> associated test procedures necessary to test a specific SCAP
> feature[.]{.underline}

**[Interrelation]{.underline}**

> **Definition:** The aggregation of two or more *SCAP Components*
> resulting in testing requirements that extend or replace the testing
> requirements for each individual *SCAP Component* that forms the
> combination.

**[Import]{.underline}**

> **Definition:** A process available to end-users by which a SCAP data
> file can be loaded manually into the vendor product. During this
> process, the vendor process may optionally translate this file into a
> proprietary format.

**[Machine-Readable]{.underline}**

> **Definition**: A tool output is considered "machine readable" if the
> output is in a structured format, typically XML, that can be consumed
> by another program using consistent processing logic.

**[Major Revision]{.underline}**

> **Definition**: Any increase in the version of a SCAP standard's
> specification or SCAP related data set that involves substantive
> changes that will break backwards compatibility with previous
> releases.
>
> See also SCAP revision.

**[Minor Revision]{.underline}**

> **Definition**: Any increase in version of an SCAP standard's
> specification or SCAP related data set that may involve adding
> additional functionality, but that preserves backwards compatibility
> with previous releases.
>
> See also SCAP revision.

**[Mis-Configuration]{.underline}**

> **Definition:** A setting within a computer program that violates a
> configuration policy or that permits or causes unintended behavior
> that impacts the security posture of a system. CCE can be used for
> enumerating mis-configurations.

**[OVAL ID]{.underline}**

> **Definition:** An identifier for a specific OVAL definition that
> conforms to the format for OVAL IDs. For more information please see
> the OVAL specification reference in section 2.1.

**[Product]{.underline}**

> **Definition:** A security software application, appliance, or
> security database that has one or more *capabilities*.

**[Product Output]{.underline}**

> **Definition:** Information produced by a tool. This includes the
> product user interface, human readable reports, and machine-readable
> reports. There are no constraints on the format. When this output is
> evaluated in a test procedure either all or specific forms of output
> will be sampled as indicated by the test procedure.

**[Reference Product]{.underline}**

> **Definition:** A product provided to accredited laboratory testers by
> NIST for use as a baseline for testing requirements. The product
> exhibits the behavior that is deemed to be correct.

**[Role]{.underline}**

> **Definition:** An implementation of an SCAP component specification
> that utilizes specific features of the standard to achieve a
> pre-defined purpose (e.g., OVAL Producer, OVAL Consumer, and XCCDF
> Document Generator).

**[SCAP Capability]{.underline}**

> **Definition:** A specific function or functions of a *product* as
> defined below:

-   **FDCC Scanner**: a product with the ability to audit and asses a
    *target system* in order to determine its compliance with the
    Federal Desktop Core Configuration (FDCC) requirements.

-   **Authenticated Configuration Scanner:** a product with the ability
    to audit and assess a *target system* to determine its compliance
    with a defined set of configuration requirements using target system
    logon privileges.

-   **Authenticated Vulnerability Scanner:** a product with the ability
    to scan a *target system* to locate and identify the presence of
    known *software flaws* and evaluate the software patch status to
    determine compliance with a defined patch policy using target system
    logon privileges

-   **Unauthenticated Vulnerability Scanner:** a product with the
    ability of determining the presence of known *software flaws* by
    evaluating the *target system* over the network

-   **Intrusion Detection and Prevention Systems (IDPS):** a product
    that monitors a system or network for unauthorized or malicious
    activities. An intrusion prevention system actively protects the
    target system or network against these activities.

-   **Patch Remediation**: the ability to install patches on a target
    system in compliance with a defined patching policy.

-   **Mis-configuration Remediation**: the ability to alter the
    configuration of a target system in order to bring it into
    compliance with a defined set of configuration recommendations.

-   **Asset Management:** the ability to actively discover, audit, and
    assess asset characteristics including: installed and licensed
    products; location within the world, a network or enterprise;
    ownership; and other related information on IT assets such as
    workstations, servers, and routers.

-   **Asset Database:** the ability to passively store and report on
    asset characteristics including: installed and licensed products;
    location within the world, a network or enterprise; ownership; and
    other related information on IT assets such as workstations,
    servers, and routers.

-   **Vulnerability Database:** a database containing information
    relating to known software flaw issues with associated CVEs where
    applicable.

-   **Mis-configuration Database:** a database containing general
    information relating to known software mis-configuration issues with
    associated CCEs where applicable.

-   **Malware Tool:** the ability to identify and report on the presence
    of viruses, Trojan horses, spyware, or other malware on a target
    system.

**[SCAP Component]{.underline}**

> **Definition:** One of the six defined *SCAP* standards: *CCE, CPE,
> CVE, CVSS, OVAL, and XCCDF*

**[SCAP Data stream]{.underline}**

> **Definition:** A collection of five related XML files containing SCAP
> data using the SCAP standards that provide the data necessary to
> evaluate systems for compliance with a configuration-based security
> policy. Patch checking content may also be included in this bundle.
>
> Files included for SCAP 1.0 are:
>
> XXXX-xccdf.xml - XCCDF 1.1 content
>
> XXXX-cpe-oval.xml - CPE OVAL 5 definitions
>
> XXXX-cpe-dictionary.xml - Minimal CPE 2.0 dictionary
>
> XXXX-oval.xml - OVAL 5 compliance definitions
>
> XXXX-patches.xml - OVAL 5 patch definitions
>
> Where XXXX represents a unique prefix for the bundle (i.e. fdcc-xp,
> fdcc-vista, etc)

**[SCAP Revision]{.underline}**

> **Definition:** SCAP uses revision numbering in the format nn.nn.nn,
> where the first nn is referred to as the major revision number, the
> second nn number will be referred to as the minor revision number, and
> the final nn number will be referred to as the refinement number. A
> specific SCAP revision will populate all three fields, even if that
> means using zeros to show no minor revision or refinement number has
> been used to date. A leading zero will be used to pad single digit
> version or refinement numbers.

**[Software Flaw]{.underline}**

See Vulnerability.

**[Target Platform]{.underline}**

> **Definition:** The target operating system on which a vendor product
> will be evaluated using a platform specific validation lab test suite.
> These platform specific test suites consist of specialized SCAP
> content used to perform the test procedures defined in this document.

**[Unauthenticated Scanner]{.underline}**

> **Definition:** A scanning product that runs without privileges
> against a target system in order to conduct its assessment which could
> include network data and port scans.

**[Vulnerability]{.underline}**

> **Definition:** An error, flaw, or mistake in computer software that
> permits or causes an unintended behavior to occur. CVE is a common
> means of enumerating vulnerabilities.

**[XCCDF Content:]{.underline}**

**Definition:** A file conforming to the XCCDF Schema.

# Vendor Product Validation Testing Requirements

The following guidelines must be followed by all vendors seeking
validation of a product:

1.  Required vendor information is detailed within each derived test
    requirements.

2.  All text submissions must be submitted in the English language.

3.  For tests that require testers to import NIST provided XCCDF or OVAL
    test file(s), vendors may indicate whether or not this import should
    be a standalone file or part of an SCAP data stream.

4.  All SCAP tests require an SCAP data stream as input.

# Derived Test Requirements for Specific SCAP Components

This section contains the Derived Test Requirements (DTR) for each of
the six *SCAP Components* for the purpose of allowing individual
validation of each *SCAP Component* within a *product*. Version
information and download location can be found above in section 2.1 and
should be referenced to ensure that the correct version is being used
prior to testing. SCAP specific requirements are found below in Section
5.

Each DTR includes the following information:

-   The DTR name. This is comprised of the acronym followed by ".R" to
    denote it is a requirement, and then the requirement number within
    the component section (CVE, CCE, etc...)

-   Required vendor information. This states what information vendors
    are required to provide to the testing lab in order for the test to
    be conducted.

-   Required test procedure(s). This defines one or more tests that the
    testing laboratory will conduct in order to determine the product's
    ability to meet the stated requirement.

## Common Vulnerability Enumeration (CVE)

The following CVE requirements are used to achieve CVE Validation or in
conjunction with other non-CVE test requirements for SCAP Validation.
Thus, all of the tests in this sub-section are focused exclusively on
CVE and do not cover how CVE interrelates with other SCAP standards.
Section 6 includes a capability matrix that indicates which of the CVE
test requirements are used in SCAP Validation.

**CVE.R.1: The product's documentation (printed or electronic) must
state that it uses CVE and explain relevant details to the users of the
product.**

**Required Vendor Information**

CVE.V.1: The vendor shall indicate where in the product documentation
information regarding the use of CVE can be found. This may be a
physical document or a *static* electronic document (e.g., a PDF or help
file). This must be separate from any results reporting.

**Required Test Procedures**

Internet Connectivity: Permitted

CVE.T.1: The tester shall visually inspect the product documentation to
verify that information regarding the product's use of CVE is present
and to verify that the CVE documentation is in a location accessible to
any user of the product. This test does not involve judging the quality
of the documentation or its accuracy.

**CVE.R.2: The vendor must assert that the product implements the CVE
standard and provide a high level summary of the implementation
approach**.

**Required Vendor Information**

CVE.V.2: The vendor shall provide a 150 to 500 word English language
document to the lab that asserts that the product implements the CVE
standard and provides a high level summary of the implementation
approach. This content will be used on NIST web pages to explain details
about each validated product and thus must contain only information that
is to be publicly released. If applicable, this document shall include
information about what product functionality uses CVE versus product
functionality that does not.

**Required Test Procedures**

Internet Connectivity: Permitted

CVE.T.2.1: The tester shall inspect the provided documentation to verify
that the documentation asserts that the product implements the CVE
standard and provides a high level summary of the implementation
approach. This test is not to judge the quality or accuracy of the
documentation nor is it to test how thoroughly the product implements
CVE.

CVE.T.2.2: The tester shall verify that the provided documentation is an
English language document consisting of 150 to 500 words.

**CVE.R.3: The product shall include the associated CVE ID for each
software flaw and/or patch definition in the product output (i.e., the
product displays CVE IDs).**

**Required Vendor Information**

CVE.V.3: The vendor shall provide instructions, and a test environment
(if necessary), indicating how *product output* can be generated that
contains a listing of all software flaws and patches both with and
without CVE IDs. Instructions shall include where the CVE IDs and the
associated vendor supplied and/or official CVE description can be
located within the *product output*.

**Required Test Procedures**

Internet Connectivity: Permitted

CVE.T.3: The tester shall visually inspect, within the product output, a
random set of 30 software flaws and/or patches, to ensure that the CVE
IDs are displayed. Note, this test is not intended to determine whether
or not the product correctly maps to CVE or whether or not it provides a
complete mapping.

**CVE.R.4: The product shall provide a means to view the CVE Description
and CVE references for each displayed CVE ID**[^2] **within the product
output.**

*.*

**Required Vendor Information**

CVE.V.4: The vendor shall provide instructions on the where the CVE IDs
can be located within the product output. The vendor shall provide
procedures and a test environment (if necessary) so that the product
will output vulnerabilities with associated CVE IDs.

**Required Test Procedures**

Internet Connectivity: Permitted

CVE.T.4: The tester shall select a random sampling of CVE IDs from
within the available forms of the product output. The tester shall
determine that the product output enables the user to view, at minimum,
the official CVE description and references.[^3] The vendor may provide
additional CVE descriptions and information and should not be penalized
for doing so. The tester shall perform this using a randomly selected
set comprised of 10% of the total CVE IDs available in the product
output, up to a maximum of 30.

**CVE.R.5: The product shall indicate the correct CVE ID for each
software flaw and/or patch referenced within the product that has an
associated CVE ID (i.e., the product's CVE mapping must be correct).**

**Required Vendor Information**

CVE.V.5: None

**Required Test Procedures**

Internet Connectivity: Permitted

CVE.T.5: Using the product output from CVE.R.3 the tester shall compare
the vendor data against the official NVD CVE ID description and
references. The tester shall perform this test using a randomly selected
set comprised of 10% of the total software flaws and/or patches with CVE
IDs, up to a maximum of 30. The tester does not need to rigorously prove
that the vendor's software flaw and/or patch description matches the NVD
CVE description, but merely needs to identify that the two appear to be
same. Note, this test ensures that the product correctly maps to CVE. It
does not test for completeness of the mapping.

**CVE.R.6: The product shall associate an existing CVE ID to each
software flaw and/or patch referenced within the product for which a CVE
ID exists (i.e., the product's CVE mapping must be complete).**

**Required Vendor Information**

CVE.V.6: None.

**Required Test Procedures**

Internet Connectivity: Permitted

CVE.T.6: Using the list of software flaws and/or patches produced in
CVE.R.3, the tester shall examine the descriptions and search the NVD
for any corresponding CVE IDs. The tester shall perform this using a
randomly selected set comprised of 10% of the total software flaws
and/or patches with no CVE IDs, up to a maximum of 30. The tester does
not need to rigorously prove that no CVE ID exists, only that there does
not appear to be a match. Note, this test ensures that the product has a
complete mapping to CVE. It does not test the correctness of the mapped
data.

## Common Configuration Enumeration (CCE)

The following CCE requirements are used to achieve CCE Validation or in
conjunction with other non-CCE test requirements for SCAP Validation.
Thus, all of the tests in this sub-section are focused exclusively on
CCE and do not cover how CCE interrelates with other SCAP standards.
Section 6 includes a capability matrix that indicates which of the CCE
test requirements are used in SCAP Validation.

**CCE.R.1: The product's documentation (printed or electronic) must
state that it uses CCE and explain relevant details to the users of the
product.**

**Required Vendor Information**

CCE.V.1: The vendor shall indicate where in the product documentation
information regarding the use of CCE can be found. This may be a
physical document or a *static* electronic document (e.g., a PDF or help
file).

**Required Test Procedures**

Internet Connectivity: Permitted

CCE.T.1: The tester shall visually inspect the product documentation to
verify that information regarding the product's use of CCE is present
and to verify that the CCE documentation is in a location accessible to
any user of the product. This test does not involve judging the quality
of the documentation or its accuracy.

**CCE.R.2: The vendor must assert that the product implements the CCE
standard and provide a high level summary of the implementation
approach**.

**Required Vendor Information**

CCE.V.2: The vendor shall provide a 150 to 500 word English language
document to the lab that asserts that the product implements the CCE
standard and provides a high level summary of the implementation
approach. This content will be used on NIST web pages to explain details
about each validated product and thus must contain only information that
is to be publicly released. If applicable, this document shall include
information about what product functionality uses CCE versus product
functionality that does not.

**Required Test Procedures**

Internet Connectivity: Permitted

CCE.T.2.1: The tester shall inspect the provided documentation to verify
that the documentation asserts that the product implements the CCE
standard and provides a high level summary of the implementation
approach. This test is not to judge the quality or accuracy of the
documentation nor is it to test how thoroughly the product implements
CCE.

CCE.T.2.2: The tester shall verify that the provided documentation is an
English language document consisting of 150 to 500 words.

**CCE.R.3: The product shall display the associated CCE ID for each
mis-configuration definition in the product output (i.e., the product
displays CCE IDs).**

**Required Vendor Information**

CCE.V.3: The vendor shall provide instructions on how *product output*
can be generated that contains a listing of all mis-configuration items
both with and without CCE IDs. Instructions shall include where the CCE
IDs and the associated vendor supplied and/or official CCE description
can be located within the *product output*.

**Required Test Procedure**

Internet Connectivity: Permitted

CCE.T.3: The tester shall visually inspect, within the product output, a
random set of 30 mis-configuration items, to ensure that the CCE IDs are
displayed. Note, this test is not intended to determine whether or not
the product correctly maps to CCE or whether or not it provides a
complete mapping.

**CCE.R.4: The product shall provide a means to view the CCE Description
for each displayed CCE ID within the product output.**

***NOTE: This requirement is being deferred until September 1st, 2008
for SCAP Capabilities. All products seeking validation or re-validation
subsequent to this date will be required to meet this requirement as
part of their testing. Products seeking specific CVSS Validation are
still required to meet this requirement.***

**Required Vendor Information**

CCE.V.4: The vendor shall provide instructions noting where the CCE ID
can be located within the product output. The vendor shall provide
procedures and a test environment (if necessary) so that the product
will output configuration issues with associated CCE IDs.

**Required Test Procedures**

Internet Connectivity: Permitted

CCE.T.4: The tester shall inspect the CCE IDs from the product output
and verify that the official CCE Description[^4] is available. The
vendor may provide additional CCE descriptions and information and
should not be penalized for doing so. The tester shall perform this
using a randomly selected setof 10% of the total CCE IDs available in
the product output, up to a maximum of 30.

**CCE.R.5: The product shall relate the correct CCE ID for each
configuration referenced within the product that has an associated CCE
ID (i.e., the product's CCE mapping must be correct).**

**Required Vendor Information**

CCE.V.5: None.

**Required Test Procedures**

Internet Connectivity: Permitted

CCE.T.5: Using the product output from CCE.R.3 the tester shall compare
the vendor data against the official CCE description and references. The
tester shall perform the comparison using a randomly selected set
comprised of 10% of the total mis-configuration items with CCE IDs, up
to a maximum of 30. The tester does not need to rigorously prove that
the vendor's mis-configuration description matches the official CCE
description, but merely needs to identify that the two appear to be
same. Note that this test ensures that the product correctly maps to
CCE. It does not test for completeness of the mapping.

**CCE.R.6: The product shall associate an existing CCE ID to each
configuration referenced within the product for which a CCE ID exists
(i.e., the product's CCE mapping must be complete).**

**Required Vendor Information**

CCE.V.6: None.

**Required Test Procedures**

Internet Connectivity: Permitted

CCE.T.6: Using the list of mis-configuration items produced in CCE.R.3,
the tester shall examine the descriptions and search the CCE dictionary
for all corresponding CCE IDs.. The tester shall perform this using a
randomly selected set comprised of 10% of the total mis-configuration
items with no CCE IDs, up to a maximum of 30. The tester does not need
to rigorously prove that no CCE ID exists, only that there does not
appear to be a match. Note, this test ensures that the product has a
complete mapping to CCE. It does not test the correctness of the mapped
data.

## Common Platform Enumeration

The following CPE requirements are used to achieve CPE Validation or in
conjunction with other non-CPE test requirements for SCAP Validation.
Thus, all of the tests are focused exclusively on CPE and do not cover
how CPE interrelates with other SCAP standards. Section 5 includes a
capability matrix that indicates which of the CPE test requirements are
used in SCAP Validation. .

**CPE.R.1: The product's documentation (printed or electronic) must
state that it uses CPE and explain relevant details to the users of the
product.**

**Required Vendor Information**

CPE.V.1: The vendor shall indicate where in the product documentation
information regarding the use of CPE can be found. This may be a
physical document or a *static* electronic document (e.g., a PDF or help
file).

**Required Test Procedures**

Internet Connectivity: Permitted

CPE.T.1: The tester shall visually inspect the product documentation to
verify that information regarding the product's use of CPE is present
and to verify that the CPE documentation is in a location accessible to
any user of the product. This test does not involve judging the quality
of the documentation or its accuracy.

**CPE.R.2: The vendor must assert that the product implements the CPE
standard and provide a high level summary of the implementation
approach**.

**Required Vendor Information**

CPE.V.2: The vendor shall provide a 150 to 500 word English language
document to the lab that asserts that the product implements the CPE
standard and provides a high level summary of the implementation
approach. This content will be used on NIST web pages to explain details
about each validated product and thus must contain only information that
is to be publicly released. If applicable, this document shall include
information about what product functionality uses CPE versus product
functionality that does not.

**Required Test Procedures**

Internet Connectivity: Permitted

CPE.T.2.1: The tester shall inspect the provided documentation to verify
that the documentation asserts that the product implements the CPE
standard and provides a high level summary of the implementation
approach. This test is not to judge the quality or accuracy of the
documentation nor is it to test how thoroughly the product implements
CPE.

CPE.T.2.2: The tester shall verify that the provided documentation is an
English language document consisting of 150 to 500 words.

**CPE.R.3: If the product natively contains a product dictionary (as
opposed to dynamically importing content containing CPE Names), the
product must contain CPE naming data from the current official CPE
Dictionary.**

***NOTE: This requirement does not apply if the product is using the
official dynamic CPE Dictionary as provided on the NVD web site or as
part of an SCAP data stream.***

**Required Vendor Information**

CPE.V.3.1: The vendor shall provide a list of all CPE Names included in
the product using the standard CPE Dictionary XML schema as provided in
the CPE Specification version cited in section 2.1.

CPE.V.3.2: If the vendor product includes CPE Names that are not in the
official CPE dictionary, a listing of exceptions must be provided.

**Required Test Procedure**

Internet Connectivity: Permitted

CPE.T.3: Using the "CPE Validation Utility", the tester shall import the
vendor provided list of CPE Names for comparison against the official
CPE Dictionary. Prior to each tool being tested, the latest CPE
Dictionary must be used in the utility. The tester shall verify that all
exceptions found by the "CPE Validation Utility" match the list of
exceptions provided by the vendor.

**CPE.R.4: A product's machine-readable output must provide the CPE
naming data using CPE Names. This requirement does not apply if the
product does not produce machine-readable output.**

**Required Vendor Information**

CPE.V.4: The vendor shall provide procedures and/or a test environment
where machine-readable output containing the CPE naming data can be
produced and inspected. The vendor shall provide a translation tool to
create human readable data for inspection if the provided output is not
in a human-readable format (i.e. binary data, encrypted text, etc).

**Required Test Procedure**

Internet Connectivity: Permitted

CPE.T.4: The tester shall manually inspect the vendor identified
machine-readable output and ensure that CPE naming data is correct
according to the CPE specification. The tester will do this by randomly
choosing up to 30 vendor and product names in the product output that
are also included in the official CPE dictionary.

## Common Vulnerability Scoring System (CVSS)

The following CVSS requirements are used to achieve CVSS Validation or
in conjunction with other non-CVSS test requirements for SCAP
Validation. Thus, all of the tests are focused exclusively on CVSS and
do not cover how CVSS interrelates with other SCAP standards. Section 6
includes a capability matrix that indicates which of the CVSS test
requirements are used in SCAP Validation.

**CVSS.R.1: The product's documentation (printed or electronic) must
state that it uses CVSS and explain relevant details to the users of the
product. If external CVSS data is imported into the product, the
documentation must state the source.**

**Required Vendor Information**

CVSS.V.1: The vendor shall indicate where in the product documentation
information regarding the use of CVSS can be found. This may be a
physical document or a *static* electronic document (e.g., a PDF or help
file).

**Required Test Procedures**

Internet Connectivity: Permitted

CVSS.T.1: The tester shall visually inspect the provided product
documentation to verify that information regarding the product's use of
CVSS is documented, verify that the source of the CVSS data is
specified, and verify that the CVSS documentation is in a location
accessible to any user of the product. This test does not involve
judging the quality of the documentation or its accuracy.

**CVSS.R.2: The vendor must assert that the product implements the CVSS
standard and provide a high level summary of the implementation
approach**.

**Required Vendor Information**

CVSS.V.2: The vendor shall provide a 150 to 500 word English language
document to the accredited validation lab that asserts that the product
implements the CVSS standard and provides a high level summary of the
implementation approach. This content will be used on NIST web pages to
explain details about each validated product and thus must contain only
information that is to be publicly released. If applicable, this
document shall include information about what product functionality uses
CVSS versus product functionality that does not.

**Required Test Procedures**

Internet Connectivity: Permitted

CVSS.T.2.1: The tester shall inspect the provided documentation to
verify that the documentation asserts that the product implements the
CVSS standard and provides a high level summary of the implementation
approach. This test is not to judge the quality or accuracy of the
documentation nor is it to test how thoroughly the product implements
CVSS.

CVSS.T.2.2: The tester shall verify that the provided documentation is
an English language document consisting of 150 to 500 words.

**CVSS.R.3: The product provides CVSS base scores for each security
related software flaw referenced in the product.**

***NOTE: This requirement is being deferred until September 1st, 2008
for SCAP Capabilities . All products seeking validation or re-validation
subsequent to this date will be required to meet this requirement as
part of their testing. Products seeking specific CVSS Validation are
still required to meet this requirement.***

**Required Vendor Information**

CVSS.V.3.1: The vendor shall provide documentation and/or procedures
that explain how to view software flaws and associated CVSS base scores
within the product output.

CVSS.V.3.2: The vendor shall provide documentation and/or procedures
that explain how to produce a report of all software flaws supported by
the tool along with their associated CVSS base scores.

**Required Test Procedure**

Internet Connectivity: Permitted

CVSS.T.3.1: The tester shall validate that the product output provides
impact scores labeled as CVSS scores for a random sample of 30 security
related software flaws referenced in the product output. The tester does
not need to validate the correctness of the scores within this test.

CVSS.T.3.2: The tester shall validate that the product provides impact
scores labeled as CVSS scores for 30 randomly chosen software flaws in
the tool. The tester does not need to validate the correctness of the
scores within this test.

**CVSS.R.4: The product provides CVSS vector strings along with each
provided CVSS base score**[^5]**.**

***NOTE: This requirement is being deferred until September 1st, 2008
for SCAP Capabilities . All products seeking validation or re-validation
subsequent to this date will be required to meet this requirement as
part of their testing. Products seeking specific CVSS Validation are
still required to meet this requirement.***

**Required Vendor Information**

CVSS.V.4.1: The vendor shall provide documentation and/or procedures
that explains how to view the CVSS vector string for all software flaws
in the product that have CVSS base scores.

**Required Test Procedure**

Internet Connectivity: Permitted

CVSS.T.4.1: The tester shall randomly choose 30 CVSS vector strings
provided by the product and validate that they conform to the CVSS
version vector specification as described in Section 2. The vectors
chosen should all be unique vectors (each one is different from the
others).

CVSS.T.4.2: For each of the 30 CVSS vectors used in CVSS.T.4.1, the
tester shall validate that the associated CVSS vector calculates to the
same CVSS base score as provided by the product. The tester shall use
the NVD CVSS calculator reference implementation to perform the
calculations.

**CVSS.R.5: The product enables users to customize**[^6] **CVSS base
scores to produce CVSS temporal scores for each CVSS base score provided
by the product. Alternately, the product may directly provide temporal
scores**[^7]**.**

***NOTE: This requirement is being deferred until September 1st, 2008
for SCAP Capabilities . All products seeking validation or re-validation
subsequent to this date will be required to meet this requirement as
part of their testing. Products seeking specific CVSS Validation are
still required to meet this requirement.***

***Note: The required elements for temporal scoring are available from
NIST IR 7435 section 2.2.***

**Required Vendor Information**

CVSS.V.5.1: The vendor will provide documentation explaining how users
can customize CVSS base scores to produce CVSS temporal scores for each
CVSS base score provided by the product. Alternately, the vendor will
provide documentation stating that they directly provide temporal scores
for the user. It is possible that a product will do a combination of
both approaches.

**Required Test Procedure**

Internet Connectivity: Permitted

CVSS.T.5.1: The tester shall validate that the product enables users to
customize CVSS scores to produce CVSS temporal scores or the product
directly provides temporal scores for a set of chosen software flaws
referenced in the product.

CVSS.T.5.2: For the set of chosen software flaws in CVSS.T.3.1 (reuse of
previous sample), the tester shall perform the same CVSS base score
customization using the NVD CVSS calculator reference implementation and
validate that the resultant NVD CVSS calculator and product temporal
scores are equal.

**CVSS.R.6: The product enables users to customize**[^8] **CVSS base
scores to produce CVSS environmental scores for each software flaw
referenced in the product**[^9][^10][^11]**.**

*.*

***NOTE: This requirement is being deferred until September 1st, 2008
for SCAP Capabilities. All products seeking validation or re-validation
subsequent to this date will be required to meet this requirement as
part of their testing. Products seeking specific CVSS Validation are
still required to meet this requirement.***

**Required Vendor Information**

CVSS.T.6: The vendor will provide documentation explaining how users can
customize CVSS base scores to produce CVSS environmental scores for each
CVSS base score provided by the product.

**Required Test Procedure**

Internet Connectivity: Not-permitted

CVSS.T.6.1: The tester shall validate that the product enables users to
customize CVSS base scores to produce CVSS environmental scores for 10
randomly chosen software flaws referenced in the product.

CVSS.T.6.2: For the 10 randomly chosen software flaws in CVSS.T.6.1, the
tester shall perform the same CVSS base score customization using the
NVD CVSS calculator reference implementation and validate that the NVD
CVSS calculator and product environmental scores are equal.

## eXtensible Configuration Checklist Document Format (XCCDF)

The following XCCDF requirements are used to achieve XCCDF Validation or
in conjunction with other non-XCCDF test requirements for SCAP
Validation. Thus, all of the tests are focused exclusively on XCCDF and
do not cover how XCCDF interrelates with other SCAP standards. Section 6
includes a capability matrix that indicates which of the XCCDF test
requirements are used in SCAP Validation.

Because of the versatility of the XCCDF language, it can be used in a
variety of roles. Some of the test requirements have been classified
based on their specific role and these are in turn applied to the
relevant SCAP Capability.

**XCCDF.R.1: The product's documentation (printed or electronic) must
state that it uses XCCDF and explain the relevant details to the users
of the product.**

**Required Vendor Information**

XCCDF.V.1: The vendor shall indicate where in the product documentation
information regarding the use of XCCDF can be found. This may be a
physical document or a *static* electronic document (e.g., a PDF or help
file).

**Required Test Procedures**

Internet Connectivity: Permitted

XCCDF.T.1: The tester shall visually inspect the product documentation
to verify that information regarding the product's use of XCCDF is
present and verify that the XCCDF documentation is in a location
accessible to any user of the product. This test does not involve
judging the quality of the documentation or its accuracy.

**XCCDF.R.2: The vendor must assert that the product implements the
XCCDF standard and provide a high level summary of the implementation
approach**.

**Required Vendor Information**

XCCDF.V.2: The vendor shall provide a 150 to 500 word English language
document to the lab that asserts that the product implements the XCCDF
standard and provides a high level summary of the implementation
approach. This content will be used on NIST web pages to explain details
about each validated product and thus must contain only information that
is to be publicly released. If applicable, this document shall include
information about what product functionality uses CPE versus product
functionality that does not.

**Required Test Procedures**

Internet Connectivity: Permitted

XCCDF.T.2.1: The tester shall inspect the provided documentation to
verify that the documentation asserts that the product implements the
XCCDF standard and provides a high level summary of the implementation
approach. This test is not to judge the quality or accuracy of the
documentation nor is it to test how thoroughly the product implements
XCCDF.

XCCDF.T.2.2: The tester shall verify that the provided documentation is
an English language document consisting of 150 to 500 words.

**XCCDF.R.3: The product shall report XCCDF content that is invalid
according to the XCCDF schema***.*

**Required Vendor Information**

XCCDF.V.3: The vendor shall provide instructions on how and where XCCDF
schema errors will be displayed within the *product output*.

**Required Test Procedure**

Internet Connectivity: Not-permitted

XCCDF.T.3: The tester shall attempt to import known invalid XCCDF
content into the vendor product and examine the *product output* to
validate that the tool reports the content as invalid according to the
XCCDF schema.

**XCCDF.R.4: The product shall be able to process XCCDF files and
generate XCCDF Results in accordance with the XCCDF specification for
the *target platform*.**

**Required Vendor Information**

XCCDF.V.4: The vendor shall provide instructions on how to import XCCDF
files for execution and provide instructions on where the XCCDF Results
can be located for visual inspection. Use of any XCCDF capable check
system(s) is permitted. The purpose of this requirement is to insure
that the product produces valid XCCDF Results and a matching pass/fail
result for a given Rule.

**Required Test Procedure**

Internet Connectivity: Not-permitted

XCCDF.T.4.1: The tester shall import a known valid XCCDF file for the
*target platform* into the vendor tool and execute it according to the
tool operation instructions provided by the vendor. The tester will
inspect the output to validate that it includes the same checks, and
uses the same check parameters as that produced by the NIST XCCDF
reference implementation.

XCCDF.T.4.2: The tester shall validate the resulting XCCDF result output
using the XCCDF schema. This validation must not produce any validation
errors.

XCCDF.T.4.3: The tester shall compare the product results to those
produced by the XCCDF reference implementation to ensure that the
pass/fail results match for each Rule.

NOTE: If the product is not seeking OVAL validation, results will
indicate that the Rules were not executed. This is acceptable.

**XCCDF.R.5: The user shall be able to select a specific XCCDF Profile
when executing an XCCDF file on the *target platform*. The product will
execute the XCCDF content using the chosen profile.**

**Required Vendor Information**

XCCDF.V.5: The vendor shall provide instructions on how the user can
select an XCCDF Profile when executing a schema valid XCCDF content
file.

**Required Test Procedures**

Internet Connectivity: Not-permitted

XCCDF.T.5: The tester shall validate that the product produces results
applicable to the chosen XCCDF profile on the *target platform*.

**XCCDF.R.6: The product shall be able to import an XCCDF file and
generate human readable prose (close correspondence to the patterns of
everyday speech) from valid XCCDF documents. This requirement includes
XCCDF checklists as well as output result files.**

**Required Vendor Information**

XCCDF.V.6: The vendor shall provide instructions on how the product
generates human readable prose from valid XCCDF documents.

**Required Test Procedures**

Internet Connectivity: Permitted

XCCDF.T.6: The tester shall use the vendor product to generate human
readable prose from a valid XCCDF document.

## Open Vulnerability Assessment Language (OVAL)

The following OVAL requirements are used to achieve OVAL Validation or
in conjunction with other non-OVAL test requirements for SCAP
Validation. Thus, all of the tests are focused exclusively on OVAL and
do not cover how OVAL interrelates with other SCAP standards. Section 6
includes a capability matrix that indicates which of the OVAL test
requirements are used in SCAP Validation.

Because of the versatility of the OVAL language, it can be used in a
variety of roles. Some of the test requirements have been classified
based on their specific role and these are in turn applied to the
relevant SCAP Capability.

**OVAL.R.1: The product's documentation (printed or electronic) must
state that it uses OVAL and explain relevant details to the users of the
product.**

**Required Vendor Information**

OVAL.V.1: The vendor shall indicate where in the product documentation
information regarding the use of OVAL can be found. This may be a
physical document or a *static* electronic document (e.g., a PDF or help
file).

**Required Test Procedures**

Internet Connectivity: Permitted

OVAL.T.1: The tester shall visually inspect the product documentation to
verify that information regarding the product's use of OVAL is present
and to verify that the OVAL documentation is in a location accessible to
any user of the product. This test does not involve judging the quality
of the documentation or its accuracy.

**OVAL.R.2: The vendor must assert that the product implements the OVAL
standard and provide a high level summary of the implementation
approach**.

**Required Vendor Information**

OVAL.V.2: The vendor shall provide a 150 to 500 word English language
document to the accredited validation lab that asserts that the product
implements the OVAL standard and provides a high level summary of the
implementation approach. This content will be used on NIST web pages to
explain details about each validated product and thus must contain only
information that is to be publicly released. If applicable, this
document shall include information about what product functionality uses
CPE versus product functionality that does not.

**Required Test Procedures**

Internet Connectivity: Permitted

OVAL.T.2.1: The tester shall inspect the provided documentation to
verify that the documentation asserts that the product implements the
OVAL standard and provides a high level summary of the implementation
approach. This test is not to judge the quality or accuracy of the
documentation nor is it to test how thoroughly the product implements
OVAL.

OVAL.T.2.2: The tester shall verify that the provided documentation is
an English language document consisting of 150 to 500 words.

**OVAL.R.3: The product shall report and optionally reject OVAL content
that is invalid according to the OVAL XML schemas and Schematron
stylesheets.**

**Required Vendor Information**

OVAL.V.3: The vendor shall provide instructions on how validation of
OVAL content is performed and where errors from validation will be
displayed within the *product output.*

**Required Test Procedure**

Internet Connectivity: Not-permitted

OVAL.T.3: The tester shall attempt to import known invalid OVAL content
into the vendor tool and examine the results to validate that the tool
reports and optionally rejects the content as invalid according to the
OVAL schema.

**OVAL.R.4: The product output shall enable users to view the OVAL
Definitions being consumed by the tool (e.g., within the product user
interface or through an XML dump of the OVAL definitions to a file).**

**Required Vendor Information**

OVAL.V.4: The vendor shall provide instructions on how the user can view
the OVAL Definitions being consumed by the product.

**Required Test Procedure**

Internet Connectivity: Not-permitted

OVAL.T.4: The tester shall follow the provided vendor instructions to
view the OVAL Definitions being consumed by the product and verify that
access is provided as stated.

**OVAL.R.5: The product shall be able to correctly evaluate a valid OVAL
Definition file against target systems of the *target platform* type and
produce a result file for each definition using the OVAL XML Full Result
format.**

***NOTE: This requirement is being deferred until September 1st, 2008
for the FDCC Scanner capability. All products seeking validation or
re-validation subsequent to this date will be required to meet this
requirement as part of their testing. Products seeking specific OVAL
Validation or validation of other SCAP Capabilities are still required
to meet this requirement.***

**Required Vendor Information**

OVAL.V.5: None.

**Required Test Procedure**

Internet Connectivity: Not-permitted

OVAL.T.5.1: The tester shall run the tool using valid OVAL Definitions
files against the target systems or the *target platform* type. The
results shall be compared against results from the OVAL reference
implementation and they must produce the same pass/fail result for each
OVAL definition and criteria contained within the definition.

OVAL.T.5.2: The tester shall validate the resulting OVAL result output
using the OVAL schema and Schematron style sheets. Both of these
validations must not produce any validation errors.

# SCAP Derived Test Requirements 

This section builds on the standard specific features that are validated
for in section 4. This section defines the requirements for validation
of SCAP specific behaviors for the SCAP standards when they are used in
conjunction with one another.

## Federal Desktop Core Configuration (FDCC)

**FDCC.R.1: The product shall be able to correctly assess a target
system using the** **FDCC SCAP data streams as input.**

**Required Vendor Information**

FDCC.V.1: The vendor shall provide instructions on how to execute a
previously imported valid FDCC SCAP data stream.

**Required Test Procedures**

Internet Connectivity: Not-permitted

Per vendor instruction in FDCC.V.1, the lab will make the necessary
configuration changes to the *target platform* and document what has
been changed. The pass/fail comparison of these changes shall not impact
the Pass or Fail result of the test.

Files examined for the following three tests will include the following
results produced by the product: XCCDF results, OVAL patch results and
OVAL compliance results.

FDCC.T.1.1: The tester shall evaluate an FDCC compliant *target
platform* and compare the pass/fail results from the product to the
results provided as part of the test suite to ensure that they match.

FDCC.T.1.2: The tester shall evaluate an FDCC non-compliant *target
platform* and compare the pass/fail results from the product to the
results provided as part of the test suite to ensure that they match.

FDCC.T.1.3: The tester shall evaluate an FDCC partial-compliant *target
platform*, and compare the pass/fail results from the product to the
results provided as part of the test suite to ensure that they match.

**FDCC.R.2: The product shall be able to produce XCCDF results using the
FDCC reporting format.**

**Required Vendor Information**

FDCC.V.2: None

**Required Test Procedure**

Internet Connectivity: Permitted

FDCC.T.2: The tester shall validate the XCCDF results produced, on the
*target platform* by the product, against the FDCC reporting Schematron
stylesheet and must verify that no validation errors are produced.

**FDCC.R.3: If the vendor product requires a specific configuration of
the *target platform* that is not in compliance with the FDCC, the
vendor shall provide documentation indicating which settings must be
changed and a rationale for each changed setting. Products should only
require changes to the target platform in order to function correctly.**

**Required Vendor Information**

FDCC.V.3: The vendor shall provide an English language document to the
lab that indicates which settings must be changed and a rationale for
each changed setting. This content will be used on NIST web pages to
explain details about each validated product and thus must contain only
information that is to be publicly released.

**Required Test Procedure**

Internet Connectivity: Permitted

FDCC.T.3: The tester shall review the provided documentation to ensure
that each indicated setting includes an associated rationale.

## General SCAP Requirements

**SCAP.R.1: The product's documentation (printed or electronic) must
state that it uses SCAP and explain relevant details to the users of the
product.**

**Required Vendor Information**

SCAP.V.1: The vendor shall indicate where in the product documentation
information regarding the use of SCAP can be found. This may be a
physical document or a *static* electronic document (e.g., a PDF or help
file).

**Required Test Procedures**

Internet Connectivity: Permitted

SCAP.T.1: The tester shall visually inspect the product documentation to
verify that information regarding the product's use of SCAP is present
and verify that the SCAP documentation is in a location accessible to
any user of the product. This test does not involve judging the quality
of the documentation or its accuracy.

**SCAP.R.2: The vendor must assert that the product implements the SCAP
standard and provide a high level summary of the implementation
approach**.

**Required Vendor Information**

SCAP.V.2: The vendor shall provide a 150 to 500 word English language
document to the lab that asserts that the product implements the SCAP
standard and provides a high level summary of the implementation
approach. This content will be used on NIST web pages to explain details
about each validated product and thus must contain only information that
is to be publicly released.

**Required Test Procedures**

Internet Connectivity: Permitted

SCAP.T.2.1: The tester shall inspect the provided documentation to
verify that the documentation asserts that the product implements the
SCAP standard and provides a high level summary of the implementation
approach. This test is not to judge the quality or accuracy of the
documentation nor is it to test how thoroughly the product implements
SCAP.

SCAP.T.2.2: The tester shall verify that the provided documentation is
an English language document consisting of 150 to 500 words.

**SCAP.R.3: The SCAP Capabilities claimed by the vendor for the product
under test must match the scope of the product's asserted Capabilities
for the target platform.**

**Required Vendor Information**

SCAP.V.3.1: The vendor shall indicate for which of the defined SCAP
Capabilities their product is being tested. This can be one or more.

SCAP.V.3.2: The vendor shall provide product documentation that
enumerates the general *product Capabilities* for the target platform
(e.g., anti-virus, intrusion detection, firewall) that relate to the
asserted SCAP Capabilities.

**Required Test Procedure**

Internet Connectivity: Permitted

SCAP.T.3.1: The tester shall ensure that all tests associated with the
asserted SCAP Capabilities of the product are conducted.

SCAP.T.3.2: The tester shall review product documentation to ensure that
the product has implemented the SCAP Capabilities for which it is being
tested. (e.g. Configuration Scanner, Asset Database, etc...)

**SCAP.R.4: For all static or product bundled SCAP data (i.e. CCE, CPE,
CVE and data streams), the product shall indicate the date the data was
last generated and updated**[^12]**. The generated date is when the data
was originally created/officially published. The updated date is the
date the product obtained its copy of the data.**

**Required Vendor Information**

SCAP.V.4: The vendor shall provide instructions on where the dates for
all offline SCAP data can be inspected in the *product output*. This
ensures that the age of content used in the vendor product is available
to users.

**Required Test Procedure**

Internet Connectivity: Not-permitted

SCAP.T.4: The tester shall visually inspect the product output for the
dates of all static or bundled SCAP data included with the vendor
product.

## XCCDF + OVAL (Input)

**SCAP.R.5: The product shall be able to import an XCCDF data file for
the target platform and correctly load the included Rules and their
associated OVAL Definitions on a target system.**

**Required Vendor Information**

SCAP.V.5: The vendor shall provide documentation and instruction on how
to import an SCAP data stream for the target platform, including XCCDF
and OVAL content, into their product.

**Required Test Procedures**

Internet Connectivity: Not-permitted

SCAP.T.5: The tester shall import valid SCAP data streams for the target
platform into the vendor product and execute it on a target system.
Results of the scan shall be visually compared to the results from the
XCCDF and OVAL *reference tools* to validate that the results match.
This test is to ensure that the product's XCCDF and OVAL integration is
working correctly.

## XCCDF + OVAL (Output)

**SCAP.R.6: XCCDF Results files and OVAL Results files shall be produced
by the tool in compliance with the XCCDF and OVAL Results schemas.**

***NOTE: This requirement is being deferred until September 1^st^, 2008
for certain SCAP Capabilities. For those capabilities, a "D" is marked
on the matrix in Section 6. All products seeking validation or
re-validation subsequent to this date will be required to meet this
requirement as part of the validation testing of their product.***

**Required Vendor Information**

SCAP.V.6: The vendor shall also provide instruction on where the
corresponding XCCDF and OVAL results files can be located for
inspection.

**Required Test Procedures**

Internet Connectivity: Not-permitted

SCAP.T.6: The tester shall visually inspect XCCDF and OVAL results to
validate that they are valid according the associated specification for
each. The output is also compared to the results from the reference
implementation to verify completeness and accuracy of the XCCDF and OVAL
results.

## XCCDF + CCE

**SCAP.R.7: For all CCE IDs in the XCCDF input document, the product
shall correctly display the CCE ID with its associated XCCDF Rule in the
product output.**

**Required Vendor Information**

SCAP.V.7: The vendor shall provide instructions on where the XCCDF Rules
and their associated CCE IDs can be visually inspected within the
*product output*.

**Required Test Procedures**

Internet Connectivity: Permitted

SCAP.T.7: The tester shall visually inspect a random sample within the
product user interface and reports to validate that the CCE IDs for each
inspected XCCDF Rule match those found in the XCCDF source file.

## XCCDF + OVAL + CPE

**SCAP.R.8: The product shall be able to determine the validity of
imported SCAP XCCDF/OVAL files by evaluating the associated OVAL
definition for the CPE Name on an XCCDF \<Benchmark\>, \<Group\> or
\<Rule\> and verifying that the associated XCCDF content applies to the
target system.**

**Required Vendor Information**

SCAP.V.8: The vendor shall provide instructions on how the product
indicates the validity of the imported SCAP data stream to a target
platform. Instructions should also describe how the imported data stream
is indicated to be not valid for a target platform. This requirement is
testing the use of the OVAL check associated with a CPE name via the CPE
dictionary to determine applicability of the data stream.

**Required Test Procedures**

Internet Connectivity: Permitted

SCAP.T.8: The tester shall import an SCAP data stream into the tool that
contains a CPE Name and related OVAL definition not applicable for the
target system. The tester shall verify that the product declines to
execute the non-applicable tests.

## CVSS + CVE

**SCAP.R.9: If the product uses CVE, it shall include NVD CVSS base
scores and vector strings for each CVE ID referenced in the product.**

**Required Vendor Information**

SCAP.V.9: The vendor shall provide documentation explaining where the
NVD CVSS base scores and vector strings can be located with the
corresponding CVE ID. The vendor may optionally provide the tester
information on how the product can be updated with new NVD CVSS base
scores and vector strings prior to testing.

**Required Test Procedure**

Internet Connectivity: Permitted

SCAP.T.9: The tester shall update the product's NVD base scores and
vectors (using the vendor provided update capability if it exists) and
validate that the product displays the NVD CVSS base scores and vectors
for 15 randomly chosen CVE IDs referenced in the product. The CVEs
chosen must have an NVD vulnerability summary "last revision" date that
is at least 30 days old. A link to the information on the NVD web site
is sufficient for this test.

## SCAP Data Stream Import

**SCAP.R.10: The product shall enable the user to import an SCAP data
stream.**

**Required Vendor Information**

SCAP.V.10: The vendor shall provide documentation explaining how an SCAP
data stream can be imported into the product and subsequently executed.

**Required Test Procedure**

Internet Connectivity: Not Permitted

SCAP.T.10: The tester shall import a valid SCAP data stream into the
vendor product and ensure that the imported content is available for
execution.

## Compliance Mapping Output

***NOTE: This requirement is being deferred until September 1^st^, 2008
for SCAP certain Capabilities. For those capabilities, a "D" is marked
on the matrix in Section 6. All products seeking validation or
re-validation subsequent to this date will be required to meet this
requirement as part of the validation testing of their product.***

**SCAP.R.11: When processing SCAP data streams that contain compliance
mappings to included CCE's, the product shall output the compliance
mappings.**

**Required Vendor Information**

SCAP.V.11: The vendor shall provide documentation explaining where CCE
compliance mappings can be viewed within the product output.

**Required Test Procedure**

Internet Connectivity: Not Permitted

SCAP.T.11: Using the vendor product, the tester shall execute a valid
SCAP data stream with CCE compliance mapping information and view the
resultant output to ensure that the CCE compliance mappings are correct.

# Derived Test Requirements for Specific Capability

This section contains Derived Test Requirements for each of the defined
*SCAP capabilities*.

When a tool is submitted for validation, the submitting organization
will provide a list of *capabilities* the tool possesses, as defined in
this document. The information regarding *capabilities* will be provided
by the vendor as part of their submission package.

To determine the correct test requirements for that tool, the tester
creates the union of all these *capabilities*, using the provided chart.

The following chart summarizes the required *SCAP Components* for each
*SCAP* *Capability* together with the specific requirements necessary to
achieve SCAP validation.

Chart A

  ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
                  **FDCC      **Authenticated   **Authenticated   **Unauthenticated   **IDPS**   **Patch         **Mis-configuration   **Asset        **Asset      **Vulnerability   **Mis-Configuration\   **Malware
                  Scanner**   Configuration     Vulnerability and Vulnerability                  Remediation**   Remediation**         Management**   Database**   Database**        Database**             Tool**
                              Scanner**         Patch Scanner**   Scanner**                                                                                                                                 
  --------------- ----------- ----------------- ----------------- ------------------- ---------- --------------- --------------------- -------------- ------------ ----------------- ---------------------- -----------
  **FDCC.R.1**    X                                                                                                                                                                                          

  **FDCC.R.2**    X                                                                                                                                                                                          

  **FDCC.R.3**    X                                                                                                                                                                                          

  **CVE.R.1**     X           ** **             X                 X                   X          X                                                                 X                                        X

  **CVE.R.2**     X           ** **             X                 X                   X          X                                                                 X                                        X

  **CVE.R.3**     X           ** **             X                 X                   X          X                                                                 X                                        X

  **CVE.R.4**     X           ** **             X                 X                   X          X                                                                 X                                        X

  **CVE.R.5**     X           ** **             X                 X                   X          X                                                                 X                                        X

  **CVE.R.6**     X           ** **             X                 X                   X          X                                                                 X                                        X

  **CCE.R.1**     X           X                                                                                  X                                                                   X                       

  **CCE.R.2**     X           X                                                                                  X                                                                   X                       

  **CCE.R.3**     X           X                                                                                  X                                                                   X                       

  **CCE.R.4**                                                                                                                                                                                                

  **CCE.R.5**     X           X                                                                                  X                                                                   X                       

  **CCE.R.6**     X           X                                                                                  X                                                                   X                       

  **CPE.R.1**     X           X                 X                 X                   X          X               X                     X              X            X                 X                      X

  **CPE.R.2**     X           X                 X                 X                   X          X               X                     X              X            X                 X                      X

  **CPE.R.3**     X           X                 X                 X                   X          X               X                     X              X            X                 X                      X

  **CPE.R.4**     X           X                 X                 X                   X          X               X                     X              X            X                 X                      X

  **CVSS.R.1**    X           X                 X                 X                   X          X               X                                                 X                                        X

  **CVSS.R.2**    X           X                 X                 X                   X          X               X                                                 X                                        X

  **CVSS.R.3**                                                                                                                                                     X                                         

  **CVSS.R.4**                                                                                                                                                     X                                         

  **CVSS.R.5**                                                                                                                                                                                               

  **CVSS.R.6**                                                                                                                                                                                               

  **XCCDF.R.1**   X           X                                                                                                                                                                              

  **XCCDF.R.2**   X           X                                                                                                                                                                              

  **XCCDF.R.3**   X           X                                                                                                                                                                              

  **XCCDF.R.4**   X           X                                                                                                                                                                              

  **XCCDF.R.5**   X           X                                                                                                                                                                              

  **XCCDF.R.6**                                                                                                                                                                                              

  **OVAL.R.1**    X           X                 X                                                                                                                                                            

  **OVAL.R.2**    X           X                 X                                                                                                                                                            

  **OVAL.R.3**    X           X                 X                                                                                                                                                            

  **OVAL.R.4**    X           X                 X                                                                                                                                                            

  **OVAL.R.5**                X                 X                                                                                                                                                            

  **SCAP.R.1**    X           X                 X                 X                   X          X               X                     X              X            X                 X                      X

  **SCAP.R.2**    X           X                 X                 X                   X          X               X                     X              X            X                 X                      X

  **SCAP.R.3**    X           X                 X                 X                   X          X               X                     X              X            X                 X                      X

  **SCAP.R.4**    X           X                 X                 X                   X          X               X                     X              X            X                 X                      X

  **SCAP.R.5**    X           X                                                                  X                                     ** **          ** **                                                  

  **SCAP.R.6**                X                                                                  X               X                     ** **          ** **                                                  

  **SCAP.R.7**    X           X                                                                                  X                     ** **          ** **                                                  

  **SCAP.R.8**    X           X                                                                  X                                     ** **          ** **                                                  

  **SCAP.R.9**    X                             X                 X                   X          X                                                                 X                                        X

  **SCAP.R.10**   X           X                 X                                                X                                                                                                           
  ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

[^1]: Internet Engineering Task Force (IETF) Request for Comment (RFC)
    2119, Key words for use in RFCs to Indicate Requirement Levels. S.
    Bradner. March 1997. (Status: BEST CURRENT PRACT

[^2]: This requirement can be met be providing a URL to the NVD CVE or
    MITRE CVE vulnerability summaries

[^3]: The official CVE description and references are found at:
    http://nvd.nist.gov

[^4]: The official CCE descriptions are found at:
    http://cce.mitre.org/lists/cce_list.html

[^5]: The requirements for CVSS vectors are available from NIST IR 7435
    section 2.4.

[^6]: This could be achieved through a wide variety of mechanisms
    including user importation of temporal data, access to subscription
    services, and/or linkage to a CVSS calculator.

[^7]: This can be achieved by a product hyperlinking from the product's
    CVSS score to the NVD CVSS calculator reference implementation.
    Instructions for how vendors can do this are available at
    <http://nvd.nist.gov/cvss.cfm>

[^8]: This could be achieved through a wide variety of mechanisms
    including user importation of temporal data, access to subscription
    services, and linkage to a CVSS calculator.

[^9]: It is possible for a vendor to automatically collect the
    environmental metrics from the network, configuration database,
    system inventory, or some other source such that the user does not
    have to manually customize the scores. This is actually the
    preferred implementation approach

[^10]: This can be achieved by a product hyperlinking from the product's
    CVSS base score to the NVD CVSS calculator reference implementation.
    Instructions for how vendors can do this are available at
    <http://nvd.nist.gov/cvss.cfm>

[^11]: The required elements for environmental scoring are available
    from NIST IR 7435 section 2.3.

[^12]: For example, if the product is not dynamically reading
    information from the NVD CPE Dictionary, the product CPE Dictionary
    shall display when it was last imported into the tool