Moving Target Defense for our Intelligence Platform

Moving Target Defense (MTD) is considered today to be the most effective innovation in the field of cybersecurity. 

 

Until now, IT infrastructures were regarded as unchangeable and stationary. A great deal of effort has been invested in protecting these infrastructures by identifying, preventing and eliminating threats. MTD is a completely new paradigm in the arena. MTD creates a dynamic attack surface for moving targets, thus creating asymmetric disadvantages for the attacker. The playing field between the defender and the attacker becomes evener.

 

A possible implementation of MTD is done by using Software Defined Networking. As described by Cyel, this continuously changes the attack interface. Attackers will find it difficult to identify and track targets in the first place as their targets seem to hop around in the Colosseum. 

 

This white paper can be seen as the starting point of MTD for Traversals’ platform. The ideas described herein will evolve constantly to further develop the cybersecurity capability of Traversals’ solutions.

Technical Overview

Secure Software Supply Chain

In Secure Software Supply Chain, Traversals described its new CI/CD tool for secure artifact creation and deployment. This pipeline helps us to address security issues, prevent license violations and to keep dependencies up to date with the lowest efforts. 

 

Every commit to the version control system results in triggering the CI/CD pipeline and finally in a new deployment unit of the affected application. The time between commit and final deployment is currently about 30 minutes. If necessary, the time can be reduced by deactivating time-consuming checks.

 

 

A good CI/CD solution is one of the low-hanging fruits when it comes to designing the attack surface dynamically. The faster new software versions can be deployed, the faster the structure of a complex software solution changes. This approach cannot keep up with the speed of Cyel’s Software-Defined-Network solution, but it can be seen as a supplement to it, thus it further increases the security of a system.

 

The mentioned CI/CD tool is flexible and configurable and is now in production for the build process of our Intelligence Platform. Thus, the same toolset can now be used to implement the following Moving Target Defense ideas.

Autoscaling as Security

A large part of the Intelligence Platform is based on the serverless concept. In the past there was a large monolithic architecture, but now the large application is divided into many small functions. In case of the Intelligence Platform, there are functions for providing the static and web-based user interface, functions for persisting data or functions for processing data. These functions can be written in different programming languages such as Java, Python or NodeJS. All functions have in common that they are containerized and stateless.

 

The number of function requests is the basis for the orchestration of the functions. Increasing function requests will result in more function instances. If there is no load on the system, then in extreme cases no instance of the function runs and the system is dormant. Technically this means that no container is started for any of the functions resulting in a decreased attack surface. 

 

The orchestration of the functions uses the features of Kubernetes. When the functions are started, it is not possible to predict on which Kubernetes node the functions will ultimately run.

 

This serverless concept, which was implemented in the Intelligence Platform, creates a completely dynamic system that will look different every minute. It can be seen as one step toward Moving Target Defense.

Using Credential Managers

With distributed systems, one is inevitably confronted with the question of when and how to transfer access credentials, for example to databases, to the containers. There are already mature and sufficiently tested solutions for this, which take over the administration of credentials. 

 

Using Hashicorp Vault and its Spring Cloud integration in Traversals’ Moving Target Defense approach, it is possible to query access credentials to an Apache Cassandra database at the start of an application. Hashicorp Vault generates a combination of user and password in the background, which is securely transferred to the application. These credentials are stored within the Cassandra database by Hashicorp Vault with a certain time-to-live. The combination loses its validity after a certain period of time, e.g. 1 day, and can no longer be used. If an application is ever compromised, the damage is be limited in time.

 

The heart of the system is the credential manager, which makes credential handling safer and more dynamic. It must of course be assumed that the credential manager can be trusted.

Changing Base Images

All modules of the Intelligence Platform are containerized by using Docker and orchestrated by Kubernetes. In most of the cases, the base image relies on Official Docker Images, e.g. Alpine Linux images from AdoptOpenJDK. Alpine Linux is a security-oriented, lightweight Linux distribution based on musl instead of glibc as C/C++ compiler. In case of Java, Clojure, Kotlin or Scala, the JVM runs on musl instead of glibc.

 

In order to change the attack surface, the development team can select and validate various base images for the Intelligence Platform modules and let the CI/CD tool decide randomly which one is selected for deployment. In case of Java and all derivatives it can be a randomized decision between Alpine and non-Alpine Linux distributions.

Changing Host Images

As already described, Kubernetes is used as central container orchestration. The Kubernetes master dynamically distributes the load to the Kubernetes node. The Kubernetes software runs on machines with a Linux operating system. The machines can run as bare metal or as a virtual machine installation. 

 

In the past, we could successfully create fully automated ISOs for the operating system installation, which already contained all the necessary software packages, patches, etc.. This makes it possible for machines to boot the ISO over a network by using the PXE protocol. Immediately after booting the ISO, the respective machine is ready for operation and does not need to reload any further packages.

 

In the case of the Kubernetes nodes, this would mean that they are also stateless and will get their operating system installation over the network when they are powered on and don’t need any hardware disc any longer since they run in RAM.

 

For the Moving Target  Defense concept, this means that the CI/CD solution would be used to create different and trusted operating system installations in regular intervals. Linux distributions could be Ubuntu or CentOS. The decision which node would boot which ISO would also be randomized and controlled by the CI/CD solution.

Switching to Micro VMs

Within the Intelligence Platform, containerd is the runtime that manages the entire lifecycle of a container. Containerd fully leverages the OCI Runtime Specification, image format specifications and OCI reference implementation (runc). In addition, there is a Docker daemon on top of containerd, which provides further necessary features for the management. 

 

The big weakness of the Docker daemon is that it runs with root privileges. This means that if a service were to break out of the docker container, it would immediately have root privileges on the respective Kubernetes node. The damage as described in CVE-2018-15664 would be severe.

 

On way to prevent this is by introducing another abstraction layer. In contrast to conventional containers, the so-called micro-VMs can provide an additional isolation layer via the KVM hypervisor. Firecracker is one implementation of the micro-VM idea. Like traditional containers, Firecracker micro-VMs offer fast start-up and shut-down and minimal overhead. The big advantage of Firecracker is, it offers strong hardware-virtualization-based security and workload isolation. Containerd is still the runtime that manages the entire life cycle of a container. It keeps the benefits of containerization but eliminates the security concerns.

 

To improve our Moving Target  Defense, there are first tests planned for Q2 of 2020 to replace Docker with micro-VMs such as Firecracker.

Summary and Consequences

The ideas described in this paper make the deployed instance of the Intelligence Platform look differently within a short time span. Adversaries will lose their asymmetric advantage in having time to study a system, identifying its vulnerabilities and choosing the time and place of attacks. The described approaches are tested and some of them are already implemented, and the rest are part of our road map. 

 

The Moving Target Defense paper is intended to show that Traversals work consistently with countering modern cyber threats and that both knowledge and competence are available to implement defense effectively and efficiently.