One of the current niche's within the Identity Management space is that of RBAC - roles based access control. RBAC is not a new 'niche' or indeed a new framework, but has seen a wave of interest in recent years with numerous small independent vendors (as well as the usual players) entering the market and creating a buzz.
The increased interest has been driven by several factors including general audit compliance and the drive for simplified account administration. But the main one I believe to be is the general maturity of Identity Management and the missing link of roles enforcement.
With roles, organizations have the ability to manage detailed account entitlements in an automated and security controlled manner, implementing access of least privilege as well as providing entitlement ownership, reporting and accountability. Many organizations see this as a key requisite of any automated account provisioning mechanism, but fail to understand the key components of how to successfully approach or deliver such a project.
To many the migration from a user centric access platform to an RBAC framework is often a daunting enterprise wide project similar to attempting to 'Eat an Elephant'.
Role Mining Theory has generally been viewed academically for several years since papers from the likes of Ferraiolo and Kuhn became popular reading as well as standards from ANSI becoming the main starting point for any RBAC project. Role Mining (or Role Engineering) can generally be viewed from a top down (looking for patterns based on HR or job description data) or bottom up (application specific, entitlement carrying) view point. Many projects should really focus on utilizing both mining methods in order to create a hybrid model allowing roles covering a multitude of job functions and entitlements.
Like any large scale enterprise wide project strong project management is a must, by allowing the implementation to be broken down, prioritized and risk reduced. Business areas should be selected with strong business stakeholder buy-in, in order to provide guidance on non-IT requirements and role ownership.
The use of RBAC has several business process changes which require non-IT operations to understand and manage various processes in the RBAC lifecycle. Without business buy in RBAC becomes an IT centric tool which will fail to deliver enterprise wide benefit.
Any selection of an RBAC tool is really based on enabling the business to perform greater and more efficient access governance and identity management. In order for this to be successfully accepted, the business needs first to understand the expected benefits of undertaking such a large project. This is can generally be best seen if an RBAC framework is attempted manually without any automated tools. This shows the difficult and time consuming process of attempting to cluster users and entitlements together. It also gives a point of comparison between manual delivery and an automated methodology for RBAC access governance.
The implementation of an RBAC framework should generally be seen as a long term strategic direction as opposed to a short term tactical fix for a single application. A long term view must include business ownership of the framework as well the automated IT mechanisms underpinning such a solution such as provisioning, access enforcement, role development and separation of duty monitoring.
The key to most of the points mentioned so far nearly all include business buy-in. This is true of so many enterprise security projects, with so many however over looking this critical point. Many large scale organizations now have an information security function with a representative at board level
generally seen to be the CISO or Chief Information Security Officer. Whilst they maybe the main advocate of an RBAC framework on behalf of the IT function other board members should be keenly focused too.
The CFO should be interested due to the long term ROI and lowering TCO. Representatives from Audit (for the increased reporting and access governance ownership gained by RBAC) as well CEO reports should also be part of the decision making process due to the enterprise wide
impact of RBAC. This would not be limited to non-IT managers becoming part of the access control ownership function, but cultural changes to existing business processes mainly surrounding access request and access remediation and reporting.
Industry analysts such as Gartner and Forrester now regularly comment on the expectation that RBAC frameworks will become the standard offering to large scale organizations intent on increasing access governance whilst lowering TCO for user administration.
It remains to be seen whether successful RBAC implementations can be made without cross business understanding and buy-in, as with only IT sponsorship any enterprise wide project is destined to fail.
Comments regarding the role model.
Most people tend to think that the role model, the basis for RBAC, simply consolidate 80% of the access rights in groups that together correspond to one or more business functions as they are defined in the org-chart or HR system.
The fact is that the role model should consist three layers:
1. The role layer (as already discussed)
2. The privileges layer – even in perfect role model, some access rights are left out side role definitions. Managing those is as important as managing the roles.
3. Policies – after all there are role combinations that are toxic (cannot be granted together), or combinations that must be assigned as a group. Those policies of deployment are part of the role model
Without those the role model is too shallow, but adding to the implementation project doesn't means that the elephant will grow to a size of dinosaur.
Mature tools offer full discovery and management capabilities for full role model, that easily support the implementation, and more important increase the value of RBAC to the business people
Azi Cohen
The writer is the CEO of Eurekify, a provider of enterprise role management solution
Posted by: Azi Cohen | 21 June 2008 at 02:51 AM