Creating a Baseline for Nessus Configuration Auditing

The only thing that is constant is change, and yet the one thing that most humans resist at some level is change itself. But when it comes to IT systems or machines in general, we observe the exact opposite behavior: IT systems change all the time. Software applications get added, accounts get deleted, new configuration policies replace old ones, and permissions get revised. A myriad of events happens during the typical lifecycle of a system, triggering many changes. It’s so common that you would be hard pressed to find a system that hasn't changed over time.

Before you can start tracking change, you first need an acceptable baseline

Change is good, especially if it leads to better, stricter and more accountable compliance policies. But untracked changes can result in absolute chaos if those changes are not well-documented and communicated to employees. This is especially true in tightly regulated industries such as healthcare and finance.

Tracking change against a baseline

Before you can start tracking change, you first need an acceptable baseline or a reference point to compare with ongoing activity. Without such a baseline or reference, there is no way to know if your system configurations are any better than yesterday. That baseline could be a CIS or DISA STIG guideline, or even a configuration policy that you developed internally for site-specific needs. Until recently, developing such a baseline with Nessus involved customizing Tenable supplied audit policies, which could involve a steep learning curve, depending on the level of customization required.

Creating a gold standard in Nessus

When Nessus users customize .audit files, they are often trying to get a policy file to match a reference target, commonly referred to as a gold standard. That target could be the initial default image used for production deployments, or something that was painstakingly configured with attention to each individual setting.

Wouldn't it be great if you could just point Nessus to such a model system, capture all its relevant settings, and use it to audit all the other systems in your environment to make sure that they align with the reference system? Well now you can. With the release of Nessus 6.3, compliance plugins support a new feature that enables Nessus users to create a baseline reference audit file.

Nessus 6.3 compliance plugins now support the creation of baseline reference audit files

At a high level, the process involves three simple steps:

1. Configure a target server to your organization's internal requirements, or choose a target that closely resembles those compliance requirements.
2. Run a scan against the target server to capture the results/settings from the target.
3. Use the results file (.nessus) from step 2 to create a new reference .audit file to audit other servers.

Example workflow: CIS server compliance auditing

Let's assume your organization follows CIS standards for your Windows workstations, but you have a business or legacy application that will not operate under these restrictions. So you introduce certain compensating controls, have Nessus mark those expected deviations from the standard as PASS, and create a new baseline.

Here’s how the typical workflow would work:

1. Pick a target server (or a range of targets) that is in compliance with your organization’s requirements.
2. Select an .audit file with a comprehensive list of settings to audit. For example, use the CIS/DISA STIG audit file.
3. Run a scan with the audit, and capture the .nessus results file. Most likely, there will be some failed results.
4. Create a new baseline reference .audit using the .nessus file (using the Tenable-supplied nbin script).
5. Run the scan with the new reference .audit file. Most configuration checks should now pass. 

For example, here’s a scan with a stock CIS Windows 7 Audit file, scanned before capturing the .nessus file (step #3 above). Notice that there are 144 failures:

Compare that scan to a later scan, done with the new reference .audit file (step #5 above). Notice that the failures are now gone:

How does it work?

We developed a new Nessus nbin script to create a baseline reference .audit file from a .nessus file. You can find details about the script in the Discussions Forum.

In the background, the script works by leveraging the "Known Good" feature by comparing the system values to values in the .nessus file and flags them each as PASS. For more details about how the "Known Good" feature works, see the Discussions Forum message on that subject.

Here’s how the result would look if the reference values didn’t match:

Making your life easier

The ability to create a baseline reference audit file is now available for all Nessus compliance plugins. But this is just a small step towards further innovation in configuration and compliance auditing. Watch this space for more new features as they become available.