Security Requires Immutability: Avoid Dynamic Environments with Change Management

Image

When Shelley published his famous poem in 1816, he was telling us that the only constant in life is change. This was not a new concept, even then. Heraclitus proposed the same concept around 500 BCE with ‘Panta rhei’ (Life is Flux or everything changes). Even though we all know and understand this ancient concept, people still have difficulty with change. When I was in high school, Sheryl Crow even tried to remind us with her hit song, A Change Would Do You Good. And she was right, a change would do some of us good. Mutability is a fact of life that we can’t avoid, and we need to embrace it because that change opens the door for many new possibilities.

The critical importance of immutability in cybersecurity

While this is a great life philosophy, mutability is not one of the major tenets of cybersecurity. In fact, the very opposite is true… we want immutability. A great example of this desire appears in a recent article from my colleague, Craig Young. In the article, he discusses how important it is to democracy that voters have confidence that the vote they input with electronic voting be the same vote when it is counted. Voters want to know that their votes are immutable, and electronic voting without a human readable element removes that knowledge. In this case, change is definitely not good. The desire for immutability in cybersecurity is why IT has, for years, had the concept of a gold image. You create a single environment, ensure everything is properly configured and create a static copy from which you image all future machines. This way, you know that your PC setup is immutable from system installation to system installation. No matter which technician works on deploying a new computer or which department is getting the system, they’ll all get an identical computer that is at an identical snapshot. Imagine what a nightmare system administration would be if every system was created as a one-off, if we allowed each technician to install their favorite software and tools when setting up an environment for employees. This desire for immutability has been at the forefront of cybersecurity over the past decade, with standards like PCI pushing change management and file integrity monitoring. This desire is why companies like Tripwire exist… to provide you with tools that confirm the immutability of your environment.

When changes do happen, alarms sound and you know that something is wrong

As vendors have worked to deliver better tools and reduce the manual effort involved, we see advances in technology to make sure only the most important alarms sound. One of the advances is Tripwire’s Dynamic Software Reconciliation (DSR), for which my team (VERT) recently started producing content. DSR allows you to ignore good changes by detecting and automatically reconciling them regardless of the size of your network. This is important because even in a seemingly immutable environment, important changes, such as security updates, need to occur, and DSR helps identify those critical changes. This is why it’s important when looking at your security toolkit to decide if it is helping your environment be as close to immutable as possible or not. With items like critical security updates, you likely have a change window. You know exactly when a change is occurring, and outside that window, your system returns to an immutable state. It would be detrimental to your security posture if systems were changed randomly. Occasionally, a customer will ask why we report vulnerabilities in services that are installed but not running since they do not contribute to the attack surface. The reason we do so is that environments are not as immutable as we think; sometimes services are enabled and disabled without proper change management. Whether it is a user that only “needs the service for a few minutes” or a security tool that offers “on-demand service enablement,” there are plenty of ways that services can be enabled on systems. In a perfect world, with immutable environments, this would never happen. In a semi-perfect world, these enabled services would always be disabled as expected. However, we live in an imperfect world, and from time to time, errors within a host or a network, forgetfulness on the part of the user, corruption of a security tool’s function and any number of various reasons could cause that service to remain on longer than expected. This increases the attack surface on the host, introduces risk and demonstrates just how mutable our seemingly immutable environments truly are.

Another way to look at this would be to compare it to physical security

Have you ever noticed that when you walk into a convenience store, there are often chimes or an electronic bell? That is the corner store’s version of change management. It lets them know that someone has entered or exited the store. Now that store also has a backdoor, but it is locked and only used by the staff, so they don’t have a chime. We could talk about how lock picks could be used to open that backdoor, but what if it’s a real estate agent, someone you trust with a key? They could leave that backdoor open or forget to lock it again when they leave. This exposes the convenience store to unnecessary risk as they are expecting it to only be opened and accessed by a trusted individual, but one simple mistake changes that. It could be a dangerous mistake to make. Now imagine that the real estate agent is a trusted user or tool and the backdoor is a service they decide to enable. What happens when they forget to disable the service or an error prevents it from stopping?

Instead of taking that risk, why not avoid the situation all together?

This is why it’s important to operate under the principle of least privilege. Users don’t need access to enable and disable services. Security tools don’t need the ability to provide “on-demand service enablement.” These are examples of working around well-defined processes. They are examples of bad change. These small choices to allow unnecessary change can have negative consequences to both our organization and operational security and are best avoided at all costs.