In modern ships, we find highly complex controller networks, so much that a modern ship is more like a floating factory, managing power, controlling ballast tanks and thrusters based on a number of inputs from the bridge and from sensors, and also providing the operator on the bridge with crucial information. The thrusters can be procured by one vendor, while the dynamic positioning systems can be bought by a different vendor, without sacrificing interoperability.
Network of things
The key to success for these kinds of networks is that the machines speak the same language. Information a sensor gathers is typically not displayed directly to a human, but must rather be interpreted and “understood” by another machine. A climate control system e.g. Needs to know what units temperature and humidity is measured and how this information is encoded on the network. For this to work, it is important that devices adheres to standards.
In automotive, cars typically use controller area network (can) for communication. First, can was mostly a communication standard defining how raw information should be sent on the wire, but have later been extended with more standards that defines in detail behavior of specific applications. The canopen standards provides a wide range of device profiles for a myriad of applications, for everything from medical tomography to large crane installations. There is also a standard for writing a standard if none of the existing fits your application. The marine industry have also extended canopen by standardizing how high reliability redundant networks can be built for ships, maintaining control over the ship even in the events such as fire disabling parts of the ship.
There is a lot of good work that have been put into making such standards for interoperability, but how does it relate to a smarter and more connected internet of things? Without standards, we risk ending up with an internet of incompatible things, or as jean-louis gassée from the apple initial alumni team put it, we end up with a “basket of remotes”. Today we often see each internet of thing vendor providing their own app for controlling their devices, but they provide no way to integrate the different devices into doing new smart things in a seamless way. However, home automation standards such as zigbee or z-wave takes some of the same design decisions as industrial standards, and specifies how different kinds of devices should operate in order to be compliant with the standards.
While industrial networks have typically been designed with safety and reliability in mind, security is another issue. Features such as authentication, authorizon and confidentiality are typically not subjects that are being addressed by industrial standards. If we are going to apply the experiences from industrial networked devices to the internet of things, these are issues that needs to be addressed. The security expert bruce schneier compares the current situation to the general computer security of the mid-90s, when the internet first saw widespread adoption, but without software or security practices ready for this revolution.
In 2010, security researchers studied the tire pressure sensors of a car. Since it is hard to make wired connections to a rotating wheel, the tire sensors were made wireless, and this was what interested the security researchers. By forging malicious data into the wireless receiver of the car, the researchers where able to take full control of the internal network of the car, and were able to monitor and control critical subsystems such as engine control and braking. That this breach was possible was mainly due to a design that did not take into account security attacks of this kind, but a design that was based on the assumption of security by isolation of the network.
A conceptually similar attack was brought against nuclear enrichment centrifuges in iran, with the internet worm stuxnet. Even though the enrichment plant was not connected to the internet, this worm also spread on usb thumb drives, and in the end, the attack succeeded in spinning the centrifuges into destruction.
A basis for making secure software for devices is to have a clear and well defined communication protocol. Typically it is seen that proprietary solutions have had less scrutiny and discussion than openly developed standards. One interesting case is the industrial bus hart, which have been extended to a wireless standard, wirelesshart. In this standard, in addition to the more traditional reliability and safety concerns, security is also addressed, keeping unauthorized devices out of the network, and keeping messages confidential and authenticated using encryption.
But even a good design can have a buggy implementation. While we have many good practices for achieving high software quality, it is sadly beyond the state of the art to implement perfect software without security holes. A device vendor that ships a product must acknowledge this in order to maintain a satisfactory level of security. Security, like hygiene in a hospital, must be viewed as an always ongoing process, embracing the whole lifetime of the products. In 2014, both general motors and tesla was ordered to do a recall because of a fire hazard when using damaged charging cables. Gm had to physically bring in all the cars for repair, while tesla performed an over-the-air software update to detect bad cables, and then limit the currents to safe levels.
Need for experience
While we are seeing a growth of new devices targeted for the consumer market, it is not clear how this myriad of devices should be connected in a meaningful way. The industry have been successful in defining standards and protocols for such use, but there is still work to be done with security before exporting these ideas to the mass market. Also, it is also wise for the industry to try to learn lessons from the development in the consumer market, where the innovation moves at a even faster pace.