Overview
Vulnerability Response CI matching can be a challenging and a difficult thing to get right. For effective CI matching there are a few key things to keep in mind. This article is intended to help you understand how to tune your CI Matching logic to work as effectively as possible with the data that you have available.
Background
The process in which asset/vulnerability data from the third-party scanners, such as Qualys or Rapid7 are then reconciled within ServiceNow Vulnerability Response is already well documented in; CI matching in the Vulnerability Response. To help you better understand how to 'tune' your CI matching logic, you need to know where the problems can happen. The basic overall flow is described in the following diagram.
There are three lookups where Vulnerability Response CI matching can potentially not work as expected.
1. Lookup in Discovered Items
Vulnerability Response will try to identify if the asset information returned by the scanner was already matched with a CI during the previous runs of the third-party scanner. Vulnerability data returned by third-party scanners such as Qualys or Rapid7, contains a unique ‘Asset ID’. This is the identification of the asset (for example, Windows server or Tomcat application) containing the vulnerability.
The “Asset ID” is used to find an existing match with “Source ID” in the Discovered Items table. If the Discovered Item was matched incorrectly in a previous run, it will continue to use the CI referenced in the Discovered Item as the ‘matched’ CI.
2. Evaluate CI Lookup Rules
If no match can be found using the Asset ID to Source ID in the Discovered Items table, then CI Lookup Rules are used to try and reconcile the Asset to an existing CI in the CMDB. There are two types of CI Lookup rule methods:
- Field matching: In this method, the value of one of the fields in the API response from scanners can be used to query a specific field in a specific table in CMDB.
- Script: In this method, you can write a script to implement the more complex logic of a lookup rule by potentially querying multiple CMDB tables based on different criteria or conditions.
3. IRE used to find a match
At this point the Asset was not able to be reconciled with an existing CI. An Unclassed Hardware record has been created to allow the Vulnerable Item to be created with a CI. IRE is then utilized to try and find a match with an Unclassed Hardware CI andcan potentially reclassify the Unclassed CI to the correct class with data brought in from a CI discovery source.
Configuration Item Matching Tuning Methods
- For Matched Discovered Items that were improperly matched. Evaluate your CI Lookup rules and make any necessary adjustments.
- Utilize the “Source Data” field on the Discovered Item to make sure you are using the right data to match
- Example – Hostname/FQDN attributes are as you expect (hostname contains a NAME value and not a FQDN value).
- Re-order the rules to use the best matching logic that makes sense for your data
- Example – IP Address rules should not be evaluated first, instead use MAC address or NAME rules first.
- After you make adjustments utilize the Reapply CI Lookup rules logic to reevaluate any improperly matched Discovered Items
- For Unmatched Discovered Items where you have reconfigured/new CI Lookup rules you will want to utilize the Reconcile Unmatched Discovered Items. This will re-evaluate the Unmatched CI through the CI Lookup rules and determine if a matching CI can be found.
- Utilize system property settings when running CI Lookup Rules to take advantage of OOTB features:
- sn_sec_cmn.filterOutDecommissionedCI
- Filter decommissioned CIs while running the CI lookup rules. Filter decommissioned CIs when running the Security Operations CMDB CI lookup rules
- sn_sec_cmn.ignoreCIClass
- To ignore some configuration item (CI) classes, for example Load Balancer [cmdb_ci_lb]
- sn_sec_cmn.autoPromoteFields
- Property should include classes you want to use the related parent CI as a match, example VMWare NIC [cmdb_ci_vmware_nic]
- Evaluate the “Hardware Rule” Identifier Entries attributes. You may need to add/modify Identifier Entries attributes to include additional “Criterion attributes” to include attributes that you can use to match existing Hardware CIs.
“Tuning” your CI Matching logic is an activity that takes time and more than likely a few iterations to get it right. The main other factor that can affect your matching rate is the completeness and accuracy of your CMDB, if your CMDB does not have the same set of data that your third-party scanner is scanning, you will more than likely have a lower match rate. The more “Unmatched” CIs you have the less automated triage logic you can perform (auto assignment, risk score accuracy based on CI attributes, etc.). The following shows some common CI Matching issues and where to start troubleshooting:
Helpful links and videos
ServiceNow Documentation
CI Lookup Rules for identifying configuration items from Vulnerability Response third-party vulnerab...
Steps to help prevent duplicate or orphaned records after running Vulnerability Response CI lookup r...
De-duplicating existing configuration items
Creating CIs for Vulnerability Response using the Identification and Reconciliation engine
Identification and Reconciliation Engine (IRE)
Creating CIs for Vulnerability Response using the Identification and Reconciliation engine
Reapply CI Lookup rules
Reconcile Unmatched Discovered Items
Ignore CI classes
Filter decommissioned CIs
ServiceNow Support
CI matching in the Vulnerability Response
KB Articles - CI Matching
You Tube Videos
CI Matching for Vulnerability Response - How to get it right.
Vulnerability Response End to End Demonstration
Vulnerability Response and your CMDB
Other helpful links
Partner Portal and Customer Success Center, are great resources where you can find best practices for Security Operations, and more.
.png){kind=link}
