Following my previous post about Windows Phone 7’s support for Exchange ActiveSync (EAS) security policies I’ve had some further conversations with MS on the subject.
They’ve sent through some more detailed information about what’s supported, what’s not supported and the thinking behind those decisions.
The big one is encryption, at present WP7 doesn’t support it. However there are some factors which help mitigate the risk of having data in plain text on the device.
Firstly WP7 doesn’t support accessing data on the device over USB. You can’t plug a WP7 phone into a PC and access it’s file system as you could with earlier Windows Mobile OS’s, so in that respect it behaves like an iPhone. In addition, WP7 doesn’t support the use of removal media such as Micro-SD cards, so in theory there’s no way of getting to the raw data.
In practice I’m not sure that’s the case. It looks like at least one device has a user accessible micro-SD card slot, and that WP7 does have at least some support for expanding storage in that way. Whether you could remove a card and recover anything useful from it is another question altogether. Initial reports would suggest not, but but that’s not certain.
The other slight concern was WP7’s limited support for MS Exchanges ActiveSync Policies. These allow an organisation to configure the security options on any device connecting into it for email. Or indeed block any device which doesn’t comply.
My previous post lists the policies that are supported, but MS have offered some additional info about some of the policies which aren’t.
- Encrypt storage card – With WP7 not supporting removable storage this isn’t needed
- Disable desktop ActiveSync – WP7 no longer supports desktop Sync for Email and Documents, and Zune software takes care of media sync’ing with a PC
- Disable removable storage – Again, WP7 doesn’t removable storage
- Disable IrDA – WP7 doesn’t have any Infrared support so the policy wouldn’t do anything
- Allow desktop sharing from device – Desktop Sync is no longer available or supported
- Allow unsigned applications – As all WP7 apps are delivered through marketplace, they are all signed and have to be in order to be installed. WP7 doesn’t allow loading or installation of apps through the browser as Windows Mobile used to.
- Allow unsigned CABs – WP7 does not support native applications delivered through CAB files so the policy is redundant
- Configure message formats (HTML or plain text) – plaintext messaging is not supported in WP7 anyway
- Allow mobile OTA update and Mobile OTA update mode – WP7 only supports app installation through marketplace, marketplace automatically notifies users if there is a new version of software
- Include past calendar items (Days) – This is only user controlled in WP7
- Require manual sync while roaming – Again this is user controlled in WP7, though I would imagine many organisations would like control over this – either to enforce it to minimise data charges or disable it.
- Allow attachment download (client side) – This is always on in WP7
- Application allow list and Application block list – All applications are installed through MarketPlace and currently there’s no way to explicitly allow or block the use of certain apps
Many of these do make sense, but whether the support offered will be enough to mitigate the security risks for large organisations who care about these things I’m not sure.
I think MS will need to demonstrate and prove the inherent security they are claiming around WP7’s internal storage, particularly where devices can be expanded through micro-SD cards. Previous versions of Windows Mobile have been pretty secure, indeed there are configurations that have passed Common Criteria evaluation. Whether MS is pursuing this with WP7 is unknown.
I seem to have found a small correction to the info you got from MS:
“Allow attachments to be downloaded to the device” is indeed supported. Sure, it might always be on client side, but when you disallow it server side the client enforces this. It will show the not so informative “Download didn’t complete. Try again.”, but sniffing the EAS traffic server side indeed shows it is respecting policy.
Interesting, thanks for letting me know. I’ll feed that back to MS and see what they say.
Files on the phone are accessible. A few weeks ago some peeps released a tool called ChevronWP7 that allows the side-loading of apps (so bypassing the MarketPlace). Combined with some interop stuff they’ve uncovered this basically opens up the entire file system of a Windows Phone.
Anyway, it might be difficult for normal people to access the phone’s files. But there might also be dedicated professionals or organizations (criminal / government) that might try to access your phone. Hardware encryption will always be the better choice.
Hi Leon,
Indeed, it’s tools like ChevronWP7 and the fact that some hardware vendors allow access to the ‘internal’ SD cards that invalide MS’s reasoning. It was fairly obvious tools like this would be developed and until there are better ways of securing the devices MS will struggle in the Enterprise market they used to dominate.
T
Thanks for publicing your table on mobile devices and axchange policies. I find it very usefull as we are also thinking about a BYO policy for mobile devices.
When I compare your policy list with the microdsoft list at:
http://technet.microsoft.com/en-us/library/bb123484%28EXCHG.80%29.aspx
It seems your list is missing some policies (or have I overlooked them?)
– minimum device password complex characters
– Allow S/Mime software certificates
– Require S/Mime encrypted messages
– Allow Text messaging
Another thing which could be added is the use of client certificates for authentication. This isn’t a real Exchnage policy but it is a feature very often used in comination with Exchange. I know most devices support this (Nokia, Apple, WM). Unfortunately Android 2.2 is still lacking this functionality . Therefor Third party applications like Nitrodesks Touchdown have to be used to add this functionality . (Touchdown also adds support for a number of Exchange policies.)
Regards,
Jan-Taeke Schuilenga
IT architect & user of Android/Touchdown
Hi,
Thanks for the feedback. I’d be interested to hear how your BYO policy goes.
I noticed the discrepancy between the lists too. My list was built up from the options available in the Exchange management GUI, I matched the Technet settings to the GUI options. For some reason the technical name for the settings listed in the docs is different from the GUI names so I put the Technet policy name in brackets. The odd thing was there doesn’t appear to be a GUI equivalent for some of the specific settings (unless I completely missed them!). I can’t remember the exact ones, but suspect they were the ones you mention. I assume that either some GUI options set more than one policy or that they can perhaps be implemented via powershell.
Good point about the client certificate authentication, we’ve recently started to look into that as well, though on first look it would seem to be quite difficult to automate on the Apple platform. If I can pull together all the info I’ll add it to the table, I might also add in a column for Touchdown too as is seems to be getting popular now.
Tom
Tom,
I found a small error in your table.
The policies “require password” & “require alpha numeric password” are already available in Exchange 2003.
Jan-Taeke Schuilenga
Tom,
About the client certificate authentication on iPhones. I agree that it takes some work to improve upon the Apple-supplied method of docking the iPhone with a computer, use iPhone Configuration Utility, and transfer a certificate already in your user store.
Depending on whether you want certificates issued to the devices or the users it might not be all that much work. Assuming you’re using username/password in addition to the certificate you can issue certs to the devices through SCEP. SCEP is included in some MDM solutions, or you can “hack” a web page that takes care of initiating the process (since the client is part of the OS). It might be possible to modify the SCEP enrollment parameters to issue user certificates too, but I’m not sure of that. If you want user certificates you can probably create these by installing the web service extension to the 2008 R2 CA role and create a web page interacting with the CA. This would require some extra work as opposed to the SCEP scenario though.
But this is a digression from the original topic, and it probably would be more than a five-minute job implementing it :)