- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hello Community,
We created custom CI Lookup rules based on OOB. Just adding a query line and else loop with OOB script. There are many Unmatched CI & Unclassed Hardware records are created. Previously I thought that IRE got invoke based on custom CI Lookup rule. With the help of this below link, I understood even if it is OOB or Custom Lookup rule, the IRE works.
Solved: Re: Can we switch from ci lookup rule to IRE for C... - ServiceNow Community
Then what will be the best approach to avoid Unmatched CI & Unclassed Hardware records?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
Hey @MURALIR20469232
The IRE is usually in play, whether you have custom CI lookup rules or not.
When our Asset information is imported from the scanner, following lookups are performed:
1. Does a matched or unmatched discovered item already exist for the unique asset that the scanner reported? (lookup based on the source_id on the discovered item source data)
IF THAT DOES NOT MATCH
2. We run the CI lookup rules (custom or not) and they search the CMDB based on defined logic to identify an existing CI
IF THAT DOES NOT MATCH
3. We pass the payload to the IRE and the IRE invokes the identification rules to try and identify an existing CI
Only if all 3 steps fail to find a match, the IRE itself inserts a new CI in the CMDB in one of the following classes:
-Cloud Resource (for cloud resources)
-Unclassed Hardware (for assets where we know the ip + an additional attribute like the fqdn or hostname)
-Incomplete IP Identified device (for anything that comes with just an IP-address)
And if due to any reason the IRE blocks or fails to create the CI, as a fallback mechanism, VR will create its own CI in the old deprecated "Unmatched CI" Class.
If you see a high number of unmatched CIs, you need to re-visit your rules and the CMDB data, consider:
-If youre working on a dev instance, when has the last clone down happened - is the CMDB up to date?
-Does your scanner provide proper information to match accurately or are you receiving mostly unauthenticated scan results providing IP information only
-Are the CIs youre looking for being populated in the CMDB, sometimes theres a mismatch in the scan ranges between Vulnerability Scanner and whichever source is populating CMDB (e.g discovery) make sure to check that
-Dont try to artificially increase match rate, whats important is the matching quality (right CI, right class, valuable info)
Hope this helps.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
Hey @MURALIR20469232
The IRE is usually in play, whether you have custom CI lookup rules or not.
When our Asset information is imported from the scanner, following lookups are performed:
1. Does a matched or unmatched discovered item already exist for the unique asset that the scanner reported? (lookup based on the source_id on the discovered item source data)
IF THAT DOES NOT MATCH
2. We run the CI lookup rules (custom or not) and they search the CMDB based on defined logic to identify an existing CI
IF THAT DOES NOT MATCH
3. We pass the payload to the IRE and the IRE invokes the identification rules to try and identify an existing CI
Only if all 3 steps fail to find a match, the IRE itself inserts a new CI in the CMDB in one of the following classes:
-Cloud Resource (for cloud resources)
-Unclassed Hardware (for assets where we know the ip + an additional attribute like the fqdn or hostname)
-Incomplete IP Identified device (for anything that comes with just an IP-address)
And if due to any reason the IRE blocks or fails to create the CI, as a fallback mechanism, VR will create its own CI in the old deprecated "Unmatched CI" Class.
If you see a high number of unmatched CIs, you need to re-visit your rules and the CMDB data, consider:
-If youre working on a dev instance, when has the last clone down happened - is the CMDB up to date?
-Does your scanner provide proper information to match accurately or are you receiving mostly unauthenticated scan results providing IP information only
-Are the CIs youre looking for being populated in the CMDB, sometimes theres a mismatch in the scan ranges between Vulnerability Scanner and whichever source is populating CMDB (e.g discovery) make sure to check that
-Dont try to artificially increase match rate, whats important is the matching quality (right CI, right class, valuable info)
Hope this helps.
