September 21, 2009, 10:47 AM — I've been called everything from stupid to a Microsoft fanboy in recent days for an opinion article criticizing Apple's handling of a bug fix in the iPhone OS. While there's legitimate argument over how damaging Apple's decisions were, many e-mails, comments, and blog posts show how few users really understand the issues around access policies when connecting to corporate servers. And many bloggers are telling users that there's a simple fix to this issue. There isn't. For many enterprises that allowed or were planning to allow iPhone access to their networks, Apple's handling of this situation is, in some measure, a betrayal.
[ Read the article that set off the controversy over Apple's handling of the iPhone's Exchange policy support. | Learn how this is not the first time Apple had quietly fixed a policy bug in the iPhone. ]
First, a recap: A bug fix in the iPhone OS 3.1 update now ensures that iPhones and iPod Touches accurately report back to Microsoft Exchange servers whether they have on-device encryption enabled. Prior to Version 3.1, iPhone OSes reported to Exchange that the devices had on-device encryption despite the fact that no device prior to the iPhone 3G S included that functionality. Because of this, Exchange servers set to allow connections only from devices with encryption enabled -- a federal and state requirement for many organizations -- have been accepting connections from unencrypted iPhones for more than a year.
Somewhere along the line, Apple figured this out. And by not telling IT of this issue earlier, Apple has put many organizations at risk of noncompliance. To add insult to injury, Apple's quiet bug fix suddenly and unexpectedly caused encryption-requiring Exchange servers to block iPhone and iPod Touch users, except for those with iPhone 3G S and the late-2009-model iPod Touch devices. This has caused headaches for many IT support staffs and embarrassed those IT admins who had convinced their companies to allow Apple's technology into their sacrosanct networks.
iPhone users and IT admins dealing with this issue would be wise to avoid falling prey to the following myths circulating widely on the Web.
Myth 1: You just need to turn off the policy at Exchange Several blogs have recommended a quick fix to the access issue: Turn off Exchange's on-device encryption policy requirement, and all iPhones and iPod Touches will then be able to connect to your network. Incredibly, Apple makes the same recommendation on its support page.
Sure, it's possible to change this setting, as AppleInsider explains in a recent blog post, but most enterprises will not. They have that policy in place for a reason, and they're not going to make an exception for the iPhone. (Or other devices -- they're not targeting the iPhone, despite what some conspiracists seem to think.) In many cases, they would face huge costs if they did.
There are a bevy of regulations -- such as Sarbanes-Oxley, FIPS, HIPAA, and the privacy breach notification statutes in most states -- that require many companies to enforce various access and security policies for corporate and personal data. For example, HIPAA (which applies to the health care and insurance industries) requires that patient data be kept confidential and cites encryption as an acceptable method of doing so. The state privacy breach disclosure laws say that if data is encrypted on devices -- laptops, mobile devices, and so on -- companies don't have to notify everyone whose personal information might have been on a lost or stolen device; such notification costs a lot of time and money, and it damages the company's reputation -- remember the brouhaha when a Veterans Affairs employee lost a laptop that had thousands of Social Security numbers on it?
Good luck getting your corporation's legal, security, and/or risk officers to grant iPhone users an exemption to such regulations just because their device can't support the encryption policy. They'd be foolish to say yes. It's like expecting a waiver from obeying speed limits because you drive a hybrid. Sorry, public -- or in this case, corporate -- safety comes first.
