Security from First Principles

Chapter 4. Minimization

In order for three people to keep a secret, two must be dead.

Benjamin Franklin

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,¹ 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.

The animal kingdom is replete with examples of animals that fend off predators by becoming smaller, harder, or less exposed—the armadillo rolling into a ball, the turtle retracting into its shell, the tardigrade being, well, a tardigrade. The defensive advantage of being small and simple is widely recognized. Yet one area for which this minimization is often overlooked is time. For instance, nocturnal animals, like the little brown bat, spend the daytime in hiding, only to emerge at night, when there are far fewer predators. Similarly, the trapdoor spider spends the vast majority of its time in hiding, only to emerge, suddenly and briefly, to attack its prey. These animals are minimizing the amount of time that they are visible to their enemies, both by reducing their overall time exposed and by reducing their exposure time while predators are active. Although defensive adaptations like the armadillo’s armor or the porcupine’s spikes can help, often the best defensive strategy is to simply reduce the amount of time you are exposed to your predators in the first place.

This minimization of time exposure is equally important in the information security world. In addition to the security benefits of keeping things small and simple, minimizing the amount of time our systems and strategies are exposed to vulnerabilities is a powerful way to improve defenses. A perfect example is temporary tokens, like those used for password resets. Rather than allow these keys to exist in perpetuity, giving attackers the time they need to crack them, we limit keys to a short life cycle—often a day or a matter of hours. By minimizing the various mechanisms by which our attackers gain strategic advantage, we are able to focus resources while simultaneously raising the complexity needed for attacks to be successful.

The Principle in the Wild

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 or disable code known to create vulnerabilities, like JavaScript and Flash.

• 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.² 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.

Keeping It Simple Versus Cutting Complexity

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.³

Interactions

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.

Takeaways

• 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.

• Minimization is important to understand in combination with Compartmentation (Chapter 5), Comprehensivity (Chapter 1), Rigor(Chapter 3), and Opportunity (Chapter 2).

¹ 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.

² 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).

³ 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.