Skip to content ↓ | Skip to navigation ↓

In Part 1 of this series, we looked at some of the metrics that an executive team would want to see to identify how the business risk is trending. It is very important to keep in mind that if the business does not see the information security program as effective and efficient, they will not continue to invest in information security projects.

In this part, we will look at the operational level reports that can assist in focusing efforts to reduce the risk to the business.

Operational Vulnerability Reports

An alarming yet common trend among organizations is to run a report that contains all the vulnerabilities under a particular system-owner and send them a very large report. Some organizations have matured beyond this point to provide reports that include everything with a “High” score. The main question then becomes: what defines a high-scoring vulnerability? To answer this, security analysts have typically said anything that is a CVSS 7 or above should be remediated. The PCI standard, for example, says that a CVSS score of 7.0-10.0 is High, 4.0-6.9 is Medium, and 0.0 to 3.9 is Low.

In common practice, system administrators have said that there are far too many vulnerabilities that are a CVSS score of 10 and above to remediate within a reasonable time frame. Depending on the organization, system administrators are committed to remediating anywhere from one to ten vulnerabilities per month. So the first question they pose to the security analysts is: which of these CVSS 10 scoring vulnerabilities is the most severe?

The Tripwire Vulnerability Risk Score alleviates this problem. By providing specific details about the ease of exploit, the privilege gained, and the age of the vulnerability, security analysts have a simple, objective answer to provide to system administrators. In some cases, based off of these factors, a vulnerability that has a CVSS score below 10 might pose more of a risk to the organization than a vulnerability with a CVSS score of 10.

System administrators, depending on the organization, will channel their remediation efforts on a per-host basis or on a per-vulnerability basis. If they would like to target per-host, we can provide a report, such as the one below, that shows the top 10 most-at-risk hosts.

Each one of these hosts can then be investigated further to show the top vulnerabilities along with their remediation details. Below is an example of the top 10 vulnerabilities within the highest scoring host from the above report along with a subset of the remediation information of the highest risk vulnerability within that report.

If the system administrators would prefer to channel their remediation efforts on a per-vulnerability basis, we can look at the reports based on the vulnerability risk score to see the top 10 most severe vulnerabilities within the organization.

One of the most common frustrations for information security analysts is false positives in the data. When the data collected cannot be trusted, the system administrators lose confidence in the analyst and the solution providing the data. While no solution is perfect, it is important to be able to provide evidence for each detected vulnerability. In many cases, just because a patch is applied, it does not necessarily mean that the vulnerability is remediated. In these cases, sometimes a reboot is required or a vulnerable file needs to be manually removed for successful remediation of the vulnerability. Below is an example of the detection evidence that Tripwire provides for each vulnerability.

Here we can see the specific rule that was run, at what time, and what information was gathered. In this particular example, a specific registry key was missing that should have been applied.

0-Days and Application Licensing

There are many cases where a 0-day vulnerability is announced and specific vulnerability detection coverage is not available. In these cases, information is provided to show which version(s) of the application(s) are affected. Using Tripwire reporting, a new scan does not necessarily need to be run to identify which systems are vulnerable. A simple report can be run to show how many of each version of the application is running using the most recent scan data. Below is an example of a report that shows how many hosts are running what versions of Adobe applications.

Similarly, this data can be used to determine software license counts for applications such as database instances across the organization.


Vulnerability and risk management is an ongoing process. The most successful programs continuously adapt and are aligned with the risk reduction goals of the business. The process should be reviewed on a regular basis, and staff should be kept up-to-date with the latest threats and trends in information security. Ensuring that continuous development is in place for the people, process, and technology will ensure the success of the enterprise vulnerability and risk management program.

It is not uncommon for an organization to have a very high average vulnerability score with lengthy remediation cycles in the initial stages of building the program. The key is to show progress month by month, quarter by quarter, and year by year. The vulnerability risk scores and time to remediation should be decreasing as teams become more familiar with the process and become more educated on the risks that the attackers pose.

If you have enjoyed this article, you can read our Vulnerability Management Buyer´s Guide here.