AnsweredAssumed Answered

How are you assigning remediation work and allotted remediation time (Qualys vs Another tool)?

Question asked by Jake VanMast on Jan 25, 2019
Latest reply on Jan 29, 2019 by derekv

Requesting a little market research into how other Qualys customers are handling 1-3 below:

(1) assigning vulnerability remediation

(2) setting the timeframe to remediate in (based on severity or risk), considering first open, or reopen cases.

Do you use Qualys functions for these purposes, or something else?


Additionally (3) do your business processes have a single owner for all vulnerabilities on the host, (ie. including the OS level patching, database, storage, or common apps/tools like MS office, Adobe, Java, etc)?  If so, does that one team do all patching, or do they use some specific tool to coordinate with the teams that do the work?




Below are some details about how we are trying to accomplish 1-3 in our environment...


For the last year we have been attempting to use the power of Qualys Dynamic Search lists, (and the Asset Group/Tag inventory already configured within Qualys), to accomplish both assignment to remediation teams, and to set the remediation "Due Date" (different time frame for sev4-5 vs sev2-3 issues).  Qualys Remediation Policies accomplish this task to some degree, although we are facing problems in the following areas.  Discussions with Qualys indicate most customers are unable to use Qualys to accomplish either of these tasks, so looking for a few details on how other companies do this, and what tools they use.



(a) Reporting, including Assignee and remediation Due Date:


We assign work via reports (either CSV file, or CSV file loaded into Splunk).  Qualys VM Remediation Policies provide the ability to both assign remediation work (we have a Qualys "user" per remediation team, used only for reporting), and assign a "Due Date" based on some combination of host asset(s) and QID (in our case filtered also by severity, to specify shorter remediation times for higher severity issues).  They create Remediation Tickets with Assignee and Due Date attributes, which can be manually changed where functionality is not present (see #c & #d below), or business processes changed/etc dictate.


However, we cannot find any native support for generating detailed reports with these attributes (specifically "due date"), and additionally no way to generate detailed reports by "assignee" value.  (Ticket State seems to be the only Remediation Ticket attribute present in the VM Scan Report details).


Therefore about a year ago, using the Qualys API, we re-implemented Qualys Scan Report, plus a few additional fields [assignee, due date, ticket ID, last remediation policy name], and generate these reports regularly via a specific subset of "assignee" values. 



(b) Reporting using API + Cisco (caveat for above)


One large headache with the above solution is the Qualys APIs don't seem to support Qualys' Cisco implementation.  With any other OS, having the vendor supplied workaround in place (eg CLI config to disable feature, or etc) does not result in a confirmed/red vulnerability.  However for Cisco, all vulns are confirmed/red based upon the OS version only, but Qualys also gathers device config (QID=45229), to use in special Exclude due to config or non-running service features of native reporting.  However, the Qualys APIs seem unable to Exclude Cisco vulnerabilities based on vendor supplied workaround.



(c) Assignment via vendor/product:


The vendor/product values for QIDs containing CVE-ID seem pretty consistent.  However QIDs without CVE-IDs (obsolete software, "best practices", etc), or sometimes regular OS patching, often have "product" field as "none".  This makes it difficult to assign vulnerability remediation by product; consider common vendor=Microsoft products like:  MS Windows OS, MS SQL, MS Office, etc.  Additionally mistakes or inconsistencies with vendor/product/category values are typically not fixed due to already being published.  This leaves creating Dynamic Search lists filtering on QID "title" strings (with no regexp support), or manually changing the resulting Remediation Ticket assignments after the fact.


We are currently attempting to split different applications between different remediation groups (OS, database, storage, standard apps, special apps).  We are facing some unsolvable issues due to inconsistent KnowledgeBase data, and to a lesser extend pain points due to limitations on the Remediation Policy rule functionality itself (no way to combine AND/OR logic, no "excludes", etc...).  Therefore we are considering changing our business processes based on tool limitations to have a single asset owner (and then assign based on asset(s) instead of QID attributes), however wanted to check how other companies handle this.



(d) Assignment via Layer4 address (eg TCP Port)


Qualys vulnerability reporting doesn't provide running service, so it is often necessary to use the port that the service is attached to for assignment.  However Qualys Reports can’t filter (include/exclude) by port value, and Qualys Remediation Policies cannot assign by port value.


For an example, consider the TLSv1.0 vuln can apply to RDP/3389 & ssh/22 (OS level), MSSQL/Oracle (databases), or apache/tomcat (application), etc…  In our organization these are different remediation/patching teams.



Thanks for reading this, would appreciate any comments or best practices you could recommend based on what works in your environment.