Embedded Security Risks and Best Practices for IoT and Critical Devices

Arm has announced that it has successfully certified their Cortex-M33 and Cortex-M35P soft processor IPs and their security features to EAL6+ for the Common Criteria standard. This certification of Cortex-M soft processor IPs is an important step towards enabling the industry to develop cost-effective security solutions that can be trusted. Semiconductor companies now have a clear path towards achieving high-assurance certification of their SoC design.

ProvenRun brings another building block of the complete solution: ProvenCore, its secure operating system that has already received a Common Criteria EAL7 certification for devices based on Cortex-A processors and is also available for Cortex-M processors. 

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:

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.