Why is CI Matching rule not empty for Unmatched Discovered Items

Patrik Z · ‎11-03-2023

Hello,

the client has some Unmatched Discovered Items in ServiceNow but the CI Matching Rule is populated nonetheless. How is that possible? "Unmatched" should mean the asset wasn't matched to any CI by any of the CI Lookup Rules?

Does anybody know, please?

Thank you

andy_ojha · ‎11-03-2023

Hey there - that is a great observation.

The trigger behind the State of the Discovered Item, is not trivial.

The State of the Discovered Item, is not driven by the concept whether a SecOps CI Lookup Rule was used or not - rather, it is simply based on the Class of the CMDB CI being referenced on the Discovered Item.

It is expected to see the scenario you describe - for the different 3rd party scanner vendor integrations out there - and it is a good thing (it is not a problem nor something to fix)...

When a Host comes into from the SecOps VR integration, the query to find a matching CI will scan SecOps related CI Classes as well, among your other expected CI Classes / tables in the CMDB (like Computer, Server, etc)...

-> This includes Unclassed HW, Incomplete IP, Cloud Resources, Unmatched CI

The Discovered Item State - really represents the nature of the referenced CMDB CI value itself:

Matched - Reflects the CI being referenced on the DI, was in the CMDB and SecOps VR matched to it
Unmatched - Reflects the CI being referenced on the DI, is in the unknown bucket (not present in the CMDB before SecOps brought it in)

Consider this scenario:

Day 1
- Host brought into ServiceNow
  - Source ID = 123456
  - IP = 192.168.4.5
  - Name = Server-12345
- Result -> No matching CI found, new CI created in Unclassed HW
- DI.State -> Set to Unmatched, as the CI Class is Unclassed HW
- DI.Lookup Rule -> Empty
Day 27
- Host brought into ServiceNow
  - Source ID = 987654
  - IP = 192.168.4.99
  - Name = Server-12345
- Result -> Matched to an existing CI -> the Unclassed HW previously created on Day 1
- This is good - you do not want to create duplicate CIs
- DI.State -> Set to Unmatched, as the CI Class is Unclassed HW
- DI.Lookup Rule -> Will reflect what particular rule won

This is helpful - because you do not want to create another CI in Unclassed HW and be left with a duplicate in this situation, it is appropriate to match to the existing Unclassed HW.

Many vulnerability scanners will present the scenario where the Source ID can change over time - even though it references the same theoretical host (consider Qualys, when an IP address changes on a given host or a new IP interface is introduced --> a new Host ID is generated, and this is what maps to the Source ID on the Discovered Item).

View solution in original post

andy_ojha · ‎11-03-2023