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.

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.

Security and Architecture Part III Going Wrong

At its most abstract, security concerns itself with the protection of a specified object, whether that object is immaterial like information or physical like a building.  Information security practitioners concern themselves more often than not with safe guarding communication of some form.    Typically there is a protocol designed whose goal is to assure one or all of the traditional CIA elements, Confidentiality, Integrity, or Availability.  Additionally, security is no different than any other engineering problem.  We are attempting to reach an ideal state while calculating the benefit offset by the cost and harm made by changes to the system.  There is no perfect state of security only relative harmony with uncertainty.

So where do things go wrong?  For every advantage a principle imparts there exist potential problems.  For example one of the benefits of modularity is information hiding.  It is quite possible that when we create a module over time the information contained therein and its details of operation fade from institutional knowledge due to shifting priorities and loss of personnel.   As system complexity grows there are interactions that were never anticipated that permit security breaches.  This happens in normal system evolution even in the absence of malfeasance or error.

Each of the six operators on modularity and category of changes they embody brings with them the potential for errors.  The first operator on modularity discussed was splitting in which one module becomes two.  Take for example, a system of a single level that is split into two levels, a high security level and a low security level.   In this case we need a constraint of confidentiality on the high level.  Information should not flow down (Bell-LaPadula model).    We prevent the lower system from reading the higher system and we prevent the higher system from  writing information to the lower system.  What happens if the lower system writes up to a file with the same name?  Once we make a change we need to re-think the security.

Substitution, where we replace one module for an improved one is the source of many problems.  One runs into regression errors where problems fixed in preceding generations are reintroduced.  Internet Explorer has had this happen several times.  Sometimes the substitution itself introduces new features that break the security of the module if not the entire system.

Augmentation, that is introducing new or duplicating existing modules creates problems also.  Sometimes for cost reasons fail over systems are less robust than the main system.  A system comes on line to replace the down system and cannot handle the load.  This can also be exploited by intentionally increasing the load on the redundant system.  Wait for an outage and then attack the backup.

With the exclusion operator, removing a system element can create a weaker system particularly if the removal of that system is driven by convenience or cost, for example, dropping two factor authentication.  Alternatively, removing a module may reduce its capability to respond to an environmental change.  We exclude a module for security reasons that decreases the flexibility of the system.

Inversion can go wrong due to its new global nature.  Where before any weaknesses were local and isolated down the system hierarchy now the system is overarching and can cause widespread damage.  Previously, I used identity management as a example of an system inversion.  Imagine a data synchronization event from a malicious administrator that changes everyone’s network ID.

Porting can wrong from a domain knowledge limitation.  Features of the system where the module was first created do not exist in the target system and a lack of understanding of this introduces errors.   A network module of an application on Linux is going to need different safeguards when it is ported to Windows.

Traditional design offers the information security architect principles and a way of thinking about securing systems.  Analyzing the systems in terms of modules, and the operators on those modules allows us to build flexible, robust systems.  But there are always trade-offs and one must examine the operators for deleterious second and third order effects.  They are there and you cannot possibly find them all but thinking about them in terms of modularity and the module operators may help you find more.

What I have tried to do in this short series is show a way of approaching security architecture in systems that draws on the knowledge gained over the years and embodied in principles; principles that are reflected in complex adaptive systems.  Through increasing modularity and flexibility secure systems  can be built at lower costs reducing their impact on the corporate profitability.

note: fixed typo and updated post.

Security Architecture and Design Part II

In Part I of this post I discussed generic design principles that apply directly to information security, viz. modularity and flexibility.  I discussed the six operators on modularity identified by Baldwin & Clark and in this post I will examine examples of each of these operators from engineering secure systems .  To review the operators were as follows:

  • splitting
  • substituting
  • augmenting
  • excluding
  • inverting
  • porting

The first thing that is typically done during redesign with a monolithic interdependent system is to split the modules.  Take for example a symmetric cryptographic system which produces a single key for encryption and decryption.  The symmetry can be broken by splitting the functions such that I have one key for encryption and one for decryption (public key, private key).  Although it wouldn’t make sense in this example, once we have split the function, development can continue in parallel with each new module following a separate evolutionary path.

The next operator, substituting, is complementary with splitting.  With substituting we replace an existing module with one that is “better” in some way whether lower cost, higher performance, for example having previously broken the symmetry of our encryption we are now able to optimize the encryption and decryption functions so long as they don’t lose their essential mathematical relatedness.  Following this innovation we replace the existing functions.  The operation of substitution normally occurs over the useful life of the system.

Further into the lifecycle the augmentation operator is used.  This is where a new module is added to an existing system.   For example, If only one person has the launch authentication code for a nuclear weapon and that person is eliminated, the country loses the ability to respond to a first strike. Therefore a new module is added, a backup system, where the authentication code is a shared secret among several parties who when they put their part of the secret together, can derive the authentication code.

The exclusion operator is the removal of a module.  We take something away to make it more secure and possibly lower cost.  A common example would be the removal of the application programming interface (API) prior to deploying an application to reduce the attack surface,  or the removal of unused  network protocols when hardening a system.

The fifth operator is inversion.  This typically happens later into the life cycle after many design iterations.  An example of inversion would be an identity management system where prior to its deployment each application managed its own identities.  Now there exists a single system which centralizes the function and eliminates redundancy.

Porting is the operator that people are most familiar with and there are numerous examples.  A common port is moving a security monitoring system, for example, a host based intrusion detection system from one operating system to another.  Porting occurs normally following the design being proven on one particular platform whether that proof occurred via testing or was proven in the market.

Those are the six modular operators with examples.  In the next post I will address things that can go wrong when using them.