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 organizations, whether it be a government department, an established company, or a startup. Most organizations have employees who use mobile devices, whether those devices are mobile phones or PDAs.
This article can help companies think through a mobile security policy that will work for their organization. It can also be useful to help individuals determine what level of security they're comfortable with for their devices.
Mobile device security should be very high on any organization's to-do list. Why? Because lots of organizations 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 is no longer just a personal device, but must be included in the organization's mobile security policies.
A lot of mobile device users will disagree with this idea, but the reason for this requirement is simple: if the device synchronizes with a work system, then the mobile device has corporate data on it such as e-mail, files, calendar items (which often include details of meetings), and even business contacts. Would it bother the company if the contacts and prospects of the company's top sales people were, for instance, to become available to the company's competitors?
What is a mobile device security policy?
Device-oriented security policies form the foundation of how the user interacts with the device and with 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 must also ensure that the device is password protected and that the password (and therefore the device) cannot be compromised by unauthorized users.
The policy mandates things such as password characteristics (length, how many unique characters must be in it, and what should happen if an incorrect password is repeatedly entered).
In short, a good security policy enables administrators to prescribe simple, manageable security steps, all based on the security requirements for the organization's data. These steps can then be distributed to devices as they are deployed or serviced.
Where do I start?
Begin by figuring out why you want to allow these devices in the organization. What uses can or should they be put to? Are they convenient, or a necessity? Are they marginal, or are they an integral part of how the company does business? Then, list the limitations you want on the spread of the company's data. Finally, turn these limitations into technical guidelines: this is the framework of the security policy.
The security policy is really technical guidelines that list the requirements that each device has to meet. The guidelines must be based on the bigger IT security policy of the organization. They're prescriptive, meaning they must be met, but they are high level and do not go into exhaustive detail for each device. Specific policies for each device can be drawn up in separate documents.
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: 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.
