VIT assigned with wrong Assignment group

[PaulSylo]

Hi Experts - I have an issue.

I see two CIs in the CMDB with the same name, `WEBFE01`, but different classes: one is classified as a `Windows Server`, and the other as a `VMware Virtual Machine Instance`. The support group assigned to the `VMware Virtual Machine Instance` class is `Apps_Operation`, while the support group for the `Windows Server` class is `Windows Team`.

When a Vulnerability Item (VIT) is created for `WEBFE01`, it is being assigned to the `Apps_Operation` team based on the CI name. However, it should be assigned to the `Windows Team`, as they are responsible for infrastructure support. Since the VIT only includes the **Configuration Item (CI)** field, how can we ensure that the correct team is assigned? This mismatch is causing tasks to be assigned to the wrong team. how to fix this 

[PaulSylo]

Hi @andy_ojha /Andy,

Thanks for your message. This is indeed showing me a bright path. I have to question following up on this.

1. Do you mean changing or editing the "Lookup rules for HOSTname" to prioritize the hardware class? if so, if this need to be in the script? or how to do this ?

2. What will do to the VIT which got created already on the Psuedi layer? tis need to be closed or deleted?

[andy_ojha]

Hey there...

Yes, it depends on the scanner at hand the data point being used for the rule - but the idea is to have a rule that initially starts it search/query on the hardware table first (and all tables that extend from hardware)...

That way, you'd match to the Server CIs in this case over the VMware Instance (it also helps bypass other troublesome classes like DNS, Websites, Certificates)... 

In this manner you'd be inclusive about what you want to attempt to match to first, before falling back a more broad search spanning the CMDB at large...

Splitting up your rules gives you good insight for troubleshooting as well as you can see which Rule wins on a Discovered Item...

You could look at the Re-applying the CI Lookup Rules with this System Property in play:

• sn_sec_cmn.update_on_ci_change
• https://www.servicenow.com/docs/bundle/xanadu-security-management/page/product/vulnerability-respons...
•  This will help with the existing Detections and VITs - re-evaluating them thru core logic like Assignment Rules, Risk Scoring, etc when the CI value on them changes (e.g. from VMware Machine Instance to a Windows Server)
• https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1120438

[Theresa Messeng]

With assistance from our implementation partner, we built a class 'inclusion' solution instead of using the OOB 'exclusion' logic.  This increased our CI matching accuracy by at least 15%.  

Personally speaking, I just do not understand why it is OOB to use the exclusion logic rather than inclusion.  Inclusion is so much more efficient and accurate.

[PaulSylo]

Thanks for your comments @Theresa Messeng , can you explain in detail, what are the option you have tried?

[Theresa Messeng]

Basically, the script was set up to use a system property that contains a list of allowed classes to match to.  If the class is not in the list, then a match will not be allowed. This helped clean up a lot of erroneous matches.   I sent you an IM in case you want to discuss in more detail.

**In my previous life as a Configuration Management Process Owner, I loathed the VMWare Virtual Machine Instance CI's.   haha