I began my exploration of the microsegmentation space by semantically deconstructing the title. The result? Microsegmentation solutions help define network segments as small as a single entity. While I believe this is a useful approach to intuitively understand the technology, my couple hundred hours of research revealed that the scope for microsegmentation is enormous. It is so large that I have to invalidate the initial “single-entity network segment” definition to capture the technology as exhaustively as possible. This means that microsegmentation is not a single-entity exercise, and it’s not defined only using network constructs.
Microsegmentation is a Multiple-Entity Construct
In absolute terms, when you define a microsegment, you dictate the policies applied to a single entity, such that it allows some traffic or requests while blocking others. However, traffic always flows between two entities, so both endpoints must be considered.
On one end, you have the entity you want to isolate—let’s say a container. On the other, you have all the other entities that will communicate with the container you want to isolate. It’s worth noting that these requests are likely bidirectional, but for the sake of simplicity, we will assume ingress traffic only.
When looking to isolate a container, sophisticated policies (other than allow/block) need to consider requests from a wide range of entities, which include other containers, virtual machines, developers and administrators, function as a service (FaaS)-based microservices, external APIs, monolithic applications, IoT devices, and OT devices.
The underlying technologies that can define policies between containers and all these other types of entities include container networking interfaces for container-to-container communication, service meshes for service-to-container communication, ingress controllers for cloud or data center workload-to-container communication, secure shell for administrator-to-container communication, and so on.
It quickly becomes obvious that defining these policies involves a lot of components that span across disciplines. Some solutions choose to deploy agents as a single point for managing policies, but organizations increasingly favor agentless solutions.
When working with a microsegmentation solution, the day-to-day activities of defining and managing these policies will not involve directly working with all these technologies because they abstract all these aspects and provide an intuitive GUI.
The reason I am highlighting this is to evaluate a solution. Depending on the types of assets you need protected, the supported entities are by far the most important evaluation aspect. If you want to protect IoT devices, but a solution does not support that, it should be immediately excluded.
Microsegmentation is Not Just Network-Based
Those with a networking background, myself included, borrow the segmentation concept from firewall-defined network segments. It’s both useful and relevant, and you can see this concept being carried over in distributed firewall solutions provided by the likes of Aviatrix, VMware, and Nutanix.
But there are two more ways of isolating entities besides using network constructs:
- Using identity-based policy enforcement. This offers controls that are independent of network constructs such as IPs. Access can be governed using attributes such as operating system type, patch status, VM name, Active Directory groups, and cloud-native identities like labels, tags, and namespaces. Solutions can also assign labels or categorize entities natively to remove dependencies on third-party labeling systems.
- Using process-based policy enforcement. For example, the microsegmentation solutions can monitor the running processes on every entity, capturing detailed context for each process and its associated libraries. Process and library hashes can be assessed against a threat data feed to identify malicious code execution and detect variation from known good processes. Processes can include applications, services, daemons, or scripts, and details such as process name, path, arguments, user context, and parent processes. If a malicious process is detected, the entity is then isolated from communicating with the rest of the network.
At the end of the day, you can’t cut off communications without involving the network, but the microsegmentation policy itself does not have to be dependent on networking constructs, such as 5-tuples.
Next Steps
When evaluating microsegmentation solutions, I recommend you approach them as highly sophisticated designers of security policies. Most often, an entity can be isolated just by blocking ports. So, the effectiveness of the solution will depend on whether it can support all the entities you need to protect and how easy it is to manage all the policy permutations.
To learn more, take a look at GigaOm’s microsegmentation Key Criteria and Radar reports. These reports provide a comprehensive overview of the market, outline the criteria you’ll want to consider in a purchase decision, and evaluate how a number of vendors perform against those decision criteria.
- GigaOm Key Criteria for Evaluating Microsegmentation Solutions
- GigaOm Radar for Microsegmentation
If you’re not yet a GigaOm subscriber, you can access the research using a free trial.
The post There’s Nothing Micro About Microsegmentation appeared first on Gigaom.
