The VMware NSX Platform – Healthcare Series – Part 4.3: Micro-segmentation Practical – vRealize Network Insight

In the last post, we showed the methodology to building out Micro-segmentation rules for the OpenMRS EMR application in the test environment.  This was a straightforward process using the VMware NSX Distributed Firewall and vRealize Log Insight. The process became even simpler when we leveraged the new NSX 6.3 feature – Application Rule Manager. More importantly it gives us a starting point for applications to provide a Zero-Trust security posture.

As we continue the series, we’re going to expand the Healthcare organization’s environment to include other systems that are typically running.  As Healthcare professionals, we know that while the EMR is a critical application, it’s not solely an independent system.   There are many systems within the Healthcare organization that have connections to and pull information from the EMR system, and there are other systems inside that environment as well beyond clinical-facing.  All of these systems require the same amount of security as the EMR system does.  In this post, we’re going to leverage the VMware NSX Platform, our foundational methodology for micro-segmenting we built out in the first post, and vRealize Network Insight to help build our NSX DFW rules for several new systems we’re going to be adding in.  This will help complete the environment build out and conclude the Micro-segmentation NSX use case for the series.

Let’s start with a layout of the environment and the systems we added in to show just how complex this type of environment could be.

Lab_topology.png

  • We have our EMR system as we had in the previous posts.
  • We’re now going to add a DCM4CHEE PACS system that our OpenMRS EMR can forward events to. Our PACS system has 2 modalities, a CT and MRI scanner that talk to the PACS system, simulated using the DTKv modality emulator.  These systems simulate physical devices out in a clinical setting.
  • We’re introducing an HL7 Interface Engine, Mirth Connect, that is pulling data from our EMR and sending that information via SFTP over to our Data Warehouse DB server for processing into a population health application. When the SFTP job is complete, the HL7 system will be sending an email notification of completion to our hMail, email server.
  • Finally, we’re going to connect the systems to the organizations Active Directory, DNS, and NTP servers for the shared infrastructure based services these systems require.

 The Healthcare organization has asked that we expand the Zero Trust security model using NSX to their entire environment.  They have given us some details about the applications and requirements on what we need to accomplish.  Given the size of the environment and number of applications now in-scope, the customer has asked for a scalable way to operationalize Micro-segmentation.  The customer has added several new integrations to the EMR and between other application systems in the infrastructure.  We need to find out what the applications are, verify with Application Teams, block/allow as necessary per Application Team.

 Expanded Use case – Provide a Zero Trust security model using Micro-segmentation around a Healthcare organization’s data center applications.  Facilitate only the necessary communications both to the applications and between the components of the applications.

  • Allow EMR Client Application to communicate with EMR Web/App Server
  • Allow EMR Web/App Server to communicate with EMR Database Server
  • Allow PACS Client Application to communicate with PACS Web/App Server
  • Allow PACS Web/App Server to communicate with PACS Database Server
  • Allow PACS Web/App Server to communicate with EMR Web/App Server
  • Allow PACS Modalities (CT Scan/MRI) to communicate with the PACS Web/App Server
  • Allow HL7 Server to communicate with whatever systems it requires
    • This system is the ‘bridge’ between ancillary applications and the EMR system
  • Allow HRHIS Client Application to communicate with HRHIS Web/App Server
  • Allow HRHIS Web/App Server to communicate with HRHIS Database Server
  • Allow EMAIL messages to be sent as necessary. Certain applications are emailing their status updates.
  • 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.
  • Block any unknown communications except the actual application traffic and restrict access to the HRHIS application to only a HRHIS Desktop system running the HRHIS Client Application.
  • Allow bi-directional communication between the Infrastructure Services and all applications that require access to those services

Problem – The Healthcare organization still does not have a full understanding of how their applications communicate within and outside the organization. We have some details listed above, but nothing about the flows or ports and protocols to restrict traffic to only necessary communications.  With the expanded use case, the Healthcare organization thinks it will be difficult to operationalize this security model.

Technology used –   

Windows Clients:

  • Windows 10 – Clinician Desktop – Client-01a (192.168.0.36)
  • Windows 10 – HR Desktop – Client-02a (192.168.0.33)
  • Windows 10 – Jumpbox-01a – (192.168.0.99)

VMware Products:

  • vSphere
  • vCenter
  • NSX
  • vRealize Network Insight

Applications in question –

Open Source Healthcare Applications:

  • OpenMRS – Open Source EMR system
    • Apache/PHP Web Server
    • MySQL Database Server
  • DCM4CHEE – PACS (Picture and Archiving Communication System)
    • Apache/PHP Web Server
    • MySQL Database Server
  • IceHRM – 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 Server
    • Data Warehouse DB server

Infrastructure Applications:

  • LDAP
  • DNS
  • NTP

Enterprise Applications

  • hMail Email Server

After sitting down with each Application owner and asking questions about their application, we were able to at least identify the virtual machines associated with each application.  Using vRealize Network Insight (vRNI from here on), we’re going to map out the flows of all the applications that are in-scope here. Now that we have all the Applications defined, we’ll go ahead and build all the constructs within NSX for use with our rules.

If you’ve heard me speak before, you’ll know that I harp on creating naming schemes that are intuitive.  What do I mean by that?  Intuitive, in that just looking at the name will tell you the meaning of whatever you’re looking at.  In any setting, making changes to rules, services, ports, groups, etc. can have a profound impact on the infrastructure.  In the Healthcare setting, this could mean patient lives.  It’s important that we adopt a naming scheme, and adhere to it, even if the services already exist within NSX.  I’ve settled on these examples for this blog post:

vrni_ms_table1

INFRA Analysis and Rule Building:

 Similar to the last post with ARM, we’re going to start with Infrastructure services.  They are services that all of these systems depend upon and represent rules that will encompass the entire environment.  When we open up vRNI we’re going to look at everything within the vCenter for Site 1.  You can go more granular as you wish but with my environment being nested I have to look at bit higher.  I’m also only going to look at flows over the last 7 days.  In a production deployment, you’d want to examine each application and understand it.  If it’s a payroll processing application that does month-end processing you may want to look at the last 30 days.  When we change the micro-segments to ‘by Application’ we can see all of our custom applications we created and their flows both intra and inter the virtual environment.

Servers:

  • Active Directory – AD-DNS-01a
  • DNS – AD-DNS-01a
  • NTP – NTP-01a

These are the 3 servers in scope for the infrastructure.  We’ll need to create our structure for writing our rules.  We’re going to combine all of these servers into one Infrastructure Grouping as necessary.  To start building our rules we’ll need to ‘Plan Security’ using vRNI for the VM’s.

We’ll start by examining the flows of the AD-DNS-01a VM to other VMs.  When we log into vRNI the top option on the left side menu is ‘Plan Security’.  When we select that, we get a pop-up box that allows us to choose several Entities to plan security around as well as to examine the flows over a duration of time.  vRNI will allow you to examine flows from the last 30 days.  Again, understand the application and the necessary time that would be needed to realize the flows.

vrni_ms_pic1.png

When we select Analyze, we’ll be given a report of information about the VM in question.

vrni_ms_pic2

We’ll need to change a few settings to bring into view, the information we’re looking for.  In this case, we’re going to change the ‘Group By’ to ‘by VM’.  We’ll also need to change the ‘Also show groups for’ to ‘Other Virtual’.  This will show us all VM’s that are in-scope for this planning.

vrni_ms_pic3

From this view, we can see all of the ‘Other Virtual’ machines that the AD-DNS-01a server talks to.  If we want to dig into the flows we’ll need to look at to build our rules, we’ll focus on the AD-DNS-01a wedge.  Double-clicking on that wedge brings us to this screen.

vrni_ms_pic4

This screen shows up all of the flows captured over the last 7 days both to and from AD-DNS-01a as well as the port and protocol information.  We can use filters to break down the flows into smaller groups and dig into them specifically.  In this case, we want to take a look at what vRNI is recommending we do to create NSX Distributed Firewall (DFW) rules.  To see that, we’ll select the ‘Recommended Firewalls Rules’ tab.

vrni_ms_pic5

vRNI has shown us that it’s recommending we create 17 rules for our flows.  Let it be said, that Infrastructure Services will share the bulk of the flows in this lab.  Nearly every VM needs access to some or all of the services.  It will show very granular rules for us to build.  The thing to understand, is that these are ‘recommendations’, not absolutes.  Taking a look at the recommended rules, it looks like we might be able to combine a few and make things a bit simpler.  To do that, we’re going to take these rules and extract them from vRNI.

vrni_ms_pic6

In the upper right corner of vRNI, there’s an option to ‘Export as CSV’.  This will take all of those recommendations and put them in a format we can modify to our liking.

vrni_ms_pic7

vRNI has also given us some recommended Security Group structures as well.  You can choose to use this structure or not.  In my case, I’m going with the structure I created above.  I’ve gone through and replaced the groups with the custom ones.

 

We see a few Destinations in this output that don’t give us an explicit location, DC-Physical and Internet.  How do we handle those? What we need to do is go back to the wheel depiction, and hover over the DC-Physical portion.  For the Internet flows, we’re going to block any communications to the Internet.

vrni_ms_pic8

When we do this, we can see the flows just between AD-DNS-01a and DC Physical.  If we want to see the what the Destination of these flows are, we can click on the green line.  This will open up those flows.  When we get into this screen, we’re going to select the DC-Physical to AD-DNS-01a tab.

vrni_ms_pic9

From this output, we’re given the port and protocol, the number of flows, and the amount of traffic that’s been sent over the 7-day period.  If we drill into the ‘Count of Flow’ of ‘3’, this will give us the information we need.

vrni_ms_pic10

We now see that the 3 flows are coming from:

  • 168.0.33 – Clinician Desktop
  • 168.0.36 – HR Desktop
  • 168.0.99 – Management Jumpbox

Now that we have this information, we can create IP Set’s to match these sources, and add them to our rules.  Since we’re not going to specifically allow any Internet flows, we don’t have to worry about creating any rules specifically for this traffic.  The Block All rules will catch anything not explicitly allowed.

Let’s look at our vRNI output, albeit modified.

vrni_ms_pic11

So, you’ll notice a few things are different with the original output from vRNI.

  • Subbed in custom Security Groups with appropriate naming
  • Added a column for Combined Security Groups and Combined Service Groups. This will help us tremendously slim down the number of rules we need to write overall.  Remember, vRNI will give us very granular rules one by one.  We can consolidate those down to bigger groups and smaller numbers of rules.
  • Split all Services out if multiples were showing per line and created Services in NSX.
  • Color-coded things so that you can see where we can group Security Groups together to make one rule to cover each line instead of a single line for each.

What does this all mean?  Well this is what things will look like for our rules now:

vrni_ms_pic12

Let’s move to the rules for NTP.  We’re going to change the VM to NTP-01a and run the Analyze again.

vrni_ms_pic13

We’ll get a similar output that we got for the AD-DNS-01a VM.  When we drill into the NTP-01a wedge that will show us more details.

vrni_ms_pic14

We can see that there are 10 flows both incoming and outgoing, and vRNI is recommending 10 rules for us to build to accommodate.  Let’s drill into the ‘Recommended Firewall Rules’ tab.

vrni_ms_pic15

Now this set of ‘Recommended Firewall Rules’ is much simpler than the AD-DNS-01a ones.  One of these rules, the rule for DNS is already covered in the rules built above.  The rest are 9 rules from different Sources going to the same Destination.  We can reduce these rules down to one rule.

vrni_ms_pic16

vrni_ms_pic17

As you can see, we’ve significantly reduced the number of rules we’ll need to cover all the recommended rules just by combining Security Groups and nesting.  This will make our DFW policies much more efficient.  Let’s take this info and put it into our tables so we can visualize what all these groupings have inside.

vrni_ms_table2

Now that we have our structure in order, we start building our Security Groups, Security Tags, Services, and Service Groups in NSX.  I’m not going to go through the process of creating the objects within NSX.  The processes are very straightforward and my previous blogs discuss this very process.  Here are the results.

Security Tags:

vrni_ms_pic19

IP Sets:

vrni_ms_pic20

Security Groups:

vrni_ms_pic21

Services:

vrni_ms_pic22

Service Groups:

vrni_ms_pic23

Let’s build the rules that we had planned above now.  Again, I’ve already shown how to build rules in previous posts, so I’m not going to go through that here either. Here’s what we end up with in the DFW.

DFW Rules:

vrni_ms_pic24

All in all, we were able to take 27 recommendations and bring that all down to 4 Allow rules, and 2 Block rules that cover all of our Infrastructure Services.  Let’s move onto the next application and requirements, our EMR.

EMR Analysis and Rule Building:

 Requirements to meet:

  • Allow EMR Client Application to communicate with EMR Web/App Server
  • Allow EMR Web/App Server to communicate with EMR Database Server
  • Allow PACS Web/App Server to communicate with EMR Web/App 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.

In the previous post we went through and put in our rules for the EMR application.  I have since removed those rules so we can leverage vRNI to show us what to put in.  Since we’ve added several new systems that may communicate with the EMR, we’ll be making some changes anyway.

Similar to what I did in the Infrastructure Services section, I’m going to select the EMR-WEB-01a VM and then show the micro-segments ‘by VM’.

vrni_ms_pic25

We’re going to dig into the VM and look at the recommended rules just like we did for the Infrastructure VMs.

vrni_ms_pic26

What we will notice is that there are a few different rules for different connections. We see new connections from the PACS-WEB-01a VM to our EMR-WEB-01a server.  This would imply that these two systems shared information over TCP 9696 and TCP 2575.  We also see TCP 8080 and TCP 22 connections from DC-Physical which means that external systems are accessing the EMR-WEB-01a VM.  Lastly, we see that the EMR-WEB-01a system talks to its EMR-DB-01a system across TCP 3306 like we’d discovered before.  Since these devices are from outside the NSX environment, we’ll need to look at the Flows section to see what these IP addresses are.

These seem to correlate with at least one known IP address.  The 192.168.0.99 address was my Jumpbox system from the last blog post, but this 192.168.0.36 and 192.168.0.33 systems are unfamiliar.  Talking with the Application Team we learned:

  • The 192.168.0.18 system is an outside system that is accessing the EMR-WEB-01a via SSH on TCP 22, and also accessing the EMR itself, over TCP 8080.
  • The 192.168.0.36 system is a Clinician Desktop
  • The 192.168.0.99 Jumpbox should have access for management purposes to the EMR.
  • The TCP 9696 is an integration plugin that now exists between the PACS and EMR system to route data to each. This port is the DICOM MPPS port.
  • The TCP 2575 is also part of the integration plugin that now exists between the PACS and EMR systems. This port is used by the EMR system to send Radiology orders to the PACS system.

One of our requirements was to only allow Clinician Desktops access to the EMR, and block any other connections that are not identified. If we don’t explicitly allow that communication, our catch-all Blocks will stop this communication.

Extracting these rules from the interface gives us this format in CSV.

vrni_ms_pic27

We’re going to swap in our groupings and remove any already covered rules like NTP and DNS.  We need to figure these DC-Physical flows first.  We’re going to go back to the Flows tab and filter down the results to only show the 8080 and 22 flows respective of the recommended rule.

vrni_ms_pic28

From this page, we’re seeing:

  • Two unknown IP address flows from 192.168.0.18 on 8080 and 22.
  • One unknown IP address flow from 192.168.0.24 on 8080.
  • One known IP address flow from 192.168.0.99 (Jumpbox) on 8080.

Looking at these, only one of these is a proper flow that we should account for.  The others have been identified as not necessary.  Now we can finish up our rules.

vrni_ms_pic29

Legend

Yellow with dots = Already covered by another rule

Blues – Rules we’ll write

Let’s move onto EMR-DB-01a and get our recommended rules.  Same process as before.  We’re going to analyze the VM named EMR-DB-01a.

vrni_ms_pic30

vrni_ms_pic31

vrni_ms_pic32

 

This brings us to those output.

vrni_ms_pic33

vrni_ms_pic34

This leaves us with only a couple of rules for our EMR.  Now that we know the communications that are necessary and are known good, we’ll go ahead and write our rules. Let’s lay out what those rules should look like:

vrni_ms_table3

Most of our groupings have already been created, so we’ll finish out whatever is left.

Security Tags:

vrni_ms_pic35

Security Groups:

vrni_ms_pic36

Services:

vrni_ms_pic37

With all this info, we build our DFW rules.

DFW Rules:

vrni_ms_pic38

 This completes the EMR section of the DFW.  We can move to the next application and it’s requirements, the PACS system.

PACS Analysis and Rule Building:

PACS applications have physical devices, modalities, that connect to them to send the images and information.  In this case, we have an MRI and CT Scanner emulator that’s playing that role in this scenario.  While they are VM’s themselves, they are outside the NSX environment so we’ll have to use IP Set’s to accommodate, similar to Clinician physical desktops.  The requirements are similar to all the other applications.

Requirements to meet:

  • Allow PACS Client Application to communicate with PACS Web/App Server
  • Allow PACS Web/App Server to communicate with PACS Database Server
  • Allow PACS Modalities (CT Scan/MRI) to communicate with the PACS Web/App Server

We’ll start by running the analysis against PACS-WEB-01a and then on PACS-DB-01a.

vrni_ms_pic39

vrni_ms_pic40

vrni_ms_pic41

Let’s clarify our DC-Physical flows:

vrni_ms_pic42

Talking with the Application owners, the Modalities are shown to be the systems connecting via on port TCP 6060.  The Application owners have shown that this is the DICOM Echo port for the modalities.  The other system is our Jumpbox, as usual.

vrni_ms_pic43

vrni_ms_pic44

We’re all squared away on the PACS-WEB-01a server.  Let’s work on the PACS-DB-01a.

vrni_ms_pic45

vrni_ms_pic46

vrni_ms_pic47

We’re going to start noticing a trend here.  The recommended rules are going to start being covered by previous recommendations as we continue down the list of applications.  This is good because this is simplifying our rule sets overall.

vrni_ms_pic48

vrni_ms_pic49

Looks like every rule that’s recommended here will be covered in a previous rule.  Let’s build the groupings and our rules.

vrni_ms_table4

Security Tags:

vrni_ms_pic50

IP Sets:

vrni_ms_pic51

Security Groups:

vrni_ms_pic52

Services:

vrni_ms_pic53

DFW Rules:

vrni_ms_pic54

This completes our rule build out for the PACS system.  Let’s move to the HL7 integration engine, Mirth Connect.

HL7 Analysis and Rule Building:

 Requirements to meet:

  • Allow HL7 Server to communicate with whatever systems it requires
    • This system is the ‘bridge’ between ancillary applications and the EMR system

Talking with the Application Team for the HL7 system, we learned that it’s all running on one server, HL7-01a.  With that being the case, there will be no intra-group communications necessary for this application to function.  However, the HL7 system talks with many other systems in the infrastructure.  It’s a broker of communications between disparate systems.  In our case, we’re going to take a look at what other systems this one brokers communications between.

vrni_ms_pic55

vrni_ms_pic56

vrni_ms_pic57

Let’s dig into the DC-Physical side so we can understand the IP-based flows to build out our full rule sets.

vrni_ms_pic58

vrni_ms_pic59

We see a port 22 connection talking with the Application owners, we’ve determined that this connection is for the HL7 system to SFTP a file pulled from a MYSQL query.  Let’s clean these up a bit and classify them.

vrni_ms_pic60

The green identified flow, we’re going to put that into the EMAIL Group as that’s accessing the EMAIL server, specifically.  Now that we’re all cleaned up, we can build out our rules and groupings.

vrni_ms_table5

Security Tags:

vrni_ms_pic61

Security Group:

vrni_ms_pic62

Services:

vrni_ms_pic63

Service Groups:

vrni_ms_pic64

DFW Rules:

vrni_ms_pic65

EMAIL Analysis and Rule Building:

 Requirements to meet:

  • Allow EMAIL messages to be sent as necessary. Certain applications are emailing their status updates.

As with the HL7 system, the EMAIL server is running on one server so there’s no need for any intra-group communications.  Let’s analyze the flows.

vrni_ms_pic66

vrni_ms_pic67

vrni_ms_pic68

As usual, we need to dig into the DC-Physical flows to get the IP addresses of these systems.

vrni_ms_pic69

It appears that we have the two Desktop machines connecting to the EMAIL-01a server over IMAP and we have a NETBIOS-DGM port that’s hitting the Broadcast network of the VLAN it’s on.  Let’s start making our groupings.

vrni_ms_pic70

Let’s refine this.

vrni_ms_pic71

vrni_ms_table6.png

Security Tags:

vrni_ms_pic72

Security Groups:

vrni_ms_pic73

Services:

vrni_ms_pic74

DFW Rules:

vrni_ms_pic75

Let’s finish up with our HR System now.

HRHIS Analysis and Rule Building:

 Requirements to meet:

  • Allow HRHIS Client Application to communicate with HRHIS Web/App Server
  • Allow HRHIS Web/App Server to communicate with HRHIS Database Server
  • Block any unknown communications except the actual application traffic and restrict access to the HRHIS application to only a HRHIS Desktop system running the HRHIS Client Application.

Again, we’re going to follow the same process to finish our build out.

vrni_ms_pic76

vrni_ms_pic77

vrni_ms_pic78

vrni_ms_pic79

Looks like our Clinician’s desktop has been attempting access to the HR system.  There doesn’t appear to be much traffic, but that’s definitely a system we don’t want having access to the HR web site.  We’ll be blocking this traffic off from that system.

vrni_ms_pic80

vrni_ms_pic81

These are pretty simple rules.  Half of them are covered already in Infrastructure Services.  A quick analysis run against the DB:

vrni_ms_pic82

A quick glance will show that there are no recommendations that aren’t already covered by another rule we’ve accounted for.  We’re all set to finalize our last application.

vrni_ms_table7.png

Let’s build our groupings and rule sets.

Security Tags

vrni_ms_pic83

Security Groups:

vrni_ms_pic84

Services:

vrni_ms_pic85

DFW Rules:

vrni_ms_pic86

With the rules all in place, we will go through and check our communications with our applications and verify they’re all still working correctly per the requirements given by the customer.

Let’s bring back the requirements we needed to fulfill and demonstrate how we’re accomplishing these as specified.

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

vrni_ms_pic87

Verified – Able to log into the EMR and pull up a patient record.

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

vrni_ms_pic88

Verified – Able to log into the PACS system and run a DICOM Echo from the PACS system to the EMR.

  • Allow PACS Modalities (CT Scan/MRI) to communicate with the PACS Web/App Server

vrni_ms_pic89

vrni_ms_pic90

Verified – The PACS modality physical emulators are able to DICOM Echo to the PACS system successfully.

  • Allow HL7 Server to communicate with whatever systems it requires
    • This system is the ‘bridge’ between ancillary applications and the EMR system

vrni_ms_pic91

vrni_ms_pic92

Verified – We’re seeing successful connections from the HL7-01a system to EMR-DB-01a, runs a MySQL query, outputs it to a file on the HL7-01a server, and then SFTP’s it to DW-DB-01a for import.  Then, it emails the ‘dwftpservice’ Email account and provides the status.

  • Allow HRHIS Client Application to communicate with HRHIS Web/App Server
  • Allow HRHIS Web/App Server to communicate with HRHIS Database Server

vrni_ms_pic93

Verified – We’re able to access the IceHRM, HRHIS system, and login.  We’re also able to pull up Employee data, all from the HR Desktop system.

  • Allow EMAIL messages to be sent as necessary. Certain applications are emailing their status updates.

vrni_ms_pic92

Verified – This is the same confirmation email that was sent from the HL7-01a system.

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

vrni_ms_pic94

  • Block any unknown communications except the actual application traffic and restrict access to the HRHIS application to only a HRHIS Desktop system running the HRHIS Client Application.

vrni_ms_pic95

Verified – We’ve attempted access to the HRHIS system from the Clinician Desktop.  You can see that we’re not allowed access from this machine.

  • Allow bi-directional communication between the Infrastructure Services and all applications that require access to those services

vrni_ms_pic96

vrni_ms_pic97

That completes our verifications.  As you can see we were able to use vRNI to do Micro-segmentation at scale and get to a Zero-Trust model faster than traditional methods.

Advertisements

2 thoughts on “The VMware NSX Platform – Healthcare Series – Part 4.3: Micro-segmentation Practical – vRealize Network Insight

  1. Hi Geoff,

    You’re creating custom services for all application. If we have 50 different Applications and each needs http access, So you need to create 50 custom service for http only. Using Predefined http service may be better for known services ? Whats your opinion ?

    • I like creating my own, simply because I know what I’m changing if I need to modify something. I like knowing that if I make a modification to SRV-HTTP-WEB, that I know exactly what I’m impacting. You could narrow this down a bit on only doing very high priority types of applications, but that could get confusing.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s