How to Use the Best Security for Your Embedded System

Malicious attacks against an embedded device can harm the device, the product it serves and your company. So I’ve gathered best practices and tips from experts to help you give your embedded device the best protection possible.

In this article:

• Traits of embedded systems that can cause security issues
• Basic steps of a cyberattack
• Tips and best practices to protect your device

What is security in an embedded system?

Security in an embedded system protects the system from malicious intruders. Security experts help build and adjust embedded systems to include mechanisms to prevent attacks or limit the damage.

Software vs. hardware security

A lot of embedded device security focuses on its software. That includes firewalls that filter network traffic and block outsiders. But companies can also make embedded hardware more secure.

Software security often concentrates on combating attacks coming through an external network. However, hardware security in embedded systems comes through other means, including key management, encryption and isolation of hardware functions.

Isolation means taking “everything that needs to be secure and isolating it in one part of the hardware,” says Dan Zimmerman, an embedded software engineer and consultant. That means it “can’t be accessed from the remaining, potentially insecure part of the hardware except through well-defined, very narrow interfaces that enforce security constraints.”

Rob Wood, Vice President for Hardware and Embedded Security Services at NCC Group, says it’s best to look at a system holistically and understand security issues can exist in any part of the system.

“Everything is built upon foundations,” Wood says. “Applications are built on top of libraries and frameworks. These run on top of an operating system, which depends on drivers and firmware, which run on hardware. And all of this is designed and built by design and manufacturing processes involving fallible people. Security issues arise in all aspects of this, and the density of vulnerabilities is probably consistent across everything people build.”

Qualities of embedded systems that affect security

Certain qualities of embedded systems jeopardize their security. How much an embedded system communicates with external devices can cause security issues.

The difficulty of updating software in compromised embedded devices is also a challenge.

Here are other details on the qualities that can cause embedded system security issues:

• Level of connectivity: Years ago, embedded systems had little need to communicate outside of the system. Today, many embedded systems communicate through network connections with external systems and devices. Unfortunately, that means those embedded systems are now much more susceptible to outside attacks through that network.
• Level of communication needs: The cybersecurity risk increases with how often the device or system communicates with external devices. A device that communicates continuously through a network connection is more vulnerable.
• Length of the product life cycle: Manufacturers expect embedded systems within some devices to last for years, often without an easy way to install software updates for security issues. Manufacturers of these systems must keep that in mind.
• Type of embedded OS: The type of operating system within the embedded system will affect its security. Applying a security patch or software update can be difficult in many embedded systems; using certain operating systems can make it even more difficult. (You can learn more about embedded system operating systems and choosing the right one for your system.)
• Ability to update and provide security patches: Because of how embedded systems work in many devices, manufacturers build those systems expecting they won’t be updated with new software. So, they will need to consider that as they consider security for these systems. Or they will need to consider the cost of providing updates or replacing the embedded system as a whole when security issues require that.
  
  “Agility to patching is certainly high on the list of characteristics that can leave embedded systems open to vulnerabilities,” Wood says. “With very few exceptions, most gadgets are simply not designed to update their software and firmware automatically and still require user intervention. This is an obvious problem: People don’t even regularly change smoke detector batteries on recommended intervals, so asking them to manually download and apply firmware updates to all their gadgets is a recipe for failure.”
   
• Value of data in the system: Embedded systems may contain more valuable data than other systems for many reasons. Malicious intruders will more likely attack the systems with the most useful data.
• Embedded systems are often customized: Another quality of many embedded systems is that they are customized to work in a very specific device. That means they are much different from a laptop computer that a multi-national company produces, with hundreds or thousands of employees constantly working on its security.
  
  “There’s a fundamental difference for your laptop,” says Vladimir Minenko, Senior Product Manager for Qt. “There is always someone else: the manufacturer or maybe your network system administrator” who is concerned with its security. “But if you’re building an embedded system, your company alone will be responsible for most of its security.
• The low one-time costs of many embedded devices: Many embedded devices are very low-priced items within another product. Once the vendor sells the item, sometimes at mere dollars or less, that company will not be inclined to spend money providing continual software updates.
  
  “The biggest factor is cost,” Wood says. “Providing ongoing software and firmware maintenance for in-market devices is certainly not free in terms of developer resources for the vendor. Most consumer devices are sold at a fixed one-time cost, often very low,  without ongoing maintenance contracts. Hardware subscription models might help resolve this, but that’s a mind shift for users. The ongoing costs will eventually lead to vendors cutting corners and ending support before the devices have reached the end of their useful life.”

Most common embedded software vulnerabilities

The software in embedded systems may be vulnerable to attack. Common problems include weak authentication when the system receives a communication. Another problem occurs with a lack of restrictions on programs accessing memory.

Here are the details of common vulnerabilities of embedded software:

• Weak authentication: Your embedded system software should ensure that every communication comes from a trusted source. Your software should reject all such communications until the system has established the source of communication is appropriate and trusted. Too often, systems allow some external communications to enter without that authentication. That often leads to trouble.
• Improper user input validation: Any data entering a system can become a way for intruders attack or disable the system. In the same way your software checks on external communications, it must validate the format and content of any input before it allows it to enter the system. In essence, any input must prove you can trust it. Good software requires that validation. But too many components in a system may not require that sort of validation. That leads to attacks.
• Not restricting other programs from directly accessing memory: Sometimes, an embedded system’s operating system or programming language does not properly restrict a program from accessing memory. That can allow someone to cause the system to crash or even take control of it. (You learn more about the different types of embedded system memory and how to choose the best for your system.)
• Bad cryptography: Engineers use cryptography in embedded systems as a countermeasure against attacks. But some of that cryptography is badly written and gives people a false sense of security.
  
  “Lots of embedded systems that ‘try’ to use cryptography for security purposes do so incorrectly, in ways that make them trivially easy to break,” says Zimmerman.

Basic steps of an embedded cyberattack

Most attackers focus on system vulnerabilities and follow common steps. For example, the first step is often exploiting bad or easily secured passwords to gain access. Other basic steps then follow.

Here are the steps of an embedded cyberattack:

1. Gain access to the network.
   Hackers will often work to gain access to the network through various means. After that, they can gain access to affect the device’s operations in many ways.
   
   There are complicated ways to do that, of course. But experts say you shouldn’t only focus on sophisticated attacks and defenses. Many hacks come too easily: finding and using a password to get into the system.
   
   “In my opinion, the vast majority of security vulnerabilities are very simple,” Minenko says. “One of the most popular problems, for example, in embedded Linux is to keep using or even set simple passwords or just reuse one which is preset. If you put such a device on the Internet, it will be hijacked the first night.”
   
   Zimmerman agrees: “Many embedded systems ship with bad default administration passwords that are identical across identical products, or even across entire product lines from the same company. That may well be the biggest security problem with such systems.”
   
   Beyond that simple method of entry, there are others. Hackers, for example, can exploit known vulnerabilities to monitor and intercept communications from an embedded device.
   
   
2. Learn how the embedded operating system and hardware works.
   Gaining network access allows a hacker to learn how the system works.
3. Look for vulnerabilities in host protection.
   The hacker can then find vulnerabilities in how the embedded device is protecting itself from intrusions. That might be through a programmable logic controller, through the embedded operating system or middleware.
4. Exploit the vulnerability to attack the system and potentially other systems.
   Once deep into a system, the hacker can manipulate and control the system and gain access to other systems associated with the device.

Best practices to secure embedded systems

Experts recommend best practices to protect embedded systems. Those best practices range from establishing good password policies to partitioning components of the hardware and software.

Here are more detailed best practices to protect embedded systems:

• Fix password issues. Establish strong passwords and password policies. Change the default password that may come with some components that become part of your embedded system. Build your system so it limits the number of login attempts.
  
  “Good passwords, unique to each device, baked in at the time of manufacture go a long way toward taking care of a lot of low-hanging security problems,” Zimmerman adds.
  
  
• Minimize attack surfaces. An attack surface means any point where an embedded system or any computer system is exposed. Attack surfaces include computer code,  ports, applications and websites. Those attack surfaces provide an opportunity for someone or something to invade your system.
  Embedded system designers should reduce as much as possible the number of attack surfaces in the system. That means reducing things you don’t need, from non-essential drivers to excess computer code.
  
  “A smart refrigerator doesn’t need to be running a web or FTP server that is open to arbitrary requests from the entire Internet, for example,” Zimmerman says. “The embedded system should only expose to the outside world services that are essential to its functioning, and even then preferably have some sort of access control.”
  
  
• Use an authenticated or secure boot. Intruders and malicious code can gain access to your system and its software as the system boots up.
  
  “The trick is that hackers try to cheat how the system boots up,” Minenko advises. “And for example, let it boot with a different user than it was originally set to be boot on. And so they try to manipulate the boot process in order to be able to log in or gain more access.”
  
  You want a well-engineered boot sequence to help protect against this. That will include authentication procedures. Specific tools and technologies can help.
  
  
• Partition hardware components. You don’t want all of your embedded system’s software to have access to every hardware component in your system, including components that specific software doesn’t need to access. That just allows more ways for an intruder to get in.
  
  So that’s among the design challenges you must think about as you build your embedded system. First, you must design your embedded system so the software can only access the hardware components it needs to do its work. That provides a more straightforward system configuration. It is also more secure. Vulnerabilities that might exist in one application are limited to only that application and not your entire embedded device.
  
  “The whole point of segregation is that if one entity is attacked, the rest is usually still safe,” says George Zaher, Research and Development Engineer for Classified, a London-based security consultant.
  
  You can learn more about the design process in building an embedded system.

• Use self-contained or containerized software applications. Just as you should isolate hardware components, you should also ensure that one insecure piece of code can’t compromise your entire embedded system. You can help protect against that by using “containerized” software whenever possible. Containerized software includes the program’s code, tools, setting and library in one portable package. That means an attack on or vulnerability in that component won’t affect other parts.
• Protect data at rest. You also need to protect the data stored on the embedded device, which is called the data at rest. Engineers can protect data at rest on an embedded device through encryption of the device’s applications and data.
• Use a trusted execution environment. This means a secure part of an embedded system’s processor. It allows trusted applications to do processing on behalf of the embedded system in a secure way. (You can learn more about choosing a processor for your embedded system, including “system on a chip” options.)
• Communicate only with external sources that you’ve authenticated. The widespread use of embedded devices in the Internet of Things means you must always think about IoT security. Your embedded device should communicate only with outside sources that it trusts and has authenticated. That also means embedded engineers should think about external communications that aren’t necessary for the device.
  
  “Isolating the devices from the Internet as much as possible, or completely, helps too,” Zimmerman suggests. “Because if somebody on your local network is trying to hack your embedded devices, that’s an easier problem to deal with than if the entire world is doing so.”
  
  
• Validate the data from all inputs. Your embedded device’s software architecture should validate the data from any external source before allowing the embedded system to process the data. In addition, your embedded device should make sure any external messages follow a data standard.
• Use address space layout randomization. Address space layout randomization continually changes the address space and locations of key memory regions. That makes something called a buffer overflow attack more difficult. That’s because the hacker won’t know where the information is stored.
• Continually monitor for problems. You need to periodically monitor to understand whether someone is hacking your device or already has. You can do that through anomaly detection of your network or operating system. You can continually monitor your system log and scan for known malware. These steps allow you to take action against potential attackers or revoke trust with certain external devices.
• After detecting problems, fix them. Even with your great efforts to fight intrusions, they will happen. So, one of the most important best practices is this: Detect the intrusion and fix the problem quickly.
  
  “You cannot secure everything. It’s just not possible,” adds Minenko. “So it’s more important that you can quickly react to it and provide fixes.”
  
  Firmware and software makers provide continual updates to fix security issues. Monitor and install those updates.
  
  But Zimmerman also points out that you must be careful even with what can appear to be those updates. “You don’t want trojaned software or firmware update being installed from unauthorized sources, as has happened in some instances in the past.”

Downloadable checklist for embedded security

Download the checklist for embedded security 

Embedded system security depends on a range of measures

Protecting your embedded system requires strong measures. You’ll want to identify every weak link in your system and strengthen it. Work with software and software code that you trust for its security. Everything starts with that.

Qt ensures a secure framework for embedded devices

Developers must protect their embedded devices against intruders who use tampering and reverse engineering. A commercial Qt license makes it legal to prevent any modifications or reverse engineering. That can go a long way to prevent a wide range of attacks.

Developers should focus on a wide range of security areas to give their embedded device the best overall protection possible. Qt is a source code product, from the first to the last byte. That makes it easy to audit and add a quick fix in urgent cases. Qt software keeps a constant focus on the best security and provides a way to protect your embedded device. Watch this 77-second video on how Qt can help with security for your embedded device.

The Embedded Product Planning and Requirements Guide

In this guide for IoT and embedded product planning, we examine the most important criteria to consider at the outset, compare a list of the most used technologies, and rate them in easy-to-compare categories.

Download