The VMware NSX Platform Healthcare Series Part 4.1: Micro-segmentation Pra ...

In the previous blog post, we discussed how the concept of micro-segmentation provides a Zero-Trust security model for Healthcare applications. We also discussed how that model would apply when we talk about security around a Healthcare organization’s EMR/EHR. In this post we’re going to take those concepts and actually apply them to a Healthcare lab environment to show how we functionally achieve this outcome. With some applications however, organizations are not privy to the details of the communications flows for the application. In this post, we’ll be leveraging VMware tools to help figure out how the application actually communicates so we can write our rule sets. We’ll be focusing on using the NSX DFW and Log Insight to create our rules for the application. The next blog post will be over using Service Composer and vRealize Network Insight and rule building at scale.

Use case Provide a Zero Trust security model around a Healthcare Organization’s EMR system. Facilitate only the necessary communications both to the application and between the components of the application.

Allow EMR Client Application to communicate with EMR Web/App Server Allow EMR Web/App Server to communicate with EMR Database Server Block any unknown communications except the actual application traffic and restrict access to the EMR application to only a Clinician Desktop system running the EMR Client Application. Allow bi-directional communication between the Infrastructure Services and the entire EMR Application We’re going to skip this part for now as we’ll add it in later when we expand the use case.

Problem The Healthcare organization does not have a clear understanding of how the application communicates within and outside the organization. Organization wants to lock down the EMR application so that only known good workstations can access.

Technology used

windows Clients:

Windows 10 Clinician Desktop (my jump box system) Windows 7 Non-Clinician Desktop (random system on the network)

VMware Products

vSphere vCenter NSX vRealize Log Insight Application in question

Open Source Healthcare Application:

OpenMRS Open Source EMR system Apache/php Web Server mysql Database Server

With the EMR system I have deployed now, OpenMRS, it consists of two systems; the Web/App server and the Database server. The Web/App server runs queries and application-specific functions against the Database server.

I’m not going to go through how to deploy and install the VMware NSX Platform. Suffice it to say, that’s covered very well in many other blog posts and deployment is rather trivial. In this environment, I have 3 ESXi servers in my Compute1 Cluster. All three hosts are prepared with the VMware NSX Distributed Firewall (DFW) software bundle. Once the NSX DFW has been deployed, all virtual machines that reside on those hosts will be covered by the Layer 2-4 stateful Distributed Firewall that NSX provides at the virtual network card level of each virtual machine. To start the process of locking down the communications between the systems we need to first come up with our methodology for doing so. Since the NSX Manager is connected to the vCenter Server, we can use vCenter-type objects to build our rules, in this case we’re going to use VM names. When we move these systems to different networks and the rules still work, this will make more sense and show the agility of the VMware NSX Platform.

For applications we’re unsure of how they interact, there are tools and methods to help build your rule sets for NSX DFW. I going to use vRealize Log Insight and also vRealize Network Insight. Both provide very granular ways to help build your rule sets and offer slightly different approaches overall. When you write your rules you can leverage either the NSX DFW or Service Composer.

First let’s start with the methodology I use to build rules using NSX DFW and Log Insight

Create NSX Security Groups and Security Tags for each of the different ‘tiers’ of the application in question. The Security Tags will be applied to the VMs of each tier, and the Security Tag will be the criteria which places the VMs into the Security Group. There are many different ways to included VMs in a Security Group and tags is just one. We’ll be looking at more in future posts. The IP addresses are there for reference purpose, not as a criterion for inclusion. Security Group Application EMR-SG-WEB EMR-SG-DB Security Tag Application EMR-ST-WEB EMR-WEB-01a 192.168.0.25 EMR-ST-DB EMR-DB-01a 192.168.0.27 Create an NSX Security Group for the entire application. This will be used to nest the different tier Security Groups into. Security Group EMR-SG-APP EMR-SG-WEB EMR-SG-DB Create firewall rules in the NSX DFW interface. We start with very general rules for the entire application. Once we take a look at the flows within Log Insight, we can write more specific rules for the application that will only comprise of the necessary ports and protocols for the application to function. Allow All Inbound Log Rule ID 1008 DFW Allow All Outbound Log Rule ID 1007 DFW Block All Inbound Log Rule ID 1006 DFW Block All Outbound Log Rule ID 1005 DFW Security Groups

Security Tags

DFW Rules

This methodology allows us to see all the traffic coming in and out and between the application and pipes it all to our logging application. As the application generates traffic, we’ll be able to use either Log Insight or Network Insight to see it. We simply apply the Security Tag to VMs and they’re placed into the appropriate Security Groups and subsequently the NSX DFW rules are applied.

Now that we have the application traffic being logged and the rules placed into the NSX DFW, we will bring up vRealize Log Insight and take a look at the traffic patterns.

As we can see, we’re getting traffic connection hits on the two rules we should be getting hits on, the 1007 and 1008 rules which are the Allow All Inbound/Outbound Log rules. This is exactly what we should be seeing. When we dig into the connections and do an Interactive Analysis on each of the hits we’re getting on these two rules we see the following in the Field Table:

We can see that our rules are working and when traffic is generated to the application, we’re seeing the connections being established within the application and to the application. With Log Insight we’re constrained to only seein