5 Mobile Device Security Policies to Help You Sleep at Night

November 3, 2014  |  Dan O'Leary

Thinking about mobile device security policy keeps me up at night. It probably keeps you up too.

On a recent evening, I was browsing the findings of a study by McAfee and Ponemon Institute titled “The Lost Smartphone Problem,” which provided data on how many employee devices are lost and recovered annually. My life is exciting.

This problem of mobile security—especially in SMB—is too great to turn a blind eye to, particularly as more and more devices enter the workplace, and get filled up with customer and confidential data.

In case you don’t feel like reading the entire study, here are a few key takeaways:

  • Approximately, 4.3 percent of all smartphones issued to or used by employees are lost or stolen every year. 4%! If they were laptops, you would have a method to find and recover them, right?
  • Fifty-seven percent of lost smartphones were not protected by enabling mobile security features. Meaning all data on those phones—emails, contacts, files and more—is open and available for possible exploitation
  • Out of the 142,706 mobile devices lost or missing in our benchmark sample, on average, only 9,298 (or 7%) were recovered. Replace the word “device” with “puppy” and this would be on every news network in the country. Are mobile devices just not as lovable as a puppy?

With that in mind, here are the five mobile device security policies that will let you sleep better at night:

1. Require device passcode locks. If you do one thing, do this.

With a passcode you are preventing accidental data access (children, nosy people) as well as potential malicious access to information. On iOS, a passcode will encrypt your phone[ii], making it nearly impossible to access. On Android, you should further ensure that storage is encrypted on the device. In the upcoming release of Android 5, also known as Lollipop, this will also be enabled by default[iii].

2. Ask users to opt in to basic enterprise security policies for mobile devices, and be prepared to revoke access controls in the event of changes. Users that are not able to bring their devices into basic compliance must be denied (or given extremely limited) access.

3. Specify minimum supported versions of platforms. Consider not supporting or not allowing versions that don’t meet your requirements. If you bought an iPad 1, the original model, you are likely to be impacted by this, as that model cannot be upgraded past iOS version 5.

As mobile devices age, often support for OS level updates is discontinued. This means that security vulnerabilities and old versions of applications can continue to be used. You could block or not allow use of these mobile devices as a policy, or just end support for them if you support a bring your own device (BYOD) environment.

4. Enforce a "no jailbreaking/no rooting" policy. Disconnect infringing devices from your network and sources of enterprise content and data.

I’ve had my personal iPhone in and out of jail a dozen times in the last few years, so I’m guilty here. It’s a process where you install applications from untreated sources and in the process you can unintentionally download malware or monitoring software than can compromise more than just your device depending on the data you have access to on it. Enforce this by policy first, and by technology second.

There is nothing wrong with hacking your mobile devices (in fact, it’s fun), just don’t do it with your primary device, and be careful what you do with that device after the fact.

5. Require access to enterprise applications and resources with single-sign on and multi-factor authentication. Expect that mobile devices will install applications and access websites and content that you can’t control- and that is OK. The question then becomes, how do you manage access to resources and data that you DO care about?

You can have a mobile security policy to restrict access to things like email, customer data, files, and internal applications to only mobile devices that login with organizational credentials, often through single-sign on. I recommend that you go one step further and purchase or use a multi-factor authentication tool as well so that people are accessing your services with both a password (something they know) and a second factor like an app, token, or text message (something they have).

Dan O’Leary, Solutions Architect at Box, which provides ways to improve mobile security for your organization. Dan works closely with customers to make cloud content management what it should be: simple and secure.

References

[iii] http://www.android.com/versions/lollipop-5-0/

Share this with others

Get price Free trial