UHN. Encryption. Devil. Details.
Another lost laptop; another press release, something entirely too common these days. But one press release issued last week had an element that caught my eye and serves as a reminder that encrypted laptops are not a panacea for those who want to have data readily at hand in a portable device.
University Hospital Network (“UHN”) in Toronto issued a press release indicating a laptop, containing “select personal health information on about 20,000 surgical patients” was stolen from a staff person’s car on the weekend of May 8-9, 2010. Leaving aside the “downplaying” of the loss of personal health information, here’s the curious part:
“UHN also found that encryption on the laptop failed, so that the information could potentially be accessed.”
Encryption failure?
The obvious question is: How did the encryption fail?
When I canvassed several IT/security professionals as to their experience with “encryption failure” the first reaction was a pause followed by the raising of eyebrows. As in, “are you sure there was encryption on that device?” followed by “not if it was installed properly”. One raised the point: “if the laptop was stolen, how did they ascertain there was a failure?”
There aren’t enough facts here and I’m not looking to criticize UHN but the incident serves as a good reminder that, yes, “the devil is in the details”.
Most, if not all, Privacy Commissioners in Canada recommend encryption be placed on portable devices. (In Ontario, it has been ordered.) As a policy decision, it’s hard to argue with such an approach but the initial implementation and on-going support of encryption – especially with this example – suggests that maybe it’s not the ultimate answer and organizations still need to consider whether large amounts of personal information should even be stored on portable devices.
One can understand if there is a hardware issue (installing encryption designed for a laptop on a netbook) or if there was a software issue (the operating system wasn’t supported by the encryption solution or there was a conflict with other software on the device). But one would think that the initial deployment project in a reasonably sophisticated IT shop would have addressed these scenarios. Ordinarily, these days, if you buy an encryption solution, all things being taken into account, it should work. (I recognize that bugs may exist and zero-day vulnerabilities could emerge.) If anything, people tend to have a “decryption” problem (i.e. the file, drive or disk won’t decrypt), not an “encryption failure”.
If encryption is installed on a device, there are two ways that one can still get at the data: knowing the encryption key or knowing the password. There appears to be a third way, as in this case, where one could simply have it open and on when stolen. Passwords are more vulnerable since they are usually shorter and somewhat easier to crack. Assuming one-factor authentication (two-factor authentication, using a token, being preferable) changing passwords frequently and “rate limiting” are probably the most effective means to deter password cracking.
While minimizing personal information on portable devices is preferable (at least my own preference), at the end of the day, encryption, if used, has to be accompanied by good key management, user training and awareness (including acceptance of the need to change passwords on a regular basis), a robust security policy and, obviously, proper installation.
UHN’s unfortunate incident has been brought to the attention of Ontario’s Information and Privacy Commissioner. If anything good can come from this experience, a fulsome exploration of the facts and further guidance from the IPC – to avoid “encryption failures” in the future – would be welcome.
Thanks for the article Michael. The rate of loss on portable devices is indeed scary and we continue to see very sensitive data just waiting to be taken.
At the end of the day, whether encryption is hard or easy is not relevant. If you have a lousy lock on the back door to your home, will you stay home just in case? No, you’ll have to install a new lock which incurs cost and effort or take a risk. With sensitive personal data, the risk must be minimized.
Encryption on laptops, smartphones and other portable devices is a necessary “evil”. And it’s not evil if deployed properly and with buy-in from the organization in question.
This is basic stuff…but all organizations must take steps to ensure they are protected. And “encryption failure”, as you have intimated, is only a failure of the deployment and use of encryption; not the encryption itself.
Certain States are now being quite prescriptive as to the protection of sensitive data of their citizens:
“(5) Encryption of all personal information stored on laptops or other portable devices”
Source: 201 CMR 17.00: STANDARDS FOR THE PROTECTION OF PERSONAL INFORMATION OF RESIDENTS OF THE COMMONWEALTH OF MASS. (found at http://www.mass.gov/Eoca/docs/idtheft/201CMR1700reg.pdf)
We can’t blame budgets, ignorance, errors anymore. Let’s just get it right.
Hello Michael,
Spot on! Privacy concerns asied, coming from an IT background myself, these are the same questions that I had when I first read the press release….how does encryption “fail”???
I submit that there are three likely possibilities:
1. UHN had auto-deployed an encryption package to all laptops in their fleet. But on checking the records post-theft, they found an error in the logs for that device, indicating that the install had not completed.
2. The password/key was on a sticky-note attached to the laptop, or stored with it.
3. Whatever encryption method was used, it was only applied to a subset of the hard drive’s contents (eg. – e-mail store), leaving the rest of the data unprotected.
An unfortunate situation, but I would commend UHN for having the decency to self-report the breach to the IPC’s office.
Patrick
None of which constitutes an “encryption failure” per se.
Hello Anon,
Agreed, my examples obviously don’t represent the literal failing of encryption (whatever that would be), but represent likely scenarios for which UHN’s communications group might have created such a clever euphemism.
P
Patrick
Your first suggestion on auto-deployment raises another point: if this was the case (and it seems a plausible means of deployment), then there is a step missing in the deployment process – a failure to confirm installation. Checking post-installation as opposed to post-theft might have avoided the problem.
M
UHN uses WinMagic. WinMagic communicates its status to a central server. There are conditions where a deployed installed package does not run properly and fails to encrypt the hard-drive. This is all too common with WinMagic SecureDoc. I suspect that this happened at UHN.
In several cases, we have seen clients telling us that they had encryption on their systems when in fact they only had a start up password setup in the BIOS which is not encryption but just another door lock. Sorry about the late reply but just saw the article.