Years ago, a client called me in a panic. Their servers were hacked and spitting out spam. They had to take their production environment offline and the business was hurting. As a CEO with an appreciation for the costs of downtime, I recommended they forgo incident response. I suggested they wipe the affected machines, rebuild from a known good backup, and get back on-line quickly. Once they were back on-line, we would help them improve their defenses to automatically block attacks.
The client’s information security officer did not like my strategy. I defended my approach adding that the cost of the investigation was not worth it. Unpatched systems were the likely culprit.
My pitch was ineffective, and the company chose to hire a well-known incident response company instead. They blew through a few hundred thousand dollars to uncover that their developers did not patch their servers, bots are quick to exploit vulnerable Apache installations, and their security tools are largely unmonitored and unmanaged.
This story highlights one of the more enduring challenges in information security: attack detection and response is complex, expensive, and seldom rewarding. This company did not discover any giant conspiracies. They were the victims of a garden variety attack. The downtime and investigation were expensive and debilitating. The culprit of the vulnerability was obvious: inconsistent system maintenance and weak security controls.
Challenges with Endpoint Security
While modern endpoint detection and response (XDR) products like Crowdstrike have come a long way at detecting, identifying, and stopping attacks, these platforms still demand a lot of care and feeding. Companies spend millions each year desperately trying to stop and clean up after attacks. Often this results in no insights, other than the organization has security vulnerabilities, like every other organization on earth.
What if none of this mattered? What if, as I suggested to my client, you could destroy and rebuild an environment automatically based on a schedule or triggered input. Attackers need time to infiltrate systems, move latterly, and exfiltrate data. If compromised host(s) vanished every few hours, hacking the environment would become enormously difficult (although not impossible).
This is the premise behind Moving Target Defense (MTD).
What is Moving Target Defense?
MTD, despite being a emerging technology, is not a new concept. A group of security researchers wrote a detailed book on the topic in 2011: Moving Target Defense, Creating Asymmetric Uncertainty for Cyber Threats. This book is a bit dense and written before container technologies existed. However, these researchers had a sound premise, even if the technology at that time was not fully capable of realizing those ideas.
MTD products create a compute environment that is dynamic and non-persistent. If a host or application is compromised, it is quickly destroyed and replaced with a known-good version from a trusted, read-only repository.
MTD currently comes in two flavors: infrastructure and endpoint.
The endpoint versions work internally within an operating system to randomize memory, isolate the core processor, and prevent unauthorized applications. This makes the individual system more difficult to crack. I am hesitant to call these products MTD, since they are merely endpoint products with specialized detection and protection capabilities.
Infrastructure versions work on a larger scale to constantly wipe and rebuild the components of an environment. These technologies are particularly effective in containerized environments. A properly architected Kubernetes or OpenShift environment, can become extremely resistant to attack using MTD.
In my opinion, I think it is a stretch to call endpoint products MTD. These are merely XDR products with MTD-like features. True MTD must happen at the infrastructure level.
What is so Great about MTD?
MTD is a profoundly effective defense because it is simple. It shoves aside all the complexities of detection, response, and incident handling. Rather than try to figure out how a system is hacked, MTD makes a hacked system irrelevant.
Moreover, MTD does not invalidate existing detection and response tools. It reduces the dependency on these technologies and can augment MTD capabilities. When MTD and XDR are paired together, the endpoint tools can trigger a rebuild based on the detection of an attack.
Why MTD Now?
The reason MTD has come of age is due to advancements in adjacent technologies. In the past, traditional hardware environments could not handle the dynamic nature of MTD. Virtualization brought MTD closer to reality, but was still clunky and unreliable.
With the advent of containerization, MTD not only becomes possible, but preferrable. Individual containers or pods can be trashed and replaced in a blink. If the application is architected properly and stores persistent state information in a database (and not on a filesystem) there is no functional limit to how often systems are refreshed.
Who Are the Players in MTD
There are few. As of December 2022, there is one lone company (I could find) with an infrastructure MTD product: R6 Security, out of Palo Alto. Their Phoenix platform works with Kubernetes as well as RedHat’s Openshift platform. It can work on a schedule to refresh the environment or configured to interoperate with other container security tools. I have seen this product in action, it is slick.
On the endpoint side, there is Morphisec. They claim to have a lightweight agent that performs core isolation, randomization, and other endpoint security enhancements.
What is the Future for MTD?
In a recent post on LinkedIn, Lawrence Pingree, Vice President of Emerging Technologies for Gartner announced that 2023 will be the year of Moving Target Defense (MTD). This is a bold claim for a nascent technology. However, I think Pingree is right. The conditions are right for this technology to take off.
With organizations moving more of their core workloads into containerized environments, it only makes sense to use MTD. Moreover, MTD bundled with other security capabilities creates an extremely resilient environment.
However, now that Gartner has said MTD is hot, expect a lot of other security companies to suddenly “add” this capability to their product.
The Bad News about MTD
MTD is not a panacea that will solve every security problem everywhere forever. There is one, big gotcha with MTD: application architecture.
For MTD to work properly, the application environment must be architected to handle constant change. This means using rest APIs and microservices, rather than traditional monolithic applications. It also means persistent information, cannot be stored within a container or on a filesystem. It must be stored in a shared repository such as a database. Moreover, state information must be isolated and protected, such that an attack could not break through the MTD layer, into the backend environment.
One fear I have about MTD is how it can break applications. This is why many endpoint products with these features struggle for traction. They offer all these novel memory and processor randomization tricks, that crashes regular applications. They quickly devolve into a configuration mess of whitelisting specific functions, which kind of negates the whole point of MTD.
This is why I believe the future for MTD is in infrastructure products and not endpoint.
What captivates me most about MTD is that it disrupts the entire hacking environment. Rather than trying to outsmart the hackers (which has consistently proven to fail) MTD devalues the hacker’s advantage. It does not merely level the playing field, it wipes the field out and replaces it with a new, fresh, clean one eliminating all the hacker’s clever attacks. MTD also forces an organization to architect their applications in a more modular, resilient manner.
MTD might not be the panacea that solves everything, but it has the potential to disrupt the security market as much as it disrupts the hacking environment.