Moving Target Defense

COAR is working on several different moving target defense (MTD) technologies that fall under the general category of proactive defense strategies. We have been and continue to be actively involved in MTD research groups from the Association of Computing Machinery (ACM), the Air Force Research Lab (AFRL), Ratheon BBN, Florida Institute of Technology (FIT), University of New York at Buffalo, Iowa State University, Sandia National Laboratory, and Pacific Northwest National Laboratory.

Multiple OS Rotational Environment

Operating systems are a significant attack vector for would-be malicious actors in cyberspace. Of particular concern are zero-day vulnerabilities. These types of vulnerabilities, particularly the recent Heartbleed OpenSSL vulnerability and the glibc Ghost vulnerability, have proven to be a perfect test for the defensive strength of the Moving Target Defense (MTD) platforms. Recently, MTD strategies have grown in popularity due to their ability to enhance resilience and force attackers into uncharacteristic behavior. The MTD prototype discussed below acts as a proactive defense strategy that offers increased protection against an attacker being able to probe for and exploit vulnerable operating systems (OSs). The main goal of MORE MTD is to reduce the number of zero-day exploits on client-server applications.

Testing shows that OS diversity in an MTD reduces impacts of zero-day vulnerabilities and increases the resilience of the protected application. While there is no way to eliminate zero-day vulnerabilities, our results demonstrate that platform diversity and rotation offer improved security that drastically reduce an attacker’s ability to exploit those vulnerabilities. The likelihood of a successful attack against a known vulnerability decreases proportionally with the time between rotations. Additionally, any downtime to the secured application in the event of a successful attack is limited to that same time window.

How rotation works:

The Daemon establishes a SSH connection with the Live machine

The Live machine is moved to the spare IP for intrusion detection

The Daemon establishes a SSH connection with a selected machine in the list of available servers (selected as a queue or randomly)

The selected machine is moved to the active server

Intrusion detection is run on the machine that was taken out of the Live IP

If the Server was not compromised it is added to the list of available servers

If the Server was compromised it is added to the list of unavailable servers and will not be placed into the rotation

Though the security landscape has been fraught with major vulnerabilities over the past year, MTD has shown itself to have validity as a defensive technique. Zero-day vulnerabilities are one of the most difficult problems security professionals face, as there is no real defense against them. MORE MTD proceeds from the assumption that zero-days will be found in existing systems; however, its proactive nature increases the diffuculty for attackers to exploit such vulnerabilities and lowers the consequences of any such exploitation. Increasing our platform diversity is a key part of our strategy moving forward, but the essential effectiveness of our approach has been proven. Increasing attacker uncertainty and system resilience are themes that will continue to unite the cybersecurity community, and strategies such as MORE MTD that do both are valuable in that context.

Dynamic Application Rotation Environment for Moving Target Defense

Owing to the ubiquity of web applications in modern computing, the server software that delivers applications is an attractive attack vector for would-be malicious actors in cyberspace. Dynamic Application Rotation Environment (DARE) MTD uses the two most common and freely available web servers, Apache and Nginx. It runs a single application on both platforms, redirecting incoming traffic to one server or the other at a random interval. The goal is to mitigate any unknown vulnerability in one of these platforms by reducing the amount of time that platform is exposed to a would-be attacker. Like the MORE MTD strategy, this variability increases the cost of reconnaissance on a target and reduces the likelihood of exploiting any zero-day, or previously unknown, vulnerability.

One virtual machine (VM) is selected at a given time to handle all network traffic, and it is known as the active VM. At a predefined interval, which may be as short as 15 to 30 seconds, the active VM is switched. When a VM becomes inactive, the integrity of the file system is checked for signs of attack and removed from rotation if any integrity compromise is detected. The procedure mirrors MORE MTD, which set the lower rotation window to 60 seconds. The idea of both strategies is to rotate at a suitable interval in order to accomplish the following:

Prevent accurate fingerprinting and identification of entry points.

Thwart persistent attacks by reducing the exposure of vulnerable software.

Reduce the viability of any gain to the attacker by consuming extra time and resources.

DARE MTD offers significant promise as a proactive defense against web server application-level vulnerabilities. It succeeds in both the goals of increasing uncertainty (as shown in the VM fingerprinting tests) and increasing resilience (as shown in the exploit mitigation tests). There are a number of unsolved problems with DARE MTD and MTD solutions in general. Though in the present set of experiments, we showed that performance is actually increased over a static Apache web server, performance during rotation remains an area that requires further exploration. Additionally, there are several unanswered questions regarding session maintainability, stateless transport mechanisms such as the user datagram protocol, and overall maintainability with regard to patching and system overhead. However, the conclusion remains that MTD technologies, such as DARE MTD, have the ability to offer significant benefits for protecting high-value targets.

Stream Splitting Moving Target Defense

Cyber infrastructures can be attacked with relative ease, as most of the current infrastructures have configurations with a single, static network stream for communication between any two nodes at a particular time. The aim of this project is to explore and design a TCP moving target defense technique by splitting the payload (data) over multiple TCP streams, making it difficult for the attacker to access the entire communication payload and gain meaningful information. TCP stream splitting (SS) splits a network stream into multiple streams, making it difficult for an attacker to attack the system by eliminating the advantage of fixed system configurations and network architecture.

By mathematically defining a diversity quotient and a desirable state, it follows that we would want to design our software to attempt to reach the desired state.

At the launch of a network transmission, we will compute a diversity quotient Q and compare it to a user configured threshold.

If Q is greater than the threshold, the software will attempt to increase diversity by adjusting the number of sub-streams.

Counterintuitively, in some cases reducing the number of sub-streams may actually reduce Q (increasing diversity).

SS-MTD is designed to be media agnostic. Although initial prototypes focus on traveling over different paths on the internet using TCP/IP, the protocol itself is designed to operate at the application layer, over any protocol, over any media. To accomplish this, when not using a stateful lower level protocol, like TCP, we have a dual-layer reassembly algorithm. Our full-stream reassembly algorithm still focuses on the integrity of the original communications stream, but our sub-stream reassembly algorithm allows for the retransmission of individual packets or chunks without triggering a failure of the channel.

SS-MTD is similar to multipath TCP (MPTCP), though it has several key differences. SS-MTD does not aim for layer 4 backward compatibility, it runs totally at the application layer. This means that there are no flags in the TCP headers to signal that this stream is running over multiple paths. Also, MPTCP has no way to measure the diversity of the paths that communication goes over.