Monday, November 19, 2012

An Identity standards-based Model for Mobile Application Security


What are the identity requirements for securing employees access to business applications on mobile devices? What identity standards are relevant?

I’ll present a model for the above in this and subsequent posts.

At its most basic, the model proposes using 3 identity standards (SAML, OAuth, & SCIM) between the enterprise and the MAM (Mobile Application Management) & SaaS Providers – thereby allowing the enterprise to extend it’s purview out to the MAM (and subsequently) the SaaS Clouds.

Caveat -  today’s MAM solutions do not (AFAIK) follow this model. But there are indications (from discussions we at Ping Identity are having with them) that some providers see the value.

Actors


First, who are the actors.
  •  Enterprise – wants to control employee access to relevant business applications & corresponding data.  Does NOT want the corresponding security controls to overly interfere with employee’s ability to do work. The enterprise holds the authoritative identity for a given employee in AD or equivalent.
  • MAM Provider - enforces enterprise security policy with respect to how employees use devices to access business applications . Comprised of 
    • Cloud endpoints, behind which sit the MAM policy (and maybe business apps) to be pushed down to the device installed agent
    • Device installed agent, enforces the MAM policy and so keeps business data on the device protected & sandboxed
  • SaaS Applications – offers up some service to enterprise employees. Comprised of
    • Cloud endpoints, behind which sit the application data – accessed either via a web interface or via a native application. Note: although labelled here as ‘cloud’, the principle is the same for on-prem endpoints, ie for custom enterprise native apps interacting with on-prem endpoints).
    • Native versions, OS native applications that interact with the corresponding cloud endpoints to pull down application data, for local display & manipulation
    • Web versions, accessed via device browser (while the relative importance of web & native may change in near future with HTML5, both are likely to co-exist. So our model must support both.)
Graphically, see below. The native applications & MAM agent are installed on the device (as well as the browser), they interact with their corresponding server endpoints – these interactions acting under the control of the enterprise via the access control, encryption, etc mechanisms provided by the MAM solution.


The fundamental interaction is between the native applications ( labelled as 'SaaS1' and 'SaaS2') and their corresponding cloud. The challenge is to ensure that that the employee be able to use those applications in order to do their job and that those interactions are secure (authenticated, confidential, etc). The MAM agent on the device, driven by policy from its own corresponding Cloud, will enforce security policies.

Goals


At the highest level, I believe the enterprise has the following goals for mobile - it wants to ensure that
  1. Valid employees can access the applications (and associated data) relevant to their role from their device and so be productive & content.
  2. Nobody else (neither family, colleagues borrowing the phone, the well-meaning stranger who finds the phone in a cab, or a malicious hacker) can access those applications (and associated data) if they get their hands on the device.
  3. The controls of #2 do not inappropriately impact the employee’s personal applications & data on the device , ie  respect the employee’s privacy.
Note: I contend that the above (even the last) are valid whether the device is owned by the enterprise (a COPE model) or the employee (BYOD).  Consequently, ownership is mostly a red herring (or at least an orthogonal issue) when thinking about securing mobile applications.

The first goal above is satisfied by giving employees convenient access into both the:

1.     Web version of the business applications
2.     Native versions of the business applications

Of course, ultimately the enterprise cares less about employee convenience than about productivity. But there is of course a correlation between the two – if you make it convenient for employees to access business applications, then you don’t prevent them from using those applications to sell widgets, review iPads, create Venn diagrams, or whatever it is they do for you.

The second goal can be satisfied by ensuring that the above access to applications & data, while convenient, is also secure, ie
  1. only valid employees can access applications & data
  2. valid employees can only access applications relevant to their enterprise role
  3. when a valid employee becomes an invalid ex-employee, their access is terminated
  4. any data delivered down to device of valid employee is protected both in transit and in device storage
  5. when a valid employee becomes an invalid ex-employee, any data stored on device is removed (or equivalently made inaccessible)
           
The third goal above can be satisfied by isolating the employee’s personal applications & data from the security & policy controls of the enterprise – fundamentally to leave alone anything that is not under the enterprises legitimate authority – like Angry Bird high scores and wedding pics. Whether BYOD or COPE, it behooves the enterprise to respect the employee's privacy.

In the next post , I’ll show how the enterprise can use identity standards like SCIM, OAuth, & SAML to meet the above requirements of convenience, security & privacy – specifically how the enterprise can
  1. Manage (create, edit, delete etc) identities for its employees at both the MAM & various SaaS providers so that
  2. Those employees can access the SaaS applications relevant to their job , and do so in a manner compliant with enterprise policy (as enforced by the MAM) and importantly
  3. Not require the employee be issued (and so be forced to remember) passwords for all these various services but instead enable access to applications via Single Sign On for both web & native applications.
Tieing back to the diagram, as drawn above there is significant 'whitespace' between the enterprise & the MAM (where IT wants to define security policies) and the SaaS clouds (where employees need to be able to access application functionality). Employee's have an identity in the on-prem AD, but the stuff they need to do is out in the cloud. How do you bridge that gap? I'll show how in the next post.

No comments: