The Essence of SOX, J-SOX, EuroSOX and many more

While I was preparing a speach about the influence of national and international laws on the content and design of GRC tools, I did a research and tried to find all the laws and regulations that you need to follow when you run your business.

I started with SOX sections 404 (we all know them well), moved to J-SOX, EuroSOX and then to the national laws of Germany like Abgabenordnung (AO), which is part of the Handelsgesetzbuch (HGB)… it was quite interesting to read all those modern sections detailing out the traditional laws. Well, I continued and looked into the German data protection law “Bundesdatenschutzgesetz”, followed by some research on German corporate governance law KonTraG (Gesetz zur Kontrolle und Transparenz im Unternehmensbereich).

If you then start to look into specific regulations for industrial sectors, you will find many many more – a very prominent one is Basel II for the Banking sector, regulating which risks a Bank should take and which ones are too dangerous because it would burn the substance (equity quotes).

After browsing through German BSI IT-Grundschutz (equivalent to ISO27001), I thought it could be pretty simple… I had three letters in my mind – guess which ones´it could be?

Nothing changed over years and years when those laws were published and evolved. It is all about handling the complexity of more and more information and data which is handled in your IT systems.

In the end, the essence of all those laws is about establishing transparency by building up an Internal Control System. And here pops the Segregation of Duties concept in – a control system means that you need to establish SoD checks and no one should be able to have the power over a full business process. It is all about SoD – nothing more or less…

Advertisements

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™.

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

Segregation of Duties, also called Separation of duties (SoD) has been in the headlight of public accounting firms since the beginnings of the Sarbanes-Oxley regulations, specifically the 404 section. Wikipedia describes it as: “the concept of having more than one person required to complete a task. It is alternatively called segregation of duties or, in the political realm, separation of powers”.

Translated to application security this means that no person should have a set of authorizations that enables them to perform two incompatible tasks of a process. The easiest example is related to the procurement process: The person creating a Purchase Order should not be the same doing the Goods Receipt and another one should be doing the Invoice Receipt. Depending on the size of the company the process could be further splitted into who is doing the Invoice Receipt and the one doing the Payment run.

Such infamous lists of SODs are normally given to companies by their auditors and they are all very similar (From my experience working at PwC and Deloitte). Companies or the auditors then run some automatic programs to analyze the state of authorizations in certain critical systems such as SAP in comparison to these SOD requirements. They normally get “sexy” excel sheets lists with ten thousands of conflicts, and start cleaning up in an iterative process until the auditor is happy.

In 2003 however I was confronted by a client with a completely different approach. We were in a big-bang project that was completely reimplementing the client business models, processes, organization and implementing a new centralized SAP system. I was in charge of the Process and Security team which was covering SOX 404 compliance, the implementation of a new internal control framework and sap security. The head of the shared services department came to me:

“Greg, I can setup the shared service center to be segregation of duties clean from day 1 of operations. I have received this list from the auditor, how many groups would I need for implementing all SOD rules?”

You have to imagine those lists as being like 300-400 lines long with entries like this:

(PR-1) Purchase Orders # (PR-2) Goods Receipt
(PR-3) Invoice Receipt # (PR-2) Goods Receipt
(MD-1) Bank Master Data # (PR-1) Purchase Orders

over all areas of business, from finance to sales. What the client was asking me was: Given this list of 300-400 rules, what is the minimum number of people we would need to avoid all segregation of duties problems? (For the expert: I am simplifying the problem here, clearly you would try to use mitigating controls in real life and not solve everything through organizational changes).

After some thinking about the problem I was quite happy to have been attentive during the theoretical computer science lessons at university. Turns out that what the client was asking me was in fact equivalent to a well known problem called “Vertex Coloring”. Unfortunately the problem is one of the so-called NP-complete problems. Finding th smallest group of people satisfying all SOD constraints is equivalent to finding the smallest number of colors needed to color a graph G: this is called its chromatic number. How do we transform one problem into the other one? Turns out it is quite straightforward: Imagine tasks like “creating purchase orders” as vertices of graphs and when 2 tasks are in conflict they are connected by an edge. Based on the previous list, we have a graph representation (See Image)

Finding the chromatic number of a graph

Finding the chromatic number of a graph

With only those 3 SOD rules to satisfy we would just need 2 groups of people. For small graphs it is quite easy to find an optimal solution, but for graphs with 50 or 60 vertices and 300-400 edges the complexity explodes. I had a special program (Mathematica) run a whole night without finishing. Fortunately there are so called randomized algorithms coming to our rescue. They can find approximate solutions in a short time frame. They do not guarantee to find the optimal solution, but can often guarantee for example that the found solution is not more than twice as worse as the optimal solution. So I ran the randomized program and waited for a solution.

Part 2 of the blog in the next days …

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.