Reapply CI lookup rule not changing to a found CI

Go to solution
Andrew Cocker
Kilo Contributor

‎04-22-2022 04:03 AM

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. 

 

Labels:
0 Helpfuls
  • 2,518 Views
1 ACCEPTED SOLUTION

Go to solution
Chris McDevitt
ServiceNow Employee
ServiceNow Employee
In response to Andrew Cocker

‎04-23-2022 07:19 AM

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. 

¯\_(ツ)_/¯

 

 

 

View solution in original post

0 Helpfuls
5 REPLIES 5

Go to solution
Andrew Cocker
Kilo Contributor
In response to Chris McDevitt

‎04-24-2022 03:06 AM

Thanks again. They did a big de-dupe a while back and actually their CMDB is one of the better ones I've come across. It is just for some reason Discovery can't see the switches at times and after a while they get classed as retired, only for them to appear in vulnerability scans. 

I was hoping there was a property after your response, but just haven't had a chance to go hunting for it. Thanks again for saving me a lot of time. 

 

0 Helpfuls