This tip is part of SearchSecurity.com's Data Protection Security School, Mobile device policy: How to prevent data theft. For more free lessons on essential concepts related to enterprise
information security and compliance, visit the SearchSecurity.com Security School main page.
Many large organizations recognize that securing mobile data is critical, but may be unsure how to rein in the wide variety of mobile devices that have access to enterprise data. A mobile device security policy is the first step toward regaining control over this business asset.
But how do you go about constructing an effective enterprise mobile device security policy? Let's look at where to start, what to include, and mistakes to avoid when creating a policy to protect your organization’s mobile data.
Mobile device security policy: Getting started
As with every kind of security policy, starting with a solid understanding of business objectives, threats, risks and their implications and effects can make all the difference.
First, enumerate mobile devices that might be carrying business data. Inventory the business data touched by or stored on those devices, classifying data by origin, use and sensitivity. In short, get a concrete handle on the assets the policy must help the organization protect and your business objectives for doing so.
Next, identify potential mobile data threats, the likelihood of each being realized, and resulting effects on business. For example, regulated data may be breached when an unencrypted device is lost; many businesses consider this a high-risk/high-impact threat. Data may also be breached by a mobile Trojan, resulting in a similar high-impact security event, despite typically being classified as a lesser risk.
In order to focus on threats of greatest risk and impact during your assessment, plot a grid with mobile data threat risk level on one access, and potential impact of a realized mobile data threat on the other. When doing so, it can be helpful to consult a standard risk assessment model such as ISO 27005 or NIST SP800-30.
Then, for each threat, identify possible compensating controls to reduce risk. (For a list of relevant threats and controls, consult NIST SP800-124.) In cases where residual risk is deemed acceptable, your policy may permit mobile data access while requiring specified controls. In other cases, mobile data access may be prohibited, but you must still identify how those policies will be monitored and enforced. These decisions will become the framework of your enterprise mobile device security policy.
Mobile device security policy: Putting policy onto paper
Having decided what your enterprise mobile device security policy will be, it’s time to document those decisions in a manner that is clear, concise, easily disseminated, implementable and enforceable. This might seem like common sense, but many policies are crippled by missing one or more of these elements.
There is no magic one-size-fits-all policy template that guarantees success, but effective policies do tend to include some common elements:
- Purpose: It is difficult for any organizational policy to achieve a business objective
if the policy's purpose is not clearly communicated. Briefly state why mobile device security is
important to your business – be that regulatory compliance, expense reduction or customer
protection – and how policy contributes to meeting those objectives.
- Scope: Characterize the mobile devices that fall within your policy’s scope, as well as
those that do not. For example, indicate whether the policy pertains to employee-liable and/or
corporate-liable devices and enumerate relevant device types (e.g., feature phones, smartphones,
tablets, eReaders, netbooks).
- Acceptable use: Lay out your conditions for accessing and/or storing business data on
mobile devices. For example, must employees explicitly consent to device monitoring, management,
wipe or physical surrender? What data does the employer own; what usage permissions are hereby
granted to mobile device users that comply with this policy?
- Policies: Enumerate mobile device (including mobile data) protection requirements,
including mandatory and recommended compensating controls. For example, specify device PIN or
password requirements, including minimum length, complexity, update frequency and inactivity
timeout. Specify acceptable encryption methods for data-in-transit and data-at-rest, including
scope of data to which they must be applied.
- Enforcement: Describe how you as the employer will monitor mobile device usage and
settings, and any steps taken to enforce policy compliance. For example, summarize conditions for
invoking remote wipe or revoking mobile data access, as well as HR/legal consequences.
- Responsibilities: Identify tasks that fall to the employer and employee with respect to
protecting mobile data. For example, who is responsible for backup and restoration? What (if any)
actions must the employee take, such as disabling desktop file sync or turning in a retired
(personal) device for rigorous data wipe.
- Definitions: Don’t assume users understand security or mobility lingo. Policies often use technical terms; define what they mean to you, in this context.
Templates and examples from other organizations can provide a generic framework for defining your own mobile device security policy. Here are a few to get you started:
- Guidelines: SANS Technical Writing for IT Security Policies in 5 Easy Steps
- Template: SANS Mobile Device Encryption Policy
- Template: NPower Northwest Mobile Policy
- Example: State of Illinois Mobile Device Security Policy
Mobile device security policy: Pitfalls to avoid
Of course, there are many mistakes that can result in an ineffective mobile device security policy. One sure-fire mistake is to craft a lengthy, jargon-filled policy that no one but the authors understand. Conversely, drafting a policy that institutes a few simple rules can fail just as badly, if those rules are impractical or impossible to implement or enforce.
For best results, involve stakeholders in policy definition from the start; this includes end users, device administrators, data owners, security staff, HR and legal. Don’t assume you know what data needs protecting; inventory representative devices, including employee-owned devices, and classify the business data found there. Focus policy development on meeting business objectives; avoid being distracted by personal data or data that poses little or no business risk.
When assessing risk and compensating controls, acknowledge that risk tolerance varies, even within a company. Breaking a workforce into roles can help you apply different rules to different users, without weakening your policy with numerous exceptions. In addition, don’t assume compensating controls can be implemented uniformly on all mobile devices. Instead, investigate the practicality and effectiveness of controls for each major device type/mobile OS, and specify default decisions for atypical devices.
Finally, test-drive your draft security policy, starting with a small but representative sample of users and mobile devices. Use your pilot to not only debug policy language, rules and compensating controls, but to also develop supporting processes for user education, device activation, technical support and remediation of non-compliant devices. In the end, what makes a policy effective is rarely limited to what has been documented on paper, but rather on how those decisions are put into action.
About the author:
Lisa Phifer owns Core Competence Inc., a consulting firm specializing in network security and management technology. Lisa has been involved in the design, implementation and evaluation of data communications, internetworking, security and network management products for over 25 years. At Core Competence, she has advised large and small companies regarding security needs, product assessment and the use of emerging technologies and best practices. Before joining Core Competence, Lisa was a Member of Technical Staff at Bell Communications Research where she won a president's award for her work on ATM Network Management.
This was first published in November 2011