The VMware NSX Platform – Healthcare Series – Part 4.2: Micro-segmentation Practical with Application Rule Manager

Originally this series on Micro-segmentation was only going to cover Log Insight, vRealize Network Insight (vRNI), and VMware NSX.  With the release of VMware NSX 6.3, there is a new toolset within NSX that can be leveraged for quick micro-segmentation planning The Application Rule Manager (ARM) within NSX, provides a new way to help create security rulesets quickly for new or existing applications on a bigger scale than Log Insight, but smaller scale than vRNI.   With that in mind, we’re going to take the previous post using Log Insight, and perform the same procedures with ARM in NSX to create our rulesets using the same basic methodologies.

The Application Rule Manager in VMware NSX leverages real-time flow information to discover the communications both in and out, and between an application workload so a security model can be built around the application.  ARM can monitor up to 30 VMs in one session and have 5 sessions running at a time.  The beauty of ARM is that it can correlate the information that you would typically have to either have or look up in Log Insight to create your rulesets and significantly reduces time to value.  ARM can also show you blocked flows and the rules that are doing the blocking.

Let’s bring back our use case from the previous post and sub in, ARM instead.

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

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 – Client-01a (192.168.0.36)
  • Windows 10 – HR Desktop – Client-02a (192.168.0.33)
  • Mac OSX – Unauthorized Desktop – (192.168.0.18)

VMware Products

  • vSphere
  • vCenter
  • NSX and Application Rule Manager

Application in question –

Open Source Healthcare Application:

  • OpenMRS – Open Source EMR system
    • Apache/PHP Web Server
    • MySQL Database Server

Infrastructure Services:

  • NTP

The first thing we need to do to utilize ARM is establish the VM’s that we’re going to look at the flows from.  These systems will represent the session that we will build and run for a period of time to examine what flows are coming in and going out, and between these systems.

Since Infrastructure Services are generally global services that affect more than one system within a data center, we’re going to build the rules that accommodate our NTP virtual machine first.  We’re going to see more flows to other VM’s in the lab, but we’ll be narrowing it down to just the EMR systems.  Then when we’ve got those working, we’ll do the EMR-based rules.

First, we need to establish our naming scheme and methodology to writing our rule sets.  Below is a chart I use when creating my rules for the applications.  It helps me lay things out logically and then apply it quickly in the DFW.

ms_table_pic1

You will notice that I like to nest my Security, Services, and Groups.  I do this because at scale, this makes changing things much simpler and more efficient.  If I have to swap in a service or change a port, I want the changes to be reflected to all affected groupings down the table without having to seek out where else I might need to make a change.  This has consequences as well, you must pay attention to what you’re doing when you make a change as it can have effect on other applications.  This is why I name things the way I do, to ensure that any change you make that you understand the implications.

Now that we have all our custom services and naming convention in place, we can go back to the ARM and start resolving Services, Service Groups, and building out rules.  We’re going to take these flows and squeeze them down even further to create very succinct rules with as few entries as possible.

We’re going to create a session called INFRA MONITOR and add the NTP-01a server into the monitor so we can see all the flows coming in and out of it.

arm_ms_pic1

The amount of time that you collect flows for is up to you.  My advice is the following:

  • Understand the application you’re planning for. If this application is a billing cycle application that does 30 day monthly cycles, ARM my not be the tool to use.  ARM was built to monitor flows in real-time over the maximum of a 7-day period.  If the application you’re looking at has periodic flows that occur over a longer period of time, I suggest using vRealize Network Insight for those applications.  It has a longer retention period for looking up flows.
  • Keep the applications small. ARM has a 30 VM upper limit on monitoring of flows per session, with up to 5 sessions.  While most applications may fall into this range, some applications may have more than 30 machines.  In that case, my suggestion is breaking up the application into smaller chunks and running the chunks in different sessions to keep the numbers down.
  • ARM uses NSX Manager resources. Just like Flow Monitoring, ARM uses resources from the NSX Manager to collect flow data.  Be careful of NSX Manager utilization during this process.  Unlike Flow Monitoring, if you exit the interface, ARM will continue to run until you stop the session collection.

Once we hit OK, the flow collections will begin.

arm_ms_pic2

When we’re comfortable that we’ve captured all the flows from the VM, we can stop the collection and ARM will take the number of flows, de-duplicate the flows down to unique flows for us.

arm_ms_pic3

Now we’re going to analyze our flows.  This is going to resolve any VM names it can as well as resolve the ports to protocols that they could be.

arm_ms_pic4

I’ve hidden other flows to other systems within the lab for simplicity sake for now, and only focused on finding the flows to the EMR system.  You’ll also notice a column that I added into the View Flows tab.  The column is Rule ID.  The Rule ID column will show the applied rule that affects that flow in the View Flows table.

arm_ms_pic5

As you can see from the output, all the flows appear to be hitting the Rule ID of 1001.  If you click on the Rule ID 1001 link, it will pop open the details of the Rule from the DFW.  While this is showing an allowed flow, we will see later, that we can also see flows being blocked by a Rule ID.

arm_ms_pic6

The View Flows tab only resolves to VM names.  We’ll need to take this information and create appropriate Security Group, Service, and Service Group names for our rules.  We’ll click on the gear icon next to the EMR-DB-01a VM and select ‘Create Security Group and Replace’.

arm_ms_pic7

We’ll name the Security Group after the naming scheme you’ll find below of EMR-SG-DB and we’ll statically add in the VM, EMR-DB-01a.

arm_ms_pic8

What we’ll find is that the Security Group now replaces the virtual machine as the Source.  But since we’re both of the VM’s that make up the EMR talking to the same destination, we’ll create an EMR-SG-ALL Security Group and nest the individual VM Security Groups within it.  To do this, we can click on the gear for the Source we just changed, and select ‘Create Security Group and Replace’ same as before but this time we’re going to add the EMR-SG-DB Security Group to the EMR-SG-ALL Security Group we’re going to create.

arm_ms_pic9

We should now see that the Source has changed to the EMR-SG-ALL GROUP.

arm_ms_pic10

For the EMR-WEB-01a VM, we’ll do the same thing.  Create a Security Group called EMR-SG-WEB and add that VM to it.

arm_ms_pic11

We’ll then click on the gear and select ‘Add to existing Security Group and Replace’.  Then select the EMR-SG-ALL group, and this will nest the EMR-SG-WEB Security Group into the main group.

arm_ms_pic12

We repeat this same process for the NTP-01a VM according to the layout above.  Create an INFRA-SG-NTP and add the NTP-01a system.  Create a INFRA-SG-ALL and add the INFRA-SG-NTP Security Group to it.  This will allow us to add more SG’s to the main group later as needed without having to write another rule to do it.  When done, it should look like this.

arm_ms_pic13

You only need to do this to one rule as you’ll see later, we’ll grab both of these flows to write one rules.  We focus in on the Services that we found now.  If you click on the ‘2 Services’ link, you’ll see what ARM resolved the ports to, protocol-wise.

arm_ms_pic14

I like creating my own Services and Service Groups.  This way we know if we make changes, we know what could possibly be impacted.  So with this, we’re going to perform a similar workflow as we did above.  Create a Service and Replace.  Create a Service Group and Replace.  This will add the custom Service we create to the custom Service Group we create.

arm_ms_pic15arm_ms_pic16arm_ms_pic17arm_ms_pic18

Leaving us with this final result.

arm_ms_pic19

We’re now ready to create our rule from the two flows.  Selecting both rules, we right click and select ‘Create Firewall Rule’.

arm_ms_pic20

We’ll see some unresolved items in the list, but we’re going to make modifications so that this one rule covers both flows.  We’re going to:

  • Remove the NTP-01a as the Destination leaving the INFRA-SG-ALL
  • Remove the UDP 123 Service leaving the INFRA-SVG-ALL
  • Remove the vNIC for NTP-01a and add EMR-SG-ALL and INFRA-SG-ALL

arm_ms_pic21arm_ms_pic22

Once we click on OK, we’ll have a new rule created in the ‘Firewall Rules’ tab.

arm_ms_pic23

Double check our rule and make sure it looks correct and then hit ‘Publish’.  We’re then prompted to create a section name and select where to insert it.

arm_ms_pic24

We should get confirmation that the publish was successful and we can go to the ‘Firewall’ interface and verify our work.

arm_ms_pic25

Everything looks good!

Now we can focus on the EMR system.  Talking with our applications team, we have determined that the VM’s in question are:

  • EMR-WEB-01a
  • EMR-DB-01a

Now that we know the names of the VM’s, we can go into the Flow Monitoring section of the NSX Management console and select Application Rule Manager.  From here we can Start New Session.

We’ll select the VM’s we discussed above, EMR-WEB-01a and EMR-DB-01a, and we’ll add them to the session.  This will start collection of flow data from the vNIC’s of these VM’s and post them in the View Flows table.

From here we will create a new session, calling it EMR MONITOR, and add in our VM’s to the session.  Once we hit OK, the collection will start and we can stop the collection when we’re comfortable with the period of time we collected for.  In this instance, I’m going to collect data for 15 minutes.  I have automated tasks running to provide traffic to the EMR so we can see flows that run every 5 minutes, so this should be long enough for this demonstration.

arm_ms_pic26

Once we have stopped the collection, we should see the View Flows table has several flows showing.  ARM will attempt to de-duplicate repeated flows as much as possible.

arm_ms_pic27

Analyze the outputarm_ms_pic28

Now that ARM has analyzed our flow data and matched where it can we can see a few things:

  • Direction – This tells us in what direction the flow came to the source
    • IN – Inbound
    • OUT – Outbound
    • INTRA – Between
  • Source – Resolved to a VM name if the VM falls under the scope of the vCenter/NSX Manager relationship. If an IP address, represents an external IP system that is not resolvable in the vCenter/NSX Manager relationship.
  • Destination – Resolved to a VM name if the VM falls under the scope of the vCenter/NSX Manager relationship. If an IP address, represents an external IP system that is not resolvable in the vCenter/NSX Manager relationship.
  • Service – Resolved to all services that exist within NSX. If more than one service is shown, this means that the user will need to manually pick the service it correlates to because NSX has more than one service definition with that corresponding port number. If you want to create a custom Service or Service Group, which we will

With the information shown we have the following:

  • Inbound 192.168.0.99 > EMR-WEB-01a TCP 8080
    • 168.0.99 is identified as the Management Jumpbox for the infrastructure.
  • Inbound 192.168.0.36 > EMR-WEB-01a TCP 8080
    • 168.0.36 is identified as the Clinician Desktop
  • *Inbound HL7-01a > EMR-DB-01a TCP 3306 – Skipping this for now
  • *Outbound EMR-DB-01a > NTP-01a UDP 123 – Rule ID 1028
  • *Outbound EMR-WEB-01a > NTP-01a UDP 123 – Rule ID 1028
  • Intra EMR-WEB-01a > EMR-DB-01a TCP 3306

What you may notice when you have the Rule ID column unhidden, is that the two flows we already built for above in the Infrastructure section are showing as the Rule ID 1028 which is the Rule ID for that Infrastructure rule.  As I said before, ARM can show you any flow and the corresponding rule in the DFW that it’s hitting.  All of the rest of the flows are hitting the Default Allow Rule ID of 1001 just like Infrastructure before we started.

arm_ms_pic29

What this means for us, is that we’re already covered on Rule ID 1028 for NTP Services and we can hide these two flows.  We’re also going to hide the HL7-01a flow so we can see another interesting feature that ARM can show us.

arm_ms_pic30

This leaves us with three flows we need to write rules for.  Using the same methodology as we did above, we’re going to create our table for naming and apply it to the VM’s, Services, Security Groups, Service Groups for the EMR.

ms_table_pic2

Good news is that we’ve already created Security Groups for the EMR system when we created the Infrastructure Rules.  We just need to ‘Replace with Membership’ each VM with the appropriate Security Group.

arm_ms_pic31

When you select ‘Replace with Membership’, ARM will show you all the Security Groups that the VM belongs to.  You’ll notice the differences when you change EMR-WEB-01a and EMR-DB-01a.

arm_ms_pic32arm_ms_pic33

We do however, need to create IP Sets for the Desktop systems that we’re going to allow access to the EMR through.  We do this by clicking on the gear and selecting ‘Create IP Set and Replace’.

arm_ms_pic34arm_ms_pic35arm_ms_pic36

We then create the EMR-SG-ACCESS Security Group and add these two IP Sets to it and replace.

arm_ms_pic37arm_ms_pic38

We need to resolve our Services now as well.  We have two unresolved ports of 3306 and 8080.  Again, we’re going to refer to the table and create new Services and Service Groups for these.

arm_ms_pic39arm_ms_pic40arm_ms_pic41

There’s no reason to resolve the service for the second IP-based flow, as the services are the same and we’re going to create one rule like we did above for these two flows since they’re fundamentally the same.  Time to swap in Service Groups.

arm_ms_pic42arm_ms_pic43arm_ms_pic44

We’re now left with this output.

arm_ms_pic45

Let’s create our rules.  We’re going to select both of the IP-based rules and combine them.

arm_ms_pic46arm_ms_pic47

Cleaned up it looks like this

arm_ms_pic48

Now to create our INTRA communication rule between the EMR-WEB-01a and EMR-DB-01a VMs.

arm_ms_pic49

Cleaned up it looks like this

arm_ms_pic50

We now have our two rules that we can publish to the DFW for the EMR application.

arm_ms_pic51

We’ll create a new section called ‘EMR’ and place it below our Infrastructure Section.

arm_ms_pic52

Double check our work.

arm_ms_pic53

Things look correct.  Let’s add in our Block Rules so we can do our testing to make sure we did this correctly and it meets the requirements.

arm_ms_pic54

Here’s the list of requirements the customer gave us:

  • 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

With ARM, we can check that these requirements are hitting the correct rules very quickly.  We’re going to create another Monitor session to monitor EMR-WEB-01a, EMR-DB-01a, and NTP-01a.  When we see the flows that come out, we should see the rules that they hit.  This will quickly tell us if things are working correctly.  I’m also going to generate traffic that should hit the block rules because they don’t meet the requirements.  Let’s start!

arm_ms_pic55

arm_ms_pic56

We can see flows hitting the Rule ID’s to the right which is good.  We’re going to stop the collection and do an analysis on the flows captured.

arm_ms_pic57

We can see the flows captured and the Rule ID’s associated.  Nothing appears to be hitting the Default Allow Rule ID 1001 which is good.  The Application is functional and NTP is accepting connections from the VMs.  If we take a look at the first requirement:

  • Allow EMR Client Application to communicate with EMR Web/App Server

arm_ms_pic58arm_ms_pic59

You can see that both of the IP-based flows are captured under Rule ID 1030 which when you click on it, shows the correct DFW rule.  Let’s check the next requirement.

  • Allow EMR Web/App Server to communicate with EMR Database Server

arm_ms_pic60

You can see that by clicking on the Rule ID of 1029 for the EMR-WEB-01a to EMR-DB-01a flow, that that traffic is hitting the correct rule.  Let’s check the next requirement.

  • 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.

arm_ms_pic61

When we look for block based rules, we’re looking for anything hitting a block rule in the DFW.  In this case, Rule ID 1032 is a Block rule.  We seem to have two flows that are hitting that rule.

arm_ms_pic62

When we drill into Rule ID 1032, we see that it is indeed, our Block rule.  Let’s look at the last requirement.

  • Allow bi-directional communication between the Infrastructure Services and the entire EMR Application

arm_ms_pic63

From this picture, we can see that there are two flows from the EMR VMs to the NTP server.  Both are hitting Rule ID 1028.  When we open up that rule we see that it is indeed hitting the correct rule to allow NTP traffic to flow to the NTP server from the EMR.

arm_ms_pic64

This completes our requirements set forth by the customer to meet to secure the EMR application.

As you can see, ARM is very adept at helping simply micro-segmentation with VMware NSX.  Taking the concepts we learned and leveraged with Log Insight, we can remove quite a bit of manual processes involved with resolving services and VM’s IP addresses to their names.  I was able to perform this process in about 15-20 minutes outside of flow capture time from start to finish and that’s what makes ARM another very useful toolset to use for reducing the complexity of micro-segmentation.

The VMware NSX Platform – Healthcare Series – Part 4.1: Micro-segmentation Practical

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.

Picture1.png

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.

Picture2.png

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

Picture3.png

Security Tags

Picture4.png

DFW Rules

Picture5.png

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.

Picture6.png

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:

picture7

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 seeing the IP address of the logs and not the DNS names. We can now pick out the connections to start writing our more specific rules:

  • 192.168.0.99 > 192.168.0.25 over TCP 8080
    • 192.168.0.99 is the Clinician Desktop that’s accessing the EMR WEB server. Since we were unsure who was accessing the EMR and we want to lock it down so only specific machines can access, we’ll leverage an IP Set here since this machine is outside the NSX environment.
  • 192.168.0.25 > 192.168.0.27 over TCP 3306
  • 192.168.0.27 > 192.168.0.25 over TCP 3306
    • This is an exampled of a stateful TCP flow. The application established a connection over 3306 to the database server and the database server responded back on 3306.  Since the NSX DFW is stateful, we can write one rule to allow the application server to talk to the database over 3306 and the database can response back on the same port without needing to open any ports or writing any rules for the database server for that communication to occur.

We’ll quickly add a new Security Group and IP Set for the Jump Box system so we can build a rule that only allows this system to communicate with the EMR.  I have another Windows 7 desktop called CWS-01a, 192.168.0.33, that we will attempt connection to the EMR from and show how we can restrict who can actually hit the EMR application from the web interface.

Picture8.png

Before we write our rules, the port 8080 does not match anything in the NSX Services list specifically for this application.  However, there is a listing for 3306, MySQL.  Being that this is the most critical Healthcare application, I recommend creating your own Services and Service Groups within NSX to accommodate these ports regardless of whether or not they’re in the Services list.  This provides a visual cue to anyone looking at modifying a service in NSX.  They will immediately know that this service is in use by the EMR and that they should be very careful making changes or removing it from NSX.

Services and Service Groups behave in a similar fashion to Security Groups.  You simply create the Services you want and add them as members of the Service Group.  You can find a post a did a while back on how to go through this process here.  I’ve already went ahead and built and added them.

picture9

picture10

When we take all this information and put it into NSX DFW rules we get the following configurations:

Picture11.png

Let’s break down this output and explain this in simple terms.

  • Rule 1 – Restrict EMR Access
    • EMR-SG-ACCESS (IP SET = 192.168.0.99) > EMR-SG-WEB over EMR-SVG-WEB (TCP 8080) is Allow and Applied To EMR-SG-WEB

Functionally we are allowing a system outside the NSX environment, my jump box with an IP of 192.168.0.99, access to the EMR-WEB-01a system over TCP port 8080.  Were applying this rule only to the EMR-SG-WEB Security Group.  This means that only the EMR-WEB-01a will get this rule in its firewall.  This reduces adding rules that don’t need to apply to a VM where they’re not needed.  The power of NSX in this scenario is that if the EMR system adds another WEB server that needs to talk to the DB, we can simply apply the EMR-ST-WEB Security Tag and that system will be immediately put into the EMR-SG-WEB Security Group and the above NSX DFW rules will apply to that machine too!  Consistently applying security through operational simplicity is just one of the many benefits NSX provides.

We then applied a similar rule to only allow EMR-WEB-01a to communicate with EMR-DB-01a over 3306 and applied those rules to each of the Security Groups to reduce rule sprawl.  Going back to the discussion about stateful firewalling from above, we only needed to add this one rule and when the WEB system communicates over 3306 to the DB, the response communication back to the WEB system is not necessary.

Finally, we have the last 4 rules for logging inbound and outbound communications for the entire application.  Now that we have more granular rules and have reduced the number of open ports down to the 2 necessary, we can turn off our Allow All rules and ensure the application is functioning.  At this point we’re not seeing any communication in and/or out of the application to any other systems so we can comfortably test the application.  Let’s go back to our use cases and requirements to see if we fulfilled them properly:

  • Allow EMR Client Application to communicate with EMR Web/App Server
    • Built EMR-SG-ACCESS > EMR-SG-WEB over 8080
  • Allow EMR Web/App Server to communicate with EMR Database Server
    • Built EMR-SG-WEB > EMR-SG-DB over 3306
  • Block any unknown communications except the actual application traffic and restrict access to the application to only a Clinician Desktop system running the EMR Client Application.
    • Restricted access to only 192.168.0.99
      • Test attempt to login from another system, 192.168.0.33, and verify that the access is blocked and hitting Rule ID 1006 that blocks unauthorized access to the application.
      • Test attempt to SSH from Web to DB
  • 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.
    • We’re going to follow up on this requirement in the next post as we expand the environment out further to include more applications.

I’ve turned off the Allow All rules and we can now test our results to ensure the application works and we fulfill the requirements asked. Disabling the rules turns them grey.

picture12

Allow EMR Client Application to communicate with EMR Web/App Server – Rule 1009Allow EMR Web/App Server to communicate with EMR Database Server – Rule 1010

Picture13.png

picture15picture14

We can access the application from the Clinician Desktop as expected and application is working as we would not be able to login and perform a patient lookup.

Let’s see if the block requirements are working properly.

Block any unknown communications except the actual application traffic and restrict access to the application to only a Clinician Desktop system running the EMR Client Application.  Rule – 1006

  • Restricted access to only 192.168.0.99
    • Test attempt to login from another system, 192.168.0.33, and verify that the access is blocked and hitting Rule ID 1006 that blocks unauthorized access to the application.
    • Test attempt to SSH from Web to DB

Picture16.png

Trying to SSH from WEB to DB

Picture17.png

Let’s look in Log Insight to confirm

Picture18.png

Looks like we have covered all the bases with our rule sets we built.  The application is functional and the appropriate systems are able to access the EMR application.

I know this post was fairly long for an application that only had two ports, but in the next post we’re going to be adding more complexity to this environment.  The fundamentals are sound as we’ll be applying them to the rest of the applications we introduce.  Remember, the Healthcare EMR is connected to many ancillary systems in a Healthcare Organization, it doesn’t just function on its down. We’ll be adding in systems that will talk to our EMR and showing how to do micro-segmentation at scale using vRealize Network Insight and then leveraging Service Composer with NSX.  This will setup the foundation for subsequent posts in the series.

The VMware NSX Platform – Healthcare Series Part 3 – Micro-Segmentation Concept

When using an application-based policy approach, security is a critical part to the application workload.  Security is just as important as how much CPU or RAM you give an application workload.  The VMware NSX Platform introduces 3 primary use cases when it comes to security for application workloads.  We’re going to focus on the first use case:  Micro-segmentation and how it relates to Healthcare organizations.

picture1

A quick background on why Micro-segmentation is important and security trends in modern data centers. In most modern data centers, there has been a large uptick in the amount of traffic that occurs between systems rather than inbound-and-outbound of systems.  This is referred to as East-West traffic within the data center, versus North-South traffic in and out of the data center.  In the hardware-base world, security for East-West traffic is sometimes done either by sending the traffic from their applications to their perimeter firewalls or by purchasing hardware appliances to put inside the data center between the applications. This form of security is through isolation and segmentation of the applications.  You can do this at the entire application level through concepts such as Trust Zones, achieving what some call macro-segmentation, but when we place security at the workload level we achieve what’s called, micro-segmentation.  Micro-segmentation facilitates a Zero-Trust security model. Zero-Trust means that unless communications between systems are explicitly trusted, it’s implicitly untrusted.  The application of Micro-segmentation using a hardware-based approach creates a two-fold problem:

Lack of interior controls and security – If an organization simply does nothing, no use of micro-segmentation, to secure the East-West traffic within their data center, the perimeter firewall becomes the single point of entry and security to their environment from North-South.  This type of defense still provides protection, however once an attacker is able to break through that perimeter, unfettered access around the inside of the environment is rather easy.  With no lateral controls, the attack surface is enormous for attackers to work with.

Picture2.png

Operationally infeasible and lack of scale – If an organization puts in hardware appliances or use the external firewall to facilitate Micro-segmentation for both East-West and North-South traffic firewalling, those systems become operationally difficult to manage.  Hardware appliances are costly and only scale to a point.  Multiple user interfaces and policies that don’t scale as you add new workloads or even modify existing workloads into your data center and certainly don’t provide mobility in a virtualized environment.  As you add new applications you may need to add more firewalls.  If a workload needs to move, you may need to move or change the rules associated with that application.  And what happens when that application needs to talk to another application?  All those rules need to change as well.  While this can reduce the attack surface of the application, it’s operationally infeasible to support and lacks scaling as a long term option for customers.

Picture3.png

How does the VMware NSX Platform provide a business value around these issues? The VMware NSX Platform uses a software-defined micro-segmentation approach applied at the Virtual Machine workload level to facilitate a Zero-Trust security model.  This security is built into the vSphere hypervisor creating a distributed and scale-out firewalling architecture.  This architecture provides kernel-level performance and scales as your organization and workload requirements increase without the need to add more specific hardware appliances to the environment.

Picture4.png

Let’s focus on Healthcare customers specifically.  A recent study by the Ponemon Institute and IBM for 2016, shows that a security breach and exposure of a patient health record is now averaging $355 per record.  The average total cost to an organization in the US was $7.01 million and the average number of records breached was around 29,000.  Traditional methods of security, like those listed above, are no longer sufficient to prevent attacks.  While there is no ‘silver bullet’ to security, Healthcare organizations can provide a layered approach to security that helps reduce their attack surface overall and reduce the potential for exposure. The VMware NSX Platform, through the use of Micro-segmentation, allows Healthcare organizations to accomplish this.

The VMware NSX Platform can provide an application-based security policy around the critical and patient information sensitive applications within the data center.  This provides us the ability to effectively control all communication paths both in and out of the application, thus reducing the attack surface of that application immensely.

The EMR/EHR system for Healthcare organizations, represents a mission-critical application for the organization and houses the majority of patient record information.  For this example, we’re going to look at a typical installation of an Electronic Medical/Health Records system, EMR/EHR, and how traffic both in and out and between the servers within the application are secured. They can be comprised of several Windows/Linux and Appliance-based systems. Below is a typical example of the layout of an EMR/EHR system server architecture.  Most consist of a client application that connects to the Application Server which has a Database Server connection where the data is stored.

Picture5.png

Let’s take a look at traditional security approaches to East-West and North-South traffic isolation, first.  You’ll see below that for North-South traffic, the end user workstation could traverse through either a perimeter firewall or an internal data center firewall before it gets to the presentation layer of the EMR/EHR.  Also from an East-West perspective, to secure communications between the servers within the application and Shared Services, the traffic patterns will need to traverse through those same firewalls to either allow or block the communications necessary for the application to function. This creates a hair pinning effect that is operationally inefficient.

Picture6.png

With the Physical Firewall Policy, we’re now sending all the traffic through the external firewall to do the segmentation for the applications.  This firewall could also be an internal firewall between the applications.  Nevertheless, the premise stands.  Sending all the traffic through that firewall will not scale-out as your workloads increase and this is just one application in this environment.  Most Healthcare organizations have hundreds of applications they need to secure.

With the VMware NSX Platform, we instantiate a stateful, Layer 2-4, firewall at the Virtual Machine virtual network card level, which allows us to create security policies based on the application, that can secure the application in the host itself, rather than traversing to an external firewall.  This reduces the dependency on the external and internal physical firewalls for allowing and disallowing of traffic both in and out and between the EMR/EHR system and provides a much more operationally efficiency configuration for both network and operational resources.

Picture7.png

As you can see, the VMware NSX Platform has Security Policies created for each of the different applications, in this case the EMR App Server, the EMR DB Server, and the Infrastructure Services Servers.  Through micro-segmentation, we can setup NSX Security Policies that only allow the traffic that needs to occur within the application, to actually occur.  This enforcement is done in the hypervisor with no need to traverse to a hardware Firewall device to secure the workloads.  What we see here is:

  • The EMR Client Application initiates a connection to the EMR App Server.
  • The EMR App Server allows inbound communications to occur with the EMR Client Application and also allows communication to the EMR DB server.
  • The EMR DB Server only allows connections inbound from the EMR App Server. This functionally secures the EMR application to only allow the communications that are necessary for the application to function, and the EMR Client Application to connect to the system securely.
  • The EMR App and DB Servers are also allowing both inbound-and-outbound, communications to the Infrastructure Services servers.

Using the VMware VMware NSX Platform, Healthcare organizations can implement security at a much more granular level that provides a simple way to secure Healthcare organizations application workloads and reduce their attack surface.  Security is now implemented at the virtual machine workload level using the Application-Based Policy control.  This new model, scales as the application workload scale in the data center environment while still providing the same security posture consistently.

The VMware NSX Platform – Healthcare Series Part 2 – Environment

To get started with the series, we need to establish the environment that we’re going to use to apply the NSX platform concepts on and the applications we’re going to use.  Access to real world applications is a great way to break out of the typical test application bubble and really apply these concepts.  One of the requirements I had for this environment was that all the software had to be in use somewhere in production and the applications needed to obviously be Healthcare applications.  Getting access to a full EMR, PACS, HR, or other Healthcare-related systems would be very difficult and costly.  However, after some serious digging I found open source alternatives that are in real-world usage today.  These applications can facilitate the points of how Healthcare application integrate with each other and are representative of typical applications in a Healthcare organization.

With that in mind, using a combination of open source software, VMware products, and 3rd party partner products, we’ll be able to showcase multiple use cases and how the NSX platform can help customers move toward a Software-Defined Datacenter and drive application-based policy through the stack.

Open Source Healthcare Applications:

  • OpenMRS – EMR system
    • Apache/PHP Web Server
    • MySQL Database Server
  • DCM4CHEE – PACS (Picture and Archiving Communication System)
    • Apache/PHP Web Server
    • MySQL Database Server
  • OrangeHRM – HRHIS (Human Resource for Health Information System)
    • Apache/PHP Web Server
    • MySQL Database Server
  • Weasis – DICOM (Digital Imaging and Communications in Medicine) system
    • Runs on a Windows-based system
  • DTKv – DICOM Emulator
    • Runs on a Windows-based system
    • Used to simulate a modality for the PACS system
      • Modality – MRI, CAT Scan, etc.
  • Mirth Connect – HL7 Interface Engine
    • Apache/Java
    • MySQL Database Server
  • DHIS – Health Information Management System/Data Warehouse
  • i2b2 – Informatics and Data Warehouse

VMware Applications:

  • vSphere
  • vCenter
  • NSX
  • vRealize Log Insight
  • vRealize Network Insight
  • vRealize Operations Manager
  • vRealize Automation
  • vCloud Air – Advanced Networking Services
  • Site Recovery Manager
  • vSphere Replication

3rd Party Applications:

  • Palo Alto
    • Panorama
    • V1000MH
  • Trend Micro
  • EMC Virtual Isilon

Infrastructure Servers:

  • Active Directory
  • DNS
  • NTP

This list subject to change and will grow over time, but provides the foundational basics we need to setup a true re-creation of what a Healthcare organization would be using in their own organizations. We’ll be using the new nested system I built to provide the environment to test in.

Starting with a conceptual design we have the following for our environment:

Picture3.png

As we continue with the series, we’ll add in a second site for discussions around Business Continuity and Disaster Recovery, Metro-Pooling, Hybrid-Cloud use cases.

The VMware NSX Platform – Healthcare Series Part 1 – Intro

At VMware, I’m part of a dedicated team of professionals that are focused solely on Healthcare organizations.  My role is around providing NSX specialist support to my customers.  If you’re in the Healthcare field, you know that Healthcare has a vastly different approach when it comes to business goals than say Financial or Retail.  Healthcare customers are focused on patient care, driving down costs, security of patient information, and how fast they can innovate their services to their patients. Healthcare also brings up interesting and different challenges from a business and use case perspective.  We believe that the NSX platform can help organization with the business goals that matter to them, and more specifically we’re going to examine how Healthcare organizations can benefit.

The NSX platform is one of the three pillars in VMware’s Software-Defined Data Center (SDDC) approach.  When extended to our Compute virtualization platform, vSphere, and our Software Defined Storage platform, VSAN, the NSX platform provides the software networking portion of the infrastructure that allows an organization to drive Application-based policy through the entire infrastructure stack.

picture1

Similar to how vSphere disrupted the hardware compute business by removing dependency on specific hardware to run application workloads, the NSX platform is doing the same for the networking hardware layer. We’re not saying the hardware layer is not important and/or irrelevant, but driving application-based policies through hardware intelligence is something that can often times require specific and even proprietary hardware to accomplish.  With a software-defined approach, customers can choose the hardware of their choice and budget, and layer on the same hardware intelligence through software products and gain speed and agility, but not at the cost of security.  This means the focus of organizations moves to the application where it should be, and less on the hardware-based infrastructure.

When looking at a Healthcare organization and asking how the NSX platform can help achieve their goals, we need to examine the NSX use cases and find out how they apply to a Healthcare organization.  The NSX platform provides several outcomes for organizations:

 

Picture2.png

As you can see, the NSX platform is truly a strategic platform, and not simply a tactical solution for one business goal a customer wishes to accomplish.  The NSX platform extends into multiple areas of the infrastructure and customers are seeing tremendous benefits.  While some customers often start with a single use case, we’re seeing our customers immediately find other use cases for the product.  Over the next series of blog posts, we will be digging into each of the use cases for the NSX platform listed above and how these use cases are applying to Healthcare organizations.

New Home Lab Build

In previous iterations of my home lab, I’ve built on the premise of keeping things as close to a ‘production’ system as I could.  This meant running physical equipment and setting up scenarios with that line of thinking. This grew from two physical hosts that I bought back in 2010 and then grew into the three vSAN nodes that I added in 2014 and Cisco 3750G switches that I added in as well.  I managed to build out a dual-DC type of configuration and it worked great for quite a while.

Since joining VMware in late 2014, my lab has been satisfactory to keep my skills current.  As I made the transition to the Networking and Security Business Unit, NSBU, at VMware in January of 2016, the lab has been in need of some updating.  Recently I made a decision to build out a new home lab, this time consisting of high-end pieces and going with nesting.  I sold off my vSAN nodes, moved one of my old servers to be my wife’s new desktop, it’s still a badass for what she needs, and I got rid of the loud and power-hungry 3750G’s.  The result has been a dramatic reduction in heat and noise in my office which is where I had to put my lab as I’m not fortunate to have basement where I can this gear.

As I started going down the path of deciding what I wanted to build, I knew it had to be powerful, quiet, and as power-efficient as possible.  I wanted maximum capabilities to run multiple topologies and basically be a on-premises version of VMware’s OneCloud environment we have to demo and testing.  With my new job in the NSBU and working with the VMware NSX platform, there are so many different use cases that I wanted to be able to setup and test out that my Healthcare customers may run into.  With some back and forth with my homeDC peer, Erik Bussink, I came up with a build that does just that.

The build consists of the following:

The best thing about this was I was able to sell all the other parts of my home lab and not have to add too much more cash to build this.  I got a really good deal on the NVMe drive off eBay as those can run as much as $2500 by themselves.

The rest of my lab consists of the following:

The result has been a new high-powered and fully capable lab system that meets all my requirements.

screen-shot-2016-11-13-at-9-40-58-pm

screen-shot-2016-11-13-at-9-40-43-pm

screen-shot-2016-11-13-at-9-40-14-pm

Managing Custom Services in NSX

I was working on some labs recently and creating custom services to block ports that may otherwise not exist in the NSX Service list. NSX allows you to create custom services in Firewall rules to block certain kinds of services. I was fumbling about in the interface trying to figure out where all you could create these custom services, and also where the heck do I edit them after I’ve created them? Just a bit of background on what I’m talking about.

Services – NSX has out of the box Services that can be used when creating Security Policies and Firewall rules for common types of services that may run in most datacenters. These can be used to either, Accept, Block, or Reject, those types of service traffic with NSX. Here’s just a glimpse of the list. It’s quite extensive.

NSX_custom_service_pic1

Service Groups – NSX has out of the box Service Groups, which are groupings of common services that make up certain types of applications. You can see from this list, what I’m referring to. Let’s take a look at SharePoint 2010. It has several services that could be grouped together to easily create one rule that could encompass all of the services associated with that application. This means when I want to setup a rule for that type of application service, I only have to create one rule to ‘rule’ the entire application. Beautiful!

NSX_custom_service_pic2

As I was working through my lab and practicing making Security Policies and Service Groups using the Service Composer, I noticed that when I went to put in a service I wanted to block, that service wasn’t in the list. Nobody likes CIFS and I wanted to try and block it for a VM. So I figured I would just create a custom service for CIFS to block it. What I found was that CIFS wasn’t in the list. 😦

NSX_custom_service_pic3

What I also found out is that you can’t create a custom service from Service Composer through the Security Policies Wizard. You can see from the shot below there’s no ‘New Service…’ link.

NSX_custom_service_pic4

However there is a ‘New Service…’ link when you edit a Firewall rule as you can see here. I figured there had to be a better way to get my custom Service input without having to go through a Firewall rule to do it.

NSX_custom_service_pic5

Never one to consult the documentation, because what fun is that, I went digging through the interface to find out where the custom service would show up and I found it!

The list of Services and Service Groups can be found by selecting NSX Managers>Click on the NSX Manager in the list>Manage>Grouping Objects>Service/Service Groups. From this interface I can create new services and new service groups as well as edit them. You can also edit the out of the box policies as well.

According to this link, I can see what I need to help me in terms of ports and protocols.  Now I can create my custom service for CIFS. CIFS operates on both TCP and UDP 445, so I’m going to create a custom Service Group to encompass both of those into one easy group to make my rule with. But I first have to create both of the services I want to add to the group, one for TCP and one for UDP.

NSX_custom_service_pic6

NSX_custom_service_pic7

I can now add both of these to a new Service Group to be used in my Security Policy.

NSX_custom_service_pic8

And now I can select it from the list when I create my Security Policy and all is well. Easy stuff.

NSX_custom_service_pic9