How to fix a mis-matched CI manually?

[Kevin149]

Our CMDB is a bit of a mess (working on that as we speak) and I sometimes get VI's that are matched incorrectly to a CI.  Is there a way for me to just reassign a VI to a DIFFERENT CI without going and changing matching rules and deleting the CI table and re-importing vulnerabilities?  I want to be able to just say this VI = this CI and change the matching.  

[Vratislav]

Hello Kevin,

On what version of VR are you currently. Because is not just CI. The most important part is also detections table /sn_vul_detection/ and if you will just change the CI on VI it will be not helpful for you in the end, because any new vulnerability and probably even new detection of existing one should create VI based on the ci lookup rule. Basically, from my point of view, your lookup rules could be polished. You can even make some new table where it will be looking for CI. I don't really think that is a perfect solution but depending on the number of faults you got.

1. Something like mac|fqdn|IP -> reference to CI

2. Lowest order lookup rule to search only in the table

Option number 2 which I'm definitely not sure it will be working correctly, you can give it a try:

1. update record in sn_sec_cmn_src_ci table and change that incorrect CI to the desired one

2. Add vr_admin the possibility to update CI on VI

This could work also as it will search in Discovered Items table and using the already found CI

Definitely many will disagree with this approach, but I was in a similar situation so know that CMDB quality is crucial for VR project, but on the other side is a long run to achieve good quality in there.

Vratislav

[MGanon]

Instead of reassigning existing vulnerability items to different configuration items, why don't you close the VI and create a new VI with the same vulnerability but the different CI?

This will associate the vulnerability and CI that you want while maintaining history of the association that you deemed incorrect. This history may turn out to be valuable for your CMDB cleanup later.

[MGanon]

Short-term resolution

[Chris McDevitt · Accepted solution]

Kevin,

Typically, we try and not delete data in Production....

1. Adjust your CI Lookup Rules.

2. Close the incorrect VIs

3. Configure the Auto-Delete Rules to target the old / Closed VI

https://docs.servicenow.com/bundle/orlando-security-management/page/product/vulnerability-response/t...

4. Delete the Discovered items 

5. You may also need to delete any unmatched CI (If they are not associated with anything else...)

6. Reload the data

Test and perfect your CI Lookup rules in a lower environment.

• Most V10 integrations include a way to only pull the Hosts/Assets from the Scanner.
• • For example: "Qualys Host List Integration" only pulls the hosts from Qualys.
• Shift-Left (I get it, easier said than done....)
• • All hosts should have their Netbios name and FQDN configured at the OS level.
  • • (For your scanner...) All hosts should be in DNS (Think IPAM)
  • Make sure your Imports / Discovery integrations run before data import each day.
  • Make sure your data imports not creating junk.
  • Review the CMDB life-cycle practices of your organization
• Clean your CMDB (Duplicates, retired, junk, orphans, etc)
• Create a new CI Lookup rule to split the of the host part of the FQDN and Match in the "Name" field
• There is a good chance that you should set the rules to look at cmdb_ci_hardware for correct matches
• • Add rules to test at the cmdb_ci_hardware level first before a broader approach
• Consider setting the Install Status on your hosts, then add:
• • cmdbcihardware.addQuery("install_status", '!=', 7); //i.e. not “Retired"
• Tune all your other rules to NOT rely on the IP address rule. Buy the time it gets to the IP Address rule it is just a crapshoot.

People need to understand the VR becomes the acid test for your CMDB. Your CMDB will never be perfect, but VR will help improve its accuracy! 

Go ahead and mark this is a helpful or Correct!