How is embedded security unique?
Not a week goes by without news of breaches and exploits that expose corporate networks and regular end-users to risks to data, identity, and more broadly, well-being. With the increasing sophistication of both computer systems and of the cybercrimes that plague them, no system or device is safe. Systems at risk span from enterprise and cloud servers to desktop computers to embedded and mobile/wireless devices to increasingly ubiquitous IoT “things” – vehicles, medical instruments, industrial equipment, infrastructure systems and other intelligent devices.
But while humans imbue more devices and machines with intelligence, it is important to understand the distinctions among those systems – how they are built, maintained and targeted – to be better able to defend current and future designs from malware and bad actors.
The focus of this blog is to compare the cybersecurity risk profiles of three system classes – data center and cloud servers, desktop computers, and embedded/wireless/IoT devices – and to highlight how security counter measures for each require different types of investment.
| Data Center / Cloud | Desktop | Embedded/IoT |
Development | Native / Cloud / Container | Native | Cross |
System Access |
|
|
|
Network | Always | Usually | Increasingly |
Physical | No | Sometimes | Often |
OS | Linux, Windows, Cloud OSes | Windows, MacOS, Linux | Linux, Android, iOS, RTOS/kernel |
Operation |
|
|
|
Attended / Supervised | Yes (agents/SoC) | Yes (user) | No |
Shrink-wrapped apps | Yes | Yes | Sometimes |
Attack Surface | Internet-facing | Web and Email | Whole device |
Let’s examine key areas called out in the table above.
Development
Enterprise and desktop applications are most often developed “natively”, that is, on the actual types of systems later used in deployment, or equivalents of those systems on-premises or in the cloud. Development of applications and systems software occurs in very different settings: operating systems, drivers and system middleware are created and integrated by hardware vendors (HP, Dell, Apple et al.) and/or by OS vendors (OSVs Microsoft, Apple, Google, Red Hat and others). Applications are usually developed by third parties (ISVs) or by those same OSVs, or by enterprise developers, on top of systems and software already vetted for secure operations.
But embedded designs start with non-standard hardware platforms on top of which customized system software and applications are integrated. Low-end or highly-purposed devices may employ real-time operating systems (RTOSes) or embedded kernels that make no real distinction between system and application software. Moreover, instead of developing directly on deployment hardware, embedded development often proceeds on “cross platform” systems – workstations running Linux or Windows used to write code for different embedded software and hardware types, e.g., an RTOS running on an ARM-based MCU.
This radically different development paradigm introduces multiple security challenges:
- Vendors traditionally have relied on “security by obscurity” – counting on the unique nature of their products to stymy bad actors accustomed to exploiting Windows and other well-known environments.
- More deeply embedded systems on one hand are less stateful and have less storage, presenting less attractive targets with smaller attack surfaces. On the other hand, they still exhibit known vulnerabilities and multiple attack vectors, and suppliers and developers using them typically are not well versed in best security practices; counter-measures, if even present, are often not enabled or correctly configured.
- For intelligent devices build around desktop and enterprise-class OSes (especially Linux), existing security mechanisms usually need to be disabled or scaled back during development so as not to impede developer access. At deployment time, efforts to re-enable native security mechanisms to “lock down” those devices are often unsuccessful.
System Access
Originally, embedded systems of all kinds were dedicated mono-functional devices with minimal connectivity, most often site-local, usually accessed over serial lines or proprietary channels. Starting about two decades ago, two phenomena brought these systems “out of hiding”:
- Web-based user interfaces – headless designs, rather than investing expensive display and input hardware, began taking advantage of increasingly ubiquitous TCP/IP functionality and web-page design skills to offer users and administrators configuration and general UI capabilities.
- Mobile/wireless explosion – mobile phones, originally voice-centric devices, began benefitting from both increased bandwidth on 3G networks and more powerful application processors to vie with and even surpass the desktop as the center of users’ connected digital lives.
Making embedded system network-accessible, on a par with enterprise servers and desktop systems, helped to revolutionize computing at and beyond the edge. But making intelligent devices into network peers exposes them to the same threats that plague enterprise and desktop systems, and also to new threats:
Enterprise/Desktop Threats | Device-based Threats |
· Buffer overflow exploits · Data exfiltration · DDoS · Password-cracking · Ransomware · Social engineering · Viruses/worms/malware · Zero-day vulnerabilities | · Bot-net recruitment · Bricking / disabling devices · Device-specific spyware · Inflicting physical damage (especially in transportation, industrial control and medical systems) · State-sponsored espionage and counter-measures (e.g., Stuxnet) · Tracking user location and activities |
But embedded designs start with non-standard hardware platforms on top of which customized system software and applications are integrated. Low-end or highly-purposed devices may employ real-time operating systems (RTOSes) or embedded kernels that make no real distinction between system and application software. Moreover, instead of developing directly on deployment hardware, embedded development often proceeds on “cross platform” systems – workstations running Linux or Windows used to write code for different embedded software and hardware types, e.g., an RTOS running on an ARM-based MCU.
This radically different development paradigm introduces multiple security challenges:
- Vendors traditionally have relied on “security by obscurity” – counting on the unique nature of their products to stymy bad actors accustomed to exploiting Windows and other well-known environments.
- More deeply embedded systems on one hand are less stateful and have less storage, presenting less attractive targets with smaller attack surfaces. On the other hand, they still exhibit known vulnerabilities and multiple attack vectors, and suppliers and developers using them typically are not well versed in best security practices; counter-measures, if even present, are often not enabled or correctly configured.
- For intelligent devices build around desktop and enterprise-class OSes (especially Linux), existing security mechanisms usually need to be disabled or scaled back during development so as not to impede developer access. At deployment time, efforts to re-enable native security mechanisms to “lock down” those devices are often unsuccessful.
Physical Access
Enterprise and cloud servers enjoy a greater degree of protection from physical attack – they are usually locked up in server rooms and on isolated server farms, limiting attack vectors to network access.
Enterprise desktop systems enjoy some level of physical security – locked offices and password-protected screen locks; notebook computers are far more vulnerable as they can “walk off” in the hands of bad actors. If physically stolen, all types of PCs can be dismantled, opening physical data storage to attack (encryption not withstanding). Such systems are also vulnerable to malware contained on removable media – USB memory sticks, external drives, etc.
Embedded systems – IoT devices, control systems, mobile/wireless handset/tablets, vehicle head units and myriad other devices – are most subject to direct physical attack. They can be unplugged in place or smashed; they often deploy weaker, prior-generation wireless encryption; many have exposed factory reset buttons; and they can be carried off and exposed to further mischief on a workbench. A particularly infamous hack[1] was carried out against a Jeep vehicle, accomplished first through updates to the head unit and then via access to the vehicle CAN bus. The hackers also discovered an embedded wireless modem onboard and were subsequently able to gain control of similar vehicles (and of multiple other car models) actually driving in traffic.
Operation
Types of system access are related to modes of operation: attended vs. autonomous.
In the enterprise, both servers and desktops are subject to monitoring via software agents, authentication protocols, threat-hunting software and other means. If a system exhibits aberrant behavior or experiences attempts at unauthorized access, alarms trigger and alerts make their way to an SoC (Security Operations Center), where trained staff initiate appropriate security responses.
Autonomous and remote systems can benefit from the same sort of monitoring, but most often do not. Instead, they are deployed and forgotten. Often they don’t receive or cannot receive updates to software with patches to address vulnerabilities, and so with time become increasingly vulnerable to attack. And when those devices have missions in transportation, defense, healthcare and other critical applications, such attacks can constitute real threats to national security and public safety.
Attack Surface
The attack surface of enterprise servers is mostly limited to the software and services that interact with users over the internet – web servers and webapps, cloud storage and hosting, etc. Breaching those outward-facing services exposes the rest of the software stack to exploit (e.g., the ongoing vulnerability crisis around Log4j). Aside from actual vulnerabilities, enterprise servers suffer greatly from misconfiguration of existing security mechanisms and measures.
Desktop systems suffer from a multi-vector attack surface, where users are often the weakest link. The typical exploit narrative starts with users opening an email attachment or visiting a malware host site, opening an innocuous-looking file and in doing so, installing malware. An entire industry exists today around “endpoint security”, but despite the efforts of over 70 vendors and IT security organization, the desktop onslaught continues.
Intelligent devices share some security attributes of both servers and desktops: the greatest threats typically come through their network connections, but overall embedded systems fall into the category of network endpoints, with the added bonus to bad actors of variously unfettered physical access. Adding further insecurity to this unfortunate combination is the lack of attention by embedded developers to designing with security in mind. Legacy RTOS and embedded kernels, designed for size, efficiency and responsiveness, seldom even begin to address security. And while embedded Linux in theory can leverage enterprise capabilities, it is often misconfigured and/or not kept up to date. Worse yet, application-centric systems, especially Android, are vulnerable to poorly coded and malicious downloaded apps.
Best Practices for Device Manufacturers
The attack surface of enterprise servers is mostly limited to the software and services that interact with users over the internet – web servers and webapps, cloud storage and hosting, etc. Breaching those outward-facing services exposes the rest of the software stack to exploit (e.g., the ongoing vulnerability crisis around Log4j). Aside from actual vulnerabilities, enterprise servers suffer greatly from misconfiguration of existing security mechanisms and measures.
Desktop systems suffer from a multi-vector attack surface, where users are often the weakest link. The typical exploit narrative starts with users opening an email attachment or visiting a malware host site, opening an innocuous-looking file and in doing so, installing malware. An entire industry exists today around “endpoint security”, but despite the efforts of over 70 vendors and IT security organization, the desktop onslaught continues.
Intelligent devices share some security attributes of both servers and desktops: the greatest threats typically come through their network connections, but overall embedded systems fall into the category of network endpoints, with the added bonus to bad actors of variously unfettered physical access. Adding further insecurity to this unfortunate combination is the lack of attention by embedded developers to designing with security in mind. Legacy RTOS and embedded kernels, designed for size, efficiency and responsiveness, seldom even begin to address security. And while embedded Linux in theory can leverage enterprise capabilities, it is often misconfigured and/or not kept up to date. Worse yet, application-centric systems, especially Android, are vulnerable to poorly coded and malicious downloaded apps.