Embedded systems - specialized, self-contained computer systems designed for specific functions within a larger system or device - continue to increase in popularity, with the global market size expected to reach USD 258.6 billion by 2032. While embedded systems exist in consumer applications, such as household appliances, electronics and wearables, they are also prevalent in industrial settings where they support control and automation, process monitoring, and data collection and analysis. In agriculture irrigation systems, for example, embedded systems control the timing of watering via moisture sensors; likewise, in manufacturing and supply chain use cases, embedded systems control robotics and automate assemblies.
In light of the growing pervasiveness of embedded systems, businesses must recognize that these systems are uniquely vulnerable to cybersecurity attacks. As such, organizations need to understand why embedded systems are so open to attack and respond with the best cybersecurity practices. Moreover, companies should stay up to date on the ever-evolving body of cybersecurity legislation – especially those that apply or indirectly affect embedded systems.
Why are embedded systems so vulnerable?
Embedded systems, like any other technology, are susceptible to various cybersecurity attack vectors, including hardware security flaws and attack strategies like buffer overruns, man-in-the-middle and denial-of-service or DoS attacks. In the US, for example, these attacks could be homegrown, but many advanced, persistent threats come from competing countries. Although these particular risks are nothing new, embedded systems are becoming more vulnerable because they increasingly connect to the Internet.
Previously, embedded systems functioned in isolation, connecting to an internal network rather than the outside world. However, since the rise of Internet of Things (IoT) devices, most embedded systems, while capable of being monitored and managed from anywhere, can now get attacked from anywhere, amplifying cybersecurity risks tenfold. For starters, when embedded systems connect to the Internet, they become part of a larger digital domain, expanding the attack surface to a global hacking community. Embedded systems connected to the Internet are also integrated with other systems (the cloud and mobile apps, among others), further widening the attack surface. Likewise, since embedded systems were once isolated devices requiring minimal security protocols, they typically are unprepared for a new slate of Internet-based threats.
Additionally, embedded systems are difficult to keep secure, with the fast-moving nature of online risks making patches and updates obsolete. While this is not a problem for commercial applications, it is a problem in industrial and medical settings. Embedded systems also have longer service lives, more than 10 years longevity usually, meaning developers must counter a lifetime of unknown and unpredictable cybersecurity threats during the design phase and, of course, throughout the product lifecycle. Plus, the limited flexibility of embedded hardware restricts the security defenses developers can leverage post-market release. If these restraints weren’t challenging enough, embedded systems are likewise in physically out-of-the-way or precarious locations outside of traditional IT networks and their protection as e.g., firewalls, bearing in mind as well that many systems are battery powered and not always connected, being even more difficult to monitor and update remotely.
Safeguarding embedded systems against cyberattacks
Not every embedded system is an IoT device - however, because the world continues to become more connected, most IoT devices contain an embedded system. As such, securing IoT devices requires businesses to consider the embedded systems inside. One best practice organizations should incorporate is root of trust, which uses protected hardware mechanisms to keep private crypto keys (encrypted data) confidential and unchanged. Another is secure boot, which utilizes the signature provided by a device trust anchor to safeguard the software authenticity running on a device. Executable space protection is also a best practice that organizations should incorporate to prevent attempts by bad actors to execute machine code in specific memory regions. Similarly, by stacking canaries, a business will enable the operating system to detect a stack buffer overflow before malicious code gets executed.
As for IoT architecture, companies must manage the security capabilities of devices already in the market. To that end, product lifecycle management is critical to ensuring a device remains compliant with legislation from approval to end-of-life. Cloud-based monitoring, update services and maintaining a comprehensive analysis to build custom software bill of materials (SBOM) are all ways that manufacturers can watch for emerging vulnerabilities during the lifespan of a device while fulfilling transparency obligations. Rapidly pushing critical updates to counteract new threats as the embedded system operates in the user setting is also crucial to IoT architecture security. Furthermore, involving stakeholders in the critical infrastructure ecosystem will help them understand their role in protecting devices.
Relevant cybersecurity compliance regulations
There are no cybersecurity regulations specifically for embedded systems; nevertheless, because the devices that contain embedded systems connect to the Internet, embedded systems can fall within existing cybersecurity compliance regulations. For example, an X-ray machine containing an embedded controller must comply with cybersecurity regulations for medical devices. Likewise, an IoT device with embedded technology (like a smart home appliance) should also meet similar requirements.
In the US, various laws cover IoT security, which, by extension, affects embedded systems, such as sector-specific healthcare and financial services regulations. Just last year, lawmakers added requirements for connected medical devices to the FDA Act, including the need to monitor devices while in the market, the necessity of issuing an SBOM and time windows for patching and remediation. The Payment Card Industry Data Security Standard (PCI-DSS) in financial services entails the embedded systems inside devices that handle payment card data. At a state level, California passed and put in force SB-327 in 2020, extending the existing privacy laws for IoT devices and the information they collect, store and transmit. For federal regulations, the IoT Cybersecurity Improvement Act of 2020 entails IoT devices used by federal agencies, indirectly affecting consumer products. Again, while these regulations do not specifically deal with embedded systems, IoT devices typically have embedded systems, making these laws relevant to manufacturers.
When manufacturing IoT devices with embedded systems, it’s helpful to consider broader IoT security standards, like EN 303 645 and IEC 62443-4-2, as well as the NIST Cybersecurity for IoT Program, NISTIR 8259A: Core Device Cybersecurity Capability Baseline. Additionally, for those products intended for European customers, manufacturers must show proof that their products meet the EU’s regulations, such as the General Data Protection Regulation (GDPR) and the EU Cybersecurity Act, in addition to Radio Equipment Directive (RED), regulations for medical devices (MDR), and in vitro diagnostic medical devices (IVDR) and NIS2 Directive, depending on the use case.
Tips for finding an ideal partner
The necessity of securing embedded systems throughout the entire lifecycle of a product cannot be understated. However, with threats constantly mutating like viruses, and cybersecurity regulations evolving to keep up, protecting a product from release to end-of-life can be incredibly challenging. And for businesses lacking the resources to support lifecycle management, finding a trusted partner with developer tools and services is highly beneficial. Of course, not all third-party partners are equal, so vet them accordingly, distinguishing between those with tools for rapid product design, embedded security and wireless integration, and those that do not possess such capabilities and proven expertise.
