IS Audit Basics: Auditing Mobile Devices

By the time this article is published, it will have been about 20 months since the US Federal Bureau of Investigation (FBI) unlocked the iPhone of the San Bernardino, California, gunman who killed 14 people.¹ The request by the FBI for Apple to build new software to unlock the mobile device resulted in strongly held opinions on encryption and backdoors on both sides² that have yet to be resolved. I have sympathy for all involved, but, as a technologist, I passionately believe that backdoors should not be developed. This conviction has been strengthened by the recent WannaCry³ and Petya⁴ attacks, which were developed using the leaked Shadow Brokers exploit, EternalBlue, which is generally believed to have been developed by the US National Security Agency (NSA).

Although a critical issue, this is not the focus of this column, nor is it something that we, as IT auditors, can influence on a day-to-day basis. However, an aspect of this case that received little or no coverage was the fact that San Bernardino County owned mobile device management (MDM) software that was not installed on the device.⁵ This would have allowed its IT department to remotely unlock the phone and, in my opinion, save the reputation of the organization in question. This is a risk that IT auditors can and should influence. So how can practitioners audit to help mitigate this and other mobile device risk scenarios?

In a previous column,⁶ I advocated the use of an ISACA paper on creating audit programs.⁷ This process can be applied to build an audit program for mobile devices for an organization.

Determine Audit Subject

The first thing to establish is the audit subject. What does a mobile device mean in the enterprise? If there are distinct types of mobiles devices in use, they should probably be recorded as separate audit universe items. ISACA categorized mobile devices (figure 1) in a 2012 white paper⁸ while an earlier white paper⁹ listed the type of mobile devices:

• Full-featured mobile phones with personal computer-like functionality, or smartphones
• Laptops and netbooks
• Tablet computers
• Portable digital assistants (PDAs)
• Portable Universal Serial Bus (USB) devices for storage (such as thumb drives and MP3 devices)
• Connectivity (such as Wi-Fi, Bluetooth and HSDPA/UMTS/EDGE/GPRS modem cards)
• Digital cameras
• Radio frequency identification (RFID) and mobile RFID (M-RFID) devices for data storage, identification and asset management
• Infrared-enabled (IrDA) devices such as printers and smart cards

In 2017, wearables, including smart watches, can certainly be added to that list. The key is to use the guidance to consider mobile devices in use at an enterprise and determine the audit subject(s). One needs to answer the key question: What is being audited?

Define Audit Objective

Once what is being audited has been determined, the objective of the audit needs to be established. Why is it being audited? From an auditor’s perspective, it is advisable to adopt a risk-based view and define the objectives accordingly.¹⁰

• Identify the risk associated with the devices (figure 2).
• Define objectives for each category or type of selected device; refer to information value and information risk. This is key.
• Focus on a limited number of audit objectives for a reasonable scope.

It is worth noting that although ISACA’s Securing Mobile Devices white paper considered the vulnerability of the enterprise not managing the device, it did not consider a San Bernardino County scenario. The lesson? Spend some time considering emerging risk scenarios.

Audit objectives should also correspond to security and protection goals as defined by the enterprise (figure 3).¹¹

Set Audit Scope

When the objectives of the audit have been defined, the scoping process should identify the actual mobile devices that need to be audited. In other words, what are the limits to the audit? This could include devices in a specific country, region or division; devices that are used for a specific purpose; or devices that contain especially sensitive data. Again, this should be risk based. Also, consider if personally owned devices (bring your own device [BYOD]) should be included.

Perform Pre-Audit Planning

Now that the risk has been identified (figure 2), it should be evaluated to determine its significance.

Conducting a risk assessment is critical in setting the final scope of a risk-based audit.¹² The more significant the risk, the greater the need for assurance. Assurance considerations for mobile devices include:¹³

• Policy—Does a security policy exist for mobile devices? Does it include rules for appropriate physical and logical handling? The enterprise should have a policy addressing mobile device use and specifying the type of information and kinds of devices and information services that may be accessible through the devices.
• Antivirus updates—Auditors should verify that the enterprise updates the mobile device antivirus software to prevent perpetuation of malware.
• Encryption—Auditors should verify that any data labeled as sensitive are properly secured while in transit or at rest.
• Secure transmission—Auditors should determine whether mobile device users are connecting to the enterprise network via a secure connection. VPN, IP Security (IPsec) or Secure Sockets Layer (SSL) can offer some levels of assurance.
• Device management—Auditors should determine whether there is an asset management process in place for tracking mobile devices. This asset management program should also detail procedures for lost and stolen devices as well as procedures for employees who have been terminated or have resigned from the enterprise.
• Access control—Auditors should verify that data synchronization of mobile devices is not set to receive access to shared files or network drives that contain data that are prohibited for mobile use by the policy.
• Awareness training—The auditor should verify that the enterprise has an awareness program in place that addresses the importance of securing the mobile devices physically and logically. The training should also make clear the types of information that can and cannot be stored on such devices.
• Risk—Mobile devices have the capability to store large amounts of data and present a high risk of data leakage and loss. As such, mobile device policies should be created and enforced to ensure that information assets are not exposed.

The use of any mobile device encompasses several legal relationships and obligations that must be considered when auditing or reviewing devices. In partial or full BYOD scenarios, further legal obligations may arise from the fact that parts of the mobile device (and information) are considered beyond the control of the enterprise.¹⁴ Furthermore, when the device is used for private purposes—even to a very small extent—questions of personal data protection and privacy will inevitably arise. In most jurisdictions, privacy is protected by law and additional regulations.¹⁵ If any doubt exists, it is prudent to seek legal advice in the relevant jurisdiction.

Finally, the auditee should be interviewed to inquire about activities or areas of concern that should be included in the scope of the engagement. Once the subject, objective and scope are defined, the audit team can identify the resources needed to perform the audit work.¹⁶

Determine Audit Procedures and Steps for Data Gathering

At this stage of the audit process, the audit team should have enough information to identify and select the audit approach or strategy and start developing the audit program.¹⁷ There is enough information to decide what documents are expected to be seen, what laws and regulations apply, the criteria and whom the audit team is going to interview. However, the testing steps do need to be defined.

In August 2017, ISACA released an updated version of its Mobile Computing Audit/Assurance Program,¹⁸ which defines testing steps for mobile devices. Some readers may have just thought, “Why did he not just state this at the beginning of the article?” I refer those readers back to this author’s first column.¹⁹ Audit programs should be considered a starting point and adjusted based upon risk and criteria that are relevant to the organization that is being audited. Failure to do so can result in a checklist approach, which can lead to the auditor recommending controls that are not applicable to the organization. This, in turn, can damage the auditor’s reputation with the auditee and, ultimately, with senior management.²⁰ It is worth spending the time considering the risk and the resulting need for assurance (figure 4).

Key testing steps in the audit program include password controls and the configuration of the selected MDM solution (if one is in place). Excellent guidance is provided on these and other aspects of mobility by the US Department of Defense (DoD) information systems Security Technical Implementation Guides (STIGs).²¹

Conclusion

As the uses, storage capabilities, power and proliferation of mobile devices have increased, so has the risk they pose to an enterprise. As a leading advocate for managing this risk, ISACA has produced several white papers in this area. Each of these documents is worth consulting to develop an audit/assurance program that is tailored to the individual enterprise. Failure to do so can result in a checklist approach, which can lead to a failure to mitigate key and emerging risk.

Endnotes

¹ Burgess, M.; “FBI Unlocks Shooter’s iPhone Without Apple’s Help,” Wired, 29 March 2016, www.wired.co.uk/article/apple-fbi-unlock-iphone-5c-court-order-dropped
² Elmer-DeWitt, P.; “Apple vs. FBI: What the Polls Are Saying—Updated,” Fortune, 23 February 2016, https://fortune.com/2016/02/23/apple-fbi-poll-pew/
³ Symantec Security Response, “What You Need to Know About the WannaCry Ransomware,” 12 May 2017, https://www.symantec.com/connect/blogs/what-you-need-know-about-wannacry-ransomware
⁴ Symantec Security Response, “Petya Ransomware Outbreak: Here’s What You Need to Know,” 27 June 2017, https://www.symantec.com/connect/blogs/petya-ransomware-outbreak-here-s-what-you-need-know
⁵ Finkel, J.; “Exclusive: Common Mobile Software Could Have Opened San Bernardino Shooter’s iPhone,” Reuters, 19 February 2016, www.reuters.com/article/us-apple-encryption-software-exclusive-idUSKCN0VS2QK
⁶ Cooke, I.; “Audit Programs,” ISACA Journal, vol. 4, 2017, www.isaca.org/resources/isaca-journal/issues
⁷ ISACA, “Information Systems Auditing: Tools and Techniques, Creating Audit Programs,” USA, 2016
⁸ ISACA, Securing Mobile Devices, USA, 2012
⁹ ISACA, Securing Mobile Devices, USA, 2010
¹⁰ Op cit, ISACA, 2012, p. 89
¹¹ Ibid.
¹² ISACA, Audit Plan Activities: Step-By-Step, USA, 2016
¹³ Op cit, ISACA, 2010, p. 9
¹⁴ Ibid., p. 91
¹⁵ Ibid., p. 94
¹⁶ Op cit, ISACA, 2016
¹⁷ Ibid.
¹⁸ ISACA, Mobile Computing Audit/Assurance Program, USA, 2017
¹⁹ Op cit, Cooke
²⁰ Ibid.
²¹ Department of Defense, Security Technical Implementation Guides (STIGs), USA, https://iase.disa.mil/stigs/mobility/Pages/index.aspx