Vulnerability groups

Chuck S1 · ‎08-15-2019

Does anyone have a recommendation and / or best practices on how to group, categorize or define Vulnerability groups recieved from Rapid7. I am trying to reduce the number of groups and auto assign vulnerability items as they are received in ServiceNow.

Chris McDevitt · ‎08-16-2019

Chuck,

"... I am trying to reduce the number of groups and auto assign vulnerability items as they are received in ServiceNow...."

I would recommend that you do not focus on reducing the number of groups. I recommend concentrating on accurately assigning the vulnerability groups to the correct teams for remediation.

The first thing you need to consider is "Assignment Rules (AR)." AR run and decide which assignment group to set on the Vulnerability Item(VIT). Think about how you want to assign the VIT's and then make sure you have a "default" rule that catches things that do not match your parameters. The rules run or order lowest to highest, and the first match stops the run.

Moving on to Vulnerability Grouping Rules(VGR). First, take a look at "Group by". You have five keys to play with, (Really Four, because you always want to keep the first key as Vulnerability) you have thee basic and two advanced keys. Typically, I see people wanting to group vulnerabilities that are most impactful to the organization. For example, the next keys could be: priority, active threat, external-facing asset, PCI, etc. (you will dot walk from the VIT to these other items).

Once that is done, you need to consider filtering ('Limit vulnerable items') on the same VGR. For example, you may want a positive and negative filter: '~items that contain PCI' and then '~items that DO NOT contain PCI'.

The goal is to get a very focused VG to the team who can take action AND know which VG to act on first.

Go ahead and smash that correct or helpful button!

-Chris

View solution in original post

leosequeira · ‎08-15-2019

Hi Chuck - VGs should be created based on how your remediation teams actually take in work/patch/remediate systems. A common way (not be confused with the term best practice) is to group by Vulnerability and Vulnerable Item Assignment Group using VG rules. When you use VG rules to create VGs you can quickly scale the creation on insert. In the VG rules you can select the Vulnerability as a key and then the vulnerable item as another key and if needed a third key. Some orgs simply remediate based on business services (assuming they have that mapped out with business services) and don't use Vulnerabilities as on of their keys. This is not a wrong way, it's just how they remediate their vulnerabilities. Whether or not it comes from Rapid 7, Tenable, Qualys, etc. has no effect on how you create VGs. You should start with how your organization actually remediates the vulns, how do they break them up and work them, that'll be your start. Hope that helps.

Chuck S1 · ‎08-17-2019

Thx. Well noted

SanjivMeher · ‎08-15-2019

We usually group name based on Application.

For example, if we receive 2 million vulnerabilities with qualys host, we find out their parent application and application owner and group them based on the Application.

We create Group Rules, where you have option to specify on which parameter you want to group.

It will mostly depend on your response team, how would they like to respond to the vulnerabilities. Some people may do it based on location, some based on operating system, some based on node type etc

Please mark this response as correct or helpful if it assisted you with your question.

ESkogquist · ‎09-22-2020

Interested in how you determined the "parent application". Currently, I only see the application referenced in the vulnerability.summary. Getting at each unique application is a pretty manual task. Curious if there's a field in Qualys we are overlooking which would hold the parent application.