By Scott Matteson From TechRepublic

IT mistakes reported in the Apple and FBI story offer lessons in what not to do when it comes to mobile device management. Here are MDM best practices IT should follow.

The FBI wants information about the details and motives behind the mass shooting committed in San Bernardino, CA in December 2015 by Syed Farook and his wife Tashfeen Malik. As a result, the iPhone 5C issued to Farook by his employer, San Bernardino County, has become a subject of much contention and hot debate.

The iPhone could provide more clues about the plans behind the shooting, as well as who else might have been involved or assisted Farook and Malik. However, the locked iPhone (which had no fingerprint security setting) is currently off-limits to anyone, and the FBI has requested that Apple alter the software on the phone to set it not to erase all data after a set number of failed password attempts.

Rather than contribute to an already well-populated debate arena, I want to focus on the mobile device management (MDM) aspects of this case.

MDM blunders and best practices
Farook’s iPhone was last backed up to iCloud October 19, 2015, and that information has been made available to the FBI. However, there is quite likely information on the phone that was added or received since then that might help the FBI investigation.

More about Mobility

Samsung inspired by Apple Purchase Plan
Why mobile apps are the biggest challenge to the web’s freedom
Subscribe to our newsletter, The Mobile Revolution
Power checklist: Managing and troubleshooting mobile devices
In order to induce another backup to iCloud the iPhone should have been taken to an area with a known Wi-Fi network, such as Farook’s home. Unfortunately, on December 6, 2015 the San Bernardino County IT department reset Farook’s Apple ID password (supposedly at the direction of the FBI, although there is conflicting information about that detail). That, in turn, prevented the phone from backing data up to iCloud the next time it was connected to a known Wi-Fi network.
This situation could — and should — have been avoided. Reuters reported on February 19, 2016 that San Bernardino County had a contract with MDM software provider MobileIron Inc., but hadn’t installed the software on Farook’s phone. The software could have allowed the county IT department to unlock his phone in the aftermath of the massacre. This is a huge mistake from a MDM best practices standpoint.

The following MDM best practices should have been applied in this case, and should be applied in your organization for company-issued devices:

Require the IT department to approve the addition of mobile devices to the company network/messaging system via a quarantine mechanism;
Require complex passwords;
Activate a screen lock after a period of inactivity (60 seconds for instance);
Enforce automatic wiping of devices after 5 or 10 failed logon attempts;
Mandate encryption of storage, both for internal and external micro-SD cards (if applicable);
Mandate automatic backups to a location the IT department can access;
Utilize antimalware software to protect devices and report on malware activity;
Establish approved applications and functions, and disable those that do not meet company criteria;
Allow applications to be installed only from approved locations;
Configure access only to desired networks (or block access to open, unsecured Wi-Fi networks);
Configure VPN settings as needed via MDM management;
Use “containerization” to separate business vs. personal information on devices;
Implement content management settings to expire documents if needed and/or restrict users from sharing or editing these items;
Figure out whether multiple policies are needed (depending on the employees involved) and customize them as needed;
Monitor and report on device status. IT should be aware of any devices that haven’t checked in for several days and take steps to determine why (Was the device lost, stolen, or broken? Is the employee using it on vacation?); and
Restrict users from interfering with or disabling any setting needed to properly manage, maintain, or support the device.
The key to all of these settings (and the above case) is that the IT department should be able to change or revert them for any company-issued phone as needed. The phone must have network access to receive the updated setting(s). If the user has put the phone into airplane mode, it will be dead in the water. A policy to turn off airplane mode after a set period (say two days) at which point the device will re-establish network connectivity also makes sense. I’m not aware of an MDM policy that can currently do this, but it should be food for thought for MDM vendors who seek to provide better flexibility and control for IT departments who might find themselves in San Bernardino County’s situation.

Another possibility is for the IT department to select and provide mobile device passwords to users and then restrict these from being changed. This could be tedious, but it would guarantee device access in situations such as these.

With proper MDM controls, the IT department should have full access to any company-issued or company-connected device as well as the data on the device.

For more on this story go to: http://www.techrepublic.com/article/applefbi-battle-highlights-it-blunders-and-need-for-strong-mobile-device-management/?ftag=TRE684d531&bhid=22414566808023710814878762937500