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.

[Shivam Sarawagi · Accepted solution]

Hi,

Since, proof is dynamically changing you can remove proof from detection key.

You can either follow this KB to remove proof being one of the detection key https://hi.service-now.com/kb_view.do?sys_kb_id=e495b73e1b80a0103222ea89bd4bcbc8

or

You can use autoclose feature to close these VIs.

If this is helpful, please mark as helpful.

Thanks,

Shivam

[Matt Martin1]

Would you be able to share the steps in the KB?  I currently do no have access. 

Also have you seen any downside to removing proof from the detection key?

[Shivam Sarawagi]

Hi Matt, Can you reach to HI support? 

I don't see any downside except after upgrade you need to make sure its working

Thanks,

Shivam

[maulik_shah]

I would also like to mention that this issue was brought to our attention a few weeks back and we've confirmed this behavior with Qualys. We are looking to fix this issue by not using the proof as a unique key when closing the detections.

This fix will be available in our next release. In the meantime, you can use the workaround that Shivam has posted.

Thanks

Maulik