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.

Advertisements

4 Responses to “Enterprise Role Management: Lost in the technical trap?”

  1. Mat Hamlin Says:

    Gregory,

    I believe you are mostly correct.

    ERM absolutely requires committed resources from the Business. Like any big project, there must be executive sponsorship, but also, there needs to be business owners of access identified and continually involved with the ERM definition and evaluation process. One way to accomplish this is to set up a Role Governance Board that includes parties from Business, IT, and Implementation Services, who meet on a regular basis to review Role Content, Role Ownership, Role Membership, Project progress, etc.

    As far as accuracy of access data that is used during role mining, there are ways to increase the accuracy through including captured usage data from an SSO and/or SIEM solution, so that a more accurate representation of what someone needs can be derived. Alternatively, a strong tops-down approach, while labor-intensive, could be effective in ensuring access granted is actually needed and used.

    Lastly, your statement about well defined roles in back-end systems is as you said, controversial. STOP. In a typical enterprise, you will have systems with well defined roles, and systems without roles. Vendors should accommodate both, and allow a Business role to include fine grained entitlements as well as back-end roles. The key is being able to describe what fine-grained entitlements the back-end roles include, and be able to present those, for review, to the role owners and access certifiers. This can be accomplished and is implemented for some vendors’ customers.

    • Gregory Guglielmetti Says:

      Mat,

      thanks for your comments. I absolutely agree with the executive sponsorship aspects. The 2 main impediments to a unified ERM approach I see today are:

      – Lack of a common understanding inside the company about what should be protected. (Information ?, Processes ?, Systems ?)
      – Lack of a common repository describing which information is to be protected in what way (for a bank for example customer accounts and which specific information of customer accounts)

      Without a clear direction from business on what should be protected to what extent, most ERM projects cannot realize their value. RBAC is not the goal, RBAC is a tool to achieve business security and resiliency. If the company doesn’t have it, what exactly is the RBAC model supposed to protect? Is it right to start discussing with middle-level managers about how roles should be structured without them having shared principles on what their company wants to protect or not? Can the Chief Accountant decide by himself what is to be protected in finance or should the logistics and sales people have their say too?

      • Mat Hamlin Says:

        Completely agree.

        This is where the line gets a bit fuzzy between ERM and IT GRC. Most of the good IT GRC tools will provide some guidance based on existing controls frameworks and their foundational regulations. Outside of that, the business will have to come to an agreement on their internal governance rules. This is where a governance board is helpful.

        To prime these decisions, the leading ERM products provide access certification and Separation of Duties capabilities which should help drive the conversations between “access owners” and refine the governance rules.

        But you are correct…. the people making the decisions about the appropriateness of access must be educated, or the tool should be configured to automatically remove access that fall outside of defined governance rules.

  2. SailPoint Overview Part II « Netweaver Identity Manager Weblog Says:

    […] role management which is both top down and bottom up.  As has been pointed out by Gregory in this post, just doing bottom up role mining is a mistake since many people have access they never use.  In […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: