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.