Published in The Cyber Edge
Data in deployed networks must be protected from within.
Embedded systems are emerging as the latest challenge in the drive to secure deployed U.S. military technologies, including those residing within weapons and flight controllers. Because they are deeply entrenched inside critical hardware, these systems can be tricky to safeguard, so cybersecurity and cyber resiliency must be considered at the beginning of the design and architecture process. And although upgrades can boost embedded systems’ cybersecurity, system operators must determine when the potential pitfalls of doing so outweigh the benefits.
Future Army aviation systems will need to be able to operate against adversaries with advanced capabilities even in a contested airspace. Embedded systems need to be designed with cybersecurity in mind and may require some size, weight and power tradeoffs. U.S. Army graphic by Aviation and Missile Research, Development and Engineering Center VizLab
Implementing cybersecurity can alter fundamental architectural choices for embedded system design in numerous ways. The good news is that rules of thumb help guide the decision-making process.
The first rule is to understand the real risks to the system. Cybersecurity is not simply a functional requirement to be satisfied; it is a cat-and-mouse game against myriad potential adversaries. If a system designer does not understand the risks to be mitigated, precious resources might be wasted for too little additional security.
Hardware selection can profoundly affect an electronic system’s ability to withstand cyber threats. Attacks such as those that take advantage of the Rowhammer vulnerabilities inherent in dynamic random-access memory enable malicious actors to subvert system security remotely. Similarly, the Meltdown and Spectre vulnerabilities exploit the side effects of processor pipeline architectures to enable cyber attacks. While many cyber attacks can be mitigated via firmware updates, these fixes may result in unintentional effects, including increasing power consumption and affecting processing or timing, all of which can limit hardware performance.
In addition, how the system’s data flows can have secondary effects on system performance. For example, encryption techniques used to ensure system and data confidentiality during transit and storage can dramatically impact central processing unit performance because resources must be diverted to encrypt data prior to transmission and to decrypt it after receipt. Tacking on processing requirements to secure the data also can increase system latency and decrease overall throughput. If data authentication and integrity are required, even more cryptographic processing will be needed to sign and verify the data, also adding to system overhead.
Other unique aspects of embedded systems’ architectures also can require special considerations that affect the implementation of cybersecurity measures. For example, these systems often are situated in locations with limited accessibility. Legacy system interoperability issues, specific safety and physical security conditions and, depending on the platform, size, weight and power (SWaP) limitations, may all pose architectural challenges.
Another security obstacle is the very nature of embedded systems. Because they may be entwined within existing systems that are connected only intermittently, the opportunities to install or upgrade cybersecurity measures can be limited, restricting the amount of time available to install updates that protect against new attacks or address recently identified vulnerabilities.
This situation is exacerbated when the architecture features both new and old embedded systems; legacy connections might not have been updated to counter the most recent cyber attacks and threats. Under these circumstances, rather than updating virus definitions, maintenance time may be best spent addressing mandatory access controls and disallowing unapproved processes from being able to be executed.
Cybersecurity guidance often advocates updating operating systems, libraries and applications to the latest versions to mitigate any disclosed security issues. However, because many embedded systems manage the function of critical hardware such as flight controls, weapon systems and power controls, they may need to undergo rigorous certification processes to ensure their safe continued operation. As a result, updating critical systems with every new software patch or version quickly becomes infeasible because each might require a new round of extensive and costly testing. Partitioning the systems so safety-critical functionality is sequestered from other operations as much as possible is one way to address this issue.
The multiple locations of embedded systems also can pose distinct cybersecurity challenges. While outsider access to desktop computers and servers can be restricted physically, embedded systems reside at numerous sites, increasing adversaries’ opportunities to gain access. Consequently, embedded systems’ cybersecurity cannot only be applied to interfaces connected by architecture, design and function, but also must be applied to every available connection. One approach is to modify the hardware to physically remove all unnecessary connections.
For SWaP-constrained embedded systems, it is crucially important for designers to understand cybersecurity requirements and the impact on the architecture early in the design process to ensure availability of adequate SWaP capabilities.
For example, helicopters have space and power constraints and additional weight can limit a mission’s duration. In these environments, it may not be possible to increase processing requirements to support cybersecurity techniques such as encrypting communications, checking for viruses, monitoring system behavior or acting as a firewall.
Meeting stringent cybersecurity requirements in embedded systems is challenging, but the National Institute of Standards and Technology (NIST) Risk Management Framework (RMF) provides a means to select, assess and monitor controls to manage risk for systems. Although the framework was not designed specifically for embedded systems, it proffers a methodology that can be tailored to address the challenges embedded systems pose.
By using the RMF, categorizing a system appropriately, and then selecting and monitoring the appropriate controls aligned with the system’s operational behavior, risks that might be overlooked during normal functional architecture, design and development stages can be identified.
A formal process can help highlight possible cyber risks, but embedded system designers must then choose tradeoffs based on those risks. One way to limit risks is to leverage convergence in requirements.
For example, if an avionics system must manage safety-critical behavior as well as cybersecurity, many of the data artifacts generated for safety-critical certification related to architecture, design, process, testing and configuration management also can be used to satisfy similar RMF controls related to processes and procedures. Likewise, operational controls related to limiting outside access and partitioning can be used to meet safety-critical and cybersecurity goals. What’s more, aligning requirements from divergent certification authorities, if possible, can help minimize costs and improve schedules.
Another way to ensure embedded systems are cyber resilient is to design the systems to be updated. It has become increasingly important to ensure that hardware vendors distribute firmware updates quickly and reliably, which can affect testing that needs to be quick, robust and thorough. Systems also must be designed for fast reintegration and tested with minimal overhead.
It’s critical to ensure that trusted solutions continue to be delivered to meet today’s challenges. Working closely with commercial vendors can significantly reduce the risks associated with implementing cybersecurity in deployed embedded systems. Understanding the interplay between cybersecurity techniques and the embedded solutions they are intended to protect enables the system designer to deliver the appropriate system solution: one that balances risks and resources appropriately.
Read the full article here