Reporting Vulnerabilities in an IT Managed Environment

If you are performing some sort of vulnerability monitoring program or audit, you are most likely finding a large volume of information. Making sense of this information and presenting it to other users who may be less technical than you (or at least less familiar with the vulnerability discovery process) can be a challenging task.

However, knowing which systems are "supposed" to be updated on a regular basis can help simplify your message when reporting vulnerability findings. This blog entry discusses how knowing if the hosts you are scanning are or not "managed" and what this can mean for a vulnerability report.

What Does it Mean to be Managed?

A very simple and narrow answer for this question is that the system is patched and configured as per a network policy. For example, a Windows 2003 server should have all patches installed within 15 days of the patch being available and accept configuration settings dictated by a Windows domain. A different organization may have a different time period for patches, may want to manually set their own configurations with a commercial agent and so on.

I've spoken with other organizations who feel that to "manage" a device, it must have an agent on it. Solutions from Tivoli, CA, BMC, .etc. can be used to control software distribution, system settings and patch application for entire networks of servers and desktops. So for a network that is trying to manage everything with a specific technology, they may feel their managed systems all "have an agent" on it.

The bottom line, is that each organization will have their own definition of what it means to have a system under "management".

Automatic Discovery and Classification

Using a tool like Nessus or the Passive Vulnerability Scanner (PVS) to gather information and vulnerabilities about a network can yield clues to see if a system is indeed managed or not. Each network will have its concept of what a managed device is. Here are some examples:

• Actively, Nessus can ask Windows hosts which domain they are part of.
• Passively and actively, Nessus and the PVS can identify various types of management agents.
• With credentials, Nessus can itemize a list of all software installed on each Windows and UNIX host.
• Also with credentials, the very fact that Nessus can log into a UNIX or Windows host means that someone is managing a password and/or access control policy.
• Nessus can also make use of the compliance checks to log into a host and verify the presence of custom asset registry keys that might be placed there for inventory control.
• The Passive Vulnerability Scanner and Nessus may also identify hosts that no one is aware of. 

Consultants and analysts manually working with raw vulnerability results can group lists of IP addresses that seem to be managed for the environment they are working with. On smaller networks, manually identifying hosts and what their management profile is isn't a small task but is certainly doable. Users of Tenable's SecurityCenter can use this vulnerability data to automatically classify network nodes into managed and un-managed devices depending on the criteria for the local network.   

Reporting the Issues

When working with the vulnerability data, there are really two themes that need to be reported:

• non-compliant managed devices
• devices that are not managed but should be

Reporting Vulnerabilities on Managed Systems

Rather than reporting raw numbers of vulnerabilities, the number of critical holes, which once are exploitable, .etc, it can be more constructive to say something along the lines of:

"We have X hosts under management that are fully patched every Y days. To verify this, we performed an independent patch audit with Nessus and only found vulnerabilities that were less than Y days old."

Of course that sounds too perfect, but it makes much more sense than continuously scanning with the latest vulnerability checks in an environment that doesn't patch that quick.

Tenable does a very good job of keeping Nessus and the PVS up to date with the latest vulnerability checks (available in the Direct Feed). If your organization is always one or more weeks behind in patching, by policy, then testing with the latest checks isn't really telling you much.

The real value of a vulnerability audit in a managed environment is with detecting older vulnerabilities on "managed" devices. In this case you not only have a vulnerability that has been around long enough to be exploited, you also have evidence of a policy violation. We've blogged before about why patch management systems can fail.

The important thing is to find these sort of issues so that IT can rectify their process and to not bury these older and perhaps fewer vulnerabilities in a set of statistics. For example, imagine having 1000 Windows 2003 servers, one of which isn't getting patch updates. A scan on "Patch Tuesday" might show 1001 vulnerabilities, one new vulnerability for each host and 1 extra vulnerability for the server that isn't being patched. An IT manager who's not aware of that the 1000 new vulnerabilities will get fixed shortly won't focus on that last system that isn't getting updates.

SecurityCenter users know they can filter discovered vulnerabilities by Nessus ID (Tenable releases them in order, so older vulnerabilities have older checks) as well as when the vulnerability was first seen or last seen on the network for each host. When combined with asset management, it is very easy to report on managed hosts that have older vulnerabilities. Non Security Center users can still manually apply these concepts to their Nessus data for reporting.

Reporting Vulnerabilities on Unmanaged Devices

When identifying a device that do not seem to have a function or be part of the patch or configuration management process, an analyst quickly crosses into the political nature of IT security. Tracking down what the system is, who owns the system and what it is used for can be a daunting task.

Being able to scan a system like this to discover open ports and vulnerabilities can help escalate an effort to discover what it is. Being able to say that you've found a unknown Linux server with older versions of Apache, Sendmail and Secure Shell on it is more interesting that just saying that you've found an unknown Linux server.

As these "unmanaged devices" are discovered and understood, they can be reported on separately. Ideally these devices will become managed so that they do not have to have special attention given to them. Having an IT management team that understands where there devices are and in what state they are is more useful than raw vulnerability counts.

For More Information

Users who want to audit their networks with the latest checks should consider the Nessus Direct Feed (now called ProfessionalFeed). The plugins produced by Tenable are immediately available whereas the Registered Feed is a seven-day delay. If you are auditing your patch process with the Registered Feed, by default, it is giving you false negatives for the latest checks, especially on days like "Patch Tuesday".

Readers who liked this article will also like these previous blog entries:

• Testing the Effectiveness of your Patch Management System
  
• Security and IT Controls