Skip to main content

Optimized Role Based Access Control

RBAC.  It's been around a while.  Pretty much since access control systems were embedded in to distributed operating systems.  It often appears in many different forms, especially at an individual system level, in the form of groups, or role based services, access rules and so on.  Ultimately, the main focus is the grouping of people and their permissions, in order to accelerate and simplify user account management.


Enterprise RBAC
Enterprise role management has become quite a mature sub-component of identity and access management in the last few years.  Specialist vendors developed singularly focused products, that acted as extensions to the provisioning tooling.  These products developed features such as role mining, role approval management, segregation of duties analysis, role request management and so on.  Their general feature set was that of an 'offline' identity analytics database, that could help identify how users and their permissions could be grouped together, either based on business and functional groupings or system level similarities.  Once the roles had been created, they would then be consumed either by a provisioning layer, or via an access request interface. The underlying premise, being that access request management would be simplified due to business friendly representations of the underlying permissions and the account creation and fulfillment process would be accelerated.

The Issues & Implementation Failures
The process of developing an RBAC model was often beset with several problems.  IAM encompasses numerous business motives and touch points - which is why many still argue identity management is a business enabler more than a security topic - and developing roles across multiple business units and systems is time consuming and complex.  A strong and detailed understanding of the underlying business functions, teams, job titles and processes is required, as well the ability to perform analysis of the required permissions for each functional grouping.  Whilst this process is certainly mature and well documented, implementation is still an effort laden task, requiring multiple iterations and sign off, before an optimal model can be released.  Once a model is then available for use, it requires continual adaption as systems alter, teams change, job titles get created and so on.  Another major issue with RBAC implementation, is the often mistaken view, that all users and all system permissions must be included in such an approach.  Like any analytic model, exceptions will exist and they will need managing as such, not necessarily be forced into the RBAC approach.

Speeding up Role Creation
Role creation is often accomplished using mining or engineering tools.  These tools take offline data such as human resources and business functional mappings, as well as system account and permissions data.  Using that data, the process is to identify groupings at the business level (known as top down mining) as well as identifying similarities at the permissions level (known as bottom up mining).  Both processes tend to be iterative in nature, as the results are often inconsistent, with difficulties surrounding agreement on user to functional mapping and of function to permissions mapping.

One of the key ways of speeding up this process, is to use what is known as 'silent migration'.  This approach allows roles to be created and used without change to the users underlying permissions set.  This instantly removes the need for continual approval and iteration in the initial creation step.  The silent migration consists of initially mapping users into their functional grouping.  For example, job title, team, department and so on.  The second step is to analyse the system permissions for users in each functional grouping only.  Any permissions identified across all users in the grouping are applied to the role.  No more, no less.  With it, no changes are therefor made to the users permissions.  This process is simply performing an intersection or each users' permissions.

Focus on the Exceptions
Once the users of each functional grouping have had their permissions migrated into the role, it's now important to identify any user associated permissions that are left over.  These can simply be known as exceptions, or permissions of high risk.  They're high risk, as they are only assigned to specific individuals and not the group.  This association could well be valid - a line manager for example may have different permissions - but as a first pass, they should be reviewed first.  To identify which are exceptions, a simple subtraction can be done between the users current permissions (as identified by their target system extract) and the permissions associated with their functional grouping.  Anything left needs reviewing.

This approach can also help with the acceleration of access review strategies.    Instead of looking to review every user, every permission and every functional grouping, simply analyse anything which is anomalous, either via peer comparison or functional grouping.

RBAC is a complex approach, but can provide value in many access review and access request use cases.  It just isn't a catch all, or perhaps approach for every system and user.  Specific application using a more simplified approach can reap rewards.

By Simon Moffatt


Popular posts from this blog

Top 5 Security Predictions for 2016

It's that time of year again, when the retrospective and predictive blogs come out of the closet, just before the Christmas festivities begin.  This time last year, the 2015 predictions were an interesting selection of both consumer and enterprise challenges, with a focus on:


Customer Identity ManagementThe start of IoT security awarenessReduced Passwords on MobileConsumer PrivacyCloud Single Sign On
In retrospect, a pretty accurate and ongoing list.  Consumer related identity (cIAM) is hot on most organisation's lips, and whilst the password hasn't died (and probably never will) there are more people using things like swipe login and finger print authentication than ever before.

But what will 2016 bring?


Mobile Payments to be Default for Consumers

2015 has seen the rise in things like Apple Pay and Samsung Pay hitting the consumer high street with venom.  Many retail outlets now provide the ability to "tap and pay" using a mobile device, with many banks also offer…

Customer Data: Convenience versus Security

Organisations in both the public and private sector are initiating programmes of work to convert previously physical or offline services, into more digital, on line and automated offerings.  This could include things like automated car tax purchase, through to insurance policy management and electricity meter reading submission and reporting.

Digitization versus Security

This move towards a more on line user experience, brings together several differing forces.  Firstly the driver for end user convenience and service improvement, against the requirements of data security and privacy.  Which should win?  There clearly needs to be a balance of security against service improvement.  Excessive and prohibitive security controls would result in a complex and often poor user experience, ultimately resulting in fewer users.  On the other hand, poorly defined security architectures, lead to data loss, with the impact for personal exposure and brand damage.

Online-ification: The Role of Identity

The Wikipedia entry for Digital Transformation, "refers to the changes associated with the application of digital technology in all aspects of human society".  That is a pretty broad statement.

An increased digital presence however, is being felt across all lines of both public and private sector initiatives, reaching everything from being able to pay your car tax on line, through to being able to order a taxi based on your current location.  This increased focus on the 'online-ification' of services and content, drives a need for a loosely coupled and strong view of an individual or thing based digital identity.