Two-thirds of the global edge footprint is composed of billions of embedded devices, ranging from discrete sensors, cameras, and industrial automation controllers to larger systems-of-systems such as appliances, robots, drones and cars. These devices are typically powered by one or more microcontrollers (MCUs) or lightweight CPUs, running monolithic firmware or embedded
Linux that has historically been time-consuming to develop and rigid to innovation.
In this blog, I outline the key cybersecurity considerations for embedded development, macro trends that are necessitating change in how we approach device security, and how Atym helps organizations enhance the cybersecurity posture of their connected products.
Core Embedded Security Challenges
Security is a cost center, and organizations are faced with “right sizing” investments to ensure proper protections while maximizing profit and customer satisfaction, and complying with regulations. Cybersecurity is especially challenging for embedded devices because they often don’t have sufficient hardware resources to protect themselves, lack robust authentication mechanisms, are physically accessible, run on untrusted networks, and are often inadequately tested due to resource limitations. Compounding these challenges is that they are typically deployed across geographically diverse areas which greatly increases the attack surface.
Today, 99% of MCU-based devices are powered by firmware written in C/C++. These programming skills can be hard to come by and development cycles are complex and long. The required investment has resulted in widespread legacy codebases that are especially vulnerable to exploits. Further complicating security (and performance) is that MCUs don’t have Memory Management Units (MMUs), meaning a single compromise in firmware provides attackers with access to the entire memory footprint. MPUs help but are limited to what they can do and are complicated to develop for.
Complexity is also driven by the heterogeneity of embedded devices compared to server, PC and mobile hardware running Windows, Android, iOS and commercially supported Linux. MCU-based devices have wildly different silicon architectures with different tool sets, require Real Time Operating Systems (RTOS), have specialized I/O (e.g. serial, I2C) and related drivers, and may or may not have a silicon-based secure element like TPM to tap into for root of trust. On top of this, developers are working with kilobytes to megabytes of available memory – compared to the luxury of gigabytes available on hardware further upstream in the edge continuum.
Additionally, any single code change requires an entire firmware image to be recompiled. In the field, this introduces risk in terms of downtime and the potential to “brick” the device with a failed update – potentially triggering an expensive truck roll to remediate. For this reason, Industrial and Enterprise operators often choose to not update embedded devices unless absolutely necessary. In the case of smart homes, consumers may prioritize convenience or practice “ignorance is bliss” instead of keeping up with security updates for their connected devices. That said, I do believe attention will increase over time with growing breaches of personal information.
Devices running embedded Linux have similar security challenges, but Linux skills are easier to come by and the target hardware typically has more resources to support security elements. As such, the focus of this blog is primarily on MCU-based devices.
Zero Trust is Key
Embedded edge devices are deployed in the physical world - spanning locations such as the factory floor, retail stores, energy infrastructure, and homes. These locations often lack a well-defined security perimeter, enabling attackers to physically tamper with devices. The devices may also be deployed on networks that are untrusted and not owned by the manufacturer. For all these reasons, a robust zero trust security policy is a necessity for embedded edge devices. A “zero trust” approach means that all users, devices, and networks are inherently untrusted, and that access is explicitly granted based on policy. This requires design considerations for both devices and supporting management tools.
Macro Trends Necessitating Change in the Embedded Space
We joke at Atym that “the 90’s called and want their embedded approach back” because firmware development has remained largely the same for many years. Meanwhile, server software has evolved from similar monolithic software images that are tightly-coupled to hardware to being abstracted and modularized. This started with VMware’s introduction of the virtual machine in 1998, followed by technologies like Docker and Kubernetes. Most recently, WebAssembly is driving additional architectural evolution (more on that shortly).
Despite being resource-constrained in comparison to hardware further up the computing paradigm, MCU-based edge devices continue to get more capable. This enables new innovations but also presents new challenges. There are several key macro trends that are driving a need to change how we approach embedded development to maintain an appropriate balance between a robust cybersecurity posture and both the developer and user experience. “Security usability” is critical to make this happen.
Software-defined Everything
Key to today’s digital innovation is that the total value of a product or solution is delivered over its entire lifecycle, versus the day it is first commissioned. Historically, embedded devices and systems have typically been designed to serve one purpose their entire life, but they’re increasingly becoming software-defined to be able to evolve in functionality over time. This necessitates a mirror of the continuous software delivery (e.g. CI/CD) that we’ve been doing in the cloud for years, but on an exponentially larger distributed scale... and attack surface.
Edge AI
The rise of on-device AI for real-time analytics and preserving privacy is especially driving the need for secure and reliable device updates. As AI models mature they need to be updated on devices much more frequently than critical security patches have been performed in the past.
Adding intelligence to devices also increases their risk profile. A “dumb” IoT device such as a basic sensor can already serve as a conduit into broader networks and data systems or be spoofed by a hacker to pass fake data upstream and adversely affect decisions and operations. As edge devices become more intelligent, they increasingly host sensitive IP and personally identifiable information (PII), making them even greater targets for attackers because they can inflict harm on an even larger scale.
Era of the Ecosystem
These days, solutions are rarely developed entirely in-house. Rather, they are built from a combination of best-in-class internal, open source and partner technology. The “source code soup” of hard-coded firmware makes ecosystem collaboration especially difficult. A developer that’s an expert in AI is typically not skilled in developing lower-level security functionality and device drivers. Developers need simple tools to be able to develop embedded applications in collaboration with an ecosystem.
Growing Cybersecurity Regulations
Further complicating things is increasing cybersecurity regulation. You would think that the potential cost of remediating a large-scale breach, and the associated brand damage, would be enough for all organizations and users to appropriately invest in security. If that’s not enough, the threat of incurring fines or being all over the news for failing to comply with regulations is certainly an effective influence on behavior. As I like to say – “people love to save money but hate to get fined”.
A few examples of emerging cybersecurity regulations affecting the embedded space include:
Software Bill of Materials (SBOM) - Increasingly required of manufacturers, an SBOM is a list of code that provides a complete view of software provenance. Achieving SBOM compliance is especially difficult with traditional embedded firmware due to the “source code soup” of monolithic compiled code with hard-linked libraries.
Cyber Resiliency Act (CRA) – Developed by the EU, the CRA establishes broad-reaching requirements for connected devices that applies to both hardware and software/firmware. It’s fully applicable on December 11, 2027 and it’s reasonable to expect that similar regulations are enforced in other regions over time.
Memory Safe Code – Security regulators are increasingly urging developers to program in memory safe programming languages such as RUST and GoLang. Today, C/C++ represents the majority of code powering embedded devices, but they are not memory safe languages. It’s simply not feasible to rewrite all legacy C/C++ code in the near term, so we need methods to protect existing device code while programming new applications in memory safe languages.
Leveraging WebAssembly to Improve Embedded Security
So, how do we address embedded security needs while keeping up with the pace of innovation with available resources? Applying cloud methodologies using WebAssembly is emerging as a potential answer.
Initially designed as an augmentation for JavaScript in web browsers, WebAssembly (Wasm) is increasingly being leveraged for cloud architectures and edge use cases. Wasm was designed with security as a top concern, and its light footprint makes it especially suitable for resource-constrained devices, including ones powered by MCUs.
Some of the key elements of the Wasm security model include:
Wasm modules are designed to execute within a sandboxed environment, meaning they are isolated from both the host hardware and other software modules. Since each module is a virtual machine instance, it provides an increased level of isolation over even Linux-based containers such as Docker.
By default, access outside of the Wasm virtual machine is not possible. Only explicitly injected interfaces can be called from within the VM, supporting a zero trust security posture.
Wasm modules have restricted memory access, only being able to access their own allocated memory. This effectively creates a “soft MMU” for MCU-based devices. Further, Wasm code can’t jump to arbitrary addresses or execute data in non-code locations (e.g. data memory). This prevents a large variety of potential code vulnerabilities.
Wasm provides a protected call stack to prevent vulnerabilities due to buffer overruns. Traps provide a way to immediately terminate execution in the case of abnormal behavior. If termination occurs, only that specific container/VM is affected, and control is returned to the underlying runtime for handling.
For a deeper dive on the fundamentals of WebAssembly, check out our CTO Stephen Berard’s two-part blog.
The Atym Solution and Security Enhancements
Atym is revolutionizing the embedded space by bringing cloud development principles and containerization to resource-constrained edge devices. Using our central orchestration Hub, developers can containerize applications written in their preferred programming language and deploy them to fleets of devices at scale. The Atym Hub is offered in both SaaS and on-prem options and enables policy-based management of connected devices and applications throughout their entire lifecycle. Our Hub works in concert with the on-device Atym runtime.
The Atym device runtime abstracts hardware complexities to provide a consistent deployment environment for developers to build applications without requiring specific embedded expertise. It’s effectively now the firmware below one or more software-defined application containers. The runtime is powered by WebAssembly and is developed as part of the open source Ocre project in the Linux Foundation. Atym seeded the Ocre project with code in August of 2024 to afford vendor-neutral governance for both the architecture and code evolution.
We’re also co-chairing an Embedded/Industrial Special Interest Group (eSIG) in the ByteCode Alliance alongside colleagues from the likes of Bosch, Emerson, Siemens and Sony Midouka. In turn, a key goal of the Ocre project is to codify the standards of the eSIG. At Atym, we’re firm believers in integration vs. reinvention, but will get ahead of available standards as necessary, serving to buffer end users from any associated churn.
With a footprint of just 256KB of memory, the Ocre runtime is suitable for supporting applications on MCUs that have as little as 1MB of available memory. It’s currently based on the Zephyr RTOS but is generally RTOS-agnostic and we anticipate other variants (e.g. FreeRTOS, VXWorks) to be available over time. We also expect the footprint to shrink with additional optimizations, and we’re planning a Linux-based runtime to serve as an alternative to Docker for more capable devices.
Our device edge orchestration solution accelerates time to market, opens opportunities for different developer skill sets, simplifies ecosystem collaboration, streamlines and hardens field updates, and provides additional layers of security on top of what’s enabled by Wasm and Ocre. Some examples of how our commercial offer further enhances security include:
Container Orchestration – The central Atym Hub orchestrates and manages application containers deployed on the Atym Runtime and has full control over when and how container modules execute. Policy can be enforced for fault handling should a container start exhibiting security vulnerabilities or terminate unexpectedly. A specific compromised container can also be quarantined so the remaining containers can continue to operate on a device. Container updates are fractional, meaning only necessary code needs to be replaced.
Marshalled Execution – Access to any device resource can only happen through the Atym Runtime. Direct access to any hardware resource is never granted directly to Wasm code. For example, if a socket is opened from code within a container, all access to that socket is brokered by the Atym Runtime based on policy established through the Hub.
Granular Permissions - Each container needs to have permissions to call specific sets of APIs. For example, a container would need the “network” permission to call methods for making network connections. Without this permission, the Atym Runtime will not allow the call to execute, and the container can automatically shut down if configured to do so per security policy.
Container Signatures – Devices can be configured to execute only code that has been signed. This integrity check ensures that 1) only code from trusted sources is allowed to run, and 2) container code has not been modified. Like container permissions, this provides an additional layer of defense in depth. The overall process of signing certificates can be fully controlled by the end user so Atym does not have access to the signing secrets.
Bookended AOT Compilation Process – Atym employs Ahead-of-Time (AOT) compilation of Wasm modules to optimize each instance for the specific architecture of the target hardware to yield near-native performance. This AOT compilation process is fully managed in the Atym Hub and is performed seamlessly when application containers are deployed to the Atym Runtime on edge devices. This “bookending” eliminates the potential for an attacker to hijack the compilation/optimization process to inject or run infected code on deployed devices.
Simplified Regulatory Compliance – The Atym solution helps developers programmatically address regulatory requirements like the Cyber Resiliency Act while requiring less specialized developer skills than traditional embedded firmware and software. Separation of code provenance helps with SBOM compliance, and developers can “lift and shift” existing C/C++ code into protected containers while developing new applications in memory safe programming languages.
Summary
Implementing appropriate cybersecurity measures has historically been especially difficult in the embedded space due to the skills required, tight code coupling to resource-constrained and heterogenous hardware, and broad geographical distribution. Developers are faced with “right sizing” security measures for their products while providing an excellent user experience, maximizing profit, and complying with regulatory requirements.
A good starting point to striking a balance between these needs is borrowing from cloud practices in terms of zero trust security, modularized software, hardware abstraction and continuous integration and delivery (CI/CD). In recent years, Docker and Kubernetes have made their way to more capable edge hardware but there has been a gap for resource-constrained hardware. The adoption of WebAssembly is changing this – enabling developers to build secure embedded edge solutions similarly as they would in the cloud.
Atym takes this a step further by integrating WebAssembly into our full device edge orchestration platform. Enabled by the open source Ocre device runtime, our solution greatly simplifies developers’ ability to tap into silicon-based root of trust, issue and manage certificates, establish fine-grained zero-trust policies and more. They can do so while reusing legacy code investments alongside new applications written in choice of programming language.
With Atym, field updates are fractional and fail-safe without requiring a reboot. Any compromised code can be quarantined in its own container until it can be updated. Further, remotely debugging a faulty or compromised code in a container is simplified because the overall device can still be running.
We're committed to helping customers address growing cybersecurity regulations. Our solution makes it easier to track SBOMs for embedded software built from a mix of internal and third-party code written in different programming languages.
Customers can more effectively comply with the Cyber Resiliency Act with built-in root of trust, IAM and certificates, policy-based control of inter-app and -device communication, granular visibility of code provenance and revisions, separation of ecosystem roles and responsibilities, and ability to quarantine specific compromised code without shutting down the entire device.
Our platform can also help developers immediately “lift and shift” legacy C-based firmware into isolated containers for a layer of protection while new apps are written in memory-safe programming languages like Rust or Go.
To learn more about how we can help you strike a balance between embedded cybersecurity, accelerating innovation, meeting budget and schedule, complying with regulations, and scaling field deployments, check out the Atym blog page, follow us on LinkedIn, dive into the Ocre community, or contact us!
Comentários