Reapply CI lookup rule not changing to a found CI

[Andrew Cocker]

I seem to have found an issue that maybe someone can help me with. Prior to this release (16.1.1) if I had an unmatched discovered item which created a ci in either the custom tenable or Qualys tables, changing the CI lookup rule and then reapplying the rule, the Discovered item would correctly pick up the existing CI record and update (matched) with the VIT linked to the correct CI.

With the newest version of vul, if a CI is created by the Discovered Items not being able to match with the rules, it creates a CI in the Unclassified Hardware table. Rerunning an updated rule against that SDI record will find a match but fails to update either the SDI or VIT record to reference the correct CI. I've added some logging to the rule script and can see that it is finding the correct ci but won't correct the reference. 

Step to recreate. 

Open Discovered Items. Find an unmatched record that has created a CI in Unclassed Hardware where there is a matching item in the CMDB. 

Create or alter a CI lookup rule that would have found the correct CI record. 

Select the Discovered item in question and choose "Reapply CI lookup rules" to that record. 

Result: rule finds the real CI and returns the correct sys_id. VIT and SDI are not updated. 

If the Unclassed Hardware record is deleted first, it will recreate it and reference that record instead of the "found" ci record. 

[Chris McDevitt]

Hi,

• Is the item a "duplicate" in the CMDB? Check the "Duplicate of" field.
• Is the item "Retired" in the CMDB? Check the Status and/or Life Cycle State Status

If the answer is yes to either of these questions, the CI is "filtered" out and it will not match.

[Gagandeep6]

Hi,
i am facing similar issue, The discovered item is not matching the right CI as this CI has "Duplicate of" field populated with the Unclassed Hardware CI. Do you have any suggestions for this situation ?
TIA

[Andrew Cocker]

Thanks for the info. 

It looks like "retired" is the issue. The CI name is duplicated between hardware and IP address but doesn't show up on the SDI record as a duplicate. 

The client has a custom matching rule just for retired items as their discovery feed is showing a large number of their IP switches as either offline or retired. A known issue in their estate which nobody has been able to correct. To work around this, the vulnerability CI matching rule was made just to match to retired items in one specific class. (net gear) This rule has been working fine until the upgrade of Vul to version 16.1.1. 

However, Tenable and now Qualys are finding these devices still active and connected with validated vulnerabilities. If as you say it is now ignoring retired items, even though the rule is finding them and returning the correct sys_id to the matching job, it is going to be a big issue for them. 

If there is no way to have the matching job include retired items, I'm going to have to kludge this to get it to work for this client. 

Maybe, "re-animate" the CI inside of the matching script in order to see if the rest of the job will pick it up as active and correctly reference it. 

The alternative would have a scheduled job that hunted down any unfound CI records against ones that are retired, change the state, then force a rerun of the CI matching. (ugly kludge) 

[Chris McDevitt · Accepted solution]

Or just turn this feature off 😉

Retired

sn_sec_cmn.filterOutDecommissionedCI = false

https://docs.servicenow.com/bundle/sandiego-security-management/page/product/security-operations-common/task/filter-decommissioned-ci.html

Duplicates..... 

IF the duplicates are of the same Class (table) THEN those need to be cleaned up...

https://docs.servicenow.com/bundle/sandiego-servicenow-platform/page/product/configuration-management/concept/de-duplication-tasks.html

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0869861

VR is pretty good at working with bad or no CMDB data... but some things just need to be addressed by the customers if they want good results. 

¯\_(ツ)_/¯