A Death in the Desert

The often-repeated cliché “The devil you know and the devil you don’t know” is used for taking no action in the face of something new, keeping something you understand and foregoing something that has more uncertainty. The question of staying put or changing is a problem all CEOs and executives contend with.  In my youth a much older and wealthier businessman told me that when you are an innovator and you are first to the well, you get a long drink.  And he was right; he just left out the part that most innovators die in the desert before they reach the well.  On my second death in the desert (with apologies to Robert Browning) I realized that successful enterprises walk quickly over the corpses of innovators and hang around the well having a good drink and speaking admiringly of the recently deceased, whose agonizing path made it all possible.  So the market collectively is always smarter then any one individual innovator and all the guesses of all the participants will eventually show the way (if one exists) and others will copy.

Returning to our original problem of which devil – which we can show more concretely with an enterprise risk management example such as upgrade the enterprise software or stay on the current version – what is one to do?  The answer comes down to access to capital and level of pain.  This may not be so obvious if you have spent your entire career in a large enterprise and take capital for granted.  Innovation fails so often that if you can afford to wait then do so.  Some will say “innovate or die” but that truth does not have a time preference nor does it specify the degree of innovation to survive.   In most cases, it’s years longer than the salesman says and good enough is sufficient if the customer is happy.  How long did it take for the Internet bubble to burst under the weight of bad models?  How long was General Motors able to ignore its customers?  It’s always longer than you think.   Those vendor discounts will lower your perceived risks not your actual risk.  The insider clamoring loudest to be first may only want a bullet on his resume or to see his name in the case study.  The small company with little capital must be more aggressive and as statistics show will fail at a higher rate from which we can all learn.

But if, appealing thence, he cower, avouch
He is mere man, and in humility
Neither may know God nor mistake himself;
I point to the immediate consequence
And say, by such confession straight he falls
Into man’s place, a thing nor God nor beast,
Made to know that he can know and not more:
Lower than God who knows all and can all,
Higher than beasts which know and can so far
As each beast’s limit, perfect to an end,
Nor conscious that they know, nor craving more;
While man knows partly but conceives beside,
Creeps ever on from fancies to the fact,
And in this striving, this converting air
Into a solid he may grasp and use,
Finds progress, man’s distinctive mark alone,
Not God’s, and not the beasts’: God is, they are,
Man partly is and wholly hopes to be.

Excerpted from A Death in the Desert

by Robert Browing


The Discipline of Disciplines

Every one of us today is attempting to move from a less desirable state toward a more desirable one.  We are goal directed whether those goals are ignoble or not matters little.  The farmer, the criminal all seek after something more desirable.  This is true of individual behaviour and corporate action.  Along this path we face scarcity of resources and absolute limits on our time.  Eventually we die.  Because of the foregoing, we make daily trade offs in actions we take and don’t take and we approach our goals systematically.  The fool and the wise both have a process.

So when a business fails to address any number of risks are they behaving irrationally?  Any one with in depth knowledge in any field is tuned into the risks.  The Bundesnachrichtendienst knows more about the threat of terrorism to Berlin, than I.  The top security researchers know just how vulnerable our systems are to directed attack by a highly skilled person. Many security researchers carp endlessly that people “don’t get it”, that they are victims waiting to happen.  As a generalization this is true, but I believe the behaviour is not irrational.  The corporate result may appear irrational but the individual activity is not.  Most people access risks based on some degree of its locality and recent occurrence, for example, if you discovered that several of your neighbors had been mugged you would grow more cautious. There have been sufficient numbers of viruses and exploits that most people have some degree of caution now.  Inside corporations we have policies, practices, frameworks and protocols to address the threats but there always be residual risk.

When I found outstandingly bad practices inside a company, it used to be because of ignorance.  This is not a slur; they didn’t know or understand.  In the last five years it has become increasingly due to limited resources.  I believe this is progress.  The goal of security has always been to build reliable and dependable systems in the face of misadventure, malice, and error.   I would add a secondary goal and that would be to accomplish a better result over time at a lower cost*.

You cannot address all risks so you have to divide them into those that can be measured statistically, and probabilities assigned and those whose statistical profile is not known, for example, a terrorist attack or an earthquake.  For those with known probabilities and losses the approaches are well established. For those that occur infrequently with catastrophic consequences, the best we can do now is build resilient systems and set aside financial reserves.  Time and experience aid us in addressing risk;  we will never be fully protected, the purist and idealist in any field is a cynic in training; the discipline of disciplines is balance.

*This must be done even in the face of ossified regulatory burdens.

CIOs Dismiss Cloud Security Concerns

Today I read an article on the web about “CIOs dismissing Cloud Security Concerns”. I found the article quite irritating. Firstly because this has not been my experience in the field, where CIOs are very concerned about security even if simply from a compliance perspective and second because this is only one of a lot of articles I have seen in the latest months trying to downplay security concerns in cloud computing.
Clearly you can start to feel the frustration of many cloud computing providers/vendors about the slow adoption of their new vision of IT by most corporations. And is it really new? I remember, as an ex IBMer the ON DEMAND campaign almost 10 years ago, wasn’t that basically cloud computing? Well, wake up cloud computing providers and start knocking on the doors of IBM/EDS and all other providers of outsourcing services. They have been there before from a security and legal standpoint. They will tell you how painful it will be to convince large corporations to move their crown jewels to the cloud.
Instead of downplaying security concerns, why don’t you map a roadmap to your clients about how you will solve all of their concerns about cloud computing? Large corporations will always test you. You will get a little piece of action (The sandbox environments for example) and will have to prove yourself worthy. Then, if you were successful, you will get a larger part of the pie. What are therefore the security and compliance requirements of corporations that cloud computing providers will have to address in the next years? Here a short list:

  • Robust Access Control Capabilities: (Above all for providers like Google App Engine and Windows Azure)
  • Logging & monitoring
  • Audit trails
  • Long-term Archiving
  • Legal support for cross-national compliance issues (Ever wondered why big outsourcers like IBM/EDS have at least one outsourcing center in every country?)
  • SAS70 certifications and Security SLAs
  • Assurance that the BIG4 Audit companies are going to support this move: If you do not convince Deloitte/E&Y/PwC and KPMG you will be facing an uphill battle

So, dear cloud computing providers, get back to the drawing table and spend some money on these fundamental questions, instead of ridicolous surveys.

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…

The Regulatory Tail and Risk Management Dog

There are a seemingly endless number of information security frameworks available to the practitioner, life cycles to aid in understanding, and policies derived from frameworks.  In many cases the implementation takes place but unless it is an audit item or there exists regulatory compliance requirement, there is very little enforcement.  I have witnessed this in every major corporation I worked with. In most cases this is because of limited knowledge, or limited number of personnel, which is driven by budget priorities.  Renewing the club membership for senior executives is more critical then adding one more person for policy compliance.  I write that without a hint of sarcasm.  If I have a senior marketing executive whose efforts are growing sales, it is money well spent.  Take that away and he may move to a competitor.  Sales and marketing are the apex of the pyramid, everything else is support.

Companies invariably treat various forms of regulatory compliance as a nuisance to be dealt with not as a risk management tool. The correct approach is to do risk management properly and the regulatory compliance will follow. This is well known.  It isn’t done on the whole, however, and many infomation security managers use regulation to push through better practices under the auspices of meeting compliance.  It is ineluctable that regulatory frameworks will become outdated as innovation occurs, and those companies whose regulatory tail wagged the risk managment dog will be more vulnerable than ever.

Thoughts on SAP Risk Management 3.0

“In the economy an act, a habit, an institution, a law, gives birth not only to an effect, but to a series of effects.  Of these effects, the first one only is immediate; it manifests itself simultaneously with its cause-it is seen.  The others unfold in succession- they are not seen; it is well for us if they are forseen.”

— Frédéric Bastiat

Bastiat was rumbling through my mind as I watched the SAP webinar GRC Partner Knowledge Session, “Process Control and Risk Management Enablement Session for Partners”. When it was over I had to look up the quote from his essay That Which is Seen and That Which is Unseen .  As the presenter  showed the risk management process:  Risk Planning –> Risk Identification –> Risk Analysis –> Risk Response –>Risk Monitoring and how the software allows you to execute this process,  what is seen are all the risk management controls available in the software, the compliance to regulatory risk, supply interruptions, all the obvious routine problems that happen with some regularity.  We can even model that risk with Monte Carlo simulation using four very limited distributions, discrete, continuous, lognormal and normal.   What is unseen is the cascade of events under way based on decisions made years ago.  The limits of our knowledge stare us in the face but knowing this is to be prepared.  We live most at risk when we feel comfort by engaging in the process, with misapplied statistical measures of uncertainty, Monte Carlo simulation using distributions more suited for modeling Roulette than real life business.  What is your exposure to rare events whose variance is not known?  We can imagine innumerable disasters but how much money will be spent to survive the rare unexpected event when the quarterly earnings report is just around the corner?  SAP  BuinsessObjects Risk Management 3.0 is fine software but not in the hands of the dilettante and the intellectually lazy.

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