How to balance connectivity with security in IoT and IIoT

Why add connectivity?

There are many legitimate reasons for including connectivity on a new or existing product. Sometimes connectivity is the entire point and premise of an embedded systems project. Sometimes it just provides quality of life by integrating with other tools and services.

For instance, an industrial system that can report easily on its status without users having to go near it can be especially useful to improve safety in manufacturing environments and maintain up-time.

Then there’s additional non-user facing functionality. The benefits of adding connectivity can include:

• Remote firmware updates that don’t need user interaction.
• Enforcing licenses so that you can protect your intellectual property.
• Collection of usage data for further product development and research.

These are just some of the benefits for a device being able to connect. Taking a solid User-Centred Design approach to adding connectivity can also help you to ensure that you’re adding product connectivity for the right reasons.

What routes are there for adding connectivity to devices?

Depending on:

• User experience
• Power constraints
• Licensing
• Existing hardware designs

There are a variety of ways that an embedded device may connect and communicate over the air or through wired means. Options include:

• Over the GSM network using a publish/subscribe protocol like Message Queuing Telemetry Transport (MQTT) which can be used for smart city vehicles.
• Using low-power, mesh technology such as the Thread networking protocol.
• Streaming data over low range radio protocols like Zigbee as part of a personal area network.
• EtherNet/IP which is an industrial protocol standard for Ethernet which enables larger data volume to be sent across networked machines faster than options like the PROFIBUS RS-485 serial communication method.
• Standard Wi-Fi protocols, which are used across a variety of existing IoT devices.
• … and more.

There are as many ways to connect devices as there are applications out there. Plus, there are differences based on the setting.

Perhaps one of the critical considerations is how much power (energy) will be available for your product. As we discussed in our blog post on green software engineering, wireless connectivity options such as GSM and Wi-Fi often use more energy than other technologies and are therefore unsuited to low-powered environments.

But there’s an even more significant consideration:

Security.

Why you need to think about security from the start

There has been a tendency to not take security seriously in consumer devices. Even in commercial devices for enterprise, attitudes toward security have often been lacklustre despite ever-evolving and complex security threats.

But can stakeholders in a product’s supply chain afford to continue thinking like this?

Security in consumer IoT is already an issue

In the first half of 2020, SonicWall recorded a 50% increase in attacks on IoT devices. As SonicWall explains:

“While most people have at least some IoT devices, many don’t have the time or expertise to adequately secure them. But when these devices connect to endpoints that connect to corporate networks, they can provide cybercriminals an open door into what may otherwise be a well-secured [organisation].”

And the above is just considering the threat posed by consumer IoT to corporate networks.

It doesn’t consider the threat to consumer data which, depending on device function, can be incredibly personal and valuable. Or the risk IoT devices spell for increasing sizes of botnets used in cyberattacks. Nor does it consider the threat to consumer safety, an issue keenly highlighted in the 2019 recall of 4000 insulin pumps that had unpatchable, unsecured wireless connectivity.

IIoT is at risk as well

Meanwhile, with Industrial IoT devices enabling companies to achieve the transformation to Industry 4.0 operations, the security threat posed by connectivity is a challenge that needs to be addressed here too.

Speaking with ZDNet, Eitan Goldstein (Senior Director for Strategic Initiatives at Tenable) points out that:

“Historically these devices would have been on an island. Nobody thought much about them, they were theoretically air-gapped and didn’t connect to anything.”

Even without a surge in IIoT, hackers are already working hard to find their way into systems. In 2018, the US Department of Homeland Security revealed that hackers had managed to infiltrate the control rooms of US utility companies.

As attack surfaces increase, so do the opportunities for adverse cybersecurity events to occur. And from the FDA to ENISA, there are demands for products to have security by design.

A shifting expectation of risk and legal responsibility

Suppose the increase in attack surfaces and the activities of hackers wasn’t reason enough to sway you toward security by design. In that case, prosecutors are now starting to look along tech supply chains for who to prosecute after serious cybersecurity incidents, further adding to corporate risk.

For example, an ongoing case in Germany has recently seen prosecutors shift their attention from hackers to the IT team responsible for a hospital’s systems. In this case, a ransomware attack compromised the IT systems.

So how do you work to secure connected devices?

Five ways to support security by design

Enable security by design from the outset

A networked device’s security is as strong as the weakest link. Seeing as the start of a project is where all the building blocks are set, it is tough to retrofit security as an afterthought, and it’s likely by doing so would incur undesired behavioural changes.

Minimise the attack surface

Superficial and/or redundant connectivity features should be limited. There should be, if possible, only one way to perform anything the device needs to do. All behaviour should be correctly gated behind authentication with a transparent permissions system.

Understand the trade-off between in-house and third party

There are advantages to both. In-house code is less likely to be secure, but usually less exposed to malicious actors. Third-party code (especially free and open-source software, like Linux) is expected to be more closely scrutinised and frequently updated but is also more likely to be targeted by attackers.

Look at your supply chain

It’s also worth considering your entire supply chain from start to end, and to do so for the whole lifecycle of a product. ENISA has released detailed guidance on securing IoT and IIoT devices. They suggest ensuring there is clear communication with and between suppliers for certain aspects of development, and to consider adopting “the view that security in the chain” is “a continuous process”.

Build a security culture

Software developers are technically minded by nature, so it’s difficult to create interest in security through legal and regulatory angles. Instead, many developers prefer to respond to offensive security challenges. Any organisation that wants to enforce a culture of security by design would benefit from an in-house “red team” that routinely carries out penetration tests against products and/or infrastructure from other teams.

Deliver the benefits of connected devices without the downside

Taking a security-first approach to developing connected devices means that it will bring benefits such as updateable systems or real user data to your product, but with a smaller security risk to everyone.