{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":45184,"path":"security-management/sem-configure-lookup-rules.md","title":"Configuring lookup rules","bundle":null,"doc_type":null,"release":"australia","body":"\n# Configuring lookup rules\n\nBy configuring lookup rules, you can map security exposure data to the correct configuration items \\(CIs\\) in the CMDB. This mapping is a critical function because associating exposure findings with the right assets is essential for proper risk assessment, assignment, and remediation workflows.\n\n**Parent Topic:**[Configure rules to manage findings](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/sem-configure-rules-manage-findings.md)\n\n**Related topics**  \n\n\n[Associating finding with a configuration item using lookup rules](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/sem-associate-finding-configuration-item-using-lookup-rules.md)\n\n## Create lookup rule\n\nCreate lookup rules to automatically and accurately associate incoming exposure findings data with the correct configuration items \\(CIs\\) in the Configuration Management Database \\(CMDB\\) This is essential for enabling the rest of the vulnerability management process to function correctly.\n\n### Before you begin\n\nRole required: sn\\_vul.vulnerability\\_admin\n\n### About this task\n\nCreating lookup rules requires advanced ServiceNow and Unified Security Exposure Management \\(USEM\\) expertise. Rather than modifying one of the existing lookup rules, consider copying it and modifying the copy. When you are satisfied that the new rule does what you want, deactivate the original.\n\n**Note:** Rules, once removed, cannot be recovered. Rather than removing existing rules, deactivate them when creating new ones.\n\n### Procedure\n\n1.  Navigate to **Workspaces** &gt; **Security Exposure Management Workspace**.\n\n2.  Select **Administration** \\[gear icon\\] in the navigation pane.\n\n3.  Select **Review** on the **Look-up rules** tile.\n\n4.  On the Rules page, select **Look-up** in the navigation pane.\n\n5.  Select **New**.\n\n6.  On the form, fill in the fields.\n\n<table id=\"table_t4d_4bd_5t\"><thead><tr><th>\n\nField\n\n</th><th>\n\nDescription\n\n</th></tr></thead><tbody><tr><td colspan=\"2\">\n\nDetails\n\n</td></tr><tr><td>\n\nName\n\n</td><td>\n\nName of the rule.\n\n</td></tr><tr><td>\n\nLookup method\n\n</td><td>\n\nMethod used for matching. Choices are:-   **Script**: Pre-built \\(IP address, DNS name, and so on\\) or custom script.\n-   **Field matching**: Search on table or field in the CMDB.\n\n\n</td></tr><tr><td>\n\nType\n\n</td><td>\n\nType used with the Script **Lookup method**.\n\n</td></tr><tr><td>\n\nOrder\n\n</td><td>\n\nOrder of precedence for the rule. Rules with the lowest order are evaluated first.\n\n</td></tr><tr><td>\n\nActive\n\n</td><td>\n\nCheck box for whether the rule is active or disabled.\n\n</td></tr><tr><td>\n\nSource\n\n</td><td>\n\nSource used as input to this rule.\n\n</td></tr><tr><td>\n\nSource field\n\n</td><td>\n\nSource field used as input to this rule. Select any field, but it is treated as a string value.\n\n</td></tr><tr><td>\n\nDescription\n\n</td><td>\n\nDescription of the new look-up rule.\n\n</td></tr><tr><td>\n\nLookup target\n\n</td><td>\n\nLookup approach you want to follow. Select from: -   Configuration item\n-   Product model\n\n\n</td></tr><tr><td>\n\nApplies to\n\n</td><td>\n\nThis field has no value by default.\n\n For third-party and ServiceNow® integrations that support both Application Vulnerability Response \\(AVR\\) and Vulnerability Response \\(VR\\) like the Vulnerability Response Integration with Wiz, for example, select one as it applies to each rule:\n\n-   **Discovered Item** - for Vulnerability Response lookup rules.\n-   **Discovered Application** - for Application Vulnerability Response lookup rules.\n **Note:** If you leave this field empty for lookup rules that support both VR and AVR integrations, background jobs for both applications apply changes on the same set of lookup rules. This state might cause a conflict and set the reapply flag incorrectly.\n\nWith this distinction set, after the respective background jobs for AVR and VR are completed, the system resets the flag only for the lookup rules for the background job that was run.\n\n</td></tr><tr><td colspan=\"2\">\n\nIf condition is met\n\n</td></tr><tr><td>\n\nCondition\n\n</td><td>\n\nCondition based on which the lookup rule is applied. This condition depends on the attribute from the third-party scanner.**Note:** The asset attribute is a part of the payload. It is received from the third-party scanner. See the Discovered Items table for payload examples.\n\n</td></tr><tr><td colspan=\"2\">\n\nThen set this value\n\n</td></tr><tr><td>\n\nLookup method\n\n</td><td>\n\nMethod used for matching. Choices are: -   Script: Pre-built \\(IP address, DNS name, and so on\\) or custom script.\n-   Field matching: Search on table or field in the CMDB.\n\n\n</td></tr><tr><td>\n\nSearch on CI table\n\n</td><td>\n\nTable to search within the CMDB. Used with field matching **Lookup Method**.\n\n</td></tr><tr><td>\n\nSearch on product table\n\n</td><td>\n\nIf you choose the Product model Lookup target, the default value is Application Model.\n\n</td></tr><tr><td>\n\nSearch on CI field\n\n</td><td>\n\nField that contains information that can be used to locate a CI. Used with the field matching **Lookup method**. This field may be on the CI record, or on a related record, such as a network adapter.\n\n</td></tr><tr><td>\n\nSearch on product model field\n\n</td><td>\n\nIf you choose the Product model Lookup target, the default value is Name.\n\n</td></tr><tr><td>\n\nType\n\n</td><td>\n\nType used with the Script Lookup method.\n\n</td></tr><tr><td>\n\nScript\n\n</td><td>\n\nEditable sample script, based on the **Type**, is shown. Implement the custom script following the comments included in the template of the default function.**Note:**\n\nThe process function has three parameters: **rule**, **sourceValue**, and **sourcePayload**\n\n</td></tr></tbody>\n</table>7.  Select **Save**.\n\n    For more implementation information for lookup rules see, [Steps to help prevent duplicate or orphaned records after running Vulnerability Response CI lookup rules](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/vulnerability-response/ci-identifier-rules-impl-test.md).\n\n\n**Related topics**  \n\n\n[Vulnerability Response vulnerable item form fields](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/vulnerability-response/vulnerable-item-fields.md)\n\n## Ignore CI classes\n\nTo ignore some configuration item \\(CI\\) classes, for example Load Balancer \\[cmdb\\_ci\\_lb\\], when running lookup rules, set the **ignoreCIClass** \\[**sn\\_sec\\_cmn.ignoreCIClass**\\] system property.\n\n### Before you begin\n\nRole required: admin\n\n**Note:**\n\nThe **ignoreCIClass** system property is available starting with Vulnerability Response v9.0. However, the property functionality is not available upon upgrade from any previous version.\n\nIf you have upgraded from any Security Operations application, prior to version 9.0, see [KB0788209](https://support.servicenow.com/kb_view.do?sysparm_article=KB0788209) for instructions on how to enable this functionality.\n\n### Procedure\n\n1.  Enter `sys_properties.list` in the left navigation bar.\n\n2.  Select **Enter**.\n\n3.  In the **Search** menu, under **Name** enter `sn_sec_cmn.ignoreCIClass`.\n\n4.  In the **Value** text box, enter the CI classes to exclude in a comma-separated list.\n\n5.  Select **Update**.\n\n    This list is used by CI Lookup Rules during the next import. Vulnerable items created during import are not associated to a CI of any type listed in the **Value** field of the `sn_sec_cmn.ignoreCIClass` system property.\n\n\n## Reapply lookup rules\n\nReapply lookup rules to ensure updated or existing rules are applied to relevant items. This helps maintain accurate data mapping and consistency after rule changes or additions.\n\n### Before you begin\n\nRole required: sn\\_vul.vulnerability\\_admin, sn\\_vul\\_cmn.usem\\_admin, sn\\_vul.app\\_sec\\_manager, sn\\_vul\\_container.admin, sn\\_vulc.admin\n\n### About this task\n\nReapplying lookup rules is useful when:\n\n-   Look-up rules are updated or newly created.\n-   Findings were previously unassigned or incorrectly assigned.\n-   You must reassign ownership based on updated business logic or CI ownership changes.\n\n**Note:**\n\nFor Vulnerability Response \\(VR\\) lookup rules, two background jobs are simultaneously initiated after you select **Reapply**: one for Vulnerability Response \\(VR\\) rules and one for Application Vulnerability Response \\(AVR\\) rules.\n\nTo keep these jobs distinct and to prevent conflicts, the AVR and VR lookup rules have the **Applies to field** on lookup rule records, which by default is not populated.\n\nIf you're [creating lookup rules](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/sem-configure-lookup-rules.md) for third-party and ServiceNow® integrations that support both Application Vulnerability Response \\(AVR\\) and Vulnerability Response \\(VR\\) like the Vulnerability Response Integration with Wiz, for example, you might want to create two separate rules, one for VR and one for AVR and choose one in the Applies to field:\n\n-   **Discovered Item** - for Vulnerability Response lookup rules.\n-   **Discovered Application** - for Application Vulnerability Response lookup rules.\n\nWith this distinction set, after the respective background jobs for AVR and VR are completed, the system resets the flag only for the lookup rules for the background job that was run.\n\n### Procedure\n\n1.  Navigate to **Workspaces** &gt; **Security Exposure Management Workspace**.\n\n2.  Select **Administration** \\[gear icon\\] in the navigation pane.\n\n3.  Select **Review** on the **Look-up rules** tile.\n\n4.  On the Rules page, select **Look-up rules** in the navigation pane.\n\n5.  Select **Reapply**.\n\n    All the rules are reapplied regardless of any filters.\n\n6.  Alternatively, you can navigate to the Lookup Rules \\[sn\\_sec\\_cmn\\_ci\\_lookup\\_rule\\] table, select individual rules, edit the records, and update them.\n\n7.  Select **Apply Changes** to apply your recent changes to existing discovered items.\n\n    **Note:** Depending on your number of discovered items, evaluating them with your updated rules might take some time.\n\n\n**Related topics**  \n\n\n[Reapply lookup rules on selected discovered items]()\n\n## Reapply lookup rules on selected discovered items\n\nReapply the lookup rules on selected discovered items from the discovered item list view select actions. If the configuration item \\(CI\\) changes after you reapply the rules, the discovered items are updated with the new CI and impacted detections. Vulnerable items are also updated.\n\n### Before you begin\n\nRoles required: admin\n\n### About this task\n\nFor more information, see [CI changes for discovered items](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/security-management/vulnerability-response/reapply-discovered-items-ci-changes.md).\n\nFor more information on the concepts of CI matching and the CMDB, discovered item lookup, rule-based identification, see the [CI matching in Vulnerability Response \\[KB0998706\\] article](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0998706) in the HI Knowledge Base.\n\n### Procedure\n\n1.  Navigate to **All** &gt; **Security operations** &gt; **CMDB** &gt; **Discovered Items**.\n\n2.  Select the required discovered items and select **Actions on selected rows...**.\n\n3.  From the list, select **Reapply CI lookup rules**.\n\n    **Note:** You can skip the reapplication of lookup rules on discovered items with the substate ‘CI Decommissioned’ by enabling the system property **sn\\_sec\\_cmn.skipItemsWithCIDecommissioned**.\n\n    The rules are reapplied on these discovered items.\n\n4.  Select **View status** in the message.\n\n    The status displays on the background job form.\n\n    **Note:** In the **Notes** field, the `Discovered items could not be process due to exception` attribute with a non-zero value indicates that there’s an error or exception while reapplying a look-up rule. Check the system logs for more details.\n\n5.  Reapply only applies to items scanned within the last 90 days based on the **last\\_scan\\_date, last\\_comp\\_scan\\_date, non\\_infra\\_last\\_scan\\_date, non\\_infra\\_last\\_comp\\_scan\\_date** column.\n\n    Added ci\\_lifecycle\\_status\\_source \\(scope = sn\\_sec\\_cmn\\) system property for configuring CI lifecycle status columns \\(for example, Install Status, Operational Status\\). You can configure additional columns for retiring CIs.\n\n    Columns are added to the background job list view:\n\n    -   Elapsed Time\\(ms\\): The time required for processing the background job.\n    -   Items Processed: The number of items processed until now.\n    -   Total Items to be Processed: The total number of items remaining to be processed.\n    -   Time Until Completion\\(ms\\): The time remaining until the background job is processed. These columns provide visibility into job progress. These columns are available for each form view for you to add according to requirement.\n\n"}}