Home > Blogs > VMware Security & Compliance Blog > Tag Archives: HIPAA

Tag Archives: HIPAA

vCenter Configuration Manager 5.5 is now Generally Available

As you are probably aware, back in October we unveiled the VMware vCenter Operations Management Suite designed to deliver integrated performance, capacity and configuration management for virtualized and cloud computing environments.  What is less well known is that VMware vCenter Configuration Manager is the anchor for the “configuration” management capabilities within the suite.  Having been part of Configuresoft for several years before it was first purchased by EMC and then sold to VMware, I feel a bit like a dad watching his baby grow up.  The technology that was Configuresoft is at the heart of vCenter Configuration Manager.

 With today marking the general availability of vCenter Configuration Manager 5.5, I am both excited and proud to see this one go out the door.  vCenter Configuration Manager has always been a great solution for ensuring that Operating System software, whether Windows, Linux or Unix is properly configured to meet a broad range of security best practices, vendor hardening guidelines and regulatory mandates (think HIPAA, PCI, SOX etc).  But with this release, vCenter Configuration Manager becomes an indispensable part of the VMware family – addressing core requirements of the Virtual Infrastructure teams looking to leverage the VMware Cloud Infrastructure Suite as the foundation for business critical workloads moving to the cloud.

The primary theme for vCenter Configuration Manager 5.5 release is “Cloud Ready”.  New capabilities within this release significantly increase the ability of the Virtual Infrastructure team to ensure that their VMware Infrastructure is properly configured to meet the rigorous demands associated with virtualizing business critical workloads; including addressing requirements associated with VMware’s own hardening guidelines.  

This new release dramatically increases the ability to track configuration changes and to assess configuration compliance across the VMware Infrastructure including ESX, ESXi, vCenter, vCloud Director and vShield products.  There are also a substantially greater number of new configuration actions that can be executed against vCenter and ESX, ESXi configurations.  These configuration actions can be executed against a single object or in bulk against multiple objects spanning multiple vCenters.  They can be executed as part of an organization’s general configuration management processes or as part of a configuration compliance program. 

The enhancements to vCenter Configuration Manager 5.5 put tremendous visibility and control at the fingertips of the Virtual Infrastructure team responsible for VMware Infrastructure.  To help illustrate this I have included an example of how vCenter Configuration Manager can help manage configuration changes across the VMware Infrastructure (Figure 1). This particular high level dashboard is focused on the Virtual Infrastructure team and shows all changes that have occurred across the VMware Infrastructure for a specific time period.  

Figure1

 

You can quickly drill down into any of these dashboards to investigate anything of interest or concern.  In this example I’ve drilled down into a specific vCenter (Figure 2) to understand a change associated with the “client.timeout.normal” setting.  I can see that this setting has been changed from 60 seconds to 10 which I know is out of compliance with operational best practices for vCenter (which calls for this setting to be equal or greater than 60 seconds).

Fig 2

In addition to the ability to see and understand prior changes, vCenter Configuration Manager provides the ability to change configuration settings across the VMware infrastructure (Figure 3).  I can do this for a single object or for multiple objects.  Bulk configuration changes can be directed across objects that span vCenters. 

Fig 3

Finally (Figure 4) I can proactively manage configurations through compliance where I create rules and templates (collections of rules) for any configurations I want to ensure are uniformly applied across my entire virtual data center or subsets of “like objects” in my data center.  vCenter Configuration Manager comes with a rich set of templates out-of-the box that can be used as is or as the starting point for the development of your own internal best practices.  

Fig 4

The new capabilities of vCenter Configuration Manager 5.5 significantly increase the value delivered to customers purchasing the vCenter Operations Management Suite Enterprise Edition where today vCenter Configuration Manager is included to address critically important use cases associated with “hardening” the VMware Cloud Infrastructure Suite. 

Other significant enhancements to vCenter Configuration Manager in this release include:

  • Ability to create machine groups within vCenter Configuration Manager based on organizational constructs (clusters, virtual datacenter, application trust zones) within vCenter, vCloud Director and vShield.
  • Support for configuration and compliance management for virtualization specific constructs such as templates and offline VMs (via VMware vCenter Orchestrator workflows delivered separate from the release)
  • The ability to snapshot a VM before making a configuration change
  • Support for the “Security Content Automation Protocol” (version 1.0) –  important to federal agencies
  • A new REST based API that will allow vCenter Configuration Manager to more fully participate in VMware and 3rd party ecosystem solutions

Early feedback from customers involved in beta testing has been extremely positive.  The increased ability of vCenter Configuration Manager to harden the VMware Infrastructure combined with the existing strength of the product to harden the Operating System (Windows, Linux, Unix) make vCenter Configuration Manager fundamental to clouds built on VMware technology.  More information can be found by visiting the vCenter Configuration Manager page on VMware.com.   Also, be sure to download the free vSphere Compliance Checker which will help you better understand the value that vCenter Configuration Manager delivers to organizations looking to move business critical workloads to the cloud.

Peace Out!

George Gerchow, Director, VMware Center for Policy and Compliance

 

Is Healthcare Ready for the Cloud?

Healthcare peeps, HIPAA\ HITECH has teeth and the fines handed out this year are HUGE. 

The best example was Cignet Health Center, a group of clinics based in Prince Georges County, Md., that operates a health plan, was been fined $4.3 million for failing to turn over medical records to patients who requested them and failing to cooperate with the HHS probe. (Feb 2k11) 

http://www.ama-assn.org/amednews/2011/03/07/bisb0307.htm 

For my friends in EMEA, you're having issues around PHI as well. NHS Lost unencrypted devices with patient records. 

http://www.itpro.co.uk/634225/nhs-laptop-with-8-6-million-medical-records-missing

Finally, for those of you who are obsessed with Celebrities, don’t let that spill over into your job! Personally, I could care less about what Miley Cyrus is doing next, but some people just can’t help themselves.

 "The University of California at Los Angeles Health Services has agreed to pay a $865,000 fine and pledged to tweak their infrastructure after potentially violating the HIPAA regulation when several employees apparently accessed the health records of various celebrity patients at the hospital without valid justification. 

http://thunderfeeds.com/reader/news/ucla-hospital-hit-with-hipaa-fine-on-celeb-records 

So, if Healthcare IT shops can’t cut it when it comes to protecting PHI, or meaningful use around EHR, should the business turn to the Cloud? 

From what I can see, part of the problem is some OLD legacy Healthcare apps can not run on x86 and do not support Virtualization. 

So, maybe a few things need to happen:  

  • Assess the risk of apps that can no longer be maintained and will not meet compliance standards, versus the ease of migrating at least the front end of the legacy systems to a virtual platform
  • There are a ton of healthcare apps that are cloud ready and work on mobile devices

o   http://www.readwriteweb.com/cloud/2010/11/3-mobile-healthcare-apps-that.php

o   Approximately 60% of all doctors today use IPADS or similar devices (IDC)

  • VMware has the infrastructure to support those apps and allow IT shops to build private cloud services that can be moved to public providers during periods of high demand

o   And… ported back of course J

  • For some small Healthcare Organizations, they are moving their services and patient data to Cloud Providers like NaviSite

o   http://www.informationweek.com/news/healthcare/EMR/231601342

o   BTW: A lot of these orgs are adopting HITRUST as a certification process to meet HIPAA\ HITECH Compliance 

The main concern is Trust, will Large Healthcare Organizations “Trust” cloud providers with Medical Records? 

My guess is yes, they will in time. At VMware we are working on Trusted Cloud Solutions with other vendors to build an eco system that will let Consumers move their workloads with confidence to the cloud. The key will be if the Providers will allow the Consumers to validate that “Trust”.  The Consumer holds the power, as my colleague and active QSA Davi Ottenheimer says, “If a service provider refuses to give you the log services or compliance support you need, it may be time to find another provider.”

When it comes to Healthcare, yes, the complexity of how regulated the vertical is when it comes to compliance could make it difficult for a Provider to offer those services. However, if we are really going to make the Journey to the cloud, Providers need to bake in cost efficient Security & Compliance solutions for consumers as part of their offering and open the kimono to let the Consumer Validate what is happening with their assets. 

We would love to get your feedback on the comments above, hit us up here or: 

As usual, please forgive me for any spelling and grammar errors. Spanish is my first language and like the rest of us, I am still learning.  

Peace out…

vShield App and View Desktops: Desktop Security Zones and the Desktop DMZ

Hi…Rob Randell here again.  In an earlier posting on the partner announcements at the RSA and HIMSS Conferences, I promised that I would go into detail on how we can leverage VMware View to provide what I like to call Desktop Security Zones and the Desktop DMZ.  In this blog I am going to illustrate this in a use case on a hospital network. 

Specifically, in this use case we have two primary sets of users: Doctors and Hospital Administrators.  The doctors need to have access to the medical records of their patients.  These records reside in a medical records app on the hospital’s internal network that they access via a browser. 

The hospital administrators on the other hand need access to the billing and insurance information of these patients.  This data resides on another set of servers also served up via a web application on the local hospital network.

The doctors have no reason to access the billing or insurance info for their patients and the hospital admins don’t need access to the medical information.  Both the doctors and the hospital admins need access to the web though so they can do research and check on personal matters. 

So based on this case study we are going to have three sets of virtual desktops:

  1. Doctor Desktops
  2. Hospital Administrator Desktops
  3. Web Browsing Desktops

We have two different users that we are going to demonstrate this use case for.  The first is Doc Jones and the second is Hoss Admin.  You can probably guess who is the doctor and who is the hospital admin. 

The first step we need to take in our configuration is to put Doc Jones and Hoss Admin into Active Directory groups that match them to their roles.  In our case, the AD groups are simply “Doctors” and “Hospital Administrators.  These can be seen in the screenshot below.

1

The next step happens in vCenter where we need to create some resource pools for the housing of our different desktop pools.  These will be necessary for our vShield App rule creation later.  We need to create three resource pools for our different virtual desktops: “Browsing Desktops”, “DoctorDesktops”, and “HospitalAdminDesktops”.  The screenshot below shows the three resource pools we created for our virtual desktops. 

  2
Now that we have created our groups in AD and resource pools in vCenter, we need to create the Desktop Pools within the View Manager.  We will create three desktop pools to matchup with the roles we talked about earlier, BrowserDesktops, DocDesktops, and HospitalAdminDesktops.  You can imagine having additional pools here for other roles within a hospital like nurses, pharmacists, etc… For our use case we will focus on the Doctors, the Hospital Admins and the browsing desktops.  These can be seen in the screenshot below.

3

Next we configured the entitlements to give the user access to their desktop specific to their roles and the browsing desktop.   

4

5

6

OK, now that we have our desktop pools provisioned.   We need to create the rules necessary for the desktops to work properly.  This includes ensuring that Windows works properly and can communicate with everything it needs like DNS, AD, NTP, etc…  Lots of Windows rules to create as can be seen in the screenshot below.   Click on the screenshot to see the full image.

Rules1

Communication with the View Server needs to be opened up to allow for PCoIP, USB redirection (if needed), etc…  We have up to 4 rules per desktop pool.  TCP and UDP for PCoIP to allow the View Client to connect to the View Desktop to allow the PCoIP display protocol to work, JMS to allow the View Agent to communicate with the View Manager, and USB Redirection that is tunneled through the View Manager.  Of course in a most cases I would argue that it is a good idea to block this traffic unless it is absolutely necessary.  In this case, it would be reasonable, and likely that we would disable and block the USB Redirection as we probably wouldn’t want the Doctors and Hospital Admins to be able to copy data off of their virtual desktops to a USB drive.   So in our case we will only have three rules per desktop pool (PCoIP (both tcp/udp) and JMS.  Click on the screenshot to see the full image.

Rules2

Note that the creation of these rules can be scripted so as new desktop pools are created, we can then run a quick script to add the necessary rules. 

Next we need to create the rules to allow the doctors access to the medical app and the hospital admins access to the billing and insurance app.  In this case, albeit very simple, it shows that the Doctors are entitled to the “Doctor Desktops”, which are restricted by vShield App to only have access to the Medical Servers.  The Hospital Admins are entitled to the “Hospital Admin Desktops”, which are restricted by vShield App to only have access to the Billing Servers. 

We used vApps to group the Medical Servers and Billing Servers.  Doing this made creating our rules very easy as we just choose the “Medical Servers” and “Billing Servers” vApps for our destinations and the “HospitalAdminDesktops” and “DoctorDesktops” Resource Pools as opposed to doing some sort of IP subnet based rules.   Both the medical app servers and the hospital app servers provide access via SSL.  

Rules3

Both need Internet access from the browsing desktops, as the other desktops are not allowed Internet access.  Notice that we deny the “Browsing Desktops” access to all Internal IP Addresses.  If a rule does not match these two rules, it means that the IP address is an external IP address where we allow these desktops HTTP and HTTPS access.  If we wanted to we could allow additional protocols, but for the purposes of our hospital, they should only need these basic protocols.  Also, if we wanted to send a syslog message anytime one of the browsing desktops attempted to access an internal resource and was denied we could check the “Log” checkbox in those rules.  In this case we didn’t choose to do that.

Rules4

The doctors and hospital administrators now have access to their desktop and any of the resources that their particular desktop is capable of connecting to. This network access is controlled through vShield App where the View Connection Server controls the access to the desktop.  In this case, you can see the vShield App firewall rule that shows the DoctorDesktops have access to the Medical Servers.  Notice that we created these rules based on the resource pool where View Composer deploys the doctor’s desktops (DoctorDesktops) as the source and the vApp that contains the medical application (Medical Servers) as the destination.  Pretty simple, huh?  

Interestingly, it was pointed out to me by Rob Babb that we could make this even simpler for the browsing desktops by setting up a proxy server.  This could be the single point of access to the Internet and would make setting up the rules even simpler as we wouldn’t need the “Deny” rules to the internal networks for the BrowsingDesktops.  All we would need is an allow rule for these desktops to the proxy server, as the deny to the rest of the network would be handled by the default deny rules we have setup at the bottom of our rule set.

Now it is time for the users to login.  We will show the instance of a doctor logging in.  The doctor will run the View Client on their iPad, Thin/Zero Client, laptop, or any other device.  In this case we will show the login with the standard View Client from a Windows machine.

11

Doc Jones will then authenticate to the connection server.  In this case he is using a standard AD Credentials, but we could use a Smartcard or SecureID as well.

12

Once authenticated the doctor will have a choice of whether they want to login to the “Doctor Desktops” or the “Web Browsing Desktop”.  Once they decide on the desktop their login credentials they provided to the View Client will be automatically passed through using the single sign-on capabilities of VMware View.

13

In this case we are logging them into their main desktop so they can gain access to the medical server, but are not allowed access to anything else.   This can be seen in the screenshots below.

14

15

Here we can see both the allowed and blocked connections for the docvm2, which is the desktop that Doc Jones was using.

16

So to summarize, in a minimal amount of work, we were able to setup two desktop pools that are entitled to specific sets of users, which protected with vShield App are restricted to access only a specific set of resources.  Make note that these rules are good for one desktop or 1000 desktops as they apply to the resource pools as opposed to creating the rules for individual desktops.  So we don’t have to constantly add rules as new desktops are added or old desktops are removed.

The cool thing about this is that we can automate this even more to make it even easier which I didn't address in this posting.  I also didn’t talk about how we could use vShield Endpoint and vShield Edge in this use case.  Not to mention adding in partner solutions for IDS/IPS protections as well.  Stay tuned for more on all of this.