In Vulnerability Response, how do you handle non-persistent VDI's?

[Egide]

We have a large number of non-persistent VDI's. This is causing our Discovered Items matching percentage to suffer, what is the Service-Now best approach in handling non-persistent VDI's?

Additional notes on how VDI's work:

In VDI, a hypervisor segments servers into virtual machines that in turn host virtual desktops, which users access remotely from their devices.

Users can access these virtual desktops from any device or location, and all processing is done on the host server.

Users connect to their desktop instances through a connection broker, which is a software-based gateway that acts as an intermediary between the user and the server.

[Chris McDevitt · Accepted solution]

Hi,

Right now, I think you need to solve this issue by improving your internal process.

Is there a reason that you are scanning VDIs? I think I would only launch VDIs in a certain subnet(s) then I would exclude all scanning from those subnets. Except for a handful of IPs that would only represent all VDIs. (Repeat as necessary)

So, if you think about it, each VDI is a clone from a single image.

What is really needed is that the VDI image build/validation/maintenance process would scan a single host, that is well defined, and is owned by the VDI image build team. If you find a vulnerability, the image needs to be fixed.

The latest VR release now has "Container vulnerabilities". A specialized container vulnerability scanner really reports the issue on the container image, because that is what needs to be fixed. VDI can be thought of in the same manner.

I think this is a source data issue, don't scan each VDI..... which at its base/root is a duplicate issue.

Ideas In order of goodness 🙂

• Limit VDI's to their own dedicated subnet(s)
• Don't scan all VDIs (just a sample one or one per image)
• Filter out VDI on your Scanner
• ----- OOB VR relm -----
• Set Auto-Close rules aggressively in SV VR for VDI's
• Set Auto-delete rules aggressively to delete the VI
• ---- Customization relm -----
• Clean up the host from the CMDB
• Clean up Discovered Items

[Egide]

This was very helpful @Chris McDevitt, thank you for sharing your expertise!

[Joe Kline]

@Chris McDevitt would you mind elaborating just a bit on your two Customization realm items?  By clean up are you suggesting that records be deleted, ot to what level are you suggesting?

Thanks much,

Joe

[Chris McDevitt]

@Joe Kline 

Here is what I thinking:

1. Identify DI that don't have a VI

https://gist.github.com/cmcdevitt/84306ab24ebfcc94bf2c19a6e3e4b8c4

2. Flag those DI (i.e. a 'No associated VI' T/F field)

3. A Business Rule that runs and Retires their Associated CI (based on step 2)

-- Use Status AND Life Cycle State/Status fields

4. Using Auto-Delete Rules (Auto Flushes) delete these DI and CI objects in the future.

-- Based on Step 3 + time

-- Go slow and understand when data is no longer relevant to your organization

--- Remember: Retention Policy (if any) and wisdom of your peers (i.e. when do most people agree the data becomes stale)