It's almost trite to keep saying this, but your
- Device selection and provisioning: Tell people what devices are supported, and who is responsible for getting them set up properly. If you only plan to support BlackBerry devices, put this in the policy. If you have software that supports Symbian cell phones, make that clear so someone doesn't show up with a Palm phone expecting to use it. If you are going to only allow a subset of devices, make sure you have management backing for the policy, or you'll have someone who just can't live without their iPhone/BlackBerry/Android/Symbian device working against you. When you define a provisioning policy, you want to be clear what services are included. For example, you may wish to extend your office VoIP network services to smartphones to simplify call forwarding, dialing and presence services. That's a provisioned service, and should go into your policy.
- Device deployment and configuration: Explain exactly how devices are deployed, and what are the allowed configurations and applications. A common configuration requirement would be password protection on each device. Similarly, you may have specific applications you want to allow -- and some you want to forbid. You may decide that instant messaging applications are allowed, but only to the corporate encrypted IM server. When you define the deployment process, this will lay out who gets devices and under what circumstances. If you're going to allow people to go outside policy and buy their own devices, explain whether or not you're willing to support those and whether they can connect to the corporate network. Much of the mobile device policy on provisioning and configuration will depend on technology, such as a device management tool. For example, you may have decided to use Windows Mobile and Microsoft's management tools built into Exchange to push out common configurations, handle device wiping and locking, and manage applications on the devices. Even though it's a bad security practice to write the policy around the tools, it's also bad security practice to write a policy that you can't enforce. So keep your choice of tool and your policy in close synchronization -- make good use of the features offered by your tools, and don't require something that can't be done. Be explicit about how you will use that tool.
- Device use and policies around maintenance and loss: Presumably these devices are out there to help the organization, so your policy should be very explicit about what devices can -- and cannot -- be used for. It's not enough to state the rules in some obscure document; this is something that end users have to be educated about, and have to buy into. In this policy, describe the acceptable usage policy (AUP) and explain that everyone has to sign the policy -- not "sign" as in "scrawl a signature across it," but "sign" as in "really read, understand and agree to it." Since we know that devices will be damaged or lost, your policy should account for this and describe what should happen when someone is suddenly without their mobile device. Will you be keeping a spare on the shelf to express deliver? Do they go into the nearest phone store and buy a compatible replacement? Or if they lose the device, is that their problem to resolve? You should cover maintenance policies, replacement policies and any insurance requirements. Battery replacement, a particular issue in mobile devices, should be covered here: Who is going to pay for it, and how often?
- Device recovery and disposal: Portable devices have a shorter life than most IT assets, so after two to three years of solid use, they generally need to be replaced. Your policy should explain how often this happens, who gets to keep the old device (and under what circumstances), and the procedure for replacement. For example, properly wiping devices of all information (whether sensitive or not) is a very important policy requirement that should be explicitly stated.
This description of mobile device policy may seem intimidating, but you can short-circuit a lot of difficult discussions by getting one critical question on the table: "Who owns the device?" I'm not talking about who paid for it, I'm talking about who is in control of the device. Who makes the final decision on configuration and applications? If it's the organization, then say so, and make it clear that when push comes to shove, the person who decides what that device is used for, how it's set up, and what it can connect to is, well, you, or your boss, or certainly someone at the organization.
On the other hand, if the device is really controlled by the employee, and not by the organization, then be sure you describe what the device can't be used for: it can't have corporate sensitive data on it, for example, or really almost any corporate data at all, including email or contacts information. It can't connect to the corporate network, and it's not a replacement for a real corporate asset, such as a laptop.
I've worked with many organizations in this area, and the most important lesson I can offer is that you can't have it both ways: either the organization "owns" the device, in which case it can be used safely, or they don't. In which case, you can't make any assumptions about the safety or security of the device.
Once you get your policy laid out, you can continue on to the next steps: encryption of data in motion and data at rest.
Send comments on this technical tip email@example.com.
Join our IT Knowledge Exchange discussion forum; please use the midmarket security tag.
Join us on LinkedIn group.
About the author: This was first published in April 2010
Joel Snyder is a senior partner at Opus One, an IT consulting firm specializing in security and messaging.
This was first published in April 2010