Don't Wait to be Breached! Creating Asymmetric Uncertainty of Cloud Applications via Moving Target Defenses

TL;DR

This paper tackles zero-day vulnerabilities in cloud-native applications by proposing Moving Target Defense (MTD) as an immune-system-inspired security framework with two layers: infrastructure regeneration and application-layer diversification. It formalizes a control-loop that regenerates infrastructure nodes to purge undetected intruders while simultaneously diversifying microservice architectures at runtime to disrupt replayed attacks, supported by code-generation-based transformations. Empirical evaluations across AWS, GCE, Azure and OpenStack with reference apps show that attacker dwell time can be reduced to minutes and the attack surface can be changed by up to approximately $98\%$, making scripted attacks hard to reuse. While promising, the authors acknowledge limitations and emphasize the need for further evaluation, integration with secure development pipelines, and consideration of intelligent regeneration strategies and countermeasures against adaptive threats.

Abstract

Cloud applications expose - besides service endpoints - also potential or actual vulnerabilities. Therefore, cloud security engineering efforts focus on hardening the fortress walls but seldom assume that attacks may be successful. At least against zero-day exploits, this approach is often toothless. Other than most security approaches and comparable to biological systems we accept that defensive "walls" can be breached at several layers. Instead of hardening the "fortress" walls we propose to make use of an (additional) active and adaptive defense system to attack potential intruders - an immune system that is inspired by the concept of a moving target defense. This "immune system" works on two layers. On the infrastructure layer, virtual machines are continuously regenerated (cell regeneration) to wipe out even undetected intruders. On the application level, the vertical and horizontal attack surface is continuously modified to circumvent successful replays of formerly scripted attacks. Our evaluations with two common cloud-native reference applications in popular cloud service infrastructures (Amazon Web Services, Google Compute Engine, Azure and OpenStack) show that it is technically possible to limit the time of attackers acting undetected down to minutes. Further, more than 98% of an attack surface can be changed automatically and minimized which makes it hard for intruders to replay formerly successful scripted attacks. So, even if intruders get a foothold in the system, it is hard for them to maintain it.

Figures (9)

• Figure 1: The cyber attack life cycle model.Adapted from the cyber attack lifecycle used by the M-Trends reports, see Table \ref{['tab:dwells']}.
• Figure 2: The control theory inspired execution control loopcompares the intended state $\rho$ of an elastic container platform with the current state $\sigma$ and derives necessary scaling actions. These actions are processed by the execution pipeline explained in Figure \ref{['fig:pipeline']}. So, platforms can be operated elastically in a set of synchronized IaaS infrastructures. Explained in details by Kra2017a.
• Figure 3: The execution pipelineprocesses necessary actions to transfer the current state $\sigma$ into the intended state $\rho$. See Kra2018 for more details.
• Figure 4: Infrastructure specific runtimes of IaaS operationssee Kra2018.
• Figure 5: Typical Microservice Attack Surfaces illustrated with the PetClinic Application spring_petclinic