Forrester’s iPhone Article

Earlier this week Forrester released a paper on iPhone and Enterprise use.   That article was summarizedby Larry Dignan on ZdNet.   As a side note, I started to write on this earlier but wasn’t sure that I could legitimately quote from the article.   I guess it would be ok to quote small passages to critique.   But it’s fairly easy to start using too much.   I don’t need Forrester on my case over their $500 article.   I notice the article was updated 8/4.   I read the original Forrester article.

The thing to remember is these research company articles focus on feature sets.   Can you check the encryption box.    Can you require a pin.   Can you remote wipe.    While that is a good baseline, I’m worried about security not box checking.   Can you bypass the encryption still is first on my list.   So they bury security considerations deep within the article after spending half the article saying the iPhone 3.1 was secure enough.   No.   It wasn’t .   iOS 3.1 failed to fix the Zdziarski Method.   There was also the insecure backups in Zdziarski’s videos.   And then later there was the boot PIN bypass.    Lets not forget that Apple downplayed or denied these issues.   That’s just how they roll.

Andrew Jaquith equates iPhone security with PC security.   Yet denies that the phone needs any of the security software that a PC would have.   He says because people don’t worry about Cold Boot Attacks against Full Disk Encryption, they shouldn’t worry about encryption bypasses on the iPhone.    My FDE product claims to have protection in place against the cold boot attack.   Additionally, the FDE still protects against cold boot attacks when off.   Lastly, laptop computers are necessary.   Replacing the Blackberry with an iPhone is personal preference.   Thus different requirements are possible.  I would suspect a phone is much more likely to be lost, and now it s a candidate to be stolen as well.

The iPhone already found a home in organizations that don’t care about security.   What is supposed to allow us to sleep at night and deploy the iPhone is the new encryption.   Each App can now have a separate data container with its own encryption keys.   Check out Anthony Vance’s blog post .   Only Mail by default is encrypted this way.   Each app developer would have to specifically use it.   I wonder if a year from now we’ll have similar security issues as were found in ios 3.

I feel pretty secure about my corporate email inside a GoodLink on the iPhone.   But what other data will end up on this device?   Fortunately, the iPhone doesn’t seem to like our brand of EAP-GTC.   So it stays off our internal wireless.   We keep them off the ASA by not enabling it for access.  (I’m guessing that request isn’t far behind).

 I feel a bit offended by the tone that anyone stopping to evaluate the security of the iPhone must be a security idiot.   (even though they do go on to say that Corporations under strict regulatory control will need the stronger security of the Blackberry).

3 Comments

  1. Roger, thanks for taking the time to comment about my report. I have been reading your blog for about two years, and always appreciate your thoughtful analysis.

    Sorry you were offended by the tone of my iPhone/iPad security report. The report was meant to give those enterprises who are being asked to say “yes” to the iPhone a way to do so, by recommending policy options for securing the device. For most enterprises, that is what “security” means: being able to impose restrictions that keep the device secure, and protect their critical information. And in my judgement, the Apple devices support the key policies enterprises tell us they want. (Enforcing encrypted backups, by the way, is one such setting, although I didn’t mention it in the report). I was also very careful to describe when the iPhone and iPad fall short.

    As for the other definition of “security” that you hinted at — resistance to attack — iOS 4 improves on its predecessor. The application encryption features of iOS 4 will prevent a “side-channel” attack (such as Zdziarski’s method) from accessing information that has been encrypted by the application. I have reviewed Apple’s WWDC materials on application encryption and feel confident in that assessment. Today, application encryption is limited to mail, but frankly, that is the application most enterprises care about the most. I don’t have any inside knowledge about Apple’s plans, but we can reasonably expect that they will apply application encryption to other key apps like SMS and MobileSafari at some point in the future.

    • Wow! Thanks for the read Andrew and the comment. I struggled with that post. I hope I didn’t come across like a jerk.

      I talked with the I.T. Director today and without my prompting she had a similar reaction. We’ve been in seige mode since the iPhone 3. The VPs want their iPhone. We could just image what the VPs would be saying after they read that.

      I’m in the middle of an iPhone eval now. We require two factor authentication. I know securID works with ActiveSync, but that sounds like a mess to me. So we’re evaluating Good this month. we might even feel secure enough about good to allow personal phones.

      • Roger, no worries!

        It’s funny reading your comments about two-factor authentication. I was just talking to a financial institution about this. SecurID certainly ought to work, but it’s an invasive experience for the user. I am more intrigued by certificates — it seems like it would be a (theoretically) easier user experience because you can push certs down to the phone at enrollment time (or generate the via SCEP), then use them to authenticate.

        As you proceed in your evaluation, I’d be very interested in hearing what you find. You’ll probably want to look at MDM tools from Trust Digital, Sybase. If you would rather “roll your own” enrollment tool, you could customize the Apple-supplied script on this page: http://developer.apple.com/iphone/library/documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/profile-service/profile-service.html. (Click on the “Companion Files” link at the top right of the page to get the Ruby source.)

        Also: would you mind if I sent you an e-mail about Good? We are getting huge interest about this product, and I have a specific tactical question that I need a practitioner’s perspective on. :)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>