A security policy is a document that defines how a given enterprise approaches the security of its IT resources. The scope here can be very broad indeed -- physical security, network security, information security, and (especially important for our purposes here) mobile device security. It's very important that a security policy be in place before any decisions are made as to specific solutions -- while basic security measures should always, of course, be operational, too often major and otherwise expensive upgrades are made before a real need for them has been established. A security policy therefore serves as a vital focal point for any enterprise or organization.
In general, a security policy defines what information is to be treated as sensitive (and therefore protected), who should have access to this information and under what conditions, and -- very importantly -- what to do when security is compromised (or even suspected of being compromised). From a physical security perspective, it should define who may have access to IT-specific areas of a given installation or building and how these areas are to be secured. But the following three elements are most important with respect to mobile security:
- Information security -- this defines what information should be treated as sensitive. I generally recommend adopting an approach similar to that used by the government, which is to have multiple levels of security with fewer people or groups
- having access as the classification level rises. For example, we might use a legend of "Company Confidential" for any data that is restricted to employees, and "Company Most Confidential" for that restricted to only certain employees. This policy might also restrict access to certain applications to authorized users only.
- Network security -- there are two key elements to the solution here, strong authentication and the encryption of sensitive data wherever it is stored. Note again that while a security policy will not usually define the actual solution in any given case, it will mention, for example, that two-factor and/or mutual authentication is required and that a VPN must be used when accessing the enterprise network remotely. It might even restrict the choice of a specific network to certain approved carriers.
- Device security -- Finally, this part of the policy defines how security is maintained on mobile devices outside the perimeter and otherwise outside the protection of the physical enterprise. It might restrict the ability of a user to install an application on the device, for example, and it might specify that mobile devices are to be backed up or virus-checked or that a particular firewall configuration might be required. I think that eventually so much will be required of mobile devices that they will simply need to be provided by the enterprise. There's no effective way to manage security -- or anything else, for that matter -- on a device that the company does not own.
Each of these areas can be affected by some kind of security breach, and the security policy defines what to do when a potential (or realized) security problem occurs. For example, a lost handset might involve little more than a phone call to the team that will remotely "zap" (erase) any sensitive data on the unit, while unusual network activity might involve shutting off remote access and waking an emergency response team.
Critical to the success of any security policy is the building of a culture of security within the organization. As with those "Loose Lips Sink Ships" posters from World War II, everyone entrusted with confidential information must always be conscious of the need to protect it. The stakes today are higher than ever (and I'll expand on this next time), so every effective policy must be backed up with an awareness campaign that includes training in both the policy and tools needed to implement and enforce it. And, again, while those tools are not necessarily defined in the policy, solutions must be convenient to use and simple enough that support costs will be limited.
Finally, keep in mind that a security policy isn't all you'll need -- the security policy will need to mesh with an acceptable-use policy and perhaps also with business continuity (integrity and availability) plans as well.
This was first published in May 2008