Moving Target Defense — how a military strategy translates to the cybersecurity world [Q&A]
Introduced by the US military in the 1950s, Moving Target Defense (MTD) is the concept of controlling change across multiple system dimensions in order to increase uncertainty and apparent complexity for attackers, reduce their window of opportunity and increase the costs of their probing and attack efforts.
This technique has been translated to the cybersecurity world in recent years, but while the concept is strong, it’s a complex strategy that has many drawbacks if not executed properly. We spoke with Avihay Cohen, CTO and co-founder of Seraphic Security, find out more about how this concept is applied to today’s cybersecurity strategies, its pitfalls and how to implement it successfully.
BN: What does MTD look like for cybersecurity?
AC: Moving target defense is an old concept that was embedded in the 50s by the US Army. You can think of it as an ever-changing lock that keeps altering when you try to pick it.
There are many implementations for MTD on the operating system (OS) level, like address space layout randomization (ASLR). One of the fundamental and necessary parts of an exploitation is the predictability of the target. Plain and simple, memory corruption exploitation needs to rely on the predictability of the exploitable target. Before ASLR for example the address space of a process was predictable, but then ASLR came and randomized the address space of the process on each execution. This means the locations of certain memory addresses that the attacker knew of when they developed the exploits are no longer valid on any other machine. So, it’s changed a lot of things, and ASLR on its own is highly robust. It provides prevention for specific memory corruption bugs, but the field matured and there are now more sophisticated ways to bypass those defenses. ASLR is still a thing, and it’s in your OS now. Every process that you execute actually executes in an ASLR fashion.
There are startups that wanted to utilize this approach to other areas in the process, like changing the address space of loaded dynamic libraries for example. This caused a lot of overhead and resulted in a lot of functionality breakage, so it didn’t take off. Although, for specific areas, ASLR works great because it’s quite simple and robust. For other applications, it’s extremely complicated, but for browsers it’s totally different. In a browser, you’re not at the OS level because there is something in between called the JavaScript engine. The reason this approach works so well for browsers is because we have a middleman in between the OS and JS code which is the JavaScript engine that is under complete control.
Because of the techniques of MTD, the robustness of it is outstanding because you are not relying on detection. This is the most problematic part of any security solution. It’s either the false positive rate or, more importantly, the false negatives. What happens if we fail to detect the threats that are becoming more and more sophisticated?
The ability to prevent threats without detecting them is huge. This is exactly what ASLR is doing — it’s not doing any detection at all. It’s preventing specific cases of memory corruption bugs. At the browser level because you don’t interact directly with the OS, but instead interact with the JavaScript engine. Any exploit in the browser needs to rely on specific, predictable features in the browser. When implementing MTD for browsers, you create an unpredictable environment without causing major performance impact or functionality breakage while changing the entire environment. So, it’s not just a single aspect like ASLR, but it’s many components together that create unpredictability that results in high prevention rates without any need for detection. The prevention is completely independent from the detection which makes the browser highly robust against exploitation.
BN: Why are organizations currently struggling to implement MTD strategies?
AC: Most organizations do not know about MTD, unless they have more sophisticated security programs. There are quite a few companies that are doing some sort of MTD at the OS level, but it has not proven to be successful because it causes major performance impacts and functionality breakage. You obviously want employees at work to not mess with the bugs and the breakage of native applications, so that’s why it was extremely problematic to implement for those organizations that were familiar with those techniques.
There is a long MIT survey that looked at many companies that leveraged some type of MTD strategy and compared them. After looking at all their capabilities, the results of the survey highlighted that the field itself is not mature enough for MTD. So, the main reason MTD has not gained wider popularity is because it can cause specific performance impact or functionality breakage when not executed properly, and more importantly, many of the proposed solutions were simply not enough.
BN: What does success look like for a properly implemented MTD strategy?
AC: As I’ve shared, MTD strategies do not rely on detection. If you only have prevention capabilities and zero detection capabilities, the way to get an indication that the strategy is working is not getting indications at all. If you’re not getting feedback from your users that something crashed or there are bugs, then this is one indication that your strategy is doing its job.
BN: What types of organizations would you recommend use MTD strategies?
AC: If there is an MTD approach that can provide robust prevention without any loss of functionality or major performance impact, then I advise any organization to implement it. MTD provides organizations with the ability to prevent sophisticated, as well as not so sophisticated attacks, without relying on certain algorithms to detect those threats because it’s there working all the time, and you’re safe while deploying it. I really do believe this approach could work for any organization.
Image credit: lightsource/depositphotos.com
