When a mobile device is lost or stolen, any business data it contains is jeopardized. Laws, such as California SB1386 (and similar laws introduced in 35 states last year), require companies to notify individuals whose private information may have been compromised. And businesses that violate industry mandates like HIPAA and GLBA face hefty fines or even jail time. But many companies cannot even enumerate the data carried by lost or stolen mobile devices.
A growing number of workers are using PDAs and smartphones to access business networks and applications. In the Nokia study, commonly-used mobile applications included e-mail, instant messaging, corporate database access, sales force automation, field service, CRM and ERP/supply chain applications. Companies without mobile-specific applications may still face mobile exposure through traditional applications. For example, many employees synchronize company e-mail onto PDAs or forward messages to smartphones. Therefore, if lost or stolen, these devices can be used to gain unauthorized access to an otherwise private network and applications therein.
Additionally, many mobile devices now support multiple wireless interfaces, creating new attack vectors. Mobile phones with Bluetooth can be "BlueBugged" (used by an attacker to place calls) or "BlueSnarfed" (accessed to retrieve contacts and calendars). Cradled PDAs can become Wi-Fi bridges into corporate networks. When used correctly, wireless interfaces can aid productivity, but safeguards are needed to prevent misuse or attack.
To manage these risks, companies need to define which mobile devices are allowed and under what conditions. They should place limits on network and application access, and on business data storage and transfer. Security measures and practices should be required, and processes defined to monitor and enforce compliance.
These decisions should be documented in a mobile device security policy -- a formal statement of the rules by which mobile devices must abide when accessing business systems and data. Such policies may include the following sections:
Objective: Identify the company, organizational unit and business purpose of the policy. For example, the intent of the policy may be to prevent disclosure of company-confidential data when transferred to or stored on PDAs and mobile phones, no matter who owns those devices.
Ownership and authority: Identify those responsible for policy creation and maintenance (development team), those responsible for policy monitoring and enforcement (compliance team), and those responsible for policy approval and management oversight (the policy's owners).
Scope: Identify the users/groups and devices that must adhere to this policy when accessing business networks, services and data. Enumerate the mobile device models and minimum OS versions allowed to access or store business data. Identify the organizational units that are (or are not) permitted to do so. For example, you may forbid business data storage on unapproved devices, or you may require users to register personal devices before using them for business.
- Risk assessment: Identify the business data and communication covered by this policy --
your company assets that may be placed at risk by mobile devices. For each asset, identify threats
impacts, taking into consideration both probability and cost. For example, when a mobile device
is lost, hardware replacement is probably just a small fraction of the impact. If your risk
assessment determines that data carried by a mobile device is more valuable than the device itself,
this may lead you to focus on data backup and confidentiality as your top priority.
More on mobile device security
Protect your organization from mobile threats
Find out where mobile malware threats are headed
Get best practices for protecting handhelds from mobile malware
- Security measures: Identify recommended and required mobile security measures and
- Power-on authentication to control lost/stolen device use
- File/folder encryption to prevent unauthorized data disclosure
- Backup and restore to protect against business data loss or corruption
- Secure communication to stop eavesdropping and backdoor network access
- Mobile firewalls to inhibit wireless-borne attacks against devices
- Mobile antivirus and IDS to detect and prevent device compromise
- Application and interface authorization to control program installation, network use, synchronization and data transfer to/from removable storage
For example, your policy may mandate authentication, specifying the minimum length and complexity for passwords and any applications that are excluded from authentication (e.g., accepting incoming phone calls without entering a password). Your policy may also define a process for mobile password reset that is convenient yet safe for users who cannot easily return to the office.
Acceptable usage: Define what users must do to comply with this policy, including procedures required for device registration, security software download and installation, and policy configuration and update. Enumerate best practices that users are required to follow, including banned activities. If users understand what they can and cannot do and why, they will be less frustrated and more likely to comply with stated policy.
For example, you may implement a mobile security system that automatically detects any PDA cradled to a corporate desktop. That system may prompt the user for self-registration and then push security software and policy onto the PDA. Your policy might explain this procedure and require that users cradle any purchased PDA to their office desktop before using it to store business data. It might also describe unauthorized use that will be blocked, like beaming business data over Bluetooth or copying data to removable storage.
Deployment process: Define how you plan to implement and verify your mobile security policy. It is a good idea to begin with a trial, taking both your mobile security software and defined procedures out for a test drive with a small group of users. Many security policies fail because they prove impractical to deploy or use. Working out these kinks before requiring everyone to follow your policy will increase voluntary compliance and overall effectiveness. Don't forget to include training for administrators and users in your deployment process.
- Auditing and enforcement: Voluntary compliance is nice, but insufficient for truly managing business risk. Effective policies ensure compliance through monitoring and enforcement. For example, you may adopt a mobile security system that checks for a correctly-configured security agent whenever a PDA or phone is synchronized over-the-air or cradled. Be sure to consider all points of network entry (e.g., e-mail server, VPN gateway, Wi-Fi AP, desktop PC cradle), and define a business process to deal with non-compliance and intrusion. Some mobile security systems can hard-reset devices that have been stolen or appear to be under attack, but your policy should clearly define the conditions under which this potentially destructive step will be invoked.
About the author
Lisa Phifer is vice president of Core Competence Inc., a consulting firm specializing in network security and management technology. Phifer has been involved in the design, implementation, and evaluation of data communications, internetworking, security, and network management products for nearly 20 years. She teaches about wireless LANs and virtual private networking at industry conferences and has written extensively about network infrastructure and security technologies for numerous publications. She is also the guest instructor for SearchSecurity.com's Wireless Security Lunchtime Learning.
This was first published in January 2008