Tip

Defining your mobile security policy

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

    Requires Free Membership to View

  • 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.

About the author: Craig Mathias is a principal with Farpoint Group, an advisory firm, based in Ashland, Mass., specializing in wireless networking and mobile computing. The firm works with manufacturers, enterprises, carriers, government, and the financial community on all aspects of wireless and mobile. He can be reached at craig@farpointgroup.com.

This was first published in May 2008

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.