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.