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 

[JenniferRah]

I believe this is determined from the Assignment Rules table (sn_vul_assignment_rule).

[PaulSylo]

Thanks, Jennifer, But how can two infra vulnerabilities for the same host be assigned to two different teams?

[JenniferRah]

It depends on your rules and what order they are in and what records they check. You would have to look at each rule, in order, to see if they apply to each vulnerability to answer that.

[andy_ojha]

Hey there,

This scenario does tend to pop-up and can be treated.

Those virtualized assets can be represented in both forms of 1) the actual Server (Windows, Linux) and 2) the virtualized "pseudo hardware" of the virtual machine when populated in the ServiceNow CMDB.

Depending on your VR Scanner with SecOps Vulnerability Response, you are more than likely going to care about the "hardware" layer here - i.e. the actual Windows Server OS and components - especially for "Host/Infrastructure VR" such as with Qualys VM, Tenable, Rapid7, etc.

Your SecOps CMDB CI Lookup Rules can be tuned in one of two ways for the particular scanner integration:

1) Prioritize CIs derived from the Hardware class first (so that any CI Classes extending from Hardware are selected first) - this tends to shape CI matching to the Windows Server rather than the Virtual Machine Instance since that Class is not extended from Hardware.   

2) A bit of a more "big hammer" approach, would be to ignore matching to CIs in the Classes you specify, such as VMware Virtual Machine Instance, Virtual Machine Instance, etc.
 - System Property: sn_sec_cmn.ignoreCIClass 

 - https://www.servicenow.com/docs/bundle/xanadu-security-management/page/product/security-operations-c...

There are some really good SecOps CMDB matching tuning tidbits here as well:

- https://www.servicenow.com/community/secops-articles/servicenow-vulnerability-response-ci-matching-t...

- https://www.servicenow.com/community/secops-forum/recommended-practices-for-ci-matching-success-cust...