Elisity Zero Trust (ZTNA) is HOT!

Security is arguably the hottest topic in networking these days, especially for the industry verticals of hospital / medical and manufacturing. One major driver for this is IOT/OT: medical or other devices are rapidly being moved onto the production network rather than remaining standalone or on a separate dedicated (and usually very legacy) network.

The security concern is that the plethora of medical, OT, or IOT devices may not be well-hardened. After all, vendors must get the product working, pass any approvals and testing, and start building a customer base while adding features, etc. Secure app design and networking may also not be in their technical wheelhouse since prior products may have been standalone or on isolated or dedicated networks.

Zero Trust is, of course, a Big Deal, for good reasons. So every security vendor wants to have a play in the Zero Trust space. Deployment complexity, costs, and other aspects sometimes are not talked about for good reasons.

Elisity has a product that has a great story concerning ease of deployment, especially at scale.

This blog is about the market niche Elisity occupies and what makes them hot. The focus is on market positioning and the broad ZT(NA) space to some extent, with a follow-on blog providing a deeper look at Elisity’s product.

Traditional Approaches

As I see the market landscape, we’ve had two basic approaches to Zero Trust.

The first and more legacy approach leverages traditional firewalls for “moat” and maybe makes them “smarter” (ID aware, etc.). That is usually done by tying them back to centralized software to provide simpler policy deployment and possibly some AIOps, behavioral analysis, etc.

There should probably also be centralized reporting and perhaps behavioral monitoring, which might be tied to other systems (e.g. Cisco ISE, SIEM systems, etc.). Routers / SD-WAN and access lists might also play a role in this. If nothing else, a ZTNA product should be able to tell you who’s accessing what and when.

A mildly different recent variant of this uses dedicated hardware that you insert into your network path(s) to contain policy and do enforcement. One I read up on recently apparently assumes sites consist of Layer 2 only VLANs. Enabling enforcement means inserting their box(es) in the path to the default gateway, plus shifting VLANs to private VLANs with the default gateway on the security device. That apparently excludes sites with a modern L3-to-the-edge design, or probably VXLAN.

To sum up, approach #1 involves hardware in the data path to do enforcement.

The second approach is illustrated by Illumio, which I’ve blogged about in the past. Let’s call that the agent-based approach, where agents on endpoints provide contextual information, monitoring and enforcement.

Concerning the first approach, the moat approach, buying and maintaining firewalls or stacks of high-throughput with enforcement capability has gotten expensive. Throughput/capacity is a major cost driver there. Supporting firewalls is also a potential problem, as cloud firewalling likely requires a virtual version of the main firewall vendor’s firewall, or the cloud vendor’s alternative approach.

Note that, in general, multi-vendor/multi-cloud network designs means more skills for staff to acquire, and more effort to manage. For cloud, I also have the concern that there is no cabling to enforce traffic traversal of the virtual firewall. Staff could conceivably easily create a virtual link and routing bypassing the virtual firewall without anyone noticing. But that topic belongs in a separate blog.

Concerning the agent-based approach, the challenges are (1) getting the agents installed everywhere and (2) what do you do about IOT devices or servers where the app vendor prohibits you from adding drivers or agents. Is that paranoia or just rigorous security thinking? Obviously, I opt for the latter!

If you think about it, one of the strengths of the agent-based approach is that it distributes the enforcement workload, avoiding the problem that firewall code and chipsets tend to be limited in throughput due to rule processing CPU impact. The drawback is more deploying the agent and situations where the agent cannot be deployed. E.g., apps/servers built by a vendor or consulting team where any changes void support/warranty/contract. Do note that agent deployment is a one-time event and might be done with desktop etc., upgrade automation tools. Ditto agent upgrades.

Recent Innovation

Cisco’s DNAC / SD-Access leverages an intent-based design approach and deployment automation to provide a means to macro- and micro-segment a network, with tie-ins to Nexus/ACI EPG enforcement. It has great capabilities. It ties directly to Cisco ISE. It uses VRFs for macro-segmentation and SGACLs for micro-segmentation between user/device groups within a VRF. It does require advanced skillsets (SDA + DNAC GUI + ISE).

All that is wonderful, but it does require LISP-based tunneling, VXLAN, appropriate (new!) Catalyst switches, and a network re-design and/or migration. Also, Cisco products support large customers with complex needs, meaning their solutions generally have a degree of built-in complexity and capability. Some shops may not want or need that, or may not be able to afford it (cost, staff time, learning curve, risk concerns, etc.).

NetCraftsmen is assisting some migrations to SD-Access, but it is clearly at best a future activity for many sites that are still doing basic ISE (etc.) deployment and working their way towards more sophisticated user access validation.

Control Points versus Policy Enforcement Points

A mild digression: I find it useful to think about where and how the enforcement gets done, where the Policy Enforcement Points (PEPs) are. You can likely see that lurking above, and it will come up again. It comes down to the fact that there needs to be something somewhere in the path of traffic flows that can block traffic. The choice comes down to: on the edge network devices, in the middle of traffic flows, or on the endpoints.

The enforcement points need to function bidirectionally.

Ideally, the control software deploys policy to the PEPs, and provides a central control system with ID + flow analytics , i.e. who’s doing what.

For traditional moat security, the hardware (firewall etc.) is the PEP. You just have to make sure it is in the path of the flows you want to control.

For agent-based, the agent is the PEP. You just have to make sure the agent is deployed everywhere, with exceptions secured in some other way.

In general, one purchasing criterion to consider is what gaps or exceptions does a given product have (if any), what’s the work-around, and how does that fit your needs. Yeah, fancy words for pros and cons of the product…

What’s Different about Elisity

Elisity uses the term “moat” for a traditional legacy firewall strategy, of putting a firewall anywhere you need to control access, namely between the outside world and the inside network, or between internal segments, etc. Elisity is NOT a moat approach!

They call their overall capability “Identity Based Micro Segmentation”.

Elisity has a different approach, what I’d perhaps call an intermediate approach. Elisity operates with centralized cloud policy control as a service, the Cloud Control Center. It gathers user and context data, allows you to define groups and policy, and deploys policy. It can also be deployed on-premises for air gapped networks or for organizations that dislike cloud management tools or cloud dependency.

The central control point receives info from and passes security policy to and from local control points, Virtual Edges (VEs). The Virtual Edge code runs as a common lightweight Docker-container, either per-switch on recent Catalyst switches or on servers/VM hosts controlling nearby older Catalyst switches. It can also be run on an aggregation switch controlling policy in multiple downstream access switches. The server/VM approach can also be used to onboard newer switches, e.g., Cat9K. Doing so would also support managing independent control apps on fewer switches.

The VEs pass identity and context information upstream to the cloud control, and under central control, provision policy into the switches, which are the PEPs. Elisity calls them Virtual Edge Nodes (“VENs”).

Elisity describes this approach as the product “not being in the data plane”. They don’t process and intercept packet, the switch does.

The following is Elisity’s graphic showing how this works.

(Diagram courtesy of Elisity, used with permission)

To summarize: centralized Elisity handles policy formation and deployment, also reporting, but leverages the hardware (TCAM and ASICs) in the switches for actual enforcement with high performance.

My impression is that this is arguably closest to DNA Center in terms of how it works, compared to other products. But with an ID / device ID / context focus rather than a more networking-centric focus.

Why Is Elisity’s Approach a Win?

The good thing about Elisity’s product is that may well map better or more directly to an organization’s needs. And make addressing those needs simpler.

This approach uses your existing campus hardware. Currently, the VE containers can be deployed to Catalyst 9K switches. Or they can be run on a host/VM to control the older Catalyst 3650/3860 switches. (See Elisity’s supported hardware / compatibility page.)

Why is that a win?

From the PEP perspective, it is a distributed enforcement, for the throughput win!
It leverages what you probably have in place in your campus network or modest data centers. No new “pile o’ hardware”. No re-architecting of the network to get full functionality (aka “migration to SD-Access”).
It does not require LISP, VXLAN, etc. (i.e., operates with lower networking tech complexity). Nor VRFs.
It “sees” any device whose traffic passes through those campus switches and can provision policy to control such traffic.
The policy is identity-based, not IP/MAC address based. And can leverage additional attributes and trust logic.
It can be deployed quickly, and a low-risk Proof of Value can quickly be done onsite.
It discovers and provides visibility into devices on the network (IT, IoT, IOmT, OT) and allows rapid configuration and deployment of policy. (IOmT = Internet of Medical Things)
Enriched data is available via integrations, e.g. with Active Directory, ServiceNow, Claroty, Mediagate, Tenable and others.

Yes, there are container or other agents to deploy, but the number of switches is far fewer than the number of endpoint devices. Aggregation via VM agents can further reduce the agent deployment points.

Furthermore, Cisco has provided automation of container deployment for the newer switches, and the VM/container approach (or agg switch container) can manage policy deployment etc. for the 3850/3650s still in place. Also note you can do the 1 to many approach with VMs. (Although I’m told this is rare for large enterprises, who usually do the VM or aggregation hosting model.)

Cloud-based central control is something I view as mixed. It’s less hassle and the customer is less likely to break it. (As reference, I’ve heard some horror stories about upgrading DNAC, ‘cuz when a cluster breaks it is a real “cluster-f” event.)

If you have cloud concerns, Elisity offers a simple on-premises deployment of the Cloud Control Center as an option. It is template based and reportedly takes 30 minutes to deploy from a VMware template.

I suspect Elisity’s approach also lends itself to porting to other Places in The Network. The requirement appears to be that the other hardware support something like Cisco SGACLs. At present the product focus is on controlling user and device access to each other and to apps, but not necessarily external access.

I’m told Elisity will support Arista and Juniper switches soon, for some value of “soon”.

Conclusions

Elisity is focused on Time To Value, and claims results beginning within a couple of weeks.

Elisity appears fairly simple and fast to deploy, and focuses on user / device identity and attributes.

The approach Elisity is taking looks like they have found a cost-effective sweet spot, in between firewalls/moats, and agent-based approaches.