IdentityGraph™

 

What is IdentityGraph™?

IdentityGraph™ is Elisity's asset identity engine developed to address the challenges faced by modern network administrators in managing and understanding asset identities. IdentityGraph™ has been engineered to process, refine, and present identity data in a manner that provides a holistic and clear view of all network assets. 

In contemporary network infrastructures, organizations are often using a variety of identity tools to assist in discovering and identifying assets on their network. These assets may be managed by different departments, with varying levels of data maintained that is often fragmented or even conflicting across different identity sources.

For instance, one source might identify a device based on its MAC address and vendor type, while another provides data regarding its operating system or its last known user. Combining these disparate pieces of data into a single source of truth is crucial when it comes time to enforce identity-based policy for assets dispersed throughout your network. The problem is, creating this single source of truth isn't just tedious; it's often not feasible given the dynamic nature of modern networks where new assets are connecting to the network and new data is available every hour.

IdentityGraph™ provides value to network administrators by automating the process of data reconciliation and providing a single, reliable source of truth for asset identities. This reliability ensures that when policies are enforced or assets are tracked, decisions are based on accurate, consolidated data. As a result, organizations can be confident in knowing that their assets are classified correctly, and therefore the correct network policy is being applied.

 

How IdentityGraph™ Works

 

Device Discovery and Data Aggregation

The initial step for IdentityGraph™ is device discovery. As assets connect to the network, various data sources are used to glean identifying data about these devices such as DHCP, IPDT, Radius, CDP/LLDP, to name a few. This data is collected via carefully filtered ERSPAN, and API integration with onboarded switches. IdentityGraph™ uses this data to then query all available connectors and Identity sources. This involves harnessing data from Elisity's Native Identity Database, Active Directory, Claroty, Medigate, and your CMDB, among many others, and aggregating all this data into a single source. The goal here is to cast a wide net, ensuring that no relevant data is overlooked.

You can see much of the high level device data above the IdentityGraph section. Here you can see:

1. Location Information

    Virtual Edge and Virtual Edge Node from which the device was discovered, as well as Site Label association.

2. Policy Details

    Policy Group and Policy Set association, including Distribution Zone location of the Policy Enforcement Point (Virtual Edge Node)

3. Basic Networking Information

    Basic network identifiers like IP and MAC address, and current device status.

    Possible Device Statuses Include:

• Online - Device is connected and active, meaning we have observed attaches or traffic in the last 24 hours.
• Offline - Device is not connected, meaning we have not observed attach events or traffic in 24 hours.
• Suppressed - rapid attach/detach events (aka. flapping) will cause a device to be suppressed as to not overwhelm logging and alerting functions. 

Data Sources and Prioritization for IdentityGraph™

The main categories within IdentityGraph™  are the following:

 

Core Effective Attributes

 These are the primary, consolidated attributes that the IdentityGraph™ determines as most relevant for an asset.

Once the raw data is collated, the challenge becomes one of resolution and refinement. Given that different sources can offer varying (and sometimes conflicting) data about a single asset, IdentityGraph™ employs algorithms to categorize and rank this information based on its reliability and relevance. This ranking mechanism ensures that the most accurate data is given precedence, culminating in the formation of "Core Effective Attributes."

These attributes represent the essence of the device, giving a clear and immediate understanding of its nature and function.

• Examples: Hostname, Genre, Class, Vendor, Type, Model, Operating System, Risk Score, Label, Purdue Level.

 

Core Effective Attributes serve as the primary match criteria when creating Policy Groups, offering a consolidated, accurate identity for each device or endpoint. This does not mean, however, that you MUST match on Core Effective Attributes. As seen in the image above, administrators in Cloud Control Center have complete visibility into all attributes that have been gleaned for any given device.

Each attribute that Elisity has collected will be categorized, and shown on the asset details view for any device.

Trust Attributes

These attributes indicate the reliability and credibility of a device's identity based on its association with various platforms or systems. It provides a measure of how well-known and verifiable the device's identity is within the network and linked systems.

• Examples: Known in AD, Known in Claroty, Known in ServiceNow, Known in Tenable, Manually Verified, Unverified.

 

Elisity Native Attributes

Attributes in this category are derived directly from Elisity's native detection and identification mechanisms. They represent information that Elisity has been able to ascertain on its own, without relying on external platforms or manual input. Elisity Native attributes such as VLAN, Virtual Edge Node association, custom Device Labels, and more can be used as match criteria in Policy Group Definitions. 

 

Overview of Unique Elisity Natively Discovered Attributes and Their Use in Policy Group (PG) Definitions

Hostname

This attribute represents the discovered host name assigned to a device within a network, discovered via RDNS, DHCP, or other mechanisms.

Usage: Hostname can be matched using "contains" logic, which allows the creation of policies that apply to multiple devices with a common naming convention. For instance, devices with hostnames containing "NYC" can be grouped to apply specific security policies. Additionally, multiple values can be entered in the "contains" logic to match on a variety of hostnames.

 

Device Class

The Device Class attribute in Elisity is a closed list of predefined device types, determined through Elisity's native discovery and machine learning processes. This attribute is populated automatically by Elisity’s system and cannot be modified by third-party systems. The predefined list includes the following classes:

• Audio Video
• Building Management
• Collaboration
• Consumer Mobile
• Industrial Automation
• Medical Device
• Miscellaneous IoT
• Networking Equipment
• PC
• Physical Security System
• Printer
• Server Appliance and Storage
• WiFi AP and Controller
• Unclassified

Unclassified Devices

Devices that cannot be clearly categorized into one of the predefined classes are assigned the Unclassified device class. This ensures that every device has a classification, with Unclassified serving as a container for devices that require further investigation or categorization. 

The Device Class attribute can be used as a match criteria in Policy Group (PG) definitions. Administrators can define policies based on the device class, allowing for targeted policy enforcement on specific categories of devices. For example, a policy can be applied to all devices classified under Medical Device, or all devices listed as Unclassified for limited access or monitoring. 

 

Site Label

This attribute is derived from the Virtual Edge (VE) or Virtual Edge Node (VEN) and indicates the physical or logical site to which the device belongs.

Usage: Site Label can be used to create policies that apply to only devices from a specific site. This is useful for enforcing site-specific security measures and ensuring devices at different locations adhere to appropriate security standards.

 

Subnet

Represents the subnet in which the device resides. Elisity discovers this network-level information and allows usage subnet assignment in Policy Group match criteria.

Usage: Subnet can be used as match criteria to dynamically match assets in a specific network segment. This allows administrators to layer additional identity-based match criteria on top of subnet assignment, providing granular control over device access and communication within specific network segments while retaining identity-based controls. Example below shows matching Random MAC devices on a specified Guest subnet.

 

Trust Attributes

Indicates the level of trust assigned to a device based on external systems of record or manual verification.

Usage: Trust Attributes can be leveraged to apply differentiated policies based on the trustworthiness of devices. For example, devices with the trust attribute "Known in ServiceNow" can have more lenient access policies compared to "Unverified" devices. Trust attributes are typically leveraged alongside other identifying match criteria, enabling elevated security posture for a subset of devices.

 

Virtual Edge Node

Represents the node within the Virtual Edge infrastructure responsible for policy enforcement to which discovered devices are attached.

Usage: Policies can be defined to apply specifically to devices managed by particular Virtual Edge Nodes. This is beneficial for scenarios where different Virtual Edge Nodes manage devices with distinct security requirements.

 

VLAN

Virtual Local Area Network identifier for devices gleaned from enhanced endpoint discovery can be used as PG match criteria.

Usage: VLANs are commonly used to segment network traffic statically, using a firewall or some other mechanism to block VLAN to VLAN traffic.  Elisity enables administrators to use VLAN assignment in a dynamic fashion in Policy Groups, offering a flexible new approach. For example, if a device moves to a new network segment in a new VLAN and Policy Groups are leveraging VLAN info, the device will be assigned to a new PG dynamically based on the new VLAN assignment information with a new set of microsegmentation policies.  

 

Randomized MAC Address

Elisity Native discovery has the ability to identify devices that have randomized MAC addresses. Opening up an asset view shows an icon next to the MAC address that indicates this type of MAC address.

 

 

These attributes are also available in the device table view for quick sorting and filtering to quickly find assets with this designation.

 

Devices discovered with random MAC are typically personal devices such as tablets or phones with minimal identifying attributes, which are not found in any external system of record. These devices often have unique security and policy requirements, and must be isolated from vulnerable assets in the network. For this reason, Elisity gives administrators the ability to use "Random MAC" as Policy Group match Criteria. This attribute can be found in Elisity Native > Randomized MAC.

 

After creating the Policy Group, random MAC devices will automatically be assigned to the Policy Group you have created and will inherit the set of policies associated with this PG.

 

Other Elisity Native Attribute Examples: Genre, Class, Vendor, Discovered By, Last Seen, Last Update, Interface. Any of these attributes can be used in Policy Group match criteria.

 

Practical Applications

• Hostname Matching: By using the "contains" logic, you can create policies for devices with a common hostname pattern. For example, all devices with hostnames starting with "Sales-" can be grouped under a Sales policy group.
• Site-Specific Policies: Site Label allows for the creation of policies tailored to the security needs of different sites. For instance, stricter policies can be applied to devices at a data center compared to those at a branch office.
• Network Segmentation: Subnet and VLAN attributes provide a way to enforce network-based segmentation. Devices within a specific subnet or VLAN can be subject to customized access controls and monitoring.
• Trust-Based Policies: Trust Attributes enable the application of different policies based on the trust level of devices. This is crucial for managing access and protecting sensitive resources from potentially compromised devices.
• VE Node Management: Using Virtual Edge Node, policies can be enforced at specific nodes, allowing for localized security measures that cater to the unique requirements of each node's managed devices.

By leveraging these unique attributes, administrators can achieve fine-grained control over network segmentation and security, ensuring that policies are both flexible and comprehensive in addressing various organizational needs.

 

Manually Configured

These are attributes that have been manually set or adjusted by administrators or users. They represent a level of customization and might override or augment the data gathered through automated processes.

• Examples: Hostname, Genre, Class, Model, Operating System, Last Update, Label.

 

Additional Connector-Based Tiles

Alongside the core categories, any connector from which data has been derived will also manifest as its distinct subsection within the IdentityGraph™. These connector-specific subsections represent specialized sources of information and will display attributes specific to that connector. By examining these subsections, users can gain insights into the diverse data sources contributing to an asset's identity, ensuring a multi-faceted understanding of its profile. Each connector-based subsection serves as a testament to the integrative capabilities of the system, seamlessly pulling and centralizing data from a variety of platforms and systems.

Examples: Active Directory (AD), Claroty, ServiceNow, Tenable, Medigate, Palo Alto Networks IoT Security.

Once these attributes are defined, they can be seamlessly integrated into Policy Groups. By doing so, organizations can enforce network policies based on the refined data offered by IdentityGraph™, ensuring that policies are both precise and effective.

IdentityGraph data enriched by connectors are refreshed periodically however if the operator wishes to refresh the data immediately simply click the refresh button next to each connector tile. 

 

Ongoing Reconciliation and Updates

IdentityGraph™ serves as a continuous, dynamic identity engine. As assets evolve and network dynamics change, the service continually updates its data repository. This ensures that the identity information remains current, and any changes or anomalies are rapidly identified and reconciled. Whether it's a software update on a device, a change in its operational status, or a new device entering the network, IdentityGraph™ ensures that its data remains a reflection of the network's current state.

 

Using IdentityGraph™

Attributes learned from IdentityGraph™ are immediately usable in Policy Group definitions. To use any attribute, create a new Policy Group and scroll down to the attribute type. They will be categorized according to how they appear in IdentityGraph™. As you can see, you can select attributes from "Core Effective Attributes" or "Active Directory Attributes." Scrolling down will reveal any additional categories and their associated attributes.

 

Benefits of IdentityGraph™

Streamline Asset Management for Efficiency and Savings

Leverage the consolidated view of IdentityGraph™ to effortlessly overcome the hurdles posed by decentralized asset databases. By centralizing asset management, you're not only simplifying the process but also driving down operational costs. Dive into the structured methods of updating, categorizing, and managing with IdentityGraph™, ensuring that your network assets remain a strategic advantage rather than an operational challenge.

Fortify Your Security with Precise Asset Identification

A robust security posture begins with knowing exactly what's on your network. With the IdentityGraph™, you can elevate your security protocols through high-fidelity identification. The 'core effective attributes' feature works tirelessly behind the scenes, gathering and consolidating data from various layers. This results in a comprehensive, accurate representation of each asset. The outcome? A fortified security shield, ready to tackle sophisticated threats.

Ensure Accurate Policy Enforcement Across Your Network

The efficacy of your network policies hinges on the clarity of your asset identification. By utilizing these meticulous identification methods, you're creating an environment where policies are crafted with precision. More importantly, you can move forward with the confidence that these policies, once enacted, target the right assets, ensuring that your network's integrity remains not compromised.

 

View Connectors in Devices Page

Quickly view and filter which devices have enriched data in IdentityGraph on the devices page. Export filtered device pages by "Known In" Connector attributes that can be used to generate reports and improve device classification accuracy.

 

Sources and Fields for Core Effective Attributes

Core Effective Attributes use an order of precedence for each connector that is established by the customer in order to rank and aggregate the most accurate and relevant data about assets from all available sources. Core Effective Attributes include identity data about the device such as Type, Genre, OS, and much more, as well as risk data and authorization status. Here is an example of Core Effective Attributes within IdentityGraph:

 

Shared Services

In certain scenarios, customers may want to ignore Active Directory login events for a specific device. Generally, when a user logs in to a device, we will see this login event and associate a user identity to said device. This is often the desired behavior as this allows for identity-based policies for these assets based on user identities. For example, you may want to define network segmentation based on user groups. Radiologists and Pediatricians may work at the same hospital, but they don't need access to the same systems. 
Clicking "Shared Services" on any asset will disable user-based identity for the asset. Elisity will ignore AD User login events for the device, causing the asset to be classified purely based on device data in IdentityGraph. This is ideal for applications where user login is required to use a machine, but user identity is not relevant to the segmentation strategy.

To enabled "Shared Services, go to the device and click edit. Click the check box next to "Shared Service" and click save changes.

 

 

Risk Score Level

In the intricate ecosystem of network security and device management, it's imperative to differentiate and understand the varying risk levels associated with each device. To address this need, we introduce the Risk Score Level.

What is the Risk Score Level?

The Risk Score Level is a Core Effective Attribute designed to provide clarity regarding the security posture of a device, by classifying it into categories based on its perceived risk. This classification can be:

• High
• Medium
• Low
• Very Low

This score is dynamically sourced from integrations with external platforms such as Medigate and Claroty xDome. And what's remarkable is its adaptive nature: if, for instance, Medigate introduces a new classification like 'Extreme' in the future, our system will automatically recognize and integrate this without needing any manual updates.

 

Why is it Significant?

1. Manual Configuration & Bulk Actions: When adding or editing a device, the Risk Score Level is available as a Manual Configuration item, ensuring that you have full control and visibility. Additionally, when adding multiple devices, it can be included as a Bulk Add/Edit field in the CSV.

2. Device Overview Enhancement: For a comprehensive understanding, the Risk Score Level is a default column on the Device Overview page. This makes sorting and filtering devices based on risk scores straightforward.

3. Policy Evaluation & Creation: The Risk Score Level is essential when creating policies, especially when dealing with policy groups (PG). It's now an option under Core Effective Attributes when establishing a PG, ensuring your policy creations are as accurate as they are effective.

Risk Score

The Risk Score is a Core Effective Attribute designed to provide clarity regarding the security posture of a device  based on its perceived risk. Risk Score is an integer between 0 and 100 and can be leveraged as match criteria in Policy Group definition. 

Risk Score data is provided on a per device basis through integrations with solutions such as Claroty xDome, Medigate or Palo Alto Networks IoT Security. The following match logic is supported:

• Equals
• Not Equal
• Greater Than
• Greater Than or Equals
• Less Than
• Less Than or Equals