10 Steps for Auditing Mobile Computing Security

How to audit the security of mobile devices.

Editor's Note: IT Auditing: Using Controls to Protect Information Assets (Second Edition) authors Chris Davis and Mike Schiller (with Kevin Wheeler) provide a handbook for creating an organization’s IT audition function and for performing their IT audit. This excerpt examines the requirements for auditing the security of mobile devices.  

 



Test Steps for Auditing Mobile Devices

Several mobile device management (MDM) vendors hope to offer solutions to customers struggling to handle the explosive demand for smartphones. (Note that the MDM vendors are not the same as the handset manufacturers.) MDM solutions are designed to handle the management of smartphones created by the handset manufacturers, such as the Blackberry, iPhone, and Droid.

Established providers include Good Technology, Research in Motion (RIM), Microsoft, Motorola, and Sybase. We will cover some of the supporting company infrastructure required for their implementations, but we don’t go beyond this here. We don’t examine such components as e-mail servers or network equipment, which may or may not be in the scope of your audit. Consider other sections of this book as necessary if you want to expand the scope of the audit beyond the following steps, which conceptually follow closely to the steps in the WLAN audit with some slight changes.

Part 1: Mobile Device Technical Audit

Step 1: Ensure that mobile device management software is running the latest approved software and patches.

Running old software on the mobile device gateways may leave the gateways or remote mobile devices open to known attacks or prevent the organization from taking advantage of more robust security features.

How: Evaluate the gateway with an administrator, and verify that the code running on the gateway is the latest version. Verify that the latest version is correct using the manufacturer’s website or other similar updated source of information from the manufacturer. Examine the change-management processes around evaluating and maintaining current code releases for the APs. Note whether this process is automated and coordinated and whether it scales operationally across regional sites.

Step 2: Verify that mobile clients have protective features enabled if they are required by your mobile device security policy.

Many MDM solutions, including GoodLink and RIM (maker of Blackberry), both provide several client features such as password controls and remote or local wiping that can bolster your security should a device become lost or stolen.

How: Requisition a mobile device with an administrator’s help, and verify that it has the protective features enabled as determined by your mobile security policy or other agreed-on standard. If you don’t have a policy, we’ll suggest some components for a mobile security policy in step 7.

Some common features available with MDM solutions include enforced passwords, password settings, remote lock, remote wipe, and local wipe. Passwords can be set up to meet several different requirements in terms of length and complexity. Emergency calls to 911 should be allowed when configured to enforce passwords. Remote lock allows administrators to lock a lost or stolen mobile device until it is either found or a decision is made to wipe the device remotely. Wiping the device prevents an attacker from retrieving any data. The local wipe feature is designed to wipe the device if a user exceeds the maximum number of tries to log into it.

If you have the capability, you should evaluate the process a user would follow if his or her PDA phone were lost or stolen. Test these features to verify that your company processes work as designed and that all parties understand how to carry out the process.

Step 3: Determine the effectiveness of device security controls around protecting data when a hacker has physical access to the device.

This is an advanced step and would be performed with the help of your company’s computer forensic or security team. The subtle reason for performing this step is to help shed light on the need for security on mobile devices. The company’s e-mail server and global address book are accessible remotely on lost or stolen devices until the device account tied into the company network is deactivated.

How: In one large company, it was estimated by the administrator that wiping a device succeeds only about 20 percent of the time. One of the reasons for this is because users tend to wait too long before reporting that their devices have been lost or stolen. If users are not aware of what to do when they lose a device, a window of opportunity opens for someone with malicious intent to attempt to record data from the device. Waiting to raise a potential issue renders the remote lock and erase controls ineffective.

If you determine that you need to use forensic tools to test your controls, you need to state your assumptions clearly. You could, for example, give yourself a timeframe to pull data from a device before remotely attempting to kill the device. Assume that you have the ability to kill devices remotely, and assume that Faraday bags are not used by the attacker. Faraday bags prevent radio signals from reaching a device and lend an unfair advantage to an attacker. These bags might be used by a skilled, intentioned attacker, but they are not common. You can review the Guidelines on Cell Phone Forensics (SP800-101) located at http://csrc.nist.gov/publications/nistpubs/800-101/SP800-101.pdf.

The following additional controls may help to prevent physical access hacks. These must be turned on manually and should be in line with your policies.

  • Managed devices must be password-protected and erase themselves automatically after, for example, 15 incorrect password attempts.
  • Devices can be locked or erased remotely.
  • A password is required to read data on a mobile device.

Step 4: Evaluate the use of security monitoring software and processes.

Security monitoring and regular log reviews can reveal potential issues before a serious event occurs.

How: Speak with the mobile device administrator in an attempt to understand what’s being logged and how those logs are reviewed. It’s best to have an automated review process. Work with the administrator to understand whether these logs are useful; if they are not, determine what barriers exist to prevent them from being reviewed and delivering actionable data.

Step 5: Verify that unmanaged devices are not used on the network. Evaluate controls over unmanaged devices.

Unmanaged devices often contain sensitive personal and corporate data without the benefit of the security controls enforced on managed devices. This makes them easy targets for compromise when they are lost or stolen.

How: One method for discovering the number of potential unmanaged devices on your network is to look for the existence of the supporting desktop software on your systems. This doesn’t prove that an employee is actively using the device but suggests that at one point he or she tried to do so. You could use your endpoint management software, for example, to search for the existence of the executables associated with the desktop software used with the mobile devices. The reality is that this can be a very difficult step; however, it’s important to manage mobile devices on the corporate network.

Advanced controls might include a preventative control such as Network Access Controls that can prevent these devices from connecting to the network. Discuss detective and preventative controls with your administrator.

Part 2: Mobile Device Operational Audit

Step 6. Evaluate procedures in place for tracking end user trouble tickets.

Failure to establish ownership and tracking of end user issues could result in end users being unable to resolve connectivity problems.

How: End user issues should be tracked through a trouble ticketing system. An owner for these issues should be assigned and a group should be held responsible for tracking the progress to closure for any tickets opened because of mobile device issues. Discuss these processes with the administrator.

Step 7: Ensure that appropriate security policies are in place for your mobile devices.

Policies help to ensure compliance with a standard, help with repeatable processes, and allow the company to act against documented company violations.

How: Determine whether mobile device policies exist and whether the administrator responsible for the mobile devices knows and understands the content of those policies. Determine whether the policies are being followed or what barriers might exist to prevent them from being followed. Finally, ensure that relevant portions of the WLAN policies are communicated to employees that use the wireless network. A few common policy items might include the following:

  • You must use one of the defined and supported devices.
  • Synchronizing to your local workstation is allowed only with approved managed devices.
  • When available, antivirus and encryption tools should be used on your handheld device.
  • The password policy for handhelds that access the company’s Internet and/or e-mail systems is [defined policy].
  • After 15 failed password tries, the handheld must be erased automatically.
  • The device must time out after 30 minutes of inactivity.

Step 8: Evaluate disaster recovery processes in place to restore mobile device access should a disaster happen.

Failure to have appropriate recovery processes in place prevents a timely restoration of mobile e-mail access for users who must have it to conduct company business.

How: Restoring mobile device access may not be at the top of most people’s list following a critical disaster, but at least be some thought should occur around and procedures in place to facilitate this process. Discuss this with the administrator, and ensure that the recovery processes are in line with the expectations and standards of other recovery processes in the company. Depending on the use of mobile e-mail, this may be a critical component, such as with a large mobile sales force that depends on wireless mobile e-mail to conduct business and close deals efficiently. Other environments, such as those that use wireless e-mail to supplement existing and working wired infrastructures, may not view this as very important. This is a business risk that should be evaluated and measured appropriately when you review the mobile device security policies and BC/DR processes.

Step 9: Evaluate whether effective change management processes exist.

Change management processes help track and provide controlled changes to the environment. Controlled environments are more secure and have less impact on user productivity.

How: Discuss change management practices with the administrator as they relate to changing components in the environment that affect the infrastructure and especially changes that might affect the end user. Consider asking for evidence of a recent change and following through how the change was handled from start to finish, verifying that appropriate approvals were obtained and documentation created.

Step 10: Evaluate controls in place to manage the service life cycle of personally owned and company-owned devices and any associated accounts used for the gateway.

The service life cycle of devices is defined as the provisioning, servicing, and deprovisioning of devices over the period of time such devices are used at the company. The risk of not tracking a device through the service life cycle includes losing track of the device to an employee who leaves the company with sensitive information still on the mobile device.

How: Measures should exist to manage the service life cycle of the mobile devices managed by your company and the accounts associated with those devices. Discuss this with the administrator, and look for records supporting his or her statements. Walk through a recent provisioning and deprovisioning process with the administrator.


Excerpted from IT Auditing: Using Controls to Protect Information Assets; copyright 2011 by The McGraw-Hill Companies.  Used by permission of McGraw-Hill.