CVE details list

The CVE list shows CVEs, and uses one table row per CVE. For vulnerability mitigation purposes this is not enough because you also want to analyse CVE distribution over individual devices. That's what the CVE details list is for.

The relationship between the CVE list and the CVE details list is similar to the relationship between the software products list and the software instances list. The software products list shows you all installed software products, and you can see where they are installed when opening the software product profile. The software instances list, on the other hand, lists software instances for individual devices. The same is true for the CVE details list: It shows vulnerabilities for individual devices.

Note that by default the CVE details list contains entries for mitigated vulnerabilities as well. If you only want to see unmitigated vulnerabilities, filter the "Vulnerable" column using the value "yes".

You can use the CVE details list as a vulnerability mitigation worksheet.

• By filtering the list, you can define a problem set that you want to use for a mitigation project.
• By saving a given scope and filter combination as a stored view, you can make that problem set / mitigation project easily accessible.
• By exporting the result set to Excel, you can easily pass it to coworkers and contractors who don't have access to Asset Center, or to auditors and regulatory authorities for documentation.

Note that the CVE details list also allows you to enter comments. This is particularly useful to provide additional information the following situations:

• You decide that a particular vulnerability is irrelevant for a result set and therefore set the Relevance field to "No"
• You mitigate a vulnerability using compensating controls, such as network segregation or application whitelisting and then manually set the vulnerability to "fixed".

Note that you can use bulk edit to edit multple entries at once.

A useful feature is to use tags for filtering your CVE details list. You can assign tags to CVEs in the CVE list. This allows you filter for other characteristics in the CVE details list than just the table columns. For example, if you have already filtered the CVE list for all CVEs that affect Google Chrome, and assigned a tag to those CVEs, you can then use that tag to filter the CVE details list as well.

Defining and executing mitigation projects via saved views

Just like in the device inventory, you can save a given filter setting as a "view". This is particular useful for the definition and execution of mitigation projects where you and your team set out to mitigate a particular set of vulnerabilities. In order to save current filter settings, click on "Manage Views". Then use a catchy name and decide if the view shall be private or public.

You will now be able to revert to your saved filter settings by simply selecting the view from the drop-down next to "Manage Views".

And it even gets better. You will also get a graphical representation of your saved view in the "Timeline" tab where you can see how vulnerabilities covered by a given view develop over time.

This is particularly useful for tracking progress of your mitigation projects. Let's say, for example, that you have set up a project that aims at getting rid of vulnerabilities associated with Adobe Flash Player -- by simply removing the dreaded software from devices. The graphs in the timeline tell you how well you are doing. You will see a timeline for

• Number of affected devices -- these go down because we have simply removed Flash Player from a couple of devices, hence the number of affected & vulnerable devices dropped.
• Number of vulnerabilities -- these went down accordingly because with Flash Player removed, many vulnerabilities no longer exist. Note that this number may well be much higher then the number of devices, because software products such as Adobe Flash carry multiple vulnerabilities.
• VScore -- this is the cummulated CVSS base scores. This number contains a bit more information than the plain number of vulnerabilities, because not all vulnerabilities are equal. If the vulnerabilities you have eradicated are particularly bad, you will see a much larger decrease of the VScore than in the number of vulnerabilities.