In order for three people to keep a secret, two must be dead.
The Principle: Minimize the size, quantity, and complexity of what is to be protected, and limit externally facing points of attack.
Key Question: Can this be a smaller target?
Related Concepts: Attack Surface, Compactness, Data Minimization, Simplicity
Minimization is the Principle of reducing needless size, complexity, and overly burdensome assets. Rather than burn resources attempting to secure ever-expanding data sets, systems, and networks, Minimization makes the practitioner’s job easier by reducing the number of things to care about, and by extension, the number of things that can go wrong.
Minimization is the principle of keeping things as small and simple as possible. Rather than erecting more walls, putting in place more checks, and hiring more guards, Minimization improves security by reducing the number of things that can go wrong, the number of points open to attack, the duration of high-risk exposure, the value of the assets you have to protect,1 and the consequences of failures. Every piece of information you store and every bit of complexity you add comes with a cost, and those costs must be weighed against the benefit that the addition provides. Even though it’s often tempting to add more security when faced with a problem, the drawbacks of that added security can prove more damaging than doing nothing at all, and the better option still would be to further minimize what you already have.
Here are few ways to minimize:
Delete sensitive data when it is no longer needed, and don’t store data in the first place if there is no need. If I don’t store credit card information, it cannot be stolen from me. This means both that I’m not a target for credit card thieves, and that if I do experience a compromise, I will not need to report a loss of credit card data.
Remove unnecessary interfaces and functionality. Just as a castle limits the number of ways in and out, a program or system should have as few open APIs or ports as it can while still doing its job. You have limited resources for security. Having fewer points of entry allows you to dedicate more of those resources to each one.
Remove unused code as soon as possible. Unused code is often left in a code base, trusting its unreachability, tendency to be compiled out, or tendency not to be run. Yet this code is still a recurrent source of vulnerabilities, particularly as other code evolves without it. Minimizing a system’s “moving parts” minimizes both the number of ways the system can fail and the number of ways the system can be attacked.
Give every element in an organization the minimum access needed to do their jobs—this includes nonhumans, such as servers and applications. High-ranking executives don’t require unfettered access to company systems. Giving these people access to firewalls and servers they’ll never configure creates a huge and unnecessary attack vector.
Patch systems quickly to minimize the time you are exposed to known vulnerabilities. As soon as a patch is published, attackers now know about the underlying vulnerabilities. Anyone who doesn’t immediately update is at greater risk of attack.
Although it is tempting to think of the job of the security practitioner as primarily being about securing vulnerabilities, in many cases the best strategy is to remove the vulnerability entirely. The world is full of unnecessary risks arising from systems that bite off far more than they can chew, and they end up doing a sloppy job of everything. Keeping systems simple and minimized makes them far easier to defend, makes the practitioner far more effective at his job, and makes the organization a less appealing target.
For instance, think about a mouse trap that you would use to catch a real mouse, as opposed to the board game Mouse Trap.2 Which is more prone to failure? Which can more easily be disrupted by a malicious actor? Which would you choose as the system to work with? Or imagine that you are an attacker, which system will you go after first? Even though our comparison may seem cheesy (with deepest apologies…), almost every system has some fat that can be cut to make it a simpler, more streamlined, and easier to defend.
Doing Minimization on a day-to-day basis is about two things: 1) resisting or taming growth that adds unnecessary size, complexity, or assets, and 2) pruning back existing size, complexity, and assets when they no longer prove necessary or useful. This reflects a basic divide in the job of security practitioners: helping to design systems so that they are secure, and managing existing systems to keep them secure. Sadly, although making systems secure by design is typically far more effective, the majority of the security practitioner’s job will be in managing existing, insecure systems.
Nevertheless, existing systems can often be made substantially more secure by removing unnecessary interfaces, privileges, functionalities, and assets. Similar to how Comprehensivity requires you to diligently look for new vulnerabilities, so too does Minimization require you to look for new ways to reduce needless complexity. Indeed, Minimization is a very effective way to fix the problems highlighted by Comprehensivity: if you find a new vulnerability, rather than add even more complexity to try to secure it, consider just removing the source of that vulnerability entirely.3
The most important interaction is between Minimization and Compartmentation (Chapter 5). These principles operate like two sides of the same coin, with Minimization serving to reduce the external attack surface and overall complexity, while Compartmentation structures the underlying complexity that remains to ensure that breaches are contained. Minimization and Compartmentation form the backbone of secure architecture, keeping systems simple, well defined, easily understood, and easily modified.
However, Minimization also has important interactions with Opportunity, Comprehensivity, and Rigor. Comprehensivity and Rigor are both enabled by Minimization, because sprawling, overly complex systems are difficult, if not impossible, to fully understand, account for, manage, and monitor. If the scope and complexity of your infrastructure is not in proportion to that of your needs and resources, mistakes will inevitably slip through the cracks. Similarly, Opportunity and Minimization both recommend reducing the number of components your organization independently maintains, relying instead on common solutions, such as open source software and standards.
Minimization is the Principle of keeping things small, simple, and manageable.
Minimization relates primarily to overall size and complexity.
Minimization requires both resisting new size and complexity, and reducing existing size and complexity.
Minimization teaches that removing vulnerabilities wholesale is often more effective than trying to manage them with controls.
1 By minimizing “value,” we mean value that does not advance the mission. For example, maintaining databases of personal information creates a target for attackers, yet might offer little value to the mission.
2 The board game Mouse Trap involves erecting a convoluted, Rube Goldberg–style device to achieve a simple solution: catching a mouse. To learn more go to https://en.wikipedia.org/wiki/Mouse_Trap_(game).
3 Because security isn’t always the controlling interest, you must be able to 1) articulate why Minimization is good for the mission, and 2) recognize when Minimization isn’t worth the trade-offs to other business interests and manage the vulnerability in a different manner.