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

This blog entry marks the 200th post for this blog. I've been very pleased with the content we've created for our Nessus users and customers. The feedback I've received is that the content here is useful to information security practitioners from all walks of life.

Tenable recently released Nessus plugin #30000. This means that there are roughly 20,000 plugins (although some have been retired) in the current archive. Raw counts of vulnerability tests are very deceiving, however we feel very strongly that crossing this plugin ID count is a milestone worth noting.

We try to be very open about which checks are available by providing a public RSS feed of new plugins, dynamically listing the unique count of CVE and Bugtraq IDs addressed and by allowing the public to search our plugins database. We've also provided detailed advanced notice of changes to the plugins database such as when we moved our severity scoring algorithms from CVSSv1 to CVSSv2. We have also provided an in-depth statistical analysis of the types of plugins available.

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.

Tenable Network Security's research group recently introduced support for credentialed patch auditing of SuSE Enterprise 9 and 10 for both the Server and Desktop editions. Plugins which support patch auditing of these operating systems have been available to Registered Feed, Direct Feed and Security Center users since late 2007. All plugins are published as part of the SuSE Local Security Checks Nessus plugin family.

In addition, patch auditing of AIX 5.x and 6.x is also fully supported through the AIX Local Security Checks plugin family. Customers parsing AIX logs collected with the Log Correlation Engine can now also make use of new updates which analyze login and system activity. These normalized events automatically feed into the automatic statistical event profiling and event correlation of the Log Correlation Engine.

Recently, Tenable Network Security introduced Nessus plugin #29871 which looks at the content of a web site to see if it is hosting potential hostile javascript code. There have been several recent mass defacements and infections of 1000s of web sites through SQL injection attacks. Plugin #29871, named "Web Site contains links to malicious javascript files", specifically checks web sites for links to the "uc8010.com" addresses used in this recent wave of infections.

When performing CGI scans, Tenable recommends several strategies:

• By default, Nessus will only mirror 200 pages for a scanned site. If your site has more pages than this, you should increase this value to a relative amount.
• Plugin #29871 is dependent on the webmirror.nasl script so this plugin (#10662) should either be enabled, or the test should be performed with dependencies enabled at runtime.
• If you are scanning web servers that run on ports other than 80 or 443, be sure to include these in your scan policy.

Tenable also introduced a plugin for the Passive Vulnerability Scanner (#4334), which also detects web sites that are hosting this type of content based purely on traffic analysis.

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

The Nessus Client 3.0 introduced a new format for Nessus scan policies, targets and results. This is known as the ".nessus" format. This blog entry discusses the advantages of this new file type and includes links to recently published technical documentation about the format and layout of the file.

Unified Scan Targets, Policy and Results

Historically, Nessus daemons and clients supported various file formats for scan configurations as well as scan results. When Tenable designed the new file format, we wanted to unify these into one file. This allows for rapid and accurate reproduction of a previous scan as well as understanding what a scan was looking for to begin with.

For example, if you only enabled FTP checks and performed a scan, you should expect to get information about FTP security issues and not SSH or Internet Explorer issues. You also shouldn't conclude that there aren't any SSH or Internet Explorer issues because your FTP scan didn't find any, but this is exactly what a variety of NAC and SIM vendors do. We're hoping that the unified .nessus format will make working with the scan results easier.

Multiple Scan Policies

Multiple scan policies can be specified within one .nessus file. This can help identify different scan settings for different portions of a network. It can also make it very easy to publish "standard" scan settings for your consultants, auditors and IT administrators.

For example, Tenable recently released a SANS Top 20 2007 policy which included individual policies for each unique area of concern identified by SANS. I've spoken with several Tenable customers and Nessus users that are using  .nessus policy files to standardize on remote scans of external networks and to scan servers and applications before they go into production.

Credential Management

The Nessus Client also won't save credentials for a scan policy unless a user specifically checks the 'Save credentials in clear text' option. This is a feature which was added in version 3.0.1 of the Nessus Client.  If you wish to share polices among multiple users which include credentials to audit systems, you must enable this option. Otherwise, the Nessus client won't store the credentials in the .nessus file.

Integration with the Security Center

Customers who use the new Nessus Client 3.0 along with the Security Center can upload their results centrally. Security Center 3.4 (scheduled for release early this quarter) has the ability for any user to upload their Nessus scan results. This allows for remediation tracking, secure sharing of scan results, automatic asset discovery, report creation, vulnerability/IDS event correlation and many other features. It also makes it convenient for corporations to centralize scan results from networks which may be physically separated.

Technical Reference

Tenable has produced a technical reference for programmers who wish to develop tools to parse and analyze Nessus results. This document describes each section of the .nessus document format.

Publishing Scan Policies

If you wish to author and publish your own Nessus scan polices, consider following these guidelines :

• Do not publish credentials in your policies unless you specifically need them.
• Name each sub-policy something informational and that can be grasped by a new user easily.
• Include a description for each policy.
• Minimize your policy such that it is purposeful. For example, if you don't need a certain family, disable it.
• When placing your policies online for other Nessus users, consider compressing them with both ZIP and GZIP so that Nessus users on different platforms can easily obtain them.