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.
If your company doesn't need to follow these regulations, then maybe you can convince IT to drop the requirement for iPhone and/or other devices. But don't be surprised if IT still says no: Even if not required to follow these regulations, many companies choose to do so to reduce their risks.
Myth 2: Encryption can be broken, so it shouldn't be required
Yes, encryption can be broken, and it appears the iPhone 3G S's and most recent iPod Touch's encryption is easily defeated. But legally, if a device has encryption, it satisfies many of the regulations that apply to larger businesses. That gives them a legal pass even if the data is ultimately compromised. Can you really imagine a company not taking advantage of that legal pass just to satisfy iPhone users?
Of course, many organizations -- especially those subject to Defense Department's standards -- must support specific levels of encryption. In those cases, you can bet that your choice of devices allowed onto the network will be very small: likely just some BlackBerry and Windows Mobile models.
And if your data really is supersecret, your company wouldn't allow it on a portable device anyhow, no matter what encryption is in use.
Myth 3: The iPhone supports SSL encryption, so I'm covered
Sorry, but SSL encrypts data as it is sent between the device and the server. Most organizations require such encryption, which the iPhone does in fact support. But SSL does not protect the data stored on the device, so it doesn't satisfy that encryption policy requirement.
Myth 4: You can require passwords and remote-wipe an iPhone, so you don't need encryption
Yes, the iPhone supports these capabilities, though sometimes you need to use Apple's free iPhone Configuration Utility to enable them. But so what? Bottom line, some regulations require encryption. They don't say that you can substitute other policies in place of encryption. (To learn more about using the iPhone Configuration Utility, see InfoWorld's article "Can you manage an iPhone like a BlackBerry?")
By the way, some regulations require multiple policies be in force, such as insisting that the device be password-protected against use, that it be remote-wipe-enabled in case it is lost or stolen, that its built-in cameras are turned off, and that on-device encryption is enabled for corporate data.
Myth 5: My laptop's not encrypted, so my iPhone needn't be, either
It's true that many organizations have not enabled encryption on laptops, though that's been changing in recent years as the risks of having employees carry their data out the door have become clearer. (For a good primer on how to deploy encryption, check out Mel Beckman's article "Your laptop data's not safe. So fix it" on InfoWorld.)
Some argue that organizations that have fallen down on the job when it comes to laptops should thus relax the requirements on other devices. Good luck there. If your organization qualifies under regulations requiring encryption (or any other access policies), you can bet that at some point all portable client devices will have to adhere. Mobile devices are often the first targets because there aren't that many of them, and as the new device in the IT mix, it's easier to start off requiring policy adherence. You can bet that your laptops will get encrypted, too.
Myth 6: It's really Microsoft's fault
One of the more ludicrous arguments I've seen is that it's not Apple's fault that the iPhone OS was misreporting to Exchange that it supported on-device encryption when it did not. It's Microsoft's fault for not catching the lie.
That's impossible. As the folks at Internet security firm VeriSign explain, "It appears all policy conformance claims (like this ActiveSync mailbox policy on device-encryption claim from the iPhone) are not programmatically verifiable, so they're not programmatically enforceable." In other words, Exchange can't peer into a client device and figure out what's going on under the hood; it has to rely on the client to be honest. That makes sense: How could Exchange or any server independently access all the kinds of devices out there and figure out how they're set?
Myth 7: Microsoft's software is so buggy, Apple should get a pass
The only more ridiculous argument along this vein is that because Microsoft produces such buggy, insecure software, Apple shouldn't be criticized when it has a bug.
Microsoft does produce a lot of buggy software. There's a reason it has a regular Patch Tuesday schedule to release fixes to the never-ending stream of bugs that Microsoft seems to generate.
[ To learn more about addressing the Mac's security issues, see InfoWorld's article "Mac (in)security: How to secure Macs in business." ]
So what? Microsoft's failures don't justify Apple's. Remember what your mother said: If your friends jumped off a cliff, would you?
I would argue that Apple has a higher standard to meet. It's needled Microsoft mercilessly for years about Windows' proneness to viruses and other security flaws, leaving the (false) impression that its Mac OS X is somehow immune to them. So Apple needs to be like Caesar's wife: beyond reproach.
Of course, Mac admins know that Mac OS X is less susceptible to malware because hackers have focused on the hapless, widely deployed Windows instead, not because the Mac OS is inherently safer. Mac admins also know Apple is often slow to fix bugs in its OS and rarely describes what it did fix. Microsoft at least tells you, though buried in reams of documents that make you think it is trying to hide its flaws in plain site.
A related argument on some blogs is that Apple never promised that the iPhone would accurately report its on-device encryption status, so it is wrong to hold Apple accountable for the iPhone OS's misrepresentation. That's an argument that justifies any poor product, and I doubt it's a standard that any reputable company would hold itself to -- least of all Apple, which has staked its business on delivering exceptional products.
How to avoid the smartphone Exchange policy lie
Just because a mobile device says it supports Exchange policies doesn't mean it does. Case in point: Apple's iPhone
The other iPhone lie: VPN policy support
The iPhone OS 3.1 fixed false reporting about Exchange policy adherence. It turns out that a similar flaw existed for VPN policies, too
Apple betrays the iPhone's business hopes
Apple's fix of a security hole reveals a long-simmering flaw and makes many iPhones suddenly incompatible with Exchange
Mac (in)security: How to secure Macs in business
As Macs make their way into the enterprise, IT needs to address these six security flaws before disaster strikes
21 apps Apple doesn't want on your iPhone
Worthwhile productivity apps you won't find at the App Store
The no-junk business iPhone apps finder
InfoWorld's interactive catalog of iPhone apps designed for businesses, professionals, and IT staff