CI Matching - How to do it right. (20 min tutorial) and Deep-dive CI matching webinar

Eric Feron · ‎03-03-2020

The matching of your CMDB's Configuration Items (CIs) to the list of hosts and vulnerabilities brought in by your scanner is key to the success of your Vulnerability Response (VR) implementation.

Learn how this works and how to do it right in 20 minutes. In this second episode of the 2020 VR series, Andy Ojha (aka @./andy-b2poYQ== ) , Principal Security Consultant with the Professional Services organization at ServiceNow shares his knowledge and advice so you can be successful.

Ensuring that the early steps of CI Matching are executed as needed will ensure an optimum use of the CMDB and guarantee time savings and effectiveness down the line. Getting it wrong will create unnecessary challenges.

This tutorial follows the earlier episode of the VR series: "The importance of your CMDB for Vulnerability Response."

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

Video contents:

00:01 Introductions.

01:20 The VR maturity model.

01:37 The VR tutorials series.

02:08 The VR forum.

02:28 CI Matching = Scanner + VR application + CMDB.

02:55 CI Matching: how it works. CI Lookup Rule, Discovered Items, Vulnerable Items, Third Party Entries library.

05:56 An example.

04:55 CI Matching is an iterative process, the first run is critical. Matched Discovered Item, Unmatched Discovered Item, Unmatched CI.

06:05 Flavors of Matched Discovered Items: Complete (success), Incomplete (needs more work), Incorrect (needs more work). Unmatched Discovered Items.

07:39 "Walk-up" for low level CIs with no context.Parent.

08:37 Vulnerable Items.

09:00 Lessons learned in the field. Best prevention: get the CMDB and the CMDB team ready.

11:40 Success with VR is about cross-functional leadership, change management and coordination.

12:18 What YOU (Security team) should do: training and community, start small and iterate.

12:30 How to interact with the CMDB team: engage early, understand the CMDB, make sure they understand your VR strategy, ensure they are ready to handle unmatched CIs.

14:31 How to interact with your Partner/Consultant. Iterative approach is key, track results, tune the Lookup Rules, ServiceNow Discovery.

16:51 Involve the remediation teams, the end users of the VR implementation.

17:15 Keep the executives apprised.

17:52 Beyond CI Matching, there is more. Scanners, Vulnerabilities, Exploit Enrichment, Remediation Target Rules, Risk based approach with Scoring, Grouping, Assignment. Watch the upcoming episodes.

19:00 What you should be doing RIGHT NOW: Engage with your partner and your CMDB team, review the other VR tutorials, engage in the VR forum, sign up for training.

19:48 Conclusion and reminders.

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

Here are some additional resources on CI Matching that will be useful to you:

Deep-dive: CI Matching and Reconciliation in Vulnerability Response by Elizabeth Skogquist and John Gibbons - Recording of the Product Success webinar, PDF of slides and full Q&A (coming soon), June 2025. One of the webinars in our "Success with Vulnerability Response" series of recommended practices deep-dive webinars.

Here is the recording of the webinar for your convenience:

Reapplying CI Matching Rules to Discovered Items after Source Data is updated by Dan Daugherty - Full article, Feb 2023.
ServiceNow Vulnerability Response CI Matching Tuning by John Gibbons - Full article, Mar 2022.
The more you know - SecOps and CMDB Interactions (Video) by Andy Ohja and Denny Ng - Video, Jan 2023

-----------------------------
Questions and Answers from webinar:

Question	Answer
To be able to configure/update these lookup rules, does the VR Admin role have the required permissions to do this? Or it needs to be done by platform admin	They can be defined/edited by the VR admin.
When continous scans are being done, would they keep the Most recent discovered field on the Incomplete IP or unclassed Hardware record updated so that the record does not get stale?	Yes - the SourceID field is updated everytime the scan is imported. If anything on SourceID changes - the Re-apply CI Lookup Rules on the Changed Discovered items (if enabled) would run to try and match to a new CI if necessary
Is there som AI Driven approach to enable associating / suggesting VULS to existing changes? E.g. Patching Weekend Change typically opened few weeks ahead? (e.g. Linux Servers)?	That is not currently available out-of-box but it is a great use case. Thank you for sharing.
How to handle tens of thousands of Discovered Items? Our VR scanners and discovery create DI’s faster than we can have staff reclassify and it creates a bad data source that is referenced before CI Lookup Rules. Ideally, we would have staff reviewing it regularly, but do not have the institutional buy in.	Discovery does not create DIs, only VR does. And agreed, if the DI table is continually growing, it is recommended to set up a scheduled job to delete DIs (unmatched with no VITs) that have not been found in a certain amount of days, executed on a regular basis
What level of collaboration does ServiceNow have with 3rd party vendors who ship their plugins with lookup rules?	For 3rd party vendors that build their own integration to ServiceNow, we engage for a certification of their build before it becomes available on store.servicenow.com.
In case a CI is not used in either assignment rule, remediation task rule, risk calculation etc. do we still need to care about CI matching? Because the Remediation owner will only care about the information of the CI (example Windows Server), which the Remediation owner can also get from the Detection tab as well. The actual remediation will also happen in the Server and not in ServiceNow.	When determining risk of a vulnerability in your environment, knowing if the asset is externally facing, hosting a crown jewel application, maintains sensative data (PCI, PII, etc.). The value of having vulnerabilities prioritized for the Remediation Owner with these risk valuations assures they are working on the vulnerabilities that need attention first.
We have multiple assests under same Vul so should we create multiple VIs or group them in single VI?	Remediations Tasks are intended to group VIs that would have the same remediation efforts. This allows the Remediation Owners to work with the one task, vs. each of the VIs individually.
This is still after all these years very Discovery centric with the Unmatched CI etc. Many of these assets will never be seen by Discovery. Any plans to improve the IRE process for this and create true rich CIs. I beleive that would require more attributes natively mapped.	You can utilize Service Graph Connectors to augment the CMDB, however IRE is the only piece that will automatically change the class of CI’s created by VR
Any plans on adding a debug property to potentially enhance logging for CI lookup, we have multiple customers facing many issues with the same	That is a great suggestion, we can forward to our product team to see if that can be included. You can always place a gs.info statement in your script to print anything into the log
Is there a list of CMDB tables to help identify the target table on a matching rule?	This docs page should be helpful: https://www.servicenow.com/docs/csh?topicname=c_ConfigurationManagementDatabase.html&version=latest
On the Discovered Item table, there is a value in the "Matching type for the DI" field of "Matched Manually" - how does this get set? How are we able to match a discovered item manually?	if you manually change the CI on the discovered item then the "Matching type for the DI" field will be set to "Matched Manually"
When a Discovered Item that had previously matched to CI ABC and is NOT Matched after a Re-Apply runs. this D/I becomess an unclass hardware record , is that a correct assumption?	Correct - Check why it is now unmatched and determine if the incoming data supports a match opportunity and work with updating rules for it to align
Do we need to ever auto-purge the unclassified items table?	It would depend on the situation, you would want to use archive or auto-delete features that will allow cascade to related records, to avoid orphaned records
One thing that we're still having to deal with is the CMDB CI overwriting the discovered item fields such as IP, Name etc. This causes issues for us when we're trying to find assets that need to be rematched that are being missed. Is there anything coming out to help with this?	Most of the fields on the discovered item come from the CI (FQDN, MAC, IP, Class) - if Discoverey or another source changes the CI then these fields will change on the discovered item. You can always use the source and initial source data fields to validate the attributes that came in from scanner
should the database vulnerabilities be mapped to host CI or the database CI?	All scanner CIs are typically matched to the Host CI. Use classification rules to classify application (i.e. database, OS) vulnerablities for assignment
Is there an option to not use discovered items? John mentioned that it does highlight gaps and ‘forces’ the cmdb, discovery, and vr scanner teams to work together, but if they cannot or will not, it would be useful to know if there was a way to avoid creating DI’s.	With the current design, there is not a means to have discovered items be optional.
We tried to create auto-delete rules on discovered item table which are not scanned in alst 90 days. It did deleted the discovered items, but not the associated VITs. Is that expected?	Yes. Look at the option of using Cascade delete (check box in the auto-delete rule). Information can be found: https://www.servicenow.com/docs/bundle/yokohama-platform-administration/page/administer/field-admini...
Would like to understand how ServiceNow VR deals with Assets that are deleted from scanning tools? We see an issue of duplicate assets being created in our environment. How to mitigate these issues? The problem is due to duplicate issues some VITs are not getting closed because of old asset data	Set up Auto-close rules to have assets that go a long period without scanning have their VIs auto-closed.
For CIs created via VR/IRE process. For Unclassed Hardware CIs, There is in most cases just a name and network adapter info present in the CI record. In most cases the discovered item will have additional datapoints like OS, etcc that are not passed to the IRE payload and inserted into the created CI. Why is this information not passed? I understand these CIs created in this fashion are intended to be “Temporary” and the client’s discovery sources should be where the asset is discovered, but I have encountered many clients who do not have Discovery, or their CMDB is not in the best of shape, where they intend to using these VR/IRE CIs permanently. Having the other datapoints like OS (if available) being passed to IRE would be a major value add. Any plan on enhancing this process so that if a CI is created, it contains all available datapoints that the Discovered Item has?	We can pass this to product team to see if this can be included in a future release
If the lookup rule does not have a source but is higher on the order. Does that rule trigger for every source, or it will only fire when the source matches?	Source is a required field and needs to be populated. Only rules with a source are evaluated.
Does reapplying CI lookup rules will also update VIs risk rating if any changes in CI?	Risk Calculators rerun if the CI on the VIT is updated (due to reapplying the CI lookup rules). They will not run if individual changes are made on the CI attributes unless configured to do so
Does the Re-apply CI Lookup job have and performance impacts when ran?	it could depending on the volume of Discovered Items. You will also want to increase the value for System Property: sn_sec_cmn.background_job_max_concurrency. From 10 to 20 and increase the processor pool jobs. https://www.servicenow.com/docs/csh?topicname=vr-adv-config-bkgrd-fmwrk.html&version=latest You may have to increase the Max Concurrent Threads and Size of partition values based on performance(run time) of the critical jobs https://www.servicenow.com/docs/csh?topicname=vr-configure-bckgrnd-frmwrk.html&version=latest
We have different scanners creating discovered items for the same CI, any way to merge this.	No, it is working as intended - You can have multiple DIs mapped to one CI.
I do not see the SecOps - Vulnerability Health Dashboard - is that not available in the Washington release?	This is available for Washington: https://store.servicenow.com/store/app/2fd923a21b246a50a85b16db234bcb18#linksAndDocuments
Is there documentation to create scripts to help with the look up rules?	https://www.servicenow.com/docs/csh?topicname=ci-identifier-rules.html&version=latest
How do I validate that the third party library is being updated on a regular basis?	Check the Third-Party listing, and add the updated field to the listing, sort by descending date so the latest date is at the top. This will confirm when the last update was executed.
We have multiple discovered items for same CI. And each DI source data contain different source ID and different IP. Is this expected? Anything needs to be checked for this?	Yes, if the source ID is different then it will create multiple Discovered Items. Licensing will only focus on the unique CI references
No auto delete rules are not setup	Recommend checking out docs on setting up auto-delete rules: https://www.servicenow.com/docs/bundle/yokohama-security-management/page/product/vulnerability-respo...
Which SNOW release will include the mentioned new features (announced for May 2025)?	Vulnerability Response version: 26.0.11, which is compatible with Yokohama, Xanadu and Washington. The VR compatibility matrix can be viewed in a KB on Support at: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0856498
We're seeing instances where the Source Data field hasn't been updated in months, but the DI is regularly being scanned - should Source Data get updated during every Asset integration run or only periodically?	The Source Data field should be updated with the latest payload data changes, which should update last_scan
What can I do if my current CI has no active DI record, as the CI was reinstalled/redeployed under the same name as it was before, with the re-install we kicked off "re-evaluate CI" which ran in DI table, it ended up that all DI records were now pointing to the retired CI. But now I don't have a DI for the new CI?	You may want to consider changing the system property 'sn_sec_cmn.filterOutDecommissionedCI' to true so that it will include retired assets when try to do a CI match
Can an existing CI data get updated because of the CI matched by Lookup rule or matched by IRE? If yes, on what scenarios will it update existing data and how can this be disabled? CMDB team does not wants to update the CI discovered by 3rd party.	Existing data on the cmdb should not be updated. SN Discovery should be the only source that updates the CI.
In which conditions the status of the DIs will change to Reclassified?	When IRE makes a change to the CI and it reclassifies the CI then the DI status will show as reclassified.
for script rules, what is the function/value of the 'type field' - what does it do?	It specifies the rule execution method, whether it uses a script or another logic type. See more here: https://www.servicenow.com/docs/bundle/vancouver-security-management/page/product/security-operation...
Also I would like to understand what is the best practice to cleanup the discovered item table?	Here is a KB for removing DIs without vulnerabilities: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1349923. With licensing only working with the last 90 days of scanned assets, you might consider removing older DIs (6 months since last scan), knowing they will get rebuilt if they become active and get scanned.
We're using the Azure SGC to import Azure HW & SW inventory into the CMDB - but a recent Azure SGC version update/enhancement has added some additional scripts which are intended to be used to get more CI information into the CMDB (which we can't turn on due to security implications).... I fear that not enabling the above feature will stop us improving VR Defender TVM integration VIT CI lookup hit rates... could my assumption be correct ?	yes, if you are using a SGC to import data then theoretically it should help improve the CI Match rate
In some situations, is it possible to inhibit the creation of CIs in the CMDB (By VR System) natively while maintaining the creation of the VIT or AVIT?	No, creating a VIT or AVIT without referencing a CI is just importing vulnerabilities without any context. You do have the ability not to create VITs for Incomplete IP CIs through exclusion rules
What is "Source" referring to?	Source is where the data is coming from, usually the scanner.
I know the benefits of grouping multiple VIT with a VUL, but is it possible to not group and create a 1:1 VIT VUL logic with OOB config?	You can do everything on VIT, you would do on the Task, so it would be unecessary processing. Work from the VIT table, if the use case is needed. However, we recommend working from Remediation tasks for efficiency in handling all like VITs.
How to best handle situations where we are actively discovering 24/7 but vulnerabilities are ingested prior to discovery hits the asset so we produce an unmatched DI?	The intent is that discovery IRE would reclassify the unclassed record to the correct class(windows server)
Suppose a CI was not existing in ServiceNow CMDB. In that case a CI will be created in unclassed hardware or incomplete IP class. Later after 1 month that CI is created in the Linux server class Question: What happens to the existing discovered item that was mapped to a CI created in unclassed hardware or incomplete, IP class	If discovery find the new server it will reclassify the unclassed hardware CI to Linux server CI
Regarding Reapply CI lookup rules is there a way to separate that capability from the admin now or in the future. As some of our vulnerability analysts needed to sometime do rematching outside of scheduled jobs.	There is an individual role that can be used for matching: sn_vul.app_sec_manager. Caution running CI lookup rules during operational hours, and they cannot run during any integration jobs. The only time CI lookup rules should be rerun manually is if properties or lookup rules are created / updated.
is it possible\advisable to have listeners for things like a database or web server set as a CI? what would we use to match them?	You should only match against CI classes that the remediation analyst can remediate. You can adjust CI Lookup rules to match against whatever classes you want.
I don't see the SecOps - Vulnerability Health Dashboard in my instance. Is there another name for the dashboard?	You can access the VR Health Dashboard through analytics or the Vulnerability Manager Workspace. It is available through a store plugin SecOps Health Analytics: https://www.servicenow.com/docs/bundle/yokohama-security-management/page/product/vulnerability-respo...
Are CI Matching Rules case sensitive?	No, CI matching rules aer not case sensitive.

Satya36 · ‎05-22-2020

Is Vulnerability Response comes with by default CI look up rules or we have to create those rules? If it comes with out box CI lookup rules where I can check those? In SecOps - CI lookup rules or somewhere else?

ESkogquist · ‎08-26-2020

Out of box examples are provided. Search in the navigation window for CI Lookup Rules.

ESkogquist · ‎09-09-2020

Yes, the CI lookup rules used for VR are in SecOps> CI Lookup rules.

mayurt · ‎06-25-2021

Hi Eric ,

Thanks for the detailed information, can you please highlight the role of IRE engine with Quebec release ? Can we reclassify CI from "Incomplete IP Identified Device" ?

Kind Regards,

Mayur

michellelim · ‎12-28-2021

hi, is there an updated version on this ?

Eric Feron · ‎12-29-2021

@michellelim , thank you for your question. What parts would you think need to be updated?

Best.

Eric Feron · ‎01-19-2023

Make sure you do not miss this webinar:

Recommended practices for CI Matching success (Customers only: deep-dive webinar) Jan. 25-26, 2023

See you there.

Cheers,

EF

Eric Feron · ‎03-20-2023

Some more recommended resources to help you with CI Matching:

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

CI Matching - How to do it right. (20 min video tutorial) and downloadable slides by Andy Ohja and Eric Feron - Video tutorial and slides, Mar 2020.
The more you know - SecOps and CMDB Interactions (Video) by Andy Ohja and Denny Ng - Video, Jan 2023.
ServiceNow Vulnerability Response CI Matching Tuning by John Gibbons - Full article, Mar 2022.
Recommended practices for CI Matching success (Customers only: deep-dive webinar) Jan. 25-26, 2023 by Elizabeth Skogquist and John Gibbons - Recording of the Product Success webinar, Jan 2023.
Reapplying CI Matching Rules to Discovered Items after Source Data is updated by Dan Daugherty - Full article, Feb 2023.

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