.svg)
As part of an out-of-the-box Vulnerability Response implementation, ServiceNow creates unclassed hardware “cmdb_ci_unclassed_hardware” records when it encounters a vulnerability on a CI that it cannot identify through either CI Lookup Rules or the IRE. This will be handled by the persona CI Manager “ (sn_vul.ci_manager) in the Vulnerability Response Module. In the following diagrams, you can see how each module interacts with the CMDB.
Reclassification and the Problem
As part of vulnerability response, ServiceNow supports the reclassification of unclassed hardware with CI Lookup Rules. However, this system needs to be updated, and we will leverage IRE whenever possible. Currently, ServiceNow does not supply an easy way to reclassify unclassed hardware with the IRE engine. When discovery comes along and finds a CI that was in the unclassed hardware table, it will create a new CI rather than replace the existing CI. Typically, there would need to be a manual task for the “CI Manager'' to analyze the unclassed hardware table and determine whether or not the CIs have been discovered.
Suggested Improvements
To alleviate this manual process, here are two quality-of-life improvements.
First, create a scheduled job to find retired unclassed hardware records. This job will loop through the unclassed hardware table and cross-check with the discovered item and discovered container image table. If there is no longer a match, we can assume the CI is no longer in use and can be marked as retired and eventually deleted. Below is an example of what this scheduled job could look like.
Second, create an “Unclassed Hardware” discovery schedule and automatically increment the list of IPs that it scans with any new unclassed hardware records. This will allow the CI Manager to run that schedule and use the result to determine the accuracy of any record in the unclassed hardware table. To accomplish this, create a business rule on the unclassed hardware table. Ensure the “When to run” is on updated and created records. Use the advanced tab to create a script. The objective of this script is to update the discovery IP range that is associated with the “Unclassed Hardware” discovery schedule. Review the script below.
At the end of the day, the unclassed hardware table is not strictly part of the CMDB. It represents the unidentifiable data brought in from a vulnerability scanner so that a relationship and the corresponding vulnerability can still be established. We should not prioritize keeping it clean but rather look at the underlying causes of why that data is there.
If you want to explore unclassed hardware in your environments further or need a better understanding, contact us at chat@rapdev.io.
