Black Hat 2024 – Las Vegas
In infrastructure design there used to be a philosophy of putting components in silos (segmenting them). This was not really done for security, but more to limit impacts across an organization or environment. The use of different subnets, ACLs, routers, and firewalls was just part of how you built things. This philosophy seems to have died out as environments became more physically disbursed and technologically complex. With the advent of OT and IoT devices being able to access everything without the need to physically visit a site or needing to connect to a different system which then connected to another control plane was just not something that modern businesses would tolerate. Networks got flatter and, sadly, in some cases restrictions and controls for accessing sensitive devices disappeared. Now far too many organizations (especially Hospitals and Infrastructure) need that segmentation but cannot afford the time needed to rebuild their entire networks with this in mind.
This challenge created the conditions for a new market to emerge; Software-Defined segmentation. This market has a submarket which includes firewall devices and firewall like appliances for inline access and controls. During Black Hat 2024 I spoke with James Winebrenner, CEO at Elisity about this challenge. Elisity focuses on microsegmentation based on identity to identify, classify, and monitor access in an environment, with a particular focus on Healthcare and OT heavy environments.
While there are other players in the market, one of the things which seems to differentiate Elisity is the lack of an agent to do what they do. Anyone in IT Ops knows that things are getting rather crazy with multiple agents for multiple services and at times all trying to do similar things on the endpoint. Not having another agent taking up the finite resources on a device is a good thing. It also means that you are not necessarily relying on access to the firewall on a device to control access to it. Instead Elisity moves off the endpoint and into the network itself. Using software either hosted in a Hypervisor, or on switch hardware (called a Virtual Edge Node or VEN), assets, access, and identity usage is collected, and policy information is enforced at the switch level (with supported switches). I am getting ahead of myself here though, so let’s take a step back and work on understanding how Elisity goes from deployment to enforcement.
Ok so, first things first. Elisity will spin up your Cloud Control Center. The Cloud Control Center is the control plane for your environment (I know pretty obvious right?). Here you will find all your analytics, policies, etc. It is intended to provide you a view into asset and access data. Now this is probably going to be empty until you connect your tenant into other services and/or deploy your VENs into your environment. Connection into other services like EntraID (or active directory), CrowdStrike, Claroty, Tenable, Splunk, Cisco, Palo Alto, etc. will give you additional context and visibility into what is going on in your network and can also act as a logic check for identifying devices which might not have proper coverage or be part of shadow IT. The VENs are the additional “ears” in the environment to establish assets, their identities and who/what are accessing them. All this data funnels up into the Cloud Control Center to build an Identity Graph. The data in the identity graph is leveraged to build out access policies to control who/what can access the resources in your environment.
Now once the identity graph is ready and you want to build policies, Elisity has a LLM augmented policy engine which allows you to use plain English to build out the policy you want. As you start typing out what you are looking for the LLM (GenAI) starts suggesting the options you have available which allow you to accomplish your intended goal. It can also suggest the best policy based on identified behavior via machine learning (another name for AI). These two components help in building fast context around identified behavior or known threat activity patterns to help inform your team on the best path forward.
Once policies are built you can also test them to mitigate the chance of a policy which has unintended consequences. From there you can implement the policy let it alert for you, and finally put it in enforcement mode to start preventing unauthorized access to resources in your organization. You can also build polices which address new or unknown devices which are identified in your environment, these policies can include quarantining the device which prevents communication to other assets or the outside world.
The idea is to build a system which allows for fast, effective deployment and integration while also providing a team with actionable data and response quickly. From what I can see Elisity met this goal and their positioning the product where they have lets them build access zones in a more effective way. As I mentioned before there are other players in the market here, but most of them use an agent to connect into the endpoint firewall to allow or block access there leaving the attacker in knife-fighting range still. Keeping the bad guys out of the room in the first place provides a “greater than arm’s length” method of protection giving more time to respond to improper behavior while also lighting the agent load on the end point and addressing devices that might not be able to support an agent.
All of this can be accomplished even the flattest of flat networks and in near real-time with new policy updates hitting the VENs rapidly once they are applied to the environment. There is no need to replace existing equipment or to make changes to your existing network layout (although, if it is a single VLAN flat network, I would personally recommend making the changes anyway).
While there are the usual benefits to having this type of control in place like easier compliance tracking, greater visibility when threat hunting, fast Incident Response, etc. The largest one by far is in limiting lateral movement and/or potentially limiting the spread of destructive malware (think Ransomware) in an environment during an attack.
Overall Elisity is an interesting extension of “Zero or Least” Trust networking. On paper it seems to avoid many of the existing pitfalls of other player in the market (end point agents, long deployment and learning times) and should be able to show value in a relatively short period of time. There is current no option for a network that has no internet connection like a High-Side environment or isolated development environment, but (and this might be wishful thinking), I would hope that an organization sophisticated enough to have a true High-Side environment would already have proper segmentation and least access controls.
I can see where Elisity would fit in very well in many Healthcare, Hospitality, and Industrial organizations. All these verticals have had challenges with ensuring proper network segmentation and access controls. Healthcare and Hospitality often also have the added fun of contracting regulatory needs which can be expensive to meet as new access control requirements pop-up at bad budgeting times. Elisity could be a good answer to these challenges and allow teams, who are usually overworked, to start doing the job of ensuring proper security and not hammering away on a seemingly endless list of projects which are intended to do the same thing but are likely to fall short of the mark in the end.
