It’s an unfortunate reality that all CISOs must face: security tools sometimes don’t work as planned. The savvy CISO knows better than to believe vendor claims of perfect fixes. However, it’s not always the product that falls short of its mark; sometimes controls just aren’t fully deployed. In worst cases, some control solutions operate so poorly that they are bypassed, creating additional risk.
How prevalent is this problem? One survey found that nearly a third of security dollars are spent on security solutions that go unused or under-utilized.1 It’s hard enough to get resources to deploy risk mitigating controls, but it is discouraging to hear how those resources are being wasted. This isn’t a problem unique to security. Another survey found that project failure within IT affects more than half of businesses surveyed.2 As we say here at F5 Labs, you cannot throw sod down on cement and hope it will grow.
There are many reasons security projects fail to thrive. One reason that is not well-examined is simplistic and shallow planning. This disconnect begins when planning is done purely from a technical perspective, and often with idealized assumptions about how things work. Some architects assume their enterprise systems are clean, simple, well-defined architectures with disciplined users performing defined operations within the system. They erroneously assume that if they make a little change, there will be little or no blowback within the enterprise. This is not always the case.
In the real world, most IT infrastructures are complex Rube Goldberg machines composed of a tapestry of piecemeal designs and multiple point solutions stitched together over time. On top of that, these IT systems are also interwoven with dynamic “out of scope” processes such as legal, business, social, and financial subsystems. Many of these variables and subsystems can affect each other with delayed and non-direct feedback loops. How can there ever be “one little change” to such a complex system without unforeseen effects? Small events that are separated by distance and time can cause significant upheaval in complex systems. Worse, as problems mount, the use of the same poorly fitting fix over time can create more and more unintended consequences that silently build up to a major new problem.

To treat complex systems as simple machines is to invite unnecessary delay or, worse, project failure. A better way of planning is to embrace the complexity and model it using a holistic systems approach. This means to acknowledge, examine, and incorporate those “invisible” factors and their relationships. A discipline called Systems Theory offers guidance on how to do this. Here are some basic tenets of Systems Theory:
- Systems have context and history: the past is integrated into the present
- Systems have many connected levels or facets that constrain and compel each other
- A minor change could produce major consequences, therefore everything has trade-offs
- Systems maintain equilibrium and are governed by feedback
Through the lens of Systems Theory, you can view your organization’s IT infrastructure as a constant interaction of users, business needs, technology changes, and cultural context. There are also external feedback loops, direct and indirect, that pass in and out of the organization, such as relationships to customers, vendors, and regulatory agencies. While these things need not be modeled, they still exist, and you should be prepared for possible changes. Altering the behavior of a system involves monitoring and adjusting the interaction rates between the different subsystems.
Let’s move away from the abstract and nail this down with some pragmatic specifics. The normal practices of a CISO would stay the same, but it is in thoughtful application based on these dynamic factors that new leverage is gained. Per Systems Theory, there are specific ways to alter a system. Below are system theory adjustment methods mapped to common techniques in the CISO toolkit.
Systems Adjustment Tool | Security Program Example |
Adjust parameter for rate of change | Bug bounties, deployment process, rollout of controls |
Alter the rules | Security policy, approval process, ownership of assets/risk |
Adjust buffers and flows | Budget, workload, personnel |
Regulate feedback loops (positive, negative, delays) | Audits (internal/external), awareness rewards |
Alter information flows | Make things visible/invisible (risk or compliance scorecards, shared cost) |
(Re)define the goals/paradigm | Define and share acceptable risk, define security culture, lead by example |