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.
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.
- Apple vs. FBI: TechRepublic members speak out, side with Apple (TechRepublic)
- 10 things to consider when choosing an MDM solution (TechRepublic)
- Lawmaker to FBI: Don't use iPhone unlock case to bypass Congress on encryption (ZDNet)
- Tim Cook says Apple's dispute with FBI is best handled this way (CNET)
- Bill Gates hedges on FBI demand for iPhone access (CNET)
- Apple's Tim Cook: We'll fight 'iPhone backdoor' demands from FBI (ZDNet)
- Apple vs. the FBI: This may not be a war Apple can win (ZDNet)
- Survey: Americans split on Apple vs. FBI privacy dispute (TechRepublic)
Scott Matteson is a senior systems administrator and freelance technical writer who also performs consulting work for small organizations. He resides in the Greater Boston area with his wife and three children.