Security consultants have long advocated “layers of security” for both physical and data systems. The strategy still applies when you are protecting the remote IoT and IIoT devices that are outside of your immediate control. Protecting the MCU, data, physical devices, and the network are key to securing your IoT and IIoT environments. In Part 1 of this series, we looked at protecting the MCU and boot process, and then in Part 2, we looked at protecting data and physical components. In Part 3, we’ll examine securing the network.
The greatest vulnerability of any IoT network is its exposure to the public Internet. Simply adding an Ethernet connection or wireless transceiver makes the devices a target for botnet herders, ransomware schemes, and data skimmers.
By definition, disabling Internet access is not an option because there is no such thing as the _____ of Things. So, if having a network interface of some kind is such a gaping security hole, how does Industry 4.0 make sure that the connection is used only for good, and not evil?
One approach may be to take advantage of out-of-band communications that are available on cellular radio modules. All cellular modems expose either a binary- or AT-command-interface that allows software to send and receive short messages (SMS). While the cellular infrastructure may use IP for both data and SMS, they are routed differently in each case, so correlating and SMS with a particular TCP/IP connection is difficult. If an IoT device does not allow incoming TCP connections, we can envision the following scenario.
Suppose that one of your IoT devices is reporting errors, so you want to log in remotely and check the device logs to diagnose the problem. Most current devices leave open a Telnet, SSH, or HTTP port, which allows an operations team to connect to it for diagnostic purposes. If we instead disable incoming TCP connections, there is no way to initiate a session with the device. In this case, a specially formatted (and encrypted) SMS is sent to the device, which responds by starting a TCP session to the IP address encoded in the SMS. This creates a kind of “reverse” tunnel over which to conduct subsequent exchanges.
A natural option for securing communications is to use SSL/TLS for establishing a secure channel between the operations center and the remote device. This is an ideal choice if the remote device has sufficient processing power to manage the encrypted link. An additional barrier to using this approach is that each device needs to be provisioned with a certificate and private key, which complicates the manufacturing process.
Regardless of bandwidth constraints of the device, it is good practice to ensure that only TCP ports that are actually used by the application are left open. Additionally, if the device absolutely has to include a management interface (web or SSH), do not provision the devices with the same administrator username and password from the factory. Instead, use a default password that is random, and include it on a sticker with the device. This puts additional burden on the installer to either make note of the device’s password, or to change the password to something that is managed by the purchaser.
Randomized passwords may be perceived as less user-friendly than a fixed default, but it was exactly how the botnet that attacked Krebs on Security was formed. By scanning the Internet for devices with default passwords still active.
A company with thousands of remote sensors stands to lose much more than the inability to check a nanny-cam on the web. The more distributed a company’s operations, the more potential vulnerabilities there are to exploit. Even the lowliest device can become a loose thread that can be picked at until your entire operation unravels.