The concept of segmentation has existed ever since we started connecting data centers to each other. In the early days, firewalls controlled what was able to get in from the outside. Perimeter firewalls are still a critical part of protecting the data center and that will never go away, despite the dissolving perimeter. As networks became more complex, we saw the concept of segmentation move inside with VLANs creating segments for the right size broadcast zones to ensure network performance. For more granular control, we’ve seen ACLs used to control what can communicate across networks. As application traffic and communication increases behind the perimeter, we’ve even seen the concept of the firewall move deeper into the data center to try to provide more granular control of East-West communications.

While each type of segmentation is valid, not every kind of segmentation is right for every use case. Another approach that has emerged to help to control the increase of East-West traffic is micro-segmentation. Micro-segmentation solutions can provide the right level of granular control to protect modern application environments, given the increase in connectivity as well as the diversity of platforms and infrastructure.

There are many architectural approaches to micro-segmentation, including doing it in the network, from the hypervisor and on the workload. In this post, we’ll review the different micro-segmentation approaches and cover the advantages and the challenges of each one.

Network-Centric Segmentation

With the network-centric approach, micro-segmentation policies are enforced by implementing access control in network devices such as switches or data center firewalls using IP-based ACLs (access control lists). The network devices in this case can be physical or virtual. Here are some considerations of this architectural approach:

Pros:

• – IT teams are most familiar with this architecture because they have likely been doing broad segmentation (e.g., for development, test, production, DMZ, internal network etc.) with this architecture for ages.
• – The policy is enforced outside the workload so if a workload is compromised, the attacker cannot turn off the enforcement.

Cons:

• – This works for private data centers but is much harder to deploy in public cloud environments. Many firewall vendors offer virtual versions but you’ll run into throughput limits and will have to consider architectural implications of traffic steering through choke points.
• – Getting to granular segmentation, even as you’re trying to segment at the application-level, can require an extremely large number of ACLs that may max out network devices, not to mention the burden of creating, testing and ongoing management of rules.
• – There is no visibility into the process on the workload that’s initiating or receiving connections.

Hypervisor-Centric Segmentation

Micro-segmentation enforcement with this architecture is done in the hypervisor. Since all VM traffic has to traverse the hypervisor anyway, the thought is that you’ll get visibility into traffic flows and can also enforce policies defined with tags or labels. Here are some considerations of this approach:

Pros:

• – Fewer architectural implications when compared to the network approach since VM traffic will need to pass through the hypervisor anyway.
• – Policy is enforced outside the workload so, as with the network approach, if a workload is compromised, enforcement can’t be turned off.

Cons:

• – No support for bare-metal (e.g., non-virtualized) workloads.
• – Support is usually limited to a specific hypervisor, so if you have more than one solution (e.g., ESXi and Hyper-V), you’ll need to create and manage policy separately.
• – Limited or no support for workloads in public cloud where you don’t have control over the hypervisor.
• – Limited support for containerized workloads; they’ll need to be running on top of a hypervisor, which might not make sense.
• – No visibility into the process on the workload that’s initiating or receiving connections.

Workload-Centric Segmentation

Micro-segmentation enforcement with this architecture is done from the workload itself, leveraging the firewall inside the OS or inside the container running on that OS. Here are some considerations of this approach:

Pros:

• – Works for workloads running on anything and anywhere including bare-metal (non-virtualized), VMs on any hypervisors, containers, in private data centers, private clouds or across public and hybrid clouds.
• – Can pull context from each workload to provide the most granular form of visibility, using application dependency mapping to see what’s communicating with what.
• – Being on the workload, you gain insights into the processes that are running to enable granular segmentation, as well as to ensure the best enforcement for applications that might use a dynamic port range (e.g., Active Directory).

Cons:

• – Policy is enforced inside the workload, so if a workload is compromised, an attacker can potentially turn off enforcement. Without the right solution providing checks and balances, this can be a risk.
• – Orchestrating policy across every workload and keeping it up to date can be a challenge without a purpose-built solution to centrally manage everything.

So, which micro-segmentation architecture is right for you and your applications? It really depends on your environment today and where you think it will be in the future.

• – If your team is comfortable with network-based controls and doesn’t have plans to move to cloud, then the network approach may work for you.
• – If you have a single hypervisor vendor and aren’t looking to move to cloud or containers anytime soon, then looking at hypervisor solutions might be the way to go.
• – If you have diversity in your environment, which might include some bare-metal, two or more hypervisors, containers or some workloads in public cloud, the workload-centric approach would probably be best.

ONUG SDSS (Software-Defined Security Services) working group has brought together IT executives across some of the largest organizations on the planet, including Bank of America, Barclays, Cigna, Gap Inc, Principal Financial Group, Salesforce, Tesla, Visa, Wells Fargo, etc. to discuss requirements and best practices for securing applications in modern, diverse, and sometimes very complex environments. We’ll be discussing these topics and several solution vendors will be showing proof of concept demos at the upcoming ONUG Fall Conference in NYC. If you’re in town, stop by to see what we have to offer and join the conversation. We hope to see you there.