WMPoweruser.com

The recent revelation that Apple’s iPhone OS had been falsely reporting to Exchange servers that iPhones and iPod Touches provided on-device encryption when in fact they did not has raised several questions regarding mobile device support for EAS (Exchange ActiveSync) policies — vital safeguards many businesses employ to secure access to corporate information, whether to meet specific regulations or as a matter of general security prudence.

Exchange ActiveSync 2007 (EAS) supports 29 access and security policies that IT can enable.

Many mobile devices support at least some EAS policies: Apple’s iPhone; smartphones using Microsoft’s Windows Mobile OS; Nokia’s E and N series, as well as the S60 through a download; and Palm’s WebOS, along with its defunct Palm OS.

Windows Mobile 6.1 supports all 29 policies, though an Exchange enterprise license is needed for 14 of them. Apple and Nokia did not respond to InfoWorld’s request to list specifically what EAS policies their devices support; a Palm spokeswoman was unable to find the information even after several days.

Google’s Android OS does not support EAS at all, and Research in Motion’s BlackBerry does not support EAS directly. Instead, you use RIM’s BlackBerry Enterprise Server, which has its own set of policies, all of which, of course, the BlackBerry OS supports.

Thus, if EAS requires a policy that the device does not explicitly says it supports, "the device is blocked from accessing the Exchange server," a Microsoft spokesman confirms.

The reason that the iPhone OS got away with connecting to Exchange servers that required on-device encryption is because Exchange has to trust that the devices are accurately reporting what they support, as well as the device’s actual status for each supported policy.

Apple’s false reporting of on-device encryption for iPhones ended with its iPhone OS 3.1 OS update released on Sept. 8, but still does not allow the full range of security policies enterprise seen.

As a security and compliance manager, at a minimum, one should make sure that the Allow Non-Provisionable Devices option in EAS is disabled. This treats a non-answer as a no when it comes to policy support, and will block devices that support only a subset of Microsoft’s 29 EAS policies — meaning the Apple iPhone, Palm Pre, and Nokia E series, N series, and S60 smartphones — when your EAS policies on Exchange aren’t supported by the device.

However since once can not be sure the devices are telling the truth about the policies they support — for example, if you have iPhone users that run iPhone OS 3.0 or earlier, the best solution is really the only solution.

Ban them all. The safest low-cost choice for devices you don’t trust to be accurate is to ban them altogether, such as by requiring the use of certificates for access that you haven’t distributed to their users. Because these devices have no certificates installed, they can’t connect. But this technique means you need to distribute certificates to the mobile devices you do support, which essentially limits you to BlackBerry (which requires the separate BlackBerry Enterprise Server) and Windows Mobile devices in an enterprise setting.

A second, less secure option is to create separate policies for different devices. For example, if you have a corporate security standard that requires on-device encryption but you want to let iPhone users connect to Exchange, you could set up a policy requiring that a password be set that meets specific complexity thresholds, that passwords be changed every so often, and that remote wipe be enabled (through the Maximum Failed Password Attempts policy). For devices that support on-device encryption, such as Windows Mobile handhelds, you would have a simpler policy that, say, require just a complex password and on-device encryption.

Of course, you cannot use this "alternative policy" option if you have a regulatory or other reason that forces you to use a policy on all devices. For example, if you’re subject to HIPAA or privacy breach notification laws, you don’t have the option of disabling the on-device encryption policy — you risk audits, fines, and contract cancellations if you do.

To avoid jail time for your executives read more in this SFGate article here.