... [W]hen you build a thing, you cannot merely build that thing in isolation, but must repair the world around it, and within it, so that the larger world at that one place becomes more coherent, and more whole; and the thing which you make takes its place in the web of nature, as you make it.”
— Christopher Alexander, A Pattern Language
Security has soared to top-of-mind in general, and to the top of enterprises’ agendas, as the number of incidents and the breadth of impact continue to grow. New types of attackers, the points at which they attack, and the purpose of attack also continue to shift. A recent example of a ransomware attack that impacted a number of companies, exploiting vulnerabilities not within those companies but at a point upstream in their supply chain, illustrates a new trend.
“Security should not be bolted on as an afterthought” has long been the exhortation made by security professionals who aspire for security to be designed in organically as systems are changed and as new systems are solutioned and put in place. The security-as-an-afterthought problem is being exacerbated as new architecture patterns and newly emerging technologies drive rapid changes in the business landscape of an enterprise. In this environment, if enterprises must be agile as well as secure, there cannot be daylight between security design and the broader architecture and purpose of the enterprise.
The Security Legacy
Security has a legacy problem. Security professionals have, over the years, inserted security controls and processes up and down the Open Systems Interconnection (OSI) seven-layer model as well as across the enterprise landscape as framed by the eight security domains that are part of the Certified Information Systems Security Professional (CISSP) certification administered by (ISC)², the cybersecurity organization for professionals. Over the years, this effort has resulted in many of the bits and pieces — the security components, patterns, and processes — that, together, provide the basis for an overarching security foundation.
However, a basis for a foundation and having a coherent foundation are not the same thing.
Too Much, Yet Too Little
Security, as with many other capabilities that are a means to an end, must add more value to an enterprise than it subtracts from it. It is just as certainly possible to overdesign, overengineer, and over-provision security for an enterprise as it is to fall short in satisfying the goal of protecting an enterprise and its assets. It is indeed possible to hamper a business from doing business! An anecdotal example comes from my work a while back with a large corporation that had some rather stringent security requirements. Over the years, it had implemented a security “architecture” that was so restrictive it prevented the company’s executives from being able to connect their laptops to their corporate network in the US when they traveled there from their offices in Europe. The enterprise IT landscape was studded with firewalls and other protective mechanisms that essentially had a “deny all” default orientation; it required explicit permissions, approvals, provisioning, and security reconfigurations to allow what would be considered normal business operations by many other companies.
Philosophical Position or Hope?
It may be satisfying to feel that the dogma of “more security is better” is a consciously adopted philosophical position. In the example above, and likely in many other cases as well, it may not be so much a “philosophy” as it is a being trapped in a complex patchwork of various infrastructure components, configurations, and processes that exceed human cognitive ability.
As complexity increases, it obfuscates coherence — sometimes to the point of making everything opaque. As incidents happen and as concerns escalate, the pressure to respond in some manner — any manner — is strong. This can result in “just in case” patches to the security “architecture” in the hope of compensating for an inability to grasp the whole picture. Ironically, these activities may increase the existing complexity even further and cause even more opaqueness.
How “Coherent” Is Your Security Architecture?
The industry is demonstrating the necessity for coherence by moving toward creating and implementing various security-enabling components and constructs such as security information and event management (SIEM) and security orchestration, automation, and response (SOAR). These mechanisms start to bring things together, creating more holistic views, separating exceptions from the ordinary, and even augmenting human intellect with machine learning. These are moves in the right direction and reflect where we have come from and where we are aspiring to go.
Many enterprises may need to take a step back, survey the security landscape, and evaluate the level of coherence of their security architecture. Is it easy to tell a coherent story in the form of “a day in the life of a zero-day attack” or “a ransomware that ran somewhere but failed”? Is the security architecture coherent enough for solution architects who are at the forefront of the enterprise’s strategy and operating model shifts so that they can design in security as such shifts happen rather than having to bolt on security as an afterthought? Is there a coherent security architecture, or is there a large and complex toolbox of bits and pieces that yearn to come together? Tell me what you think. Send your comments to firstname.lastname@example.org.