Asset Identity Tools and Connectors

 

Customers can leverage identity tools from both the built-in identity engine and external connectors to improve the accuracy and synchronicity of asset identification.

 

Built-In Identity Engine and Active Fingerprint Query

Identity Engine

Cloud Control Center is shipped with a built-in identity engine with a large database of devices we can natively identify. This works best for IT and IoT devices such as desktops, laptops, printers, and a variety of other non-industry specific device types. No configuration is required for this identity engine to begin identifying assets on your network. Here is an example of a device that was discovered solely using our built-in engine. Note some of the data we gleaned about the device that can be used as match criteria during policy group creation such as Model, Device Class, Device Type, Vendor, Device Genre, etc.

 

 

Elisity uses multiple sources to gather accurate identifying information about device attachments. We use data from DHCP, MAC, Device Tracker, traffic flows, Kerberos and more to identify devices with context. A hierarchy of device discovery methods and process flows is available for customers who want a deeper understanding of our built-in discovery methods and how those work with external identity engines. 

 

Random MAC Detection

Elisity's built-in identity engine can identify and classify Random MAC devices. When a device with a randomized MAC address is identified on the network, the "Device Type" is classified as "Random MAC." You can then use this match criteria to form a Policy Group for any Random MAC device, or combine this match criteria with other criteria to form unique segments of Random MAC devices to be used as endpoints for policies. 

Note: As a default setting, Random MAC devices will show as offline 48 hours after traffic was last seen from the device. You can modify this value in Settings > Device Classification > Random MAC Expiration Timeout

Active Fingerprint Query Feature

To enrich data about operating systems and device level information, our Identity Engine has configurable active query OS detection that scans devices in two ways. 

1. Dynamic OS Queries for Devices Discovered by Device Tracker

Customers can choose to enable device tracker on select switch ports, which comes with a host of benefits from a device discovery perspective. On those Virtual Edge Node switch ports with Device Tracker enabled, we dynamically scan any discovered device for operating system data. This additional scanning for OS on top of Device Tracker is optional for customers with highly sensitive environments. Note that when this feature is enabled, it only applies to those switch ports with Device Tracker enabled. Note that this feature is disabled by default.

To enable this feature, navigate to Administration > Settings > Device Classification and toggle the box labeled "Enable Active Fingerprint Queries."

 

 

2. Scheduled OS Queries 

Customers can schedule targeted OS Discovery Scans for select subnets on Virtual Edge Nodes. This would be utilized in environments where Device Tracker has been disabled as performing a scheduled OS scan in an environment with Active Fingerprinting would be redundant. 

To utilize scheduled OS Scans, the user must first create a Device Discovery Profile. The Device Discovery Profile is used to target certain groups of assets and exclude any assets that the user does not wish to scan. Navigate to Administration > Settings > Device Classification and click the button labeled "Add Device Discovery Profile."

 

 

When creating a Device Discovery Profile, users need to fill out the following fields.

 

Below is an example of a completed Device Discovery Profile.

Scheduling an OS Scan

Now that our device discovery profile is active, we can schedule our OS Scan. First we must enable Active Fingerprint Queries. When Active Fingerprinting is disabled, and attempted OS Scan will fail, and you can also see if you click on the "more options" button on one of the device discovery profiles that you are unable to run or schedule a discovery scan.

 

With Active Fingerprinting Queries enabled and our Device Discovery Profile created, we can now schedule and run a Discovery Scan. To immediately run a scan, click Run Discovery Now. To schedule a scan for a certain time and date, click Schedule for Later. First select your time zone preference (Coordinated Universal Time or Local Time) then click the calendar icon to schedule a date and time for the scan to be ran. Click on the date on the calendar, then click select time to choose precisely when the scan will begin.

 

In the status column you can see the progress of FAILED, PENDING, IN PROGRESS, and SUCCESSFUL scans. You can also see the next scheduled scan, when the profile was created, and other relevant information.

 

Note: The size and number of subnets directly impacts the time that a scan will take - you can assume roughly 4 IP addresses scanned per second.

 

Here is an example of how these scans improve OS detection. The first image shows Operating System data for a given device before Active OS Fingerprinting. The second image shows additional data gleaned post-scan.

Active Directory

Our agent for Microsoft Active Directory enables customers to use user identity data in policy, as well as real-time monitoring of events such as login, user identity changes, and device attachments as all user and device Kerberos events are reported to Cloud Control Center. The agent can be run on multiple servers for redundancy in the case of issues with a server. Users can quickly onboard their Active Directory servers using our connector, sync data about all users and computers, and begin using that data to build Policy Groups in a matter of hours, depending on the size of the organization.

Below are some examples of the data we gather and how it can be used in Policies. 

 

 

Device Policy can be created around whether a device is known in Active Directory, helping organizations limit network access for any devices that are unknown to the organization with policies.

  

 

Users can also check the status of all Active Directory Connectors deployed throughout their network within Cloud Control Center within the Connectors page. 

 

Note: Active Directory imports all devices in the domain that you choose to onboard. If these devices do not attach to the network for us to glean additional identifying data, these devices will likely fall in the "Unclassified" Policy Group due to the lack of identity data that is often found in Active Directory.  In many cases we match on device attributes like Device Type or Device Class. For user-based PCs, these are often associated with a user and inherit those attributes. For cases where the device has not attached to the network, we only have data that is available in Active Directory. Example Device Attributes from AD before an attachment: Example of additional Device Attributes after an attachment:

 

For server requirements and installation steps regarding our Active Directory Connector App, please review Connecting Microsoft Active Directory.

 

Claroty

Elisity supports simple API connectivity to Claroty as a method to enrich Operational Technology (OT) device discovery and identity.

 

The way this integration works is simple but powerful. After onboarding the connector in Cloud Control Center, we import your list of devices and identifying data from Claroty into our device inventory in Cloud Control Center. We merge data from the two sources to increase the accuracy and granularity of device identification, which then better informs how devices are matched to policies.

Below is an example of some of the OT device data that has been enriched by our connector with Claroty.

 

 

For more information about our API connector with Claroty and instructions on how to set up the integration, please review our Connect Claroty article.

 

Medigate

Similarly to our Claroty CTD Connector, Elisity supports simple API connectivity to Medigate as a method to enrich Medical device discovery and identity.

 

This integration works by polling customers existing Medigate deployment via API calls to retrieve data about any device that is discovered by Elisity. When a device attaches to your Elisity-secured network, data regarding that device is sent to the Medigate instance in an attempt to match the device. Any valuable data about that device is returned to Cloud Control Center, and merged with existing device data in Cloud Control Center. You can then use that enriched data to build granular identity-based policy for your medical devices that leverages Medigate as a source of truth for asset identity. Medigate is actively polled for any new device, but you can also sync Medigate at any time from the Connectors page to poll Medigate for additional data for your medical device inventory.

For an in-depth guide on how to set up our Medigate connector, please visit our Connect Medigate Article.

ServiceNow CMDB

Our simple API connection to CMDB enables our customers to further enrich device discovery and identity data. 

 

 

This API Connector works by importing your CMDB database of devices into the Device Inventory found in Cloud Control Center, along with all the identifying data about those devices. We then merge the data from ServiceNow and Elisity's built-in identity engine for any devices discovered on your Elisity-secured network. This means that all the work you have done to organize, categorize, and identify assets known by your organization can be leveraged into actionable network policies. 

We can create Policy Groups (groups of assets used as the endpoints for policy) for devices that are known in CMDB to be leveraged in network access policies. You could use this to limit network access of any devices that are not known in the CMDB, or reserve access to select resources for only devices that are known in the CMDB. Below you can see what this might look like in a Policy Group declaration.

For more information about connecting your CMDB to Cloud Control Center, please review our Connect ServiceNow CMDB article.

 

Utilizing Manually Verified Match Criteria

Another notable feature of our platform is the "Manually Verified" match criteria for Policy Groups. This powerful capability empowers administrators to enhance the security of identity-based policy groups by implementing an additional layer of authentication. By manually verifying assets within the Cloud Control Center, admins can confirm the authenticity of devices and establish their association with the organization. This feature becomes especially valuable when building highly secure policy groups for critical assets, ensuring that only assets that have undergone rigorous admin review can access these sensitive resources. With the ability to establish trust and control over verified devices, organizations can reinforce their security posture and minimize the risk of unauthorized access to their most crucial assets.

To leverage "Manually Verified" match criteria, first add the match criteria to your policy group. This can be found in "Trust Attributes" for Devices. 

 

Now you need to review the assets you want to be permitted into this Policy Group. Find your devices in Cloud Control Center, verify them, and edit the device by clicking the three dots and clicking edit.

You need to modify the attribute column "Admin Verified" and select "yes" for the asset to be permitted to our Policy Group. If this is set to "no" or is left blank, the asset cannot be included in our verified Policy Group.