Taking a Closer Look at Elisity

This blog follows a previous blog about Elisity, which described its position in the Zero Trust / ZT / ZTNA market, doing ID/device type / context-based authentication and internal access controls.

One key differentiator for Elisity is Time To Value: no impact deployment, initial results within about two weeks.

This blog provides more details about Elisity, including screen captures that give you more of a feel for the product’s administrator-facing side.

I will start with the policy and enforcement side then briefly touch upon some other aspects of the product.

What Information Is Used by Elisity?

Elisity discovers information about devices attached to the (campus) network. Here is a partial list of information collected:

Device ID (MAC, IP, flow-based discovery data)
Device Tracking (MAC to IP mapping, switch port location, DHCP/ARP snooping by switch port, Cisco CDT)
Traffic flow data (device interface locations, source/destination IPs, source/destination ports for TCP/UDP)
Switch Configuration (checking switch configuration, pushing policy configuration to switch)
Context information gleaned from various third-party sources such as AD, CMDB, Claroty, Medigate, Tenable etc.

The operator can see essential information that Elisity has learned via the GUI:

(Diagram courtesy of Elisity, used with permission)

Building Your Policy

Policy creation starts with identifying the “business assets you want to protect” and then defining groups of users, devices, and custom-defined applications, and creating policy rules. Policy rules are similar to access list rules but leverage the asset attributes rather than IP addresses etc. In other words, they are identity and attribute-based. And they can be continually verified.

Here is an example of a policy controlling traffic from Admin users to printers in the group IT Printers.

(Diagram courtesy of Elisity, used with permission)

Policy groups can lump together users, device types, and custom-defined apps that need to be treated similarly – to reduce rule-building complexity and enhance readability. They are specified by match criteria. You can then use them in Boolean expressions, e.g., “User in AD group Physician” AND “Device model is Heart Monitor”.

For example, lumping together various types of medical imaging devices might be a good idea for “sanity retention”. Here is sample info about a group named “MED Imaging Devices,” tab “Match Criteria”.

Clicking on the Assets tab shows the devices in the group.

Clicking on the Attached Policies tab brings up all the associated security policies:

Individual policy rules can be examined in more detail:

(Diagram courtesy of Elisity, used with permission)

Note the hierarchy inherent in attributes: DEVICE versus USER, greater-than sign (“>”), and attribute. The attributes can be comma separated (for logical “OR”).

Here is Elisity’s example showing a sample policy used for credit card data:

(Diagram courtesy of Elisity, used with permission)

There are pre-built groups, including “Unclassified” (anything else) and “InternetPG” (external subnets, modifiable).

A security profile lists L3/L4 protocols allowed or denied in a policy.

Policy Visualization

Other key aspects of security are managing what you have put in place and keeping it all straight. To keep all this organized and readily accessible, Elisity provides a policy visualization view.

(Diagram courtesy of Elisity, used with permission)

There is a legend at the bottom of the figure (not shown).

My immediate reaction on seeing this matrix was, “seems similar to Cisco DNAC”. (Hey, repeated exposure means I have DNAC on the brain!) Well, the Matrix IS a natural (obvious?) and concise way to represent interactions between the pairs of items in a list of things.

A similar view lets you examine observed traffic flows:

(The legend and color-coding differ from the previous diagram.)

You can also list policies as shown below:

Integrations

So, I hope that gave you an idea of what the day-to-day use of Elisity might be like.

Equally important, behind the scenes, Elisity ties into a growing number of other Asset and ID tools via “Connectors”. Here’s the list as of the time of writing:

Built-in asset and ID engine
Active Directory
Azure AD is on the roadmap for later in the year
Claroty
Medigate
ServiceNow CMDB (as SSOT and for policy match criteria)
Okta
PingIdentity
Dragos
Tenable
SIEM: Splunk
Radius
Kerberos login

Other:

SSO tools: Azure SSO, Okta, Ping Identity

Visibility/Troubleshooting

Elisity provides a large number of web reports on devices, flows, blocked traffic, etc. Too much to summarize here, so I’ll provide a link: Visibility and Traffic Analytics.

Conclusions

Elisity is focused on Time To Value. Their sales process uses a quick onsite Proof of Concept. The claim is that Elisity can show value within a couple of weeks.

LATE BREAKING NOTE: Just in time for CiscoLive 2023, Elisity announced version 15.0 with major enhancements to their policy creation and management functionality. I hope to write about that and/or post links.

What Information Is Used by Elisity?

Building Your Policy

Policy Visualization

Integrations

Visibility/Troubleshooting

Conclusions

Links

Related Topics