Securing industrial IoT applications
For any industrial IoT application, ensuring signal integrity is crucial for safety and operational reliability. However, even the most robust system has many attack surfaces that are vulnerable to would‑be hackers’ intent on compromising a system. This is unacceptable for high‑reliability systems in general, but as more contextual information gets added, including time and position, the level of compromise increasing dramatically, so gaps in security must be identified and closed at every opportunity.
In the case of an IoT sensor, a chain of trust must be established from the sensor to the microcontroller and wireless module, and all the way through to the end application.
In industrial applications for the IoT, every attack surface must be secured in order to establish a chain of trust; which u‑blox has added to its five pillars of security design.
The five pillars of secure IoT are as follows:
• Device firmware and Secure Boot
• Communications to the server
• Interface security
• Enforcing API control
• Robustness that includes handling spoofing/jamming.
Secure Boot ensures that a device is executing the intended firmware by authenticating at each stage before booting the next process. Also, while over‑the‑air updates are useful for mass‑uploads of many widely deployed IoT devices, they create an attack surface that can vulnerable so all firmware must be first validated before being installed. A good implementation will include a back up of a previously authenticated image to allow backtracking if there is a problem.
At the communications or transport layer, a device needs to be able to authenticate itself with the server and all exchanged data should be encrypted, with no possibility of a “man‑in‑the‑middle” attack. Secure key management will allow for this, even on a per‑session basis.
The defined APIs that provide access to device functionality are also a vulnerability that must be addressed, though they are often overlooked. This particularly insidious as hackers usually have a lot of time to look for open APIs and explore there relationship to device functionality and features, which sometimes might include access to paid services. Also, developers often undocumented APIs for their own test and configuration purposes, so these must be protected too, using the same formal authentication and authorization processes as used for all APIs.
The fifth link in securing IoT devices involves ensuring robustness, such as when facing jamming or spoofing attempts that might undermine the device’s ability to get accurate position data from a GNSS. The design must be able to detect that the reported information is not accurate and report the situation to the user or IoT network operator.
For more about security, watch the video (especially 17:46‑27:30):