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

Themes Change Required ..

Ok, I had to change the blog theme again. Hopefully for the last time. The problem with the previous theme was that it didin’t show the author of the post and since this blog evolved from a single author (Gregory Guglielmetti) to a multiple authors blog (Welcome on board to Gregg Dippold), I had two options: Modify the “fadtastic” theme we were using or take another theme that shows the author name. Being the lazy man I am I went the easy route.

SAP Opportunity Discovery Camp 09 – Interlaken, Switzerland

I will be 2 days in Interlaken for the SAP 2009 Discovery Camp for partner companies. Interesting program this afternoon with:

  • SAP Business Objects Portfolio: Strategy and Execution
  • Legal Requirements with GRC
  • IDM & GRC for CIOs
  • Company wide Data Warehouse

Good to catch up with colleauges from partner companies like Cirrus and old Deloitte and PwC beer drinking champions (you know who you are).

I found the first presentation particulary interesting. GRC is getting integrated in the Business Objects portfolio together with Business Intelligence, Strategic Enterprise Management and Information Management. Seems like the now 3 years old efforts to combine GRC and EPM initiatives is getting some traction from the software side too.

Governance, Risk and Compliance – The bigger picture

This post is a slight adaptation of an old post of mine on the BPX Community of SAP on the 2nd of May of 2007. Two years have passed by, but most companies are still far away from reaching the described state, so what I describe is still very actual.

The originating question was: What kind of framework or approach do you use when trying to implement GRC in an organization? At that time I was still working for one of the Big 4. Here is the response:

“Each company has a different approach to GRC. However, you can divide them in two broad categories: tactical and strategic approaches to GRC.

Tactical: many companies, mostly those still struggling with SOX, buy technology for solving niche problems (SODs, automating controls for decreasing sox costs, documentation tools for control frameworks, etc). Often the need for a quick fix make it impossible to broaden the discussion around the integrated GRC message. It is not uncommon to find corporations using SAP GRC in India and China and Approva in the United States. Or even companies starting to implement GRC Process Controls without having exploited the configurable controls already inherent in their SAP systems. In summary it is a chaotic situation characterized by individual activism (at country/ division/personal level) in which companies tend to create GRC silos inside the company itself. The right approach to take is an organizational one: Is there somebody in the organization (at the CxO level) interested in harmonizing and sponsoring the GRC discussion? Is the CIO on board? If yes then you should care about a GRC framework, if no, it is wasted time in my experience, because the tactical forces will disrupt the cohesive GRC approach and frameworks.

Strategic: There are very few of them at the moment but they are increasing lately. These companies are willing to broaden the discussion about the GRC message and are interested in a GRC framework/approach. What does a GRC framework/approach contain:

  • Define the path forward (Where do we want to be in 4 years from now?)
  • Provides a clear view for how GRC integrates into core business processes (Yes, this means working with business people to collect GRC requirements, not just automating something in the backoffice and running off. I do not know how many failed SOD projects I have seen in the last year because they were only technology driven)
  • Identifies where risk and compliance management procedures can be automated (And above all where it does not make sense)
  • An understanding of how information technology should play a critical role in risk management, proactive compliance, and adherence to standards and policies.
  • Maximize the use of existing assets and investments (ex: SAP configurable controls, sap reports, etc)

These companies are clearly not only strategic, but they have realized that GRC should be approached with a combination of tactical (pilot projects) and strategic (what do SOX 404, FDA, Basel II, Loi Financiere, Turnbull, etc.. have in common and how can we leverage common GRC processes and IT infrastructure?)

I think it is also beneficial to distinguish between the GRC message as a business message and the SAP GRC message wich is still mainly technology driven. They are definitely interconnected, because they enable themselves mutually, but you need to make sure you have the right people in the projects on both sides. As an example, if you are implementing the SAP Risk Management component there is a technical part to the implementation of the module but there is also a fundamental business part in creating the processes and understanding around operational risk management in the company so that those numbers and risk estimates that go into the tool make business sense and are lived as part of the day to day business. For that you need industry experts on supply-chain risk management or procurement for example.”

Scary. Two years old and still actual.

a fresh start!

Hi there!

My name is Gregory Guglielmetti and I am currently a Managing Partner for an SAP Security specialist called Secude.

I’d like to use this blog to post some of my thoughts on the Risk and Security space with a focus on SAP Environments. Please feel free to comment and share your thoughts!