
PDAs, and especially smartphones, are very popular devices. Sadly many IT departments still ignore Windows Mobile devices. The devices live in the grey area where they do interact with the business systems (like Exchange and Sharepoint), but are not secured according to company policy. This results in an unmanaged risk in the infrastructure: the devices do contain business information but no demands are posed upon them to make them secure. We identify the risks that are introduced and show you that these risks are in fact unnecessary because you can do reduce the risks without adding costs or overhead. In this article we show how you can achieve a reasonable level of security that has minimal impact on user experience and budget.
This article is written based on a series of presentations for IT managers from both small and big companies as well as several articles I've written for information security magazines. What amazed me is the lack of attention for the devices that are bought by employees themselves. Companies are extremely restrictive on the mobile solution they buy themselves: most of the IT managers I spoke rejected any proposal to do so. To them, that was the end of the mobile discussion. To me it wasn't: it proved to me that they were ignorant about the devices that entered through the backdoor, by taking this position the problem got worse instead of better. The discussions that followed provided great insight on both sides, and I want to share the things we learned together.
Major point in this article is that it is necessary for ICT departments to take measures to secure mobile devices, regardless who is the owner of the physical device. These measures are relatively easy to take and that users should not be hindered too much by these measures. Many companies have developped a blind spot for mobile devices in general, especially the ones that are taken along by employees themselves. Companies are in fact taking counterproductive measures to protect their interest: most companies only allow the desktop sync with these devices, which makes these devices unseen and uncontrollable even if they are completely filled with company information. To stop this, companies do have to grasp any means possible to gain control over these devices: it requires querrilla tactics to find uncontrolled devices in your infrastrucure and convert them into well protected containers of information.
Backdoor devices?
Currently, there is a root-up momevement of PDA deployment and companies do have to act to protect their information proactively. PDAs and smartphones are gaining popularity by the minute. Many people see the benefit of using a PDA for picking up e-mail and managing their calendar while they are on the move. It lightens their daily taskload in a significant way, giving people a better feel of productivity and a better work/life balance. The sense that they can make their life easier triggers a lot of people to want a PDA or smartphone, regardless if their employer buys it for them or they have to buy it themselves. With prices of devices going down, people are in fact now capable of buying the devices themselves.
The combination of the prices going down and the need of effectiveness is noticeable in business settings. A lot of devices are simply entering the company through the backdoor: people are simply buying devices themselves and take them to work to hook them up to whatever they will find. Research by the yankee group indicates that a staggering 86% of the employees take personal equipment to the workfloor. According to research conducted by HP, 83% of all devices found in companies are privately owned. Still these devices are used in business contexts and contain company information. Since the devices are privately owned IT departments ignore them, making them unmanaged risks in the company. This introduces the need for guerrilla tactics: you will have to find unusual ways to gain control over devices that legally are beyond your control or otherwise you will lose control over your data completely.
There is a need to gain control over these devices: they are in fact a risk. They are not considered under the company control, but still they contain company confidential information. Lots of it and the nasty stuff as well: an avarage PDA has a memorycard of 1Gb to 2Gb installed. Many companies are in fact becomming extremely woried by the vulnerability of all these small data carriers. While the most traditional view focusses on the data contained on the device: the so-called PIM data, there are other types of data to consider as well. Research conducted by Pointsec Security reavels that PDA’s confirms that most PDA's contain the following information:
.jpg)
But it isn’t this type of data that should worry IT departments. These items can also be found in your ordinary Filofax or suitcase. So while losing this kind of information isn't what you want, it did happen all the time without anybody noticing or worrying about it. What makes these devices so dangerous is that these devices also contain active credentials to company networks, mailservers and even backoffice systems like Sharepoint. Since entering a password on a mobile device is such a hassle, most of them are simply cached on the device, giving the user access when he needs it, anyone gaining control over the device has full access to that part of the company. Even if the IT department did not release such information themselves, people simply copy certificates and other credentials from their laptop to their PDA and use them to gain access to company owned networks, systems and above all internet. Although the certificates and other credentials are encrypted on the device, they still can be used by anyone if the device is accessible.
Seeing the data and credentials contained on these devices, there are in fact several risks: major risks are theft or loss of the device, as well as unattended use. Theft and loss do happen a lot: in a city like London alone, every year around 60,000 mobile devices are lost and 120,000 are stolen. Although destruction of devices does happen a lot more, it generally is not a problem for corporate IT departments when it concerns privately owned devices: the data on the device is hopefull destroyed along with the device, although you are never sure what someone can retrieve a damaged device. Looking across the many corporate applications of mobile devices, having talked to dozens of IT managers, confidentiality concerns are always on the top of the list. Other security aspects, like integrity and availability are much lower on the interest list of managers. So for the rest of the article we will focus on confidentiality of the data and credentials on the device.
Companies do seem to care a lot about this confidentiality and it has a huge impact on their buying behaviour: according to research performed by Symantec companies are even shying away from mobile solutions. Managers do care about mobile solutions as well: according to research by Pointsec around 60% of all managers think that their company might be harmed if a mobile device is lost. So there is an interest in reducing risks associated with mobile devices, even if they are company not owned. To do this in a realistic way measures shouldn’t be expensive, have minimal impact on the user experience and, if possible, be centrally enforced for every user. We do this by addressing each of the previously mentioned risks with standard functionality of the Windows Mobile platform or freeware.
Taking measures
The most drastic measure a system administrator can take is completely block all unknown devices from the exchange server. In Exchange 2003 this requires certificate based authentication, In Exchange 2007 specific users can be allowed/disallowed to synchronize with Exchange through the Exchange Management shell, and even the specific devices allowed can be specified. Although this might seem to solve your problem, it just gives you a false sense of security. People will still copy data onto their device using their desktop with ActiveSync as an in-between and still access the wireless networks with their PDA. In effect you have robbed yourself of your only chance of luring your users with honey into the position where the security measures can be taken and the benefits for the end-user still outweigh potential negative effects, making it a good balance for all stakeholders.
There are more subtle measures protecting company information and credentials. Luring the users into accepting a policy is relatively easy by using the honeypot of mobile e-mail, since almost 79% of the users wants this badly. In fact, this probably is the sole reason most people bought the device. So using the Exchange server as a honeypot, you can "force" people to accept the policy the Exchange server pushes upon them. The policy implemented should protect all the data-objects on the device when they are at risk: when data is at rest (stored either in the memory on the device) or when they are active during communication or device use.
As a system administrator you can force users to follow the most essential parts of a policy, regardless of it being a privately owned device, by setting policies for mobile devices in Exchange through cmdlets or through the GUI. In Exchange 2007 you can even set multiple policies which allows you to make distinction between different usergroups. These policies are pushed to any mobile device that connects to the Exchange server befor picking up any data. After that you can set the interval that the policy is checked by the device by setting the DevicePolicyRefreshInterval to the appropriate length. This construct allows you to ensure that all connecting devices will conform to the most basic level of security.
In the following part we discuss how much you control you can gain by using the Exchange server in order to fight your companies risks, as well as some hints to third party applications improve its shortcomings.
Data at rest
Theft, loss and unattended use are major threats to the information that is stored on a device. In case of theft or loss a "power-on" password can help you keep the data on the device confidential: it blocks access to the devices buttons, screen and input-ports completely until the password is entered correctly. So it offers a lot of protection to the on-device data, where only a complete hard reset of the device will make it usable for others. Activating the password does not even harm the user experience: alerts and calls still can be handled without any problem. Sadly, only a quarter of the users will voluntarily activate the PIN (password) protection.
Since the PIN/password is a very critical component in the Windows Mobile security model many policy options are available to make a security policy suit your needs. These settings include:
- AllowNonProvisionableDevices, allows the blocking or allowing of legacy devices (i.e. devices with Windows Mobile 5 AKU2 and before). This is typically set to false to guarantee that only devices that can be secured are allowed to connect to the Exchange server;
- DevicePasswordEnabled, this forces that some password/PIN protection has to be used. This generally is set to True to force users to have PIN or password protection.
- AlphanumericDevicePasswordRequired, specifying if a stronger alphanumeric password is required. This is typically set to false to allow for simple PIN numbers to be used, which generally has a higher user acceptance. It is worth the investment in time to check if a simple PIN does suffice for specific usergroups in your specific environment;
- MinDevicePasswordLength, defines the minimal length of a PIN-code (only applicable to Windows Mobile 6 and beyond devices). A basic minimum is 4, for more secure solutions a length of 6 or 7 digits is used;
- AllowSimpleDevicePassword allows users of Windows Mobile 6 and beyond to use weak passwords (like 1111 and 1234). This is typically set to false;
- MaxInactivityTimeDeviceLock defines the time interval on inactivity before the device requires a PIN/pssword to be accessed again. Typically set to 10 or 15 minutes. Please note that people might not like a password popup when the device is running on external power if they use car navigation solutions;
- MaxDevicePasswordFailedAttempts defines the number of failed attempts triggers the device in hard resetting itself, and (with Windows Mobile 6 and beyond devices) wiping the memorycard. This typically is set to 5 or 10.
By enforcing these policies before people gain access to mobile e-mail you can make the data and especially the credentials on a device a lot safer. So luring devices to synchronise with the Exchange server does provide you with an opportunity to gain some leverage and control over your users.
One should be carefull. Allowing the Exchange connection does introduce another way of entry into the company infrastructure. This is created by the feature that mobile devices with Windows Mobile 6 and beyond and combined with Exchange 2007 can also access SharePoint servers, using Exchange as an intermediary. If this is a desireable situation probably depends on the typical access levels these users have on the Sharepoint server and the access-measures that are already taken on the device (i.e. PIN/password settings and selfdestruct option). Mobile SharePoint access might be undesirable in certain environments, so disabling this, by setting the WSSAccessEnabled flag to false in the mobile device policy for the usergroup, might be a very wise decission for certain usergroups.
Hooking up devices to Exchange does provide another level of security. Devices that synchronize regularly with Exchange, or are even connected through push communication, gain the benefit of remote destruction of all data on the device. This can be done through Exchange, which allows administrators to initiate a so-called remote wipe. In Exchange 2007, the user can even initiate the wipe themselves, without the IT department being needed. So besides a thief possibly exceeding the maximum number of tries on the PIN, a system administrator or user can force the device to destroy all data as soon as it connects to Exchange. With push-communication this is almost instantaneous. This would be a very appropriate response if the administrator would be notified of theft.
Quick alerting of the IT department that a theft has taken place is a crucial part if you want to revoke certificates, change passwords and want to kill the device remotely. This proves to be quite a task when people consider the device to be just their personal property, without considering the business data and credentials on the device are at risk as well. Since there is no automatic alerting of potential indicators for theft (a hard reset or change of owner data), there is a high chance that the IT department finds out about a device theft through the occasional discussion at the coffee machine, instead of through proper channels. According to research only 18% of the managers think that device loss/theft would cause trouble for the company and only 10% of the managers believe they might hurt the company. As said: these people are not likely to contact the IT department directly if their device would be stolen. Although education and policies do help, there are technical ways to detect theft of devices quickly. Easiest one is a freeware tool like IIPWO, which sends an SMS if the device gets a hard reset or owner information is changed. Both are clear signs that the device is changing owner. More advanced solutions, like the commercial PhoneBAK, even provide customizable messages alerting you of a device ending up in the wrong hands.
But even with PIN and (remote) destruction of data, mobile data is at risk. The weakest link in any mobile device is the memorycard inserted in a mobile device. Although the device itself might be well-protected, the memorycard can be removed easily and read on a desktop. Given the limited memory of the device itself, a memorycard is quickly accepted by users to store e-mail attachments, word documents, spreadsheets and other data. Memory sizes keep expanding and are now around the 4 Gb to 8 Gb area for most types of memory. So the memorycard is the place containing the most company data but is also the least protected datastore. Unfortunately, policy controlled memorycard encryption can only be used on Windows Mobile 6 devices and beyond through setting the DeviceEncryptionEnabled flag in the mobile device policy in Exchange 2007. However, older devices are left in the cold. Even the Windows Mobile 6 implementation does leave something to be desired: the encryption keys can not be backed up, making hardware failure of the device catastrophic for the data as well. Also, the encryption does not encrypt files already present on the card and might slow down applications with large datafiles, like the very popular car navigation solutions. So some caution with this setting is needed. There are solutions for encrypting data on storage cards available, including free ones. These applications provide higher security levels for all devices, as well as better management capabilities, but it does require the users to be aware of them, install them and to use them explicitly with care, which might prove to be too much for most users.
Data in use
Mobile devices are not just static transport devices of data. They are actively used when people are on the move. So another potential threat to confidentiality of your data is when a device is actively used in an untrusted environment and sometimes communicates through public networks, communicating to other untrusted systems. First we look at viruses, followed by the various types of networks a Windows Mobile device is connected to: Bluetooth, WiFi and cellular networks.
When thinking about threats to a device while it is at use, one has to think about attacks on the device both from the outside as well as from trusted sources: the devices have become a true extension of the business network, in every way. Good thing about Windows Mobile devices is that currently there are no real viruses or Trojans active. This does not stop anti-virus companies from creating Windows Mobile virus-scanners, but currently they are not needed and might absorb way too many CPU power to be accepted by users. So from a virus-perspective Windows Mobile devices themselves are pretty safe.
There is of course the possibility that mallware has the form of a trojan that is installed by the user. There is the possibility to block any application from being installed by the user: the operating system allows for an administration password to be set, blocking installation of any application on the device. Also there is the possibility of only allowing signed applications to be used. Although both these solutions seem like a good idea on company owned devices, on personally owned devices they might limit user freedom too much resulting in a rejection of the policy altogether: people like to install thing s on their personal toy. Educating people about the dangers might be a better policy.
One should realize that mobile devices might be a way to infect the network: people do receive attachments on their mobile devices and copy them to their desktop, possibly creating a possible way to infect desktops. To prevent this from happening, you can block the downloading of attachments to Windows Mobile devices on the Exchange server. In Exchange 2003 this required some tricks with URLScan on IIS, in Exchange 2007 this simply is done by setting the AttachmentsEnabled flag in the Exchange ActiveSync policies to false, which blocks that attachments to be downloaded to the device. This way you can prevent Windows Mobile device in becoming a threat to your infrastructure. One should realize that this is a measure with a lot of impact: a lot of people buy the device to quickly read e-mails and the accompanying attachments. Turning the downloading of attachments off might lead for them looking for other ways to get these attachments, typically by bypassing your infrastructure altogether. Making sure that your desktop virusscanner scans files that are copied from Windows Mobile devices might be the best measure here.
Most Windows Mobile devices are equipped with Bluetooth. In practice most people leave it turned on to accommodate the Bluetooth headsets they use while driving their car. This is quite a safe setup as long as people turn off visibility of the device and require a PIN for accessing the Bluetooth ports: when Bluetooth is set up correctly pretty resistant to attacks and due to its limited range it is quite unpractical to use it as an attack vector. In practice most phone manufactures choose the setup that proves to be easiest to install as a default, with small warnings in their manual to make this safer. Practical experiments, like scanning for Bluetooth devices in my neighborhood on airports, learns that most people forget to turn off visibility or require a PIN. For most users it is a too complex task and one should help users with assuring that their setup is correct. Also some education might be needed, just to make sure people keep using the technology in the correct way.
WiFi isn’t a big suspect when it comes to outside attacks: most people turn off WiFi (automatically) when it isn’t used since it drains the battery. So firewaling or blocking it might not prove to be very efficient or popular amongst users. What is a big concern is the use of unknown WiFi access points while people are on the move, especially when they are abroad. On the road people simply use open access points they stumble upon or blindly trust a hotspot with a trustworthy name. This introduces the possibility of eavesdropping communication between a mobile device and the business servers by recording all traffic that passes such an access point. This is in fact a real scenario and one should take measures to prevent this. By requiring SSL-tunnels for communication with your business networks from the server-side, you effectively protect the communication with mobile devices against eavesdropping.
Most modern devices are connected to a cellular network as well, making the device semi-connected to the internet. What this means is that, although the connection is open, the hardware is only half-awake: it will only be active when the device is using the internet connection. The cellular connection does introduce a new vulnerability: Windows Mobile devices are capable of receiving MMS messages through a third-party component most OEMs include. MMS messages are frequently used to spread viruses (for other operating systems) and the third party MMS client used by most OEMs is vulnerable to attacks. Although there are no practical attack vectors known, it is an area of concern and it might crash the device into a hard reset. Easiest way to prevent any possibility of attacks is by turning off the reception of MMS messages completely. This can’t be done remote so this does require cooperation of the end user and physical access to his/hers device. Whether this acceptable to the end user, limiting the functionality of the device, is a matter of discussion between user and IT department which does have to take place.
Getting into this discussion and securing a device through on-device measures requires you to find out someone is using a (new) device in a company context, preferably before some harm comes to the device. This is in fact one of the huge secondary benefits of luring users into the Exchange connection: finding out who is synchronizing to the Exchange server is easy. By using a simple script, using on Get-MobileDeviceStatistics (Exchange 2003) or Get-ActiveSyncDeviceStatistics (Exchange 2007 and beyond), you can retrieve the mobile users and the device-ids they used. Auditing this on a regular basis might help you find and get in contact with these people, allowing you to proactively help them secure their data. Education, helping and the possibility to alert theses people is key to making these externally originated devices full and respectable citizens in your infrastructure.
Conclusion
This all combined makes the protection of data to guarantee confidentiality pretty easy: every device connected to the Exchange in effect becomes a trigger happy destructor underneath the company data. If the device isn’t operated by its rightful owner there is a high chance of the device wiping all data. The data isn’t just protected by a PIN/password, it is actively protected through the possibility of (remote) destruction, making brute force attacks infeasible and corrective action after theft thorough and efficient. This makes Windows Mobile devices in fact superior to USB sticks to transport data.
When the device is active it is quite invulnerable to attacks: due to its infrequent network communication behavior most attacks from a network to the device are simply impractical. There only practical attack vectors are the ones that use the push-capabilities of the cellular networks: MMS messages. By turning off that functionality altogether, you can achieve a device which is secure without sacrificing too much end-user comfort.
What is required is that you find and talk to your users and show them that they are allowed to benefit from the corporate infrastructure as long as they play by the rules, luring them into your security policy. By auditing the Exchange server regularly, you can identify new mobile devices and users and help them to protect their data, protecting your companies assets. When you do that, you can remove the devices from the grey area of tolerance, and get those devices into the controlled area of the IT department since they might not be your responsibility, but they still are your management’s security concern.
Comments
When running RapiConfig.exe, you must specify an XML configuration file that defines what actions to perform on the device. Visual Studio includes several sample XML provisioning files to perform the following tasks: