In October 2018, the GAO released a report on cyber vulnerabilities in weapons systems. This report highlights the need to consider cyber survivability in the weapons system design process. At Star Lab, we think virtualization is an enabling technology that helps address many of the concerns raised in the GAO report. In this post we will share two virtualization techniques that we often use for securing systems: 1) minimizing a system’s attack surface and 2) isolating components within the system. To demonstrate these concepts, we’ll use the example shown below. The system effectively has three networks: the CAN bus, the Local Area Network (LAN), and an RF link to DoD Networks. The CAN bus connects various cyber-physical systems that control the core functionality of the weapons system, the LAN is used for connecting the traditional computing platforms, and an RF link provides status information to ground control. The maintenance system bridges the gap between the CAN Bus and the LAN, allowing systems on the LAN to obtain status of the weapons system.

An attacker trying to control the system remotely has a couple of options for initial exploitation of the system: 1) remotely exploiting the communications system or 2) obtaining physical access to exploit one of the other machines. Let’s assume the system engineers built a robust and secure communications system, so consider the physical access option. The database server is likely a commodity server running a commercial operating system. A sophisticated attacker could recruit someone with physical access to insert a USB drive with a malicious payload demonstrated by the BadUSB attacks. Typically, the USB port of the database server is not necessary for normal operation of the weapons system. Unintentional, unused access vectors such as USB ports are often the weakest points of attack. Virtualization can eliminate this problem by disabling physical interfaces to virtual machines by default, requiring engineers to explicitly whitelist interfaces that will be visible within a virtual machine. The screenshot below shows the tooling interface for Star Lab’s Crucible. Our tools allow designers to assign PCI devices to a specific virtual machine. This isolates devices from system software and makes it easier to understand the connectivity throughout the system.

Obviously it’s not ideal for an attacker to gain code execution on any component of a weapons system, but it’s crucial to limit the attacker’s ability to maneuver if they gain access. An attacker could leverage execution on the database server to pivot to the maintenance system, resulting in the attacker gaining control of the cyber-physical systems connected to the CAN bus. Controlling the CAN bus would give the attacker full control of the physical operation of the weapons system. Before applying virtualization to protect the systems connected to the CAN bus, we’ll first have to define a notional software architecture. We’ll assume that the Maintenance system runs two daemons. The first listens for requests from systems on the LAN. The second interacts with the CAN bus to determine the state of the system. We’ll call the first daemon land and the second daemon cand. Assume the two daemons communicate using a local UDP socket. After gaining execution on the database system, the attacker would probe the system for vulnerabilities. Of particular interest would be weaknesses that would provide an opportunity to access the maintenance system. While there are many potential vulnerabilities, misconfigurations that expose privileged components are the easiest to exploit. For example, a minor misconfiguration could result in cand accepting commands from the local network interface instead of the loopback interface. This would allow an attacker to bypass land and send arbitrary commands over the CAN bus. We would advocate virtualizing the maintenance system, and running three separate virtual machines or domains, to include:

network domain
land domain
cand domain

The network domain will be solely responsible for interacting with the network interface. A virtual bridge interface connects the land domain to the network domain and a second virtual bridge interface connects the land domain to the cand domain. This design ensures that a software error in the cand application is not directly exposed to the LAN, thereby requiring an attacker to chain together multiple exploits to access the CAN bus. Star Lab’s Crucible tooling (see screenshot below) makes it easy to create and assign virtual network interfaces between domains.

A more naive design might combine the network domain and the land domain, but we recommend isolating the network interface into a purpose-built domain. Exploiting the network interface driver generally gives an attacker execution in kernel space, essentially enabling full control of that virtual machine. When the networking interface is in an isolated domain, an attacker will have to find additional exploits to bypass land and directly interact with cand. We are well aware that modern weapons systems are composed of more applications and interconnections than the simplistic representation presented above. The reality of such systems is they are too complex, and engineers constantly struggle to protect them using the same legacy tools and design paradigms. Star Lab’s Crucible offers a virtualization platform as an alternative approach to weapons systems design, one that doesn’t compromise performance for security and robustness. Using our tools, engineers can design with security in mind, helping them eliminate risks from single points of failure, human or cyber. Cyber attackers have the advantage of constantly adapting, using new tools and techniques to attack these largely static systems. Weapons systems must too adapt if they are going to have a chance at being resilient in the face of modern threats.

Designing for Isolation Using Virtualization