Mobility can improve the quality and cost of health care, from care-giver access to electronic health record (EHR) systems to more accurate order fulfillment and asset tracking. But it is imperative that health care organizations safeguard mobile devices and the sensitive regulated data they may carry. Here we explore mobile security best practices for the smartphones and tablets used by health care professionals.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Health care organizations already use many specialized mobile devices, from voice communication badges to wireless IV pumps. But mobile populations are rapidly shifting onto consumer smart phones and tablets that support a multitude of medical applications. According to Manhattan Research, more than 80% of U.S. physicians already own smartphones; about half use them for patient care, education or administration.
As this mobility grows, health care IT and network administrators are being challenged to manage associated risks. These include the following:
- Breaches of protected health information (PHI) due to smartphone/tablet loss or theft.
- Unauthorized access to health care data sent over the air or at rest.
- Inability to ensure or prove regulatory compliance after an incident.
- Insufficient lifecycle control over devices with access to sensitive data.
- Smartphone/tablet compromise by malicious apps and SMS phishing.
The Aberdeen Group estimates that failure to address risks in organizations subject to HIPAA regulations can result in unencrypted data losses at a median cost of $147,485 per lapse.
Use essential mobile security best practices
Health care organizations can manage risks -- including those posed by employee-owned smartphones and tablets -- by implementing four mobile security best practices.
First, risk management starts with visibility. Establish processes for enrolling and vetting every mobile device used to deliver health care, regardless of ownership. This can be done using a mobile device manager portal that health care workers visit to enroll new devices. There, users can be authenticated and mapped to permissions that determine which devices are allowed and the degree of access granted, under what conditions. Authorized devices that meet requirements can thus be automatically inventoried and provisioned for safe, productive use, establishing a foundation for monitoring to ensure continued mobile device compliance throughout their lifetimes.
Second, device access controls are the first line of defense against breach due to loss or theft. Access control policies should reflect user, role and risk. In some health care scenarios, such as tablets used for patient education, a native password may be sufficient. However, tablets with access to EHR systems or used by several workers may require two-factor mobile authentication to track and control individual use. Enforce password complexity rules and inactivity timeouts to stop unlocked devices from falling into the wrong hands -- but balance usability against risk reduction.
Third, to recover lost devices or permanently erase stolen or decommissioned devices, implement a central process to find, lock and partially or completely wipe phones and tablets. Start by defining when these commands can be initiated and their impact on personal data and privacy. For example, workers could be required to give full-wipe permission when enrolling devices that touch PHI. For compliance reporting purposes, make sure IT can prove that a device was in fact wiped.
Fourth, for many devices used in health care, data wipe is not enough. Both over-the-air and at-rest encryption is essential to avoid costly HIPAA notification requirements after incidents involving a potential data breach.
To protect data at-rest, health care organizations should prohibit on-device storage (by using a virtual desktop infrastructure, for example) or encrypt all sensitive data at rest. This may include complementing hardware encryption with container encryption or denying devices that do not offer hardware encryption, such as Android 2.x. Finally, prevent data leakage by disabling data transfer to removable storage or synchronized desktops, and make sure that encryption reports satisfy compliance requirements.
These essential practices should be applied to all smartphones and tablets used in health care environments. However, some applications and uses require fully-managed proven-trustworthy devices that can implement stronger policies. For example, smartphones used for e-prescribing may be limited to IT-standard models, issued certificates and outfitted with both health care and security applications. Examples of stronger policies include blacklist enforcement, anti-SMS phishing and integrity checks such as jailbreak and rooting. Furthermore, enforcement often requires third-party security applications to augment native capabilities.
Leverage native device security …
In fact, BlackBerry devices are popular within health care in part due to their robust native security and management. But other smart phones are catching up quickly. Today, every major mobile operating system (OS) incorporates native device security capabilities that can implement many -- but not all -- essential mobile security best practices.
Research in Motion Ltd.BlackBerry devices run a proprietary OS that enables secure management via BlackBerry Enterprise Server (BES). Each user is bound to a policy, which is pushed to the device upon activation. BES makes it easy to centrally deploy applications and policies such as mandating passwords, wiping data from long-unused devices and enabling content protection.
An option to unlock BlackBerry devices with wearable smart card readers can also be attractive to health care professionals. However, the BlackBerry PlayBook tablet cannot yet be managed or secured this way. Instead, the PlayBook serves as an extended user interface to data on a paired BlackBerry.
A descendent of Microsoft Windows Mobile and WinCE, Windows Phone 7 runs on devices manufactured by Motorola, Samsung and others. The health care industry has long used WinCE on purpose-built medical devices, but physicians who carry Windows Phone 7 will have an entirely different experience.
Windows Phone 7 policies can be configured via Microsoft Exchange ActiveSync (EAS), including password or smart card access control, SD card encryption and remote wipe. These policies can be managed by an Exchange Server or System Center MDM. However, although Windows Mobile 6.5 supports hardware encryption, Windows Phone 7 does not.
The Apple Inc. iOS4 runs on iPhone, iPad and iPod touch devices. Although early iPhones offered no central management and light-weight security, iOS4 includes a native management API, which enables third-party MDM control over an extensive set of profiles. Native security settings that can be enforced for the iPhone 3GS+ include passcode complexity/timeout, remote lock/find/wipe and hardware encryption. Alternatively, EAS can be used to enforce a few basic attributes. Apple tightly controls application access to the OS and device features, inhibiting both malware and anti-malware.
Google Inc.'s Android 2.3 (Gingerbread) OS runs on devices manufactured by HTC, Samsung and others. Like early iPhones, Android 2.3 devices support lightweight security policies, including EAS-enforceable passwords and remote lock/wipe. Android 3.x (Honeycomb) runs on just a few tablets today, where it can also enforce hardware encryption. Third parties have filled some Android security gaps -- for example, storing data in encrypted containers -- but health care organizations should clearly exercise caution on Android.
… And bolster with third-party apps
To ensure that mobile security best practices address higher-risk scenarios, health care organizations can augment native capabilities with third-party defenses. This may be done for many reasons, including back-filling essential gaps, implementing more granular policies, increasing automation or improving visibility and reporting.
For example, third-party biometric or proximity-based authentication can strengthen access control while facilitating frequent hands-free device use. Even when native encryption is available, but especially where it is not, applications with their own authenticated, encrypted data containers can make it easier to reliably track and erase regulated data.
Furthermore, although smartphones are always-connected devices, they lack basic laptop network defenses such as personal firewalls, anti-spam and anti-malware. Third-party security agents can add these while adjusting to OS and hardware differences. Given limited battery life and storage, consider applying some defenses "in the cloud" instead.
Finally, management is a critical enabler for mobile security. As mobile populations grow more diverse, maintaining dedicated management systems and policies per mobile OS becomes inefficient. Instead, consider multi-platform MDMs that can deliver IT visibility and enforce policy compliance for an entire mobile workforce, from iOS4 and Android to Windows Phone and BlackBerry. For example, a multi-platform MDM can establish one central repository for compliance reporting, generating weekly reports that detail when every enrolled device last checked in and whether it was (still) encrypted. This consolidation can facilitate efficient reporting in regulated industries like health care.
As we've seen, smartphones and tables offer native capabilities that can implement many essential mobile security best practices, thereby managing risks associated with mobile devices in health care environments. Employee-owned consumer devices do make security and management more challenging. Some users and tasks will continue to require IT-issued and managed devices. However, health care organizations have much to gain by finding new ways to safely expand mobility, without placing regulated data at risk.
Lisa Phifer is president of network security consultancy Core Competence Inc. Let us know what you think about the story; email firstname.lastname@example.org.