How to Harden Applications against IIoT Security Threats

The miniaturization of sensors and radios has enabled the placement of millions of smart connected devices in industrial applications for purposes such as automation, remote monitoring, and predictive maintenance. Collectively, the industrial Internet of Things (IIoT) is considered to be a more robust version of the classic IoT, where connected devices provide data for commercial and consumer applications.

In IIoT use cases, smart devices can be deployed in construction vehicles, supply chain robotics, solar and wind power, agricultural sensor systems, smart irrigation, and more. IIoT applications tend to have one thing in common: they are deployed in challenging network environments. While Wi-Fi can support many of these IIoT applications, some use cases will require 4G LTE or 5G NR cellular technologies to set up private cellular networks.

But with remoteness comes vulnerability. Recently, IIoT cyberterrorism has emerged as a particularly worrisome trend. These potentially devastating security breaches make exceptionally strong security essential for any business that deploys remote IoT devices. The latest technologies, such as communications platform as a service (CPaaS) and secure access service edge (SASE) can help these businesses keep their connected devices secure, but to counter the evolving range of cybersecurity threats, application developers must evolve their security smarts by:

1. Understanding how and why their IIoT applications and devices are vulnerable to hacking attempts;
2. Applying modern solutions and strategies to harden the security of their devices and applications.

This article will explore both of these points and provide a set of best practices to address IoT security concerns.

IIoT security is a multi-faceted problem

IIoT security breaches can mean far more than just financial losses, they can severely damage the reputation of the business and cause enormous disruption. Whenever IIoT devices are located in insecure locations, security is no simple task. Here just some of the questions that development teams must consider:

• How can I remotely control, manage and troubleshoot my devices without leaving a door open for attackers?
• How can I prevent an attack from being executed from an IoT device?
• How can I securely transport data over the network to my application while preventing attackers from gaining access?
• If my infrastructure is on one of the big cloud providers, should I consider additional security measures?
• How can I make a SIM more secure so that it cannot be misused in another device?
• Where should I store passwords, identities, and certificates on the device?

It all starts with attack surfaces

An attack surface is any point or part of the system through which an unauthorized user/attacker can try to get into the system. Within any IIoT solution there are many attack surfaces: the device itself, the wireless module, the data transmission from device to application, the application infrastructure, and the application itself. Any of these can be used to gain access, to misuse the system, or to disclose or modify confidential information.

To incorporate security into the design of your deployment is to minimize risks for each of the three attack surfaces: the device itself, the network, and the application. Each attack surface requires its own specific security countermeasures. Let’s evaluate each one and, as we go, identify some best practices to minimize security vulnerabilities.

Device security

The device is the end point of any IoT deployment. It could take any form factor: a sensor, a GPS tracker, a car, or an edge gateway. An IoT device connected by means of cellular connectivity usually consists of three major components:

1. SIM card
2. Physical device (includes processor, storage, OS, external interfaces)
3. Device software

Each of these components has a Root of Trust (RoT): an unchangeable source that is guaranteed to be correct. Many security processes, such as encrypting user data or validating data, are based on the Root of Trust.

1. SIM card

Mobile connectivity brings its own Root of Trust – the SIM card. Based on 30 years of evolution and standardization, SIM cards secure data transmission on the mobile network and ensure the proper identification of a connection’s source. The following information and algorithms are part of the RoT permanently stored and executed on the SIM card:

• ICCID – identifier of the SIM card
• IMSI – international mobile subscriber identity; used for authentication with a network
• PIN1, PIN2 and PUK – PIN Code. Less frequently used in IoT use cases as it requires unique device and/or screen configuration
• Authentication key Ki – unique key used together with IMSI for authentication in the GSM network
• Security algorithms – A3 for authentication, A8 for cypher key generation
• ADM keys – multiple keys that protect the editing of the SIM card with a SIM editing application

The SIM’s unique identifiers play a central role in authenticating the device on the mobile network, granting or blocking permissions based on network policies, and transporting data securely within the network.

Best Practice #1 — device SIM security

Effective precautions to protect your device SIMs are:

• Using embedded SIMs that break when removed
• Activating an IMEI lock so the SIM can only be used in one device
• Using a cellular network firewall to control traffic to unauthorized destinations

Best Practice #2 — device data security

To protect data on a device, recommended precautions include:

• Using strong adhesive that will break the device when it is under physical stress
• Deactivation of physical interfaces (JTAG/Serial)
• Encryption of on-device storage
• The use of tamper-detection alerts that trigger remote data erasure

2. Physical device

The fact that IoT devices are often deployed in remote locations (where the provider cannot control access) means that the physical device can be the first attack surface. Attackers with physical access to a device could break into it and transfer the SIM to a different device, or attempt to gain access to the data on the device.

3. Device software

The operating systems and software embedded on IoT devices are common attack surfaces due to software bugs or exploits. Therefore, software constantly needs to be updated to protect against constantly evolving threats and vulnerabilities. Given that IoT device fleets could be dispersed all over the world, they should be capable of being managed and updated remotely. Two key capabilities are needed for this: remote device management, and remote access.

Remote device management allows IoT businesses to remotely update the firmware or execute predefined commands on multiple devices. Usually, a centralized server prepares the software image or action that the device downloads when it communicates with the server.

Remote access allows a support engineer to log in directly to a device for troubleshooting. This could be to access the file system, execute commands, or analyze data that is not sent to the application. Remote access does not require data to be sent from the device – only that a PDP context from the device is open.

Best Practice #3 — device software security

• Conduct and verify remote firmware updates over a secure channel
• Allow firmware rollback in case firmware update fails
• No hardcoded credentials, clear-text usernames, password, or encryption keys on device
• Delete relevant information remotely when the device is placed out of service
• Use remote access over a secure channel
• Follow CI/CD and roll out latest security updates for used libraries in short time windows

Network security

Next, let’s consider the network for IoT cellular deployments. All telecommunication services (voice, SMS and data) provide an additional attack surface that can be exploited by criminals. Cellular providers with an IoT focus provide mechanisms to block or limit telecommunication services at the network level to prevent attacks that misusing these services.

Voice services

Although voice is not widely adopted in the IoT domain, there are still use cases that require voice capability. IoT solution providers often use Voice over Internet Protocol (VoIP) services instead of the regular telecommunication service, so they can use the same security mechanism used for their data services.

If the voice service is active, attackers with physical access to the device or SIM can commit a variety of telecom frauds. For example, they can incur huge charges through fraudulent calls to premium rate numbers, from which they gain a revenue share. The IoT solution provider is then liable for the incurred costs. Therefore, you should limit the amount and duration of voice services allowed for any device, as well as the numbers that can be called or can call the device.

SMS

Hackers are increasingly using SMS as an attack surface. If SMS is part of a solution and cannot be deactivated, it should be blocked from external devices (also called person-to-person SMS) so attackers cannot reach the device directly. Not only does this prevent attacks, it also eliminates unwanted SMS charges from the network.

Instead of P2P SMS, cellular IoT connectivity providers typically offer an application programming interface (API) to communicate with a device via SMS. The API is secured by additional authentication mechanisms, restricting SMS access to specific users or applications.

Another best practice for IoT businesses is to ask the cellular connectivity provider to limit the amount of SMS that can be sent or received by a device. This prevents unwanted costs if the device malfunctions and sends an abnormal amount of SMS communications.

Best Practice #4 — voice and SMS services

• Allow the cellular provider to block unused services
• Use an API or provider portal to send and receive SMS programmatically instead of using external device-to-device SMS
• Limit the numbers that are reachable via voice
• Limit voice and SMS service consumption to a threshold that fits your use case

Data

Data services are the predominantly used telecommunication service in the IoT domain. Devices can send excessive amounts of data intentionally (due to misuse by an attacker) or unintentionally (due to a firmware or application error). To prevent unwanted costs, cellular IoT connectivity providers can limit the usage per SIM card, according to the expected behavior of the specific device or use case.

Over and above this, when it comes to data, the attack surface is large and there are several security mechanisms to be considered.

IP addresses and Remote Access

Cellular connectivity providers generally offer both private and public IP addresses (IPv4 or IPv6) for devices using their SIM cards. IoT businesses need to choose carefully between private and public IP addresses, as this has a significant impact on attack surfaces for attackers. There are four options: dynamic public IP, static public IP, dynamic private IP, and static private IP.

Private IP addresses significantly reduce the attack surface of devices, as they are not reachable from the public internet and attackers cannot directly route traffic towards the devices. Some cellular IoT providers require the setup of private Access Point Names (APNs) to manage private IP address spaces and the definition of a VPN/IPsec endpoint, while this is not needed by newer providers.

Although dynamic private IP addresses seem most secure, from a practical perspective it is recommended that private static IP addresses are used for IoT devices. This is because dynamic private IP addresses place severe limitations on remote access, which is essential to reconfigure, troubleshoot, and maintain connected devices. Remote commands can only be made with an additional remote access application on the device. However, these applications require additional costs, software maintenance, and device power.

Remote access to a device from cloud infrastructure using static private IP addresses has now been made even more secure with intra-cloud connect. The cellular connectivity provider manages the security of the complete path – from the device to the cloud infrastructure.

Best Practice #5 — IP addresses

• Use static private IP addresses to hide devices while retaining remote access to them
• Use a cellular cloud provider that offers intra-cloud connect, so that public IP addresses are not required for the application infrastructure

Mind the gap!

Devices that connect to the cloud infrastructure via a cellular network may have a security gap between the mobile network and application because:

• The communication from the device within the mobile network operator infrastructure is secured using the SIM card. Only SIM cards that can correctly authenticate their identity are authorized to connect to the network. Based on the identity, different policies like data volume limit, permitted networks, availability of voice or SMS service and so on can be enforced.
• The communication path between the mobile network and cloud infrastructure is not secure. Data goes over the public internet, which creates attack surfaces for man-in-the-middle attacks, impersonation and DNS spoofing attacks.

There are three important mechanisms to prevent these types of attacks:

• a) Transport layer security: end-to-end security between the device and the one application
• b) Network layer security: secure connection between mobile network and IP address ranges
• c) Intra-cloud connect: cellular cloud provider manages security from device to cloud provider

a) Transport Layer Security (TLS) is commonly used within encrypted web pages, where only one side of the communication (i.e. the server) is authenticated. The client on the device can verify the security credentials of the web page and the hostname based on the certificate signature from a certificate authority.

In the case of an IoT device, authentication takes place on both sides. Based on the certificate from the server, the device also encrypts the data it sends with the server’s public key. The server holds the matching private key, with which it can decrypt the data and therefore also confirm its identity. The data between device and server is then encrypted – preventing man-in-the-middle attacks and DNS spoofing.

There are two deployment models for using TLS in IoT:

i. Application-side authentication only. This ensures that the device is sending the data to the right application.
ii. Device- and application-side authentication. In this case, generally considered best practice, the device also requires proof of identity. Cloud infrastructure providers like AWS, Azure and Google have dedicated IoT services that mandate bilateral certificate authentication. Based on device identity, granular policies (such as which data can be sent or read) can be enforced at the device level.

In cases where certificates are required on the device, Roots of Trusts (see Device Security, above) should be used. Several operators display secure certificate storage on their SIM cards. Recently, wireless modem manufacturers such as u-blox have started to provide zero-touch provisioning of security certificates. IoT businesses can also use additional Hardware Secure Modules (HSM) for storing certificates, which provide the highest control and independence.

b) Network Layer Security. While Transport Layer encryption is recommended to be used for securing the data path, there are several challenges. Older devices might not support the TLS version required by the application or cloud service. For example, TLS 1.2 encryption has become mandatory among cloud providers, leaving devices that only support TLS 1.1 unable to connect.

This is where Network Layer Security with virtual private networks (IPSec/VPN) is a recommended alternative because it offers additional benefits on top of TLS.

IPSec/VPN provides a secure connection between the mobile network infrastructure and the cloud infrastructure – closing the security gap. The encryption is offloaded from the device, which simplifies setup while providing older devices with a high level of security. The additional data overhead for encryption is outside the mobile network, so it does not incur additional data costs from the mobile operator.

An additional benefit of Network Layer Security is that the devices and infrastructure are within the same virtual private network. For troubleshooting or configuration changes, devices can be remotely accessed with their private static IP address from the application infrastructure. What’s more, IoT businesses can use their own private DNS server in their cloud infrastructure, eliminating another attack surface that is exploited with DNS spoofing attacks.

c) Secure Intra-Cloud Connect. Traditionally devices need to connect to the public IP addresses of the cloud infrastructure, which creates an attack surface even when using Transport Layer Security and IPSec / VPN. However, with the advent of cellular cloud providers that have their mobile infrastructure already in the cloud, this can be addressed with secure intra-cloud connect.

Under this security approach, data is securely brought into the cloud infrastructure by the cellular cloud provider. The connection to the customer’s infrastructure is established via a secure intra-cloud connect service such as the AWS Transit Gateway. With this mechanism, public IP addresses are unnecessary, and devices and application infrastructure can be completely hidden from the outside. As a result, attackers cannot send any data to devices or the application infrastructure.

Benefits of intra-cloud connect include:

• All the connectivity-related security measures are managed by the cloud and connectivity provider. The cellular cloud provider is responsible for bringing data into the cloud infrastructure. The connection to the customer’s infrastructure is established using a secure intra-cloud connect service such as AWS Transit Gateway.
• Establishing a secure connection with the device does not involve an adjustment of the manufacturing process for certificate deployment or lengthy provisioning of private APNs.
• Integration is automated, and the availability of the connection is based on the reputable standards of secure connectivity provided by the cloud service.
• Public IP addresses are unnecessary. Devices and application infrastructure can be completely hidden from the outside.
• Cloud service benefits such as no upfront investment, high service availability and intra-cloud connect availability in each region.

Cellular network firewall

If attackers gain control of a device (for example, through a Mirai attack), it may not be immediately obvious to the IoT business. The device may then be able to create excessive data traffic by attacking a victim using the public network with a Distributed Denial of Service (DDOS) attack. To secure devices and SIM cards, a network firewall implemented by the cellular network provider is a powerful security mechanism.

Cellular connectivity providers specializing in IoT provide network firewalls that limit the data service accessible by a device / SIM card, so it is only able to send traffic to a specific IP address range. This limits the data service of the SIM card solely to the application’s purpose.

Application Security

Lastly, in addition to protection at the device, software, and network security levels discussed in preceding sections, IoT deployments can be protected at the application level. The ecosystem that surrounds any IoT deployment is complex and diverse — use cases are unique to every industry and the applications associated with them, and often use multiple open-source frameworks and libraries, each with their own maintainer.

IoT businesses should therefore apply an agile security approach that facilitates continuous integration and deployment of application software. This model minimizes the time between the detection of a bug or a security gap and the fix, limiting the impact of any potential threat.

Best Practice #6 – application security

• Follow security best practices, using secure and complex passwords that are changed periodically, multi-factor authentication, well-defined user roles and their permissions, and user audit trails
• To secure databases, use secure APIs that can only be executed by authenticated users
• Limit the API calls that can be executed per user, device or IP address to prevent attacks or errors that target the availability of the system
• Apply an approach that facilitates continuous integration and deployment of application software

Application infrastructure security

One of the earliest decisions that an IoT business needs to make is on the infrastructure they use for their applications – on-premise, virtualized, or private vs. public cloud providers. From the perspective of data privacy and security, the best option is to use a cloud-based infrastructure.

IoT businesses that host their own applications on virtual machines in the cloud will have to manage the security themselves. On the other hand, cloud providers such as AWS, Azure, and Google offer the highest levels of security, with infrastructure certified following international and national approved norms and standards. These providers generally take responsibility for the cloud infrastructure and services in case of security incidents. They therefore have a strong incentive to use the latest security and be innovation leaders in this field.

Infrastructure network

While cloud infrastructure services such as AWS IoT, Azure IoT hub or Google IoT are publicly accessible by all devices, the security of these services is managed to extremely high standards and unwanted access completely restricted. Cloud providers allow the definition of security groups for the virtual machines to limit the traffic into the infrastructure network on the protocol and port level.

Infrastructure accounts and user access

When deploying an IoT solution, the best practice is to logically separate services into multiple infrastructure accounts. The infrastructure is better isolated and the blast radius of human error or an attacker getting access to one account is limited.

Cloud platforms provide identity- and access-management services that allow authenticated and auditable access to all services; user logs are stored for further analysis for abnormal or malicious behavior.

Multi-factor authentication (MFA) provides an extra level of security by asking for additional security checks (besides normal login credentials) from users accessing the infrastructure.

Best Practice #7 – application infrastructure security

• Use cloud infrastructure like AWS, Azure, and Google to host IoT applications: these environments have been designed by domain knowledge experts to meet any level of sensitive security requirements.
• When working with a cellular cloud provider, hide the virtual machine infrastructure in a private network using intra-cloud security to avert port scans, DDoS, and spam attacks.
• Logically separate services into multiple infrastructure accounts, so that they are isolated, and damage is contained even if attackers manage to gain access to one account.
• Use multi-factor authentication (MFA) for an extra level of security.

Now is the time to secure your IoT endpoints

With smart cities, connected health, smart wearables, industrial IoT, and other emerging developments, IoT businesses are reshaping the world by making it more connected. However, keeping up with the latest security approaches and choosing the right one is a major challenge for any IoT business, large or small, anywhere in the world.

IoT attacks have become a serious business – where the attackers’ target is to get control of all the connected devices and ultimately use the hacked device for cryptocurrency mining, to obtain valuable private and financial data from the devices, or to infiltrate ransomware.

By using the best practices I’ve outlined in this article, businesses that depend on the industrial IoT can prevent common malicious attacks and make their business more secure.

Summary

Any internet-connected device can be targeted, hacked, and exploited for nefarious purposes. Worse, as the industrial internet of things expands, more devices—potentially with insufficient security standards - are being connected to it. This effectively lowers the technical bar for bad actors with malicious intent, and means attacks on IIoT devices will escalate, especially as more smart devices are connected. The bottom line: IIoT security should be a priority for every software developer whose applications include data from connected devices.

About the Author

Martin Giess is CTO and co-founder of EMnify, the global cellular IoT communication platform provider, where he oversees the technical execution of EMnify’s product vision. He has 15 years’ experience as a technology expert in agile development of innovative telecom services. Before founding EMnify, he held technical VP positions at Syniverse and MACH. Connect with Martin on LinkedIn.