Musings on Segregation of Duties: Are your auditors NP-complete? (Part 2)

In the first part of this post we looked at how finding a minimal set of people satisfying a list of SOD constraints is equivalent to finding the chromatic number of a graph, which is NP-complete. We then took a list of possible SOD conflicts and showed a simple transformation to a graph form which can then be further analyzed with standard mathematical programs like Matlab or Mathematica.
But these were toy examples. I therefore take a real example by doing an analysis of the standard rulebook delivered with SAP BusinessObjects Access Controls 5.3. When cleaned up from degenerate cases this rulebook contains 183 risks. Transforming this rulebook into a graph structure (GraphML) and visualizing it with the excellent yED program yields following structure (see image). Attention: The colors in this image are just for aesthetics, they do not correspond to the vertex coloring we will apply later.

SOD Graph of SAP Business Objects Access Control 5.3

SOD Graph of SAP Business Objects Access Control 5.3

I spoke in the last post about a randomized algorithm. Unfortunately I cannot find it anymore, so we will use instead a greedy heuristic algorithm for vertex coloring by Brelaz. Running this algorithm loose on our data gives a results of 5. We theoretically just need 5 people to comply with all the Segregation of Duties constraints.

Amazing isn’t it? Imagine all the discussions we had with clients and auditors along the lines of: ” We would need 100s of people to comply with all SOD constraints”. And 5 isn’t an optimal solution, it is just a heuristic solution we found in a short timeframe. Maybe there is a solution with 4, but it would take eventually too much time to find it.

So, if it takes only 5 people, then also small branches could implement it? Well, it is not so easy. We will look at some of the solutions and realize that while theoretically possible, it doesn’t make sometimes sense from an organizational theory perspective. Imagine putting an ad on a newspaper for following skills: “Looking for excellent candidate with know-how in SAP Development, Month-end closing, Accounts Receivables clerk experience”. Again, this dreaded gap between the theory and the doable!

But out of curiosity lets take a look at 2 areas from the analysis: Procure-To-Pay (P2P) and Order-To-Cash (O2C). In the attached images I have listed the different functional groups and we have given a color. In O2C for example we would need at least 4 people to satisfy all SOD constraints. In P2P we would need at least 5.

O2C: Order-To-Cash

O2C: Order-To-Cash

P2P: Procure-To-Pay

P2P: Procure-To-Pay

Other things to consider:

  • We ran the algorithm globally on the SOD list, but you could also be interested only on running it inside Finance or Procure-To-Pay. That might yeld a globally less optimal solution but might be more suitable to how companies are traditionally organized.
  • Stability of the solution: if the SOD list gets changed frequently then this could completely change the results of the analysis. That means that by just changing 2 or 3 SOD constraints we could have a completely different grouping of the functions. Fortunately sod lists do not change so frequently.
  • Organizational constraints 1: companies always need “backups”. Someone is missing or sick or on travel. Work has to continue and this could easily double the minimum number of people required.
  • Organizational constraints 2: Languages.. problem is often found in large Shared Service Centers. If serving multiple countries with diverse languages, SSC tend to organize as much around countries than processes. This creates a second dimension of complexity and can easily undermine SOD requirements out of practical needs.

Now you have a number of discussion points for the next round with your auditors on Segregation of Duties. You can:

  • Mathematically show that your small branches may not have enough people to comply with their requirements. And therefore there are no other possibilities than use mitigating controls.
  • That parts of the SOD discussion is, even in its static and simplified form, NP -complete. And considering that aour organization is a living entity with ever-changing processes and organization, it is even more complex.
  • Analyze your SOD list for some insights about how you split up the responsibilities inside processes.

In a next post I will talk about a possible usage of these ideas at small companies, called ColorSOD™.


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.

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.