Fixed Vulnerable Items are not changing to closed status even after detected closed/fixed by Qualys?

AndrewP · ‎05-05-2021

I am finding multiple vulnerable items that are remaining in Open status, even after Qualys no longer detects them. The Vulnerable Item Detection (DET#) shows them with a Status of Closed and a Source Status of Fixed, however the VIT# still shows as Open.

I believe the logic needed to update is in DetectionBase (QualysHostImportReportProcessor > Detection > DetectionBase). I have seen mention of Detection, but the bulk of the logic is in DetectionBase.

We are using VR version 12.1.4

Chris McDevitt · ‎05-06-2021

Hi,

First up, avoid customization to the Scripts Includes like the plague.

Second, keep an eye on the June Store release of VR and upgrade. (but if you customize the VR SI then it is much harder to upgrade....).

Third, take advantage of the "Close Stale Vulnerabilities"

https://docs.servicenow.com/bundle/quebec-security-management/page/product/vulnerability-response/task/vr-autoclosevi.html

And Auto delete rules:

https://docs.servicenow.com/bundle/quebec-security-management/page/product/vulnerability-response/task/enable-auto-del-vi-vg.html

Fourth,

Take a look at the VI's that are not closing. Drill down into the Detections. Are you seeing one Detection closed and another open? (one or more). Add "Detection Key" to the list view on the Detections list (related list). Are the keys different? Take a look at the Proof. Are they different? If the answer is yes, then this is most likely the issue. Again keep an eye on the June Store release.

It is hard to remote diagnose.... so...

View solution in original post

AndrewP · ‎05-06-2021

Hi,

The state field does not appear to be flipping between closed and open, just stays open.

The most common scenario is, there is usually a first Open Detection with a status of Open and source status of Active. Then a second Closed Detection with a status of Closed and a source status of Fixed (when the vulnerability gets patched). Sometimes there are 2 or 3 open detections followed by a closed detection, but the overall VI state remains Open.

We are fairly new to VR and have not customized much, so this is a bit alarming.

Thank you!

Ashutosh Munot1 · ‎05-06-2021

HI,

I agree with Chris. The detections drive the VI states. So if proof and key is different then it will cause issue. We are currently facing this as well. We are solving this with our Tenable team.

Auto deletion and Stale rules are of great help because the Retired CIs in ServiceNow and the open VITs are pain for the support teams. So this rules are of big help to get this resolved. We have discovery in place and last found date is used from tenable to mark the VIT close using this rules.

Thanks,
Ashutosh

AndrewP · ‎05-06-2021

Thanks for the information! Proof is always the same for our detections, but the detection key is different. Would this be the cause of the issue?

I agree auto deletion and stale rules help, but these are not short time periods for us due to requirements.

Thanks,

Andrew

Chris McDevitt · ‎05-06-2021

The detection key:

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

Detection key

"A hashed combination of fields that provided a way to identify and tie a detection to a vulnerable item. It is composed of: vulnerability entry, port, protocol, discovered item, and proof."

Ports are you splitting on Port?

https://docs.servicenow.com/bundle/paris-security-management/page/product/vulnerability-response/task/vr-configure-vi-key.html

AndrewP · ‎05-06-2021

Thanks for sending the docs Chris,

It seems maybe we need detection keys for a open and closed item to be the same? Some of our detections (both closed and open) have the same values across the board, with the exception of Times Found. Also we do not have a field for vulnerability entry or protocol. We also have blank values for Integration Instance.

We are not splitting on Port. I understand this makes our VIs more granular.

Thanks,

Andrew