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_harvey · ‎03-22-2022

A Idea has been posted to request a fix to the issue of Vulnerable Items incorrectly transitioning from Deferred > Closed > Open: Vulnerability Response: Reopened Vulnerable Items falling covered under Vulnerability State Change A...

Please upvote it if you have a desire to see that issue resolved.

Wojciech Werysz · ‎10-06-2022

was it fixed?

Raghu6 · ‎08-22-2022

We are facing the same issue, VR.system flipping the status from Deferred to Closed and then Open again causing confusion to the VR analysts , did anybody find the resolution or a fix for this?

Any help appreciated.

QM_SSJ4 · ‎08-24-2022

We also have this issue. The best workaround we've found is to create an adhoc VUL(s), add the needed VIT's and then defer the VUL cascading the deferment down to the VIT's. If their is already an appropriate VUL, you can re-open the VUL and then re-defer it for the same effect. Only slightly better than going thru each VIT and deferring them. This does need to be fixed and seems relatively easy task to have a nightly job to check the VUL/VIT linkage and ensure the same state is in place.

Another idea to upvote

Vulnerable Items that are Deferred then Closed then reopened should honor the active Exception

Aaron Molenaar · ‎11-16-2023

Hi all,

Our team is also looking for a solution to Deferred VI getting closed by VR action (appropriately) then getting reopened by VR action (appropriately) but in an Open state instead of the preferred Deferred state, since it previously was deferred and Remediation Task in which it was deferred is still active and still in a deferred state. The system does not create a new Task like if the original task was closed, nor does it put the VI back into the state it was pre-closure (which would be Deferred). It puts the VI in Open state in the original - and still deferred - task. This logic does not make sense to me.

I've tried searching for other community notes on this, but none are clear solutions, or links referenced in them are broken.

Any thoughts from anyone on a solution?

Thanks,

Aaron