Reopening of Closed VIs by the VR System

Patrik Z · ‎01-19-2022

Hello,

a client has several VIs that have been reopened by the VR System after being Closed so I'd just like to ask about the following scenario that occurred:

VI is Deferred by a user
VI is Closed (Substate is Fixed) by VR System
Detection Last Found is updated
VI is Opened by VR System (I assume based on the update of the Detection last found date)

And my questions are whether that's how it's supposed to work OOTB? I mean, shouldn't a new Detection record be created instead of updating the old one?

Also, they don't like a Closed VI to be reopened - what is reopening the VIs, I'd say it's the scanner (they use Qualys) but could it be something else?

Thank you in advance, guys.

Patrik

joe_harvey · ‎01-19-2022

Hey Patrik,

On their own, VR's reaction to each scanner result seem reasonable:

A VI is Closed when the scanner indicates that it has been remediated
A Closed VI is reopened when the scanner indicates that the situation exists again

The end result is frustrating, a VI that should be Deferred ends up as Open. This is probably an edge case that will not happen very often but you can request an enhancement if you feel it is warranted.

The code where VR makes the determination on reopening a VI is in Script Include DetectionBase. Basically, if the VI State/Substate is Closed/Fixed or Closed/Stale or Resolved, it is reopened.

Regarding the question of creating a new VI vs. reopening the existing one, you can probably make a case for either option. I think that having all of the detections in one VI may help to keep track of the Close/Reopen cycle and help figure out why it is occurring.

I hope that this helps,
--Joe

View solution in original post

Joe Kline · ‎11-16-2023

Hey everyone,

This has been a point of contention for us as well. Our approach was that one of my developer team mates customized the Detection/DetectionBase scripts to look for existing, not yet expired change approval records, sorted in a descending order when there are multiples ... then utilize the one with the farthest out Until date to force the reopen into a Defferal state instead of Open. Not very clean, and not what I would recommend fully to anybody else, as it still has its own issues.

We use Qualys for the scanning and have considerable few QIDs that will actually toggle open/close when the Agent scans versus when the remote network scans run; making the re-open even more frustrating.

I thought there was some mention of a release notes item suggesting that out of the box fixes the re-open to use a deferral if one exists. I have not investigated that much as of yet, because we so totally over-customized the way we do Defer to start with.

joe_harvey · ‎11-16-2023

I believe that this issue was resolved v18.0.2. Release Notes for that version contains this text under "Changed":

The “Deferred to” date on records remains populated until you manually reopen the record.
If you reopen a deferred VI prior to the time limit for a manual exception, the VI is automatically deferred.

Release Notes for that version are near the bottom of this page: https://store.servicenow.com/sn_appstore_store.do#!/store/application/054cdcc2ff200200158bffffffffff...