The essential guide to embedded systems security

Embedded systems security is essential to keeping embedded systems safe from any malicious behaviour. In a world where such systems are all around us, both in commercial and consumer contexts, it can be hazardous if a device is left unsecured. At best, it can limit the device’s performance, but at worst, it can open things up to some fairly vicious vulnerabilities that could affect other systems on the same network and more.

With more elaborate methods to circumvent security than ever, here’s a look at what you need to know about embedded system security and how to make things safer and more secure in the long term.

What is an example of embedded system security?

Two types of embedded systems security exist—physical security and software security. At its simplest, physical security can be solely a matter of locked doors, cameras, and even a security guard restricting access to an embedded system. However, it can also involve using eFuses to store secure boot loader keys, or tamper-resistant memory.

Software security can respond to malicious threats from within the system itself. This can either be during booting or while the system is running. Typically, an embedded system has a minimal operating system focused solely on a critical purpose rather than anything more general.

Examples of embedded systems include everything from your fitness tracker to in-car systems, tumble dryers, to far more advanced commercial devices like spacecraft navigation systems or missile defence setups.

Why are embedded systems under threat?

The risk to an embedded system can be a relatively straightforward one. Depending on the purpose of the embedded system, it can be for monetary gain. Accessing one’s data via an unsecured smartphone or another device can lead to using that data for blackmail or stealing valuable information. For another embedded system, such as a car’s security system, it can enable the perpetrator to steal said vehicle.

One past example found that cameras in Ukraine were easy to access, giving Russian forces valuable intel on what was happening in the area. Another found issues with the security of a connected baby cot, leading it to be rocked excessively by a remote attacker.

Another problem can arise from a car with an unsecured setup that could lead to someone remotely gaining control of the steering system. In recent years, such car hijacking has been proven numerous times. While it’s unlikely to occur for most users, there’s still a theoretical risk that the embedded system isn’t secure.

Many devices might seem insignificant, but they can lead to other issues along a network.  For instance, a smart air purifier might seem harmless to be controlled. After all, its only task is to purify the air and increase fan speed as needed. However, as part of a wider network, getting past its security can lead to someone accessing more of the network, including more pivotal roles that could be more destructive.

Reports have found that millions of medical devices in NHS Trust hospitals in the UK are unprotected due to outdated software and often being left unmonitored. While individually they might not present an issue in their everyday use, they can lead to the network being open to abuse.

That’s why embedded systems are a vulnerability in many cases—for how they can lead to a more significant issue. The more that home networks and commercial networks become interconnected by unsecured Internet of Things (IoT), the more vulnerabilities can emerge. Each network is dependent on its weakest device and its weakest password.

What are the security threats in embedded systems?

For many companies, the first consideration is whether it’s practical on a financial level. A cost/benefit analysis is likely to occur before plans are made. While it’s important to define a threat model that breaks down potential attack types that could happen, along with the likely harm (which includes risk to the business from prosecution for lack of compliance) and any mitigation strategies, some firms may find it cost ineffective to focus on all potential threats.

Once financial considerations have been overcome, it’s worth considering how to secure embedded systems that still need to be connected. Some such embedded devices have been in use for years or even decades. On a day-to-day basis, it’s easy to think of your car or watch, but power plants and defence systems are often many years old. Because of that, they aren’t always updated due to their hardware becoming obsolete and no longer supporting newer software.

Others can be difficult to upgrade or cost-ineffective to do so, leading to products needing to be updated more frequently, leading to security vulnerabilities. While the latest Windows operating system  might see regular security updates, how often might a more obscure tool see an update? In some cases, it’s not always possible to update the operating system, such as if it could break other applications incompatible with the update or—again—due to it not being financially viable.

Across many IoT devices, there’s a lack of standardisation, making it more challenging to develop secure devices and potentially leaving a network open to attack through something that can appear initially innocent. With more people using mobile networks thanks to the rise of 5G, that can also create a problem as a direct internet connection can mean no security protection other than that which the device itself provides.

Not all security threats are as apparent as one would think either. Some embedded system attacks might be seen as active, changing the behaviour of the previously secure embedded system and wreaking havoc. Others are more passive, reading data and spying on a process in operation. Both can be just as destructive but in different ways.

All involve gaining access to the system architecture, understanding the processes involved, finding a vulnerability, and exploiting the issue.

The three most common types of embedded software vulnerabilities

There are many software vulnerabilities within embedded systems, but the same few are most likely to afflict systems. These are the ones that system developers should be most aware of:

1. Improper input validation. This depends on the embedded system requiring user input and the attacker knowing how to manipulate the system. However, with the right (or wrong) input, it can cause a crash or the reveal of confidential data.
2. Password guessing. A breach can be easily made via social engineering or by using a weak password that is easily figured out. Some IoT devices don’t even require a password  or merely need a default one such as “admin”, making them even more vulnerable to this method.
3. Improper restrictions of operations. Suppose a system hasn’t been developed with security in mind, such as by only exposing what needs to be exposed, or using a custom Embedded Linux distribution. It can be possible to access memory locations outside the intended boundaries directly, leading to someone taking control or crashing the system.  This can include network services that should not have been enabled in the first place, such as telnet or FTP when related to embedded systems

How should we secure embedded systems?

As mentioned above, all embedded devices and systems must be designed to be secure by design rather than as an afterthought. A holistic approach is needed to keep such devices safe and secure. In some cases, particularly consumer products, determining whether it’s cost-effective to design  secure systems can play a role. However, it’s crucial to secure even the most innocuous of embedded systems, even if it’s simply through enforcing changing of passwords.

And it’s worth noting that in several territories now, laws are coming into place that require device makers to better secure the embedded systems in their products. Laws like the Product Security and Telecommunications Infrastructure Act 2022 in the UK.

Other systems could be made more secure by using a custom Embedded Linux distribution which is highly security-focused over a more standard distribution. It’s a lot leaner and means a reduced attack surface. Risk assessment is crucial in determining what works best for each given scenario and whether an embedded system needs to be more open and accessible or not. The best method is to keep it as closed as possible without affecting its operation.

Obsolescence can also be an issue with older devices, but that should be less of a problem if embedded systems developers have designed it with security at the forefront of their plans.