VR - How to manage "Unclassed Hardware" CIs

[Zach N]

In Vulnerability Response, how do you manage the Unclassed Hardware [cmdb_ci_unclassed_hardware] table?

In regards to VR integrations with third-party tools, ServiceNow automatically creates CIs on the Unclassed Hardware table when a CI is unmatched (this is part of the Discovered Items process). Vulnerable Items are created with this temporary CI until a proper CI is matched (when a reconcile job runs for example). However, after a CI has been matched, the temporary CI remains on the Unclassed Hardware table.

This is creating issues as some of our Event Management alerts are matching to these unclassed CIs. I'm curious what others have done to manage this table? Do you regularly clean or delete unclassed CIs? I've been unable to find any official documentation on this.

Right now we only have 20 Unmatched Discovered Items, but the Unclassed Hardware table has around 900 CIs.

EDIT (06/27/22):

I ended up implementing Chris's idea via a script include and scheduled job. I have the scheduled job set to run daily. Seems to be working pretty well for now. Thanks for the idea Chris!

Script Include:

 var VulMgr = Class.create();

 VulMgr.prototype = {

     initialize: function () {},

     retireUnclassed: function () {

         try {

             var unclassedItems = new GlideRecord('cmdb_ci_unclassed_hardware'),
                 count = 0;

             unclassedItems.addQuery('install_status', '1');
             unclassedItems.query();

             while (unclassedItems.next()) {

                 var discoveredItems = new GlideRecord('sn_sec_cmn_src_ci');

                 discoveredItems.addQuery('state', 'unmatched');
                 discoveredItems.addQuery('cmdb_ci', unclassedItems.getUniqueValue());
                 discoveredItems.query();

                 if (!discoveredItems.next()) {

                     unclassedItems.operational_status = '6';
                     unclassedItems.install_status = '7';
                     unclassedItems.update();
                     count++;

                 }

             }

             return count;

         } catch (err) {
             return -1;
         }

     },

     type: 'VulMgr'

 };

Scheduled Job:

// Create manager
//
var mgr = new sn_vul.VulMgr();

// Retire items
//
mgr.retireUnclassed();

[Chris McDevitt · Accepted solution]

Here is what I would do,

Create a scheduled job that looks at all non "retired" Unclassed Hardware items to see if they are still in use. What I mean is, I would see if there is a reference to the Unclassed Hardware item in the Discovered Items module. If there is not a reference in the Discovered Items module to that CI, then set that CI Status to "Retired".

According to the docs: "By default, events do not bind to CIs with a specified status, such as Retired."

https://docs.servicenow.com/bundle/sandiego-it-operations-management/page/product/event-management/reference/r_EMHowAlertsBindCI.html

This is a conservative approach because, once something is deleted, there is no undo.

An even more conservative approach would be to set the Unclassed Hardware item to "absent" and modify evt_mgmt.ignore_retired_cis_in_binding property to also use "absent". 

So in VR, just like Event Management, "retired" is ignored. By setting it to "absent" and updating Event Management we avoid potently creating duplicate Unclassed Hardware Items.

You will need to do a lot of testing to verify that one of these approaches will work in your environment.

[Zach N]

Hey Chris, thanks for the reply. I like your first approach the best. Only a handful of records are created on this table per month, so I'm not too concerned about duplicate CIs.

I'll start testing your suggestion and reply back with my progress. Thanks!

[PG2]

Hi Zach, did you get an outcome or response from ServiceNow on how to handle this scenario?