As we continue the journey to protect corporate data that is accessed from personal mobile devices, we’re developing increasingly rigorous policies that rebalance individual preferences with corporate compliance requirements.
Requiring a non-trivial password and a timeout is supported by all Windows, Android, and iOS phones. Using Microsoft Active Sync, we can push settings to phones, enforcing corporate policies.
Central management of personal phone encryption is much more problematic.
I’ve spoken to my peer CIOs in Massachusetts and we all have policies requiring encryption of mobile devices that access hospital information systems.
Massachusetts requires that any mobile device containing “personal information” be encrypted:
“Under the law, personal information to be protected includes a Massachusetts resident’s name (either first and last name or first initial and last name) combined with a complete social security number, driver’s license, or other state-issued number, a financial account number or a complete credit card or bank account number.”
However, no local CIO has tried to push encryption settings to personal devices.
We’ve tested encryption on several smartphones and found that it lacks robustness – we’ve had performance issues and data corruption issues.
Many phones do not support pushed settings to encrypt the device. Some devices, such as any iPhone older than the iPhone 3, do not support encryption at all. Here’s an overview of the heterogeneity.
Similarly, no local CIO has implemented automated remote wipe of personal devices for a certain number of failed password attempts. At present, smartphones have no capability to selectively wipe corporate data, leaving personal data intact. Although there are mobile device management (MDM) solutions that require loading software on personal devices, they are expensive and challenging to support.
Thus, the best practice in the hospitals of Massachusetts as of mid-2012 seems to be pushing password/timeout settings, avoiding remote wiping, and requiring encryption by policy rather than a forcing technology.
What about laptops?
Everyone in healthcare wants laptops encrypted because encryption provides a “safe harbor”. If you lose one that contains protected healthcare information, you don’t have to go through the full breach disclosure.
There are three generations of laptop encryption strategies:
- Full Disk Encryption (FDE) requiring an application such as McAfee’s SafeBoot
- Native Operating support for encryption such as Microsoft’s BitLocker in Windows 7 and Apple’s native encryption in Lion.
- Self-encrypting drives with enterprise management software such as Safend Endpoint Security. The encryption is part of the hardware when the device is procured.
We currently use FDE for Windows XP and native operating system support for Windows 7 and iOS. We’re studying management tools that support self-encrypting drives.
The issue of encrypting smartphones and laptops is a very high priority for hospital compliance and risk committees. The policies are clear, but the technology to support those policies is still in evolution.
The burden on IT departments to purchase and support mobile device security tools is significant.
Self-encrypting drive approaches hold promise because they are operating system neutral and require little support.
We will continue to enhance our abilities to centrally manage encryption of mobile devices. Like many security issues, the management of personal device encryption is a journey.