How does Kenna determine if an asset already exists?
Default Locator Order for De-Duplication
Kenna makes every attempt to de-duplicate asset data in the platform. Below is the order of preference (High to Low) given to asset locator data in order to assess if an asset already exists in the environment.
Important: The Crowdstrike Connector comes with its own default locator order. This is located on the Crowdstrike Connector page.
- Container identifier
- Image identifier
- EC2 identifier
- MAC address
- external IP address
- file name
- fully qualified domain name (FQDN)
- internal IP address (RFC 1918)
- scanner-specific asset ID (eg Qualys host ID, Nexpose device-id)
When assets are processed during connector runs, our system will start at the top of the list with #1. If there is a value in that field, it will compare it to all existing assets in Kenna. If it finds a match, it’ll update the existing asset with the current information from that connector run. If it doesn’t find a match, we will create a new asset. The only way it will continue to #2 and on down the list if there is no value in that field. For example with the list above, if we didn’t receive a container identifier, we will move down to an image identifier and try and compare with that data. If there’s no image identifier, it’ll move down to an EC2 identifier, etc until we can find a value to use for de-duplication.
For example, in a DHCP environment where internal IP addresses are being reissued, you must use a credentialed scan to bring in more specific information for each asset. This way IP addresses can be reissued to assets and be identified by another locator field. You also want to make sure that locator field is higher on the list than IP address. For example, using “hostname” and moving it up the list or using “MAC address.”
Custom Ordered Locators
The default order for locators can be adjusted both as a global setting or on specific connectors. If you would like to change your asset locator preference please contact Kenna support. The Kenna Support team can help you assess the optimal custom locator order for your organization by analyzing which locators are most duplicated.
When using a custom order on the connector, all assets brought in by that connector will be de-duped according to that connector's order and all other connectors will be de-duped according to the client order.
Custom order locators will not automatically be updated to include Container and Image locators. If you are using these for the first time, please contact Kenna Support to have them added to your custom list.
If you would like a full duplicate assets report for further analysis on how your primary locators are working, you can contact our Support Team.
Understanding Locators in the Kenna UI
One indicator of how your primary locator list is working is through the filters on the right side panel. Under Asset Filters are checkboxes that tell you how many/which assets were “matched” off of which primary locator.
For the example above, 1,634 assets were identified using MAC address, either because it was an asset with a new MAC address or de-duplicated because it found a match with an existing asset that had the same MAC address.
Important: When you are viewing assets in Explore, the top locator shown in blue does not correspond to the primary locator used to identify that asset. Also, the order in which the locators are listed does not correspond to the order being used to de-dupe assets. In this example below, these assets' primary locators are MAC addresses, but Hostname is shown first.
Using Mac Address as a Locator
Because different vendors represent mac addresses differently, we normalize how mac address is displayed in Kenna. This allows Kenna to properly de-dupe assets identified by mac address.
For all new customers, the setting is on by default (as of August 2021).
How it works
- Mac addresses are normalized to be colon separated and all capital letters.
- The mac addresses must contain 12 characters in order for de-duping to work.
- For assets with multiple mac addresses concatenated, we will lexicographically sort (order) the mac addresses, and then we will normalize the first mac address and null the others.
When bad data (any data that is not a mac address) is in the mac address field and there are other locators, we will not accept it and we will null the field.
When bad data is in the mac address field and there are not other locators, we will:
put in a placeholder hostname with “MAC ERROR: ‘insert_bad_mac_here’”
Make hostname the primary locator for that asset