Application Segmentation Solutions: Top 10 Features
In This Article
With the reality of today's threats and the inevitability of breaches, it is almost without exception that restriction of lateral movement within a technology infrastructure is an objective for many organizations. The method of establishing these restrictions is called segmentation. While each vertical has its own priority, the most common starting points for this strategy are critical application environments.
So if you're evaluating application segmentation solutions (sometimes referred to as east-west segmentation or microsegmentation), this article is for you. This is the type of evaluation we've been doing here at WWT for years, and we apply a systematic approach that is highly effective. It allows us to weight (and/or prioritize) each individual customer requirement, thus personalizing the evaluation. This is followed by numerically scoring the effectiveness of solutions based on the weighting and captured in a scoring matrix consisting of hundreds of lines. Below is a sample from this matrix.
As the culmination of that work, below is what we believe to be the top ten most important capabilities in the space of east-west segmentation (starting with the most critical). They won't be the top 10 for every single organization, but by and large these attributes are what we've observed to clearly affect most customer decisions in this process.
We'd be remiss if we didn't start with reliability. Perhaps this goes without saying, but these solutions function in critical application areas where "it's gotta work." You can't be burdened by inaccurate visibility or agents failing randomly. This is very difficult to measure without proof of concepts (POCs), pilots or someone with enough hands-on experience to validate reliability for you.
Notice the word "and" is emphasized here. Having both of these features working together is the secret sauce of segmentation. You can't segment what you can't see. Within this context discovery is the act of collecting flow data and applying business context dynamically to the results, so you actually know which workloads (servers) comprise your application.
Enforcement is the actual act of segmenting traffic (controlling traffic) between them. This is critical in not only the initial implementation but ongoing operations of your segmented environment.
Segmentation is complicated. You are now maintaining hundreds or thousands more lateral movement obstacles than you have in the past. Each barrier has very specific communication holes punched through it.
If you understand this increase in the number of variables, you will then more clearly see why a complicated solution will be extremely difficult to maintain. Look for solid visualizations and, most importantly, straightforward logical workflows. A complicated solution layered on top of an already complicated effort will not make this any easier.
This is a complicated topic, so there is a bit more data here around scalability. There are a few different ways to look at scale in app segmentation. The first is in terms of the sheer number of workloads (essentially servers with IP addresses) upon which segmentation filtering is enforced. How "micro" are you going to be able to go? Or will your policy be satisfied with broader ring-fencing of environments, which isn't easy but requires less scale?
One of the most fundamental questions you can ask your OEMs is, "what are the highest number of workloads in enforcement you have in production at your customers?" Specifically, we are not referring to those workloads obscured as part of a broader segment. We are referring to those under full active microsegmentation enforcement at scale.
Another way to define scale is in terms of geographic diversity. If you will be managing policy for international sites, does the solution have an adequate clustering technology to support such an architecture? Is that solution capable of synchronizing policy that is centrally managed? How does latency affect this? The alternative is to manage segmentation policy at each major site independently, which can be an operational burden. Throw in policy in public cloud environments and it further complicates the issues.
Finally, are the role based access controls (RBAC) capabilities of the solution sufficiently sophisticated to allow delegation of filtering configuration to application or business owners? A common strategy for keeping up with the increased operational responsibilities in segmentation is to distribute the operational burden. In these instances, you become the central authority for overall policy and the delegates are responsible for implementing it.
Can the solution see network traffic and segmentation policy from the perspective of the workloads themselves? This tends to simplify operations. While host-based or agent-based segmentation solutions have a clear advantage here, there are hybrid solutions that have clear visibility of both the workload and the network over which they communicate. This concept is encouraged by Zero-Trust, which has always included themes of de-perimeterization and pushing security closer to the endpoints themselves.
You will need to automate segmentation. The mindset should be "automate more to operate less." The question then becomes how much API development you will need to perform on your own. The more built-in integrations your solution has, and the more solutions it teams with natively, the better.
Load balancers, firewalls, orchestrators, CMDBs, flow collectors and log analysis systems are examples of solutions that will likely need to "partner" with your primary segmentation solution. The less you have to develop from scratch, the faster you will be able to move.
But still, be prepared for some API development. It is practically a given.
Modern solutions need to not only support the diversity of mainstream workload operating systems (windows families, linux distributions, etc.) but also physical, virtual, containers, public cloud and mainframe to name a few (in the spirit of policy consolidation).
Fundamentally, what you do in segmentation is create rules between workloads or groups of workloads. One of the things we like to see is the flexibility to switch between a blacklist and a whitelist mode.
It's also advantageous to be able to manipulate a permit-any or deny-all at the end of a ruleset when necessary. An invaluable option is "monitor mode" so you can evaluate rules safely without actually enforcing them. Rules based on attributes of the workloads, tags, labels and varied protocols are also things to look for in this feature category.
Reinforcing the automation reference in #6 above, it will be essential to have a solution with a solid, well documented API, most commonly a REST API. At some point you will have to use it.
In our opinion, you should test-drive the API and its documentation with Python or a simple script language of your preference. Minimal functions to test right up front include API authentication to the system, GET data from it and POST data to it. Then attempt to replicate common functions such as policy creation or reporting. Ideally, POC the API integrations as part of your anticipated workflows.
This is one of the commonly defined attributes of Zero Trust. If your long-term goal is to achieve a level of Zero Trust, look for a solution that includes this unique feature or, at a minimum, has a clear strategy to include it.
A solution with encryption is an advantage. You might not use it initially because segmentation is complicated enough as-is, but we are confident you will need it later.
So there you have it: ten of the most important capabilities to look for in modern application segmentation solutions. Remember that each business is somewhat unique, so these might not be the exact top considerations for you. It is, however, a certainty that most will be important as you continue in your segmentation efforts.
A great way to explore these capabilities and how they fit into an overall segmentation strategy is to request an Enterprise Segmentation Workshop.
Contact us directly if you want to start a little simpler, perhaps with a 1-hour briefing. For any other information or hands-on lab options, make sure to follow our Enterprise Segmentation topic for the latest content.