What differentiates Unmatched CIs from Unclassed CIs?

Abhinandan Pati · ‎03-28-2023

Hello Community,

I am bit confused about the CI un-matching process in Vulnerability Response application. I already went through all the attached articles & ServiceNow community but could not figure out everything associated un-matching process of Vulnerability response application.

Could you please help me in answering below queries in detail?

1. What is the logic that differentiates unmatched CIs [sn_sec_cmn_unmatched_ci] from unclassed CIs [cmdb_ci_unclassed_hardware] ?
2. How IRE decides which CI should be in unmatched [sn_sec_cmn_unmatched_ci] table and which one should be in unclassed [cmdb_ci_unclassed_hardware] table?
3. What does it mean by 'Created by VR' & 'Created by IRE' choices in 'Matching type for the DI' field of Discovered Item table?
4. Is it good practice to abort insertion of new CIs through VR process? If we block them, do they get created in unclassed hardware table or unmatched table?

Please do share if there is any detailed flow chart that explains all the steps. I already went through attached flow, but I feel its bit incomplete. I don't see any step associated with Unmatched CIs [sn_sec_cmn_unmatched_ci] table in the attached flow.

It would be of great help if you could share your inputs here. Thanks!

@Eric Feron @rahimulah @sivamallu @Chris McDevitt @Jan Spurlin @Madhumitha Redd @Elizabeth Skogq @John Gibbons @Anthony Ramos @andy_ojha

andy_ojha · ‎03-29-2023

Hey there,

Would suggest reviewing the content we posted here:

https://www.servicenow.com/community/secops-articles/the-more-you-know-secops-and-cmdb-interactions-...

The video and illustrations presented will help with some of the questions you posed...

-------------------------------------------------------------------

1. What is the logic that differentiates unmatched CIs [sn_sec_cmn_unmatched_ci] from unclassed CIs [cmdb_ci_unclassed_hardware] ?

--> See 5:31
--> See 10:52
- The illustration walks through the order of the target CMDB CI Class, when we create a CI (when there is no match)
- Unmatched CI Class, is used when IRE has an Error (in the current model)
- Unclassed HW is used when we have a minimum set of attributes from the incoming host (IP + something else)

2. How IRE decides which CI should be in unmatched [sn_sec_cmn_unmatched_ci] table and which one should be in unclassed [cmdb_ci_unclassed_hardware] table?
--> See 5:31
--> See 10:52
- The illustration walks through the order of the target CMDB CI Class, when we create a CI (when there is no match)
- Unmatched CI Class, is used when IRE has an Error (in the current model)
- Unclassed HW is used when we have a minimum set of attributes from the incoming host (IP + something else)

3. What does it mean by 'Created by VR' & 'Created by IRE' choices in 'Matching type for the DI' field of Discovered Item table?
--> Those are only a portion of the options
-> What this represents is either
A) If we matched to a CI in the CMDB, how did we match - with the SecOps CI Lookup Rules or the CMDB IRE Identifier Rules
B) If we created a CI in the CMDB - due to not having a match - how was it created, via the CMDB IRE or falling back to VR (e.g. IRE had an error, etc)
--> The Concept is Scenario 3 at 13:09

4. Is it good practice to abort insertion of new CIs through VR process? If we block them, do they get created in unclassed hardware table or unmatched table?
-- Sorry, not sure what the end goal here is for blocking or aborting
- If we bring in a host from a 3rd party scanner, we need to either match to an existing CMDB CI or create a new CI to track with if one does not exist (we could not successfully lookup a CI)

View solution in original post

andy_ojha · ‎05-12-2023

Hello,

Please refer to Scenario 3, in the video at 13:06 - Scenario 3, Matched Host from VR Scanner via IRE

Recall there are two methods of matching to a CI, either with the SecOps CI Lookup Rules, or via CMDB IRE.

If a Host comes in, and is not matched to a CI via SecOps CI Lookup Rules, and you have the IRE tie-in turned on, IRE will attempt to do it's own lookup before inserting a CI (as described in the video).

If IRE matched to a CI, it may then try to update certain values on the target existing CI with the values coming from the VR Scanner source (e.g. Operating System, FQDN).

We outlined the KB Article that has more information about this, and the ways to configure this so that you prevent updating attributes on existing CIs in CMDB, if IRE matches and wins.

How to prevent updates of configuration items in CMDB created by other sources (KB0963059) (Requires Customer Login Account)

Generally, if IRE is matching to a CI - our SecOps CI Lookup rules are restrictive / and very specific (resulting in no match).

Nitesh Tolani · ‎01-17-2024

This depends on the Reconciliation rules defined in the CMDB/IRE.

When the CI is getting updated via IRE engine then the system will check reconciliation rule if the current data source is allowed to update the attributes/fields of that CI.
If the data source is allowed then it will check if the same CI has any history of updates by other high priority data sources before. (It will check the table entries cmdb_datasource_last_update).
If the CI attributes are updated by the higher priority data sources previously, then it will skip the update for those attributes.

For details, check the KB: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0756709