An enterprise framework that integrates IoT cybersecurity with public key infrastructure (PKI) is essential. IoT cybersecurity for devices is hard. The Device Chronicle interviews Thomas Ryd, CEO, Northern.tech and Mender.io who says that it is essential for enterprises to get IoT cybersecurity and PKI integration right from the get go.
IoT cybersecurity is hard and the reason for this lies in the inherent complexity of IoT projects involving edge devices. The more moving parts and dependencies, the more difficult it is to adopt the appropriate security posture. It is said that perfection is not when there are no more features to be added to a product, but when nothing more can be removed. The same holds true for security. The simpler we can keep things, the more secure they will be.
At the core of IoT cybersecurity lies the answer to the question of who will be allowed to make what changes to which devices when and where. To answer this question, we can look at the 3 main stakeholders in the IoT ecosystem: people, devices and software. The interplay between these 3 stakeholders constitutes the framework of the Triangle of Trust™ . Done correctly, the Triangle of Trust™ seeks to ensure that only “the right people, make the right changes to the right edge devices”. Defining and constructing your security posture through the lens of this triangle ensures a holistic view and keeping the eye on the ball at all times devoid of buzzword distractions.
Authentification in IoT cybersecurity
The first challenge is to ensure the authenticity of the actors. How can we ensure people are who they claim, or edge devices and the software what they report? Authentication ensures authenticity. People can authenticate themselves through simple user/password, or more advanced multi-factor authentication methods. Edge devices and software authenticate through simple unique attributes like mac-addresses and software versions, to more advanced public private (software/hardware) keys. Done correctly, authentication allows us to trust the authenticity of all the actors in the triangle of trust. No imposter will be able to enter into the system.
Authorisation in IoT cybesecurity
Once the authenticity trust is established, the next step is to create and enforce rules as to what these actors are allowed to do. Best practice is to adopt a zero-trust model, which implies that by default everything is denied. All allowed actions must be explicitly expressed and approved by appropriate stakeholders. Authorisations normally affect roles. Roles continue to be assigned to people, software and devices. The developer role and administrator role are two typical roles in many organisations. These two roles will be assigned different authorisations. For instance, the developer role might be allowed to make changes to software that impacts devices running in a confined test environment, whereas the administrator role is allowed to make software changes to devices running in production, out in the field serving real customers. When done correctly, authorization rules ensure that only authorized changes to devices and software are done and then no adversary will be able to make exploitive changes to the system.
IoT cybersecurity and PKI in practice
As briefly explained above, when the Triangle of Trust™ is combined with proper authentication and authorisation, you will be able to design a properly secure IoT ecosystem. Now, let’s view this approach in light of how to update firmware and software over-the-air in connected devices.
Secure people and backend
To update remote IoT devices over-the-air, there must be a backend management system that stores the new software and instructs the appropriate devices to conduct an update. The backend system should offer a proper login system to ensure the authenticity of its users;
- Multi-factor login for human GUI access
- Private/public key for programmable API access
Next, the backend should offer role based access control to ensure proper authorisation of actions. A recommended start could be:
- Admin – full access to everything including deploying software updates to edge devices
- CI – Intended for Continuous Integration systems. It can only upload and delete software on the backend system
- Read-only – the user can see the status of connected devices and deployments, needed for support, but not make any change.
Secure OTA software updates
To ensure the integrity of software from its origin (developer) to final destination (customer device), we depend on the backend. Only authorized users must be allowed to upload and deploy new software to connected devices. To ensure no one tampers with the software in-transit the OTA software updates mechanism should ensure:
- encrypted transportation of software from backend to connected device
- signing of software to ensure authenticity and integrity
- compatibility between software and the target edge devices to ensure new software works
- integrity checks of the various software pieces to avoid corruption.
Secure devices within PKI
Obviously we don’t want anyone, by simply knowing the backend IP address and other internal settings, to be able to take a device, and have it connect to the backend. To ensure that only correct devices are authorised to access the backend, a proper device onboarding (provisioning) system is needed. At a small scale and inside facilities where with visual contact to a device, manual (human) acceptance of new devices might suffice. At scale, or with devices out of sight, other measures apply. Ways to secure and ensure the provisioning and ongoing authenticity of device would be the use of
- private/public key / PKI infrastructure
- keys stored in software (good), or keys stores in hardware (best)
- one-way handshaking (good), or two-ways handshaking (best, eg. mutual TLS)
- secure boot to ensure integrity start to finish.
Secure OTA software updates within PKI
That’s it. A secure backend system, combined with secure software and devices constitute the parts in a secure OTA software updating process for connected devices. Much more can be written and designed into a system to make it even more secure. A gigantic industry stands ready to help you out. But by following these simple steps, your IoT devices are likely to be more secure than 99.999% of all deployed IoT devices in the world!
A great beneficial implication of this fact is reduced chance of an exploit. Hackers always seek the path of least resistance, so why spend the time trying to penetrate your secure devices, when so many other and much more insecure devices exist out there? Answer: They won’t. Best practice recommends building IoT cybersecurity in layers so you get depth. The Triangle of Trust™ outlines a basic depth, and by adopting these, the likelihood of you ending up on the front news headlines for the wrong reasons will be greatly minimized.
Bugs in IoT cybersecurity
This blog post has argued for adopting a zero-trust model around the concept of the Triangle of Trust™ as an easy and smart way to secure IoT systems. These guidelines secure IoT systems from an operational point of view. With this in mind, you can sleep tight at night knowing that only the right people make the right changes to the right devices. If anything goes wrong, it will be easy to track the issue and improve.
However, another very important aspect around the security of IoT devices relates to bugs that can be exploited by adversaries. To protect against this, you would need a rigorous common vulnerabilities and exposures (CVE) patching regime. Additionally, having a proper penetration system to detect bugs, ranging from simple to AI-based super-duper threat detection systems, will be invaluable. Finally, if a worse case plays out, you would need logging and monitoring to recover and restore. How to best approach these aspects deserves another full blog post on its own.
Read how MacGregor is addressing OTA software updating and IoT cybersecurity in the Maritime and Shipping industry.
