What Is Embedded Security?
Definition of Embedded Systems Security
Embedded systems security focuses on preventing malicious access to and use of embedded systems.
Here are general cybersecurity terms that are helpful to know as you learn about embedded system security:
- An attack vector is a path an attacker or malicious process could take to compromise a system. Flash drives, the Internet, network protocols and disks are embedded systems attack vectors.
- An attack surface is a target point of exposure, or the end goal of the attack vector. For example, a network driver, a user application and a file system are attack surfaces.
- A threat actor is a source (software or a person) with malicious intent.
- An attacker is an individual performing a malicious act in real time.
- A vulnerability is a weakness that can be exploited by a threat actor to perform unauthorized actions within an embedded system or computer.
Software security vs. physical security for embedded systems
Two types of security apply to embedded systems: physical security and software security.
- Physical security, such as locked doors and surveillance cameras, keeps an unauthorized person present on location from accessing an embedded system, physically damaging it or stealing it. Physical security limits access to sensitive areas and equipment. Physical security may also include attributes of a device itself, including immutable memory technology, such as eFuses to store secure bootloader keys, tamper-resistant memory, protected key stores and security enclaves to protect sensitive code and data.
- Software security manages and responds to malicious behavior happening in the system, both during the initialization process and during run time. Software security features include authentication of a device to a network, firewalling network traffic and stringent hardening of system software to name a few.
Qualities of embedded systems that affect security
The monetary value of data, the ability to cause serious harm, and the interoperability and connectivity of modern embedded systems, including mission-critical systems, make embedded systems popular targets. Cyberattacks on embedded systems range from disabling vehicle anti-theft devices and degrading the performance of control systems to directing printers to send copies of documents to the hacker and accessing a smartphone’s data. Cyberattacks on embedded systems create an urgent need for everyone from developers to end users to help prevent, manage and patch vulnerabilities.
All elements of the hardware and software architecture need to be secure. Each of the components of embedded system architecture creates an attack surface, from the firmware and embedded operating system (OS) to middleware and user applications. The embedded OS, a foundational piece of embedded systems security, plays the leading role as the backbone of security for an embedded system.
Cyberattacks on embedded systems create an urgent need for everyone from developers to end users to help prevent, manage and patch vulnerabilities.
Some embedded systems are in the field for decades, others for just a few years. Many mission-critical systems, such as cars, defense systems and power plants, have a long service life — 20 years or more. Older embedded systems often don’t get updated because the hardware is obsolete and doesn’t support the new software. Designing a system to be secure can greatly increase the viability of keeping systems safely in service and at reduced risk of attack.
Developers need to consider hardware and software obsolescence when designing embedded systems to increase system longevity and security. Computing, networking, cyberattacks and embedded systems security will evolve over the lifespan of an embedded system in ways that cannot be foreseen by system developers. As vulnerabilities are identified, they will need to be mitigated with patches, which require software updates. Including security in the design phase helps ensure that an embedded system has a way to get updates and is capable of running new software.
Difficult to update
Some embedded systems are easier to update than others. A smart TV or smartphone can be updated regularly with minimal impact to the end user. In comparison, insecure software in a modern vehicle can put lives at risk, so software updates to vehicles are carefully orchestrated (and costly).
The type of embedded OS also affects the update process and frequency. Applying an update to an embedded system running a monolithic OS, such as Linux®, is difficult. When the OS and all OS services run in kernel space, applying an OS service patch requires a full OS install, OS refresh, and a full system reboot—all of which increase the scope of testing and the time to deploy.
In comparison, the architecture of a microkernel OS, such as the QNX® Neutrino® Real-Time Operating System (RTOS), makes embedded software updates much easier. OS services in a microkernel run outside of kernel space, which allows for the rebooting of a single service, without a kernel reboot, resulting in very minimal impact on kernel behavior. In addition, the footprint of a microkernel OS service update is generally small—it doesn’t necessarily require the kernel to be updated at the same time—reducing the time and cost of testing a patch.
Security vulnerabilities and exploits
Anatomy of an embedded system exploit
How does a threat actor exploit an embedded system? In general, most cyberattacks follow these five steps:
- Get network (or physical) access
- Understand the underlying processes, hardware and embedded operating system (reconnaissance)
- Find a vulnerability in the host-based protection, such as within a programmable logic controller (PLC), embedded OS or middleware
- Manipulate the controller
- Exploit the vulnerability to attack the system or others
Embedded system attack vectors
A threat actor gains control of an embedded system through one of these four paths:
- The larger system (the host) that includes the embedded system
- The Internet or a communications network that connects the embedded system with other devices
- A physical device, such as a USB drive or disk with malicious code on it
- Vulnerabilities present in the embedded software from the beginning
Embedded software vulnerabilities
Like computers, many embedded systems have security vulnerabilities that can provide a way for a threat actor to gain access to the system. Typically, there is a time lag between the discovery of a specific vulnerability—such as a CVE, misconfiguration, or weak or missing encryption—and the availability and application of a patch or other remediation. Meanwhile, vulnerable systems are at risk. System hardening and the use of additional layers of security—such as a managed security service, firewall or intrusion detection and prevention system (IDPS)—reduce the risk that a threat actor will successfully exploit the vulnerability.
The five most common types of software vulnerabilities in embedded systems are as follows:
Improper input validation
Improper restriction of operations within the bounds of a memory buffer
As many as 20 percent of industrial control systems have critical security issues.
Best practices for embedded security
Security advantages of microkernel OS
A microkernel OS is structured with a tiny kernel space with services like file systems provided in user space, drivers or network stacks. Less code running in kernel space reduces the attack surface and increases security. The microkernel works with a team of optional cooperating processes that run outside kernel space (in the user space) and provide higher-level OS functionality. Only the core OS kernel is granted access to the entire system, and component isolation prevents an error in one component from affecting other parts of the system. A determined hacker, as long as they don’t have root access, can only crash one component at a time when the system runs a microkernel OS or a secure embedded hypervisor.
The microkernel design and modular architecture of the QNX Neutrino real-time operating system enables BlackBerry QNX customers to create compelling, safe, and secure devices built on a highly reliable OS, a software foundation that helps guard against system malfunctions, malware and security breaches.
Embedded security is a hardware-software partnership
Hardware technologies provide a root of trust and encryption and decryption services.
Root of trust
A hardware security module (HSM) or hardware root of trust manages keys, performs encryption and decryption functions, and embeds keys for OS and application use. Often these system-on-a-chip (SoC) components provide CPU offload for bulk encryption and decryption, and they may also be used to offload network cryptographic functions.
Hardware roots of trust are increasingly available as part of the SoC but can also be integrated using discreet electronics, such as an authentication IC or a TPM. During manufacturing, a private key can be generated on a chip or injected into each chip to serve as a root of trust. When the private key is certified by a public key infrastructure (PKI), the secure device identifier can become a foundational component of trusted device connectivity. For example, a secure device identifier can help a developer or designer establish trusted communications with peer devices and cloud-based services.
Trusted execution environment
Trusted platform module
Essential defense mechanisms of a secure OS
Executable space protection
Address space layout randomization
Although 70 percent of the most popular embedded OS lack at least one of these defense mechanisms, QNX Neutrino RTOS provides all three.
A secure OS can help solve common embedded security challenges
|Data Confidentiality at Rest||Prevent a threat actor from seeing, modifying, or exfiltrating sensitive data on the system||File-based encryption|
|Data Integrity||Package system assets in an integrity-protected container that can be mounted at any time on the system for access||
Mark all executables as non-writable
Use an integrity-protected disk solution
|Unrestricted Access to System Resource Managers||Prevent unauthorized system components from accessing system resource manager channels or restrict the operations they can request after they connect||
POSIX permissions and access control lists (ACLs)
|Filesystem Object Access Control||Restrict access to filesystem objects by various processes||POSIX permissions and access control lists (ACLs)|
|Untrusted Code Execution||Prevent a threat actor from running or loading an untrusted binary from a filesystem||Use a utility to mark files and filesystems as trusted|
|Redirect Control Flow||Prevent a threat actor from modifying executable control flow||Use a compiler to mark the relocation sections of an executable as read-only|
|Repeatability of Attacks||Make it harder for an attacker to guess where code is loaded in memory||Address space layout randomization (ASLR)|
|Buffer Overflows||Instrument code to mitigate potential buffer overflow attacks||Use a compiler with fortified function support to detect out-of-bounds memory accesses|
|Stack Overflows||Instrument code to mitigate stack overflow attacks||Compile code with stack canaries|
|Revealing Sensitive System Information||Prevent a threat actor from being able to inspect the private information of other processes on the system||
Secure the /proc filesystem
|Process Execution with Least Privileges||Configure the system to restrict privileges on processes to make sure that they execute with the least privileges necessary for their tasks||
Use a granular system of policies to govern which operations a particular process is permitted to do
POSIX permissions and access control lists (ACLs)
|Device Hardware Access to Kernel Memory||Prevent a threat actor from using a device (such as a GPU or network card) to directly memory access (DMA) addresses to which the device has not been explicitly granted access||Use a system memory management unit manager that uses DMA containment|
|Denial of Service||Prevent a threat actor from interfering with critical systems by exhausting system resources||Set resource limits, such as setrlimit() system calls in C|
Cybersecurity standards for embedded systems
In addition to using a secure software foundation, security standards provide best practice processes to help developers build secure embedded systems and conform to cybersecurity regulations. While functional safety standards for embedded systems are mature, standards for embedded systems cybersecurity are not. Currently, the automotive industry is leading the way with two publications, SAE J3061 and ISO/SAE 21434, and the WP.29 regulation that goes into effect in January 2021. The following resources provide embedded developers with expert guidance:
- UNECE WP.29 Regulation on Cybersecurity and Software Update Processes: This international regulation establishes performance and audit requirements for new passenger vehicles in many countries with a goal of paving the way for connected and autonomous vehicles.
- SAE J3061, “Cybersecurity Guidebook for Cyber-Physical Vehicle Systems:” The publication provides a cybersecurity process framework and guidance to help organizations identify and assess cybersecurity threats and design cybersecurity into cyber-physical vehicle systems throughout the entire development life cycle process.
- ISO/SAE 21434, “Road Vehicles – Cybersecurity Engineering:” A work-in-progress, ISO/SAE Draft International Standard (DIS) 21434 will likely be published in 2020 or 2021. The standard will be help manufacturers demonstrate compliance with WP.29 regulation and is likely to be adapted for use in other industries.
Embedded systems developers can also find security guidance in these two cybersecurity frameworks:
- ISO/IEC 27001:2013, “Information technology — Security techniques — Information security management systems — Requirements” can help any organization establish, implement, maintain and continually improve an information security management system. ISO 27001 also includes requirements for the assessment and treatment of information security risks.
- U.S. National Institute for Standards and Technology (NIST) “Cybersecurity Framework”: First published in 2014 as the “Framework for Improving Critical Infrastructure Cybersecurity", the CSF is widely considered the first line of cybersecurity defense across all industry sectors.
Risk assessments lead to security requirements
The secure SDLC can help every developer build more secure embedded systems.
The first step in the SSDLC is a thorough risk assessment, which will inform the security requirements. A risk assessment identifies threats, the likelihood of those threats and the damage they can cause.
In addition to the risk assessment, threat models provide a structured approach to identifying and characterize threats to enable a more secure system design. Two popular threat models are STRIDE and DREAD.
Supply chain security
A common security requirement is the systematic verification of the security of software and hardware components in the internal and external supply chain. A trusted components program includes requirements such as:
- A trusted system components supplier program should identify suppliers with mature secure development life cycle processes, such as a security-aware manufacturing process to mitigate the risk of malware entering the supply chain.
- A system-on-a-chip (SoC) should support device provenance and integrity (e.g., secure boot and OS loading) through the use of immutable trust anchors, which authenticate access to internal debug interfaces to ensure on-chip security functionality cannot be bypassed. SoCs should support hardware root of trust capabilities, such as system integrity validation, secure key storage, and operations such as encryption, decryption and digital signatures. If a trusted execution environment (TEE) hardware root of trust is not available, the design should, at minimum, provide a device with a unique encryption key that cannot be easily extracted or revealed.
- Device software should be of known and trusted provenance, from integrity-protected and verifiable archives. Many off-the-shelf components are considered software of unknown provenance, or SOUP.
- Sensitive keys and device identifiers should not be exposed in any part of the manufacturing process, and there should be a clear audit trail of any provisioning process
- Records of device manufacturing should include traceability to both hardware and software bill of materials, so that potential component defects can be identified when the system is deployed.
- Device identifiers should be cryptographically secured with a system that can detect counterfeit, grey-market and remanufactured components on the original production line and during system repair.
Embedded security encryption
How TLS works
- After a connection is made between a client and server, the client requests a secure connection and tells the server what types of cryptographic security the client supports.
- The server chooses the most secure option supported by both the server and client, and then sends a security certificate signed with the server’s public key.
- The client authenticates the server’s certificate, generates a secret key encrypted with the server’s public key and sends the encrypted key back to the server.
- The client and server use the secret key to generate a pair of symmetric keys (or two pairs of public-private keys) and communication commences securely.
All communications between modules and between the embedded system and the outside world should be authenticated, trusted and encrypted. Each connected device should have its own unique private key and certified device identifier. This device certificate allows each device to authenticate to a cloud directly or via a separate security gateway to enforce security policies.
Additionally, all network traffic should be authenticated and encrypted with rolling keys. Device certificates can be used to support client authentication. This is an increasingly common way to prevent the impersonation of IoT devices and support secure peer-to-peer connectivity.
Protecting encrypted data
Code review and testing
SAST vs. DAST vs. penetration testing
Static application security testing (SAST), dynamic application security testing (DAST) and penetration testing are three types of software testing that identify vulnerabilities. These types of security testing can also find unnecessary services (FTP, SSH) and open ports that expose attack surfaces.
SAST tools look inside the code to identify common security flaws, such as buffer overflows and cross-site scripting vulnerabilities, without running the code.
DAST tools, such as vulnerability scanners, run on operating code to find vulnerabilities such as code injection and authentication errors.
In penetration testing, an ethical hacker (also called a white hat) attempts to break in to ascertain if a determined attacker could gain access or disrupt the embedded system. Penetration testing is also called pen testing or pentesting.
Binary code analysis
Threat defense and in-field tests
Once the device is in the field, intrusion detection and intrusion protection systems (IDPS) intercept communications defensively to identify or block attacks and the exfiltration of data. Some embedded systems security services, such as BlackBerry® Cylance®, take a proactive approach through threat hunting and security monitoring of embedded systems and IoT devices.
In addition, self-tests assess the security posture of an embedded system in the field. Software for self-testing analytics and diagnostics monitors events, logs crashes and anomalies, and sends this information to the cloud. A cloud-based system can then analyze the information and act to mitigate safety and security risks.
Secure OTA updates over the lifetime of a system
Maintenance is the final phase in a secure SDLC. What do you do when you find a vulnerability in software after the product ships? Updating embedded systems once they are out in the world is much more difficult than updating software on personal devices, such as laptop computers. Just identifying the physical location of embedded systems and their status (e.g., software version, in service) can be difficult. So, updating software for safety- or mission-critical systems—where downtime or restarts can have a catastrophic impact—must be performed with the utmost care and only after extensive testing of the impact on the whole system.
Until recently most embedded software updates were performed in person, which is incredibly costly and resource intensive. In recent years, a number of over-the-air (OTA) update solutions have emerged for embedded systems. But because embedded system infrastructure components (e.g., authentication mechanisms, end-point management systems, cloud, software repository, communication protocols) don’t often interoperate, out-of-the-box solutions rarely work.
BlackBerry QNX has created a flexible OTA solution that can be customized to seamlessly combine existing technology and manage even the most complex update scenarios.
How BlackBerry QNX can help you
Secure software foundation
BlackBerry QNX’s reputation as a security vendor is backed by 40 years of experience delivering secure and reliable software for embedded systems. BlackBerry QNX offers trusted mobile security, and the QNX Neutrino RTOS and the QNX® Hypervisor are the gold standard in embedded software operating systems and hypervisors. BlackBerry QNX has the expertise needed to help customers build more secure products.
BlackBerry QNX provides businesses in the most demanding industries with the building blocks for secure embedded systems; these include:
- A secure embedded OS with a microkernel architecture and adaptive partitioning
- A layered approach to security through mechanisms such as secure boot, integrity measurement, sandboxing, access controls and rootless execution
- A comprehensive security policy that enables system architects and integrators to control access to specific system resources and determine the type of access permitted (e.g., no root access)
- Secure over-the-air (OTA) updates for software maintenance over the lifetime of an embedded system
The QNX Neutrino RTOS and the QNX Hypervisor are the gold standard operating systems for secure embedded software.
BlackBerry Security Services
Leveraging BlackBerry's industry-leading cybersecurity expertise, we can evaluate your software assets to identify vulnerabilities and recommend specific remediation actions. From penetration testing to a holistic appraisal of your company’s security posture, our security and embedded system experts can assess and address security issues with your processes or products at every stage of your software development life cycle (SDLC). We can help you:
- Assess your current software security posture and goals
- Plan and implement a quantifiable security strategy
- Improve your level of software security assurance
- Choose the best security solutions and services vendors
Our security services include:
- Cybersecurity and regulation readiness
- Open source software (OSS) assessment
- BlackBerry Jarvis software security services
- Software security audit (also called vulnerability assessment)
- Penetration testing
- Security training and workshops
- Custom engagements ranging from complex multi-system integration projects to ongoing staff augmentation support
Learn more about our security services.
BlackBerry Advanced Technology Development Labs (BlackBerry Labs) works at the forefront of research and development in the cybersecurity space. With a strong focus on data science and machine learning, BlackBerry Labs’ innovation funnel investigates, incubates and facilitates technologies specifically designed to further our commitment to safety, security and data privacy for BlackBerry customers.
BlackBerry® Certicom® provides device security, anti-counterfeiting and product authentication to deliver end-to-end security with managed public key infrastructure, code signing and other applied cryptography and key management solutions.
BlackBerry® Cybersecurity offers AI-based endpoint security solutions that prevents breaches and provides added controls for safeguarding against sophisticated threats. Focusing on a stronger prevention-based approach versus signature-based prevention tools, BlackBerry has redefined what an endpoint protection solution can and should do.
BlackBerry® QNX® offers the most advanced and secure embedded operating system (OS) and embedded hypervisor for mission-critical and safety-critical embedded systems.
Check Out Our Other Ultimate Guides
Real-time Operating Systems
WP.29 Cybersecurity Vehicle Regulation Compliance