Best practices for handling unmatched fallback CIs (unclassed hardware & incomplete IP ...)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
I’m working with a client that uses Rapid7 and Microsoft TVM with ServiceNow VR. A large percentage of discovered items remain unmatched, so VR creates many fallback CIs (Unclassed Hardware / Incomplete IP Identified Device).
We need clarity on what happens when a later scan can match the discovered item with the CMDB:
- If a discovered item was previously unmatched and created a fallback CI, but a later scan contains enough data, or the CMDB has since been updated, to allow a correct match, what happens to the old fallback CI?
- Does VR link the item to the correct CI and leave the fallback CI orphaned?
- Will fallback CIs be reused, reclassified, merged, or simply remain as duplicates?
We are also evaluating:
- Whether it's safe to clean up or delete fallback CIs,
- Whether suppressing fallback CI creation (to some extent) is a viable approach,
- How to correctly use the “Reapply Lookup Rules” function,
- Can IRE functionality be of any help
Before making changes, we want to understand the risks and best practices, especially in environments with high unmatched rates.
Does anyone have experience or guidance on how fallback CIs should be managed effectively?
Thanks!
- Labels:
-
Vulnerability Response
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
Hello @LucienLauret.,
First about the question you have raised
1) If a discovered item was previously unmatched and created a fallback CI, but a later scan contains enough data, or the CMDB has since been updated, to allow a correct match, what happens to the old fallback CI?
- It depends on the specific fallback class used. If it is Unclassed Hardware, Discovery/IRE will reclassify it into the correct class. If it is an Unmatched CI, it is typically not gets reclassified and remains in the system.
2) Does VR link the item to the correct CI and leave the fallback CI orphaned?
- Yes. Open VITs move to the new CI, while Closed VITs usually remain on the original fallback CI for history. You will required some customization to update ci on closed VIT.
3) Will fallback CIs be reused, reclassified, merged, or simply remain as duplicates?
- Unclassed Hardware class is reused and reclassified and Unmatched CI remains as a duplicate/orphan and must be manually merged or deleted
4) Whether it's safe to clean up or delete fallback CIs.
- Yes but partially. You can delete If it is not tagged with any VIT, Discovered item, detection or any other records like incident or change request.
5) Is suppressing fallback CI creation a viable approach?
- No.
6) How to correctly use the “Reapply Lookup Rules” function?
- You can use this function when you have improved your CMDB data or updated your CI Lookup Rules logic.
7) Can IRE functionality be of any help?
- Yes.
To further optimize CI matching we have referred some articles and documentation motioned below. This involves several activities, including fine-tuning CI lookup rules and updating VR-related system properties
1) https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0998270
2) https://www.servicenow.com/community/secops-forum/recommended-practices-for-ci-matching-success-customers-only/m-p/2435065
Regards
----
If this response was helpful, please select "Accept as Solution" and "Helpful." This helps both the community and me.