Vulnerable Item Detection

[Matt Martin1]

We have seen an issue with an end-user not being able to close a VI because of multiple detections being listed on the VI.  From the documentation it states:

Detections are only opened or closed by data that is found by a scanner, they do not roll down from VIs. As Detections are imported, they are used to create VIs and update the states of VI​s. If all detections are closed for a vulnerable item, that vulnerable item will be closed. On the VI record, the state is closed, and the substate is fixed.

When all VIs are closed for a VG, the VG is closed.

All of this makes sense and has been working as expected.  However, there is a case where the user is not able to close the VI.  The VI was created for a specific QID from the Qualys integration with the detection on that day.  There was only one detection on this VI for about a week.  Part of the detection's proof from Qualys indicated the version of ubuntu running.  At the time the user was not working on remediating the vulnerability but updated their system and had a newer version of ubuntu.  The vulnerability was still valid and being found on the device.  After the device was updated and integration was ran from ServiceNow with Qualys a new detection was populated under the VI since the proof/results was updated.  This new detection had the same first found date, and all other information was the same except for the part of the proof showing the version of ubuntu.  The original detection was left in an open state and the new detection was then put in an open state.  The user then remediated the vulnerability and a scan confirmed the vulnerability as fixed.  The second detection that was created closed as expected.  However, the VI was not able to close because the original detection was left in an open state with no way to confirm from the scan.

It appears ServiceNow might be using proof as a unique key in the detection.  If so, should this be true.  There are vulnerabilities in Qualys dealing with versions of software or operating systems involved.  This version is often shown in the proof/results of the detection.  If the user is multiple versions behind and updates their version, but to one that is still vulnerable, the proof/results only update in Qualys and do not create a new detection.  Is anyone else seeing this similar behavior or is this as expected?  How would you suggest a user go about closing the VI since the original detection won't close from a scan and integration run? 

Thanks.

[DC_SNOW]

Did this fix ever get released into the next release from when this issue was raised?  I believe we may be potentially seeing this issue today.

[Shivam Sarawagi]

Yes, this is already released in the product. If you have applied this KB fix you have to revert the Detection script include to OOB. Also, check table sn_vul_detection_key_config. You should see an entry here for Qualys and if the status is pending then you have to run the scheduled job "Fixing the detections for updated key for Qualys".

https://docs.servicenow.com/en-US/bundle/sandiego-security-management/page/product/vulnerability-response/concept/vr_host_detections.html

A hashed combination of fields that provided a way to identify and tie a detection to a vulnerable item. Starting with v14.0 of Vulnerability Response, detection keys are integration-specific.

Detection key configurations

Scanner	Vulnerability	Port	Protocol	Asset ID	Proof
Qualys	Yes	Yes	Yes	Yes	No
Tenable	Yes	Yes	Yes	Yes	No
Rapid7	Yes	Yes	Yes	Yes	Yes (it is not case sensitive)