A new configuration auditing policy designed to test IBM Systems against the iSeries Security Reference Version 5 Release 4 is now available on the Tenable Support Portal.

Users can log into the Tenable Support Portal to obtain this audit policy. The file is called "IBM v5 r4 iseries security reference" and is located in the "IBM iSeries Configuration Audits" section.

To use this audit policy, update the plugins and create a new policy to perform compliance checks against an AS400 system.

IT auditors, penetration testers, and incident responders often ask if a system they are analyzing is managed. A managed system is one that is being looked after, updated and maintained by an IT staff of some sort. An unmanaged system is one that is on the network, but perhaps has been forgotten, isn’t authorized or has some other reason for it not to be there or updated by anyone else.

Security findings for managed systems and unmanaged systems are reported differently. For an unmanaged system, the recommendation is to make the system managed and bring it into a secured state. For security issues with managed systems, the recommendation is to alter the current management processes to make them more secure.

Unfortunately, there is no “under management” test that can easily be automated. This blog entry will describe some of the different types of data that can be gathered from logs, Nessus scanning and Passive Vulnerability Scanner sniffing that can help identify systems with and without management.

Next up on our Nessus top ten list is #9, which covers how to use Nessus configuration auditing to discover information about your system configurations. The following video presents use cases and examples, from PCI compliance to detecting viruses:

Please visit Tenable's YouTube channel for more Nessus and SecurityCenter videos!

As a vendor, Tenable has to demonstrate compliance in many different types of categories. The Payment Card Industry, the Center for Internet Security and US government's FDCC program all have certification standards and procedures for vendors like Tenable. Since Tenable is certified in most of these these categories (we're in the process of becoming an ASV), I though it would be interesting for our blog readers to share some of our insights into the differences and misconceptions between them.

NSA Hardening Guidelines

The National Security Agency (NSA) has developed security hardening guidelines for various operating systems and technologies. I remember when I first started in information technology and used these guides to harden my Windows servers. I was met with mixed success; some systems would run better, and some would cease to function due to configuration changes. This taught me about my systems and their configurations, and knowing what your systems do and how they are configured is the true key to successful systems administration. Remember, the “guidelines” are just that, a guide to configuring and securing your systems. Ultimately, it is up to you to determine which changes you will implement, and most importantly test those changes in a lab/QA environment.

Mac OS X's popularity has been growing rapidly, and so has its use in corporate environments. The NSA has released a new hardening guide for OS X. Tenable has created a configuration audit that will compare the configuration of your OS X systems with the NSA's guidelines, and below are some of the example results from an audit:

Do you know where all of your organization’s SSL certificates are and if they are providing enough protection to you and your customers? Nessus can be used to identify all SSL certificates in use, test if they are expired and with the advent of plugin # 51192, test that they have been securely signed by a valid certificate authority. This blog entry will review Nessus’s SSL certificate auditing ability and describe how plugin #51192 can help monitor your network for untrustworthy SSL certificates.

Recently, Tenable added exploitability reporting for Nessus. After performing a scan, results can be filtered to see which vulnerabilities have exploits available for them. In the report, you can even see which common exploitation tools have payloads for these vulnerabilities. This is a great way to help prioritize which vulnerabilities to fix first. However, it is not a great way to manage your network or decide whether to patch a system or not. Consider the following conversation that represents many I’ve had on this topic: 

Oracle has implemented a quarterly patch release cycle for its customers. Patches for all Oracle products are released on this schedule, and typically fix dozens of vulnerabilities in their database software, Sun Java (recently acquired) and other enterprise products.. They have a similar rating system to other major vendors (such as Microsoft and Cisco) with regular patch release cycles. Oracle describes the severity of each vulnerability using the Common Vulnerability Scoring System (CVSS): "Access Vector", "Access Complexity", "Authentication", "Confidentiality", "Integrity" and "Availability". It is a great way to categorize vulnerabilities; however, this still leaves you with the important task of scheduling, testing and applying the updates.

Tenable's Research team has added the ability to perform an Oracle patch audit into the Nessus vulnerability scanner. A new plugin was created (oracle_rdbms_query_patch_info.nbin) that logs into an Oracle database and runs a set of queries to determine which patches are missing:

• Query 1 - Determines the hostname of the system the database is running on (important when Nessus is testing an Enterprise Manager Grid Controller that contains patch information of other hosts).
• Query 2 - This query pulls the installed "PatchID" and the "Oracle_home" it is installed in.
• Query 3 - If Nessus found any PatchIDs in Query 2, it looks up all the bugs that were superseded by each PatchID that was found in Query 2.

The patch information comes from the same tables that are used by Oracle Enterprise Manger and Oracle Enterprise Manager Grid Controller for patch management.

Tenable has authored a Nessus plugin (ID 46689) named “Cisco IOS Compliance Checks” that implements the APIs used to audit systems running Cisco IOS. This plugin is pre-compiled with the Nessus “.nbin” format. This provides ProfessionalFeed users a method of using Tenable provided .audit files, or their own audit policies, to audit Cisco devices to ensure compliance with corporate policy. This functionality provides a wide range of audit capability including ACL policy detection, service status, device access control and more.

New Keywords

Many of the .audit keywords are the same as for other devices such as Windows and Unix systems. The Cisco compliance checks add two new keywords specific to Cisco IOS based devices:

• feature_set - Similar to the “system” keyword in the Unix Compliance Checks, this keyword checks the Feature Set (e.g. AdvancedEnterprise, AdvancedIP, Advanced Security, K9, etc) version of the Cisco IOS and either runs the resulting check or skips the check because of a failed regex. This is useful for cases where a check is only applicable to systems with a particular Feature Set (e.g. SSH in K8 and K9 bundles).
• ios_version - Similar to the “system” keyword in the Unix Compliance Checks, this keyword checks the version of the Cisco IOS and either runs the resulting check or skips the check because of a failed regex. This is useful for cases where a check is only applicable to systems with a particular IOS version.

"The objectives of this regulation are to insure (sic) the security and confidentiality of customer information in a manner fully consistent with industry standards; protect against anticipated threats or hazards to the security or integrity of such information; and protect against unauthorized access to or use of such information that may result in substantial harm or inconvenience to any consumer."

The SANS Consensus Audit Guidelines (CAG) is a compliance standard that specifies 20 "control points" that have been identified through a consensus of federal and private industry security professionals. This blog post provides a summary of the SANS initiative and an overview of how Tenable’s solutions can be leveraged to demonstrate compliance with these guidelines. Tenable has also released a technical white paper that shows exactly how our scanning, log analysis and auditing solutions can be used to monitor the SANS-CAG controls.

Over the past few months, I’ve had the chance to speak with many different federal government customers who have rolled out FDCC compliance programs. These programs feature central management and auditing of large numbers of desktop configurations. A few years ago, I heard a government administrator proclaim that “satellites would fall out of the sky” when these settings went in place, but recently, I hear federal executives speak about a reduction in volume of help-desk calls and fewer virus outbreaks. So how do you know if FDCC is working for your organization?

This blog discusses some key issues to consider when looking at FDCC or any other type of configuration auditing guidelines. I often ask potential customers, conference speakers and federal CIOs the following questions. The answers I receive often provide clues into how effective the overall FDCC program is.

Stacking Up to CIS Benchmarks

The Center for Internet Security (CIS) establishes consensus benchmarks for a large variety of applications and operating systems. These benchmarks are a valuable aid to evaluate the security of your systems. Tenable has produced a number of Nessus audit files that have been certified by the Center for Internet Security to perform audits against the CIS standards. These audit files are available to ProfessionalFeed and Security Center customers through the the Tenable Support Portal.
To use these audit files, you will need to provide Nessus with credentials to login to the target host to compare the configuration against the CIS standards. Scans that use login credentials run much faster than network-based scans and the results often provide more detailed vulnerability
findings and information on configuration issues.

Nessus plugin #33851 (Network daemons not managed by the package system) is a credentialed check that audits each of the server processes on the audited Linux system. If the running process is not part of a known system package, the plugin reports that the program is the result of a hand-compiled solution. Below is a screen shot of the plugin detecting a hand compiled httpd program:

Tenable’s research group recently added a Nessus plugin that makes use of a credentialed WMI query to determine the type of BIOS that has been installed on the audited computer. Similar plugins were added to perform the same task on UNIX systems via SSH as well as over SMB. The WMI and SMB plugins reside in the Windows plugin family and the SSH plugin belongs to the General plugin family.

Tenable's Research group recently added the ability to perform WMI (Windows Management Instrumentation)  queries to Windows servers and desktops as part of a Nessus configuration audit. These new features allow for rapid and in-depth auditing of a wide variety of configuration settings that are only available through WMI. This blog entry describes how the new API works, and includes several examples.

Previously, Tenable announced that full su/sudo support for UNIX host-based checks was now supported by Nessus 3.2 but that UNIX configuration audits did not have access to this feature. With the latest release of the unix_compliance_check.nbin file (version 1.5.8), full support for su and sudo while performing UNIX compliance audits is now supported. This blog entry discusses this and several other new features.

Tenable's Research group has released two new audit polices for Nessus and Security Center users which audit the AIX operating system.

Recently, Tenable's Security Center product was awarded certification to perform Federal Desktop Core Configuration (FDCC) audits, along with several other types of NIST SCAP audit capabilities, for the Windows XP and Vista platforms. FDCC makes use of the NIST SCAP XCCDF standard to describe security profiles, configuration settings and specific techniques to test for configuration settings. This blog entry describes how this process works and some of the benefits of the NIST SCAP program.

Performing FDCC Audits with the Security Center

Security Center users can download XCCDF content, such as the FDCC policies, and load them into a tool named the "xTool". This tool processes the OVAL, CPE and XCCDF content and logic to produce an audit file that can be used by the Security Center to control one or more Nessus scanners. Tenable's FDCC auditing technology requires credentials for the target systems and does not use an agent.

One of the features of the xTool is to dynamically create audit policies with as little or verbose content available from the XCCDF content. For example, in the screen shots below, the xTool has been configured to display the Nessus audit logic used to test the minimum password age policy.

In the image on the left, none of the meta data was included. In the image on the right, all information related to the Common Configuration Enumeration (CCE) ID, the specific XCCDF audit policy and a handful of related DOD, NIST, ISO and other standards is included. The xTool gives security and compliance managers the ability to customize how much information in the audit is included for analysis by the end user.

The audit policies generated by the xTool are loaded into the Security Center and can then be used to perform configuration audits. These can occur alongside vulnerability scans, patch audits or sensitive data auditing. In the below screen shots, a summary of CCE issues and an example view of detailed results for one CCE is shown:

Once scans are completed, the Security Center can be used to sort the results and identify which types of compliant and non-compliant FDCC issues have been found. These can be sorted by IP addresses, asset group, by type of CCE entry and many other filtering and reporting options.

When submitting results to NIST for FDCC compliance, the results of all systems are not required -- just the results of systems that are representative. For example, based on operational requirements, an organization may need a waiver for the length of their minimum passwords.

With more than 700 configuration checks performed by FDCC, the Security Center can be used to sort and identify unique combinations of non-compliant configurations for hundreds, thousands or even tens of thousands of unique hosts. This makes the process of finding your unique non-compliant samples much easier.

Lastly, the xTool can also import the results of the configuration audit and produce an FDCC report which includes non-compliant tracking of exceptions.

FDCC and SCAP Benefits

Independent Vendor-Neutral Content

As new XCCDF content is developed and hosted by NIST, Security Center users can download it and produce audit polices for new platforms. Tenable currently has customers who have produced audit polices for the beta XCCDF content available for Windows Server 2003, other Windows platforms, Symantec Anti-Virus and the Microsoft Office 2007 suite. As new XCCDF compliant content is developed, the xTool can consume it and produce audit policies.

Logging and Anomaly Detection

Knowing how a system or set of systems are configured is just as important as knowing their vulnerabilities. For example, consider an incident response process that was invoked due to a network wide brute force password attempt. Knowing the password policy (complexity, minimum length, expiration, .etc) of a system can help you prioritize which systems to respond to first.

Similarly, if a user population of systems is configured for a policy that has locked down likely exploit vectors, enabled access-control logging, enabled logging of access to object such as folders and shares and enabled a firewall, the ability to gather logs and look for anomalies is greatly enhanced. Performing anomaly and compromise detection is much easier when the composition of the network you are monitoring is known. 

Quicker Identification of Unmanaged Systems

When complimented with traditional active and passive vulnerability scanning, the Security Center can be used to quickly identify when a system is configured in a non-sanctioned or unauthorized manner.

Perhaps a new system has been installed prior to being locked down. Perhaps some sort of software upgrade resulted in a down-grade of secure system settings. Perhaps a hacker, insider or malware has indeed infected a system and turned off these settings as well. Whatever the reason, in an environment where most hosts are configured the same, finding a host that is different is much easier.

Commercial Auditing

Although the SCAP program has a federal government mandate, the content is also being used in a variety of commercial applications.  For example, Tenable has many financial and health care organizations that are private or commercial entities, yet choose to configure their networks according to NSA best practices, the DISA STIGS and now the SCAP content feeds.

The NIST SCAP program also offers some platforms and recommendations for configuration settings not provided by the Center for Internet Security best practice guides, or directly from vendors such as Microsoft.

For More Information

Tenable has an online video demo of how the xTool and Security Center can be used to perform FDCC and SCAP audits. We've also previously posted about how to configure Windows XP and Vista systems for auditing as well as comments from a NIST FDCC implementor's workshop. To learn more about SCAP and the XCCDF specification, please visit http://nvd.nist.gov.

Previously, I posted a blog which showed how Nessus Direct Feed and Security Center users could audit Windows XP Pro systems against FDCC compliance settings. In this blog entry, we will show how this can also be accomplished for Windows Vista systems. As with the previous blog, we will be performing audits against the reference Virtual PC systems available from NIST.

Configuring Your Vista Target

To enable scanning of a Vista system with Nessus, the following steps can be taken. These steps ensure that the firewall is not blocking connections from the Nessus scanner, that UAC has been modified to enable remote connections and that the remote registry service has been enabled. The last two steps are only required if you are working with a stand-alone Vista system and not one that is participating in a domain.

If you obtained the test image from NIST, you will be greeted with the following start up screen:

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 next item 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:

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy

For more information on this technique, please consider the following MSDN blog entry:

• http://blogs.msdn.com/vistacompatteam/archive/2006/09/22/766945.aspx

The last step is to enable the Remote Registry service. This service is disabled by default. You can enable it for a one-time audit, or enable it permanently such that it will start if the computer is rebooted.

Performing the Test With Nessus

To perform an audit of the required Vista FDCC settings, Tenable Direct Feed or Security Center customers can download the "FDCC Windows Vista Desktop" audit policy from the Tenable Support Portal. A scanning policy that enabled the Windows Compliance Check plugin (ID #21156 in the Policy Compliance family), included credentials for the Windows Vista system(s) being scanned and also included the FDCC_Vista_v2.audit policy file should be created in either the Security Center or Nessus Client. Screen shots of this sort of configuration for the Nessus Client are shown below:

Below are two separate HTML based Nessus Client 3.0 reports generated from scans made with this policy against an FDCC compliant and non-compliant target Vista system:

• Download FDCC_Vista_Compliant.html
• Download FDCC_Vista_Non_Compliant.html

Nessus, SCAP and FDCC Certification

If you have been tracking the NIST SCAP and FDCC programs, you will know that only a few vendors have been certified at this time to perform FDCC audits. Tenable is about to undergo FDCC certification for the Security Center product.

In the mean time though, Tenable has released audit content for Nessus based on FDCC and other types of NIST SCAP checks. Tenable currently has several large federal customers using this content to audit more than 25k desktops and servers in a single distributed Nessus scan being managed by the Security Center.

One of the requirements of FDCC certification is to be able to parse the XCCDF content. Below is a screen shot of a new tool that will shortly be available to Security Center customers which can read the XCCDF content.

With this tool, a Security Center user will be able to work directly with the OVAL content distributed by NIST and produce a compliant Nessus audit file. Also, customers will be able to optionally include reference content (such as FISMA, DISA, ISO and other indexes) into the actual Nessus audit file. This data will automatically be parsed and available to Security Center users after these scans are performed.

For More Information

The following links below reference previous blog entries about the FDCC and NIST SCAP program.

• Using Nessus Configuration Audits to test FDCC Compliance (of Windows XP Pro systems)
• Federally Mandated Configuration Settings for XP and Vista
• NIST FDCC Implementor's Workshop Notes
• NIST Audit Policies for Nessus 3

Tenable Network Security was recently awarded certification by the Center For Internet Security to perform audits of the following best-practices benchmarks:

• Windows Server 2003 Legacy Benchmark for Domain Controllers v2.0
• Windows Server 2003 Enterprise Benchmark for Domain Controllers v2.0
• Windows Server 2003 Specialized Security Benchmark for Domain Controllers v2.0
• Windows Server 2003 Legacy Benchmark for Member Servers v2.0
• Windows Server 2003 Enterprise Benchmark for Member Servers v2.0
• Windows Server 2003 Specialized Security Benchmark for Member Servers v2.0
• Windows 2000 Server Level 2 Benchmark v2.2.1
• Windows 2000 Level 1 Benchmark v1.2.2

Previously, Tenable products had been certified to perform audits of Windows 2003 servers against version 1.2 of their benchmark. Version 2.0 of this benchmark was recently released, our content was updated and then re-submitted for certification by CIS.

Additionally, Tenable has selected SAIC to test the Security Center against the requirements of the Security Content Automation Protocol (SCAP) Validation Program. Specifically, we are seeking approval to be an authorized Federal Desktop Core Configuration (FDCC) scanner.

Tenable's research group recently added support to all SSH enabled UNIX configuration audits to make use of "sudo". Support is available in version 1.4.4 of the UNIX compliance checks. 

Some organizations explicitly prohibit remote "root" logins to their UNIX servers. However, many of these organizations do allow a "non-root" login which has access to the "sudo" command. The "sudo" facility allows a non-root user to run specific restricted commands at the root level. Activity related to "sudo" can be logged as well.

When Nessus logs into a UNIX host via SSH, if the remote account used to login is not "root", it will attempt the command "sudo id". If the identification of the root user is returned, Nessus will perform the configuration checks through the "sudo" command. If the "sudo" facility has not been configured, or it requires a password, Nessus won't use "sudo" and will instead perform it's audit with whatever privileges the remote user account has access to.

When configuring your "sudo" facility, keep the following guidelines in mind:

• The account used by Nessus should be able to run the command "id" and see that it is effectively running as root without being prompted for a password.
• The "sudo" facility should be configured to log all commands run by the Nessus account, including failed commands. These logs can be audited by the Log Correlation Engine to ensure only authorized users are running commands.
  
• If you've restricted the list of commands available to the remote Nessus auditing account, you should perform some test audits to see if your Nessus scan policies can complete their audits. There is nothing wrong with restricting the commands allowed through "sudo", but testing this prior to performing an audit is important.
  

If you are using Nessus with the Direct Feed or Security Center, you do not need to make any changes to your existing scan policies. However, with this new update, you now have the flexibility to configure your target UNIX systems with accounts that have access to the "sudo" facility to support your CIS, NIST and other types of configuration audits.

I attended the January 25th, NIST Federal Desktop Core Configuration Implementers Workshop  this  past week and wanted to share some of my thoughts and take-aways from it.

Some Organizations Were Already Close to FDCC

Several CSO/CTO speakers from a variety of different federal agencies spoke about how they went about doing a gap analysis between their current configuration policies and those of the FDCC.

The trend seemed to be that of the ~700 Microsoft settings covered by FDCC, if an organization didn't comply, the gap was between 10-20 specific settings that were not covered. This means that whatever control and configuration processes existed, they merely had to be tweaked to also handle these new configuration settings. Organizations that had been following CIS, NSA, DISA, recommended vendor or other types of guides were already close to FDCC standards.

I spoke with several of our customers there about their deployments of Nessus and the Security Center to perform FDCC auditing and monitoring and they reported similar trends. The work they had been performing over 2007 had set them up to have an easier time with FDCC.

I'm sure there are some federal organizations that are not doing as well as others, but most have been working towards FDCC compliance since the OMB mandate. In a public setting though, it is difficult to make this a general conclusion because you won't have an agency stand up and say they aren't compliant or don't have a plan.

Issues Performing These Assessments

Only one speaker commented about technical issues deploying tools to perform these audits. I was expecting more discussion around the need to deploy an agent, to scan with credentials, to audit without impacting the mission and so on. I also thought there would have been more guidance given as to dissemination of FDCC audit results. This is fairly sensitive data that can directly effect funding from OMB.

Instead, almost every speaker gave advice on how auditors should befriend their allies in the CIO's chain of command or in operational IT. It was much better to show progress and success in some areas than to try and force a change in an organization that is against this. I think this is good advice in both the federal and commercial markets as it is much harder to argue against demonstrated success than unknown change.

Hardest to Implement Configuration Settings

Dave Dixon, a Microsoft employee working in their FDCC consulting group, gave an overview of the most difficult settings to implement for federal agencies.

The number one item on his list was FIPS 140 compliance. The requirement is to only use certain government authorized encryption algorithms. Microsoft OSes have a security policy setting that can be enabled to enforce this. Getting the thousands if not tens of thousands of desktops to have this setting turned on isn't the problem though. Many of the secure web sites within the federal government and external to the government don't support FIPS 140 encryption algorithms. Enabling this setting effectively cuts off some Windows systems from secure web sites they may need to gain access to.

Also on his list was when to harden a gold build. Depending on the mix of applications (Microsoft SQL, Outlook, Access, .etc), when to harden the registry, disk or services privileges is very important. For example, some of these applications are required to be run or installed as the system administrator, to add new accounts and so on. If a system is overly hardened, building these "gold build" images can become very difficult.

I was very glad that the build and procurement processes are being considered for FDCC. Trying to make a change to a system after it has been deployed is the most expensive and disruptive time to do it. 

Dave Dixon's presentation, along with all of the others, is located at http://nvd.nist.gov/workshop.cfm

Best Questions and Comments From the Audience

The workshop had open mikes where audience members from the federal government could ask questions and make comments. Some of the more interesting comments and questions were (para-phrased) as follows:

Have any of you been able to complete FDCC audits without exceptions?

This was asked to a panel of representatives from four different government agencies. The question was rejected by the moderator as being out of ground rules. I also think the question was unfair because the base FDCC requirements would prevent you from participating in a Windows domain and this is one of the first exceptions most organizations need to consider.

Are you trusting your builds from Dell?

This was asked to a representative who stated they were receiving Windows XP systems configured to be FDCC compliant. I was not clear on the representative's answer, but even if Dell comes close or makes some semi-intelligent effort, this can only help the government move their systems towards FDCC compliance.

Has any thought been paid to the security of the audit and management tools?

I felt this was a very intelligent question. In many ways, if you have thousands or tens of thousands of systems configured the same way, you expose them to vulnerabilities of a mono-culture. This is a valid argument, but I'm much more in favor of lower operational cost to run and secure my network than perhaps relying on "random" configurations as a defense mechanism of some sort. The questioner also wanted to know if source code audits of systems performing these audits and configuration changes were part of SCAP. Tenable has not gone through our SCAP validation lab yet, but source code auditing, or even a security evaluation of the solution, is not part of the audit.

You'll know when FDCC is in place because satellites will be falling from the sky!

This last comment was from someone who was very concerned about the operational impact of these settings. We have several customers who've implemented all FDCC settings across their entire population of Windows desktops without much effect. These customers typically express more confidence in their desktop platforms now that these changes are uniform than when they first entered the FDCC process.

Absolutely No Vista

One final note I think worth mentioning is that there was very little content mentioned about Vista. If it was mentioned at all, it was mentioned that Vista was not approved, or that these configuration changes settings would be taken into account when Vista was rolled out "after 2008" one speaker even said.

For More Information about FDCC

Tenable offers the ability to audit Windows system configurations for FDCC compliance. Previously, we've blogged about FDCC auditing at these following links:

• Using Nessus to Audit FDCC Configurations
• Federally Mandated Configuration Settings for Vista and XP

Previously we've blogged about upcoming changes to how Nessus Direct Feed and Security Center users perform configuration audits of Windows servers and desktops. Version 2 of the Windows Compliance configuration audit plugin is now available.

Nessus Direct Feed and Security Center users should log into the Tenable Support Portal and obtain version 2 of any published audit policies. Nessus users should then update their plugins and make use of these new policies in their Windows configuration audits. Security Center users should place any updated policies in the /opt/sc3/admin/nasl directory. The new version 2 policies all have a trailing "_v2" in their name. Make sure to specify any updated audit policies in your Nessus or Security Center vulnerability scan policies.

If you've written a custom audit policy for Windows systems, converting it to be compatible with the new features of version 2 has been discussed here. Our previous link also includes a technical list of all new keywords and types of audits available in version 2.

Direct Feed and Security Center users performing Windows content audits or UNIX configuration audits do not need to modify any other polices. Only Windows configuration auditing has been effected at this time.

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.

For organizations that actively keep track of and manage their base operating system patches and configurations, a somewhat lofty goal is to try and tighten down third party patches. Organizations can have all Microsoft patches installed and their systems hardened to NIST, CIS and vendor recommendations, and still have major exposure and security issues issues tracking down open source, freeware and third party applications.

This blog entry discusses some of the pain points in managing these third party applications and some ways to scan for them with Nessus and the Passive Vulnerability Scanner.

The Pain Of Non-Standard Patching

I recently went through a security audit and patch upgrade on a personal Microsoft laptop. It had no Microsoft flaws or security issues and was locked down fairly tightly. Having said that, it still had major security issues with a variety of third-party applications. When scanned with Nessus using credentials, it found:

• VMWare Server was out of date a few releases
• Several versions of the JAVA Runtime environment were enabled
• My favorite FTP client (FileZilla) was a full major version out of date
• Quicktime had not been updated in long while
• An ActiveX control in FLEXnet Connect was also exploitable
• The APSB07-12 advisory for Flash

The upgrade process was anything like my typical smooth and silent Microsoft upgrades that happen during shutdowns and on Tuesdays. If you want to avoid my long list of things that were required to get the laptop secured, feel free to skip to the next section.

With VMware, I needed to reboot the laptop, and then reconfigure the virtual NAT environment after wondering why I couldn't ssh into my Linux VMs.

With the JAVA vulnerabilities, even though live updates had been enabled, multiple older versions of the JAVA runtime environment had been installed and were vulnerable to a variety of exploits.

When upgrading to FileZilla 3 from FileZilla 2, the older version was not uninstalled. Even though I ran the upgrade process, it didn't uninstall the older version and I had to manually check the 'About' link within the application to realize that the laptop treated these like two separate applications and not an upgrade.

The Quicktime install was very old, even though live updates were supposedly enabled. Performing a manual download from Apple fixed all vulnerabilities detected by Nessus. I was very tempted to try and figure out why the updates were not occurring, but there were other issues to patch.

Nessus plugin 25371 had also detected an issue with a FLEXnet ActiveX control. This is a vulnerability in InstallSheild. I didn't have time to figure out which application actually installed this issue, and the available patch from Macrovision seemed to focus more on developers than end-users. In the end, I had to manually set a registry setting as recommended by CERT.

And lastly, I had my biggest issue patching the Adobe APSB07-12 Flash bug. Our Nessus plugin checks for both a Flash plugin as well as an Active X control. Simply downloading the patch within Firefox isn't enough. To get the latest Active X control, you need to actually visit Adobe's update site with Internet Explorer.

The point of this exercise was that I was just one user. On an enterprise with dozens or 100s of users, if third party applications are in use, it can become very difficult to keep normalized configurations, let alone secure laptops and desktops.

Active Scanning with Nessus

With more than 17,000 plugins in its database of vulnerabilities it can check for, Nessus looks for a wide variety of non-Microsoft vulnerabilities on Microsoft platforms. These security issues include, but are not limited to:

• Issues with popular email and web clients such as Opera, Mozilla and Thunderbird
• Vulnerabilities in security specific products such as anti-spyware, anti-virus and even Secure Shell clients
• Backup and network management software from EMC, CA
• Media players from Apple and Real Networks
• A wide variety of Internet chat, video conferencing, FTP and other common applications such as Skype, Goggle Talk and FileZilla.

If these services have a "server" component of them (such as iTunes which does listen on certain ports even though it is a client application) Tenable's research team will attempt to write a Nessus plugin that can recognize these services and attempt to see what patch level they are.

However, the most reliable way to identify this type of software is with administrator credentials. Most modern Microsoft environments, an IT audit group can leverage the administrator account on Windows XP Pro, and Windows 2003 systems to audit all installed software and configurations with Nessus.

Another byproduct of auditing system with credentials with Nessus is the ability to enumerate all software installed on the network. When managed by the Security Center, the list of enumerated and discovered software can be analyzed with a variety of tools and even be used to categorize systems based on the type of software installed.

Continuous Network Monitoring with the PVS

Tenable's research group also focuses on the type of network traffic generated by these third party applications. The Passive Vulnerability Scanner rules are typically in lock-step with the type of client-side vulnerabilities discovered by a Nessus credentialed audit.

In the above example of third-party patching I went through, the PVS detected most of the issues with the exception of the Flex licensing security hole.

The PVS has the advantages of not requiring credentials to audit a host and being able to run 24x7, but does have a disadvantage that the software needs to be used on the target platform. This is not a large disadvantage when looking for software in use in your organization. Users who download these tools will likely use them at least once, which the PVS can see and record.

Some of our customers actually prefer to use what the PVS finds because those are the clients that are actually in use on the network.

Putting it All Together

The main advantage of exceeding a compliance standard is that your network configurations can have much more leeway before coming "non compliant". A more practical benefit of focusing on third party security issues is that your network will also be more secure and uniform.

We've blogged before about how Nessus and the PVS can be used to audit your patches (as well as your patching process). If this article was interesting to you, the following Tenable blog entries will also likely be of use:

• Testing the Effectiveness of your Patch Management System
• Knowing When to Patch
• Finding Vulnerabilities Oder than 30 Days
• Reporting Vulnerabilities in an IT Managed Environment

Tenable Network Security has received certification for the Nessus vulnerability scanner and Security Center to perform Center for Internet Security configuration audits of the Windows XP operating system. This blog entry discusses the new audit policies, an upcoming webinar on how to use these polices and making use of these with the Nessus Client and Security Center.

Certified Audit Policies for XP Pro

New audit files are available to all Direct Feed and Security Center customers at the Tenable Customer Portal. Four new audit polices are now available:

• XP Pro Enterprise Desktop
• XP Pro Enterprise Mobile
• XP Pro Specialized Security and Limited Functionality
• XP Pro Legacy

Each of these audit policies corresponds with a CIS profile for deploying Windows XP Pro. The 'Desktop' and 'Mobile' profiles correspond to a typical Windows XP Pro deployment on either a dedicated corporate desktop or a mobile laptop. For extra hardening, tighter security settings and offering the least amount of services, the Specialized Security and Limited Functionality profile can be used. This is an ideal setting to offer very limited and single purpose services. And lastly, for compatibility with Windows NT, the 'Legacy' profile is offered. This profile relaxes some encryption and authentication protocols to retain compatibility with older Microsoft protocols.

Upcoming Webinar

Tenable is offering an upcoming webinar which illustrates what these audit policies test for, how to use them for point auditing with Nessus and how to perform enterprise auditing with the Security Center. The webinar will be held December 12, 2007 between 2:00 PM and 3:00 PM EST.

    Title: Nessus 3 agent-less Configuration and Patch Auditing Windows XP
    Date: Wednesday, December 12, 2007

Space is limited. Reserve your Webinar seat now at: https://www.gotomeeting.com/register/340209530

Installing and Using these Audit Polices

Direct Feed and Security Center customers can immediately download these new polices.

Nessus users can save these audit polices to their scanning platform and make use of them when creating scan polices. With the Nessus Client, the audit polices can be specified when a scan policy is created.

Security Center users should download these polices and place them in the /opt/sc3/admin/nasl directory as owner 'tns'. These polices will then be available to any vulnerability policy.

For More Information

To see a list of all certified CIS configuration audit polices that can be performed by Nessus Direct Feed and Security Center users, please visit:

http://www.cisecurity.org/tenable_cert.html

I was asked this question by a customer of ours at the recent NIST SCAP conference and I'm loosely paraphrasing: 

"We use Nessus and the Security Center to audit 1000s of workstations and laptops for compliance against CIS and eventually NIST SCAP policies. I'd like to be able to have a NAC enforce compliance against CIS policies and the new FDCC policy, but haven't found any to accomplish this yet. Do you know of any?"

Quick Background

If you are not a regular reader of this blog, CIS is the Center for Internet Security. They work with a community of vendors and users to build a consensus of best practices for securing operating systems such as Windows 2003. Vendors who want to audit against CIS best practices can become certified by having their results evaluated through an accreditation process.

Also, SCAP stands for the 'Secure Content Automation Program'. It is a NIST program that produces configuration audit templates in the XCCDF format. XCCDF is a content specification which can be consumed by many different vendors (including Tenable) to perform configuration audits of operating systems such as Windows 2003.

If you visit the CIS or NIST SCAP web sites, you will see a plethora of operating system vendors, patch management vendors, configuration management vendors and auditing companies (like Tenable). However, you will not see typical NAC vendors listed as supporting these standards, or even declaring their intention to support them.

Why is this?

I feel the largest reason NAC vendors have not gone down this road is that consumers have not begun to ask them for these features. Most of the evaluations and reviews of NAC products tend to focus on how easy it is to keep users without passwords or patches off the network.

The technology exists in most NAC products to perform the types of checks required by these audits, but the content has not been produced by the NAC vendors to make this easy for their customers.

A secondary reason is that organizations who have deployed NAC to perform basic authentication and patch auditing and have found it too intrusive won't tolerate a deeper audit of their systems -- especially if it impacts operations.

Why should you care?

NAC solutions that can enforce compliance with corporate configuration standards as well as government and certified best-practice configurations will ultimately reduce variance, reduce the cost of operating the network and keep it secure.

Tenable is not a NAC vendor. However, we do want to see our customers migrate from networks and systems that are un-patched and randomly configured towards systems that are hardened and monitored for anomalies and access control violations. This is the basis of our unified security monitoring strategy.

As standards like XCCDF develop, they create an opportunity for audit vendors, configuration managers and NAC vendors to all enforce the same corporate standards. There is great value and flexibility in being able to access how well a network meets a configuration standard with a solution such as Tenable's, and then at a later date enforce this with a NAC solution.

Next Steps

If you are interested in managing your network towards government or CIS standards, you should start out by assessing any gaps between your current configurations and the standards themselves. You can perform these types of audits with little impact with Nessus and the Direct Feed subscription. Larger organizations who audit against these policies should consider the Security Center.

You should also contact your NAC vendor and tell their sales staff, CTO and marketing people your desires. Nothing speaks louder to a vendor than customers saying they have a need that their solution can meet.

And lastly, if this type of configuration management is new to your organization, IT group or management, you should become as familiar as possible with concepts such as ITIL, Visible Ops and IT Controls. Tenable also offers the "Real Time Compliance Paper" which discusses how configuration auditing, vulnerability management, log analysis and anomaly detection can be jointly used to monitor organizations for PCI, FISMA and many other types of compliance requirements. This paper is available by contacting Tenable.

Tenable has recently announced FDCC audit policies for Nessus ProfessionalFeed and Security Center users. These policies help government organizations test Windows XP Pro and Vista desktops against OMB's required configuration settings. This blog entry describes how this testing can be performed with Nessus against the reference Windows XP Pro FDCC virtual machine image.

Required Materials or Software

The following resources are required to perform this testing:

1. To perform this test, you need a virtual machine player such as VMware or Virtual PC. This will be used to run the virtual disk images of Windows XP Pro.
2. The actual Windows XP Pro images can be obtained from NIST's web site. These are "evaluation" copies of Windows XP, XP Pro and Vista. Make sure your organization is aware of these OS images as unlicensed copies used for testing.
3. Nessus 3 or later with a ProfessionalFeed subscription or actively managed by a Security Center is required.
4. The FDCC Desktops v90 audit policy is available from the Tenable Support Portal under the "Downloads" button and then under the "Compliance and Audit Files " you will find a link for the "Nessus NIST and FDCC Compliance Audit Policies".

Preparing the FDCC Reference Image

When the system is booted up, you will see the following desktop and end user license agreements:

VM Desktop	EULA

The default image is very secured in that the firewall is blocking all ports and remote access has been disabled. To enable access and auditing by Nessus, the following steps must be performed:

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:

• Enable "Windows Firewall: Allow File and Printer Sharing exception"
• Enable "Windows Firewall: Allow Remote administration exception"
• Disable "Windows Firewall: Do not allow exceptions"

Screen shots of these steps are shown below:

Print/File Sharing	Enable Remote Admin	No Exceptions

Also keep in mind that the last check of "Domain Profile" or "Standard profile" depends on whether the system is part of a domain or just a standalone machine. By default, the NIST FDCC reference virtual machine is a standalone machine. However, most government agencies make their Windows desktops part of a domain, so if you've configured this VM to be part of a domain, keep in mind there are separate settings for that profile.

After modifying group policy, the following Local Security Policy setting must be changed for non-domain Windows XP desktops: "Network access: Sharing and security model for local accounts". It is located in "Local Security Settings" under: "Local Policies" => "Security Options". According to Microsoft, "This security setting determines how network logons using local accounts are authenticated". See screenshot below:

By default, this option is set to: "Guest only: local users authenticate as guest". Since remote network users are assigned "Guest" access, they do not have the required privileges to perform a credentialed Nessus scan. Switch this setting to "Classic: local users authenticate as themselves" to give remote Nessus credentialed scans the privilege they need.

Customers are also encouraged to run firewalls on their desktops. However, if they are auditing the Windows XP desktop with Nessus, ports 445 and 139 should be left open, or the IP address from the authorized auditing node running Nessus should be trusted.

Configuring Your Nessus Scanner

We will use NessusClient to perform this scan. To perform such an audit, create a scan policy with the credentials of the target server, then select the "Windows Compliance Checks" plugin, make sure that "Enable Plugin Dependencies" is enabled, and then select the FDCC Desktops v90 audit file is selected. Screen shots of this process are shown below:

Credentials	Windows Compliance Plugin	FDCC Audit Policy

Although we are focusing on an FDCC configuration audit, the scan could have just as easily implemented tests for other configurations, performed a full patch audit, or launched vulnerability checks.

If you were performing this test with a different Nessus client, or with the Security Center, the same data would need to be completed in your scan policies.

Analyzing the Results

When scanning the FDCC Reference system, testing should show 100% compliance with all required OMB settings. Below are two reports of a scanned Windows XP Pro FDCC reference system.

The first report shows 100% compliance with all settings.

The second report shows several issues which reflect non-compliant configurations For the second test we changed several settings to something less than required by the FDCC and performed a new scan.

Both reports are HTML compliant and can be viewed with web browsers.

Download FDCC_WinXP_Compliance_Report.html

Download FDCC_WinXP_Non-Compliance_Report.html

If these scans were performed with the Security Center, the scans themselves could be scheduled with the proper credentials, and specific non-compliant settings be reported across thousands of desktops for analysis and action by auditors and asset owners. 

For More Information

This test did not consider the FDCC desktop firewall audit requirements. Tenable has produced a policy for FDCC desktop firewalls directly based on the NIST SCAP recommended configuration guidelines. However, in order to work with domains, patch management systems and other Microsoft centric solutions, most organizations will need to make exceptions to this policy. Organizations who do make exceptions should modify the Nessus audit policy to reflect their desired firewall settings.

Tenable Network Security has received certification from the Center for Internet Security to perform configuration audits of the Solaris 9 and SuSE Linux 9 operating systems. Audits can be performed with Nessus 3 scanners subscribed to the Direct Feed as well as by enterprise networks with the Security Center.

To obtain these audit polices, please log into your Tenable Support Portal account and download them from the 'Download CIS Compliance and Audit Files' section.

To review all of Tenable's certified CIS audit polices, please view this CIS web link. All CIS certified audit polices are available to Tenable customers at the Tenable Support Portal.
 

Tenable Network Security has released a Solaris audit policy for PCI 1.1 configurations. We've also released a new SuSE Linux best practices audit policy and have updated several others. These are all available to Tenable Direct Feed and Security Center customers through the Tenable Support Portal.  A specific list of what is now available is as follows:

• PCI_Linux.audit (Version 1.0.7) This is an update to the existing .audit file which checks for a few more settings, such as if the network time protocol is enabled. It is available under 'Downloads' and then 'Download Configuration Audit Policies'.
• PCI_Solaris.audit (Version 1.0.0) This audit policy tests for many of the PCI 1.1 configuration requirements for the Solaris 9 operating system. It is available under 'Downloads' and then 'Download Configuration Audit Policies'.
• PCI_Windows.audit (Version 1.0.3) This is an update to the existing .audit file which checks for a few more settings, such as if the network time protocol is enabled. It is available under 'Downloads' and then 'Download Configuration Audit Policies'.
• CIS_Redhat_ES4_105.audit (Version 1.0.5) This is an update to the existing  CIS .audit policy file which fixes a few audit checks and bugs. It is available under 'Downloads' and then 'Download CIS Compliance and Audit Files'.
• SuSE_EL_Best_practice.audit (Version 1.0.0) This is a set of Tenable content to audit SuSE 9 for best practice secure configurations. It is available under 'Downloads' and then 'Download Configuration Audit Policies'.

To use these policies, Security Center users should download these audit files and place them in their /opt/sc3/admin/nasl directory and then make them part of new or existing Vulnerability Polices. Nessus Direct Feed users should download these policies to the system they are operating the Nessus client from and add them to new or existing Nessus scan policies.

Tenable Network Security was recently awarded Center for Internet Security (CIS) certification to perform audits of Windows 2003 Member Servers through Nessus Direct Feed and/or Security Center agent-less scans. Windows 2003 Member Servers are Windows 2003 operating systems which host applications or data and are part of a domain, but are not the actual domain controllers. Tenable has previously received certification to perform certified CIS audits of Windows 2003 Domain Controllers.

To obtain these policies, Security Center users should download these audit files and place them in their /opt/sc3/admin/nasl directory and then make them part of new or existing Vulnerability Polices. Nessus Direct Feed users should download these policies to the system they are operating the Nessus client from and add them to new or existing Nessus scan policies.

The polices are available for download from the Tenable Support Portal by clicking on the 'Downloads' button, and then the 'Download CIS Compliance Audit Policies' button. These policies are available alongside other CIS audit policies. Below is a screen shot of what the current download page looks like:

A short video of the Nessus vulnerability scanner for Windows being used to scan a Windows 2003 with a CIS audit policy is available here.

Tenable Network Security also offers CIS certified audit polices for these "best practice" guides:

• FreeBSD v1.0.5
• Level 1 RedHat EL v1.0.5
• Windows 2003 Domain Controllers
• Windows 2003 Member Servers

Many more CIS audit policies are in development. Tenable also offers audit content that has been generated from the NIST SCAP program, as well as content developed in-house based on guidelines from the Payment Card Industry (PCI), US CERT, Microsoft, NSA, the DISA STIG guide and customer feedback.

The Office of Management and Budget recently released new configuration guidelines for Windows XP and Vista that all Federal agencies need to adopt by February 1, 2008. The guidelines are known as the "Federal Desktop Core Configurations" (FDCC) and have been published as part of the NIST Security Content Automation Protocol (SCAP) program.

Tenable has published two new audit files for Nessus Direct Feed and Security Center users to audit Windows systems against these required configurations settings. The polices are available for download from the Tenable Support Portal by clicking on the 'Downloads' button, and then the 'Download NIST Compliance Audit Policies' button. These policies are available alongside other audit policies based on existing NIST SCAP content for Windows XP Pro and Windows 2003 operating systems.

To use these policies, Security Center users should download these audit files and place them in their /opt/sc3/admin/nasl directory and then make them part of new or existing Vulnerability Polices. Nessus Direct Feed users should download these policies to the system they are operating the Nessus client from and add them to new or existing Nessus scan policies.

A short video of the Security Center being used for a NIST compliance audit against a Windows 2003 server is available here. A short video of Nessus being used to scan for NIST compliance is also available here.

For more information about Tenable's support of NIST configuration auditing standards, please consider these previous blog entries:

• NIST Audit Policies for Nessus 3
• CVSS Version 2 Scoring With Nessus and the Passive Vulnerabiltiy Scanner

Tenable's Research group has produced two Nessus PCI configuration .audit files for both the Windows and Linux operating systems. These configuration checks are derived from specific recommendations and audit requirements based on the PCI 1.1 standard.

These checks go above and beyond the PCI requirements of performing vulnerability and patch auditing and makes it very easy to audit and analyze system configurations against specific PCI items. These new audits also makes it easy to perform a single scan of one or more PCI hosts and accomplish a vulnerability, patch and configuration audit.

For the Windows PCI policy, configuration audits are available to ensure that a host firewall is enabled, that unnecessary services are disabled, that the system is secured to prevent or log abuse and that user account security is sufficient. For the Linux PCI policy, similar audits are performed to limit abuse, to audit new accounts and to ensure that logging is enabled. Each audit file includes the ID of the corresponding PCI DSS Security Audit Procedures document.

Compared to the certified Center for Internet Security .audit policies for Windows and Red Hat available, these .audit files are not as in-depth or comprehensive. However, if you are a PCI auditor or want to see how your systems would do before an official audit, these checks can produce content required to show compliance with a wide variety of sections of the PCI 1.1 standard.

To obtain these .audit files, Direct Feed or Security Center users should log onto the Tenable Support Portal, click on the 'Download' button and then the 'Download Configuration Audit Policies' button. Both polices are available for download under the 'PCI' section.

To install these on the Security Center, copy them to the /opt/sc3/admin/nasl directory. They will then be available as a .audit policy that can be included within a Security Center vulnerability scan policy. A demonstration video of using the Security Center to audit a Windows 2003 server is available here.

Nessus 3 Direct Feed users should save these .audit files to their laptop or server which runs their Nessus client and then create a scan policy which includes the desired .audit file as a configuration audit. A demonstration video of performing a configuration audit of a Windows 2003 server is available here.

Tenable was recently awarded certification to perform  Center For Internet Security (CIS) audits of Red Hat systems with the Nessus 3 scanner and Security Center. This blog entry discusses what the audit files look for, how customers should obtain the audit files and how this impacts PCI audits.

CIS Red Hat ES4 Audit Policy

A new .audit file for both Nessus Direct Feed and the Security Center named redhat_es4_cis.audit, is available on the Tenable Support Portal. This .audit file implements configuration checks and settings recommended in version 1.0.5 of the CIS Red Hat Benchmark.

Audit checks include:

• Correct logging levels
• Secure configuration of SSH
• Banners for FTP, logins and SSH
• Disabling of un-needed services
• Configuration of TCP Wrappers
• Configuration of the cups daemon
• Configuration of Sendmail
• User account configuration
• Locking down the boot processes
• Hardening of kernel network parameters
• Configuration of FTP
• System-wide file and directory permission audits
• Secure X server configuration

Obtaining and Using these Checks

This .audit file can be loaded into the Security Center for enterprise scanning or leveraged as part of a Nessus 3 Direct Feed scan. The policy is downloaded from the Tenable Support Portal. Once logged into the portal, click on the 'Downloads' button, then the 'Download CIS Audit and Compliance Files' button.

Security Center uses should download this policy to the /opt/sc3/admin/nasl directory as owner 'tns'. They will then be available as a Compliance Audit policy for any Vulnerability Scan Policy. Multiple .audit polices can be combined to be performed simultaneously during each scan.

Nessus 3 Direct Feed users should download this policy to their laptop or system where their Nessus client is operating. Nessus 3 clients can reference one or more audit policies for their credentialed scans.

Impact to PCI Assessments

PCI requirements include vulnerability auditing, firewall analysis, log analysis and configuration auditing among many other things. The PCI standard specifically points to CIS as a source for configuration auditing.

For More Information

The following list of links and blog entries are available for readers interested in Tenable solutions and compliance auditing.

• CIS Audits for Windows Domain Controllers with Nessus and the Security Center
• Center for Internet Security -- http://www.cisecurity.org
• Realtime compliance Paper -- Current and potential Tenable customers should request a copy of this paper which details how our unified approach to log analysis, configuration auditing and vulnerability management impacts PCI,  FISMA, SOX, NERC and compliance auditing and montioring.   
• Creating "Gold" Build Audit Policies -- This blog entry details how the Windows Nessus Policy Creator can be used to extract a Nessus configuration auditing policy from a properly configured Windows server.
• NIST Auditing -- Tenable products can also perform NIST configuration audits from the Secure Content Automation Program. This blog entry provides details about the polices available to perform these configuration audits.  The NIST SCAP web site is located at http://nvd.nist.gov/scap/scap.cfm.
• Security and IT Controls -- Gene Kim was interviewed by Richard Steinian about the positive impact that IT Controls (such as configuration management) can have on security and availability of IT resources.

Tenable has recently added several new APIs to the UNIX compliance checks. This blog entry discusses the new checks with several examples. These APIs are available to Direct Feed and Security Center users who have recently updated their plugins. Many of these checks will work for any UNIX operating system, however several of them are specific to RedHat Linux and its derivatives such as Fedora. 

New File Based Keywords and APIs

Checking File Attributes

This 'attr' keyword can now be used in conjunction with the FILE_CHECK and FILE_CHECK_NOT APIs to audit the file attributes associated with a file. Here is a short example:

<custom_item>
type : FILE_CHECK
file : "/bin/sh"
md5 : "d4228cff8f00b204e9812998ecf8427e"
description : "make sure the md5 of /bin/sh is correct"
# make sure the file is immutable (linux-only)
attr : 'i'
</item>

For more information about Linux file attributes, please refer to the man page for chattr.

Checking File Masks

The 'mask' keyword is opposite of the 'mode' keyword where one can specify a permission that should NOT be available for a particular user, group or other member.

Example:

mask : 022

This would specify any permission is acceptable for the file owner but no write permissions for group and other.

A mask value of 7 would mean that no permissions for that particular owner, group or other member are acceptable.

Globbing of File Names

File names can now also be globs. For example, file: "/var/log/*" can be used to specify any and all files in the the /var/log directory.

This feature is particularly useful when all the files with in a given directory need to audited for permissions or contents using FILE_CHECK, FILE_CONTENT_CHECK, FILE_CHECK_NOT or FILE_CONTENT_CHECK_NOT audit checks. 

Required Checks

This keyword is used to specify if the audited item is required to be present or not on the remote system. It gives auditors the flexibility to say "if this file is here, then it should be configured like this". It also lets auditors require that a certain file exist.

For example if 'required' is set to ‘NO’ and the check ‘type’ is ‘FILE_CHECK', then the check will pass if the file exists and permissions are as specified in the .audit file or if the file does not exist. On the other hand if 'required' was set to ‘YES’ the above check would fail.

CHKCONFIG

This audit check allows interaction with the 'chkconfig' utility on the remote RedHat system being audited.

This check consists of 5 keywords which are 'type', 'description', 'service', 'levels' and 'status'. All of these keywords must be specified to define a CHKCONFIG check.

This only works on Red Hat systems or a derivative of Red Hat system such as Fedora.

The following example verifies that the xinetd service is disabled in run levels 1 through 6.

<custom_item>
   type:CHKCONFIG
   description:"Make sure that xinetd is disabled"
   service:"xinetd"
   levels:"123456"
   status:OFF
</custom_item>

If xinetd were to be running in levels 1,2,3 and 6, then the example would look like:

<custom_item>
   type:CHKCONFIG
   description:"Make sure that xinetd is disabled"
   service:"xinetd"
   levels:"1236"
   status:OFF
</custom_item>

It should be pointed out that this audit does not check if the actual process is running or not, just if the process is configured to start at boot time or not.

GRAMMAR_CHECK

This audit check examines the contents of a file and matches a loosely defined grammar made up of one or more regular expression statements. If one line in the target file does not match any of the regular expressions, then the test will fail.

For example, in the bottom example .audit segment, if the file /etc/securetty contained the word "tenable" (a string that should not exist in this file) or was missing the word "vc/3", the audit would fail.

<custom_item>
type : GRAMMAR_CHECK
description : " Check /etc/securetty contents are OK."
file : "/etc/securetty"
regex : "console"
regex : "vc/1"
regex : "vc/2"
regex : "vc/3"
regex : "vc/4"
regex : "vc/5"
regex : "vc/6"
regex : "vc/7"
</custom_item>

This format would also be acceptable:

<custom_item>
type : GRAMMAR_CHECK
description : " Check /etc/securetty contents are OK."
file : "/etc/securetty"
regex : "console"
regex : "vc/[0-9]"
</custom_item>

In the latter case, if we knew the exact contents of a file, it would also be possible to perform an MD5 checksum. However, if we wanted to accept ranges of values, using multiple regular expressions offers greater flexibility.

RPM_CHECK

This audit check is used to check the version numbers of installed rpm packages on the remote system.

This check consists of 4 mandatory keywords which are 'type', 'description', 'rpm', 'operator' and the optional keyword 'required'.

The ‘rpm’ keyword is used to specify the package to look for and the ‘operator’ keyword is to specify the condition to pass or fail the check based on the version of the installed rpm package.

The 'operator' keyword accepts one of these four values:

• lt less than
• gte greater than or equal to
• gt grater than
• eq equal

This keyword only works on RedHat distributions.

Here are some examples, assuming iproute-2.4.7-10 is installed.

<custom_item>
   type : RPM_CHECK
   description : "RPM check for iproute-2.4.7-10 - should pass"
   rpm : "iproute-2.4.7-10"
   operator : "gte"
</custom_item>

<custom_item>
   type : RPM_CHECK
   description : "RPM check for iproute-2.4.7-10 should fail"
   rpm : "iproute-2.4.7-10"
   operator : "lt"
   required : YES
</custom_item>

<custom_item>
   type : RPM_CHECK
   description : "RPM check for iproute-2.4.7-10 should fail"
   rpm : "iproute-2.4.7-10"
   operator : "gt"
   required : NO
</custom_item>

<custom_item>
   type : RPM_CHECK
   description : "RPM check for iproute-2.4.7-10 should pass"
   rpm : "iproute-2.4.7-10"
   operator : "eq"
   required : NO
</custom_item>

<custom_item>
   type : RPM_CHECK
   description : "RPM check for iproute1"
   rpm : "webmin"
   operator : "eq"
   required : YES
</custom_item> 

Please note that although this API could be used to perform vulnerability audits for missing patches, there are already many different Nessus plugin families which perform security patch audits of many different UNIX systems.

XINETD_SVC

The “XINETD_SVC” audit check is used to audit the startup status of xinetd services. The check consists of 4 mandatory keywords which are 'type', 'description', 'service' and 'status'. The 'status' keyword

This check only works on RedHat Linux OSes and their derivatives.

Example Usage:

<custom_item>
type : XINETD_SVC
description : "Make sure that telnet is disabled"
service : "telnet"
status : OFF
</custom_item>

New "Builtin" UNIX Checks

These new APIs have been "built in" to the UNIX compliance checks grammar.

admin_accounts_in_ftpusers

This check audits if all administrator accounts (i.e users with a UID less than 500) are present in /etc/ftpusers.

Example usage:

<item>
name : "admin_accounts_in_ftpusers"
description : "This check makes sure every account whose UID is below 500 is present in /etc/ftpusers"
</item>

dot_in_root_path_variable

This check ensures that the current working directory (‘.’) is not included in the executable path of root user. Ensuring this prevents a malicious user from escalating privileges to superuser by forcing an administrator logged in as root from running a Trojan horse that may be installed in the current working directory.

Example usage:

<item>
name : "dot_in_root_path_variable"
description: "This check makes sure that root's $PATH variable does not contain any relative paths"
</item>

find_orphan_files

This check reports all files that are un-owned on the system.

By default the search is done recursively under the “/” directory which can make this check extremely slow to execute depending on the number of files present on the remote system. However, if needed the default base directory to search for can be changed by using the optional keyword "basedir".

It is also possible to skip certain files within a "basedir" from being searched using the optional keyword "ignore".

The timeout value (i.e the time after which Nessus will stop processing results for this check) is five hours and this value cannot be changed.

Two Examples:

<item>
name : "find_orphan_files"
description : "This check finds all the files which are 'orphaned'"
</item>

<item>
name : "find_orphan_files"
description : "This check finds all the files which are 'orphaned'"
basedir : "/tmp"
ignore : "/tmp/foo"
ignore : "/tmp/bar"
</item>

find_suid_sgid_files

This check reports all files with the set-user-ID (SUID) or set-group-ID (SGID) bit set. These files can be run by less privileged users but are executed with user's of higher privilege.

All files reported by this check should be carefully audited for any security issues especially shell scripts and executables that were not shipped with the system.

SUID and SGID files present the risk of escalating privileges of a normal user to the ones possessed by the owner or the group of the file.

If such files or scripts do need to exist then they should be specially examined to check if they allow creating file with elevated privileges.

Example Usage:

<item>
name : "find_suid_sgid_files"
description : "This check finds all the files which have their SUID or SGID bit set"
</item>

find_world_writeable_directories

This check reports all the directories that are world writeable and also have the sticky bit not set on the remote system.

Ensuring that the sticky bit is set for all world writeable directories ensures that only the owner of file with in a directory can delete the file which prevents any other user from accidentally or intentionally deleting the file.

Two Examples:

<item>
name : "find_world_writeable_directories"
description : "This check finds all the directories which are world writeable and whose sticky bit is not set"
</item>

<item>
name : "find_world_writeable_directories"
description : "This check finds all the directories which are world writeable and whose sticky bit is not set"
basedir : "/tmp"
ignore : "/tmp/foo"
ignore : "/tmp/bar"
</item>

find_world_writeable_files

This check reports all the files that are world writeable on the remote system.

Ideally there should be no world writeable files on the remote system (i.e. the result from this check should nothing). However in some cases depending on organizational needs, there may be a requirement for having world writeable files.

All items returned from this check must be carefully audited and files that don’t necessarily need world writeable attributes should be removed as follows:

chmod o-w world_writeable_file

Two Examples:

<item>
name : "find_world_writeable_files"
description : "This check finds all the files which are world writeable and whose sticky bit is not set"
</item>

<item>
name : "find_world_writeable_files"
description : "This check finds all the files which are world writeable and whose sticky bit is not set"
basedir : "/tmp"
ignore : "/tmp/foo"
ignore : "/tmp/bar"
</item>

writeable_dirs_in_root_path_variable

This check reports all the world and group writeable directories in the root users $PATH variable.

All directories returned by this check should be carefully examined and unnecessary world/group writeable permissions on directories should be removed as follows:

chmod go-w path/to/directory

Example usage:

<item>
name : "writeable_dirs_in_root_path_variable"
description : "This check makes sure that root's $PATH variable does not contain any writeable directory" </item>

Tenable was recently awarded certification to perform three different Center For Internet Security (CIS) Windows Domain Controller audits with the Nessus 3 scanner and Security Center. This blog entry discusses CIS, what the audit files look for, how customers should obtain the audit files and how this impacts PCI audits.

Center for Internet Security

The CIS is a non-profit organization that produces "best practice" guides for securing a wide variety of IT infrastructure such as operating systems, applications and network devices. The consortium takes input from operators, operating system vendors, governments and security experts to produce a set of "best practices" documents.

Product vendors such as Tenable that can perform a technical configuration audit can join the CIS organization and have their audit methodology and technology become certified.

For these new Windows audits, Tenable submitted a detailed methodology of how Nessus 3 and the Security Center performed and reported the specific audits required by the best practice guides.

CIS Windows Audit Polices

Three new audit files for Nessus 3 Direct Feed and Security Center users are now available. These audit Windows 2003 Domain Controllers that have been configured for Legacy, Enterprise and Specialized Security Profiles.

The Enterprise profile comprises all of the settings that the CIS best practices guide recommends. For example, it recommends that all communications for the Domain occur with "signed" packets. This feature was added in Windows 2003 and is not supported by older Windows domain controllers. The Legacy profile relaxes the security requirements that are not available to older release of Windows Servers. The Specialized Security profile is used for high-risk configurations that host sensitive data or require high availability. 

Some settings are the same across policies and some are different. For example, the minimum recommended password length for the Legacy and Enterprise policies is 8 characters, but it is extended to 12 for Specialized Security.

Example Video Demonstration

A demonstration video of both Nessus 3 and the Security Center performing and analyzing results from a Windows 2003 configuration audit is available here. The demo includes a short overview of CIS.

Obtaining these Checks

Any of the .audit files can be loaded into the Security Center for enterprise scanning or leveraged as part of a Nessus 3 Direct Feed scan. Polices are downloaded from the Tenable Support Portal. 

Security Center uses should download the polices they need and place them in the /opt/sc3/admin/nasl directory as owner 'tns'. They will then be available as a Compliance Audit policy for any Vulnerability
Scan Policy. Multiple .audit polices can be combined to be performed simultaneously during each scan.

Nessus 3 Direct Feed users should download the desired audit policies to their laptop or system where their Nessus client is operating. Nessus 3 clients can reference one or more audit policies for their credentialed scans.

Impact to PCI Assessments

PCI requirements include vulnerability auditing, firewall analysis, log analysis and configuration auditing among many other things. The PCI standard specifically points to CIS as a source for configuration auditing.

For More Information

The following list of links and blog entries are available for readers interested in Tenable solutions and compliance auditing.

• Center for Internet Security -- http://www.cisecurity.org
• Realtime compliance Paper -- Current and potential Tenable customers should request a copy of this paper which details how our unified approach to log analysis, configuration auditing and vulnerability management impacts PCI,  FISMA, SOX, NERC and compliance auditing and montioring.   
• Creating "Gold" Build Audit Policies -- This blog entry details how the Windows Nessus Policy Creator can be used to extract a Nessus configuration auditing policy from a properly configured Windows server.
• NIST Auditing -- Tenable products can also perform NIST configuration audits from the Secure Content Automation Program. This blog entry provides details about the polices available to perform these configuration audits.  The NIST SCAP web site is located at http://nvd.nist.gov/scap/scap.cfm.
• Security and IT Controls -- Gene Kim was interviewed by Richard Steinian about the positive impact that IT Controls (such as configuration management) can have on security and availability of IT resources.

Sensitive government and military organizations classify their documents with familiar terms like "TOP SECRET" and also less well known terms like "NOFORN" (which means the data can't be shared with any foreign nationals).

These terms and phrases are usually placed in the headers and footers of every page in electronic documents. Most organizations that deal with extremely sensitive data have mandatory requirements for documents to be labeled according to their classification levels.

Nessus Direct Feed users can scan network servers for these types of documents with a new audit policy available on the Tenable Support Portal. The "Classified Documents" .audit file searches Word and Adobe files for many common keywords used in the US government and NATO to indicate the classification level of the document.

Modifying the policy to audit for specific code words is also very simple. Below is an example simple search for the word "TOP SECRET":

<item>
        type: FILE_CONTENT_CHECK
        description: "Server is hosting TOP SECRET level documents"
        file_extension: "pdf" | "doc"
        regex: "TOP SECRET"
        expect: "TOP SECRET"
    max_size : "3k"
</item>

Often, classified programs receive their own codeword. Documents from a program named "TENABLE" would be labeled "TOP SECRET TENABLE". If we wanted to modify the default policy "TOP SECRET" policy to look for two or more specific program code we could run an audit with this type of logic:

<item>
        type: FILE_CONTENT_CHECK
        description: "Server is hosting TS codeword level documents"
        file_extension: "pdf" | "doc"
        regex: "TOP SECRET (NESSUS|TENABLE|UFO|ELVIS)"
        expect: "TOP SECRET"
    max_size : "3k"
</item>

The new regular expression would look for documents from the various programs named NESSUS, TENABLE, UFO and ELVIS. 

To learn more about how countries around the world classify their sensitive data, please read this Wikipedia entry. To learn more about the Nessus Direct Feed, please visit our web site or consider watching one of the Nessus demonstration videos.

Tenable's research group has released a set of seven audit policies for the Vista operating system. These polices are based directly off of Microsoft's Windows Vista Security Guide. This blog entry discusses how to obtain these audit policies and how to perform an audit of a Vista  computer system.

Obtaining These Plugins

Security Center or Direct Feed users should log into the Tenable Support Center and then click on "Downloads", then "Download Configuration Audit Policies" and then select any of the following "MS Vista" policies:

• Windows Vista Default Security
• Windows Vista EC Desktop
• Windows Vista EC Domain
• Windows Vista EC Laptop
• Windows Vista SSLF Desktop
• Windows Vista SSLF Domain
• Windows Vista SSLF Laptop

The terms EC and SSLF refer to "Enterprise Client" and "Specialized Security Limited Functionality". EC computers are expected to participate in a domain and SSLF computers are for very secure "stand-alone" functions.

Tenable customers who do not have access to the Support Center should email support@tenablesecurity.com to obtain a login.

Using These Vista Audit Files

Nessus 3 users should save these audit policies to their laptop or computer from which they are running their Nessus client. Once saved, the audit policies can be used as part of a vulnerability or scan policy.

Security Center users should save these audit polices to the /opt/sc3/admin/nasl directory as user/group owners of 'tns'. Once saved, these audit policies will be available to be included within any existing or new Vulnerability Policy.

Scanning Vista Systems

To perform credentialed scans of Vista servers, please keep the following items in mind:

• Port 445 is blocked by default on many versions of Vista. Modifying this rule in the local firewall policy is required.
• The Remote Registry Service must be enabled.
• The username and password used should be for the "Builtin Administrator" and not a new user that has been added to the Administrator's group.

Below are images of which firewall rules and services are required to be enabled to perform remote credentialed scans of a Vista system:

Enabling Remote Registry Access	Enabling File Sharing

For More Information

Tenable has produced several different webinars and blog entires regarding performing audits of Windows operating systems:

• Creating "Gold Build" Audit Policies
• Windows Nessus Compliance Video
• Windows Nessus Compliance Webinar
• Asking Vista for its list of Network Interfaces

Readers interested in obtained a Direct Feed subscription or try the Security Center should visit Tenable's web site.

Tenable has released our first batch of audit policies which can test Windows 2000, 2003 and XP Pro systems for compliance with NIST best practice configuration standards.

These ".audit" checks are currently available on Tenable's Support Portal (available to Tenable customers) and can be downloaded to any Nessus 3 Direct Feed scanner or Security Center.

NIST SCAP Program

The US National Institute of Science and Technology has many different groups which keep track of and publish guides for a wide variety of standards, including several for computer security. The NIST Secure Content Automation Program (SCAP), offers content which can be used to automate security testing. The end result of SCAP is to have common configurations and security settings across the federal government. By leveraging more default consistency and security that can be enabled on each operating system, federal agencies will decrease their attack surface and also have infrastructures that is easier to manage. 

The main technology of the SCAP program is a common format to describe system configuration settings known as XCCDF. XCCDF stands for the Extensible Configuration Checklist Description Format. It is an XML file that leverages OVAL descriptions for computer system audits. XCCDF content is available under the SCAP program for a variety of operating systems and applications. Each XCCDF file may include support for different types of reference network functions, as well as different levels of security hardening.

Tenable and XCCDF

Tenable has developed an in-house tool that automatically converts XCCDF polices for Windows to Nessus 3 compatible .audit files. These .audit files are available on Tenable's Support Portal to existing customers. As the SCAP program develops new XCCDF content, Tenable will update these audit policies accordingly. Tenable is also actively developing XCCDF content for Vista, RedHat, and Solaris platforms.

There are 24 new polices. These primarily consist of a combination of Windows XP Pro and Windows 2003 systems which have been deployed in one of the following profiles:

• Enterprise
• Legacy (Support for NT4)
• Stand Alone

In addition, NIST has also published XCCDF templates for several DISA and NSA recommendations to harden Windows XP Pro. Audit files for these policies are also available.

FISMA and OMB

The Office of Management and Budget has recently announced that all federal agencies are required to implement a common configuration standard for their Microsoft operating systems. Throughout the next year, organizations are to implement a plan and then implement procedures to ensure compatibility with existing software and to have consistent configurations across all Microsoft desktop operating systems.

The content available from NIST is ideally suited for choosing a consistent configuration because there are many types of enterprise reference models and the content was developed by NIST and NSA security experts.

Using Tenable's Direct Feed or Security Center to perform these checks is also a good choice because it does not require any agents to be deployed and the specific audit policies can be easily customized.

Using these Audit Files

Any of the .audit files can be loaded into the Security Center for enterprise scanning or leveraged as part of a Nessus 3 Direct Feed scan.

Security Center uses should download the polices they need and place the polices in the /opt/sc3/admin/plugins directory as owner 'tns'. They will then be available as a Compliance Audit policy for any Vulnerability Scan Policy.

Nessus 3 Direct Feed users should download the desired audit policies to their laptop or system where their Nessus client is operating. Nessus 3 clients can reference one or more audit policies for their credentialed scans.

For More Information

Organizations interested in purchasing the Direct Feed ($1200/year per Nessus 3 scanner) or a Security Center ($15,750 to audit 500 servers) can contact Tenable's sales group by emailing sales@tenablesecurity.com. To learn more about Tenable's involvement with NIST and configuration auditing, please consider these previous blog entries:

• NIST CVSS Scores in Nessus Plugins
• Creating "Gold Build" Audit Policies
• Security and IT Controls

Modern business attempt to put in place "Non Disclosure Agreements" with each other. These agreements dictate the rules for use for knowledge gained through interaction with each other.

Tenable's research group recently added a .audit content policy file to search for NDAs in Adobe and Word documents. The expected location for an NDA would be in your legal department. However, discovering NDAs on public web servers, on public network folders or on mobile sales laptops may indicate that unauthorized people have access. 

The .audit file performs some keyword searches. This could also be extended with specific names of competitors or business partners to be more exact in what is discovered. Below is a screen shot of a "hit" on a file which is a Tenable Network Security NDA:

The ability to audit content on remote systems with Nessus is available to Security Center users and Direct Feed subscribers.

Note: This blog entry was originally posted in April, 2007 and was updated on May 28, 2009

The Security Center can be used to manage multiple Nessus scanners and Passive Vulnerability Scanners for continuous monitoring of sensitive data at rest and data in motion. This blog entry discusses various deployment scenarios that can be used to effectively perform data leakage detection.

Active and Passive Detection Methods

In March, 2007, Tenable released the ability for Nessus ProfessionalFeed and Security Center users to scan Windows hosts for sensitive data such as credit cards, employee information and even things like source code. This technology works as part of the regular vulnerability or configuration auditing scans.

Previously, Tenable also released policy libraries for the Passive Vulnerability Scanner (PVS) to identify servers and users transmitting sensitive data in motion. The PVS can not only identify hosted Adobe, PowerPoint, Word and Excel files as Nessus can, it can look into the traffic in email, chat and web browsing to look for specific types of data such as social security numbers and credit cards.

When managed by the Security Center, the combination of active and passive data leakage monitoring is an effective method to discover where sensitive data is and when it leaves the networks. Below is a screen shot of an America Express credit card number being hosted on a web server:

Why Find Sensitive Data?

When sensitive data is identified through the Security Center, several courses of action can be taken:

• A list of all systems with sensitive data can be obtained by IP address, MAC address, DNS name or Windows name. This list is available as a spreadsheet or can be created as a PDF report.
• A list of all corporate assets with sensitive data can similarly be created, allowing users to see if any systems unauthorized to hold data actually have any.
• The Security Center's ability to combine qualities of vulnerability detection with asset identification also allows it to find hosts with sensitive data that are unmanaged or have vulnerabilities.
• If necessary, different types of sensitive data records can be classified into different asset groups. For example, all systems holding credit card data could be placed into a PCI asset list while all records holding patient health data could be placed into a HIPAA list.
• If the Security Center is able to detect a system compromise, the incident response process can immediately take into account if this was or was not a server or system with sensitive data.

All of these capabilities allow an organization to combine information about system vulnerabilities, system configurations and systems holding sensitive data to identify and manage potential compliance, security and data leakage issues.

Creating Dynamic Asset Lists based on Sensitive Content

Information about sensitive data found by Nessus or the PVS can be used to create a Security Center dynamic asset list. This data can be combined with other attributes such as IP address, system usage, open ports, domain name, system asset information and so on to create unique asset lists.

For example, in the screen shot below, we've scanned the network for documents containing the word "Tenable" in them.

If we wanted to write a dynamic asset rule for all systems that had this data on it, we'd target ID #60186 and also had the content of "[FAILED]". This second step is required because if a systems did not have any .doc files that had the word "Tenable" in it, it would also have an active ID #60186 but would have the content "[PASSED] in it.

For More Information

Information on purchasing the Security Center ($15,750 for 500 servers), Passive Vulnerability Scanner ($9995 for any network) or the ProfessionalFeed ($1200/year per Nessus scanner for end users) is available here.

Readers who are interested in compliance can request a copy of Tenable's "Real Time Compliance Monitoring" paper, as well as any of our application notes on PCI, or HIPAA compliance monitoring.

Note: This blog entry was originally posted in March, 2007 and was updated on May 28, 2009

Tenable Network Security has released a new Nessus plugin named "Windows File Contents Check" (plugin ID #24760). It is available in the Nessus ProfessionalFeed and has the ability to find a wide variety of sensitive data at rest on Windows computers. This blog entry describes how the checks work and how Nessus ProfessionalFeed users can benefit from them. This new plugin is also supported in Security Center which is covered in a separate blog entry.

Why Find Sensitive Data?

Finding and identifying where your sensitive data is within an organization allows better prioritization of security issues and can find systems (and users) that are not authorized to possess that data. 

When sensitive data is identified, an analyst can ask one of two questions:

• Is this data authorized to be on this server at all?
• Does the system that holds this data have proper access control, patch management and overall security?

When combined with Nessus' ability to find systems with vulnerabilities and systems that are not being managed, detecting sensitive data can focus an IT organization's efforts to remain compliant and reduce risk of data loss.

• Unauthorized systems and users with access to sensitive data can be detected and rectified.
• Authorized systems with sensitive data and vulnerabilities or mis-configurations can be given priority over similar systems that do not hold sensitive data.

What kind of Data is "Sensitive"?

Every organization has a wide variety of data that is important, but few organizations have built a data dictionary or a classification scheme.

Most readers are familiar with the government's use of the terms "SECRET" and "TOP SECRET". There have also been many cases of financial, academic and commercial institutions losing large volumes of customer credit card numbers, social security numbers, addresses and phone numbers.

Your organization most likely has its own list of things that it considers "intellectual property". Perhaps it is source code or a copy of  a manuscript that has not been released.

This new Nessus check can help find many different types of this kind of data.

Here is an example screen shot of detecting the word "Tenable" in any Word file on a remote Windows system:

For this example,  the offending data was not actually shown because we were looking for just the word "Tenable". If we had matched on a more complex pattern, such as a social security number, the report would display the actual data.

How does it work?

The current check supports credentialed scans of a Windows server. Like all Nessus credentialed scans, it does not require an agent but it does require an account that has login credentials and the ability to read the disk. A domain administrator account can be used to perform these checks.

Each scan is given one or more ".audit" files that have the same type of format and structure as Nessus's compliance checks. Here is a short example that looks for a Social Security Number:

<check_type:"WindowsFiles">
<item>
        type: FILE_CONTENT_CHECK
        description: "Determine if a file contains a SSN"
        file_extension: "txt" | "doc" | "xls" | "pdf"
        regex: "([^0-9-]|^)([0-9]{3}-[0-9]{2}-[0-9]{4})([^0-9-]|$)"
        expect: "Social Security Number" | "SSN" | "SS#" | "Social"
    max_size : "50K"
</item>
</check_type>

When invoked, the remote Windows host will compute a list of all local files with extensions for text, Word, Excel and Adobe files. It will then send the first 50K bytes of each file to Nessus over a secure SMB link. All data obtained by the plugin will be searched for the data patterns in the .audit file. In the above case, any of the strings "Social Security Number", "SSN", "SS#" or "Social" are required to be present. The regular expression is used to look for at least one SSN.

If the system is scanned and no sensitive data is found, it is logged as a "PASS". Otherwise, it is logged as a FAILURE.

Other technical details include:

• Any file extension can be used.
• For PDF files, the Nessus plugin automatically decodes the PDF encoding.
• A regular expression statement is optional, however, the "expect" statement that contains basic string matches is always required.
• There is an additional keyword named "only_show" which only shows the last "n" bytes of a matched file.

Protecting the Auditors

Below is an example of a .audit policy to search for American Express credit card numbers:

<check_type:"WindowsFiles">
<item>
        type: FILE_CONTENT_CHECK
        description: "Determine if a file contains a valid American Express Card Number"
        file_extension: "xls" | "pdf"
        regex: "([^0-9-]|^)(3(4[0-9]{2}|7[0-9]{2})( |-|)[0-9]{6}( |-|)[0-9]{5})([^0-9-]|$)"
        expect: "American Express" | "CCAX" | "amex" | "credit"
        max_size : "50K"
        only_show : "4"
</item>
</check_type>

As an auditor, you might think it very interesting to start collecting credit cards, personal data and so on, but organizations that are trying to limit where this type of data goes do not want to compound the problem.

Rather than making your audit team part of your "sensitive" data controls, all of the audits performed by Nessus can limit the amount of data that is displayed. The "only_show" keyword in the audit file will display the last "N" bytes of data. For example if an example credit card of "1122-3344-5566-7788" was found, it would only display "XXXXXXXXXXXXXXX7788".

Obtaining and Running These Checks

Nessus ProfessionalFeed users on Red Hat, Solaris and OS X can simply update their plugins. Along with the new plugin, a new plugin preference named "Windows File Contents Compliance Checks" will be available. The new plugin will also be available under the "Policy Compliance Family".

To run a check, download a .audit file (or write your own), build a scanning policy that includes the new plugin and your .audit file and then perform a scan against a Windows host with the proper credentials.

Tenable is adding more and more example .audit files at the Tenable Support Portal. These files are listed alongside the configuration .audit files for NIST, NSA and CERT audit standards and many more. Currently, the Sensitive Content Audit Policies .audit files are offered for discovery of:

• Employee Identification Number
• Employee Salary List
• Financial Statement
• International Wire Transfer
• Non Disclosure Agreements
• Source Code Leakage
• Classified Documents
• EDI Claim Information
• Credit Card Number
• Driver’s License
• Social Security Number (Generic)
• Social Security Number (by State)

Optimizing These Checks

While BETA testing these .audit files, there were several trade-offs than any organization needs to consider:

• Which extensions should we search for?
• How much data must be scanned?

The .audit files do not require the "max_size" keyword. In this case, Nessus will attempt to retrieve the entire file and will continue until it has a match on a pattern. Since these files traverse the network, there is more network traffic with these audits than with typical scanning or configuration auditing.

Searching for more extensions may encounter unexpected results. For example, Trillion chat logs are saved as .txt files. If you have a user who placed an SSN or a credit card number in a chat session once, that may show up.

Searching for less data, such as just the first 5000 bytes is much faster than searching for the first 50K bytes, but is much less in depth.

For More Information

There is a separate blog entry that describes using this plugin in an enterprise network as part of a comprehensive vulnerability, configuration and sensitive data audit environment.

Information on purchasing the ProfessionalFeed ($1200/year per Nessus scanner for end users) is available here.

Tenable has added several new types of configuration and security audits that can be performed by Nessus 3 against Windows servers. This blog post explains the new items.

New Auditing Options

There are four new types of audit types available for Windows:

• GROUP_MEMBERS_POLICY
• FILE_AUDIT
• REGISTRY AUDIT
• SERVICE_AUDIT

The new types allow for close analysis of file, registry and service audit policies as well as which specific users are members of of a group.

GROUP_MEMBERS_POLICY

If you would like to perform audits of a Windows server and make sure that there is a specific list of users present in one or more groups, it is now very trivial to accomplish. The template for this type of audit is as follows:

<custom_item>
type: GROUP_MEMBERS_POLICY
description: ["description"]
value_type: [value type]
value_data: [value] | ([value2] | (...))
group_name: ["group name"]
</item>

When using this type of audit, the following items should be considered. The "value_type" variable must always be "POLICY_TEXT".  The "value_data" variable is a list of user accounts in quotes, separated by a pipe character. User accounts can also refer to their domain prefix such as "MYDOMAIN\John Smith". Lastly, the "group_name" specifies a single group for auditing.

A single Nessus .audit file can specify multiple different customer items, so it is very easy to audit lists of users in multiple groups. Here is an example .audit policy which looks for the "Administrators"
group to only contain the "Administrator" and "TENABLE\Domain admins" user:

<check_type: "Windows">
<group_policy: "Audit Administrators group">
<custom_item>
type: GROUP_MEMBERS_POLICY
description: "Checks Administrators members"
value_type: POLICY_TEXT
value_data: "Administrator" | "TENABLE\Domain admins"
group_name: "Administrators"
</item>
</check_type>

When scanning a Windows 2003 server that was not on the Tenable domain, the results under Nessus 3 look like this:

FILE_AUDIT

On Windows server systems, any file or directory can have auditing enabled. This can create logs when authorized or unauthorized users attempt to access or delete content.  The new type requires the specification of a Windows access control list someplace else in your .audit file. The template for this check looks like:

<custom_item>
type: FILE_AUDIT
description: ["description"]
value_type: [value_type]
value_data: [value]
file: ["filename"]
(optional) acl_option: [acl_option]
</item>

The "value_type" feild must always contain a FILE_ACL. The "value_data" field should name an Access Control List defined elsewhere in your .audit file.  The "file:" keyword should indicate either the full path to the file or directory of interest, or make use of one of the following supported PATH keywords:

• %allusersprofile%
• %windir%
• %systemroot%
• %commonfiles%
• %programfiles%
• %systemdrive%

When using this audit, please consider the following. The "file" field must include the full path to the file or folder name (ie: C:\WINDOWS\SYSTEM32) or make use of the above PATH keywords. The "value_data"  field is the name of an access control list defined in the policy file. The "acl_option" field can be set to CAN_BE_NULL or CAN_NOT_BE_NULL to force a success/error if the file does not exist. Also, the "acl_allow" and "acl_deny" fields correspond to "Successful" and "Failed" audit events.

Here is an example .audit file that implements the FILE_AUDIT function, including an example access control list rule named "ACL1".

<check_type: "Windows">
<group_policy: "Audits SYSTEM32 directory for correct auditing permissions">

<file_acl: "ACL1">
<user: "Everyone">
acl_inheritance: "not inherited"
acl_apply: "This folder, subfolders and files"
acl_deny: "full control"
acl_allow: "full control"
</user>
</acl>

<custom_item>
type: FILE_AUDIT
description: "Audit for C:\WINDOWS\SYSTEM32"
value_type: FILE_ACL
value_data: "ACL1"
file: "%SystemRoot%\SYSTEM32"
</item>

</group_policy>
</check_type>

REGISTRY_AUDIT

Similar to FILE_AUDIT, registry settings can have auditing enabled to log when attempts to add, change, delete or modify them occur by specific users or groups. The prototype for this type of audit is this:

<custom_item>
type: REGISTRY_AUDIT
description: ["description"]
value_type: [value_type]
value_data: [value]
reg_key: ["regkeyname"]
(optional) acl_option: [acl_option]
</item>

When using this type of audit, please keep the following items in mind:

• The only supported value for "value_type" is REG_ACL
• The "value_data" field specifies the access control list name
• The "reg_key" field specifies the registry key name for auditing
• The "acl_option" field can be set to CAN_BE_NULL or CAN_NOT_BE_NULL to force a success or error if the key does not exist
• The "acl_allow" and "acl_deny" fields correspond to "Successful" and "Failed" audit events

Also, the "reg_key" value can also make use of a predefined registry path value of :

• HKLM (HKEY_LOCAL_MACHINE)
• HKU (HKEY_USERS)
• HKCR (HKEY_CLASS_ROOT)

Here is an example portion of a .audit file which audits the registry key of "HKLM\SOFTWARE\Microsoft" against an access control list named "ACL2" which is not shown:

<custom_item>
type: REGISTRY_AUDIT
description: "Audit for HKLM\SOFTWARE\Microsoft"
value_type: REG_ACL
value_data: "ACL2"
reg_key: "HKLM\SOFTWARE\Microsoft"
</item>

SERVICE_AUDIT

Similar to auditing files and registry settings, Windows also has the ability to audit when authorized or unauthorized users attempt to start, stop or restart a process. The prototype for this is as follows:

<custom_item>
type: SERVICE_AUDIT
description: ["description"]
value_type: [value_type]
value_data: [value]
service: ["servicename"]
(optional) acl_option: [acl_option]
</item>

When using this audit, please keep the following items in mind:

• The "value_type" field is always SERVICE_ACL
• The "value_data" field contains the name of the access control list to test against
• The "service" field identifies the service to be audited.
• The "acl_option" field can be set to CAN_BE_NULL or CAN_NOT_BE_NULL to force a success or error if the service does not exist
• The "acl_allow" and "acl_deny" fields correspond to "Successful" and "Failed" audit events

Here is an example portion of a .audit file for auditing the "Alerter" service.

<custom_item>
type: SERVICE_AUDIT
description: "Audit for Alerter Service"
value_type: SERVICE_ACL
value_data: "ACL3"
service: "Alerter"
</item>

Version 1.0.8 of the "inf to audit" (i2a) tool

Tenable has also released version 1.0.8 of the i2a tool to take advantage of these new features. The i2a tool converts Microsoft .inf policy files directly to a Nessus 3 .audit file. If you have previously generated a .audit file with the i2a tool, and it had audit policies for these new settings, you can rerun the i2a tool on your .inf policy file to get an updated audit policy.

Obtaining The New Audits

Nessus 3 Direct Feed or Security Center users should update their plugins. If daily plugin updates are normally performed, you will already have these new audits available to you.

At the time of this blog writing, the latest version of the compliance_check.nbin file was 1.20. On UNIX, you can test this by invoking the nasl binary test tool.

[root@megalon bin]# ./nasl -V /opt/nessus/lib/nessus/plugins/compliance_check.nbin
Script ID : 21156
Script Name : Windows Compliance Checks
Script Version : $Revision: 1.20 $
Copyright : This script is Copyright (C) 2006 Tenable Network Security
Family : Policy Compliance

Tenable has previously bloged about how change can be detected through log analysis. Network change can be detected many other ways, including scanning and passive network monitoring. This blog entry will discuss why detecting change is important to security and compliance, the different types of change that can occur on the network and how they can be detected with Tenable solutions.

Types of Network Change

You might think of a network as always being in motion. There are different users logged on, different traffic loads and over time, new services are supported by the network. Having discrete methods to detect certain types of change is extremely useful. Consider the following lists of potential changes that can occur on a network:

• adding a new server
• adding a new client or server application
• creating a new user account
• changes in a system's configuration
• changes in a system's network activity

Obviously, there are many more types of change than these, but the above list will catch a majority of changes that do occur. Each of these items can have dramatic ramifications for an organization's IT compliance or security postures.

Security and Compliance

Regardless if your organization follows ITIL, COBIT or some other form of IT management, any type of change which hasn't been authorized is against policy. If your organization allows undocumented changes as needed, over time, your network will become unmanageable since each system will likely have a very unique configuration.

This can also impact security by dramatically increasing the cost of performing system administration. If systems are not managed in a known state, then performing routine tasks like patch management can become very tedious.

Also notice that nowhere on the above list of "change" was detecting a new vulnerability. Very often, "new" vulnerabilities are discovered when they are disclosed, and Tenable's research team writes a Nessus or Passive Vulnerability Scanner plugin for them. The same exact system from the day before is now deemed vulnerable. However nothing really changed in the system except we have a more accurate test to enumerate a security issue.

Detecting a New Server

Tenable offers many ways to detect when a new system has been added.

Actively, subsequent Nessus scans can be used to identify new hosts. When managed by the Security Center, asset owners can be alerted after each active scan if there are any new systems. If the same system has been scanned several times, the Security Center will also track when issues surrounding it have been first seen, last seen and how many times they have been observed.

For passive alerting of new hosts, the Passive Vulnerability Scanner (PVS) will alert in real time if it sees a new host. When managed by the Security Center, all "new hosts" can be automatically placed into a dynamic asset list and scanned with Nessus once per day.

Detecting a New Client or Server Application

For active network scans, if the new application has listening daemons, Nessus will likely identify the system, or at least the presence of new open ports. All "server" applications have some sort of listening port which can be fingerprinted. The Security Center can alert individual asset owners when any new data, including new services and open ports, is discovered. Many "client" applications such as iTunes or eMule also have open ports which can be identified by a network scan.

Client and server applications also generate network traffic. This traffic can be observed by the PVS. At a minimum, if a system has not even browsed on a certain port in the past, the PVS will alert on this change. Typically, the PVS will identify the new application as it performs a handshake with its server or reaches out to the Internet for a potential self update.

If the Log Correlation Engine (LCE) is in use, Tenable has produced many normalization rules which detect when new client or server software has been installed or has been upgraded.

Detecting New Users

If a new user is added to an operating system, the Log Correlation Engine is able to parse these logs and gather them. Similarly, LCE rules exist to look for changes in user privileges. A variety of LCE correlation rules named TASLs are available. One in particular tracks active directory authentication requests along with DHCP queries and can alert when an individual user's MAC address has changed. Other TASLs can automatically learn any account used for most OSes (UNIX and Windows) as well as applications such as VNC.

With active scanning, Nessus is also able to list users on Windows operating systems, detect accounts which haven't been used and a variety of other types of information. 

Detecting Changes in a System Configuration

Nessus Compliance Checks can be used to audit UNIX and Windows systems against a known good policy. These checks look at user privileges, permissions of objects, file permissions and many different parameters including the content of UNIX and Windows configuration files. If there are any changes that violate an IT configuration policy, the next audit will highlight the issue.

The Log Correlation Engine also has the detect_change.tasl script. This script is constantly updated with new types of logs which indicate changes in users, changes in system configurations and software being added or removed.

Detecting a Change in Activity

The Passive Vulnerability Scanner constantly builds up a model of all systems on the network. For known systems, if it sees a new port being used for network browsing or a new port being used to serve an application, it will alert this new activity in real time.

The Log Correlation Engine also has a statistical anomaly engine that models all network and log events. This model includes frequency of events as well as internal, external and inbound connection activity. If there are statistical changes in any event (like web browsing) or connectivity (more connections between a server and a domain controller) it will log the anomaly.

For More Information

For more information on detecting change to look for compliance, IT management exceptions, and security incidents, please consider the following resources:

• Request a copy of Tenable's "Real Time Compliance Monitoring" paper.
• Read the "Security and IT Controls" blog entry
• Download a copy of the "Network Implications of Visible Ops" paper which discusses using Tenable products to monitor networks in an ITIL framework
• List of User and Compliance Monitoring TASL Scripts for the LCE

For more information on Tenable's products, please visit our web site, browse our "demos" page or consider pricing for the Direct Feed, Security Center, Passive Vulnerability Scanner or Log Correlation Engine.

Many UNIX applications and system settings are contained in proprietary text configuration files. Auditing these for unauthorized changes or configurations can be very cumbersome and time consuming. Nessus 3 Direct Feed and Security Center users have the ability to audit UNIX servers against a configuration policy without an agent. Being able to automatically prove that all remote systems and applications have a certain configuration setting or that they have not changed from a known good configuration has tremendous value for compliance monitoring and system management.

Today, Tenable released a UNIX utility named "Configuration to Audit" (c2a) which considers a text based configuration file and produces a Nessus 3 .audit file. The c2a tool can be used to quickly create .audit files suitable for Nessus 3 Direct Feed or Security Center users. These .audit files can be used to test for specific configuration file settings as well as MD5 checksums.

This blog entry discusses c2a tool usage and provides example use cases for Nessus and Security Center users with a Snort configuration file.

Creating an MD5 .audit File

Nessus can remotely audit many different aspects of a UNIX server. For our first example, we will audit the MD5 checksum values of three files on a demo system which runs the Security Center, Snort and the Passive Vulnerability Scanner. The configuration for each of these files are located here:

• /etc/snort/snort.conf
• /opt/sc3/daemons/daemons.cfg
• /opt/pvs/etc/pvs.conf

These file names are placed in a text file named files.txt and the c2a tool is run with the following results:

[root@megalon c2a]# ./c2a.pl -md5 -f ./files.txt -o test1_md5.audit
c2a.pl, v1.0 (conf to audit)
(c) 2006 - Tenable Network Security
Creating .audit file based on inputfile ./files.txt
Processing :/etc/snort/snort.conf
Processing :/opt/sc3/daemons/daemons.cfg
Processing :/opt/pvs/etc/pvs.conf

Finished creating .audit files based on ./files.txt
Please check test1_md5.audit for output.

The content of the test1_md5.audit file is as shown:

#
# This file is auto-generated with c2a.pl script
# Copyright 2006 Tenable Network Security Inc
#

<check_type : "Unix">

<custom_item>
        #System :       "Linux"
        type    :       FILE_CHECK
description     :       "Check MD5 for /etc/snort/snort.conf"
        file    :       "/etc/snort/snort.conf"
        md5     :       "823b28cbc726f68538abdb0451f29a01"
</custom_item>

<custom_item>
        #System :       "Linux"
        type    :       FILE_CHECK
description     :       "Check MD5 for /opt/sc3/daemons/daemons.cfg"
        file    :       "/opt/sc3/daemons/daemons.cfg"
        md5     :       "3403c4c155a94c4c915ac0b01d4a60dc"
</custom_item>

<custom_item>
        #System :       "Linux"
        type    :       FILE_CHECK
description     :       "Check MD5 for /opt/pvs/etc/pvs.conf"
        file    :       "/opt/pvs/etc/pvs.conf"
        md5     :       "3b4a4b0b7a3cdf7fa3aff3c54f5e6ad4"
</custom_item>

</check_type>

This .audit file can now be used within the Security Center or Nessus 3 to scan a UNIX system for their MD5 checksums of those three files. Here are screen shots of the test1_md5.audit file being loaded into a Nessus 3 Windows GUI, as well as passing results for a scan of the box with the correct MD5 values:

MD5 Audit Results	Loading UNIX .audit File

If a directory of files is required to be monitored, simply specify the directory in the list of targets given to the c2a.pl script. The c2a.pl script will recognize the entry as a directory and then recursively loop through each file and subdirectory and create a unique MD5 entry for each. For example, in the above files.txt, if we had added "/opt/nessus/etc", it would have created an MD5 value for each file in that directory.

Note on Solaris, the MD5 tool may not be installed by default.
 

Auditing UNIX Configuration Files

Most UNIX applications have one or more text configuration files. The c2a tool can be used to extract the variables when any existing configuration file, and then also make a second pass to extract the values for each variable to produce a UNIX .audit file.

Two passes are necessary because not all text configuration files have the same format. Some have different characters (other than "#") that indicate comments. Some  have a  "variablename =  value"  format while others have a "variablename value" format.

The c2a tool is ideal for processing configuration files that have unique line-by-line content. If your configuration file has multi-line functionality, such as an XML config file, c2a is not ideal.

The basic process to create a UNIX .audit file from a given configuration file is as follows:

1. Extract the variable names to create a variable mapping for the c2a.map file. This involves selecting a regular expression that will identify the variable names and their values and then running the cmv.pl tool to create a temporary map file.
2. Manually edit the temporary map file to avoid any variables that should not be audited and then append it to the c2a.map file.
3. Add in the regular expression you used with your map name to the c2a_regex.map file.
4. Add in the name of your regular expression and file name to the input.txt file.
5. Once this is all in place, create a UNIX .audit file by running the c2a.pl tool.

The resulting UNIX .audit file can be applied to any Nessus 3 scanner or Security Center installation.

NOTE: Please keep in mind that the easiest way to detect change is to get MD5 values of all your remote files, and then test for a new MD5 value. The c2a tools and Nessus can indeed look inside text files and see if certain value are set, but you should only be performing these audits if that is indeed what you require for an audit. We will now look at two examples with Snort.

Snort Configuration File Example

In the next two sections, we will generate some .audit files for a Snort IDS configuration file. Snort is a good example of auditing a remote system configuration file because it has a text configuration file and has specific settings that dramatically change the operation of the application.

This blog entry won't recommend specific settings for Snort (a good link on the subject is here though), but if your organization decides on a central set of configurations, the c2a tool can help audit them to ensure compliance.

Extracting 'var' Variables from a snort.conf File

Most Snort deployments install the configuration file to /etc/snort/snort.conf. Looking at the file, there are many settings which are specified with "var variable-name value" such as:

var TELNET_SERVERS $HOME_NET

We will start by extracting these variables and then move onto other snort.conf keywords such as 'preprocessor' and 'include'.

A regular expression to extract the variable names specified by the 'var' keyword in a snort.conf file is  '(var .+) (.+)'.  We can use the cmv.pl tool and this regular expression to create a SNORTVAR.map file and then add it to the c2a.map file as shown below:

[root@megalon c2a]# ./cmv.pl -r '(var .+) (.+)' -r SNORTVAR -f /etc/snort/snort.conf
[root@megalon c2a]# more SNORTVAR.map
SNORTVAR=var HOME_NET
SNORTVAR=var EXTERNAL_NET
SNORTVAR=var DNS_SERVERS
SNORTVAR=var SMTP_SERVERS
SNORTVAR=var HTTP_SERVERS
SNORTVAR=var SQL_SERVERS
SNORTVAR=var TELNET_SERVERS
SNORTVAR=var SNMP_SERVERS
SNORTVAR=var HTTP_PORTS
SNORTVAR=var SHELLCODE_PORTS
SNORTVAR=var ORACLE_PORTS
SNORTVAR=var AIM_SERVERS
SNORTVAR=var RULE_PATH
[root@megalon c2a]# cat SNORTVAR.map >> c2a.map

We must then add the regular expression used to create this map file to the c2a_regex.map file and create a line for SNORTVAR in our input.txt file as shown below:

[root@megalon c2a]# cat c2a_regex.map
HTTP=([a-zA-Z0-9_-]+) (.*$)
SENDMAIL=([a-zA-Z0-9_-]+)=(.*$)
SYSCTL=([A-Za-z0-9\._-]+) = ([0-9]+)
NESSUS=([A-Za-z0-9\._-]+) = (.+)
VSFTPD=([A-Za-z0-9_]+)=([A-Za-z0-9]+)
SNORTVAR=(var .+) (.+)
[root@megalon c2a]# cat input.txt
# Given below is a list default locations
# of audit files that will be audited by
# c2a.pl when -audit option is selected. If
# the default locations do not reflect the
# settings on your system, please edit the
# same

SNORTVAR=/etc/snort/snort.conf

Once this is all in place, we can run the c2a.pl tool and look at the initial part of the resulting snort-var.audit file:

[root@megalon c2a]# ./c2a.pl -audit -f input.txt -o snort-var.audit
c2a.pl, v1.0 (conf to audit)
(c) 2006 - Tenable Network Security
Processing SNORTVAR=/etc/snort/snort.conf


Finished creating .audit files based on input.txt
Please check snort-var.audit for output

[root@megalon c2a]# more snort-var.audit
#####################################################
# This file is auto-generated with c2a.pl script
# Copyright 2007 Tenable Network Security Inc
# Date: Fri Feb 16 16:33:31 2007
# User: root
# Hostname: megalon
#####################################################

<check_type : "Unix">

#############################################################
# List of values to be audited in /etc/snort/snort.conf
#############################################################

<custom_item>
        #System :       "Linux"
        type    :       FILE_CONTENT_CHECK
description     :       "Check if var HOME_NET entry in /etc/snort/snort.conf is correct. "
        file    :       "/etc/snort/snort.conf"
        regex   :       "var HOME_NET.*"
        expect  :       "var HOME_NET any"
</custom_item>

The full snort-var.audit file can be obtained here:  [Download snort-var.audit]

There is nothing special about this .audit file as it just audits the default "var" settings of a snort.conf file and is intended purely as an example.

Extracting 'preprocessor' and 'include' Settings from a snort.conf File

The snort.conf file also has other values. Many of these are settings for the Snort 'preprocessor' and also signature 'include' settings. Here is a short snippet of 'include' and 'preprocessor' settings for a typical snort.conf file:

• include classification.config
• include reference.config
• include $RULE_PATH/local.rules
• include $RULE_PATH/bad-traffic.rules
• preprocessor http_inspect: global \
• preprocessor http_inspect_server: server default \
• preprocessor rpc_decode: 111 32771
• preprocessor bo
• preprocessor ftp_telnet: global \

There are two things we need to realize now.

First, unlike the 'var' processing we did previously where each unique variable also had a unique value, with 'include' and 'preprocessor' we have the same keyword used over and over with different values. To capture the entire string, we will use some regular expression logic and then have the c2a.pl tool create a full snort-conf.audit file.

Second, those "\" characters in the snort.conf file mean there is a multiple lines for each keyword. For example, the 'http_inspect_server:' value actually looks like this:

preprocessor http_inspect_server: server default \
    profile all ports { 80 8080 8180 } oversize_dir_length 500

Since the c2a.pl script doesn't consider multiple lines, either the snort.conf file needs to be rewritten to take advantage of putting the settings on one line, or the auditor needs to realize that only one line can be audited.

The following steps show command line entires to create a snort.audit file which can test for all settings of a snort.conf file:

The regular expression '(^preprocessor (.+))' finds all snort.conf lines that make declare one of these variables. We place the entire regular expression in parentheses to tell the c2a tool  we want each line uniquely tested for.

[root@megalon c2a]# ./cmv.pl -r '(^preprocessor (.+))' -t SNORTPP -f /etc/snort/snort.conf
[root@megalon c2a]# more SNORTPP.map
SNORTPP=preprocessor flow: stats_interval 0 hash 2
SNORTPP=preprocessor frag3_global: max_frags 65536
SNORTPP=preprocessor frag3_engine: policy first detect_anomalies
SNORTPP=preprocessor stream4: disable_evasion_alerts
SNORTPP=preprocessor stream4_reassemble
SNORTPP=preprocessor http_inspect: global \
SNORTPP=preprocessor http_inspect_server: server default \
SNORTPP=preprocessor rpc_decode: 111 32771
SNORTPP=preprocessor bo
SNORTPP=preprocessor ftp_telnet: global \
SNORTPP=preprocessor ftp_telnet_protocol: telnet \
SNORTPP=preprocessor ftp_telnet_protocol: ftp server default \
SNORTPP=preprocessor ftp_telnet_protocol: ftp client default \
SNORTPP=preprocessor smtp: \
SNORTPP=preprocessor sfportscan: proto  { all } \

Notice in the above matches, some of the lines contain a "\" which indicates that the line wasa multiple-line entry in the snort.conf file. For 'include' lines, the same type of regular expression is used:

[root@megalon c2a]# ./cmv.pl -r '(^include (.+))' -t SNORTSIGS -f /etc/snort/snort.conf
[root@megalon c2a]# more SNORTSIGS.map
SNORTSIGS=include classification.config
SNORTSIGS=include reference.config
SNORTSIGS=include $RULE_PATH/local.rules
SNORTSIGS=include $RULE_PATH/bad-traffic.rules
SNORTSIGS=include $RULE_PATH/exploit.rules
SNORTSIGS=include $RULE_PATH/scan.rules
SNORTSIGS=include $RULE_PATH/finger.rules
SNORTSIGS=include $RULE_PATH/ftp.rules
SNORTSIGS=include $RULE_PATH/telnet.rules
SNORTSIGS=include $RULE_PATH/rpc.rules
SNORTSIGS=include $RULE_PATH/rservices.rules
SNORTSIGS=include $RULE_PATH/dos.rules
SNORTSIGS=include $RULE_PATH/ddos.rules
SNORTSIGS=include $RULE_PATH/dns.rules
SNORTSIGS=include $RULE_PATH/tftp.rules
SNORTSIGS=include $RULE_PATH/web-cgi.rules
SNORTSIGS=include $RULE_PATH/web-coldfusion.rules
SNORTSIGS=include $RULE_PATH/web-iis.rules
SNORTSIGS=include $RULE_PATH/web-frontpage.rules
SNORTSIGS=include $RULE_PATH/web-misc.rules
SNORTSIGS=include $RULE_PATH/web-client.rules
SNORTSIGS=include $RULE_PATH/web-php.rules
SNORTSIGS=include $RULE_PATH/sql.rules
SNORTSIGS=include $RULE_PATH/x11.rules
SNORTSIGS=include $RULE_PATH/icmp.rules
SNORTSIGS=include $RULE_PATH/netbios.rules
SNORTSIGS=include $RULE_PATH/misc.rules
SNORTSIGS=include $RULE_PATH/attack-responses.rules
SNORTSIGS=include $RULE_PATH/oracle.rules
SNORTSIGS=include $RULE_PATH/mysql.rules
SNORTSIGS=include $RULE_PATH/snmp.rules
SNORTSIGS=include $RULE_PATH/smtp.rules
SNORTSIGS=include $RULE_PATH/imap.rules
SNORTSIGS=include $RULE_PATH/pop2.rules
SNORTSIGS=include $RULE_PATH/pop3.rules
SNORTSIGS=include $RULE_PATH/nntp.rules
SNORTSIGS=include $RULE_PATH/other-ids.rules
SNORTSIGS=include $RULE_PATH/virus.rules
SNORTSIGS=include $RULE_PATH/experimental.rules

Both map files are added to the c2a.map file.

[root@megalon c2a]# cat SNORTSIGS.map >> c2a.map
[root@megalon c2a]# cat SNORTPP.map >> c2a.map

The SNORTSIGS and SNORTPP map names are added to the input.txt file:

[root@megalon c2a]# cat input.txt
# Given below is a list default locations
# of audit files that will be audited by
# c2a.pl when -audit option is selected. If
# the default locations do not reflect the
# settings on your system, please edit the
# same

SNORTVAR=/etc/snort/snort.conf
SNORTPP=/etc/snort/snort.conf
SNORTSIGS=/etc/snort/snort.conf

The regular expressions for SNORTSIGS and SNORTPP are added to the c2a_regex.map file:

[root@megalon c2a]# cat c2a_regex.map
HTTP=([a-zA-Z0-9_-]+) (.*$)
SENDMAIL=([a-zA-Z0-9_-]+)=(.*$)
SYSCTL=([A-Za-z0-9\._-]+) = ([0-9]+)
NESSUS=([A-Za-z0-9\._-]+) = (.+)
VSFTPD=([A-Za-z0-9_]+)=([A-Za-z0-9]+)
SNORTVAR=(var .+) (.+)
SNORTPP=(^preprocessor (.+))
SNORTSIGS=(^include (.+))

The tool is then run to produce a snort.audit file:

[root@megalon c2a]# ./c2a.pl -audit -f ./input.txt -o snort.audit
c2a.pl, v1.0 (conf to audit)
(c) 2006 - Tenable Network Security
Processing SNORTVAR=/etc/snort/snort.conf
Processing SNORTPP=/etc/snort/snort.conf
Processing SNORTSIGS=/etc/snort/snort.conf

Finished creating .audit files based on ./input.txt
Please check snort.audit for output

The resulting scan results with a Nessus 3 scanner look like this:

A PDF of the HTML report produced by Nessus 3 of the scan can be obtained here:

Download snort-audit.pdf

The actual snort.audit file generated for this demo is located here:

Download snort.audit

If you inspect the file, you will see several preprocessor entries which were the first part of a multiple line snort.conf entry.

Other Uses for the c2a.pl tool

Tenable has included several entries in the c2a.map and c2a_regex.map files to enable auditing of Sendmail, the Very Secure FTP Daemon (VSFTPD), Apache, the Red Hat /etc/sysctl.conf file and Nessus. More may be added in the near future. If you'd like to submit new mappings to Tenable to share with other Nessus users, please send them to nessus-support@tenablesecurity.com.

With that in mind, the c2a.pl script can be used to help create a Nessus .audit files for several live UNIX applications. Consider the following ideas:

• If your organization has many UNIX based firewalls, a .audit file can be generated to audit the common and required settings that each firewall is supposed to have.  For example, if all firewalls are supposed to have filtering of RFC 1918 addresses, the actual firewall rules can be tested for.
• If many different custom applications are being run out of CRON, the various CRONTABs can be audited to make sure that the right applications are being run at the correct time.
• For centralized logging, remote UNIX systems can have their SYSLOG, SYSLOG-NG and LOGROTATE configurations checked.

Manual Tweaking of the .audit files

Lastly, the output of the c2a.pl script  can also be manually edited. For example, consider combining the MD5 checksum rules with the FILE_CONTENT_CHECK rules into one rule.  The output  generated by the c2a.pl script also assumes that a configuration file is always in one place. Consider modifying the "file" keyword to specify other locations where a configuration file may be located.   

Lastly, if you have content that you don't want in your remote file configurations, consider manually adding in checks for that with the  FILE_CONTENT_CHECK_NOT keyword. This can help you perform audits for settings that should be present and should also not be present.   

Working with the Security Center

Although each of the above examples focused on direct Nessus usage, any of the .audit files generated with  the c2a.pl tool can be loaded into the Security Center's /opt/sc3/admin/nasl directory and then used to perform credentialed audits of remote UNIX system and application configurations. We've previously blogged about doing this with Windows UNIX checks and it is very similar for the UNIX .audit file audits.

For More Information

Anyone interested in learning more about the Direct Feed ($1200/year per scanner) can do so here. The Security Center ($15,750 for 500 systems) is available for the Red Hat operating system and can manage multiple Nessus scanners, perform configuration audits for compliance reporting, process network IDS logs and also manage multiple Passive Vulnerability Scanners and Log Correlation Engines.

In addition to auditing UNIX servers, Nessus 3 can also be used to audit Windows servers. To learn more about auditing Windows servers, please refer to these blog posts:

• Auditing Windows 2003 Servers for Disabled USB Drives and AutoRun CD-ROM
• Creating "Gold Build" Audit Policies
• Nessus 3 Agentless Compliance Checks

Tenable's 80+ page Real-Time Compliance Monitoring paper is available to current and potential customers and discusses for logging, network monitoring, vulnerability scanning and configuration auditing can help monitor PCI, SOX, FISMA, NERC and many other compliance standards.

Obtaining the c2a Tool

The c2a tool, and all other UNIX and Windows compliance utilities, plus many example .audit files can be obtained here.

The Nessus 3 Direct Feed was updated today with enhanced functionality for Windows compliance checks. This blog entry discusses the new features and has example .audit text to illustrate them, including a test case for the recent Microsoft update for 2007 Daylight Savings Time. These changes only effect Windows audits.

Multiple Potential Compliance Values for AUDIT_POLICY Items

Both the "value" and "value_data" keywords can now accept multiple values within an "AUDIT_POLICY" context. If any of these values are present in the audited system, then the system passes the audit. Values are separated with "|" characters. Here is an example for a simple built-in test as well as a custom item test:

<item>
  name: "Audit logon events"
  value: "Failure" | "Success, Failure"
</item>

<custom_item>
   type: AUDIT_POLICY
   description: "Audit logon events"
   value_type: AUDIT_SET
   value_data: "Failure" | "Success, Failure"
   audit_policy: AUDIT_LOGON
</item>

Both examples would pass a Windows server if auditing only logged login failures, or if logging of login failures and successes were performed.

REG_BINARY Support

A new value type of POLICY_BINARY is now available to test REG_BINARY registry settings. Using the regedit.exe tool, if you encounter a binary registry setting which requires testing, strip out the spaces and add it in to the "value_data" content.

Below is an example custom item for testing the application of the recent Microsoft 2007 Daylight Savings Time update. It uses a POLICY_BINARY setting to test for a value of "00 00 03 00 02 00 02 00 0000 00 00 00 00 00 00".

<custom_item>
  type: REGISTRY_SETTING
  description: "2007 Daylight Savings Patch Applied"
  value_type: POLICY_BINARY
  value_data: "00000300020002000000000000000000"
  reg_key: "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation"
  reg_item: "DaylightStart"
</item>

Service Checks support CAN_BE_NULL or CAN_NOT_BE_NULL Flags

Prior to this update, a "reg_option" value of CAN_BE_NULL or CAN_NOT_BE_NULL was only supported on Registry Setting, Registry Permissions, File Permissions, File Content Checks and File Content Check NOTs audits.

This release now supports a new optional "svc_option" tag with values of CAN_BE_NULL or CAN_NOT_BE_NULL for service policy audits. This is useful for cases where the lack of a service running doesn't violate being compliant, or specifying that a certain service has to be running.

Optionally Ignoring Access Control List Inheritance

This release also includes more flexibility when auditing access control list (ACL) inheritance. The following ACLs can currently be audited:

• file_acl
• registry_acl
• service_acl

Each of these can now contain an "acl_inheritance" value of:

• not inherited
• inherited
• not used

This can force an audit of a file, registry or service ACL to not care, if the actual list was inherited or to specifically state the ACL inheritance type.

Receiving The Latest Plugins

Security Center and Nessus 3 Direct Feed users should update their plugins after reading this blog to receive the new functionality. If your Security Center is performing daily updates of plugins, then a manual plugin update will be required if you wish to use the new functionality immediately.

For More Information

Anyone interested in learning more about the Direct Feed ($1200/year per scanner) can do so here. The Security Center ($15,750 for 500 systems) is available for the Red Hat operating system and can manage multiple Nessus scanners, perform configuration audits for compliance reporting, process network IDS logs and also manage multiple Passive Vulnerability Scanners and Log Correlation Engines.

To learn more about auditing Windows servers, please refer to these blog posts and webinar:

• Auditing Windows 2003 Servers for Disabled USB Drives and AutoRun CD-ROM
• Creating "Gold Build" Audit Policies
• Nessus 3 Agentless Compliance Checks
• Nessus Compliance Checks (webinar)

Tenable's 80+ page Real-Time Compliance Monitoring paper is available to current and potential customers and discusses for logging, network monitoring, vulnerability scanning and configuration auditing can help monitor PCI, SOX, FISMA, NERC and many other compliance standards.