Could a Strong BYOD Security Policy in Healthcare Actually Deter People from Participating?

15 07 2012

Over the past several years, the healthcare industry has seen a large push towards the greater use of mobile computing.  Quality of care is improved through providers having access to electronic medical records directly at the point of care (ex. patient bedside), rather than at a remote nurse’s station.  However, the cost of purchasing a large number of appropriate mobile computing devices can be extravagant, especially given the additional cost of maintaining the environment necessary to support mobile devices (ex. wireless infrastructure, mobile software development, etc.).  Thus, healthcare institutions have begun examining and implementing a policy known as BYOD (Bring Your Own Device).  Healthcare providers who already own mobile computing devices can use them in place of an institution-supplied device, thus potentially saving the institution from having to invest money in device procurement and maintenance.

Naturally, a BYOD policy would raise a significant number of questions and issues for an IT security analyst.  At a most basic level, a BYOD policy is challenging because you are taking devices that are neither owned, nor maintained by the institution, and incorporating them into your existing infrastructure.  Aside from the fact that there are a wide variety of devices and operating systems available to customers, IT security professionals are essentially being asked to grant access to subjects that are outside the traditional scope of control within the institution.

Personal devices serve a different purpose than due company-owned devices and thus have to be thought of differently (McNickle 2).  According to a white paper published by MobileIron, which was cited in a Healthcare IT News article, “[Personal device users] download more apps.  So with BYOD, devices may fall out of compliance with corporate policy more frequently” (McNickle 2).  The article suggests that IT departments implement a different set of security policies for personal devices than they do for company devices (McNickle 2).  Yet how is this accomplished without, in effect, deterring a device owner from wanting to participate in BYOD?  After all, this is supposed to be a program that can potentially save healthcare institutions money and improve quality of care at the same time.  Given the fact that you are dealing with peoples’ personal property that is used outside of the workplace, how much can you ask of these individuals before they decide that it’s too much of a hassle to participate?  As the cited white paper notes, there is a challenge as to whether users will accept he burden of corporate IT security policies being applied to their devices.  “If the trust level of the personal device is so low that security requires extensive usage restrictions, the employee’s personal mobile experience will be damaged, and neither the [security] policy nor the BYOD program will be sustainable” (McNickle 2).

BYOD not only has to deal with the challenges posed by the mere content and data stored on personal mobile devices, but also has to take into consideration the mindset of the users at play in this situation.  In a response to a blog post entitled “BYOD And The Healthcare Dilemma,” a contributor noted that a challenge at their institution was that providers often sent private patient data to and from personal devices via unsecured communications channels, such as text messages (Johnsen).  On a company-owned device, it’s within a company’s right to disable unsecured communications channels.  But with personal devices, specifically smartphones, it would be unrealistic to prevent such devices from accessing these channels.  As this contributor notes, they were eventually able to find a solution that removes the messages from the device once they have been sent.  It was restrictive in that it prevented BYOD users from utilizing their native text messaging functions and thus was naturally met with some resistance, but it was ultimately accepted (Johnsen).

According to the white paper published by MobileIron, preserving the core functionalities and device usability is essential to the success of a BYOD program.  Failing to do so can be a deterrent to participating in such a program and does little to serve both the company and the user.  Users will be discouraged from participating if the BYOD requirements prevent users from enjoying all of the benefits that their devices provide to them outside of the workplace (BYOD Strategies 5).  Thus, it is suggested that the company establish a clear “social contract” (BYOD Strategies 5) of sorts with the affected user, which will create a compromise that balances security requirements against the user experience.  While it may not be appropriate to track a device’s location, it may be ok to request an application inventory from the device to insure that there are no potentially malicious applications installed on the device.  Most importantly, it is vital that an institution develop a BYOD policy that is clearly understood by the user-base and not merely presented to the user-base in the form of a long, technical contract containing esoteric terminology (BYOD Strategies 5).

In conclusion, I believe that healthcare institutions can implement a successful BYOD policy that balances both the needs of the user-base and the need to protect patient information.  The key to accomplishing this is establishing a compromise between both parties.  IT security departments must realize that they cannot simply apply traditional access control models used for company-owned devices to personal devices, yet at the same time, users must realize that the information they will be accessing on their devices is confidential and must be protected.  If healthcare functions can be adequately protected while having minimal impact upon a user’s use of the device outside of the institution, then BYOD can provide major benefits to healthcare institutions.


“BYOD Strategies: Chapter I.”  MobileIron.  2012.  2011<;.

Johnsen, Elly.  Weblog comment.  “BYOD and The Healthcare Dilemma.”  FortiBlog: Reports from the   Threat Landscape.  Fortinet, 29 March 2012.  Web.  3 July 2012 <;.

McNickle, Michelle.  “6 Keys to Developing a BYOD Program.”  Healthcare IT News.  MedTech Media,     15 March 2012.  Web.  3 July 2012 <,1&gt;


BYOD Password Policies – First Level of Defense

14 04 2012

A  ThreatPost tweet (Donohue, 2012) and coverage on NBC’s Today Show (How safe is your smartphone’s data?, 2012) provided broad visibility to a recent study sponsored by Symantec and Sprint called The Symantec Smartphone Honey Stick Project. (Haley, 2012)  In late 2011, the experiment was conducted by placing fifty smartphones in five large cities in places where the phones would have appeared to have been misplaced by their owners in an effort to identify what would happen with the phones when found.  Phony personal and corporate applications were loaded on the phones along with software that tracked the access to these applications and GPS location of the phones.  No passwords or any other security features had been enabled on any of the fifty phones.  The project’s results showed that 83% of the phones’ finders accessed the phony corporate data.   The fake corporate email application was accessed on 45% of the phones while the corporate data planted on the phones was accessed on 53% of the devices.  ([OPERATION HONEY STICK] Where’s Your Smartphone?, 2012)

The experiment summary document includes several recommendations for both corporations and consumers to better protect the data that resides on smartphones.   One recommendation specifically targeted the password policies established by corporations for these devices.  “Organizations should develop and enforce strong security policies for employees using mobile devices for work; this includes requiring password-enabled screen locks. Mobile device management and mobile security software can aid in this area.” (Wright, 2012)  This experiment commissioned by Symantec reinforces the need for corporations creating policy statements to integrate BYOD (Bring Your Own Device) into their operating models to ensure that strong password policies be established for employee-owned smartphones that have access to corporate data.

Good Technology (Bring Your Own Device Individual Liable User Policy Considerations, 2012) recommends establishing password and device locking policies for employee-owned devices that are similar to those established for company-owned PCs:

  1. Policy should state the requirement of a password for the device.
  2. Policy should specify the required length of the password to be 6 characters.
  3. Policy should specify that the password include at least one letter or number where the device supports alphanumeric passwords.
  4. Policy should state the frequency required for password changes to be every 90 days.
  5. Policy should state the number of passwords retained in password history is four.
  6. Policy should state that after 30 minutes of inactivity, the device will be locked requiring the password to unlock.
  7. Policy should state that after 10 invalid logins, the device locks the account.

Andrew Jaquith, Chief Technology Officer of Perimeter E-Security, has a more practical approach toward setting password and device locking polices for mobile devices aimed at balancing a strong, secure password selection with device usability. (Jaquith, 2011)

  1. Policy should state the requirement of a password for the device.
  2. Policy should state the requirement of an  8-digit numeric PIN (not allowing the use of simple PINs)
  3. Policy should state that the device will lock after 15 minutes of inactivity (with a 2 minute grace period)
  4. Policy should state that the device will automatically be wiped or permanently locked after 8 invalid login attempts.

(No policy exists specifying the frequency of PIN changes or requirement to maintain password history.)

In a recent Forbes article (Gupta, 2012), PJ Gupta sites that one of the common BYOD policy mistakes is “Leaving Passwords Up to the Users”, as users will not consistently implement password protection on mobile devices unless required.   He instead sees the need for IT departments to establish BYOD policies that require passwords on all devices with appropriate levels of complexity standards set for these passwords.

Of all the policies required for the integration of BYOD into a corporation, password policies represent only a subset of those that are required.  But as shown by Symantec’s Honey Stick Project, password and device locking policies can provide the first level of defense in the protection of corporate data on mobile assets.

NOTE:  Symantec is in the process of building its capabilities to manage mobile devices across the enterprise with its recent purchases of two companies, Odyssey Software and Nukona.  Odyssey Software provides Management Device Management (MDM) services while Nukona provides Management Application Management (MAM) services. (Symantec Corporation, 2012)  The recent results of the study encourage the consideration of their new product offerings.


[OPERATION HONEY STICK] Where’s Your Smartphone? (2012). Retrieved from

Bring Your Own Device Individual Liable User Policy Considerations. (2012). Retrieved from

How safe is your smartphone’s data? (2012, March 8). Retrieved from

Donohue, B. (2012, April 4). Symantec Experiment: Half Of Those Who Find Smartphones Don’t Return Them. Retrieved from

Gupta, P. (2012, February 27). Developing a BYOD Strategy: The 5 Mistakes To Avoid. Retrieved from

Haley, K. (2012, March 9). Introducing the Symantec Smartphone Honey Stick Project. Retrieved from

Jaquith, A. (2011, March 7). Picking a Sensible Mobile Password Policy. Retrieved from

Symantec Corporation. (2012). Symantec Advances Enterprise Mobility with Odyssey Software and Nukona. Retrieved from

Wright, S. (2012). The Symantec Smartphone Honey Stick Project. Retrieved from