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.

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.

Security Architecture and Design

A while back a query was made on a mailing list (by James McGovern I believe) what questions do you ask architects in job interviews and my response was, without being facetious, “What is the purpose of an architect?”  The answer is straight forward but many people will give you a circuitous route through the function of design without ever giving the simple answer, to wit, the purpose of an architect is to make decisions which once made are permanent and therefore expensive to change.   Long term one design goal should be to  reduce the number of decisions which cannot be reversed.  In this first post I will look exclusively at design principles and in a later post apply this to a system.

What principles are available to the security architect when securing a system, that is, principles from design not security?  How should one convert those things which are permanent into flexible objects or at least increase their range of expression? When asking these kinds of questions we can examine how they are answered in nature.  Consider, for example, that the alphabet of deoxyribonucleic acid is limited but the information it carries is a blueprint for all advanced life on the planet. We know from the study of complex adaptive systems that modularity and flexibility (real options) are foundational approaches to dealing with complexity and increasing the ability to survive shocks.  Therefore, when first approaching the design of a system, our primary principle is modularity; modular in the sense that the parameters and design choices within the module are interdependent and those external to the module are independent.  More generally, there is information which is hidden and information which is seen.

Modularity gives us specific advantages:  it allows us to contain patterns within an object whose encapsulated parameter range abstracts the system complexity making it manageable; it allows for concurrency of design within the system by breaking unnecessary interdependencies and it increases flexibility and improves adaptability both at the time of design and later as things change.  Because it can accommodate future uncertainty, it reduces risk, the primary goal of security.  Absent modularity, one has two elements, the system design and the system design tasks.  As the complexity increases the understanding drops and as experience has shown complexity is the enemy of security.

Beyond the abstractness of this principle what kinds of operations can be conducted on modules that will improve them over time? Baldwin & Clark in their book Design Rules, Vol. 1: The Power of Modularity posit six operators on modules.  Anyone who has designed anything has most likely absorbed these practices from trial and error practice but it pays to state them explicitly.  They are as follows:  splitting, substituting, augmenting, excluding, inverting, and porting.
These operators work in combinations, for example, some features are excluded at the start of the system and augmented after go live.  Additionally, these operators are employed as part of a directed iterative design process which seeks continual improvements in efficiencies and costs.  Most innovations are process and design innovations not revolutionary breakthroughs.

Judicious use of these operators is also necessary.  Misuse can lead to a riskier system.  For example, splitting can lead to loss of functionality, substituting (normally to lower transaction costs) can lead to poor performance, augmenting can lead to useless feature creep, excluding key elements can make the system more vulnerable to attack, inverting can create single points of failure and porting can lead to system failures because the module takes on work they are poorly designed for, again driven by the need to lower transaction costs

These basic principles: modularity and  flexibility (lack of permanence) taken  from generic design elements should inform the work performed by security architects.  In the next post I will examine these principles at work in security engineering.

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.