I personally don’t use ticketing systems integrated in VM solutions. I think it’s hard to explain IT guys why they should use yet another ticketing system for patching tasks only additionally to their main Jira or whatever they use (see “Vulnerability scanners: a view from the vendor and end user side“).

But I assume that for some companies this feature may be useful or even critical.

Anyway, it’s always nice to see how the vendor works with vulnerability data to get some ideas for own ticketing procedures (see “VM Remediation using external task tracking systems“).

In F-Secure Radar you can create tickets at “Vulnerabilities” tabs. Here is the a whole list of detected vulnerabilities (filtered by CVSS > 8 by default).

You can filter them by family mane, vulnerability name, host, scan group, severity (CVSS), etc.:

And then choose some vulnerabilities and create a new ticket:

Ticket attributes: name, description, deadline, assigned user, priority. This ticket may be assigned to a F-Secure Radar user.

Here is our new ticket and some filtering options (by assigned user, ticket status and deadlines):

This user may change statuses of vulnerabilities, for example mark it as already patched or false positive.

Available ticket statuses (New, Accepted, Test, Invalid, Fixed, Duplicate):

After the ticket is fixed, related hosts may be rescanned.

I wanted to check, what if the host won’t be available during the rescan. I switched off virtual machine and started rescan task.

As you can see, F-Secure, visualize that vulnerabilities has gone (-10 -15 -3 -6).

Is this behavior correct? In my opinion, it’s not. I prefer to see the proof, that the host was scanned normally and the scanner didn’t detect vulnerability there because applications version changed. That’s why I prefer to code this logic for myself using raw vulnerability data and don’t use standard ticketing systems and dashboards.

However, F-Secure Radar has pretty advanced ticketing options. A it’s nice that you can manage it automatically using the API.