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.

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: 

A new feature was introduced with the latest update to the Nessus web server (2.0.0) and Flash interface (build 20100913A) to provide "exploitability" information to the user. Each plugin now contains a field that indicates whether or not a publicly-known exploit for the vulnerability exists:

The value will either be "True" if an exploit exists or "False" if an exploit is not publicly known. Nessus checks select sources for the presence of an exploit and updates this field accordingly. I purposely chose a "Medium" level vulnerability for this example, as exploits do not only have to be associated with “High” level alerts. In the above case, the vulnerability is a denial of service condition for NTP (Network Time Protocol), which just happens to have an exploit publicly available.

Metrics that show risk are an excellent way to communicate security information to different people and groups within an organization. However, trend lines can hide a lot of details and nuances. This blog entry discusses an example network where a month’s worth of scan data is used to trend overall vulnerabilities, those that have been around longer than thirty days and correlating systems needing a reboot with residual security issues.

One of the advantages of Tenable’s suite of Unified Security Monitoring products is that continuous vulnerability monitoring can be used to find reintroduced security issues. Vulnerabilities that were once mitigated but are now back again represent process and organizational issues that must be handled differently. Simply reporting the vulnerability again and waiting for it to be patched does not address the fundamental flaw in the process. This blog entry discusses how recurring vulnerabilities are detected, some of the reasons why they may be recurring and how you can track and report on them with Tenable’s SecurityCenter.

Your organization's network is a never-ending source of vulnerability information. New systems and applications are constantly being added, making the job of consistent vulnerability identification and risk management difficult. Tenable provides several tools to assist in this process. Nessus, combined with the Security Center, can provide detailed information about the vulnerabilities in your environment. The problem that many administrators face is that they are not always successful in getting management to recognize problems and provide resources for remediation. This blog post describes some tactics I have compiled over the years to help expedite this process.

I get the chance to speak with many different types of customers and potential customers. I am particularly interested in how they want to monitor and report on their network activity. I am frequently asked what type of metrics can be tracked for upper management. Trending charts are very popular, but what goes in them can be deceiving. Let’s consider some examples.

When you perform vulnerability discovery via network scanning, passive network monitoring or patch auditing, the discovered vulnerabilities can each be classified if they were newly discovered, or if they were previously known about. If you have historical vulnerability data, such as with the Security Center, you can also classify vulnerabilities that have been previously known about, but were somehow mitigated or are no longer present. In this blog entry, I will discuss a variety of ways to analyze new vulnerabilties, and to also analyze how vulnerabilities are being mitigated.

Many IT security managers I speak with want to produce some sort of graph or statistical data that records the amount of security incidents occurring on the network. This data is used to not only inform management of business risk, but to also justify budget for ongoing security and compliance activities. In this blog, we will consider several high-level sources of "incident data" and discuss their relevance for tracking in the enterprise.

I get this question from Nessus users and Tenable customers very often. They want to know if they are scanning too often, not often enough and they also want to know what other organizations are doing as well. In this blog entry, we will discuss the many different reasons why people perform scans and what factors can contribute to their scanning schedule.

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.