Vendor Provided Validation Details - Tenable Security Center 4.0
The following text was provided by the vendor during testing to describe how the product implements the specific capabilities

Statement of SCAP Implementation:

SecurityCenter and Nessus component have the ability to import SCAP content. SCAP comprises multiple standards including OVAL, CVE, CVSS, XCCDF, CPE and CCE, as previously described in this document.

SecurityCenter and Nessus component support SCAP by integrating each aspect of the OVAL, CVE, CVSS, XCCDF, CPE and CCE to help organizations accurately test their infrastructure and ensure that it is configured with the correct settings.

OVAL, CCE, CPE and XCCDF define policies, configuration settings and testing methodology for these configuration settings.

Tenable customers use xTool, which is compatible with these standards, to produce audit policies for the Nessus vulnerability scanner. These audit policies are used by SecurityCenter to perform configuration audits of target systems and then report and analyze them.

SecurityCenter can be used to report and analyze many different types of configuration and vulnerability data for large and small enterprises. SecurityCenter also manages re-scanning of systems (also known as remediation scanning) to verify compliance.

In addition, SecurityCenter can also manage the Passive Vulnerability Scanner and multiple Log Correlation Engines. Each of these products can be used to monitor logs and network traffic for evidence that an asset has undergone a change that may indicate a non-compliant state. These checks may also indicate that new hosts have been connected to the network and may require auditing.

Statement of CVE Implementation:
Tenable Network Security uses Common Vulnerability Enumeration (CVE) nomenclature for many different processes accomplished by the SecurityCenter, including the following:

All vulnerabilities identified by Tenable¡¯s research group for the Nessus vulnerability scanner or the Passive Vulnerability Scanner have relevant CVE entries (if available).

Tenable publishes the total count of covered CVE entries online (Twitter) and also has a public web interface that can be used to search plugins by associated CVE entries. Newly released CVE entries are added several times a week and updates to older CVE entries are frequently made.

Any vulnerability displayed in the ¡°Detailed Vulnerability List¡± mode in SecurityCenter lists all relevant CVE references. This data is also displayed through reporting and exporting via CSV content.

The text of any CVE value can be used as a search parameter within the SecurityCenter filters. For example, if the text ¡°CVE-2002¡± is entered in the vulnerability text filter field, SecurityCenter will display all matching vulnerabilities that had a CVE entry from the year 2002. Specific CVE entries can be used in a search for more detailed results.

CVE entries are also displayed when vulnerability descriptions are browsed within the SecurityCenter,

Through the Log Correlation Engine, SecurityCenter employs CVE for vulnerability to IDS event correlation so that an IDS event from a third party product can be correlated with all discovered vulnerabilities that have the same CVE entry.

Statement of CCE Implementation:
The Tenable¡¯s support for CCE data starts directly with the Extensible Configuration Checklist Document Format (XCCDF) content. To parse the XCCDF content directly, Tenable employs a utility called the xTool that can read XML content and generate a Nessus audit policy based on XML content.

As an XCCDF library is parsed within the xTool, CCE IDs, their descriptions and their associated reference material can be displayed. This information can be included in the actual audit policies generated for Nessus.

Within SecurityCenter, CCE IDs can be viewed in ¡°Scan Results¡± and ¡°Detailed Vulnerability Text¡± after an audit has been completed. CCE ID descriptions, the policy value from the .audit file, and the remote value from a scanned host are also included under the Scan Results.

As Nessus completes its configuration audit, the text files produced are gathered by SecurityCenter. Once in SecurityCenter, users can search the obtained data by CCE through the ¡°Vulnerability Text¡± field.

Tenable¡¯s support for CCE data starts directly with Extensible Configuration Checklist Document Format (XCCDF) content. To parse the XCCDF content directly, Tenable employs a utility called the xTool that can read XML content and generate a Nessus audit policy.

As an XCCDF library is parsed within the xTool, CCE IDs, their descriptions and their associated reference material can be displayed. This information can be included in the actual audit policies generated for Nessus.

Within SecurityCenter, CCE IDs can be viewed after an audit has been completed.

As Nessus completes its configuration audit, the text files produced are gathered by SecurityCenter. Once in SecurityCenter, users can search the obtained data by CCE through the ¡°Vulnerability Text¡± field.

Statement of CPE Implementation:
Tenable Network Security uses Common Platform Enumeration (CPE) to ensure that configuration audits are performed on the correct operating systems. While processing XCCDF content, relevant CPE checks for the audit policy are built into the resulting Nessus audit policy. This ensures that if the wrong policy is used on an operating system not intended by the audit, a detailed error report will be produced.

Within SecurityCenter, an inadvertent scan of a system with the wrong policy can also be recognized and prevented. Although SecurityCenter has ¡°asset logic¡± that can be used to ensure that XP Pro audits are run on XP Pro computers, it is very plausible to envision a customer simply auditing a network range that contains Windows XP Pro, Windows 2003 and Windows Vista systems. In this case, for the incorrect CPE platforms, the audit will not be performed but the correct audits will still be automatically enabled.

Statement of CVSS Implementation:
Tenable¡¯s research group uses CVSS version 2 scores available from the National Vulnerability Database (NVD). The actual CVSS scoring strings and scores are used to map severity ratings of vulnerabilities audited by Nessus and the Passive Vulnerability Scanner.

When a test for a new vulnerability is produced by Tenable, there will often not be a corresponding NVD entry for it at the time of the original test. Tenable performs its own scoring according to NIST guidelines. When NVD entries or CVSS scores are available, Tenable synchronizes with NVD. If there is a discrepancy between what Tenable has scored and what NVD has scored, Tenable provides feedback to NIST.

Tenable Network Security uses the CVSS base score to select Nessus and PVS severity ratings for vulnerability plugins. Values from 1 through 3 receive a ¡°Low/Informational¡± rating, 4 through 6 receive a ¡°Medium/Warning¡± rating and 7 through 9 receive a ¡°High/Hole¡± severity level. CVSS scores of 10 have a severity level of ¡°High/Hole¡± but also have their risk factor marked as ¡°Critical¡±.

In some cases, Tenable is unable to synchronize scores with NVD. This may happen because a Nessus or PVS plugin checks for a vulnerability for which there is no CVE/NVD entry or because NIST has not scored the entry manually (NIST labels these as ¡°approximated¡± scores). In these cases, Tenable will re-score the plugins using the v2 standard when resources allow us to do so.

Statement of XCCDF Implementation:
Tenable Network Security makes use of XCCDF content to generate Nessus audit policies that can be used to audit the configuration of desktops, servers and laptops.

A SecurityCenter administrator can download the XCCDF content from a given source (such as NIST, a third party product or a Tenable product) and then load the policy into Tenable¡¯s xTool. Within this tool, an XCCDF policy can be configured to generate an audit, including the amount of detail for each audit, a naming standard for the audit (such as including the CCE entries in the description or just as a reference) and many other parameters. The xTool implements the Open Vulnerability Assessment Language (OVAL) directly so that the audit policy generated for Nessus is based directly on the types of checks described by OVAL. The SecurityCenter administrator can then load the desired XCCDF audit policies into SecurityCenter and attach them to a scan policy.

Statement of OVAL Implementation:

While processing XCCDF content, the entire body of OVAL checks is analyzed to produce a corresponding Nessus audit policy file. Nessus supports all of the various OVAL check types from simple registry checks to the more complex logic checks that require multiple if/then decision trees.

If the tests described in the OVAL content change, the corresponding Nessus audit content will change as well. If the OVAL content contains an error, the corresponding Nessus audit policies will contain the same error. In each of these cases, xTool uses the OVAL definitions to produce the specific Nessus audit content.

As NIST updates the OVAL content for various tests, xTool does not need to be updated as it natively interprets OVAL.

Nessus component performs the checks described by OVAL through several proprietary methods that leverage remote credentials of target Windows and Unix systems.

No agents are required on the target platform to perform any of the required audits described by OVAL.