Controllers are part of the system, when you’re thinking of the Internet of Things. They are nothing more than devices on the network, and the key to their protection is making the network as secure as you need the controllers to be. The IoT is a brave new frontier, and these 11 international experts give their thoughts on keeping controllers secure and navigating through the IoT.
Learn more about IoT and what it means to manufacturing at Smart Industry.
How can machine builders protect the controllers in their equipment from external cyber hacking?
Dwayne Dixon: Use secure elements to protect encryption keys, temper detection circuits and limit the system access of individual nodes to prevent them from becoming threat vectors if they've been compromised.
Martin Harnevie: The protection of controllers must be part of the overall security management. We cannot protect controllers in isolation, as long as they are part of the overall IoT system. Well-executed and maintained security management of the complete IoT system will also protect the controllers. In some systems, the option of having a hybrid cloud—part public, part private—can be useful and economical for such controllers that handle local protected data.
Peter Waher: Using the “delegation of trust” communication pattern allows for dynamic security decisions to be taken in real time in complex networks. It allows for fine-grain control by the owners of the equipment, not the operators of the system or network, of which data values can be read and which control commands are executed by different parties. A successful distributed IoT architecture provides the same resources and decision support mechanisms to all participants in the network, be they sensors, actuators or controllers.
Samuel Bucholtz: Do not expose an interface. A cyberattack requires an interface—port, socket, API—to communicate with. If no interface is exposed or the data/operations sent into that interface are tightly regulated, an external attack becomes much more difficult. Design security to be on by default. Require users to expend effort to make the system less secure. Builders should also adopt learnings from the software industry—incorporating the hardware, firmware and software for machines into an overarching security development lifecycle, which includes training, threat analysis and testing.
Jonathan Pollet: Machine builders should ensure that minimum key security features for data, content, devices, the network, access control, monitoring and measuring are supported within their hardware or software. These security features should be preset at the factory level to the maximum security settings but allow the user to log into the device and have the flexibility to change these security settings to adapt the device best to their environment.
Any additional comments or recommendations you’d like to make concerning IoT, M2M communications or cloud-based data exchange?
Harnevie: It is a fascinating world we’re entering, almost regardless of which industry one is in. The vast opportunities, both in terms of increasing competitiveness and growing into new markets, should not have to be impeded or unexplored by fear of security threats as long as security is managed.
Pollet: Securing M2M and IoT communications is a very new topic, and unfortunately there does not currently exist any standards, best practices or regulations that can be used to help drive consistency in the product market. Each device manufacturer is left to try to figure out which security features to include in their devices. And, without common standards, security tends to fall to the lowest common denominator. Proactive device manufacturers can look to the NIST Cybersecurity Framework set of controls as guidance, and one device manufacturer that has incorporated security concepts into all of their embedded devices is HP. Look for a white paper that will be coming out soon whereby Red Tiger Security collaborated with HP to bring a common set of security controls to all of their printer and embedded devices.
Dixon: The Industrial Internet of Things holds a great deal of promise. Analysts estimate worldwide spending of $500 billion by 2020 with optimistic forecasts ranging as high as $15 trillion of global GDP by 2030. There are, however, significant security concerns that must be addressed. A recent report by GE/Accenture articulated best practices. Assess the risks and consequences. Use experts to evaluate and fully understand vulnerabilities and regulations to prioritize the security budget and plan. Develop objectives and goals. Set the plan to address the most important systems with the biggest, most impactful and immediate risks. Enforce security throughout the supply chain. Incorporate robustness testing, and require security certifications in the procurement process to ensure vendor alignment. Utilize mitigation devices designed specifically for industrial control systems (ICSs). Use the same effort given to the IT side to ensure ICS-specific protections against industrial vulnerabilities and exploits on the OT side. Establish strong corporate buy-in and governance. Gather internal champions, technical experts, decision-makers and C-level executives to ensure funding and execution of industrial security best practices.
Nicola De Carne: The cloud is efficient. Information storage, processing and management can all be done off-site, with redundancies, backup, security and service assurance, but we have to consider enhanced security and privacy concerns and real-time data processing demands. In some cases, the cloud is just too far away and not under the appropriate level of control. Plant operators are not comfortable with this situation, and this is important to provide a solution with the opportunity to offload part of the intelligence in the cloud to the edge. In particular in the industrial IoT it is particularly important for the manufacturer to improve the distributed intelligence to the edge to better manage the impressive increase of the data flow and the security issues.
Waher: It is important to make a clear distinction between M2M and IoT on one hand, and big-data on the other hand. Often, these terms are intermixed, as if one depended on the other, or vice versa. These are completely different architectural toolboxes that in some solutions can be used together and in some solutions can be completely different. For an IoT solution to be flexible and applicable in as many contexts as possible, it cannot depend on centralized architectures, such as big-data solutions do. They should be able to be used in such situations, but they must also be usable in completely distributed solutions without big data centers in the cloud storing data and making decisions.
Since distributed architecture is more difficult, I suggest everybody start thinking distributed when it comes to IoT, rather than centralized. It’s easier for a distributed solution to be used in a centralized deployment, than the other way around. Centralization is just a special case of the more general decentralized solution. You can read about these new communication patterns and the new communication paradigm being developed for IoT in my book, “Learning Internet of Things”. And anyone can experiment with new APIs and protocols at www.thingk.me/provisioning.
Main image courtesy of David Castillo Dominici at FreeDigitalPhotos.net