Wednesday, November 28, 2012

Rethinking Remote Access


As I travel the country, I find that CIOs everywhere are struggling with BYOD in particular but remote access more generally.   Who is responsible if

A personal unencrypted laptop with email containing personally identified/protected healthcare information is stolen?   The CIO of the institution providing email takes accountability and reports the theft to appropriate  government regulators.

An employee prints a web page on their home computer and patient data is discovered blowing around in a nearby dump?  The CIO of the institution hosting the patient data is responsible.

An employee with a malware infected but encrypted smartphone accesses a web application and a keystroke logger sends the username/password to hackers in Asia who use it to send spam.   The CIO is responsible for all the consequences.

Policy against using personal laptops, home desktops, and smartphones for processing of healthcare data is not sufficient.  CIOs must use technology controls to mitigate risk of data loss.

For example, BIDMC has already used AciveSync to enforce encryption of every smartphone accessing our network and to deny access to those smartphones that do not support encryption.

Personal laptops and home desktops are much harder to control.  Purchasing institutionally supported laptop/desktop devices for every user needing remote access would be cost prohibitive.  

Rather than try to manage the home clients that have multiple varieties of hardware, operating systems, and third party apps, it's more practical to impose restrictions on who can access resources remotely, where they can access resources from, and what they can do (block downloads and printing).   Solutions I've heard from industry experts include

1.  ActiveSync as the only means of smartphone email access with a configuration to require encryption of client devices.  Use Outlook Web Access as the only laptop email access method and close all other types of remote email access - WebDav, Web Exchange Services, and RPC over HTTPS, IMAP, POP
2.  SSLVPN for all remote access to all applications (including web portals) with configuration settings to prevent remote downloads and printing
3.  Citrix or Virtual Desktop Infrastructure, which typically does not persist data on local clients.

I've described security as a continuous improvement process - the journey is never done. I'm curious what you are doing to restrict remote access in a world of malware, BYOD, and enhanced regulatory enforcement.   Comments are welcome!

11 comments:

Bernz said...

Our solution was to provide a VM on secure USB Flashdrive. Open basic OS on that and then SSLVPN into the network. Prevent any kind of transfer off the VM. Only allow Internet access through VPN. Lots of scripts on VM boot to signal "here I am", too, and download patches.

If you can't control the client, you can't really impose things like "cannot print" as the data, even if just in memory, can be manipulated by that client (including printing). Having a temporary VM instance works in environments where security is king and BYOD is in place. It's not the most convenient thing, though, and requires some training.

donjduncan said...

One approach is to take a user/content managed approach instead of focussing on the device. Typically, most of the tools that exist lock down the hardware but have challenges with content management of the applications, documents, user settings etc. They also don't work well when disconnected from the network and I don't know of anyone that has a consumer data package with 5 9's of up time from their telco provider.

Also, with BYOD it is not only protecting corporate information but personal (my) information as everything is on the same device. Taking a top down instead of a bottom up management is the approach we take when working with customers.

Anonymous said...

Institutions must ensure that whoever they are sending data to know the rules with regards to security, and the consequences of breaking those rules. It would be hard to technologically prevent a client from taking a picture of their computer screen containing patient data and printing the image, but the client would be discouraged from doing so if they knew their access to the data would be blocked if a breach occurred because they did not follow procedures.

Anonymous said...

I absolutely understand the need for security, but I think CIOs also need to empathize with end-users. I think restrictive policies tend to frustrate users and reduce productivity with the end result of people trying to circumvent the systems. Forcing users to only access email via Web Access or forcing ActiveSync to encrypt phones with long passwords and remote wipe enabled have costs for users. As something like email becomes more cumbersome to use (Outlook Web Access though improved recently is pretty terrible) more and more people will turn to other services like text messaging or instant messages, creating another obvious security risk.

It seems a lot of time and attention is given to stamping out potential HIPAA violation fires, but little effort is put into speaking with or studying end-user behavior and designing new solutions that help them accomplish their goals in a secure environment. The BYOD movement is emblematic of this. Why are we even talking about securing personal laptops and personal cell phones? Because people got sick and tired of old, terrible hardware (*cough* Blackberries and Dell computers running Windows XP *cough*) and starting bringing in and using devices they actually enjoyed using (and worked for them). Hospitals and other companies took advantage of this, saying "Go ahead, bring your personal device and we'll secure it for you!" instead of investing in new hardware.

Better security will come through better design for users' needs, not simply tacking on policy after policy after policy.

abomb said...

We have taken the approach of segmenting the network. On the "Red" side we let people connect to basic things (not email, not core mission critical systems, etc.) which allows them basic functionality. If they pass the post-SSLVPN login checks for encryption, service packs, virus scan software, and corporate standards, they are allowed access to the "Green" side of the network which has all the mission critical applications.

This seems to be a compromise that users can tolerate and gives them a visual representation of what it takes to operate in a "secure" environment. It also limits the access to the mission critical information to devices that are controlled and approved by the IT department.

Shahid Shah said...

Great post, as usual, John. For those looking for a guided approach to these issues, they should check out the NIST Guidelines for Security (SP 800-124 Revision 1).

Shahid Shah said...

For NIST guidance on how to secure and manage Enterprise Telework, check out NIST SP 800-46.

Brian said...

I agree with the last anonymous. BYOD is really a symptom of a problem, not a solution. The problem is hospitals have fallen behind and are not delivering the right tools for the job.

Here is a short piece I wrote on the topic for mHIMSS:

http://www.mhimss.org/blog/bring-your-own-device-not-cure-it’s-disease

Richard DeWald said...

I work for the largest non-profit home care provider in NYC. We use SSL/VPN via a web gateway to a terminal services desktop. Requires windows on the user side, but I run a Windows XP VM on my Mac just for work connections.

Forgive me for being blunt, but there's a difference between a CIO being "held responsible" for PHI blowing around a dump and a CIO being penalized for such an unauthorized disclosure. A big difference. "Held responsible" really means little more than giving plausible scenarios for how it got there to someone in authority. Big deal.

This kind of dramatic framing of the issues has real consequences for patients and bedside providers who work remotely. Information is useless if it isn't shared, and if we don't share it because the sky might fall, what's the point in keeping it at all?

Reasonable safeguards deployed in an environment in which professionals are expected to act professionally is the answer. If we don't have some unauthorized disclosures we aren't sharing information effectively. PHI isn't lists of covert operatives embedded under enemy cover, it's simply private, as private as the contents of a paper envelope in the US mail system.

We rely on the notion that most people won't open other people's mail for privacy, why can't we rely on the notion that licensed professionals won't scatter patient records carelessly, or let their kids log-in to the lab system?

Anonymous said...

Your case:

An employee prints a web page on their home computer and patient data is discovered blowing around in a nearby dump?

How is this different from:

An employee prints a web page on their work computer and patient data is discovered blowing around in a nearby dump?

If employees can print anywhere, how is the exposure any different?

Kevin Rosenjack said...

I think you need to take into account a number of concerns:
Security, Consistency, Device Independence, Supportability

There are valid methods of securing access using SSL VPN, Citrix, VDI, etc.

When I mention consistency I really like the idea of presenting folks with a single common interface whether they are in the facility, at home, or traveling. They should work within a single controlled context – not multiple contexts ie. if you are in the facility do X, if you are outside the facility do Y, if you are on tablet or smartphone do Z.

Ideally the solution should run on nearly any device to support BYOD scenarios. We all recognize that running Windows Applications on iOS/Android is less than ideal. However, this has little to do with remote access and much to do with vendor roadmaps in regard to producing native applications. In a pinch I feel most providers can use technologies such as Citrix/View to reference patient information and simple studies (Fetal Monitoring, ECG, etc.)

Supportability is a key issue. SSL VPN and similar technologies requiring endpoint validation are effective, however, what do you do when they are not running anti-virus, or have malware, a legacy OS, etc. Users will become frustrated when you cannot directly support their personal devices. Additionally, by having consistency (above) you have a single solution which reduces support costs and staff education requirements.

All this said – if I was starting from scratch today – and looking for a solution to bridge the gap between today and the mysterious “Post-PC Era” I would look to a VDI solution such as VMWare View or Citrix XenDesktop. That’s what we are doing.