Customers can leverage identity tools from both the built-in identity engine and external connectors to improve the accuracy and synchronicity of asset identification.
table of contents
Built-In Identity Engine and Active Fingerprint Query
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.
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.
| Profile Name | Give the profile a distinct name |
| Discovery Type |
Choose the type of scan you will be performing. |
|
Discovered by Nodes OR Subnets |
Select how you want to organize your scans by selecting subnets or Virtual Edge Nodes as the scan destination. |
|
Node or Subnet Information |
Automatically discovered Virtual Edge Nodes or Subnets will populate here, depending on the selected discovery.
|
| Exclude Hosts |
Any hosts that the user does not want to be included in the OS Scan can be included here. Enter the IP addresses, separated by commas. |
| Set Purdue Level | (Optional) This option can only be configured if creating an OT scan profile. |
Below is an example of a completed Device Discovery Profile.
Note: After deploying a Device Discovery Profile, you can edit excluded hosts to include or remove additional hosts. The other fields are fixed after submission.
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.
For server requirements and installation steps regarding our Active Directory Connector App, please review Connecting Microsoft Active Directory or our additional guide for Installing Our Active Directory Connector on Domain Controllers.
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.