Software brittleness may harden embedded systems
Connecting state and local government leaders
Brittleness causes programs to fail fast when under attack, which allows systems to quickly detect and disrupt cyberattacks and revert to known-good states.
Legacy systems in the government are hard to secure against cyberattack, and that goes double for the embedded, real-time systems at the heart of the many control systems in advanced weapons, power plants and mission-critical infrastructure.
Galois, a Portland, Ore.,-based secure software developer, has linked up with the Office of Naval Research under a three-year, $2.7 million contract to tackle the problem. Leveraging what it calls “software brittleness,” Galois aims to complement the fault-tolerance that already exists in these systems to boost their resilience in the event of attack.
The applications that run these systems already contain a certain inherent level of brittleness, said Tristan Ravitch, Galois’ principal investigator on the project. It allows them to automatically fail over to a known-good state when problems arise, ensuring the systems continue to run. That’s where the resilience comes in.
“We’re trying to enhance that,” he said. “We want such events [when an attack occurs] to actually turn into a crash, rather than have it go into some weird state,” which can then be exploited by an attacker.
The brittleness that Galois wants to insert into the software would make the code crash faster, he said, before attacks, memory corruption and overflowing vulnerabilities can damage critical systems.
Galois’ approach is to rewrite binary code, as the program is running, rather than the source code. It effectively takes a firmware image that it then runs through a tool that adds some capabilities to the binary, which is executed as a part of the code’s normal runtime.
That gets around certain problems. When a compiler acts on code, it often makes decisions about what is and isn’t valid, Ravitch said, and that doesn’t leave much room for errors that attackers can exploit. Also, by acting on the binary code, the company’s approach cuts out the problems in many regular “active” security solutions that rely on monitoring processes to make sure systems are doing what they are supposed to do.
That monitoring, however, introduces an additional attack surface, Ravitch said. Attackers can compromise this monitoring controller, without anyone knowing whether an attack is being made on the main system. With brittleness, enforcement mechanisms are built into the binary and execute as part of the existing code; there is no active monitor running. Attackers would need to subvert all of these enforcement mechanisms, and there could be tens of thousands of these kinds of brittleness nodes in the code.
Software brittleness is not applicable to all systems, Ravitch noted. It wouldn’t be used in general enterprise settings, but rather in those types of industrial control systems where a certain level of resilience is already built in.
It’s also ideal for those instances where space constraints won’t allow new hardware to be added and where, certainly in the case of embedded systems, things are already running at a high level. Brittle software requires only a few extra compute cycles, unlike “regular” cybersecurity solutions that can add significant overhead to the systems they protect. It also can be applied as much or as little as desired, while still fully protecting a program.
The Navy is the first government entity that Galois has worked with on software brittleness, because its ship-borne systems have a level of inertia they can rely on, Ravitch said. They can miss two or three time steps, for example, and the ship will continue to operate.
The goal of the three-year research contract is to prove that software brittleness is a useful cybersecurity solution for those systems that already have resilience, he said. The ideal deliverable would be a “reasonably automated” tool that could produce a brittle binary, which the company could test on other platforms and with other partners.
NEXT STORY: Finding PII in a haystack of data