---
sourceDocument: Xanadu Security Management
sourceDocumentLink: https://www.servicenow.com/docs/r/xanadu/security-management

 Release :

    - xanadu

ft:locale :

    - en-US

ft:publication_title :

    - Xanadu Security Management

ft:clusterId :

    - security

bundleId :

    - security

workflow :

    - Technology


---

# CI lookup rules for identifying configuration items from Vulnerability Response third-party vulnerability integrations

# CI lookup rules for identifying configuration items from Vulnerability Response third-party vulnerability integrations {#ariaid-title1}

* Release version: Xanadu
* 
* Updated August 1, 2024
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read

When data is imported from a third-party integration, Vulnerability Response
automatically uses host data to search for matches in the Configuration Management Database (CMDB). It does this using CI Lookup Rules. These rules are used to identify configuration items (CIs) and add them to
the vulnerable item record to aid in remediation.

Starting with version 19.0, navigate to Security OperationsCMDBLookup Rules to locate the list in your instance.

As assets are imported, a lookup is performed first on the Discovered Items list using third-party IDs to find matches to configuration item (CIs) from prior imports. When a host ID match is found, it is used
as the Configuration item field in the vulnerable item record.

You can see how imported assets are mapped to CIs using the Discovered Items list. If a match is not found, or the host ID field is empty, the rules use the other host information to attempt to correctly
identify the CI. If a match is still not found, a placeholder CI is created and is designated as an Unmatched CI. See [Unmatched CIs](https://www.servicenow.com/docs/X9m4dzvviSlDzJRrYdLxzA "Configuration items (CIs) are automatically matched to CIs in the Configuration Management Database (CMDB) when they are imported. By default, the Security Operations > CMDB > Discovered Items module lists those configuration items without a match.") for more information on how those CIs are handled.  
CI lookup rules can be domain separated and are source-specific. Each source can have multiple deployments.  
Note:  
CI lookup rules are shared by all deployments of the vulnerability source integration. If a rule is deleted or modified, the deletion or changes affect all deployments of the vulnerability integration.  
When attempting a match, the first step is a vendor ID lookup for an exact match across source, source_instance, and vendor ID. Then, lookup rules are run in order, from lowest to highest and stop when a rule returns just a single CI as a match. If a rule is created in such a way that it returns more than one CI, only the first match is used.  
Note:  
To avoid matching on low-level networking elements, if a matched CI is one of `dscy_switchport`, `cmdb_ci_network_adapter`, `cmdb_ci_nic`, or `cmdb_ci_ip_address`, the parent CI is returned.

A system property to exclude CI classes is available. This property is not available with upgrade. See [Ignore CI classes](https://www.servicenow.com/docs/y_B2xD1f1wFsY5948~Bw5g "To ignore some configuration item (CI) classes, for example Load Balancer [cmdb_ci_lb], when running CI Lookup Rules, set the ignoreCIClass [sn_sec_cmn.ignoreCIClass] system property.") for upgrade information and instructions on setting the property.

To make it easier to find matching issues, when a match is found, the CI lookup rule used to find it is added to the Discovered Item record in the CI matching rule field. Lookup rules are evaluated by lowest
Order value first.

The CI lookup rules are shipped with their corresponding integration plugins.  
Some of the Qualys CI lookup rules are:

* QUALYS HOST ID
* FQDN
* NetBIOS
* DNS
* IP
{#ci-identifier-rules__ul_dms_5km_n1b}  
Some of the Rapid7 CI lookup rules are:

* MacAddress
* FQDN
* HostName
* IP
{#ci-identifier-rules__ul_dms_7km_n1b}  
Some of the Tenable.io CI lookup rules are:

* FQDN
* NETBIOS
* HOSTNAME
* MacAddress
* DNS

{#ci-identifier-rules__ul_yyb_1wx_kwb}  
Note:  
The Tenable.io CI lookup rules prioritize and populate the non-empty network interface values (FDQN, IPV4, and MacAddress) over the regular FDQN, IPV4, and MacAddress values for a discovered item. When these network interface values are empty, the regular FDQN, IPV4, and MacAddress values are populated for a discovered item.  
Some of the Tenable.sc CI lookup rules are:

* MacAddress
* FQDN
* NETBIOS
{#ci-identifier-rules__ul_qxk_gwx_kwb}  
Note:  
Rules, once removed, cannot be recovered. Rather than removing existing rules, deactivate them when creating new ones.

Importing vulnerability data can be taxing on an instance and performance issues with resources can occur if rules are not carefully constructed. The logic used to iterate through and perform matching within the CMDB can result in lengthy processing times. To avoid any potential degradation of resources or performance complications, test any custom-written CI Lookup Rules or modifications to pre-defined
CI Lookup Rules. See [Steps to help prevent duplicate or orphaned records after running Vulnerability Response CI lookup rules](https://www.servicenow.com/docs/iHddzRETLfoG7JJT04qjew "Take steps to help prevent duplicate or orphan records resulting from matching (configuration items (CIs) within the CMDB.") for more information on preventing duplicate orphan records, deleting data, and cleaning up data.  
Note:  
For information on CI matching, see [KB0998706](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0998706).

## Reapplying updated CI lookup rules {#ci-identifier-rules__section_ad2_lpj_j4b}

When you change a CI lookup rule, click Apply Changes on the CI Lookup Rules list page to rerun all the rules on the discovered items that:

* Were matched by the updated rules
* Are not matched by any rule

{#ci-identifier-rules__ul_byw_hrj_j4b} If the configuration item (CI) changes after reapplying the lookup rules, the discovered items are updated with the new CI. The impacted detections and vulnerable items are also updated. For more information, see [Reapply CI lookup rules on selected discovered items](https://www.servicenow.com/docs/w1zu4wGprutFQ3x9FFjO_g "Reapply the configuration item (CI) lookup rules on selected discovered items from the discovered item list view select actions. If the CI changes after you reapply the rules, the discovered items are updated with the new CI and impacted detections. Vulnerable items are also updated.").
* **[Unclassed hardware](https://www.servicenow.com/docs/udbJnW8xo3OYAy~a9M1beA)**   
  If an asset does not find a match in the Configuration Management Database (CMDB) by CI lookup rules, the asset is termed as an unclassed hardware.
* **[Unmatched CIs](https://www.servicenow.com/docs/X9m4dzvviSlDzJRrYdLxzA)**   
  Configuration items (CIs) are automatically matched to CIs in the Configuration Management Database (CMDB) when they are imported. By default, the Security OperationsCMDBDiscovered Items module lists those configuration items without a match.

*[\>]: and then


