Cyber Resilience for IoT: What’s the Right Level of Security for Embedded Devices?

This article is part of the Communication and Systems Design Series: Fortifying Cyber Resilience in the IoT

What you'll learn:

• How IoT connectedness leads to more vulnerabilities.
• The key factors for determining the right level of security for an application.

Traditionally, embedded systems have been kept secure by being physically inaccessible to external threats. Consider the difficulty of hacking a CNC machine. Programming the machine required direct interaction with the machine to upload a file from a disk or, if the system is old enough, a paper tape.

To change how the machine operates, a hacker would have to gain access to the factory floor and physically interact with the machine without being noticed by the person managing the machine. In short, the layers of early embedded security depended on physical security measures such as keycard door locks that prevented direct access to equipment.

With the connectedness of IoT, a hacker needn’t have physical access to equipment to compromise its operation or use it to break into the larger IT network. This is because the same mechanisms that allow a machinist to monitor and control the machine from either a main office or even a remote location can be exploited by hackers. And, as these remote capabilities and their level of flexibility increases, so does the number of openings for cyberattacks.

One could argue that even now, most connected embedded systems remain fairly closed. What this means is that the vulnerability of these systems is still significantly less complex than the standard enterprise network.

For example, an industrial machine may be connected, but only to an on-premises server. To compromise the system, a hacker would need to hack the network and the server, not the machine itself. It may seem reasonable, then, to assume security only needs to account for the actual vulnerability of the equipment. Following this logic, if a device can be protected behind a firewall, it doesn’t need its own security.

This argument fails for many reasons. Consider the accelerated evolution of the Internet of Things. While it took decades for business networks to progress to where they have, IoT-based networks are leveraging existing networking technology to evolve at an incredible rate. This means security based on where IoT is today will be insufficient in a year or two as the technology continues to rapidly press forward and catch up to the enterprise network in functionality and complexity.

We can already see this from the volatility of security in connected applications. Just look at how often a Windows device requires security updates. Note that for systems with a long operating life to stay secure, the entire system must be able to be updated, from OS and firmware to the application. Consider a recent example where a water treatment plant was hacked because the system used a legacy OS that was no longer being updated.

In addition, embedded systems are more frequently being deployed in environments that aren’t within a secure network. In the smart-home environment, for example, there’s at best a router with limited security capabilities that, in many cases, users haven’t even properly enabled. Connected home IoT devices often aren’t even behind an active firewall.

Assessing Vulnerability and Risk

These considerations make a compelling case for greater cyber resilience. Devices need some level of integrated, self-protection that can provide secure operation for years to come. To determine the right level of security for an application, embedded developers need to consider several key factors:

• How the system will be used: Use-cases are an important place to start because they define how the system will be implemented, as well as how users will interact with the system. Together, these determine the vulnerabilities of the system.
• The main vulnerabilities: A system that can be controlled remotely has a different set of vulnerabilities than a system that only uploads operating data for cloud analysis. In general, the more a system can be controlled over the network, the more vulnerabilities it will have. In addition, as a system makes more data available over the network, its operations become more exposed. The greater the vulnerability of a system, the more options emerge for hackers to exploit.
• What can hackers actually do: Given a system’s vulnerabilities, the next step is to assess what actions a hacker can take with a hacked system. This may include controlling device operations or collecting/altering data. Consider a machine that only uploads information about its operations. While machine operation can’t be directly impacted, a hacker could force the uploading of data that triggers desired actions. For instance, a system failure could be simulated so that an alarm is triggered and in turn the machine is manually shut down to find out what’s wrong. There’s also the possibility to consider that a connected device will be used to gain trusted access to the rest of the network.
• What’s at risk: Security needs to consider worst-case outcomes. When—not if—a  system is compromised, there are social, human, and business repercussions to consider. The company’s brand could be damaged from news coverage of a compromise. A customer could experience downtime. Equipment may be damaged. Users could be injured. Loss of data may bring financial reprisals (e.g., consider the stiff penalties of General Data Protection Regulation [GDPR]). The overall risks determine how secure a system needs to be to mitigate these risks.
• Common threats or attacks used to exploit vulnerabilities: Together, these factors help define the types of threats a system needs to protect against. Common attack classes include logical attacks (via remote access), observative attacks (sniffing interfaces and communications), and invasive attacks (glitching and physical tampering).
• Improving security: Security is a moving target, and new exploits are uncovered regularly. To be secure over the long term, systems in the field must be able to adapt over time.

Once the need for security has been assessed for a system, then it’s possible to develop and implement a strategy to protect devices, data, and users.

In the next blog, we’ll cover securing access to embedded devices.

Read more from the Communication and Systems Design Series: Fortifying Cyber Resilience in the IoT