Whether you are a personal user or a corporate employee, if you have a mobile device, you should either have a security policy of your own or be bound by a corporate one. Some users have an informal security policy, however many have no security policy at all and have not even thought through the security implications of owning a Pocket PC. The same is true of organisations, whether it be a government department or a corporate organisation or a startup company. There are very few organisations that don’t have a mobile device of some sort, whether it is a mobile phone or a PDA.
This article is designed to help organisations think through a mobile security policy that will work for their organisation. It will also be useful to help individuals consider how they want to manage security on their devices.
Mobile device security should be very high on any organisations to do list. Why? Because lots of organisations have users with smart mobile devices and the majority of these mobile devices have corporate data on them. In fact your default corporate policy regarding mobile devices should state that once a device syncs with any work system (server or desktop) it should be regarded as no longer being just a personal device and come under the organisations mobile security policies. That is assuming the organisation has a corporate policy regarding mobile devices.
A lot of mobile device users will disagree with this standpoint, but the reason for having this is that if the device synchronises with a work system, the organisation has to assume that the mobile device has some sort of corporate data on it such as email, files, calendar items (which often include details of the meeting), and even work contacts (which can be really good to start some social engineering to get corporate information).
What is a mobile device security policy and why do I need one?
Device oriented security policies form the foundation of how the user interacts with the device and the enterprise. If a device is mobile and contains corporate data, you need to be confident that the data on the device is safe even if the device falls into the wrong hands.
A corporate policy will consider encryption of the data on the device as well as the connections back into the enterprise. It will also ensure that the device is password protected and that the password and device cannot be compromised by unauthorised users.
The policy will make mandates such as a mandatory password, how long the password and/or pin is that the user needs to enter has to be, how many unique numbers are in the pin and what should happen if the wrong pin and or password is entered.
In short a policy will allow administrators to create a simple, manageable and repeatable security solution that is based on security requirements for the organisations data. This can then be distributed to devices as they are deployed or as they are serviced.
Where do I start?
To kick off the security policy, start by figuring out why you want to allow these devices in the organisation. With this information, write down the limitations you want on the spread of the organisations data and then turn this into technical guidelines using the considerations outlined in the rest of this article.
The security policy is really technical guidelines and should be the requirements that each device has to meet. The guidelines must be based on the bigger IT security policy of the organisation and are prescriptive meaning they must be met, but they are high level and do not necessarily have to detail the mechanics of setting up each device. This level of detail could be a separate document or perhaps even a document for each device type approved for use.
When you write the security policy, disregard whether the technology can support it or not. Once the guidelines are finished, evaluate security solutions to fit the guidelines and if necessary adjust your guidelines after you have done this evaluation. If your evaluation reveals that there is no way to meet the guidelines, then you will need to consider whether you should disallow mobile devices or change your guidelines. This decision should be based on risk and needs to be discussed at a business level, not a technical level.
The following sections are points that should be covered in the security policy.
Authentication onto the device
A major part of the security policy is authentication onto the device.
On a standard device you can have either a simple four digit pin or a more comprehensive password. You can also set the timeout to zero (meaning you must enter the password each time the device is turned on). This is certainly better than no security at all, however, if the device is lost or stolen an unauthorised user has unlimited attempts at guessing the password, making it technically possible to brute force their way into the device.
Also, the default functionality is simple meaning a user could simply have a pin of 0000. Simple pins are simple to crack.
To prevent compromise, consider a third party product to enhance the password management options. Third party products can require cooldown periods after invalid password attempts, hard reset the device (reset to factory) in the case of password failures and manage and even require a password changes on the device.
A cool-down period prevents an attacker from attempting to enter a password for a specified period of time. If you set the cool-down period to increase the period of time with each group of invalid attempts, it becomes very inconvenient to brute force your way onto the device.
Remote destruction and disabling
Some solutions available today have the ability to remotely destroy the device. This can be a handy feature to have, but it should not be relied upon for security when the device is lost or stolen. To understand the issues around this, lets consider each of these two scenarios.
A stolen device obviously presents a security threat from both a device and a network perspective since the device will not only hold corporate information such as documents and email, but it is very likely to hold network authentication information as well, meaning that if an attacker steals the device, they not only have access to the corporate data, but possibly to enterprise infrastructure (such as file and application servers) as well. If they have this information, mounting an attack on the network is relatively trivial. To protect against this you could use a remote destruction facility to remotely hard reset the device, wiping all data on the device as well as any configuration information.
However, relying on a remote destruction system is not sound security. Why? Firstly, the device may be disconnected and not able to receive the command and there are a wide variety of reasons why the device may be disconnected. The thief may remove the SIM card (if it has one) or swap the SIM. The device may be out of range of the cell site or WiFi network, the battery may be flat, the device may be connected to a different data network or is connected via a different user name, it may simply have had the radio stack turned off, what ever the reason, there are simply too many variables to be able to guarantee that a remote reset command will work - therefore you cant rely on it.
If a device is lost, it is in unknown hands. It may be down the back of a seat, left on a train or just sitting in a jacket pocket. With remote destruction, it is really easy for the user to call the administrator to request to have the device reset, however, if the device is reset (assuming the wind is blowing in the right direction and the device is connected to the correct data network), and the device is found then the user is without a device until it is reconfigured by the administrator. If the user is in another country or even city, this can be a serious inconvenience.
A better way of managing device destruction is to use a security application that will automatically destroy the device and all it’s data when an incorrect pin is entered. This ensures that the data on the device is only lost in a valid situation - i.e. when unauthorised entry has been attempted. This would not happen when the user has the device as they know the password. Nor would it happen when the device was lost - only when an attempt is made by an invalid user - i.e. when the device is lost and picked up by a third party or stolen.
Software like SOTI MobiControl can help define and distribute a security policy
Backup and restore
Of course if the device can be lost or stolen we should have means to restore the information (or part of it) onto another device. Backup and restore procedures must be define, and more importantly, followed. Most Pocket PC devices come with backup and restore programs. Even a simple file copy and PIM synchronisation to a desktop or laptop is better than not having the data replicated at all.
The policy should determine when the data is copied, frequency and also make sure the copy is protected as well as the original data.
Storage cards are great as a way of expanding the capacity of the on-board memory, but they are also portable and therefore an additional security risk. Consider locking down access to storage cards by either encrypting them or disallowing them. Again products are available to restrict access to storage cards or encrypt them.
If you write up a policy to restrict access to certain capabilities or applications, you also need to consider how a user might work around the restrictions by installing additional software. There are two approaches to application lockdown. The first is to deny access to specified applications. This is useful for removing access to some applications by the user, however, if a user installs a competing or alternative product the restriction becomes ineffective. The second approach to this problem and a better one in my opinion is to set a list of allowed applications and limit the user to those. Either way you need to think through these restrictions carefully. If a user has the ability to rename a file either on the devvice or via ActiveSync, they may be able to circumvent this protection by renaming a normally disallowed application to an allowed one.
Finally you must,consider the ways information can get on and off the device and protect these facilities. Most new devices will include one or more of BlueTooth, WiFi, Cellular data, Infrared, storage cards and good old ActiveSync and RAPI connectivity. Your security policy should include whether these items can be enabled or disabled and whether things like Bluetooth should be discoverable if it is allowed to be on.
For local connections, ensure that you consider the risk of unauthorised applications such as games being installed to the device and how these applications can be managed or restricted.
Network protection needs to cover both remote access to the device as well as the method used to connect to corporate data.
If connectivity is over a network, you must consider the security of the network. In your considerations, make sure you consider whether the network connection can be trusted or not - i.e. a private access controlled network or a publicly available network. If the network cannot be trusted, then you must restrict the services available on that network to those which you deem to be safe for such a network.
Firewalls are good for protecting the device from outside attack on a PC, however, their usefulness on a Pocket PC is limited because there are simply no services available by default to attack. However, if you have deployed a custom built application on your device which exposes a service or you have installed a web server or similar, then you will want to consider a firewall to protect these services. Beyond these, the biggest risk of attack is going to be a denial of service attack and I suggest that you need to consider if the risk associated with this warrants the price of the software to protect you.
Software firewall for Pocket PC are now appearing
Who do you trust?
As PDAs are personal devices (hence the “Personal” in Personal Digital Assistant), much of the practicalities around their use in the enterprise will revolve around the level of trust that that person has in the organisation. Therefore - how much do you trust your employees? Do you strictly enforce standards with software and security systems or do you lighten up and enforce simple password protection and data encryption and leave the user to use whatever applications they choose? Of course this depends on the sort of data your organisation works with and how the devices will be used and by whom.
Having created your security policy, you may find that no single application suits all your needs. For example, you might find that the device security works well with one product, but it does not lock down application access adequately. Be prepared to use a hybrid solution and make sure you test them thoroughly together.
If this all seems a bit much, don’t be afraid to ask for help. It is better to get some help and spend some money than suffer a security compromise that may leave the organisation in a position where it can no longer function effectively or efficiently due to a lack of customer trust, public humiliation or worse.
Each organisation is different and will have different data and therefore security needs. This article is not designed to be an exhaustive list of considerations, but it should provide a solid starting point.
Below is a list of software or services that can help you implement the security policies defined by your IT department – or yourself. These are just pointers. There are many more software and services available in the market.