Ultimate Guide to Embedded Systems Security
What is embedded systems security
Embedded systems security provides mechanisms to protect an embedded system from all types of malicious behavior, including internal and external threats. In this section, you’ll learn about embedded systems security, related security terms, software and physical security, and four qualities of embedded systems that affect security.GET THIS GUIDE AS A PDFContact Us
Definition of embedded systems security
Embedded systems security is a cybersecurity field focused on preventing malicious access and use of embedded systems. Embedded systems security provides mechanisms to protect a system from all types of malicious behavior, including threats that originate internally (such as buffer overflow) and externally (such as viruses and remote access). Cyber security specialists work with embedded systems design teams to ensure the embedded systems has the necessary security mechanisms in place.
Embedded systems security focuses on preventing malicious access and use of embedded systems.
Let’s look at some 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 system attack vectors.
- The attack surface is a target point of exposure – essentially, the end goal of the attack vector. For example, the network driver, user application and 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. For example, in the defense industry, physical security limits access to sensitive areas and equipment. Physical security may also include attributes of a device itself, including immutable memory such as e-fuses for secure boot keys, tamper resistant memory, or specialized chip architectures including protected key stores and security enclaves which protect sensitive code and data.
- Software security manages and responds to malicious behavior happening in the system, both during the initialization process and in real time. Software security features are far ranging, from authenticating a device to a network and firewalling network traffic to stringent hardening of system software.
Qualities of embedded systems that affect security
Many embedded systems perform mission-critical or safety-critical functions vital to a system’s intended function and surrounding environment. Embedded systems security is relevant to all industries, from aerospace and defense to household appliances, with one of the most notorious denial of service attacks led by an army of programmable thermostats. Modern embedded systems are starting to become interconnected by the Internet of Things (IoT), which creates another attack vector.
The most secure embedded system is one that is turned off, and the next most secure system is completely isolated. When embedded systems were islands of technology that contained minimal information, embedded software security was less important. Embedded systems are now often connected to a communications network that exposes the system to more threat actors.
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, or to 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 – from underlying firmware boot loader and OS to memory – need to be secure. Each of the components of embedded system architecture – from the user applications and middleware to embedded operating system (OS) and firmware– creates an attack surface. The embedded OS is a foundational piece of embedded systems security and plays the leading role as the backbone of security for the embedded systems.
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 and power plants have a long service life – 20 years or more. Older embedded systems often don’t get updated because the older hardware is obsolete and doesn’t support the new software. Designing a system to be secure at all levels can greatly increase the viability of keeping such 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 hardware that 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. In comparison, the software in a vehicle can put lives at risk, which results in challenging updates and time-consuming testing ahead of deployment, so software updates to vehicles are carefully orchestrated (and costly). Some mission-critical systems are updated by swapping out a component.
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 exploits and mitigations
It’s good to understand your hidden enemies and their tactics. Some embedded system attacks are active: they change the behavior of the system. Other attacks are passive: they read data and spy. In this section, you’ll learn about the anatomy of an embedded system exploit, four attack paths, the most common vulnerabilities, and specific ways developers can harden embedded systems against popular attacks.
Anatomy of an embedded system exploit
How does someone exploit an embedded system? In general, most cyberattacks follow these five steps:
- Get network (or physical) access
- Understand the underlying process, 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 paths
An attacker will gain control of an embedded system through:
- 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, which include software errors that can provide a way for an attacker to gain access to the system. Typically, there is a time lag between the discovery of a specific vulnerability (a CVE) and the availability of a patch to remediate it. Even more time will pass until a system owner will apply the patch with a software update. Meanwhile, any systems running the vulnerable software may be at risk. System hardening and use of additional layers of security – such as a managed security service, firewall or intrusion prevention system (IPS) – reduce the risk of the vulnerability being exploited.
As an example of the number of vulnerabilities found in embedded systems, consider this: as many as 20 percent of industrial control systems have critical security issues.
The six most common types of embedded system vulnerabilities are:
- Buffer overflow
- Improper input validation
- Improper authentication
- Cross-site scripting
- Improper restriction of operations within the bounds of a memory buffer
- Information exposure
Let's take a closer look at some of these vulnerabilities, including how they work and what embedded system developers can do to prevent successful attacks.
Buffer overflow attacks
Buffer overflow attacks occur when an attacker writes data or code to a memory buffer, overruns the buffer’s limits and starts overwriting adjacent memory addresses. If the application uses the new data or new executable code, the attacker may be able to take control of the system or cause it to crash.
Embedded systems developers can mitigate buffer overflow attacks and heap corruption by using tools to enforce good coding practices such as bounds checking input buffers, by performing formal code reviews and by implementing automated scanning tools to detect flaws before a product is shipped. Modern processors and development tools can protect regions of memory such as data areas from code execution. A secure operating system, like the QNX Neutrino RTOS, uses the power of the memory management unit, address space layout randomization (ADSLR) and non-executable stack markers to help mitigate this vulnerability.
Improper input validation
If an embedded system requires user input, a malicious user or process may provide unexpected input that causes an application to crash, consume too many resources, reveal confidential data or execute a malicious command. The unexpected input could be a negative value, no input at all, a path name outside of a restricted directory, or special characters that change the flow of the program.
Developers must check the input before using it. Input validation frameworks make validation easier for developers and improve the maintainability of code.
Authentication proves users and processes are who they say they are. Improper authentication may allow an attacker to bypass authentication, repeatedly try to guess a password, use stolen credentials or change a password with a weak password-recovery mechanism.
Mitigations such as secure device identifiers, integrity protected trust anchors and encrypted password files can help prevent improper authentication. In addition, static and dynamic analysis and formal methods of design review help developers discover and fix code that contains these types of vulnerabilities or back doors to systems like hidden debug passwords.
Improper authentication may allow an attacker to guess a password or use stolen credentials.
3 ways to harden embedded systems
Memory corruption via buffer overflow is a common vulnerability in embedded software. What defense mechanisms are available? At BlackBerry QNX, we call executable space protection (ESP), address space layout randomization (ASLR), and stack canaries the Three Musketeers because they work together to defend embedded systems from exploits. Let’s look at each one:
- Executable space protection (ESP) marks specific memory regions as non-executable, so that an attempt to execute machine code in those regions causes an exception.
- Address space layout randomization (ASLR) allocates the base address of the stack, heap and shared memory regions to new locations every time a new process is executed, making buffer overflow attacks difficult because an attacker can’t predict where the information will be stored.
- Stack canaries allow the operating system to detect a stack buffer overflow before executing malicious code. The OS places a small random integer before the stack return pointer and checks for it before overwriting memory. If the stack value has changed, the OS will stop execution and cause an exception.
Although 70 percent of the 30 most popular embedded operating systems lack one or more of these essential defense mechanisms, QNX RTOS provides all three.
70 percent of the 30 most popular embedded operating systems lack essential defense mechanisms.
Embedded system encryption
Information exposure is another common vulnerability in networked embedded systems. Transport layer security (TLS) can thwart information exposure attacks, including data spoofing or device hijacking.
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 network traffic should be authenticated and encrypted with rolling keys to protect the system. Additionally, device certificates can be used support client authentication. This is an increasingly common way to prevent the impersonation of IoT devices and support secure peer to peer connectivity.
Protecting sensitive device data, such as user data or proprietary information is also critical. Only a user or device with authorization should be able to decode the encrypted data, making it inaccessible to threat actors. This means sensitive keying material needs to be protected. This can be done by personalizing embedded devices with their own unique hardware keys or using hardware key stores or integrity protection modules (IPM). It is also a best practice to allow only privileged/authorized processes in a trusted state to have access to OS level or application key stores.
An embedded OS with fewer vulnerabilities
In 2019, Linux had more than 400 vulnerabilities identified in the U.S. National Vulnerability Database (NVD), and Android had more than 800. In comparison, the QNX Neutrino RTOS had 3. As a closed system, the QNX Neutrino RTOS is more secure than an open source OS, and a better choice for secure embedded systems.
Best practices for embedded security
Embedded systems security must be addressed in a holistic manner with best practices throughout the software development lifecycle. In this section, you’ll learn about cyber security standards and frameworks, security risk assessments, supply chain security, embedded security by design, security testing and penetration testing, and secure updates.
Cybersecurity standards for embedded systems
Cybersecurity standards provide best practice processes to help developers build secure embedded systems. While functional safety standards for embedded systems are mature, standards for embedded systems cybersecurity are not fully developed. Currently, the automotive industry is leading the way with these two publications: SAE J3061 and ISO/SAE 21434. Common Criteria and UL 2900 also provide valuable security guidance.
- SAE J3061, “Cybersecurity Guidebook for Cyber-Physical Vehicle Systems:” In 2016, SAE published this set of recommended practices for cybersecurity.
- ISO/SAE 21434, “Road Vehicles – Cybersecurity Engineering:” A work-in-progress, ISO/SAE Draft International Standard (DIS) 21434 will likely be adapted for use in other industries.
- “Common Criteria (CC) for Information Technology Security Evaluation:” This international standard for computer security certification describes a framework users can use to specify their security requirements.
- UL 2900, “Standard for Software Cybersecurity for Network-Connectable Products:” UL 2900 provides manufacturers with testable and measurable criteria to assess security weaknesses, vulnerabilities and risk controls.
Developers can also find security guidance in these 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.
- First published in 2014 as the Framework for Improving Critical Infrastructure Cybersecurity, the U.S. National Institute for Standards and Technology (NIST) Cybersecurity Framework (CSF) is widely considered the first line of cybersecurity defense across all industry sectors.
The frameworks refer to these CIS guidelines and STIGs for additional global cybersecurity best practices:
- CIS Benchmarks & CIS Controls: Center for Internet Security (CIS) Benchmarks provide configuration guidelines to help organizations safeguard systems against cyber threats. In addition, CIS Controls helps IT organizations use security best practices to improve cyber defenses, and the CIS Controls Internet of Things Companion Guide helps organizations apply CIS Controls to IoT security.
- Security Technical Implementation Guides (STIGs) from the Defense Information Systems agency, part of the US Department of Defense, are popular cybersecurity guides.
Security risk assessments and security requirements
Embedded systems security standards are a work-in-progress, and there is no clear formula for building secure embedded systems, but there are recommendations. In addition to security standards, the secure software development lifecycle (secure SDLC or SSDLC) can help every developer build more secure systems.
The secure SDLC can help every developer build more secure embedded systems.
The first step in the SSDLC is a thorough risk assessment. A risk assessment will identify threats, the likelihood of those threats and the damage they can cause. The risk assessment will lead to security requirements. Consider the risks of many types of threats, such as:
- Remote exploits
- Local exploits
- Spying attacks
- Takeover attacks
- Denial of service (DoS) attacks and distributed denial of service (DDoS) attacks
- Phishing attacks
Threat models document input and output threat vectors, and enumerate potential and exploited threats to the system architecture in order to design more secure systems. Two threat models are STRIDE and DREAD.
Supply chain security
Systematic verification of the security of software and hardware components in the internal and external supply chain mitigates the risk of vulnerabilities. A trusted components program includes requirements such as:
- Establishing trusted system components suppliers with a mature secure development lifecycle processes, including security-aware manufacturing process to mitigate the risk of malware entering the supply chain.
- System-on-chip (SoC) should support device provenance and integrity (e.g. secure boot and OS loading) using immutable trust anchors. They should authenticate access to internal debug interfaces to ensure on-chip security functionality cannot be bypassed. They should support hardware root of trust capabilities such as system integrity validation, secure key storage and operations such as encryption, decryption and digital signature operations. If a trusted execution environment (TEE) hardware root of trust is not available, the device should at minimum provide a device 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. No SOUP for you!
- 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 is able to detect counterfeit, grey-market or remanufactured components on both the original production line and during system repair.
Embedded security by design
Hardware, software and cloud vendors must work together to build secure embedded systems. For example, hardware technologies ensure device boot integrity and on-chip security capabilities for robust key management and encryption, which is too computation-intensive for embedded software alone. The embedded operating system supports access control policies, encrypted file systems, rootless execution, path space control and thread-level anomaly detection. Software developers also depend on hardware to provide trusted execution environments (TEEs), trusted platform modules (TPMs) and hardware security modules (HSMs). System designers may also depend on hardware to provide trusted execution environments (TEEs), trusted platform modules (TPMs) for local or remote device attestation to cloud services.
Embedded system design should always begin with an analysis of the device and its intended and potential unintended usage, security risks (attack vectors) and attack surfaces. Security should also be considered at every stage in the SDLC process.
Hardware technologies provide a root of trust and encryption and decryption services.
Root of trust
A hardware root of trust ensures that a device can protect itself and its users by using hardware protected keys and cryptographic algorithms. Hardware capabilities can be used to protect keying material, to monitor the integrity of device software (e.g. TPM functionality) and to authenticate itself to its environment. For instance, using a secure device identifier you can establish trusted communications with peer devices and cloud-based services. 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 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.
Secure boot leverages the signature provided by a device trust anchor, the public key of the root of PKI used to sign device code. When the embedded system boots, the boot image will be validated using this public key and the corresponding trust chain to ensure that boot time software has not been tampered with. Establishing the provenance of the original software and any software updates typically relies on digital signatures from a public key cryptosystem, but in some instances a hybrid model can be used. In a hybrid model, a symmetric key cryptography is used to validate software integrity and speed the boot code verification process for time-critical startup requirements. Unlike code verified with a public key, it is critical that the symmetric key remain secret, known only to the device.
Hardware developers provide many more essential security capabilities to software developers, including these three:
- 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 SoC components provides CPU offload for bulk encryption and decryption. They may also be used to offload network cryptographic functions.
- Trusted execution environment (TEE) or hardware security zone provides hardware-enforced isolation in a secure area built into the main processor allowing the software developer to establish a device root of trust. A TEE may run in a secure mode of the processor (e.g. ARM TrustZone) or on a separated, isolated CPU core, which acts as a security co-processor to the SoC. TEEs typically allow trusted applications to do security-critical processing on behalf of the embedded system.
- Trusted platform module (TPM) provides hardware-based security functions such as a cryptoprocessor to generate, store and use internal cryptographic keys; encryption of keys and other sensitive material stored in device memory; and measurement and attestation of the integrity of a system state during the boot process.
BlackBerry® Certicom® provides products and services that help secure the supply chain with FIPS-approved cryptographic libraries that provide secure remote device provisioning, and that offer on-premise and managed PKI solutions to issue secure device identifiers, and to sign firmware and application software.
Isolation prevents errors in a component from affecting other parts of the system. In a microkernel RTOS, such as the QNX Neutrino RTOS, isolation prevents errors in a component from affecting the rest of the system – a determined hacker can only crash one component at a time. An embedded hypervisor, such as the QNX Hypervisor helps you isolate safety-critical functions from non-safety ones on the same SoC, so you can consolidate more functions onto a single CPU.
Trusted communication ensures that all communications between modules and between the embedded system and the outside world are authenticated, trusted and encrypted. Each connected device should have its own unique private key and certified device identifier. This device certificate allows it to authenticate to a cloud directly or via a separate security gateway to enforce security policies.
Code review and testing
Testing allows developers to confirm that embedded software is secure – or reveal if it is not.
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 open attack vectors.
- 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.
Binary code analysis
Although most SAST is performed on source code, BlackBerry® Jarvis™ is an example of a binary code analysis tool. Jarvis scans binary files included in a build and provides metrics and cautions that tell a developer what to improve to reduce the security debt of the code, which is the accumulation of outstanding tasks that have relevance to security. Security debt is a term used in agile development as part of secure agile software craftsmanship.
Threat defense and in-field tests
Intrusion detection systems (IDS) and intrusion protection systems (IPS) intercept communications defensively to identify or block attacks and the exfiltration of data. Some embedded system security services, such as BlackBerry Cylance, take a proactive approach through threat hunting and security monitoring of embedded systems and IoT devices.
Self-tests assess the security posture of an embedded system in the field. Self-testing analytics and diagnostic software 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
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 like 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 done only after extensive testing of its impact on the whole system. Until recently most embedded software updates were done 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 like authentication mechanisms, end-point management systems, cloud, software repository and 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
BlackBerry QNX is trusted in critical systems globally to provide the software foundation for safe, secure and reliable systems. In this section, you’ll learn more about our secure software solutions, professional security services and security industry leadership.
Secure software foundation
BlackBerry’s reputation as a security vendor is second to none and backed by 40 years of experience delivering secure and reliable software for embedded systems. BlackBerry offers the world’s most trusted mobile security-backed by decades of experience. Similarly, the QNX Neutrino RTOS and the QNX Hypervisor are the gold standard in embedded software operating systems and hypervisors, and BlackBerry QNX has the expertise needed to help our customers build more secure products.
BlackBerry QNX provides businesses in the most demanding industries with the building blocks for secure embedded systems; these include:
- The most 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 our gold standard BlackBerry 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:
- Open source software (OSS) assessment
- Software security assessment (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 Cylance is an AI-based endpoint security solution 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 Cylance has redefined what an endpoint protection solution can and should do for organizations by utilizing an automated, prevention-first approach.
BlackBerry QNX offers the most advanced and secure embedded operating system (OS) and embedded hypervisor for mission-critical and safety-critical embedded systems.