VPN Haus

Nearly 64 percent of healthcare professionals are using Smartphones and more than 100,000 physicians are actively using medical applications as reference guides and platforms to input patient data.  Ddoctors can enter lab results and prescribe medication via an ePrescibing application.  As more doctors and healthcare professionals use handheld devices for functions like this, it is important for hospital IT departments to secure and manage these devices.  According to MedPage Today, smartphones have gained huge popularity among these healthcare professionals because of the functionality and ease of use.  As smartphones prove to be the preferred device, hospitals need to rethink their network’s current infrastructure and support a variety of devices, rather than just a hospital authorized device.

A few weeks back, Google instituted an emergency update to its corporate VPN, which led to many questions whether the network was compromised—Google states “no”, however, timing suggests otherwise.  All of the discussions, questions and disorder got us thinking… if Google had to issue an ‘emergency VPN update’, perhaps the rest of corporate America should be rethinking their remote access to prevent any similar occurrences from happening.

In the case of Google, simple passwords could have been used to access the network, however, if two factor authentication and network access control (NAC)—or as we like to call a ‘pat-down’—were in place this simulation would have been much harder to pull off—even if phishing grabbed some passwords.  Forrester analyst, Chenxi Wang made some interesting observations on her blog—her initial analysis was that the attackers gained access to Google’s server via its corporate VPN, from a Microsoft browser vulnerability that was exploited.  Some employees’ desktops were compromised, and the attacker used these compromised desktops via Google’s VPN to get to some of the servers.  Google ‘clarified’ this later, stating that the method of access, at some point, may have involved VPN, but does not agree with the characterization that “the compromised client used their corporate VPN to gain access to the servers”.

Touching on the fact that the victim’s machine was running IE 6, an outdated browser, Chenxi suggests that the machine may not have been a corporate managed machine.  If this is indeed the case, Google’s should be rethinking their remote access policies, and enable employees to use personal devices that are secured and managed.  This idea is similar to former Forrester analyst, Natalie Lambert’s concept of BYOPC (Bring your own PC)— employees are going to use whatever device they can to access the network, and probably break many security policies while doing it.  Instead of restricting machines that are able to access the network and taking a chance and running to in a situation that Google had on their hands, companies can support a variety of devices, whether it be Windows 7, Windows Vista (32/64 Bit), Linux, Mac, Symbian, Windows Mobile etc. AND secure them.  It seems that Google’s technology was restricting employees’ practices because the system could not handle it, which by and large caused an emergency update to the entire corporate VPN infrastructure.

This emergency update caused a connectivity disturbance for more than 24 hours, which affected work flow and productivity.  A better VPN management system might have played a significant role for Google.

Follow this discussion on Twitter: @VPNHaus

Confused about split tunneling—What is it?  Is it secure?  Is it recommended?  We spoke with Rene Poot, senior solutions specialist at NCP engineering for his opinions on this.

Lets first define split tunneling—

Let’s take a typical Windows machine, and place it in a home office environment.  In this home office environment, the user also accesses resources on his/her home network, such as a network storage device or another machine in his local network.  There will be a router present that performs firewall functions and network address translation, and provides Internet connectivity for all the machines within this home network.

When the user wants to access something on his local network, by default the Windows IP stack will look to find the shortest route to this resource.  As it is something local, it will send it to the local network interface and send the request to its local LAN.  If it is a destination that is unknown, it is sent to the so-called default gateway, which would typically be this home network’s router, which then hides the internal IP address of this machine, and routes the request out to the Internet, as though it’s coming from the router/firewall.  The responses then come back to this router who in turn then translates it back and sends it back to this Windows machine.

Now let’s introduce VPN into the picture—

Typically the user wants to connect to his corporate office in a secure manner, and so has VPN.  With ‘Split Tunneling‘ enabled, the user can sit at his machine at home, and all traffic destined for the secured corporate network is directed via the tunnel.  All other traffic is either split off to the local default gateway, or to the local resources directly.  Basically it’s just a ‘junction’ or an ‘access list’ where what needs to be directed.  This can either, depending on the VPN gateway used, be pushed to the client, or the user can define this manually on the client.

Requests for let’s say a public Internet website expedia.com is then examined, and compared to the ’split tunneling’ list.  This is a list of all the hosts and/or subnets that are to be diverted through the tunnel.  Destinations not on this list will be directed to the default gateway.  In this example, it’s unlikely that expedia.com is on this list, and so is sent to the default gateway (the router/firewall at home and out on to the Internet).

If however, the user wants to access a resource on the corporate network, they will do so, and the destination will match a destination that’s listed in the Split Tunneling ‘list’, and so it’s directed through the tunnel, and will emerge on the VPN gateway and then on to the corporate network.

Traffic for the local shared resource will simply go directly to that device on the local network and everything’s fine.

Now, it could be the case that the administrator does NOT want this to be so ‘open’.

At the corporate side, they’ve installed a firewall and locked and bolted everything down, out of fear or any accidental data leakage (i.e. via IM or access to popular websites, or whatever).  Users on the corporate network are not permitted to be looking at holiday booking sites such as expedia.com and so this is blocked by the firewall.  One is permitted only to use the company resources for corporate use and in corporate situations.  Browsing other websites are not permitted, because the user cannot be trusted he/she won’t access some nefarious website or whatever.

Now if this user is permitted to take this laptop home, and no other steps are taken, all bets are off.  The firewall rules and such that the administrator so carefully has set up to protect his corporate network no longer apply, because the machine is now at the mercy of the firewall settings of the local router/firewall at home, which will not reflect the same precautions the administrator has put into the corporate firewall.  One could then access the Internet and do whatever one pleases.

The administrator can prevent this by ensuring the a VPN is required, and ‘lock the user into the tunnel’, which is ’split tunneling’ but then with a wildcard for all, which effectively makes ALL traffic that emerges from this machine be directed through the tunnel, effectively making the VPN gateway at the corporate side the default gateway of this machine at home.  The corporate firewall then is still protecting this remote resource at home.

One can still access local resources (unless this too is blocked — an additional option within the client software) but any requests to the aforementioned expedia.com will be directed through the VPN tunnel, and then the VPN gateway will forward it to its default gateway, and that then is the corporate firewall, which then drops this request.  This allows the administrator to leverage the control he has over the machine’s access at all time; basically extending the corporate policies to the machine regardless of where it is.

I mentioned that local resources (i.e. shared resources or network printers) are still accessible; this is the case by default, but this too can be locked out; so even that must pass through the VPN tunnel first.

“Locking the user into the tunnel” or “full network enclosure mode” will put more strain on the bandwidth at the corporate side, as EVERYTHING from ALL the remote users that are locked into the tunnel must pass through the central VPN gateway and then the central corporate firewall; so that could have a performance impact.

Follow this conversation @VPNHaus