VRM Application Behavior - False Positive Closure | Reopen of VIT | Best Practice on SLA

[VIVEK ANAND]

Version: Orlando

1. VIT or VUL is tagged as Closed Manually and reason for closure is a false positive. What will happen in the next Vulnerability Import?   Will the system re-open the manually closed item or it doesn't do anything?
2. VIT is remediated and Vulnerability Scanner acknowledged the remediation and the VIT is marked as closed by the system automatically. How will the system behave if the same vulnerability is identified after a few months?
3. What is the best way to track SLA at the group level considering the vulnerability Deferment scenario? i.e. At VIT level once the target is set by the remediation rule system doesn't really change it when your VIT deferment gets approved. What's the best way to make SLA not get breached? What's the best practice suggested by ServiceNow?

[VIVEK ANAND]

My understanding of those questions are,

1. VI will not be reopened by ServiceNow. Manually closed as false positive is a one-time activity. Next import will not create a new VIT or reopen an existing manually closed VIT inside ServiceNow
2. VIT will be reopened automatically 
3. OOTB Remediation target is just a one time rule. A scheduled job sets it. At VUL earliest target from VIT will be set as a remediation target, this is done via a scheduled job. The confusing part is how do we consider deferment and prevent SLA breaching at the item level and Group level?

[Chris McDevitt]

@VIVEK ANAND 

First,

The VIT table is not derived from the Task table. So, this means that SLA's do not work on non-task tables. The VUL table is extended from the Task table so, you can run and SLA on that.

Second,

Remediation Target is only set once, they do not pause. They stop only when the VIT is closed. The Remediation Target is just that a Target. 

So... you can run an SLA on the VUL that can have a pause condition based on the States of "In Review" or "Deferred" and restarts if Opened. Measure at the group and not the item level. 

Go ahead and mark this as helpful or correct.

[VIVEK ANAND]

Hi Chris,

Thank you very much for responding.

Yes, I agree and I am aware of the task table extension at VUL and VIT is a standalone table not extended from the task.

We already have SLA running at the VUL level. I see a challenge and I find it weird based on the OOTB behavior of the application.

Initial Configuration: I had SLA which starts when a VUL is created and it stops when VUL is closed or gets deferred. 

I saw few drawbacks in this configuration,

1. When the user selects 5/10 VI tied to a VUL and creates a Change, the system automatically creates a NEW VUL. This triggers a new SLA (basically a new breach time at the VUL)
2. OOTB we give the option to remediation owners to create a VUL manually and can tie your VIT under that VUL. (as VIT can be tied to multiple VUL) - But this action again triggers a new SLA at the VUL level and it didn't make sense.
3. Split Group option also creates a new VUL and this again triggers a new SLA

Current Configuration: After brainstorming we felt its good to make use of the remediation target date at the VUL as a breach date in SLA and we use our traditional SLA to breach on the remediation target date.

This solves all 3 issues I highlighted above but still, I am not convinced on the below factors,

1. SLA trigger is a one-time activity. Remediation target at VUL level can change if I manually bring a VI which has much lesser or earlier remediation target date into the VUL.
2. I can go for deferment, this means SLA needs to pause. It won't pause in this case. We found a scheduled job that clears off the remediation target field at the VUL level - This is good. But the customer calculates SLA at the item level (As the group doesn't always give you proper numbers) SLAs are always number games and its consistent when its looked at from a VIT level. All ServiceNow dashboards OOTB looks at VIT level SLA adherence - so customers thought process is aligned with industry best practice but I don't see functionality in to align this OOTB.

@Eric Feron @Chris McDevitt @Shiva Thomas @Alex Cox  - What do you suggest?

[VIVEK ANAND · Accepted solution]

Target Rules conditions were set to exclude VIT deferred state. This automatically removes the deferment date and deferment status field. Doing this helped to resolve the above issue. 

Just posting the details here to make sure it helps others. 

Thanks!