Vulnerability Response creating CI's of multiple classes.

[BradleyGSource]

Hey Folks, I'm hoping that the hive mind can help guide me a bit here. We have recently been reviewing records in the CMDB and have identified that the VR.System is creating thousands of CI's. My understanding was that, if the host that is imported from Qualys cannot be matched using one of the 'CI Lookup Rules' then a CI would be created in either the 'Unclassed Hardware' or 'Incomplete IP  Identified Device' class.

The main class that is being created is the 'Cloud Resource' class however there are also CI's being created with the following classes:

'Computer', 'Linux Server', 'Server', 'Virtual Desktop', 'Windows Server' as well as the expected 'Unclassed Hardware' and 'Incomplete IP  Identified Device'.

Does anyone have an idea why this is happening? Is this expected behaviour? How can this be prevented. It's causing us a lot of issues and is impacting our licensing.

Many thanks!

[andy_ojha · Accepted solution]

Hi there,

This new behavior appears to have been introduced ~Feb 2023 release of the Qualys VR Store App from ServiceNow. 

Unfortunately, the behavior of creating CIs in the Cloud Resource CI Class AND blocking SecOps CI Lookup Rules from matching to CIs in the CMDB when they are Cloud based - are both not fully documented today.

That said, you should not see brand new CIs being created in Computer, Server, Linux Server, Windows Server, etc from VR-System or VR-Qualys sources.  CIs in those classes might be matched to, or we might've created CIs in Unclassed HW that were later re-classified by IRE into those proper CIs classes (e.g.Computer, Server, Linux Server, Windows Server, etc) but VR should not be directly inserting into those CI classes.

As of now, the tables / classes that VR / VR-Qualys should be inserting CIs into (if no matching CI is found), are:

• Unclassed Hardware (IP + another attribute provided by scanner)
• Incomplete IP (only IP provided by scanner)
• Cloud Resources (host from scanner has a cloud resource ID / object ID from cloud tenant provider like AWS or Azure)
• Unmatched CI (error occurred when CMDB IRE tried to process the host from scanner)

In summary, the recent "Cloud Resources" changes impacts a few things (for net new installs, or upgrades of existing installs):

1. When a Host from Qualys is derived from a Cloud provider / tenant (e.g. AWS or Azure) - the Discovered Item's "Asset Category" is set to Cloud rather than "Infra" - which is expected and a neat feature
2. The majority of Qualys SecOps CI Lookup Rules (e.g. DNS, NetBIOS), all have a stubborn condition on them that blocks the rule from executing if the Asset Category is Cloud - this prevents a Windows Server on Azure form being matched to a CI in the Windows Server Class in CMDB
3. When a host from Qualys derived from a Cloud Tenant is brought into ServiceNow and cannot be matched to an existing CI in the CMDB, a CI record is created but not in the Unclassed HW Class, but rather in the Cloud Resources Class
4. CI's created in the Cloud Resources Class are not always created with the most appropriate name - you will see some of them created with "/subscriptions/xxx/xxx" - i.e. the 'Object ID' / 'Resource ID' rather than the proper shortname sent by Qualys 

ServiceNow should be publishing a KB Article shortly - that better describes the enhancements and will possibly also offer a way to revert these changes to make it work the way it used to (create the CIs in Unclassed HW rather than Cloud Resources, remove restriction from blocking Cloud gear against traditional CI Classes in CMDB like Windows Server, create new CIs with a proper name).

For tracking purposes, you may want to create a NOW Support Case and also relay your observations, concerns and desired behavior of the ServiceNow Store App for Qualys VR.

CC: @Siva Reddy 

[Raghuveer Moort]

Hey @andy_ojha , could you share if Support team have advised with any KB article on the fix or workaround for the situation highlighted in your response. 

specifically on the 4th points, where CI's landing at Unmatched HW class with "/subscription/xxx/xxx/..."

[andy_ojha]

Hey there,

This is the temporary KB Article that was released for the Cloud Resource and SecOps VR observations:

• KB1497138

Right now - with the current behavior, if you opt to keep the method of the unknown cloud based hosts being created in the Cloud Resource Class, a gap still exists where hosts are created with the poor name from the cloud resource object id -> "/subscription/xxx/xxx/..."

You really should not see Unmatched HW Class CIs getting created with that "/subscription/xxx/xxx/..." name - but either way the method to address that will require the same work - and unfortunately, this was left out of the current KB article that was published

This requires modifying the 'Host Import Maps' via table = 'sn_sec_cmn_src_cmdb_map'

• Today for CIs created in the Cloud Resource table it favors (via the lower order number) the Object ID 
• A configuration can be added to prioritize another object from the scanner that is more appropriate - e.g. name or netbios

Would suggest creating a Support Case if you are seeing that behavior in the Unmatched HW CI Class - as this gets tricky to address AFTER the CIs are already created and data is being imported.

[Sangeetha6]

@andy_ojha 

Hi Andy, 

I need your help.

In my case we have 4 detections which are with different Hostname, IP address and NetBios. From this only one detection has correct CI name example: "ABC" as in VIT CI "ABC" and rest of the different host name based detection three other detections are also updated with same "ABC" CI but it is suppose to detected under different CI.

have you faced this kind of scenario earlier.

While analyzing this issue, found "ABC" CI server is physical server and rest of three ci servers are virtual and virtual server has the same serial number, asset tag as similar to physical server "ABC". Is it because of same Serial number available for these 4 different CI ?

What could be the reason for this ?

Thanks in advance.