{"id":1091,"date":"2010-02-21T10:39:02","date_gmt":"2010-02-21T18:39:02","guid":{"rendered":"\/?p=1091"},"modified":"2010-02-21T11:15:57","modified_gmt":"2010-02-21T19:15:57","slug":"enterprise-lockdown-versus-consumer-applications","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=1091","title":{"rendered":"Enterprise lockdown versus consumer applications"},"content":{"rendered":"

My friend Cameron Westland, who has worked on some cool applications for the iPhone, wrote me to complain that I linked<\/a> to iPhone Privacy<\/a>:<\/p>\n

I understand the implications of what you are trying to say, but how is this any different from Mac OS X applications accessing the address book or Windows applications accessing contacts? (I'm not sure about Windows, but I know it's possible on a Mac).<\/p>\n

Also, the article touches on storing patient information on an iPhone. I believe Seriot is guilty of a major oversight in simply correlating the fact that spy phone has access to contacts with it also being able to do so in a secured enterprise.<\/p>\n

If the iPhone is deployed in the enterprise, the corporate administrators can control exactly which applications get installed. In the situations where patient information is stored on the phone, they should be using their own security review process to verify that all applications installed meet the HIPPA\u00a0 certification requirements. Apple makes no claim that applications meet the stringent needs of certain industries – that's why they give control to administrators to encrypt phones, restrict specific application installs, and do remote wipes.<\/p>\n

Also, Seriot did no research behavior of a phone connected to a company's active directory, versus just plain old address book\u2026 This is cargo cult science at best, and I'm really surprised you linked to it!<\/p><\/blockquote>\n

I buy\u00a0Cameron's point\u00a0that the controls available to enterprises mitigate a number of the\u00a0attacks presented by\u00a0Seriot – and agree this is\u00a0 important.\u00a0 How do these controls work?\u00a0 Corporate administrators\u00a0can set policies\u00a0specifying\u00a0the digital signatures of applications that can be installed.\u00a0 They can use their own processes to decide what applications these will be.\u00a0<\/p>\n

None of this depends on App Store verification, sandboxing, or Apple's control of platform content.\u00a0\u00a0In fact it\u00a0is\u00a0no different from\u00a0the\u00a0universally available ability to use a combination of\u00a0enterprise policy and digital signature to protect\u00a0enterprise desktop and server systems.\u00a0 Other features, like the ability for\u00a0an operator to wipe information, are also\u00a0pretty much\u00a0universal.<\/p>\n

If the iPhone can be locked down in enterprises, why\u00a0is Seriot's paper still worth reading?\u00a0 Because many companies and even governments are interested in developing customer <\/em><\/strong>applications that run on phones.\u00a0 They can't dictate to customers what applications to install, and so lock-down solutions are of little interest.\u00a0\u00a0They turn to\u00a0Apple's own claims about security, and\u00a0find statements like this one, taken from the otherwise quite interesting iPhone security overview<\/a>.<\/p>\n

Runtime Protection<\/strong><\/p>\n

Applications on the device are \u201csandboxed\u201d so they cannot access data stored by other applications. In addition, system files, resources, and the kernel are shielded from the user\u2019s application space. If an application needs to access data from another application, it can only do so using the APIs and services provided by iPhone OS. Code generation is also prevented.<\/p><\/blockquote>\n

Seriot shows\u00a0that taking this claim at face value would be risky.\u00a0\u00a0As he\u00a0says in an eWeek interview<\/a>:<\/p>\n

“In late 2009, I was involved in discussions with the Swiss private banking industry regarding the confidentiality of iPhone personal data,” Seriot told eWEEK. “Bankers wanted to know how safe their information [stores] were, which ones are exactly at risk and which ones are not. In brief, I showed that an application downloaded from the App Store to a standard iPhone could technically harvest a significant quantity of personal data \u2026 [including] the full name, the e-mail addresses, the phone number, the keyboard cache entries, the Wi-Fi connection logs and the most recent GPS location.”\u00a0<\/p><\/blockquote>\n

It is worth noting that Seriot's demonstration is\u00a0very easy to replicate,\u00a0and doesn't depend on silly assumptions like\u00a0convincing the user to disable their security settings and ignore all warnings.<\/p>\n

The points made about banking applications apply even more to medical applications.\u00a0\u00a0Doctors are effectively customers from the point of view of the\u00a0information management services they use.\u00a0 Those services won't be able to dictate\u00a0the applications their customers deploy.\u00a0 I know for sure that my doctor, bless his soul, \u00a0doesn't have an IT department that sets policies limiting\u00a0his ability to\u00a0play games or buy stocks.\u00a0 If\u00a0he starts using\u00a0his phone for patient-related activities, he should be aware of the potential issues, and that's what MedPage was talking about.<\/p>\n

Neither MedPage, nor CNET, nor eWeek nor Seriot nor I are trying to trash the\u00a0iPhone – it's just that application isolation is one of the hardest problems of computer science.\u00a0 We are pointing out that\u00a0the iPhone\u00a0is a computing device like all the others and subject to the same laws of digital physics, despite\u00a0dangerous mythology\u00a0to the contrary.\u00a0 On this point I don't think Cameron Westland and I disagree.<\/p>\n

\u00a0<\/p>\n","protected":false},"excerpt":{"rendered":"

Application isolation is one of the hardest problems of computer science<\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[67,63,13,64],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/1091"}],"collection":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/users\/68"}],"replies":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1091"}],"version-history":[{"count":0,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/1091\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1091"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1091"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1091"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}