Locking Down the iPhone

The Center for Information Security has just published a report on secure configurations for the iPhone.

iPhones are a thorn in the side of many security administrators. While locking down Blackberries and other devices seems natural, the whole point of the iPhone is to be fun and easy and free. The CIS report gives IT administrators 20 odd tips on how to lock down the devices.

(You need to provide your personal information to get the report here. Just scroll down to the part on mobile devices. Downloading the report from the CIS was an interesting experience. It's not often you are required to agree with a philosophical statement to be allowed to download a whitepaper - By using the Products and/or the Recommendations, I and/or my organization agree and acknowledge that: No network, system, device, hardware, software or component can be made fully secure)

Is the iPhone ready for prime time in the enterprise? Although some large enterprises are already using it, the vast majority of iPhones are still in personal - not enterprise - use. But there are signs that Apple is trying to piggyback on the success that Macs have had in making inroads in the enterprise beyond their traditional graphics and artistic constinuency.

The CIS report is a very good resource - in conjunction with the Apple Enterprise Deployment Guide - for any enterprise thinking of managing or supporting the iPhone. For each security recommendation, it lists whether the setting can be remotely enforced on the device.

The report splits the various security recommendations into two levels - level I stuff that your users will actually let you do, and level II stuff that you will only be able to get away with in a security critical environment. 

Some of the level I stuff is slightly annoying to the user but otherwise pretty innocuous - require passcodes, enforce complexity, auto-timeouts, auto-updates and that kind of thing. But it is some of the level II stuff - disabling wifi, disabling Javascript, and other draconian measures that probably isn't going to fly with the average user. There's a lot of basic stuff you can't do on an iPhone without wifi. Why get iPhones for the enterprise if you can't do any of the fun stuff? 

Although all the recommendations are useful for both company and (paranoid) home use, there is one structural vulnerability in mobile platforms that they do not - and by construction cannot - address. Many (I am tempted to say most) web attacks on a client/browser somehow involve the abuse of a logged in session or the data that a logged in session left behind. This isn't just XSS (Cross Site Scripting) and XSRF (Cross Site Request Forgery) type stuff, but the abuse of any stored credentials or data on the device.

Now your run-of-the-mill brick PC or Mac are of course theoretically equally vulnerable to this. But users intuitively have a better idea of what sessions are active, what services they are logged into, and what their browser is up to when they are staring at a big screen. In the case of the iPhone, they are even further limited by the user interface from seeing what is really going on.

On mobile platforms, there is an even greater danger to all these live credentials and logged in sessions than fancy XSS type attacks. It is the gazillions of sites that actually have the gall, the chutzpah - the sheer audacity - to use your login credentials to other sites to populate your friend requests or what have you. When you are simulateously logged into 8 social networks, your email, a bunch of bookmarking sites, and who-knows what else, there is a good chance that there is someone out there trying to cull your contacts or something out of one of the other applications.

This practice isn't even considered shady any more and may even be permitted by the terms of use. I remember being asked by LinkedIn (which I consider one of the more privacy friendly social networking sites) if they could have my email password so they could invite all my contacts to link in with me. The pop-up box came up so naturally that many users probably just hand over their password by instinct.

Let's circle back to the iPhone. The iPhone is fundamentally at this point still a end user device. One of the main appeals of the iPhone is that it doesn't feel like work. If Apple were to start tinkering with its default settings and configurations to satisfy corporate IT security policies, this would negatively affect the consumer appeal of the product.

It's also unnecessary. 90% of enterprises require reasonable, but not draconian, security (OK, I made that number up but there is no doubt that the large majority of businesses, even if they deal with sensitive data such as health care or financial data, do not require fortress like data environments). So for these businesses - where data and networks need to be protected but where collaboration, creativity, and efficiency are just as important - there is no need to ban devices like the iPhone as long as sensitive data stays off the device. It is easier to be liberal with devices and strict with the data that gets on them than the other way around.

Since most people are not going to be editing spreadsheets on their iPhone, the main entry point for sensitive data is the corporate mail network. A good example of the threat mobile devices pose is the emailing of sensitive information, and in particular large attachments with personal data whose loss would trigger breach notifications. Many enterprises still do not have corporate policies prohibiting the emailing of such attachments.

Emailing sensitive personally identifiable information is a bad idea for many reasons. It's just too easy to get into a situation that results in a data breach by someone for example emailing a file to the wrong address. But mobile devices (not just the iPhone) are yet another reason why this is a bad - really bad - idea. Many webmail programs like gmail download emails onto end devices without being prompted. Many times these are not encrypted at the disc level upon download. So the unencrypted data is sitting on these devices. But of course these devices disappear/get lost/get stolen all the time. Depending on the data, the circumstances, and the state, it is certainly possible that this would trigger a breach notification requirement.

For larger enterprises some DLP type solutions may help mitigate this risk, although these are very involved implementations. Although I don't often mention particular vendors on this blog, there is one managed file transfer solution I have been a repeat customer of that addresses this issue well. Accellion is largely marketed towards the large file transfer market, but it also provides a simple and auditable way to offload sensitive data transfer from email networks. There are also numerous other managed file transfer solutions that are active in this space. At the end of the day it's easier to manage file transfer than to manage employee mobile phones.