Vulnerable Item CI lookup Rule

Mike_R · ‎04-28-2020

Hello,

We're having some difficulty with how the Vulnerability Response module chooses CI.

Say our cmdb looks like this:

Name	Class
ws-servera	Windows Server
ws-servera	Virtual Machine Instance
ws-servera	Storage Volume

When the VI is created it should match on Windows Server, but instead we're getting a lot of Virtual Machine Instance, DNS Name, and other matches. What's the best/cleanest way to reconcile without loosing historic data?

Mike
* My Collection of ServiceNow Stuff *

Chris McDevitt · ‎04-28-2020

Mike,

To fix this going forward, you will need to tell it to 'ignore' the classes you do not want it to match against.

https://docs.servicenow.com/bundle/orlando-security-management/page/product/security-operations-comm...

Next, you need to know that once an item is "matched" and a record is placed in the Discovered Items module, that match will be used gain. Long story short deletes the incorrect march from the Discovered Items module after using the Ignore CI Class System Property.

(This is different VR v9 vs. v10)

"What's the best/cleanest way to reconcile without losing historical data?"

I am going to assume that this is already in production?

If not you need to delete the VIT, VID (v10), M2M, Vul, and SDI records and reload.

If you already have this in production, you have a bit more of a challenge.

This is what I would do:

1. Look at the VIT and get the 'CI name' and test to see if it is in a class you do not want. Use the 'CI name' to ONLY look in the class(s) you want it to match against and update the VIT.

2. You will need to return the assignment rules (v9 you will need to script, v10 is not built-in)

3. If the underlying VIT support team is now different than the Vul Grp you will need to update the Vul Grp Assignment Group from the VIT Assignment Group.

Assumptions

You VGR had Assignment Group pointing to the VIT
That the underlying VIT does not change the way, the VGR would have grouped them.

Go ahead and mark this as helpful or Correct!

View solution in original post

Chris McDevitt · ‎04-28-2020

Mike,

I never said this was easy!

🙂

First off test this in a lower environment:

//Test this out in a Background or Fix Script as the Platfrom Admin in a lower i.e. not production
//Make sure the table "Appliation Access" : "Can Delete" is checked
//Get the sys_id of a Discovoerd Item and add it below
var di = 'fb22e21bdb181494ae20309d7c9619b5';//i.e. SDI000000066216
var gr = new GlideRecord('sn_sec_cmn_src_ci');
gr.get(di);
gr.deleteRecord();

//Then
//Again in a lower environment.
deleteDiscoveredItems();
function deleteDiscoveredItems(){
var gr = new GlideRecord('sn_sec_cmn_src_ci');
gr.query();
gr.setWorkflow(false); //Do not run business rules
gr.autoSysFields(false); //Do not update system fields
gr.deleteMultiple();

}

Next...

You can delete these record without impact to you existing VITs. (again test it out in you lower environment and see if that is true for you).

True, you will now know why "host001" matched on a your virtual machine instance in the past and "now" there is no history. You could update the work notes in you delete script if this is an issue. (Find the DI, look at its CIs and update their records; then delete the DI)

Mike_R · ‎04-28-2020

Thank you!

I ended up taking another approach rather than deleting & reloading the Discovered Items.

It was a bit more manual but I:

1. In the Discovered Items module, I found the classes that I did not want to use.

2. I updated the CI in the Discovered Item & related VITs to point to the new CI (in the correct class).

I ran the Qualys scan after and everything seemed to be good. Records were updated correctly and no duplicates.

Thanks for your help!

Mike
* My Collection of ServiceNow Stuff *