This article is part of Overcoming JADC2 Software Challenges, a series of reflections on software challenges faced by the Joint All-Domain Command and Control initiative written by Tangram Flex’s CTO Matt Naveau.
In my article series so far, I’ve written a lot about software connectivity challenges faced by the US Department of Defense’s (DoD) Joint All-Domain Command and Control (JADC2) effort. To achieve the JACD2 vision of connectivity and instant access to data, a huge number of software systems have to communicate. While all of that connectivity promises to revolutionize the battlefield, it also creates a whole new set of cybersecurity challenges with real-world consequences. As adversaries exploit weaknesses in connected systems, they can cause real battlefield casualties: an aircraft might crash due to compromised sensor data or a command and control system might give false information to decision makers or a targeting system might be confused and behave incorrectly or power infrastructure might be programmed to fail at crucial times. In any case, the connected battlefield creates a whole new challenge in cybersecurity that can have major consequences in all domains of the modern battlefield.
The idea that cyber attacks could affect systems in the physical world is not new. Back in 2007, the Department of Energy demonstrated that a cyber attack could cause a power generator to explode. Since then, many well-known public examples like Stuxnet or the attacks on Ukraine's power grid have shown that this is not a theoretical or academic challenge. According to security firm Norton, statistically, there is a cyberattack taking place every 44 seconds, and the number of attacks targeting physical systems and connected devices is increasing (source). In all of these examples, connectivity – which is critical to the normal operation of systems – gives attackers a path to attack systems. The more connected systems are, the more opportunities available to an attacker to compromise a system.
Layered security is critical to counter a modern cyber threat, and no single solution eliminates all risk. Tools like firewalls and intrusion detection systems need to be combined with techniques for controlling user access and auditing system logs. There are good process frameworks for ensuring layered defense, such as the National Institute for Standards and Technology (NIST) Security and Privacy Controls for Information Systems and Organizations, commonly known as NIST 800-53. All of these tools and techniques are important for building secure systems, but the frequently underutilized approach of data validation may hold the biggest opportunity for “baking in” security for command and control systems.
Data validation can seem straightforward to do by hand when developing code. All new developers are taught to check that data is valid before their software uses it. If the developer assumes it is valid before using it, the software will misbehave every time it handles invalid or bad data. It’s a simple concept, but in practice, these validity checks are often omitted. Complex systems with many communication pathways can have an incredible number of places within the code where data is used, and verification on all of them can be easily overlooked. The sheer amount of integration complexity required for the JADC2 vision makes this verification challenge tremendous. Developers are also notoriously human, which means that they take shortcuts such as assuming that data validation has been done elsewhere in the software or that all data within a certain security boundary can be trusted. Increasingly, developers are relying on artificial intelligence (AI) to assist with the development of code, and as AI becomes more common, developer complacency in tedious areas of development like verification is likely to increase, no matter how good the AI is. Regardless of the cause, these validation shortcuts create opportunities for cyber attackers to exploit. Attack techniques like buffer overflows prey on a lack of validation, and in a hyper-connected environment like JADC2, the sheer quantity of connections presents a high likelihood that validation might get missed. For JADC2 to be cyber-resilient, data validation has to scale beyond individual developers.
An example of applying data validation effectively is a cross domain solution (CDS). A CDS is purpose-built to control the flow of information between security domains, such as securely connecting a classified and an unclassified network together. The stakes are high when bridging secure networks, and the need to prevent cyber threats of all types is critical. For the National Security Agency (NSA) to allow a CDS to be used, it has to consistently apply careful verification of all data transiting through the system. In the CDS community, this is often referred to as “message filtering” – verifying every piece of data sent or received in system communications –, and message filtering is great at thwarting many types of cyber attacks.
A CDS is a high-end security product best suited for critical locations in a system architecture. However, message filtering holds great potential to expand far beyond just CDS devices. Message filtering could be baked into every single connected device. When it is done well, message filtering limits the data coming into or out of a connected system to only what should be there and nothing else. For example, if the system is a global positioning system (GPS) receiver, a message filter can limit the outgoing data to only valid location messages, eliminating the possibility that a fault in the receiver could report an invalid location. Likewise, an autopilot system relying on the GPS location could have a message filter that only accepts valid locations. Without these message filters in place, an attacker might be able to inject an invalid location in the system, which could confuse the autopilot and cause the platform to crash.
It may seem like common sense to build systems this way, but in practice, this is often not done. Systems frequently have support for additional messages beyond the ones they need, and this “extra” behavior is often undefined and unpredictable. MOSA standards designed for multiple missions like Open Mission Systems (OMS) or NATO STANAGs often include dozens or hundreds of messages. Software systems using a standard typically require only a handful of these messages yet often utilize interface code with support for all of the messages from the standard. If not properly gated off with message filtering or another technique, an attacker could send any of these unused standard messages to cause unexpected behavior in a software system.
The effectiveness of message filtering to thwart cyber attacks has been shown in prior efforts. The DARPA HACMS program demonstrated that an autonomous helicopter, built to normal industry best practices, was heavily vulnerable to attack. A hacking team was easily able to gain full control of the aircraft through a simple attack hiding in a maintenance activity. After the team applied message filters to each of the aircraft software systems, the hackers were no longer able to gain control of the aircraft, even when they were given special access to a system on board. Message filters made the aircraft resilient to cyber attacks (There is a great video describing HACMS here)
Tangram Flex believes that message filters are needed everywhere in the JADC2 architecture for cybersecurity. HACMS is part of our heritage from our parent company Galois, and we believe that every system needs access to HACMS-like security in an easy-to-develop, easy-to-integrate package. That’s why we’ve built Tangram Pro’s Developer toolkit to generate message filters in every code interface library. I’ve written previously about how code generation can accelerate MOSA adoption, and this same generated code can also provide message filtering. Including message filtering in the interface simplifies integration (no extra software or hardware required) and reduces latency (the software only needs to process the data once) over stand-alone message filters. Generating message filters rather than developing them by hand allows for customization for each software component (include only the messages from the standard used by that component), scale (quickly generate as many different filters as needed), and flexibility (need a new message? Add it, and regenerate). We want our Developer toolkit to make HACMS-type technology available for all to thwart cyber attacks and better protect our warfighters.
Tangram has demonstrated the effectiveness of these generated message filters multiple times. In one example, the Tangram team showed how a message filter generated from Tangram Pro could protect a legacy command and control system from its known vulnerabilities without any code changes to the legacy system. Like the HACMS example, the Tangram team demonstrated first that the legacy system was vulnerable to crashing when it received bad data. The team then quickly generated a custom message filter that verified that only in-range, good location data could reach the system. With the added protection, the command and control system was resilient, and no software changes to the legacy system were required. In another example, the Tangram team similarly demonstrated how a space system type robot arm could be protected against unsafe movements with a generated message filter. With no filtering, it was easy to send commands to violently and dangerously move the robot arm, which could have devastating effects in orbit. With the message filter limiting commands to safe ranges, the robot arm moved safely every time, even when told to do something unsafe. In both examples, message filtering was extremely effective at eliminating many types of cyber attacks.
JADC2 faces a tremendous cybersecurity challenge as everything becomes connected. While layered security is an absolute must, message filtering holds the potential to counter many cyber threats in a big way. Our warfighters need systems that defend against cyber attacks. Let’s all pull together to build the cyber-resilient systems our warfighters need as we make the JADC2 vision a reality.