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.