Direct Feed and Security Center customers who use Nessus to perform configuration audits of their Windows computers can now beta test an upgrade of this technology. The upgrade provides enhanced auditing features, increased speed and is Tenable's foundation for compliance with NIST SCAP auditing requirements when auditing Microsoft platforms. This blog entry discusses the new features of the upcoming release, the release schedule for this update, how customers can participate in the beta test today.

Scope and Release Schedule

Plugin #21156 (named the compliance_check.nbin plugin) is used by Nessus Direct Feed and Security Center customers to audit the configuration of Windows systems. Version 1 of this plugin has been available for over a year. Version 2 adds many new features and is available immediately for beta testing.

Current Direct Feed or Security Center users are not required to take any action right now, however, on January 15th, 2008, version 2 of the compliance_check.nbin will be released for Direct Feed and Security Center customers. This will automatically upgrade the compliance_check.nbin plugin to version 2. At that time, any existing version 1 audit policy files will need to be replaced with version 2 audit policy files. Tenable made every effort to maintain backwards compatibility, however, to achieve 100% compliance with content generated from NIST SCAP XCCDF policies, several new functions were required.

All existing Windows configuration audit polices will be re-released with support for version 2. These include a variety of PCI, NIST SCAP and CIS polices. At the Tenable Customer Support Portal, all Windows policies are now available under both version 1 and version 2. Version 1 policies should continue to be used in production, and the version 2 policies are available for beta testing. All version 2 polices have a _v2 extension on them along with the same root name as before. 

New Audit Features in Version 2

New check_type header

All version 2 Windows audit policies now contain the following header information:

<check_type:"Windows" version:"2">

Previously, version 1 policies started out with:

<check_type:"Windows">

If you have written a custom audit policy, in order to run it under the new beta plugin, the 'check_type' value will need to specify version 2 as shown above.

As part of this beta, a new version of the i2a tool (version 2.0.0) is also available from the customer support portal. It generates version 2 compliant audit policies based on existing Windows GPO .inf files.

Clearer logic symbols

Previously in version 1 of the compliance checks, the pipe symbol "|", was used to delineate lists of potential values. In some checks, this symbol functioned like an AND and in others, an OR. In version 2.0, checks make use of the following conditional functions:

•   && - conditional AND
•   || - conditional OR
•   |  - Binary OR

A binary 'OR' is used for comparing windows access control lists.

If you have written custom policies using the POLICY_MULTI_TEXT or USER_RIGHTS_POLICY audits, under version 2, they should make use of the "double and" separator instead of the single pipe separator. In other words, replace all of your '|' characters for POLICY_MULTI_TEXT or USER_RIGHTS_POLICY audits with '&&'.

For example, here is a version 2 and version 1 audit section which looks for a combination of values for a particular registry setting:

version 2 format:

<custom_item>
type: REGISTRY_SETTING
description: "HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\NullSessionPipes"
value_type: POLICY_MULTI_TEXT
value_data: "COMNAP"&&"COMNODE"&&"SQL\QUERY"&&"SPOOLSS"&&"LLSRPC"&&"browser"
reg_key: "HKLM\System\CurrentControlSet\Services\LanManServer\Parameters"
reg_item: "NullSessionPipes"
</item>

version 1 format:

<custom_item>
type: REGISTRY_SETTING
description: "HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\NullSessionPipes"
value_type: POLICY_MULTI_TEXT
value_data: "COMNAP" | "COMNODE" | "SQL\QUERY" | "SPOOLSS"|"LLSRPC"|"browser"
reg_key: "HKLM\System\CurrentControlSet\Services\LanManServer\Parameters"
reg_item: "NullSessionPipes"
</item>

Forced Reporting

Audit polices can now be forced to output a specific result by making use of the 'report' keyword. Report types of PASSED, FAILED and WARNING can be used. Below is an example policy:

<report type: "WARNING">
description: "Audit 103-a requires a physical inspection of the pod bay doors Hal"
</report>

The text inside the 'description' would always be displayed in the report.

This type of reporting is useful if you wish to inform an auditor that an actual check being performed by Nessus can't be accomplished. For example, perhaps there is a requirement to determine that a specific system has been physically secured and we wish to inform the auditor to perform the check or inspection manually. This type of report is also useful if the specific type of audit required to be performed by Nessus has not been determined with an OVAL check.

"if, then and else" Logic

A powerful new feature of the version 2 compliance checks for Windows is the ability to have conditional tests based on existing conditions. The logic implements OR and AND logic and has the following type of structure:

<if>
  <condition type:"and/or">
      < Insert your audit here >
  </condition>
<then>
     < Insert your audit here >
</then>
<else>
     < Insert your audit here >
</else>
</if>

Below is an example that audits the password policy. Since the 'and' type is used, for this policy to pass the audit, both custom items would need to pass. This example tests for a very odd combination of valid password history policies to illustrate how sophisticated test logic can be implemented.

<if>
   <condition type:"and">

     <custom_item>
       type: PASSWORD_POLICY
       description: "2.2.2.5 Password History: 24 passwords remembered"
       value_type: POLICY_DWORD
       value_data: [22..MAX] || 20
       password_policy: ENFORCE_PASSWORD_HISTORY
     </item>

     <custom_item>
       type: PASSWORD_POLICY
       description: "2.2.2.5 Password History: 24 passwords remembered"
       value_type: POLICY_DWORD
       value_data: 18 || [4..24]
       password_policy: ENFORCE_PASSWORD_HISTORY
     </item>

   </condition>

   <then>

     <report type:"PASSED">
       description: "Password policy passed"
     </report>

   </then>

   <else>

     <report type:"FAILED">
       description: "Password policy failed"
     </report>

   </else>

</if>

The if/then/else logic is extremely powerful. In the above example, only the new 'report' type was shown, but the if/then/else structure supports performing additional audits within the 'else' clauses. Within a condition, nested if/then/else clauses can also be used. A more complex example is shown below:

<if>
<condition type:"and">
<custom_item>
    type: CHECK_ACCOUNT
    description: "Accounts: Rename Administrator account"
    value_type: POLICY_TEXT
    value_data: "Administrator"
    account_type: ADMINISTRATOR_ACCOUNT
    check_type: CHECK_NOT_EQUAL
</item>
</condition>

<then>
<report type:"PASSED">
   description: "Administrator account policy passed"
</report>
</then>

<else>

<if>
<condition type:"or">
<item>
   name: "Minimum password age"
   value: [1..30]
</item>
<custom_item>
   type: PASSWORD_POLICY
   description: "Password Policy setting"
   value_type: POLICY_DWORD
   value_data: 1
   password_policy: COMPLEXITY_REQUIREMENTS
</custom_item>
</condition>
<then>
<report type:"PASSED">
   description: "Administrator account policy passed"
</report>
</then>
<else>
<report type:"FAILED">
   description: "Administrator account policy failed"
</report>
</else>
</if>

</else>
</if>

This example implements the logic, if the Administrator account has not been renamed, then audit that the minimum password age is 30 or less. This audit policy would pass if the administrator account has been renamed regardless of the password policy and would only test the password age policy if the administrator account hadn't been renamed.

'info' field for each check

A new function that can be used to label each audit field with one or more external references is also available. For example, this field will be used to place references from NIST CCE tags as well as CIS specific audit requirements. These external references are printed out in the final audit performed by Nessus and will be displayed in the Nessus report, or through the Security Center's user interface.

The field is named 'info'. Below is an example password audit policy that has been augmented to list references to a fictitious corporate policy:

     <custom_item>
       type: PASSWORD_POLICY
       description: "Password History: 24 passwords remembered"
       value_type: POLICY_DWORD
       value_data: [22..MAX] || 20
       password_policy: ENFORCE_PASSWORD_HISTORY
       info: "Corporate Policy 102-A"
     </item>

If multiple policy references are required for a single audit, the string specified by the 'info' keyword can make use of the '\n' separator to specify multiple strings. For example, consider the following audit:

<custom_item>
type: CHECK_ACCOUNT
description: "Accounts: Rename Administrator account"
value_type: POLICY_TEXT
value_data: "Administrator"
account_type: ADMINISTRATOR_ACCOUNT
check_type: CHECK_NOT_EQUAL
info: 'Ron Gula Mambo Number 5\nCCE-60\nTenable Best Practices Policy 1005-a'
</item>

When run with the nasl command line tool, this audit function produces the following output:

[root@kingghidora ~]# /opt/nessus/bin/nasl -t 192.168.20.16 ./compliance_check.nbin

            Windows Compliance Checks, version 2.0.0(Beta2)

Which file contains your security policy : ./test_v2.audit
SMB login : Administrator
SMB password :
SMB domain (optional) :
"Accounts: Rename Administrator account": [FAILED]

Ron Gula Mambo Number 5
CCE-60
Tenable Best Practices Policy 1005-a

Remote value: "Administrator"
Policy value: "administrator"

'check_type' option

Audit functions can now make use of a field named 'check_type' which implements a variety of flexible logic to test the results of an audit. Below is an example audit to check to make sure that the account name "Guest" does not exist for any Guest account.

<custom_item>
  type: CHECK_ACCOUNT
  description: "Accounts: Rename guest account"
  value_type: POLICY_TEXT
  value_data: "Guest"
  account_type: GUEST_ACCOUNT
  check_type: CHECK_NOT_EQUAL
</item>

If any other value besides "Guest" is present, the test will pass. If "Guest" is found, the audit will fail.

The 'check_type' option can accept the following values which implements the following types of logic:

• CHECK_EQUAL compare the remote value against the policy value (default if check_type is missing)
• CHECK_EQUAL_ANY checks that each element of 'value_data' is at least present once in the system list.
• CHECK_NOT_EQUAL checks the remote value is different than the policy value
• CHECK_GREATER_THAN checks the remote value is greater than the policy value
• CHECK_GREATER_THAN_OR_EQUAL checks the remote value is greater or equal than the policy value
• CHECK_LESS_THAN checks the remote value is less than the policy value
• CHECK_LESS_THAN_OR_EQUAL checks the remote value is less or equal than the policy value
• CHECK_REGEX checks that the remote value match the regular expression in the policy value (only works with POLICY_TEXT and POLICY_MULTI_TEXT)
• CHECK_SUBSET checks that the remote access control list (ACL) is a subset of the policy ACL. (This check only works with ACLs)

The following custom item checks that 'lsarpc' is in the 'NullSessionPipes' list.

<custom_item>
description: "CHECK_EQUAL_ANY"
type: REGISTRY_SETTING
value_type: POLICY_MULTI_TEXT
value_data: 'lsarpc'
reg_key: "HKLM\System\CurrentControlSet\Services\LanManServer\Parameters"
reg_item: "NullSessionPipes"
check_type: CHECK_EQUAL_ANY
</item>

The following custom item checks that 'lsarpc' and 'browser' are in the 'NullSessionPipes' list.

<custom_item>
description: "CHECK_EQUAL_ANY"
type: REGISTRY_SETTING
value_type: POLICY_MULTI_TEXT
value_data: 'lsarpc' && 'browser'
reg_key: "HKLM\System\CurrentControlSet\Services\LanManServer\Parameters"
reg_item: "NullSessionPipes"
check_type: CHECK_EQUAL_ANY
</item>

Support for Signed, Unsigned and Hexadecimal Numbers

Numbers can now be specified with plus or minus to indicated their 'sign'. Number can also be specified as hexadecimal values. Hex and signs can be combined. The following are valid examples (without the corresponding label in parentheses) within a REGISTRY_SETTING audit for a POLICY_DWORD:

value_data: -1  (signed)
value_data: +10  (signed)
value_data: 10 (unsigned)
value_data: 2401649476 (unsigned)
value_data: [MIN..+10]  (signed range)
value_data: [20..MAX] (unsigned range)
value_data: 0x800010AB (unsigned hex)
value_data: -0x10 (signed hex)

Value data can also make use of parentheses to specify ranges of valid data values. For example, the example below  would accept valid data in non-discrete ranges:

value_data: ( ([20..MAX] || 18) && (32 || 18) )

Minor Features and Differences

The following is a list of other features and differences between version 1 and version 2:

• Performance Increase on Low Latency Networks - The new logic implemented in this update is more efficient. In some lower latency networks, a speed increase of more than two times has been observed.
• Strings can be specified with single or double quotes - Escaped characters such as \n, \r, \\, \', \t, \", ... are only evaluated in strings specified with single quotes.
• USER_RIGHTS_POLICY is now case sensitive - In all of the new version 2 audit policies, the USER_RIGHTS_POLICY has been updated to the correct string and case. For example, previously, many polices included a test for "setcbprivilege" and now with version 2, the string SeTcbPrivilege is used without any quotes.
• REGISTRY_SETTING 'reg_type' field - This field is now automatically converted to the given 'value_type' policy of the audit.

Obtaining and Testing the new compliance_check.nbin beta Plugin

To obtain the new compliance_check.nbin file, log into the Tenable Customer Support Portal, click on the 'Downloads' button, and then click on the 'Download Compliance Checks Tools' button. On this page is a link for the beta of the new plugin as well as version 2.0.0 of the i2a tool.

On UNIX systems, you can download the plugin to someplace other than the Nessus plugins directory and use the nasl command line tool to test it out. If you are not familiar with the nasl command line tool, we've blogged about its usage previously before, including an example of how to perform tests with Direct Feed auditing files.

Here is an example running the new plugin with an older, incompatible version 1 policy.

[root@kingghidora ~]# /opt/nessus/bin/nasl -t 192.168.20.16 ./compliance_check.nbin

            Windows Compliance Checks, version 2.0.0(Beta1)

Which file contains your security policy : ./FDCC_Desktops_v90.audit
SMB login : Administrator
SMB password :
SMB domain (optional) :
Parse error line 99 - unknown token 'setcbprivilege'

This older audit file failed because previously, the USER_RIGHTS_POLICY was case insensitive. In version 2, the case is important. The older version 1 policy had a line which tested the string "setcbprivilege' whereas in version 2, the more specific 'SeTcbPrivilege' has been specified.

Here is a second, truncated example running version 2 of the same policy:

[root@kingghidora ~]# /opt/nessus/bin/nasl -t 192.168.20.16 ./compliance_check.nbin

            Windows Compliance Checks, version 2.0.0(Beta1)

Which file contains your security policy : FDCC_Desktops_v90_v2.audit
SMB login : Administrator
SMB password :
SMB domain (optional) :
"Minimum password age": [FAILED]

Remote value: 0
Policy value: [1..MAX]

Testing with Nessus Direct Feed Scanners

If you would like to replace your compliance_check.nbin in your Nessus plugins directory, you can make use of the new beta directly from Nessus. Simply move the current compliance_check.nbin file to a safe place to be able to revert to it, and replace it with the new compliance_check.nbin file. Any scan policies you test with should be performed with version 2 polices.

If your Nessus scanner is set to update plugins, keep in mind that the compliance_check.nbin file will be overwritten with the older version 1 plugin. Once the new plugin is in place, on Windows systems, the plugins should be rebuilt by running the build.exe command. On UNIX systems, a Nessus service restart will work, or it can be forced from the command line with the command:

/opt/nessus/sbin/nessusd -t -D

Testing with the Security Center

If you place the compliance_check.nbin file in your /opt/sc3/admin/nasl directory, the Security Center will push this plugin out to all of your managed Nessus scanners within the next hour. If you are impatient, you can force this by placing the plugin and then restarting the Security Center.

From within the Security Center, you should place any desired version 2 test polices also in the /opt/sc3/admin/nasl directory and then perform your testing.

Keep in mind that if the Security Center performs a plugin update during its nightly process, it will obtain the older version 1 of this plugin and will overwrite it on each of your managed Nessus scanners.

Providing Feedback

We appreciate any positive or negative feedback, as well as bug reports. Tenable customers should send email to support@tenablesecurity.com or open up a ticket through the support portal if any issues have been found.

Any updates to the available beta will be posted on the support portal, as well as the Nessus Compliance RSS feed.

I often get the chance to speak with our Security Center customers who perform active Nessus scans or monitor networks in realtime with the Passive Vulnerabiltiy Scanner (PVS). These customers generally have more than 5 Nessus scanners, 2-3 PVS sensors and need to watch and report on more than 5000 active hosts.

For many of them, deploying Security Center is the first time they've been really able to unify patch/config auditing, active scanning and network monitoring and have this information shared securely across multiple departments.

A common question I get asked is how to make sense of all the data collected. This blog entry considers several different strategies and ideas that use "asset lists" to make sense out of the various technologies, applications and configurations that can occur on an enterprise network.

Dividing the Network into Asset Groups

I've blogged before about how the Security Center can use asset lists to split a network up into "things you know" and "things" that can be discovered independently of any corporate knowledge. Each asset list is simply a list of IP addresses that all have the same sort of property.

For example, if one were to ask an enterprise networking group for a list of all "Cisco router" IP addresses, this list could be loaded into the Security Center and used to report, filter and analyze all vulnerabilities, as well as logs and IDS events if the Log Correlation Engine were in use, just on the "Cisco Routers". At the same time, the Security Center could also use something we call a dynamic asset list that can rely on the operating system fingerprinting (or any other plugin) of Nessus and the PVS to come up with its own list.

What gets interesting is when the "official" list of what constitutes a corporate asset differs from what has been actively or passively derived by the Security Center. These discrepancies usually indicate a failing or lack of a process to disseminate information accurately to security, audit or other types of groups. Many of our customers have also said they've been able to rectify issues or gaps in the accuracy of their corporate asset management systems by comparing their lists to the lists and data within the Security Center.

Standard Dynamic Asset Lists

Dividing your network up into different types of asset classes can map into normal technologies you and your organization are already familiar with. The following is a very easy list of default items and methods to help classify your network:

• DNS and Netbios names can be used to classify hosts. If an organization has a naming convention (my Tenable laptop is named LAP5506 -- guess what the 'LAP' means?) then dynamic asset lists can be used to generate on-the-fly lists based on naming conventions already used in the organization.
• Operating System classification can automatically label various systems in different networks. For example, combining the output of the Nessus OS ID plugin and a domain name filter could result in list of all Windows XP servers in a specific domain.
• If the Passive Vulnerability Scanner is involved, a tremendous amount of client side application and network browsing behaviors can be used to classify hosts. For example, the PVS can list all systems which make outbound connections on port 143. This is a quick way to identify all systems that receive email through IMAP.
• Nessus scanners can differentiate between live hosts and systems running in a VMWare environment. This can allow for a quick and easy way to identify which of your systems are "real" or "virtual".
• Nessus 3 can also make a variety of Windows WMI queries. The data contained on a Windows server available through WMI is richer than what can be queried for in just the registry. These include CPU type, manufacture and hardware type. All of this information is available to help classify your environment. WMI can be used to different not only different types of manufactures such as Dell and Sony, but to also differentiate different types of platforms within a manufacturer.

This list is just a portion of the types of classifications that can be performed with the Security Center and the data obtained about your network with Nessus and the PVS.

Advanced and Innovative Ideas for Classification

Over the past few years I've picked up a few tricks from customers for helping to classify systems and identify devices that have been installed that should cause alarm.

One of the easiest things to do is search for systems that aren't in the DNS system. Nessus plugin #12053 attempts to perform a DNS lookup of each active IP address that is scanned. If you are on a large network, finding systems that are alive, but are not in DNS is a great way to find test networks, non-production systems, networks and hosts that have been "forgotten" and so on.

Another interesting form of classification is to look for systems that don't have a valid OS fingerprint. Nessus uses a wide variety of techniques to accurately identify the operating system of a host. If this process does not result in a guess of the target OS, this could indicate that a host has some sort of firewall or IPS blocking the scan. If this is the case, then this asset might be more important to the organization and should be further analyzed. Some of our customers who also deploy the PVS have taken this concept a step further and have deployed rules to list systems that don't have an active fingerprint, a passive OS fingerprint or are missing both.

Creating assets based on combinations of open ports and browsed ports can also indicate how a system is used. Creating a rule which combines Nessus and PVS plugin '0' (an open port) with PVS's client side port browsing rule can identify a wide variety of systems. For example, if all we know about a host is that it browses on ports 53, 80 and 443 it is likely just performing web browsing. If a system had port 80 open (such as a web server) and also browsed on port 80, this could indicate that a production web server is reaching out to the Internet for update and is not being centrally managed.

Mapping Assets to Corporate Policy

An important item I tell our customers to keep in mind is to map their asset classification efforts into corporate policy. With more than 20,000 active and passive plugins to draw data from for classifying a host, there is ample opportunity to over-classify assets based on today's security headlines or the technical whims of the audit or security staff.

For example, due to PCI, it might be a corporate practice to alert on any system with a vulnerability older than 30 days. With the Security Center, it is fairly trivial to classify and report on any host that has a vulnerabilities older than 30 days. It is much more useful to consider the overall state of a host and how it impacts a standard such as PCI.

For More Information

If this blog entry was useful to you, the following previous entries will also likely be of interest:

• Using Manufacturer Information for Automatic Dynamic Asset List Creation
• Testing The Effectiveness of your Patch Management System
• Knowing When To Patch
• Advanced Dynamic Asset Rules
• Enumerating Corporate Data

To learn more about Tenable's Unified Security Monitoring strategy, please visit us on the web site, contact us or check out one of the online videos of our product offerings.

Tenable has produced a variety of report templates and scanning polices for both the NessusClient 3.0 and the Security Center. This blog entry discusses coverage of the SANS Top 20 2007 Annual Update in Nessus as well as the Passive Vulnerability Scanner and instructs users how to obtain and use these policies.

SANS 2007 Annual Update

As with previous annual updates, the SANS 2007 update classifies vulnerabilities into several categories including "client-side", "server-side" and "zero day attacks". CVE numbers were used in each of the sections to map to the relevant Nessus and PVS plugin IDs.

Several sections did not identify specific CVE entries, but did identify general guidelines for security and auditing your systems. For each session, Tenable suggests the following solutions:

H1 - Excessive User Rights and Unauthorized Devices

With Nessus credentialed checks, a wide variety of configuration auditing polices can be used by Direct Feed and Security Center users to  audit Windows and Unix systems. Many of the policies available have been generated from a variety of "best practices" guidelines including NIST SCAP content and the Center for Internet Security.

To detect unauthorized devices, a variety of methods can be used. The simplest is to scan with Nessus and see what is on your network. In larger enterprise networks, analyzing raw scan results is cumbersome. Continuous network monitoring with the Passive Vulnerability Scanner as well as automatic classification of systems into one or more asset categories by the Security Center is recommended.

H2 - Phishing/Spear Phishing

The Passive Vulnerability Scanner can tell you which hosts on your network connect to the Internet and the Log Correlation Engine can perform a variety of black list analysis to see if your users are connecting to potentially hostile sites.

The intent of this section is to prevent and educate your users from being "socialed" but an interesting feature of the Passive Vulnerability Scanner is its ability to recognize when a web page claiming to be from a bank or credit union appears on your local network.

H3 - Unencrypted Laptops and Removable Devices

Although Nessus does not test for "encryption", it can test for the presence of specific encryption software and to also test if the software is installed and configured correctly. End users would need to develop a Nessus configuration audit policy that identifies if the corporate standard for encryption is installed and configured to policy.

Nessus credential checks can also itemize all USB devices that have been attached to an audited Windows computer. The Security Center can use the output of this audit to classify systems based on the type of detected USB device.

A2 - Peer-to-Peer Programs

The 2007 update did not specify any particular vulnerabilities in any particular P2P applications. I feel this is an oversight, as there have been many severe vulnerabilities in a variety of P2P applications. From a corporate point of view though, the simple presence of a P2P application may have a variety of issues other than security such as the potential sharing or corporate data or the act of obtaining copy written material.

Both Nessus and the Passive Vulnerability Scanner have entire families of plugins dedicated to the detection of P2P applications and identifying any known security issues with them.

Passive Vulnerability Scanner Coverage

The PVS is able to detect relevant SANS 2007 Top 20 vulnerabilities in many of the different sections, especially the client-side vulnerabilities.

Overall, there were more than 60 unique PVS plugins which were directly attributable to the SANS Top 20 2007 audit. There are many more generic plugins (such as simply identifying older browsers or the presence of a certain type of network applications) that also help an organization to removing or mitigating harmful applications.

The relevant plugin IDs for the PVS are enabled in the SANS 2007 report for the Security Center two sections below.

NessusClient 3.0 Scanning Policy

Below are .gz and .zip files which can be used by the NessusClient 3.0.

Download SANS-2007.nessus.gz

Download SANS-2007.zip

The scan policy only enables the relevant Nessus plugins for the SANS 2007 list of identified CVE entries. The policy also includes individual scan policies for each section (such as C1, C2, S3, and so on) such that a quick scan of just that specific section can be performed.

To use this policy, download the .gz or .zip file to your system and uncompress it. Then, after launching the NessusClient, choose 'File', then 'Open' and select the SANS-2007.nessus policy. After loading, your NessusClient should look something like this screen shot below:

The policy does not include the required credentials to perform patch audits. Once you have loaded the SANS 2007 policy, if you wish to perform a patch audit, you should add in the Unix or Windows administrator credentials of the system(s) you wish to audit. If you are auditing multiple sites with different credentials, you should add in your scan targets and save the entire configuration as a new scan policy.

Security Center Reporting Templates and Scanning Polices

The following two downloads enable the Security Center to perform SANS 2007 Top 20 scans as well as generate relevant SANS 2007 Top 20 reports from existing Nessus and PVS scanning data.

Download sans-2007-sc3-scanpolicy.tar.gz

Download sans-2007-sc3-reportpolicy.tar.gz

To install these two files, perform the following steps:

1. Download both files to your Security Center in a temporary location
2. unzip and untar the sans-2007-sc3-reportpolicy.tar.gz file
3. chown each of the .xml files to user 'tns'
4. move all of the .xml files to the /opt/sc3/admin/report_templates directory
5. unzip and untar the sans-2007-sc3-scanpolicy.tar.gz file
6. chown each of the files new files to user 'tns'
7. move these files to /opt/sc3/admin/vpolicy
8. edit the /opt/sc3/admin/vpolicy/vpolicy.txt file and add the value "0033" to the list on the line before the "***END" designator.

Once these files are installed, the are immediately available for use within the Security Center.

If you have existing data from Nessus scans or the Passive Vulnerability Scanner, you can create or schedule a SANS 2007 Top 20 report by choosing one of the new report templates. There are three new templates which summarize vulnerabilities, summarize the effected network and assets and also provide full detail of the vulnerabilities in question.

Also, immediately from within the screens for browsing and analyzing vulnerability and configuration data, if the SANS 2007 policy is chosen, only the vulnerabilities relevant to that policy will be displayed.

To schedule a new scan for just SANS 2007 issues, Security Center users can choose the new policy and launch a scan. As with the NessusClient, if credentials are in question to perform host-based audits, the SANS 2007 scan policy should be cloned and in the new policy, have its credentials specified. If a network asset with known credentials is scanned, the Security Center will automatically use those as well.

For More Information

Nessus is available to end users as a complimentary download. Tenable offers a variety of commercial and no-charge methods to update Nessus to check for recent vulnerabilities. For more information, please visit http://www.nessus.org.

The Security Center, Passive Vulnerability Scanner and the Log Correlation Engine are all commercial products offered by Tenable Network Security. For 500 servers, the Security Center costs less than most commercial vulnerability scanner licenses, yet has the power of and functionality of leading SIM and vulnerability management solutions. For more information on these products, please read about them online or email our sales staff.

Tenable's research group has released several hundred new plugins for Nessus in the last few days. One of them in particular is very useful for Solaris environments.

Plugin #29217 enumerates all installed software packages on Solaris operating systems. It leverages SSH credentialed scanning to obtain these results.

This plugin joins similar plugins for Windows and Unix that leverage a variety of credential types, even including software enumeration via SNMP for Windows if you have such a network.

Previously we have blogged about how enterprise software discovery can be performed with Nessus network scans, credentials scans and continuous passive network analysis with the Passive Vulnerability Scanner.

A key point of these blogs is to be able to use products like the Security Center to automatically classify your systems into unique asset groups based on the software installed on them. For example, the Security Center can use the output from this Solaris plugin to classify Solaris systems that do or don't have a certain Tivoli agent installed on them. This allows complex enterprise networks to be simplified so the process of patch auditing, configuration auditing and event/log analysis can be performed much easier.

Plugin #29217 is currently available to Nessus Direct Feed and Security Center users.