In his book, Drucker provides us with the premise that doing things right means nothing if you are not doing the right things. As true as this is for business leadership, it is also equally true applied to our understanding of engineering and security. Engineering teams often do things right, but don’t do the right things. Put another way, we spend all our time and resources succeeding at things that do not matter. All of us are guilty of this at some level. The mark of a good engineering team is doing the right things in the right way. Stripping away all the things that do not matter so that focus can be given to the things that do matter and move the needle decidedly toward demonstrable security.
We want to consider today why security is an architectural endeavor and not a runtime one. The primary hypothesis is that security is an emergent property, one that is arrived at by making the right choices so that in the final product, security is achieved and does not require that things be added on.
We must first define what we mean by security. Borrowing from NIST SP 800-160, security can be conceptualized across three threat pillars:
- Penetration resistance: preventing breach of defenses
- Damage limitation: prevent the proliferation of damage
- System resilience: ensuring operation even in a degraded state
A system that can reasonably provide for these three tenets can be thought of as reasonably secure.
A key architectural imperative that we hold to at Stellarbridge is “security by subtraction”. By this, we endeavor to understand what our system needs in order to be able to function, and then removing everything that is not required.
This is a paradigm shift for many. Many companies seek to achieve security by adding things in: anti-virus, firewalls, Web Application Firewalls, EDR, XDR and the list goes on. In fact, so strong is the cult-like belief in such saviors that for you not have any one or more of these above solution will land you a tongue lashing. CTOs and CISOs routinely run down the checklist of pairing some risk with a correlating solutions that can be onboarded. One source claims that on average Large enterprises juggle an average of 45 cybersecurity tools , with some reports indicating numbers as high as 76 different solutions. The industry is built around security by addition. You might point out that in recent days we have seen the rise of solutions that consolidate a lot of the functionality that the 45-some-odd tools bring down into one. And while you would be right it must be admitted that we are still seeking security through addition.
Certainly, we do not want to overgeneralize and say that all of these tools are always bad. Such an assertion would be naive. However, it can be confidently said that the pattern of security by addition is a symptom of having too many components, features, or functionality, and of those components lacking the design imperatives of self-protection and trustworthiness. It signals that something is fundamentally wrong. Security by subtraction is superior because it removes the opportunity for risk to be realized—the very risks that security by addition attempts to address. Better still is not subtracting anything because from the beginning there were only the components and pieces that were needed.
One should be sympathetic to leaders who find themselves backed into a corner, forced to choose the least problematic option from a set of generally problematic alternatives. In the real world, security decisions are often made within the constraints of legacy systems, technical debt, vendor lock-in, and business pressures that cannot simply be wished away. A CISO inheriting an infrastructure built on insecure foundations cannot simply tear everything down and rebuild from scratch—they must work within the reality they've been given.
The point is not to criticize those making pragmatic security additions under these constraints. Rather, it's to acknowledge that when we find ourselves reaching for additive security measures—layering on yet another tool or control—we should recognize this as a signal that something deeper is wrong with the architecture itself. These additions are often necessary compromises, but they should be understood as treating symptoms rather than curing the disease.
The goal of security by subtraction is to break this cycle for new systems and future architectures. When we have the opportunity to design from the ground up, we should build systems that are secure by their very nature—not because we've piled defenses on top of insecure foundations, but because we've eliminated the attack surface through thoughtful architectural choices from the start.
Conversely, it must be conceded that sometimes we add on a security measure instead of subtracting a risk because the first is easier. To borrow a line from Dumbledore, “We must all face the choice between what is right and what is easy.”