Enterprise Role Management: Lost in the technical trap?

What exactly is Enterprise Role Management? It is a conceptual extension of the original RBAC model beyond a single system to a cross-system enterprise-level RBAC approach. Unfortunately, because of marketing issues everybody understands something different under Enterprise Role Management. For the sake of simplicity we will assume in this article that ERM is the practice of having a consistent set of procedures and methodologies around the definition of roles for all systems in a company. We will therefore only consider ERM software, those tools that help us define/construct and manage roles in adherence to these enterprise-wide procedures and methodologies.

Today, unfortunately most discussions around ERM start with aspects like Role Mining or Segregation of Duties. Role Mining is particularly insidious because its implementation is often based on a wrong assumption: You can mine actual roles and permissions in a company to find out what common roles and permissions people have and make a role out of it. Unfortunately statistical evidence of our work in 10 years of SAP security has shown us that more than 70-80% of permissions given to end-users are never used. They just piled up after years of operations. What value has data mining a base of information that is up-to 80% wrong? In those systems where it is possible to collect data over who is really using certain permissions (and there are very few systems that keep track of this) role mining may be  however a very helpful tool in re-engineering a role system.

But then why are most vendors just trying to sell through this angle? Because doing ERM the right way is a titanic amount of work and most companies and back-end systems are definitely not ready for prime-time. Let us forget for  a moment completely about software and just think about the business implications of Enterprise Role Management. We would like to define a business role and all associated required permissions. For example we would like to define an HR clerk role and everything that is needed for his daily work. In the analysis phase we start collecting the permissions that would be needed in databases, shared folders, ERP systems etc.. In the simplest case all backend systems have cleanly defined their roles & permissions and the ERM role would just be a bag of back-end roles. STOP. This is not ERM, this is a technical project with no business added value. It is just leaving the huge burden of defining the fine grained authorizations to the back-end system responsible. A real ERM project would contain most of following elements:

  • Company wide procedures and policies on the definition of roles across systems and inside a single system
  • A unified way of dealing with privacy laws and other compliance requirements for all systems (including cross-system segregation of duties analysis)
  • Clear business responsibilities on either process ownership or information ownership (depending on company organization) that tie into the definition of new roles or changes to roles

Only that way you can attack the main cost-drivers of authorization management. Authorization management is expensive because activities like defining requirements with the business or defining privacy requirements are done over and over and over each other year asking always the same questions for each system: who can access payroll? who can do payment runs? These questions need to be asked once for all systems in a process centric or information ownership centric way, stored in a wiki or some sort of other database system for consumption by all applications developers and the ERM people. In a recent SAP security project we have done, 60% of the time was spent on requirements gathering (5 months,4 people) and only 10-15% was on roles construction and maintenance, the rest was testing. It is therefore imperative for an ERM project to address the main driver of effort.

I think that the first vendor addressing this part right will be the winner of the ERM race. Until now the race is a technical one with little business value and most clients see clearly through the fog of marketing. You can have all XACML, SAML and other acronyms of the world on your product but if you fail in providing a bridge to connect business with IT the ERM promise will never materialize.

I am aware of being a little bit controversial in this piece, so if you disagree with the main points I would be glad to hear your opinions.

Directions Ahead!

Before starting out this blog I asked myself the fundamental question: How can I add any value to the huge amounts of information that is already out there on the net? Will I just write about subjects everyone else wrote with just a sligtly different spin? In the last 14 years I spent a significant amount of time on the net searching for information and was amazed by the amount and quality of information even in my fields of expertise: mostly SAP security, internal controls and risk management. Everything from research papers on advanced authorization theories, brilliant risk managament methodologies down to obscure configuration details about SAP. The amount of information out there is simply amazing, how could I add anything significant to it? After years being in the field and trying to bridge the gap between the possible and the doable, accumulating experience in my fields, I observed some obvious gaps in what is usually published. I collected some of these subjects and will talk about them in future posts. Here is a short list of subjects I will write about in the next months:

  • The skeleton in the closet: The systematic omission of Human Psychology and Organizational Theory aspects from Authorization Management projects
  • Role Mining: The possible, the doable, the understandable
  • The growing gap between security research and what is implemented in companies
  • Information Ownership and other prerequisites for a sensible Enterprise Role Management approach
  • The natural evolution of application security from systems security to architectural security
  • Musings on Segregation of Duties: How to explain NP completeness to your auditors

I will start with these subjects and go on from there also based on your feedback.  I will also try to report on the everyday challenges of security and risk management consultants from the trenches: the required skills, the compromises, successes and failures.

See you soon.