NSX Firewall Migrations: Progressive Microsegmentation

We've been hard at work lately doing a large NSX Firewall migration, which hasn't lent itself particularly well to blog posts (since all of the scripts that we've created have been so customer-environment specific).  I've realized that the high-level process that we've created could be helpful for other people doing similar migrations though, so I figured that I'd go ahead and write about it!

This migration has specifically been from a set of standard NSX firewall rules to a set of NSX policies.  Our goal with the creation of these policies has not been to recreate the existing rule structure, but rather to create a new policy structure that keeps everything running and really emphasizes manageability and progressive microsegmentation.

First, I need to explain our concept of progressive micosegmentation.  Microsegmentation is basically the practice of creating policies to allow only the minimally required traffic into and out of each VM.  This is a very difficult system to build, especially in a brown field environment!  So, we decided to use the concept of progressive microsegmentation where we microsegment larger logical entities and move down to the VM level as needed (and as time/application understanding allows).

We decided that our first level in our progressive microsegmentation would be the application.  This means that we treat all VMs that make up a given application as a single entity for microsegmentation.  So, we analyze the whole application and make sure that we understand all network flows going into and out of it, then we make our policies to control that traffic.  Traffic within the application is unimpeded at this first level.

So, if we look at a generic 3-Tier application, level 1 in our progression would involve policies that allow HTTPS traffic into the application, as well as whatever management & core infrastructure traffic is required by the systems.  This level is the easiest to create, but it leaves a fairly large attack surface.  The web servers need HTTPS traffic to function, so it's great that it's accessible... but at this level the App servers and the DB servers are also accessible through the firewall to HTTPS traffic.  And that's not ideal.

So, you solve that by progressing closer to true microsegmentation.  That means that we define sub-groups within our application.  At this point, the progression becomes more of a spectrum as we define more and more specific sub-groups and the policies that they need, but a common starting point is the presentation tier.

So, that means that our 3-Tier application (let's call it iAppX 2.0 because the fictional marketing team went ballistic) needs to be better understood.  We need to create a group for the whole application to have policies that apply to the whole application (for example, admin access), and we also need a group for the presentation tier (and to know which servers make up that presentation tier).  So, we create those security groups.  Now, we can apply the generic iAppX 2.0 policies to the whole application, but we can allow that HTTPS traffic in to only those web servers.  At this point, the web servers are approaching microsegmentation and the rest of the application isn't exposed to that HTTPS traffic.

This is great!  We've just created a fairly secure application... but it could be better.  The next common sub-group for increased security would be the DB group.  There are a limited number of database types that are used in most enterprise environments, and the network requirements for these databases are generally well understood.  So, our next step would be to limit the traffic (within the application) that's allowed to get to our DB servers. 

To do that, we create another sub-group, this one for the DB servers.  We then apply a policy on that DB sub-group that allows the DB traffic in and blocks all other traffic (we may have to be careful about the ordering of our policies to create this behavior, but once everything's in place, it'll basically take care of itself).  At this point, those DB servers are pretty effectively microsegmented.

Next up is the app-tier servers!  You should probably not mess around with the app-tier servers.  If your application is so sensitive that you really need to get them segmented, you'd just repeat the exact same process that you used on the DB servers... but the network behaviors of app-tier servers are rarely so well defined as the behaviors of a DB-tier server.  App-tier servers tend to be accessed by large numbers of systems within the Application on large numbers of ports, and they likewise often reach out to many systems within the application on many ports.

But, we don't necessarily even need to sub-group them.  If we have a presentation sub-group defined to limit the outside attack surface of the application and we have a database sub-group defined to secure our data plane, how much additional security do we really get by limiting the traffic that can enter the (perhaps vaguely defined) app-tier servers from the application itself?  For many applications, the security gains don't justify the work-effort.

So, does that mean that every application just needs a presentation sub-group and a database sub-group?  Not even a little bit!  If the application is a bunch of servers with combined presentation and DB functionality, there's no reason to create a sub-group structure (since all VMs would need all policies).  On the flip side, it's absolutely possible for an application to have multiple presentation or DB tiers!  Maybe there's a bunch of web servers that run a SaaS portal, but there's also a thick client that establishes a direct connection to the app-tier servers.  In that case, we'd want 2 presentation tier sub-groups: WebPresentation and ClientPresentation.  You'd then put an appropriate policy on each, allowing only the needed traffic to each of the presentation sub-groups.  You can create as many sub-groups as the application warrants, so that you can finely control what traffic gets into what parts of that application.

I call this model progressive microsegmentation for exactly that reason.  You can very granularly progress along this model towards true microsegmentation on an application by application basis, implementing the security that makes sense for each application.  And that's exactly what we've been doing!  Since we're in a brown-field environment, we have created many procedures for analyzing these applications, which I'll write about next time!