Separating multiple detections out of VI without Port

[Aaron Molenaar]

Out-of-box there is a Vulnerability Response configuration to consolidate (or not) multiple detections of a vulnerability on the same device based on different ports. In other words, if the same CVE is detected on a device on multiple ports it can be one or many VI.

Has anyone dealt with the same issue, but where the differentiator in the detections is file directory or registry key, but there is not port value? We have run into a number of situations like log4j jar files in different applications (hence in different directories) belonging to different application teams, or multiple java installs in different directories belonging to different teams. These are all ending up as a few (or dozens) of detections in a single VI.

There isn't an OOB was to separate these into multiple VI to distribute to the separate application teams that need to work on these. It is very confusing trying to direct teams to work on these in serial, one after another, not to mention inefficient.

Any suggestions? It probably doesn't matter but we are using Rapid7 as the scanner with OOB integration.

[andy_ojha · Accepted solution]

Hey there - great summary of this dilemma.

You will want to check out one of the updates to the Store Apps here (VR, Rapid7):

• https://docs.servicenow.com/bundle/utah-security-management/page/product/vulnerability-response/conc...
• I would imagine that the Proof from R7 in this case, likely should align to separating out the reg keys, file paths as you mentioned in most cases hopefully 

-------------------------------------------------------------------

Full transparency - I have not actually used this new feature, but figured to respond with this in case you have not seen it yet, as you may want to explore or include in your upgrade plans to consider.

One concept that might be a bit confusing - there is the concept of "Keys" in play here in VR

You might hear / see reference to this across Docs 

Detection Key

• This is the "DNA" or specific values that make up a unique detection 
• This might include elements such as Proof, Port IP - see Docs page here for more info
• Think of the scenario where multiple findings are reported from the vuln scanner, Detection Key is what controls de-duplicating Detection records, and also ensuring that previously imported Active Detections are appropriately closed later on when the scanner reports they are fixed (Close the open Detections, do not create new Fixed ones) 

Vulnerable Item Key

• This the "DNA" or specific values that make up the unique Vulnerable Item 
• This might include elements like the Host, Vuln, Port, etc.
• This would be what controls when a unique VI is created - and in turn, where Detections end up when they are imported (i,e. with more granularity, you will have more VIs)

They are not the same but sometimes easily confused
 - As you pointed out with VI Port Granularity, that applies to the "Vulnerable Item Key" - i.e. what makes a single VI
 - The feature mentioned above for R7 Proof, would be adding it (optionally) to the Vulnerable Item Key

[John Gregory]

This is great functionality, its a shame its not available for Tenable as well as we have a definite issue when one vulnerable item contains different proofs.