Machine builders take the first step in providing equipment data to users. Without a machine, there’s no data to share. When the controls network is designed, machine builders now account for that connectivity to other machines, as well as the plant network and beyond the plant walls to a global Internet of Things (IoT). We asked an international group of heavy hitters in the IoT domain to offer their suggestions on how machine builders can design controls and automation with data communications in mind. Learn more about IoT and what it means to manufacturing at Smart Industry.
Click here to meet the panel of experts.
How can machine builders design equipment controls that lend themselves to secure M2M or IoT communication?
Martin Harnevie: Involve the whole design team, from the CTO to programmers. Study ISO 17799 carefully. Perform a security design review before prototyping. After prototyping, perform security tests in target environments. It’s often a good idea to employ a number of pre-graduates or new graduates with bachelor of science or master of science degrees in electrical engineering or computer science to perform security stress tests. Perform a second security design review before serial production.
Samuel Bucholtz: Provide crypto-coprocessing and standardized crypto and communication protocols. Design systems with an understanding of crypto lifecycle. Of course, you also should be following the NIST Cybersecurity Framework. This isn't a blueprint for security, but it is a good guide. It gets you to ask yourself the right kinds of questions. Again, I would strongly advise conferring with outside specialists to make sure you're developing the right set of controls and that the controls are both comprehensive and tested.
Francisco Maroto: Machine builders must be advised by software vendors, hardware vendors and communications equipment vendors to use the security features of their products and then make sure when designing new equipment to count on security engineers and developers to implement security requirements and make sure they run extensive tests before they launch production.
Jonathan Pollet: The NIST Cybersecurity Framework (CSF) contains a minimum set of cybersecurity controls that should be supported for devices connected to critical infrastructure systems. The NIST CSF breaks down these security controls into categories. “Asset management/inventory” tells you which devices are on the network. “Protect” means access controls that protect access to the system. “Detect” is the ability to detect abnormal system conditions. “Respond” means the ability to provide logs and information necessary to respond to an attack or troubleshoot the process. “Restore” is the ability to support simple and effective backup or restoration services. We use the NIST CSF set of controls to walk our clients through these controls to determine how their products support the intent of these controls.
Peter Waher: Traditionally, machine builders normally thought that it was sufficient to implement support for a protocol to allow for device control or readout. When connecting things to the Internet, this is not sufficient anymore. They try to provide encryption technology onto their devices, but this is not sufficient. Each party connected to the Internet must respond responsibly to any type of request it receives. This implies making responsible security decisions. The problem for devices is to make good security decisions. Should this be preconfigured? What happens when new decisions have to be made? Should the device require reconfiguration each time? What happens when new security threats appear? The Internet is dynamic, but devices cannot always be easily updated to reflect this change, so a different approach is required.
Also read: What is the danger of taking M2M communications to the Internet of Things?
One way to solve this problem is to implement a communication pattern that is called “delegation of trust.” Whenever a new decision has to be made, a decision that has not been made before, the device asks a more powerful trusted party if it is allowed or only partial permission is granted. This allows secure decisions to be made at a device level in real time without impeding overall system performance in the long run. It also provides a mechanism to easily update network rules in a distributed fashion, where owners of things can control all their things dynamically, without affecting the operators of the infrastructure.
To implement this communication pattern, a communication infrastructure that allows for authenticated identities of all participants in the network is required. On the Internet, this infrastructure should also be globally scalable, which requires federation. One standardized Internet protocol that provides a globally scalable communication framework with globally authenticated identities and authorization and point-to-point communication that has been available for decades is XMPP. It is ideal for the implementation of this communication pattern.
Developers interested in testing these new paradigms are welcome to check out our API page, which provides more information about the details of the protocols and patterns used. Apart from the pattern described above, it also provides an architecture that allows for zero-configuration of devices for the Internet of Things, in a secure and still interoperable manner. It allows manufacturers to create devices in production that require no further configuration to be able to be used in IoT solutions, and yet still be secure and interoperable. My book, “Learning Internet of Things”, delves into these patterns more profoundly. It also goes into details regarding Internet-based communication protocols for the IoT and their pros and cons. I’ve also published freely available source code for all included protocols. These projects implement all these patterns and more.
Vihang Sapale: They should rely on hardware security, and not only on software security, while designing machines. And the identity of the machines should be exposed only to intended users.
Dwayne Dixon: Security must be designed in from the beginning and be integral to the system architecture, rather than applied at the end of the project as an afterthought. It must be included in automated testing. The system engineers must be up to date on current and past threat vectors.
Main image courtesy of sheelamohan at FreeDigitalPhotos.net
