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

Statement of FDCC Compliance:
In order to perform audits of remote Windows XP Pro systems, the following settings need to be enabled in the local firewall. (Basically, we need to ensure that the system can function as being part of a Windows domain).

Choose the Start button, select "Run" and then enter "gpedit.msc". From this new GUI, choose "Computer Configuration", then "Administrative Templates", then "Network", then "Network Connections", then "Windows Firewall" and then finally "Domain Profile/Standard Profile".
Modify the following sections accordingly:
1. Enable "Windows Firewall: Allow File and Printer Sharing exception"
2. Enable "Windows Firewall: Allow Remote administration exception"
3. Disable "Windows Firewall: Do not allow exceptions"

Also keep in mind that audits need to be performed with the Administrator account and if it has been renamed, then this should be the account used to perform the audit. For Windows Vista, the following steps must be taken:

The first item to modify is in the firewall settings. The File and Printer sharing exception should be enabled. This will allow Nessus to connect to the Vista system over the network.
The second item is to enable the inbound file and printer exception via the gpedit.msc tool. This tool can be launched from the "Run.." prompt. To navigate to the setting which needs to be changed, follow Local Computer Policy -> Administrative Templates -> Network -> Network Connections - > Windows Firewall -> Standard Profile -> Windows Firewall : Allow inbound file and printer exception.
Third, when you are editing the firewall policy, make sure that the setting to prohibit use of the Internet Connection Firewall on your DNS domain network is also disabled. From within the gpedit.msc tool, you can navigate to this setting by following Local Computer Policy -> Administrative Templates -> Network -> Network Connections -> Prohibit use of Internet connection firewall on your DNS domain. This setting should either be "Disabled" or "Not Configured".
The last step is to modify Vista's UAC to allow Nessus to perform an audit. There are two choices here. You can simply disable UAC 100%, or you can modify a registry setting to allow Nessus audits.

To turn off UAC completely, open up the Control Panel, select "User Accounts" and then "Turn User Account Control" to off.
Alternatively, you can add a new registry key named "LocalAccountTokenFilterPolicy" and set its value to "1". This key should be created in the registry at the following location:

Statement of SCAP Implementation:
The Security Center has the ability to import SCAP content. SCAP comprises multiple standards including OVAL, CVE, CVSS, XCCDF, CPE and CCE, all of which were previously documented in this appendix.

Security Center supports SCAP by integrating each aspect of the OVAL, CVE, CVSS, XCCDF, CPE and CCE such that an enterprise can accurately test their infrastructure to see that it is configured with the correct settings.

OVAL, CCE, CPE and XCCDF define which policies, configuration settings and how to perform tests for those configuration settings.

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

The Security Center can be used to report and analyze many different types of configuration and vulnerability data for large and small enterprises. The Security Center also manages re-scanning of systems (also known as remediation scanning) such that a system can quickly be shown to be in compliance if a deviation was reported.

In addition, the Security Center can also manage the Log Correlation Engine and Passive Vulnerability Scanner. Each of these products can be used to monitor logs and network traffic to look for evidence that a system has undergone some sort of change which may place it into a non-compliant state. It may also indicate that new hosts not currently being audited have been connected to the network.

Statement of CVE Implementation:
Tenable Network Security uses Common Vulnerability Enumeration nomenclature for many different processes accomplished by the Security Center.

All vulnerabilities identified by Tenable's research group for the Nessus vulnerability scanner or the Passive Vulnerability Scanner have relevant CVE entries.

At Nessus.org, Tenable publishes our total count of covered CVE entries as well as a public web interface that can be used to search CVE entries.

Within the Security Center, for any vulnerability displayed in "full detail" mode, all relevant CVE links are listed and the user can click on them to have direct information displayed in the web browser from the online CVE content. This data is also displayed in the reporting and exporting via CSV content.

Within the Security Center, the text of any CVE value can be used as a search. For example, one could enter in "CVE-2002" and would be presented with all matching vulnerabilities which had a CVE entry from the year 2002. Specific CVE entries can be used as well.

When browsing vulnerability descriptions within the Security Center, CVE entries are also indicated.

For vulnerability to IDS event correlation, the Security Center employs CVE as one of the correlation matrices, such that an IDS event from a non-Tenable vendor could be correlated with all discovered vulnerabilities that have the same CVE entry.

Statement of CCE Implementation:
Tenable support for CCE data starts directly with the XCCDF content. In order to parse the XCCDF content directly, Tenable employs a utility with can read the XML content and generate a Nessus audit policy.

Part of this process allows a user to select how they want the audits performed by Nessus to be named or have descriptions associated with the audit. By default, all CCE entries are used to name each audit such as "CCE-871:MaximumPasswordAge". Optionally, CCE content, as well as any other description information can be included in the audit policy. Some customers choose not to do this and simply report compliance or non-compliance with a specific CCE entry. Other customers wish to leave all reference information in the vulnerability report.

As Nessus completes its configuration audit, the text produced is consumed by Security Center as any other type of vulnerability or configuration audit. Once in Security Center, users can search the obtained data by CCE is they desire through the "text search" field.

Statement of CPE Implementation:
Tenable Network Security uses Common Platform Enumeration to ensure that configuration audits are performed on the correct operating systems. While processing XCCDF content, relevant CPE check for the audit policy is 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 useful user error will occur.

Within the Security Center, this also accounts for an inadvertent scan of a system with the wrong policy. Although the Security Center has "asset logic" that can be used to ensure that XP Pro audits are run on XP Pro servers, but it is very plausible to envision a customer simply auditing a network range that contains Windows XP Pro, Windows 2003 and Windows Vista servers. 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. The actual CVSS scoring strings and scores are used to map severity ratings of the vulnerabilities audited by Nessus and the Passive Vulnerability Scanner.

When a test for a new vulnerability is produced by Tenable, often there will not be a corresponding NVD entry for it yet. Tenable performs our own scoring along NIST guidelines. When an NVD entry and CVSS score is available, Tenable synchronizes with the NVD. If there is a discrepancy with 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".

Copyright 2004-2009, Tenable Network Security, Inc. Proprietary Information of Tenable Network Security, Inc. 3

In some cases, though, we are unable to sync scores with the 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 "approximated" scores). In these cases, Tenable will re-score the plugins using the v2 standard as time permits.

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

In order to make use of this content, a Security Center administrator would download the XCCDF content from their vendor and then load it into a Tenable utility named the xTool. Within this tool, a customer can configure which XCCDF policy they wish to generate an audit for, how much detail for each audit should be included, how the name of the audit (such as putting CCE entries in the name or just as a reference) should be represented, and several other parameters. The xTool implements OVAL directly such that the audit policy for Nessus is based directly on the types of checks described by OVAL. The Security Center administrator would then load the desired XCCDF audit polices into the Security Center and attach them into a scan policy.

Statement of OVAL Implementation:
Tenable has implemented the OVAL standard within the xTool. 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 such as simple registry checks to the more complex logic checks requiring multiple if/then decision trees.

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

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

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

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