Close/Defer Workflow Question

Jimmy26
Giga Contributor

Hello, I'm currently working on developing some reports for any VI or VG that was subject to the "Close/Defer" button. In doing that, I noticed that depending how a VI or VG is marked as closed, it may or may not be reflected within the table known as sysapproval_approver. With that being said, could someone explain why certain closures are not reflected in the table? Are these closure options really more intended for VR admins as opposed to regular users? Also does anyone have the dictionary definition of each close/defer option? For example, I am confused on the intent of the Close > Cancelled options....no entirely sure why a VI or VG would be cancelled.

 

The following Closure types to do not show in the table known as sysapproval_approver

VIs: Close > Cancelled

VIs: Close > Fixed

VGs: Close > Cancelled

VGs: Close > Fixed with exceptions

1 ACCEPTED SOLUTION

andy_ojha
ServiceNow Employee
ServiceNow Employee

Hey there - sounds like you might be still be working with Vulnerability Response, older than v10.3.

Baseline (v9, v10.0), the approval workflow will trigger whenever a user requests any flavor of Defer from the Vulnerability Group:

  • The reason is, when a user requests to Defer a Vulnerability Group -> that will impact the states of the associated Vulnerable Items for all flavors of Defer

The same is not true when requesting to Close a Vulnerability Group:

  • When a user submits a request to Close the Vulnerability Group, the flavor they choose, will determine if an approval is generated
  • This is because, only some flavors of Closed, actually impact the states of the associated Vulnerable Items

To summarize:

 

Closed Flavor

Impacts Assoc. Vuln Items?

Requires Approval?

Result Invalid

Yes

Yes

Cancelled

No

No

Fixed w/ Exceptions

No

No

 

Deferred Flavor

Impacts Assoc. Vuln Items?

Requires Approval?

Awaiting Maintenance Window

Yes

Yes

False Positive

Yes

Yes

Fix Unavailable

Yes

Yes

Risk Accepted

Yes

Yes

Mitigating Control in Place

Yes

Yes

Other

Yes

Yes

 

In VR v10.3 the False Positive flavor has changed:

https://docs.servicenow.com/bundle/orlando-security-management/page/product/vulnerability-response/c...

View solution in original post

5 REPLIES 5

andy_ojha
ServiceNow Employee
ServiceNow Employee

Hey there - sounds like you might be still be working with Vulnerability Response, older than v10.3.

Baseline (v9, v10.0), the approval workflow will trigger whenever a user requests any flavor of Defer from the Vulnerability Group:

  • The reason is, when a user requests to Defer a Vulnerability Group -> that will impact the states of the associated Vulnerable Items for all flavors of Defer

The same is not true when requesting to Close a Vulnerability Group:

  • When a user submits a request to Close the Vulnerability Group, the flavor they choose, will determine if an approval is generated
  • This is because, only some flavors of Closed, actually impact the states of the associated Vulnerable Items

To summarize:

 

Closed Flavor

Impacts Assoc. Vuln Items?

Requires Approval?

Result Invalid

Yes

Yes

Cancelled

No

No

Fixed w/ Exceptions

No

No

 

Deferred Flavor

Impacts Assoc. Vuln Items?

Requires Approval?

Awaiting Maintenance Window

Yes

Yes

False Positive

Yes

Yes

Fix Unavailable

Yes

Yes

Risk Accepted

Yes

Yes

Mitigating Control in Place

Yes

Yes

Other

Yes

Yes

 

In VR v10.3 the False Positive flavor has changed:

https://docs.servicenow.com/bundle/orlando-security-management/page/product/vulnerability-response/c...

Ojha, Thank you so much for the detailed explanation. Yes we are on 10.0.4 at the moment. Can you give me some clarification the impact of certain Closed flavors? I'm looking at the example of Cancelled not having an impact against vulnerable items but at the same time it looks like it really does have an impact in that now its marked as closed without any validation or approvals (See below image). My fear is simply users abusing this feature to just get VIs of VGs in a closed state for a brief period.find_real_file.png

andy_ojha
ServiceNow Employee
ServiceNow Employee

Hey there - agree on this flavor of Closed not being the most operationally friendly choice.

To ease some of the concern, when a user sets the VG to [Closed / Cancelled], this does not transition the States of the associated VIs (and does not require an approval).

One thing to keep in mind, as the third-party scanner reports vulnerability detections back into Vulnerability Response, our Vulnerable Items should be transitioning to respective States.

- Would need to check this out for Tenable IO - but if you have a Closed Vulnerable Item (as Cancelled), and run your import again -> does it get set back to 'Open'?
 - This should occur with the "Open/Reopened" job when identified vulnerabilities are brought into ServiceNow

It is a common ask to disable the 'Cancelled' option for {Closed}.

The UI Page called "review_request" is what controls this:
- Alternatively you could look at adjusting which Reasons are available for the "Closed" State (and hide Cancelled)

Thanks for the response. I tested the state inheritance concept with a VG and yes you are correct it does not replicate to the associated VIs. It an interesting concept, but I'm perplexed why that logic is in place but at the same time it does provide some ease with my concern about abuse of the feature.

I also performed the VI check you mentioned and it sort of does open back up. For example, I marked two VIs as close/cancelled and then kicked off two scheduled jobs as I have mine separated based on severity. As a result of the scheduled jobs completed, I noticed that my Critical VI opened back up but my Medium VI did not. From what I gauge, I suspect that this is happening due to when the asset was maybe last scanned and the defined date on the scheduled jobs.

 

With the above in mind, I think I will be try to limit what the normal users can select from within the close drop down. It will likely be everything that does not go through an approval process.

 

Thanks again for your input. Its refreshing to hear to good advice.