Complexity is the Enemy of Security

As a young Padawan, halfway through my technology career, I had a Jedi master who explained the difference between availability and reliability. All availability is the probability that a system or service will be there when you want to use it, and reliability is the probability that it will continue to operate through the time you need it, completing the task.

There are four ways of achieving high availability. You can have the highest quality design. You can implement it with the highest standards and use the best components that you can find. You can use redundancy and duplicate components that are prone to failure. You can eliminate points of failure - especially those that will cause a catastrophic failure. And you can eliminate complexity.

Processes such as the Risk Management Framework (RMF) from the National Institute of Standards and Technology lead us to design reliable and secure products from the beginning.

Redundancy means that we have duplicates of failure-prone components. The classic example is disk mirroring, where if one disk drive fails, there is still a duplicate copy on the other mirror-set member. The drawback here is that you are duplicating the resources.

As part of your design and analysis of the system, you can look for points of failure, especially SPOF (or single points of failure), and eliminate those through your design and implementation.

Finally, you can also simplify your design and your implementation. Traditionally, we build systems that meet design and performance characteristics. With complex and ambitious goals, we get large but very capable systems. Then, almost as an afterthought, we wrap the system in a “security blanket.” We then find ourselves between the continual forces of adding more capability or augmenting security.

When integrating security from the earliest design ideas and simplifying the implementation, we need to track fewer elements. Reducing the “moving parts” also lessens the opportunity for attackers to succeed.

The problem with redundancy is a simple fact of statistics. The more of something you have, the more likely it is that one of them will be broken. It is a depressing observation, but it is the world’s reality. We can discuss a device’s Mean Time Between Failure (MTBF.) Engineers have calculated the probability that a drive will break in a given amount of time when you have a population of objects, such as disk drives. That average, also called the mean, is when an arbitrary device will fail. If we have two devices, we can say that one device will probably fail before the halfway point of its lifetime. The more devices you have, the more failures you can expect. With two devices, we can also say that one of the other devices will probably fail in the second half of its lifetime. The problem is that we cannot tell which one will fail when.

Other than SPOF, redundancy introduces additional cost and additional complexity. The redundant components cost money to acquire and operate. Maintaining concurrency among redundant components is much more complex than operating a single device. To use a phrase from popular culture, we need to keep track of more moving parts.

As a child, I grew up with a phrase from my scholar-father. He would say, “Simplicity in All Things,” and attributed the quote to St. Augustine. Unfortunately, I can't find any trace of that quote being said in any reference online. Given that, however, there are lots of references on the Internet to the phrase “Complexity is the Enemy of Security,”

In his book Data and Goliath, Security Visionary Bruce Schneier says:

“Complexity is the worst enemy of security, and our systems are getting more complex all the time.”

In the engineering world, failures are viewed as major problems. A phrase from the Napoleonic wars says, “The architect must be willing to stand beneath the bridge as the battalion marches across.” Granted, structural engineers have thousands of years more experience than we do with computers. There are still roads and walls in the British Isles that date back to the time of Julius Caesar. We have even older and more wonderful architectural and historic monuments dating back thousands of years. In the world of electrical and radio engineering, the work of James Clerk Maxwell in the 1800s still stands today and forms the basis of our modern electrical infrastructure.

As I was writing this blog, Boeing announced that they are calling for mandatory inspections of the empennage of all 737 Max airplanes because of a possible loose or missing bolt. There are no failures yet, but Boeing is mandating that every airplane be inspected as a preemptive action. Whenever there is a structural failure in our infrastructure, for example, when a bridge collapses, this is headline news and makes the newspapers when the analysis and results of the post-incident analysis are completed.

Yet, we accept software bugs and treat them as part of our daily lives. Whether a computer crashes or a program gives us a wrong result, we shrug our metaphorical shoulders and proceed. Giving you a real-time example, I’ve been using the “Speech Recognition” feature in Windows 10. But this capability has suddenly stopped working. It now indicates “Initializing…,” and I’ve reverted to typing on the keyboard.

In computer programming, the “term-of-art” calls an issue such as this “defect.” NASA, for example, has been looking for ways to reduce and eliminate defects. That’s because it can be impossible to perform a “service call” on a piece of equipment millions of miles away. Part of the design of the James Webb Space Telescope was to make the equipment as reliable as possible. That also means it is as available as possible.

Defects can be in systems' design, implementation, or operation, including hardware and software. Defects can also be unforeseen system usage or interaction with other computing components. While defects are viewed as “bad,” the results might be benign or cause catastrophic failure.

Defects lead to bugs, and they, in turn, lead to a range of problems. Those problems might include incorrect behavior, information disclosure, privilege escalation, remote code execution, or crashes.

While bugs interfere with the system’s correct operation, some may turn into vulnerabilities. While crashes may be an operational failure, we can view them as denial-of-service attacks. Similarly, information disclosure, privilege escalation, and remote code execution compromise a system's security and integrity- and an organization's essential data.

“If a tree falls in the Forrest…” is a common metaphor about actions without consequences. The question becomes, if an attacker cannot take advantage of a vulnerability, does it matter? The answer is “probably” because every vulnerability is discovered eventually. Then, the attackers can use tools and techniques to exploit these security holes.

We can choose the 1920s or 1930s as the start of the modern computing era with the pioneering work of mathematicians such as John Von Neumann and Alan Turing at Princeton University. Early computing was notably unreliable and, while better, is still prone to failure. Historically, we’ve always had bugs in the system, starting with the moth that Admiral Grace Murray Hopper removed from a computer in 1947. We accept that software will be “buggy” and must be “debugged.” To a lesser extent, we make the same assumption about hardware.

Attackers create “exploits” to take advantage of these vulnerabilities.

Having painted a depressing image, how do we create more robust, reliable, and available systems?

Building systems without defects requires an infrastructure that supports robust design and development. RMF focuses on building systems that are secure by design and development. Modern design environments and programming languages also support creating systems with fewer defects. Applying artificial intelligence also shows positive signs that the technology may reduce or prevent defects in a system.

Our world has become much more complex in the last few years. We live in a continually more complex world between mobile technologies, Internet-of-Things (IoT), and (now) Artificial Intelligence.

Recently, a friend asked, “What did we do before Google Maps?” My answer was, “We got lost or stuck a lot!”

With the Internet-of-Things, we see on-premises devices connected to gateways connected to the Internet connected to Cloud Services and apps we carry with us. For consumers, the trend is toward the “Smart Home,” with myriad devices connected to servers somewhere and managed through our smart speakers. Recently, Xcel Energy offered discounts to electric utility customers who switched to smart thermostats. Then, Xcel arbitrarily lowered the ambient temperature in their customers’ homes during an energy shortage. We also see IoT in commercial and industrial use, whether for building management, healthcare, power distribution, or manufacturing. Municipalities are rushing to the “Smart Cities” concept.

IoT has many “moving parts” and a tremendous amount of complexity. That makes for a hazardous situation.

One can play a popular game called “Spot-the AI-Generated Image.” These image generators have become very popular but also make huge mistakes. For example, hands are often misshaped in AI-generated pictures. Likewise, you can tell that someone used AI to create product pictures. Generative AI (such as ChatGPT) will fabricate information in a process called “hallucination.” Aside from the gross immaturity of large-scale AI systems, they are so complex that they are virtually unauditable.

I do not mean to inject a non-sequitur, but I live in an almost complete Internet Desert. As a result, I rent an office to use as a studio for online sessions and as a writer’s garret. I spoke to another building tenant whose full-time job is web development. I used the phrase attributed to St. Agustine, and he looked thoroughly insulted. His job is to develop “web apps” with as many features as possible.

I pointed out that more code means more bugs. Those bugs can turn into vulnerabilities and can be exploited. The result is more successful attacks. This isn’t just his (presumably) gorgeous web apps but all the infrastructure to support the environment.

The Internet Engineering Task Force published a document in 1996 called “The Twelve Networking Truths.” Internet standards, called Request for Comment documents (RFCs,) make philosophical statements and define protocols and processes. RFC 1925 - the Twelve Truths - contains:

(12) In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.

Perhaps, instead of adding more complexity, it is time to simplify.