When I first started in mobile security nearly ten years ago ‘mobile’ was synonymous with laptops, the greatest security challenge was securing data at rest and the solution was device encryption. Today, whether you are on a laptop, tablet or smartphone, chances are your device has out-of-the-box seamless disk encryption. Security has come a long way with much of it commoditized and the conversation has moved from a need to protect towards a growing need to securely share. It is in this changing context that Axiomatics is often consulted on the assumed unique authorization challenges of a mobile form-factor.
A morphing challenge
Developing and supporting mobile apps used to be prohibitively expensive. At a time where the market exploded with devices running Palm OS, varieties of Windows CE, flavors of Symbian, and of course RIM’s Blackberry, -and where mind you: vendor make and model standardization was an impossibility (it still is), having a mobile initiative, meant supporting at least a handful of code bases [for the “same” app] and fifty or more devices(!). Then in 2007 the original iPhone was revealed. And it changed everything.
Apps, apps, everywhere apps
Today the enterprise mobile space is dominated by two platforms: Apple’s iOS and Google’s Android. From a support perspective, market consolidation has made ‘going mobile’ cheaper than ever before with vendors and IT departments only having to cope with two very similar platforms.
What has also changed however is how applications or ‘apps’ are developed for mobile platforms. While in the past developing for a mobile OS required niche skillsets, the abundance of tools available today means just about anybody can be an app developer: you, me, grandma? Well not me at least.
All jokes aside, there are so many tools and approaches available today to the would-be developer: SDK’s, frameworks, MADP’s, MEAP’s (Mobile Application Development Platforms, Mobile Enterprise Application Platforms), web based, hybrid, native and so on, that perhaps the greatest challenge [now] is the lack of standardization, lack of control and the sheer volume of apps developed.
MDM’s and mobility platforms don’t work, nothing does
Trying to address the device challenge and now also the app challenge, enterprise mobility management tools such as MDM’s (Mobile Device Management) and MADP’s/MEAP’s are falling short.
In context of “BYOD” (Bring Your Own Device) you cannot legally or practically manage what is not yours and even with “CYOD” (Choose Your Own Device), the app challenge remains.
This is because whitelisting select devices where centrally standardized services can be supported, is of little use when apps are developed or otherwise acquired in organizational silos or company branches. These apps are typically not officially sanctioned or supported and may not run on CYOD handsets, but one fine day with an increasing install base, they just “happen upon” the IT department.
Coerced into supporting mobile, a central point of concern is still security and central to security is authorization. Just as with user owned devices (BYOD) you cannot practically impose authorization on/within apps, but there is another answer, one that is cheaper, more flexible and that can support any app -new and old – any user and -any platform. It is called Attribute Based Access Control (ABAC).
XACML to the rescue
‘XACML’ is the leading standard for Attribute Based Access Control where access control decisions are made based on subject, resource, environment and action attributes. Since the ins and outs of XACML has been thoroughly explained elsewhere, I will only discuss it here in reference to the mobile authorization challenge.
Understanding that enforcing access control within existing mobile apps is not feasible, the necessary conclusion is to look towards the data they consume. Consequently, XACML-based access control can be implemented on the API calls made by mobile apps.
In the example figure below, an API gateway sits on top of company business data and acts as Policy Enforcement Point (PEP) transforming the application request to a XACML request and sends the request to the Policy Decision Point (PDP). Here, the decision engine uses the information provided in the request together with rules set in policy to decide whether the request should be permitted or denied.
For higher precision and flexibility in decision-making, the PDP calls on one or more Policy information Points (PIPs) such as Active Directories and SQL databases which enrich the engine with attributes such as title, role, department, approval limits and so on. The resulting access permit for an authorized request will be one that provides exactly the right information, to the right user, at the right time and regardless of any device and app limitation.