Once you have your vulnerability data, how do you remediate?

I need to facilitate a process where our scan results are sent to the relevant support teams, and we expect feedback about whether the vulnerabilities will be addressed, or justification as to why they should not be mitigated (such as compliance with legacy systems or other measures which reduce the risk to an acceptable level). If we agree with their recommendations, then we either need to filter that out in the future, or at least mark them as exceptions.

CSV is probably the most useful format in that you can easily manipulate the data. However, if we allow the support teams to comment on individual entries, what happens with the next report? Merging the data from the previous result and taking into account new, re-opened and fixed vulnerabilities gets quite complicated and potentially cumbersome.

I also looked at the Remediation facility, which would allow us to comment on tickets, but the functionality appears limited and does not have the flexibility for reporting like the vulnerability data.

It is important that this process is quick to import new data and easy to use, and ideally does not require the use of other risk management products which I am unlikely to be able to get the support teams to use. Excel is acceptable!

Can anyone out there relate to my challenge and let me know how they handled it?

One suggestion might be that if the remediation team provides a request to exclude a particular vulnerability and the security team agree, then the specific vulnerability can be set to "ignored" in Qualysguard. When doing this there is a free text field available which you could use to record when the request to ignore was filed, by whom and its justification. Then although the vulnerability will still be picked up during VM scans it will be ignored in automatic scan reports and remediation ticketing.

You would likely also need to produce a "Ignored vulnerabilities" report on the relevant asset groups and this is a very tidy way to present the information for periodic review.

Sounds like you’re looking for an automated way to merge each support team feedback columns from the previous report into the next report you’ll be sending out. E.g. look for the quid & IP address from each of the feedback comments on previous reports and update the latest report. I would think this depends on the type of comments the support team make... The individual support teams should take responsibility and management of remediation of devices after you send the report. You would have to ensure the policy is setup, all devices are being scanned that you want and that the right support team get their vunls. If support say something has been remediate and it appears on the next report then it needs to be looked at again which will age the vulns. Also might be useful to setup a targeted scan request to a specific IP where support teams can request a scan after they apply remediation to audit, this helps the support team and will help keep vulns down. Feedback - support teams should only be allowed to feedback on anything needing exceptions or be re-assigned to other support teams (not the correct device owners). You may already have exceptions process in place. The csv report will need updating by hand e.g removing approved exceptions, re-assignments; it also depends on how things are organized within your company.

What "Security World" describes makes sense, and it does depend on your own role responsibilities. Is it your role to flag vulnerabilities to system owners, or are you actually responsible for remediating?

Perhaps you only need to concentrate on ensuring that Qualys scans all required devices, that reports are in an acceptable format to remediation teams, and that requests to those teams are resolved or acknowledged within a certain timeframe?

I have managed this process for a large company on spreadsheets before. It can be quite cumbersome unless you are willing to do some automation with Excel or Access macro's.

I have even seen some perl scripts written to help manage these things. Keep in mind, this is just keeping track of data, and just like any other data, there is always a way to do it depending on how much work you want to do.

I've seen that you don't really feel you can use a 3rd party tool at this time so I will respond based on that limitation.

Here are some things that can help.

Keep a master list of what teams own which IP's or IP ranges.

Have a "notes" or "response" field for the customers to respond back to you.

You can add a "documented" (or similar) field to spreadsheet or csv file to document if the finding is a false positive etc.. That will also let you filter on that in the future.

If you are willing to write some macro's or scripts you can keep track of the findings based on the IP address, vulnerability title, (and port if available) as a "key" to that finding.

Keeping track of a unique finding that way will let you do scan1 vs scan2 comparisons with scripts or macros and merge or join the data together for comparisons.

Otherwise you may just have to compare the scans manually. If you are dealing with low volumes you could look at manually creating tickets in your ticketing systems for the teams to work for the findings.

Apologies in advance as I'm trying not to create a "sales-ish" comment on a community forum. This was one of several issues we ran into while I was CISO at Orbitz. Because of a lack any existing solution we opted to track this primarily in spreadsheets. Admittedly it wasn't the cleanest or easiest solution to maintain.

While I'd be happy for you to check us out as a way to automate this, there are some things you can do on your own with some scripting and the Qualys API to try to address this. You might want to pull the data into your own spreadsheet or database and place it on a share. You could use this to document your flagged exceptions, who accepted it/owns it and any other custom fields you may need. From there you could write a script to push updates to Qualys via the API to mark that vulnerability as "ignored". In essence you're begining to create a 'source of truth' for your vulnerbility data. The other advantage to doing this is, you can start using this to collect other vulnerabiity data that may have been found by other tools, or manual proceeses as well.

I'd be more than happy to discuss this further, it's sort of a passion of mine. ;-)