Failed CI Matching Against Devices with Virtual Network Adapter Address
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
8 hours ago
Hello, not sure if anyone has come across the following scenario: We're seeing a lot of "Unmatched" CI's in discovery, where matching fails using "Mac Address"(Configured as the 'primary' matching criteria) in our Microsoft TVM integration for ingesting our workstation vulnerabilities.(many of these workstations are remote VPN'd in) On further review of the integration's "Source Data" field in "Discovery", we are seeing multiple instances where the "Mac Address" value is default pointing to a static/redundant "Virtual Adapter" address(most likely due to the fact that many of the devices are VPN'd in) instead of a physical adapter. In an attempt to work around the Virtual Adapter address value being assigned the primary adapter, I am attempting to leverage the "Mac Addresses" value in the integration's Source Data" by creating a scripted "Mac Addresses" rule that grabs and iterates through the "Mac Addresses" string of various adapters in the field and checks/ignores any "Virtual Adapter" addresses in the string as well as other scenarios we've encountered. (aka. Empty values, formatted vs unformatted MAC addresses etc.) The script itself appears to work fine, and returns both a formatted and unformatted MAC Address of a valid adapter to be used for matching. However, it doesn't look like the CI Matching rule works when we tried testing it against individual "unmatched" CI's in "Discovery". (I'm seeing "Undefined" in the system log) I'm assuming that either the "Mac Addresses", "Source Data" value can't be used (as it's a non-standard matching criteria) or that perhaps an import map script needs to be used to correctly map this value. Also not sure if this is the correct way to go about fixing this "Virtual Adapter" issue. (Perhaps should this should be done at the IRE level?) Any assistance is greatly appreciated!