Apple's Iphone and Ipad: Secure Enough for Business?

August 2, 2010 | Updated: August 4, 2010 Apple’s iPhone And iPad: Secure Enough For Business? by Andrew Jaquith for Security & Risk Professionals

Making Leaders Successful Every Day For Security & Risk Professionals

August 2, 2010 | Updated: August 4, 2010 Apple’s iPhone And iPad: Secure Enough For Business? Better Security Options Allow Enterprises To Finally Say “Yes” by Andrew Jaquith with Stephanie Balaouras, Ted Schadler, Benjamin Gray, and Lindsey Coit

EXECUTIVE SUMMARY Apple’s iPhone and the iPad have become increasingly popular. In 2007, IT dismissed the iPhone as insecure and unsuitable for enterprises. !ree years later, the iPhone (and iPad) gives enterprises enough security options to enable them to say “yes” instead of “no.” In this report, Forrester de"nes seven security policies every enterprise should implement to keep its email and corporate information safe on Apple mobile devices, whether or not the enterprise owns them. We also de"ne additional security “high-water marks” — policies and processes you can implement — based on your risk pro"le and regulatory exposure. Finally, we acknowledge that while most enterprises can use Apple mobile devices securely, some require higher levels of authentication assurance, resistance to attack, manageability, and logging than the iPad or iPhone can provide. For these customers, Research In Motion’s BlackBerry still rules the roost.

TABLE OF CONTENTS NOTES & RESOURCES 2 iPhone And iPad: “No” Is No Longer The Forrester reviewed interactions with 20 Automatic Answer enterprise customers, including seven Forrester 2 Deﬁne Your Security High-Water Mark Leadership Board members. We also reviewed documentation and tools from Apple, IBM, Seven Security Policies For Every Enterprise Microsoft, and Research In Motion. Higher-Assurance Security Options For Highly Regulated Enterprises Related Research Documents High-Security Policies For Company-Owned “Apple’s iPad Is A New Kind Of PC” Devices May 14, 2010 Red Herrings: What Not To Worry About Yet “Understanding Information Worker Smartphone 9 Limitations Of The iPhone And iPad Usage” What About Jailbreaking And Other Exploits? November 20, 2009

WHAT IT MEANS “Making iPhone Work In The Enterprise: Early 12 The iPhone And iPad Are Here: Get Used To It Lessons Learned” April 10, 2009 “Build Your Business’s Mobile Strategy Around Device Management And Security” July 22, 2008

© 2010, Forrester Research, Inc. All rights reserved. Unauthorized reproduction is strictly prohibited. Information is based on best available resources. Opinions reﬂect judgment at the time and are subject to change. Forrester®, Technographics®, Forrester Wave, RoleView, TechRadar, and Total Economic Impact are trademarks of Forrester Research, Inc. All other trademarks are the property of their respective companies. To purchase reprints of this document, please email [email protected]. For additional information, go to www.forrester.com. 2 Apple’s iPhone And iPad: Secure Enough For Business? For Security & Risk Professionals

IPHONE AND IPAD: “NO” IS NO LONGER THE AUTOMATIC ANSWER Consumer-grade portable devices such as Apple’s iPhone, the iPad, and smartphones running the Android operating system have become increasingly feature-packed, powerful, and portable. !ey have also become wildly popular, and many employees are bringing them to work.

!e decision to support the iPhone and iPad in your enterprise is an easy call: Your rank-and-"le employees want it, and your executives have likely already made many “special requests” to your IT team. With the introduction of the iPad, those calls are becoming louder and more plaintive. In this past quarter alone, for example, your analyst spoke with three mutual fund and wealth management "rms wanting to issue iPads to "eld sales and marketing personnel.

Apple’s mobile security posture has improved signi"cantly. IT initially dismissed the iPhone as unserious, insecure, trendy, and suitable only for consumers. !at was valid criticism in 2007 because Apple’s iPhone o#ered few enterprise email or security features. But three years later, with iPhone OS 3.1, Apple’s mobile devices provide enough security features that most enterprises can use them safely and securely. Today, 29% of North American and European enterprises support the iPhone — and by extension, the iPad.1

To be clear, the iPhone and iPad are not in the same class as Research In Motion’s BlackBerry — the gold standard for secure mobile devices. But depending on the levels of risk and regulation your enterprise faces, the level of security provided by the iPhone and iPad might well be acceptable for use as primary or secondary mobile devices. !is report recommends where to set the high-water mark — minimum levels of security that your policies should meet or exceed — based on your requirements. It also identi"es situations when these devices are not appropriate.

DEFINE YOUR SECURITY HIGHWATER MARK Secure management of the iPad and iPhone begins with technical policies that are applied to the devices. Both the iPhone and iPad run substantially similar versions of the Apple iOS operating system. As a result, IT and security professionals can manage both devices identically and can impose the same policy controls on them.2

Because every enterprise sets di#erent high-water marks for the level of assurance it is willing to accept, we have divided device security policies into two sections: basic policies that every enterprise should implement and optional policies for enterprises with higher security requirements (see Figure 1).

Figure 1 Setting The Enterprise Security High-Water Mark: Where Is Yours? wned owned e-o y- † 1 2 3 4 AA vel vel vel vel AR ompan Employe C HIP State data breach disclosure laws PCI IT SEC 17a-4* Le Le Le Le Owner Mandate NIST 800-63 High security policies Prohibit Apple App Store purchases For company-owned device; if employee- Block camera owned, use sparingly: No screen capture

Block YouTube or browser

Hide explicit content

Higher assurance Seven-character alphanumeric options device password For regulated Autolock after 5 minutes industries or risk-averse firms, Hardware encryption add any of these: (iPhone 3GS or iPhone 4, iPad) Application encryption (iOS 4 with iPhone 3GS or iPhone 4, iPad) Device certificate authentication Policy asserting right of confiscation Policy requiring address book scrubbing Basic security policies Six-digit device PIN Add all of these: Autolock after 15 or 30 minutes

Autowipe after four wrong PINs

Remote wipe

Email session encryption Signed, password-protected conﬁguration proﬁle Policy refresh Amendments to security policy *Not recommended for iPhone or iPad. Required Optional †Not possible with iPhone or iPad. 57240 Source: Forrester Research, Inc.

Seven Security Policies For Every Enterprise Regardless of industry, size, or regulatory climate, every enterprise thinking about supporting the iPhone or iPad needs to implement seven key security features and policies to safeguard company emails and data stored on these devices:

1. Require email session encryption. You should always encrypt email to and from iOS devices. Apple devices can enforce email session encryption via ActiveSync, an email synchronization protocol licensed from Microso$. Unmanaged devices (those that do not use ActiveSync) can also use SSL-enabled IMAP and SMTP over TLS.

2. Wipe devices if they are lost or stolen. If the device is lost or stolen, you can turn it into a brick by remotely wiping the contents. !e current models of the iPhone (3GS, 4) and iPad use a technique called “crypto-shredding” that can wipe the device in less than a second.3

3. Protect devices with a passcode lock. You should protect devices with a PIN (numbers only) or password (numbers and other characters). To be compliant with the password-strength requirements of the National Institute of Standards and Technology’s (NIST) 800-63 Level 1 authentication assurance standard, a "ve-digit PIN is the bare minimum (see Figure 2).4 You should never allow simple PINs like 1111 or 1234, and you should ensure that these PINs are not the same as your employees’ normal network passwords.5 For Level 1 assurance, we do not recommend alphanumeric passwords; they increase user interface (UI) complexity signi"cantly without adding much entropy.

4. Autolock devices a!er periods of inactivity. To protect against the possibility that an unauthorized person could obtain access to information while the device is unattended, devices should automatically lock themselves a$er a short time-out. Many enterprises require 15-minute inactivity time-outs; others feel that 30 minutes is more reasonable and hampers productivity less.

5. Autowipe devices a!er failed unlock attempts. You should con"gure Apple mobile devices to automatically erase themselves a$er several failed unlock attempts. !e number of failed attempts should be related to passcode composition and strength. Shorter or simpler passcodes need lower autowipe thresholds. For example, to achieve NIST Level 1 authentication assurance, you can use a six-digit passcode that isn’t a simple PIN, combined with a policy that autowipes the phone a$er four wrong guesses.6

6. Protect the con"guration pro"le. IT managers de"ne the enterprise’s email, encryption, PINs, autolocking, and other security controls by creating a mobile con"guration pro"le. You can sign the con"guration pro"les to ensure that no one has tampered with them, a precaution Forrester recommends.7 You can also protect pro"les with a password. !is ensures that an employee cannot remove the con"guration pro"le unless he or she wipes the device clean to factory defaults.

7. Continuously refresh policies. Although Apple mobile devices can integrate with company email systems and with open standard email protocols like IMAP/S and SMTP over TLS, these technologies don’t allow you to push company policies to the phone when it "rst connects or when you update them. Instead, Forrester recommends using ActiveSync to continuously enforce policies. When used with Microso$ Exchange 2007, for example, ActiveSync will automatically refresh policies for passwords, autolocking, and other settings every time the employee connects to the server.8 Lotus Notes Traveler doesn’t yet push updated policies as of version 8.5.1, but this feature is planned in the next release. Exchange 2003 doesn’t support policy refresh.

!ese seven Apple mobile device policies satisfy the basic security needs of most enterprises. Email is encrypted in transit. !e combination of a minimum PIN length, prohibition of simple passwords, and autowipe thresholds ensures that cybercriminals cannot easily guess passwords without forcing the device to erase itself. Autolock and remote wipe features ensure that company secrets are less likely to be disclosed when a device is lost or stolen. And "nally, policy removal prevention and refresh ensures that IT security policies cannot be circumvented and stay up-to-date.

In addition to these technical policies, enterprises should also add the following provisions to their employee acceptable use policies:

· Require installation of the organization’s security pro"les on the device as a condition of access to company resources.

· Require employees to notify IT if the device is lost or stolen or if the employee no longer needs connectivity to company resources.

· Assert the right to wipe the device if it is lost, stolen, or if the employee leaves the company.

· Require employees to keep backups of their Apple device using iTunes.

· Disclaim responsibility for break/"x support for the device, other than initial enrollment and policy installation tasks.

· Clearly state reimbursement policies, if any.

Figure 2 NIST 800-63 Level 1 Password Strength Requirements

Maximum allowed failed number of passwords allowed to yield 1:1,024 lifetime guessing likelihood

. . . when the minimum PIN or password length is: Strategy 45 68 Simple PIN Not possible 1 guess 2 guesses 8 guesses

PIN (not simple)* Not possible 2 guesses 4 guesses 19 guesses

Alphanumeric with special characters (84 possible keys) 1 guess 4 guesses 16 guesses 1,024 guesses

*Source: NIST, except for (*), which are Forrester estimates 57240 Source: Forrester Research, Inc.

Higher-Assurance Security Options For Highly Regulated Enterprises For some enterprises, the preceding core security policies don’t provide enough assurance. For example, an enterprise might deploy iPad applications that process protected health information (PHI) or nonpublic personally identifying information (PII). Security managers may also desire higher levels of authentication assurance than NIST 800-63 Level 1. In these cases, you should consider four additional con"guration pro"le settings:

1. Require stronger unlock passcodes. Enterprises can decrease the likelihood of guessing a device unlock passcode by requiring passwords that use letters and special characters. Requiring a seven-character alphanumeric password that also requires special characters and a four-failure-before-wipe threshold, for example, allows enterprises to achieve NIST Level 2 authentication assurance (see Figure 3).9

2. Use hardware encryption. Enterprises wanting an extra margin of safety for compliance with state and federal data breach disclosure laws can require connecting devices to support hardware encryption, which comes standard on the iPad, iPhone 3GS, and iPhone 4. An AES- 256 symmetric key protects the entire contents of the device.

3. Implement certi"cate-based authentication. Apple mobile devices can use device certi"cates for stronger authentication to email, VPNs, or Wi-Fi networks. !e certi"cates are created via SCEP (Simple Certi"cate Enrollment Protocol) when the policy is initially installed. Device certi"cates simplify the user experience because the certi"cate is used instead of the employee’s network password, which most enterprises force employees to change periodically. Certi"cate- based authentication requires an existing PKI and a SCEP server, such as the one that comes with Microso$ Server 2008 R2 or from third parties like Trust Digital, Sybase, AirWatch, or MobileIron. When combined with a strong password policy (for example, an eight-character alphanumeric password), certi"cate-based authentication conforms to NIST 800-83 Level 3.

4. Use application encryption (iPad and iPhone 3GS and 4, with iOS 4). Many highly regulated enterprises that have standardized on the BlackBerry have turned on its “content encryption” feature, which encrypts individual applications’ contents, such as email. !e 3.x version of Apple’s iOS did not support application-level encryption. But version 4 allows apps to encrypt data with keys that are protected with the device passcode — if the app has been written to require it. Apple’s own Mail app supports application encryption in iOS 4. !e new encryption APIs provides signi"cant bene"t to enterprise developers as well. Application-level encryption supplements any hardware-level encryption supported by the device.10 Note that the iPad won’t support iOS 4 until Q3 or Q4 2010.

In addition to these technical policies, enterprises may also want to add the following so$ policies to the company’s employee responsibility and acceptable use agreement:

· Con"rm your right of emergency con"scation. !e prospect of personal devices on company networks can pose di%cult legal challenges if expectations are not set upfront, particularly in the European Union. Enterprises allowing personally owned devices should require employees to turn over their devices in the event of a legitimate investigation. For example, the US Department of Defense allows employees to use personal BlackBerry devices in certain cases, provided that employees “agree to forfeit the… [BlackBerry] when security incidents occur and to follow all required security procedures and install required so$ware in order to protect the DoD network.”

· Require employees to scrub their address books. US state and federal statutes such as ARRA/ HITECH prohibit the storage of unencrypted protected PII and PHI on computing devices, including smartphones. Employers should require employees to remove from their address books any nonpublic PII or PHI that could be used to commit identity the$ or healthcare fraud. Data elements that should be scrubbed include medical insurance numbers, driver’s license numbers, SSNs, bank account numbers, and credit card numbers. In addition to taking the device out of scope of MA-201 and similar statutes, it reduces employees’ own personal risks. !is policy is particularly important if hardware encryption is not required.

Figure 3 NIST 800-63 Level 2 Password Strength Requirements

Maximum allowed failed number of passwords allowed to yield 1:16,384 lifetime guessing likelihood

. . . when the minimum PIN or password length is: Strategy 67810

Simple PIN Not possible Not possible Not possible 1 guess

PIN (not simple)* Not possible Not possible 1 guess 6 guesses

Alphanumeric with special characters (84 possible keys) 1 guess 4 guesses 16 guesses 128 guesses

*Source: NIST, except for (*), which are Forrester estimates 57240 Source: Forrester Research, Inc.

High-Security Policies For Company-Owned Devices Con"guration pro"les for iPhone and iPad can also enforce other security settings that some enterprises might want to consider in cases where the company itself owns the devices. However, Forrester regards these policy options as excessive for personally owned devices, and we recommend that you implement these policies only sparingly. Enterprises can:

· Prohibit the employee from accessing the App Store, installing apps, or both.

· Block use of the iPhone camera.

· Turn o# the screen-capture feature of the iPhone and iPad, which is normally invoked by pressing and holding the Home button.

· Prevent use of the YouTube application.

· Prevent use of the browser.

· Hide purchased content containing explicit content.

Apple mobile con"guration pro"les also support one additional policy option that enterprises should never need to use: passcode aging. Forcing employees to regularly change their device passcodes adds very little additional security, and it annoys them.11 Password aging for mobile devices doesn’t make passcode-guessing less likely; entropy requirements are already accounted for by the autowipe policy. Moreover, because mobile device passcodes are unrelated to network passwords, an attacker who successfully guesses an employee’s passcode cannot use it to access additional resources.

Red Herrings: What Not To Worry About Yet For a small, conservative minority of enterprise IT security professionals, increasingly powerful devices like the iPad and iPhone are just “PCs with an antenna.” According to this view, smartphones require exactly the same protections as general-purpose Windows operating systems do. !ese enterprises conclude that the lack of third-party security tools makes the Apple devices insecure and therefore unsupportable. !ese arguments are understandable but wrong. Here’s why:

· Antivirus and host "rewall so!ware is a waste of money. Many enterprises believe that all devices that touch their networks should run up-to-date antivirus, host intrusion prevention, and a host "rewall — including smartphones. But this is a red herring; the combination of Apple’s code-signing system, sandboxing, and its curated App Store (and their equivalents on the BlackBerry) eliminates the threat of malicious mobile code for the foreseeable future. Moreover, the devices don’t listen on any open network ports, making a "rewall unnecessary.12 Despite what incumbent security vendors might be telling you, mobile antimalware for the iPhone is neither inevitable nor desirable.13

· You don’t need data leak prevention. DLP vendors, and some enterprises, ask Forrester about whether DLP agents are needed for smart mobile devices. Today, they are not needed. In the case of the iPhone and iPad, corporate email is the only real source of risk. Fortunately, whatever is on the mobile device is already mirrored on the server. !us, enterprises interested in DLP for iPhones, iPads, and other mobile devices will be best served by deploying DLP on email servers instead.

· USB storage is not a signi"cant risk yet. Unlike the iPod, the iPhone and iPad cannot be used as user-mountable USB mass storage devices. !e iPad does have some rudimentary sharing features that allow documents to be synched between the employee’s tethered PC and the iPad device. If document the$ is a concern, PC-resident device control so$ware or DLP can be used to block the transfers. !at said, employees intending to steal documents will seek less convoluted methods than smuggling them out on their iPads. Using Web mail sites, posting to DropBox, or copying to uncontrolled USB sticks is much easier. IT security should worry about these much bigger risks .

LIMITATIONS OF THE IPHONE AND IPAD Forrester believes that current versions of the iPhone and iPad provide enough security options that many enterprises should feel comfortable using them in the workplace as secondary devices, and in some cases, as primary devices. But despite the many improvements Apple has made to the operating system since 2007, the iPhone and iPad still lack some key security and management re"nements that enterprises require:

· Distribution of con"guration pro"les. Apple’s own iPhone Con"guration Utility generates con"guration pro"les but doesn’t automate installation tasks. Popular mail servers like Exchange and Lotus Notes can use these pro"les but can’t generate them and have limited automation for over-the-air provisioning and device certi"cate generation. Enterprises are stuck with a certain amount of manual tuning and Web-site-building. !ird-party iPhone management tools from vendors like Sybase and Trust Digital (recently acquired by McAfee) provide much more robust pro"le distribution services.

· Mature enterprise device management tools. In versions 3.1 and earlier of iOS, Apple provided no API hooks that third-party mobile device managers could use to con"gure devices, collect events and alerts, or build inventories of running applications. iOS 4, announced on June 7, provides additional integration hooks that allow remote inventory, password management, and policy installation. However, Apple does not sell its own platform for enterprise mobile device management. Enterprises seeking to operate &eets of company-owned iPhones or iPads should not expect to see credible third-party mobile device management platforms that o#er these features until year-end 2010 or H1 2011.

· Support for smart card authentication. Highly security-conscious enterprises require very high levels of assurance (NIST 800-63 Level 4), and this requires using smartphones with strong authentication tokens. For example, RIM o#ers a smart card reader that can “pair” with the BlackBerry and a desktop PC to provide two-factor, smart card authentication. !e iPhone has nothing equivalent today.

· Compliance with FIPS 140-2. !e cryptographic so$ware modules used in the iPhone and iPad have not been validated by NIST for FIPS 140-2 compliance. For enterprises that require FIPS certi"cation for devices that use encryption, neither the iPhone nor the iPad will make the grade.

· Support for client email end-to-end encryption. Although the rising popularity of server- based DLP and encryption gateways makes the need for client-side encryption unnecessary, many enterprises still desire the capability to sign, encrypt, or decrypt email messages using S/ MIME or PGP. !e iPhone doesn’t support either of these technologies, unlike the BlackBerry.

· Susceptibility to a “lunchtime attack.” A well-publicized technique for bypassing the iPhone’s passcode protections and copying its contents was published in June 2009 by security researcher Jonathan Zdziarski.14 !e hack and accompanying disk capture operation takes about 20 minutes to perform and could be done, for example, while an employee is at lunch. !is puts the iPad and iPhones that haven’t been updated to iOS 4 roughly on par with PC laptops running so$ware-based full-disk encryption, which have been shown to be vulnerable to a “cold boot” exploit that can be mounted in about the same amount of time. Email is not vulnerable to this class of exploit if the device is running iOS 4 and the device has been protected with a passcode.

· Logging of SMS. Many customers regulated by Sarbanes-Oxley and rules like SEC 17a-4 require all communications from certain employees to be preserved, including SMS. Today, the iPhone has no capability for logging and archiving SMS messages.

· Separation of work and business environments. iPhones and iPads allow employees to access both their work and personal email accounts on the same device. But from IT security’s standpoint, this could be a problem. Commingling data from the two environments on the device means that an employee could, for example, cut and paste information easily from one environment to the other. Employees who bring their own devices to work, for their part, may not be comfortable with IT remotely wiping everything on the device, and not just work-related data. For these reasons, Forrester expects that many enterprises will rely on third-party products from vendors like Good Technology, which keep company emails, calendars, and contacts within a monolithic, password-protected application.

· Fine-grained application control. BlackBerry Enterprise Server policies can prohibit so$ware installation by employees and control which applications can run. By contrast, although an iPhone or iPad security policy can restrict employees from installing additional applications

and does allow companies to use “provisioning pro"les” for distributing their own signed applications, iOS does not have an application white list that allows "ner-grained control.

!ese shortcomings in iPad and iPhone security and device management features may be deal- killers for some IT security managers, especially those who appreciate the granularity of security controls for the BlackBerry.

What About Jailbreaking And Other Exploits? Ever since Apple shipped the "rst iPhone in 2007, intrepid security researchers have been engaged in a cat-and-mouse game with Apple to overcome perceived and actual restrictions on the iPhone’s capabilities, such as SIM-locking the iPhone to the AT&T network or prohibiting installation of any applications that Apple has not signed and distributed through the App Store. “Jailbreaking” is one such technique — it gets around Apple’s restrictions by disabling the code-signing mechanism the operating system uses to verify the authenticity of code.

!e iPhone has a limited attack surface compared with general purpose PCs. Most of the exploits, including jailbreaking techniques, target two areas: the browser and the device’s “recovery mode” that allows Apple to install updated "rmware. Zdziarski’s June 2009 exploit that disabled the phone’s passcode, for example, relied on a bu#er over&ow during the boot sequence. Rather than resulting in a jailbreak, Zdziarski’s method allowed an attacker to disable the device passcode and copy the iPhone’s entire contents.

Zdziarski’s method falls into the category of a lunchtime attack: not trivial, but easy enough that an attacker with a moderate level of skill could obtain unauthorized access to the phone’s data. We view the risk as being similar to the risk of a cold boot attack on so$ware-based full-disk encryption product used on PCs. !e cold boot attack is not hard to exploit, either, yet enterprises willingly bear the risk even though there is no "x to this well-known method.15

Apple argues that jailbreaking exploits are illegal under the Digital Millennium Copyright Act (DMCA).16 Nonetheless, there is no excuse for the coding &aws that make Zdziarski’s technique — or the related exploits that are involved in jailbreaking — possible. We expect Apple to "x the iPhone’s vulnerabilities in the normal course of its product cycle. !e newest version of iOS, version 4, o#ers signi"cant improvements to the encryption subsystem that should add signi"cant defense-in-depth. But in the meantime, employees need to understand that jailbreak-style exploits are a risk. !ey make iPhones less secure than the BlackBerry and about on par with a PC. !at will be good enough for many enterprises. For those enterprises that want greater assurance, the BlackBerry still can’t be beat.

W HAT IT MEAN S

THE IPHONE AND IPAD ARE HERE: GET USED TO IT The iPhone and iPad represent the first wave of post-PC devices poised to invade corporate infrastructures. After iPhone, Android awaits. How IT responds to the iPad represents a test of the organization’s readiness to embrace nimbler, decentralized computing that doesn’t conform to the generation-old PC paradigm. What it means: · The iPhone and iPad are secure enough for most enterprises. With the right policies and technical controls, you can operate Apple mobile devices at least as securely as the typical corporate laptop, without malware and with an insurance policy (remote wipe) against theft or loss. Higher-security options, such as mandatory hardware encryption, stronger authentication, and camera restrictions, give enterprises higher assurance when it is needed. These controls mean that the iPhone can be an approved “second smartphone,” and that the iPad is ready for business use. Enterprises that want to future-proof their data protection strategies should limit iPhones to the 3GS, 4, and iPad, which support hardware encryption and the significantly improved application encryption capabilities of iOS 4. Enterprises wanting to keep work and personal data separate should consider vendors like Good Technology. · High-security enterprises will stick with BlackBerry. Enterprises that require strong authentication or that must log all forms of mobile communications will find the iPhone security features lacking. These enterprises might choose to allow lower-risk, task-based workers to use the iPhone, but for most or all of their smartphone needs, they will stick with the tried-and-true, time-tested BlackBerry solution they already know. · Inability to close jailbreaks will limit Apple’s upside potential. Attention-grabbing exploits that compromise the integrity of Apple devices give enterprises excuses to stay away from the iPhone and iPad. Conservative companies won’t adopt products they feel are easily hacked. Apple should redouble its efforts to fix coding flaws in its bootloader and Safari browser in particular. To be successful, Apple should increase the time-to-compromise from minutes to days. · ActiveSync will become the BES-equivalent for Apple and Android devices. Microsoft has aggressively sought to license its ActiveSync mail and policy management protocol to mobile operating system makers like Apple and Google (client-side) and mail server vendors like IBM (server-side). Android’s implementation lacks some key policies that make it palatable in higher-assurance settings.17 Over time, though, Forrester expects that ActiveSync will become the preferred way that all non-BlackBerry devices access corporate email. · Post-PC application management will become the next battleground. With iPhone and iPad — and to a lesser extent, Android devices — technical controls have focused on email and whole-device controls like passcodes and remote wipe. After enterprises wrangle their employee-owned mobile devices into the compliance corral, they will shift their sights to applications. By 2013, curating and managing the delivery of mobile applications, not securing the devices, will be the next frontier.

ENDNOTES 1 Source: Forrester’s Workforce Technographics Survey, Q2 2009.

2 IT security policies are enforced by installation of con"guration pro"les onto mobile devices. Apple’s iPhone Con"guration Utility, Lotus Notes Traveler, or third-party products like MobileIron can generate the con"guration pro"les. A$er creation, IT can distribute them via email, the Web, or iTunes. Most commonly, however, IT downloads the pro"les to the device when it initially connects to an ActiveSync server, as implemented in Microso$ Exchange 2003 SP2, Exchange 2007 SP, and in Lotus Notes Traveler 4.5.1 and higher.

3 “Crypto-shredding” works by throwing out the decryption key for an encrypted device. !e iPhone 3GS and iPad both include full-device, hardware-based encryption, using a symmetric 256-bit AES key that is stored on the device. When the device receives the remote-wipe command, the key is deleted. !is renders the entire device unreadable because the contents cannot be read without the key. For a layman’s reports about remote wipe on the iPhone, read Andy Pedisich’s blog post. Source: Andy Pedisich, “What’s an iPhone hard reset do? Let’s try it out!” Andy’s Blog, October 24, 2009 (http://www.andypedisich.com/blogs/ andysblog.nsf/dx/whats-a-hard-reset-do.htm).

4 !e iPhone’s user interface changes slightly depending on whether the passcode is the standard four- digit PIN, a longer numeric PIN, or an alphanumeric password. When the policy requires the device to be protected with a numeric passcode that is longer than four digits, the UI changes to show a full so$ keyboard that allows alphabetic or special characters. However, if only numbers are actually used in the passcode, the unlock keypad screen will display just the numeric keypad. If alphabetic or special characters are used, the full so$ keyboard will appear. What this means: If an enterprise requires a "ve-digit passcode (but not alphabetic or special characters), employees will still see a fairly simple numeric entry screen when they unlock the device. We feel this makes longer PIN policies much more bearable; it is further evidence of the small UI re"nements Apple is well-known for.

5 !e US Department of Commerce’s NIST division issued a short report two years ago describing federal recommendations for using smartphones and PDAs in the workplace. Most of the guidance applies equally to PCs. Source: Wayne Jansen and Karen Scarfone, “Guidelines on Cell Phone and PDA Security,” National Institute of Standards and Technology, October 2008 (http://csrc.nist.gov/publications/nistpubs/800-124/ SP800-124.pdf).

6 NIST has published an extensive analysis of estimated password strengths based on their length and entropy. NIST Special Publication 800-63, “Electronic Authentication Guideline,” describes four levels of increasing authentication assurance, ranging from Level 1 to Level 4, the "rst two of which relate to smartphone policy directly. For Level 1 (low assurance), NIST states that the probability of success of a guess may not exceed one in 1,024 tries over the life of the password (with no entropy requirements). Level 2 (moderate assurance) is one in 16,384 tries (with 10 bits of entropy). Levels 3 and 4 require the addition of a one-time password or hard token, neither of which the iPhone or iPad supports directly. Source: William E. Burr, Donna F. Dodson, and W. Timothy Polk, “Electronic Authentication Guideline,” National Institute of Standards and Technology, April 2006 (http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf).

More information on user authentication is available from the IEEE. Source: Lawrence O’Gorman, “Comparing Passwords, Tokens, and Biometrics for User Authentication,” Proceedings of the IEEE, Vol. 91, No. 12, Dec. 2003 (http://www.google.com/search?q=Comparing+Passwords%2c+Tokens%2c+and+Biomet rics+for+User+Authentication).

7 In Lotus Notes Traveler, as of 8.5.1, con"guration pro"les cannot be signed.

8 Not all iPhone security policies are refreshed by Exchange, just those that apply to ActiveSync. Exchange 2003 doesn’t support policy refresh.

9 Longer or more complex passcodes, when combined with shorter auto-wipe thresholds, enable enterprises to increase password entropy to NIST 800-63 Level 2 recommendation for password strength. Level 2 speci"es a 1:16,384 lifetime chance of guessing a password. To achieve this level of assurance, a seven- character alphanumeric password can be combined with a four-tries-before-wipe policy.

10 Apple’s new encryption subsystem for iOS 4 signi"cantly improves on the one used in iPhone OS 3.1. In the older version of the operating system, the entire "lesystem of the device was encrypted with a single key. While this implementation enabled very fast remote wipes via crypto-shredding, it provided little protection in case the device was compromised, for example, at bootup or a$er a jailbreak. iOS 4 adds signi"cant defense-in-depth and application-level encryption functionally; this is similar to the BlackBerry’s “content encryption.” We expect Apple’s new hardware-assisted cryptosystem to enable encrypted data to stay encrypted, even if the phone itself has been jailbroken or compromised in a side-channel attack such as Jonathan Zdziarski’s.

11 Anne Adams and Martina Angela Sasse wrote an early analysis of how users rebel against the conventional wisdom about password policies: “Many users have to . . . use di#erent passwords for di#erent applications and/or change passwords frequently due to password expiration mechanisms. Having a large number of passwords reduces their memorability and increases insecure work practices, such as writing passwords down — 50% of questionnaire respondents wrote their passwords down in one form or another. One employee emphasized this relationship when he said ‘. . . because I was forced into changing it every month I had to write it down.’ Poor password design (for example, using ‘password’ as the password) was also found to be related to multiple passwords. ‘Constantly changing passwords’ were blamed by another employee for producing ‘. . . very simple choices that are easy to guess, or break, within seconds of using [a password] Cracker. Hence there is no security.’ It is interesting to note here that users, again, perceive their behavior to be caused by a mechanism designed to increase security.” Source: Anne Adams and Martina Angela Sasse, “Users Are Not !e Enemy,’’ Communications of the ACM, December 1999 (http://hornbeam. cs.ucl.ac.uk/hcs/people/documents/Angela%20Publications/1999/p40-adams.pdf).

For an alternative treatment of password security, read “Do Strong Web Passwords Accomplish Anything?” In this paper, the authors argue that rate-limiting password guesses can be a more e#ective alternative to password aging and other generally accepted “strong password” principles. !is is exactly the approach Apple has taken: A$er six failed attempts, the iPhone and iPad introduce successively longer delays (up to one hour) between attempts. Source: Dinei Florencio, Cormac Herley, and Baris Coskun, “Do Strong Web Passwords Accomplish Anything?” (http://www.usenix.org/event/hotsec07/tech/full_papers/&orencio/ &orencio.pdf).

12 For Forrester’s take on mobile security threats, read our blog post. Source: Andrew Jaquith, “!e Mobile Security !reat is Overblown: the complete post,” Andrew Jaquith’s Blog, April 7, 2010 (http://blogs.forrester. com/andrew_jaquith/10-04-07-mobile_security_threat_overblown_complete_post).

13 In the sense that 50% less battery life is undesirable.

14 Zdziarski’s technique relies on a bu#er over&ow when the iPhone is in recovery mode. It disrupts the boot sequence and allows an attacker who has physical possession of the phone to disable the device passcode and access its contents in unencrypted form.

15 !e “cold boot” attack against PC full-disk encryption products refers to a technique discovered by Princeton researchers of cutting the power to a previously booted device and reading the contents of RAM before it has a chance to dissipate. PCs that use a disk encryption product and are awake, on standby, or hibernating (but not turned o#) are at risk. !e cold boot technique has been used successfully against every so$ware-based FDE product, including Apple’s OS X File Vault and Microso$’s BitLocker. A short video posted to Engadget describes the technique. Source: Nilay Patel, “Cold boot disk encryption attack is shockingly e#ective,” February 21, 2008 (http://www.engadget.com/2008/02/21/cold-boot-disk-encryption- attack-is-shockingly-e#ective/).

16 See Apple’s statement to the US Library of Congress. Source: David L. Hayes, “Responsive Comment of Apple Inc. In Opposition to Proposed Exemption 5A and 11A” (http://www.copyright.gov/1201/2008/ responses/apple-inc-31.pdf).

17 Android 2.2 (Froyo) supports a limited set of ActiveSync policies: device password, local wipe a$er incorrect passwords, lock screen timer, and remote wipe. Notable missing policies include hardware encryption and camera restrictions. For a low-level look at Google’s progress on this issue read the thread on its Web site. Source: “Support for ActiveSync provisioning protocol” (http://code.google.com/p/android/ issues/detail?id=4475).

Headquarters Research and Sales Oﬃces Forrester Research, Inc. Forrester has research centers and sales oﬃces in more than 27 cities 400 Technology Square internationally, including Amsterdam; Cambridge, Mass.; Dallas; Dubai; Cambridge, MA 02139 USA Foster City, Calif.; Frankfurt; London; Madrid; Sydney; Tel Aviv; and Toronto. Tel: +1 617.613.6000 Fax: +1 617.613.5000 For a complete list of worldwide locations visit www.forrester.com/about. Email: [email protected] Nasdaq symbol: FORR www.forrester.com

For information on hard-copy or electronic reprints, please contact Client Support at +1 866.367.7378, +1 617.613.5730, or [email protected]. We oﬀer quantity discounts and special pricing for academic and nonproﬁt institutions.

Forrester Research, Inc. (Nasdaq: FORR) is an independent research company that provides pragmatic and forward- thinking advice to global leaders in business and technology. Forrester works with professionals in 19 key roles at major companies providing proprietary research, customer insight, consulting, events, and peer-to-peer executive programs. For more than 27 years, Forrester has been making IT, marketing, and technology industry leaders successful every day. For more information, visit www.forrester.com.

57240