Equipment data can become vulnerable when it moves outside of the plant floor. Security becomes more important when that data and the network become open to external access and forces. The Internet of Things (IoT) will allow machines to communicate with one another, but ensuring the right machines are sharing the right information and not receiving the wrong commands is equally beneficial. The IoT is a very global network. This group of heavy hitters in the IoT domain offers an international take on M2M communications over the IoT. Learn more about IoT and what it means to manufacturing at Smart Industry.
What should machine builders do to increase the security of their equipment once it’s connected to an industrial network or to a Web-based interface?
Dwayne Dixon: Application-specific firewall settings, application-specific network traffic monitoring, regular security and port scan sweeps are needed.
Glenn Vassallo: The mechanisms to secure Web applications are mature and well understood. This includes authenticating over TLS, using client certificates and restricting access to a range of IP addresses. What is not well understood is how best to implement security from the device side, especially in relation to command and control. There are a number of architectural patterns that can assist with this; the one I usually implement reduces the attack surface by not opening any sockets or ports on the device and then ensuring that all command and control is initiated by the device through a subscription mechanism. Although it is popular to use a VPN to connect machines to control systems, counter-intuitively this can provide less security by providing an open pipe from the control system to the machine. Security needs to be considered as an end-to-end exercise and not one that is focused on the transport mechanism. There are so many layers to security with IoT solutions, from the securing of the hardware—how do you stop people from tampering with sensors or the firmware directly by physically making changes?—to networking and cloud applications.
Nicola De Carne: They have to implement all the standard security protocol both on logic and physical layers to ensure the best reliability and strength of the connections.
Jonathan Pollet: There are several key areas of security that should be supported on all devices that are connected to a TCP/IP network. Unfortunately, many embedded device manufacturers do not support many security features (Table 1).
Peter Waher: First, they need to learn about the new communication paradigms that exist for the IoT, and they need to understand the differences between these and traditional M2M communication paradigms. They also need to understand the reasons for these—what problems they solve and why they are needed. The basic reason these security issues exist in the first place is that the architectures of most M2M solutions are not applicable in the IoT case. For a more in-depth look at more concrete ways of protecting IoT solutions against different modes of attack, see “Security and Interoperability”.
Anand Gijare: Machine builders need to build a cybersecurity roadmap and make the process transparent with their customers. It should include attackers’ generic capabilities, clear and precise adversary behaviors that are updated from time to time, a defined set of desired system properties and set of specific assurances. They should define system architecture with composition of assurances for each independently verified component.
Francisco Maroto: They need to change their minds the way they design machines. They need to think their machines will be connected and have to hire specialists that can help them design secure machines—from security on a chip (SoC) to secure machine identification and authentication, secure protocols, encrypted messages.
Martin Harnevie: In contrast to previous Internet paradigms, which have generally involved networked computers such as servers, personal computers, mobile telephones and network equipment, the IoT encompasses a large number of devices that communicate with other devices. These devices have limitations in computational power and often run on relatively slow networks. Good practices for this rather new situation are yet to be developed. Instead, one should build on existing practices, such as those available in the ISO 17799 “Code of Practice for Information Security Management” and involve experienced IoT security experts to add any missing areas. Whenever a new system is to be deployed or upgraded, perform a security review of the design before the new system or part of the system is deployed. Apart from applicable parts in ISO 17799, the security review should specifically put emphasis on the complete cryptography chain through all data transfer cases; key handling, including the generation, protection and renewal of keys and access codes; naming, identification and geo-tagging of devices; and scrutinizing individual devices for vulnerability in terms risk of back doors to the system and the ability to detect and prevent physical security breaches. This is of particular importance when systems previously having been employed in a closed single-application M2M manner are brought over to take part in an IoT-based system.
Vihang Sapale: The data flow should be AES256 bit encrypted along with a unique identifier. Also, there has to be a provision to receive or send data to a unique Web link instead of broadcasting—limited users with different levels of accessibility at any point of time.
Samuel Bucholtz: Consider very carefully if the equipment should be connected. If connected, consider what functions can or should be exposed over that connection. Machine builders really need to make sure they're not trying to do all of their security planning in-house. They need to get the advice and guidance of "penetration testers" and "incident response firms” that deal with these sorts of attacks. When you're connecting equipment to a network, you need to fully understand all of the types of attacks that could be performed against it—buffer overflows, improper input validation, resource management errors, code injection or denial of service. This is typically beyond the capabilities of these facilities, so they need to seek the counsel of security firms that can check the myriad vulnerabilities that are common in these devices and then run tests to see if the defenses will hold up. Finally, every builder and installer must do the design work with an assume-breach mentality. Plan for the hundred-year storm, but make sure those mitigations reduce the damage of a thousand-year storm, as well.
Main image courtesy of rajcreationzs at FreeDigitalPhotos.net