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

[AndrewP]

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

[lakshmin]

Hi Chris

We are using out of box rapid7 integration and have same issue . 

I want to understand more about on your fourth suggestion we have all Yes answers for this question but dont know how and why .Could you please explain what is the underlying reason for this and how to fix.

Im trying to understand what it means to have different detection keys and Proof

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). Yes Add "Detection Key" to the list view on the Detections list (related list). Are the keys different?  Yes Take a look at the Proof. Are they different? Yes If the answer is yes, then this is most likely the issue. Again keep an eye on the June Store release.

Thanks

Lann

[Chris McDevitt]

The short story is that SN VR takes metadata from the incoming scanner, concatenates them together to form a unique key for that detection.

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

Take a look at the DetectionBase script include as an example of how the key gets built:

I am a bit rusty on Rapid7 but on Qualys and Tenable, the "proof" that was being sent in was variable/dynamic and it changed between when it was first set to SV VR to when it was closed:

So, the keys did not match and because the keys did not match, SNVR treated it like a NEW detection and did not match it on the existing detection.

The quick fix is to NOT include the proof (this.VI_KEY_NAMES.PROOF) as part of the detection key.

Looking at the code.... around line 1010 it is looking to testing to see if it should be using a legacy key... I would need to see your instance to know more....

I would upgrade to the latest VR and Rapid7 releases. Then open a ticket to see why this is so if it is still happening.

[AndrewP]

Chris,

It looks like I was mistaken, with a closer look at "Proof" there often seems to be very slight differences such as an extra space or a repeated line, which likely changes the detection key. Is there a way to remove proof from the detection key algorithm, as I think data quality issues on this field are common?

Thanks,

Andrew

[Chris McDevitt]

Andrew,

Yes... but it is in Script Include...

When you change a SI it is skipped on all future updates and Support will ask you to revert the SI to the Store version if you have any issues... this is a big deal.

Also, changing this will leave orphans in the Detections table. You will need to Close the Detection (avoided deleting any production data). You will need to come up with a strategy to handle this.

Also, we can not totally predict how this will change in the very near future... you could potentially cause a bigger mess... so be warned.... 

So....

1. You will want to make the change to Detection and not DetectionBase

https://docs.servicenow.com/bundle/quebec-it-service-management/page/product/it-service-management/reference/customize-script-includes-itsm.html

2. You want to override the "initialize" function 

3. (Around line 74 from DetectionBase) you will need to modify it in Detection:

this._detectionKeysForId = [this.VI_KEY_NAMES.VULNERABILITY,
this.VI_KEY_NAMES.PORT, this.VI_KEY_NAMES.PROTOCOL,
this.VI_KEY_NAMES.ASSET_ID, this.VI_KEY_NAMES.PROOF
];

//remove -> this.VI_KEY_NAMES.PROOF

Test, test, validate and retest before promoting this change.

You will want to roll this back after the next release. Use the Versions Related List a revert back to the Store version.

Then Test, test, validate and retest.

[AndrewP]

Thanks Chris - I don't think we have another choice other than to modify the SI as our closed VITs are not closing in these situations. I would think that these items will receive a new detection# after the change that can be closed by a corresponding closed detection key when closed? 

I see the following code in DetectionBase. How would we update the Detection table? It only contains 3 lines that simply reference DetectionBase.

Thanks,

Andrew