Micro-seg-men-ta-tion

I remember back in 2016 when I started on my AWS journey. There was something about how security groups and network access control lists intrigued me. At first, I was somewhat perplexed. As I began to do more in AWS, I was able to wrap my head around the process of securing virtual machines, as well as applications. It started to make sense, conceptually. It only took a glance at “Authorizing inbound traffic for your Windows instances” for me to figure out the basics. I then had Linux instances to figure out. That also was straight forward.

I had not considered at the time how AWS was using these features to control east-west traffic; however, as I look at the data centers today, I have made the connection. So, I decided to dive into my experiences with microsegmentation. More important, why microsegmentation?

What is microsegmentation? 

Microsegmentation is a method of creating secure zones in data centers and cloud deployments that allows companies to isolate workloads from one another and secure them individually. It’s aimed at making network security more granular.

https://www.networkworld.com/article/3247672/what-is-microsegmentation-how-getting-granular-improves-network-security.html

When I examine the reasons to consider microsegmentation, I refer back to why AWS decided it was so important. The answer, security. You see, when I ran my own data center, I relied on VLANs, routing, and firewalls to handle separation between VMs. Notice how I did not refer to applications in my last statement; instead, my focus was on VMs. It is because application separation was not even on the spectrum of my thinking back then. My typical build-out was a single VLAN for each customer. It was all that was required to separate one customer’s environment from another. If you think about it, this solved all of my multi-tenancy problems! Create VLANs on different subnets, setup some routing, and configure the firewall. I am all set. Now, let’s scale!

So here we go—time to scale. “Customer A” and “Customer B” have some crazy requirement that overlaps. Now what? “Customer C” and “Customer D” now need to share a specific application server. Next, my customers require shared file services. “Customer E” separates its business and requests only partial isolation between the two entities. Now, “Customer A” and “Customer E,” for some reason, need to have integration between each other’s applications. Ahhhhh!

My point here is that at scale, my solution does not hold up. It creates a whirlwind of problems. You see, the business is multiplying. Several new applications need to go online. We need to add additional networking to accommodate growth. Another rack is required to scale the business. Oh, did I mention that the urgency on this is yesterday? But wait, there is more. There are compliance issues and routine auditing. There are PCI workloads, and HIPPA is in play. VLANs work, but not without risk, and not without added complexity. And let’s not forget the time it takes to design and continuously audit VLAN configuration. This time takes away from other initiatives and ultimately drives additional cost. Oh, but it gets better. We hire someone new to help build out and manage infrastructure. How’s that going to work out for me?

Let’s take a closer look at VLANs

A VLAN is a group of devices on multiple LAN sections that behave as if they are on a single LAN. Computers in the VLAN are separated by bridges, routers, or switches and sometimes housed in different locations. Compared to LANs, VLANs have the advantage of reducing network traffic and collisions, as well as being more cost-effective. 

A VLAN can also bring added security. When devices are separated into multiple VLANs—often by department—it’s easier to prevent a compromised computer from infecting the entire network. Nevertheless, VLANs do come with some unique security risks that MSPs must keep in mind. The most critical threat to consider is VLAN hopping. A hacker connected to one VLAN gains access to other VLANs that they do not have permission to enter. In a secure VLAN, each computer connects to one switch access port. Each machine can only send traffic to its specific connected port by accessing a single VLAN. However, with VLAN hopping, an attacker can send packets to ports that are generally not accessible, penetrating other VLANs.

https://www.solarwindsmsp.com/blog/vlan-hopping-security

As we are on the topic of security, I feel it is essential to bring into this article something personal. At one point in my career, I managed several customers. To be more detailed, I was the person responsible for securing “Customer A” from “Customer B.” The workloads were similar for each customer: a clustered database back-end, application front-end, load balancers, ADC’s, and file services. Well, there was the idea that to reduce infrastructure costs, we could share infrastructure across customers—for example, file services. At the time, it seemed to be a good idea. We would have the proper security in place using VLANs, ACLs, IDP, etc. The solution all worked out well until it didn’t. Fast forward, ransomware. Not only was “Customer A” impacted, but “Customer B” was also compromised, and this resulted in downtime—a lengthy discovery and restoration of data, and as a result, lost productivity and revenue. Everything needed to stop to figure out what was happening and how to prevent it from repeating—a disaster.

We had to monitor our end-user computing environment. Was something malicious occurring? Did something spread from “Desktop A” to “Desktop B”? Was this vindictive? Was it an accident? How are we going to prevent this from spreading from one server to another, or between customers? At the time, ransomware was new. It wasn’t until you saw your desktop wallpaper demand money to unencrypt your files that you knew something terrible happened. From that moment on, panic set in, you stopped all services, and you went into reaction mode, just trying to contain the fire until you can put it out. Oh, but wait. If you never fully put it out, maybe by restoring the infected files, you risked re-infecting your entire environment. 

Does any of this resonate with you? If so, leave a comment. Let me know I am connecting with real issues. 

So how do we move past this? How do we learn from this?

Earlier, I reviewed the definition of microsegmentation. You see, AWS got it right. They did not rely on simple VLAN separation to protect their customers. It would be impossible. They had to come up with a better way: a way that the customer could understand, navigate, manage, and scale. A simple description would be that AWS created firewall rules in front of each VM, protecting one VM from another. Smart, right? That means that “VM A” could not talk to “VM B” unless you defined how it could communicate with “VM A.” Brilliant—and well delivered from a management perspective. This concept did not carry over immediately to the customer-managed data center. It was designed by and for the public cloud, and in this example, AWS.

When we look at what options we have inside the data center, there is a considerable gap between what AWS can provide as far as security in the public cloud versus what other solutions in the private data center can provide. Have you ever looked at VMware NSX or Cisco ACI? Both are outstanding options. But, have you really looked at VMware NSX or Cisco ACI? They are really complicated and most likely do much more than what you are looking to accomplish. I will not go into detail of what these products are capable of, but they are genuinely advanced products that handle a multitude of networking capabilities. They are true software-defined-networking (SDN) solutions. Keeping this in mind, what is the learning curve in using these products? What size data center are they best suited? What is the cost involved to purchase, deploy, and maintain? Most importantly, are you considering these products for application security or complete software-defined-networking? 

Let’s answer some questions.

• Are you worried about a data breach?
• Is there tension between virtualization, networking, and security teams?
• Is security or compliance slowing down IT operations or impacting agility?
• Would you like an increase in application security in the data center?
• Do you have concerns around VDI and the isolation of those users in the data center?

If your worries are mostly around answering the questions above, most likely, you require a product that provides application security for east-west traffic or microsegmentation. A full software-defined-networking solution is most likely unnecessary.

Is there a better way?

Right now, are you asking yourself, “What does that even mean? Is there a better way? Is there a product that is native to a platform and built around simplicity that is also application-centric when it comes to security?“ Well, why would I be writing this otherwise? Yes, there is! 

What you are looking for is Nutanix Flow. Now, in full transparency, Flow is not a solve-all solution. It just isn’t. It is a solve-80% solution. Nutanix has looked at the data points, and most customers are only looking to solve the 80% that Flow addresses. Flow targets the majority use cases of application security via microsegmentation and expansion to additional 3rd party network services through service chain insertion. It is not that we believe the other 20% is non-essential or unnecessary. Nutanix has a focus on application security and leveraging a multi-vendor ecosystem of Network Fabric vendors and open APIs to achieve the network automation that SDN broadly addresses.

Again, in full transparency, Flow is only available for customers who run on AHV. Those customers running ESXi on Nutanix are unable to take advantage of Flow.

So what now? Well, if you run AHV, continue reading. And, even if you are running ESXi as your hypervisor, please see this through.

Flow microsegmentation is a fine-grained, distributed stateful firewall capability that’s centrally managed. It protects all east-west (VM to VM) traffic flows, and any traffic originating from or destined to, a VM. Unlike traditional firewall policies, microsegmentation policies are centrally managed and auto-updated, thereby removing operational hassles related to change management and rule management. As mentioned earlier, achieving separation using traditional perimeter firewalls would require VM to VM traffic to go through additional network hops and resulting latencies. Managing VM (application) centric policies using static rules in traditional firewalls also leads to operational complexity.

Unlike other products, like VMware NSX, that require additional VMs, control planes, and complicated configuration, Flow is native and built into AHV networking, and through Prism Central can simply be enabled by checking a box.

So, what do I get?

• Application-centric firewall policies that simplify policy authoring by abstracting away networking complexities from policy language. Therefore, enabling application teams and virtualization teams to easily manage application security postures as part of app lifecycle management, without the need for specialized networking expertise.

• Seamless insertion into a customer’s existing environment without the need for any network design changes. Flow enables customers to selectively phase-in securing their applications, as needed on a per-application basis. We are going to come back to this, remember the word “phase”!

• Built-in automation of policy change management where security policies are updated automatically, as VMs are spun up, down, or moved.

• Nutanix microsegmentation enforcement occurs inside the AHV hypervisor kernel and is fully isolated from being tampered with from a compromised guest VM.

• Single pane of glass. Management of all security policies for Nutanix microsegmentation is within Prism, which acts as the single pane of glass for all infrastructure and virtualization management. On the other hand, customers using competitive products bounce between multiple consoles to manage security policies in conjunction with their VM and infra management operations.

And, what about this simplicity?

One word. Visualization. 

What if it looked something like this?

Microsegmentation policies are difficult to define without understanding application flows. Since enterprise application architectures can be complicated, users may accidentally break applications while trying to define security policies. Flow visualization helps in visually identifying application flows and correlate them with policies.

Flow visualization is part of the policy view of microsegmentation from within Prism Central. Users can start with an empty set of rules for an application and query for all the flows corresponding to the app. Flows are summarized based on group membership and presented to the user visually, in the form of inbound and outbound traffic classes for that application. Users can then ‘accept’ specific flows to create policies that would allow them, and ‘deny’ individual flows that should not be permitted. Each AHV host identifies data at connection termination to collect source and destination address, port, protocol, and bytes transferred. This data is sent to Prism Central to build the flow visualization page.

Oh, by the way, Nutanix microsegmentation does not require overlay networking, which makes it inherently seamless and straightforward to enable in any environment! One thing I like to say is that Flow is like putting a firewall in front of every VM. And that firewall follows the VM regardless of where it lives.

What about my existing firewall, you ask?

If a customer has existing firewalls in their data center environment, they can continue to co-exist with Nutanix microsegmentation. Since Nutanix microsegmentation allows for a phased (there’s that word again) approach starting with specific applications, customers do not need to rip and replace their existing firewalls. As customers gain more familiarity and confidence with the effectiveness of Nutanix microsegmentation for their chosen apps, they can choose to divert away traffic for those apps from their existing firewalls. And, no network topology changes are necessary to enable Nutanix microsegmentation to work. All rule enforcement occurs on the network edge inside the AHV virtual switch and seamlessly works in all network topologies.

Wrap it up!

Let’s review the word “phased” that was sprinkled throughout this article.

In my opinion, one of the best features Flow has to offer is the ability to monitor VM traffic flows, allowing you to phase them into production. You can create your policies and visualize the flow of traffic without applying the actual policy. Do you know why this is so critical? It allows you to get your policy right before you apply it. It will enable you to enforce policies with the confidence that you are not going to disrupt your applications. Back up for a moment. Have you ever modified a firewall policy only to find that you created another issue on your network or with an app? I know I have! I have done that on several occasions. Flow allows you to visually see your policies before you enable them. You can avoid the embarrassing moment, hand slap, or career-ending event.

---

I apologize if this article went a little deep technically. For that reason, I put together a quick video to show how simple it is to use Flow.

One last thing. I realize I did not address AHV, and I should have. Hopefully, you are now intrigued enough by the simplicity and functionality of Flow that you want to give it a test-drive! So, I will get into AHV in the coming week.

Microsegment[ed]?