Securing military embedded systems is a giant challenge
StoryOctober 08, 2020
Updating and patching security vulnerabilities to limit the attack surface for the military’s embedded systems – especially legacy ones – can be a daunting task.
Embedded systems used by the military, many of which were once considered to be standalone and secure thanks to air gaps – network security measures used on one or more computers to ensure that a secure computer network is physically isolated from unsecured networks – now require security. Demand for interconnectivity of embedded systems is increasing their attack surface, often necessitating updates and patches to thwart vulnerabilities.
“It’s a huge challenge because there are a broad range of requirements and use cases for legacy embedded systems,” says Rich Lucente, principal solutions architect, DoD, for Red Hat North America Public Sector (Raleigh, North Carolina). “Some are either very isolated or surrounded by external mitigation measures that seemingly reduce the burden to secure the system, but in reality may provide a false sense of security.”
Other embedded systems are singular in purpose, or nearly so, with a limited attack surface that can also give a false sense of security. “Systems may rely on ‘zero trust’ mitigations, which themselves must be properly implemented with timely and intelligent responses to alerts and notifications,” Lucente adds. “The challenge increases with shortening attack time scales and alert fatigue. Continuous risk analysis is also needed to determine which protections are necessary.”
As more devices become interconnected and “more embedded systems are exposed to networks, the risk of an attack increases,” says Paul Butcher, senior software engineer and lead engineer in the U.K. for the AdaCore HICLASS project (Bristol, England). “The current trend within the military programs is toward systems of systems, such as Tempest or FCAS [Future Combat Air System], where complexity is one order of magnitude higher than in the previous generation.”
This direction leads to another challenge: “How do we refute that embedded systems are insecure and how do we convince a regulatory body that our system is free of vulnerabilities that, if undetected, could lead to malicious intent or even safety hazards?” Butcher posits. “Testing is key for ensuring systems are secure, but security engineering has other objectives to more traditional software-development life cycles and, across multiple sectors, this is where we’re seeing advances in security standards’ guidelines for ensuring security compliance.”
The high level of integration of the current typical military embedded systems also presents problems, according to Butcher. “This includes components of various origins, tightly integrated together within the same partition or on different partitions – typically including an RTOS, utility layers such as communication and crypto services, and application layers – through communication channels,” he says. “We expect it to increase and pose huge engineering problems at the specification, implementation, and integration levels, and further down at the supply-chain level as well.”
To secure legacy systems, security guidelines can be applied to remove or at least mitigate known or anticipated security vulnerabilities. “Automated tooling helps with hardening the system, but these efforts also typically include manual steps,” Lucente says. “In combination with mitigation, the testing regime validates that systems have no known vulnerabilities or can withstand anticipated threats. So there’s a combination at play where you try your best to secure and then validate the system.”
Emerging threats
New attacks exploit existing architectures in ways that were unforeseen when they were originally released, according to Irby Thompson, general manager of Wind River Security (Washington, D.C.), which acquired Star Lab in 2019 to broaden its portfolio with software for Linux cybersecurity.
Thompson points to attack examples such as Meltdown and Spectre, which exploited performance optimizations within modern microprocessors to allow unauthorized access to code and data. “These attacks were not known or foreseen when the microprocessors were released, so an entirely new class of threats was born to be exploit deployed devices,” he says.
The sophisticated cache side-channel attacks in modern processors “enabled the recovery of what was thought to be protected data – cryptographic keys, passphrases, etc.,” says Lucente.
Increasing sophistication of software solutions raises issues with the supply chain as well, Lucente points out: “Instead of black-bag physical infiltration of public and private sector facilities, nation-states are exploiting weaknesses in third-party software applications to penetrate networks and steal intellectual property to use for their own purposes as well as probe for weaknesses,” he explains. “This is particularly true with software ‘appliances,’ which aren’t appliances in the traditional sense, but instead yet another general-purpose computer running software. Security approaches need to evolve to meet current and future threats.”
Attack tools may grow in terms of their power, but the software within deployed systems largely stays the same. “While software patches can be applied, it’s a cat-and-mouse game between the developer and attacker,” says Thompson. “Strong embedded systems engineers with an eye toward security are always trying to stay ahead of the attacker by releasing updates to their systems before exploits are published in the wild. But without the right security expertise, budget, or time, this can be an uphill battle.”
Thompson is already seeing signs of artificial intelligence (AI) being used to create unique and unknown zero-day attacks – that is, previously unknown vulnerabilities or “vulns” – on devices at the intelligent edge. He expects to see these threats grow; he also believes that AI will discover more efficient ways to attack systems or vulns that only humans could have previously discovered. (Figure 1.)
[Figure 1 | The U.S. military expects that artificial intelligence (AI) will be used to further exploit vulnerabilities in devices used by personnel at the tactical and intelligent edge. U.S. Army photo.]
Updating/hardening embedded systems via software
To defeat these emerging threats, designers need to think about security hardening from the beginning of the design process. Treating security hardening as an afterthought or bolting it onto a system is no longer acceptable, according to Lucente. “Security hardening should ‘shift left’ from a one-time certification at the end to being a continuous part of development and operations processes,” he says. “We can no longer do long and expensive certifications as the landscape changes, including during and immediately after the certification process.”
Rather, Lucente says developmental and operational approaches need to evolve to a continuous cycle of developing and refining models of identified security threats and risks; defining approaches to mitigate or remove those threats and risks; implementing mitigations; measuring the effectiveness of those mitigations; and monitoring for new threats.
“Most security architectures aim to keep the bad guys out,” Thompson says. “They attempt to prevent an attacker from ever gaining administrative access to a system – ensuring the attacker doesn’t gain elevated privileges and have unauthorized access to code and data.”
But a properly hardened embedded system running Linux doesn’t care if the bad guy gets root access because it’s configured to protect the integrity and confidentiality of the system, using mandatory access-control policies defined by the embedded systems developer. “Code and data are accessed if and only if a policy is defined for that access – regardless of the privileges granted to the user,” Thompson explains. “In other words, if you’ve defined a policy that allows only write access to an audit log, then nobody, not even the administrator, will be able to read from that audit log. The mandatory access-control policy is enforced by Linux.”
Designers can also use a secure virtualization environment to separate and isolate embedded applications from each other, Thompson adds, to ensure that an attack on one application or operating system doesn’t enable unauthorized access to other applications or operating systems on the system.
“When you combine this policy control and enforcement with isolation, separation, tamper resistance, and reverse-engineering prevention features such as antidebugging, driver application signing, and the like, you turn an open Linux distribution into a locked-down distribution that allows the embedded system to do only one thing: that which is was intended to do by the developer,” Thompson notes.
Multilayered approach to security
What the industry needs, say industry experts, is a stepped, multilayered approach to security for embedded intelligent systems.
The goal of security engineering is “the protection of identified key assets,” according to AdaCore’s Butcher and Romain Berrendonner, a security-offering architect at AdaCore (Paris). They say that layered defense-security architectures can ensure a “strength-in-depth” approach by adding redundancy to countermeasures.
A single layer “can never protect against all threats or patch all vulnerabilities,” says Wind River Security’s Thompson. “Multiple layers of security, known as defense-in-depth, cover far more threats and vulnerabilities. If any single layer is defeated, the attacker still has to move through multiple other layers of defenses to achieve their objective,” he says.
“It forces them to be knowledgeable about many types of vulnerabilities, attacks, and attack tools. It can help increase the time to defeat significant – giving the developer more time to update the embedded system after a new vulnerability or attack is discovered.”
One interesting area of active research within industry is to use hypervisor security around separation kernels, Butcher and Berrenndonner point out. This approach plays a key role in the upfront design of modern secure systems, but it can also help secure legacy applications around midlife updates where security certification may otherwise not be possible.
The security executives also believe that formal specification of hardware interfaces will become more important as embedded systems become more complex, if only to keep the engineering of such systems manageable.
