Beyond RBAC?

Kuppinger Cole recently had a discussion covering the potential boundaries of standard RBAC and if there are any potential next steps.  The talk focused on why RBAC projects fail and what are the main limitations of a static RBAC implementation. 

Most projects tend to fall foul of the main RBAC confusions:  What is the role supposed to represent?  A user? A job function? A set of entitlements?  In some cases the role will represent all of these things, but to different people.

One of the common scenarios we have seen during our deployments, tends to be the concept of role explosion.  The rapid increase in the number of entitlement carrying roles that attempts to match every possible access scenario within the organization.  In addition every department, area or even user adds to the concept of role exceptions where new and unique roles need to be created to match a particularly different set of entitlements or scenarios.

(Rock and) Role Explosion??

A lot of the underlying confusion manifests itself from the idea of access context.  Babak Sadighi from Axiomatics describes this concept as "..not always about who? and what? but also when? where? and why?.." access permissions are required and used.  His argument is to focus on 'privilege giving attributes' or Attribute Based Access Control (ABAC), with each of these attributes covering non-application specific characteristics such as environmental or resource based.

This allows Fine Grained Authorisation (FGA) to be done based on a users characteristics, their intent, the time of execution and also against the objects context.  If this scenario were to be managed using static RBAC, this would result in role explosion due to roles covering every possible combination of users,
 environments and sessions being created.

The role explosion arises due to the assumption that a role is simply used for static provisioning.  Once a user is associated with a role, they will receive the entitlements of that role.  If a separation of duty needs to be fulfilled, multiple accounts or roles could be used to cover the multiple combinations associated with the context.

One of the ways to overcome this scenario is to use XACML and the concept of ABAC.
XACML has seen prominence in recent years with increasing emphasis placed on interoperability and E2E access control with
several vendors entering this space, including Cisco with it's December 2007 acquisition of Securent.
The main idea with XACML is to allow authZ decisions to be made using the subject, action, resource and environmental characteristics extending the static RBAC and user model with a real time Policy Decision Point.

As more and more organisations deploy an RBAC model of some description, be it to aide provisioning or to simplify administration tasks, the need for a more dynamic and extensible access control framework will develop and the maturity of something like XACML maybe help this process.

Automating Bad Process Doesn't Make It Effective

I was recently presenting to a customer who is about to embark on an RBAC and Role Management project.  They knew the technical features they wanted to implement but their main concern was focussed more on the underlying business process.

An RBAC project can cover multiple areas of a business, not just he IT Security and Administration teams.  Obviously there are technical aspects, features and metrics that need either automating or consolidating.  These can include:

#    Automatic creation of a role object (including the entitlements a role should have)
#    Automatic association of users to role objects
#    Automatic reportin of role objects, user entitlements, user exceptions
#    Automatic recertification of user entitlements and role entitlements
#    Automatic Audit analysis like Separation of Duty or compliance policies

This list is obviously non-exhaustive but gives an idea of the sorts of tasks that a piece of software can be used to automate and a manual process.

In addition there are several business related aspects that need considering also.  Introducing an RBAC security method into an organisation requires additional support and steps from a non-IT perspective.  These can include:

#    Training for line managers to request a role for access instead of an individual entitlement
#    Providing a non-technical naming standard for role objects so business leaders understand their meaning
#    Identifying who should 'own' the roles themselves, to provide goverance for role to user memberships
#    Which parts of the organisation should have priority for an initial wave of RBAC deployment
#    Who from the organisations board should sponsor and direct the project
#    If a user requests access to a role who should manage compliance exceptions and the process flow
#    what reports need creating, when they should be stored, for long and by whom?




Again, this list is only a sample, but should give a picture of the more process related issues involved in deploying an RBAC tool.  The tool itself will not fix the process if it's either broken or missing entirely.  The implement a solution of any kind, the underlying actors need to be involved, know their role and be able to follow a prescribed process in order to deal with the general management issues that arise from using roles in an access management platform.

By simply automating bad process, all we are doing is accelerating the issues the processes cause due to their lack of scope, detail and focus.

If you're walking in the wrong direction, starting to run only makes you further from your correct track.  It is better to slow down, stop, understand the underlying issues first, before starting to use a tool to automate and influence the critical access framework you're trying to develop.

IDM09 Conference London

At the start of the week I attended the IDM09 Conference in the Docklands in London. This relatively new one day event was host to several key security, identity and access control vendors and partners as well as delegates from the private and public sector. Most delegates held positions in leadership, architecture or implementation positions related to security or audit.

The attendance was fair considering the time of year and the ongoing economic uncertainty and credit issues facing many finance related organisations - the very companies that most security solutions are aimed at. The vendor sponsorship list contained the standard big name players including Sun and Oracle as well as developing vendors such as Aveksa, Courion and the Benelux based Bhold. The consultancy partner and SI space was also well attended with the likes of DNS, Infinitum and Oxford Computer Group sponsoring and presenting.

Due to the event being only the single day the agenda was quite compact with the idea of 15 minute bullet style presentations, case studies and vendor pitches spread throughout the day. The case studies were mainly SSO based with some touching on the provisioning arena, covering the implementation and project deliverable cycle. An increasing focus was on the goverance and compliance aspect of access control, be it from a provisioning perspective or from an audit and reporting perspective. Sun's SRM tool is one of the industries leading compliance, certification and identity cleanup tools and many of the techniques, and methodologies used by Sun are now being adopted by the industry and other vendors as a means to cleanup identity data either before or during a provisioning project.

Conversations were again placed on Microsoft and their small scale attempts to enter the full identity lifecycle and provisioning landscape with their ILM tooling. Many of the features discussed - like a UI for management or workflow design - were new to Microsoft and again tend to focus on none-heterogenous landscapes. Many were discussing the use of AD as a central repository for authN across legacy and *nix based applications. Whilst this is a great idea in principle - reduction of silo'd LDAP repo's, easier provisioning/deprovisioning, centralised identity information and so - the main question was still around authZ. Unless an applications is being designed from scratch, existing deployments will need to have considerable remodelling with regards to internal access control in order to use AD as an authZ store. The discussions will continue no doubt due to the omnipresent nature of Microsoft in the desktop and directory landscape.

One of the other areas I took note of, was the discussions surrounding the Kantara Initiative. The relatively new organization is to focus on "Bridging and harmonizing the identity community with actions that will help ensure secure, identity-based, online interactions while preventing misuse of personal information so that networks will become privacy protecting and more natively trustworthy environments".

An interesting presentation by ex-Sun employee Robin Wilton on the focus and benefits of the initiative gives food for thought. Like most cross vendor forums however, the most notable vendors tend to be the ones not involved.

Overall the event was a worthwhile addition to the identity calendar.