The IoT’s arrival came long before people knew how to protect it or use it safely. As a result, millions if not billions of IoT devices have been rushed to market without much thought as to their security. Research from CISCO shows that there will be 27.1 billion networked devices this year - up from 17.1 billion in 2016. This is in addition to the already existing connected devices such as Medical Devices, Programmable logic controllers (PLC), Engine Control Units (ECUs), and similar embedded devices where they are the bases of IoT advancement.
As a result we're now faced with an entire galaxy of IoT devices with security problems. Regulation has come to address these yawning gaps, but often far too slowly and, even with all the will in the world, they cannot retrospectively fix all the weak devices which rolled out to consumers in the months and years previous.
The problems are common and numerous: Sometimes they're rolled out with default passwords which can’t be changed but can be looked up in the device’s online manuals; sometimes they come with firmware that can’t be updated. They often cannot update securely, often handle data insecurely and use weak network communications. Even the security capabilities that are present on the device are often not adequately used. I’ve often found that developers will use a processor on their device, which they are not even aware can use strong algorithms like AES. All they would need to do is look it up on the device’s datasheet.
This real-world danger of these vulnerabilities can range from the ability to steal private information from the user, to conscripting that device into a DDoS botnet, both of which present a real and present danger to human life in the form of weaknesses in large industrial machinery, medical devices or vehicles.
These problems normally start at the manufacturer level. Too few have given thought to the security considerations you might put into the development of an IoT product. The combination of computing and operational technology is a new thing for many manufacturers and they may not even understand it. Unfortunately, this is where the Go To Market (GTM) strategy gets ahead of security for such critical devices.
For many, this will be the first time that they ever have to deal with information security problems in their products. The guidance which tells them how to protect devices will make a huge difference here. Too often, hardware does support modern security protocols, like Public Key Infrastructures (PKI), but ignorant developers default to less secure username and password combinations.
Take the example of a diabetic insulin pump. These medical devices are often a potent example of IoT that can put human life in critical danger. In 2011, researchers showed that they could be hacked and remotely controlled to deliver too much or too little insulin, thus harming or potentially killing the diabetic patient using that pump.
When I studied for my masters degree, I read just about every piece of Infusion pump documentation I could get my hands on to identify what kind of security guidelines the US Food and Drug Administration (FDA) and Federal Communications Commission (FCC) provided for these critical devices. What little I could find was vague - it amounted to references to needing certain kinds of security but rarely went into detail about how to apply it or build it into a product. That kind of vague language provided little useful guidance to manufacturers. Ultimately, it could lead to some manufacturers taking an easier path of implementing less secure measurements such as utilising username and password instead of digital certificates for authentication.
Recently, the FDA has provided more prescriptive guidance that can be used for handling cybersecurity in both a pre- and post-market medical device environment. This is a positive step forward. Where manufacturers face a dearth of good information on how to make secure devices, those devices will surely not be secure. Moving forward, providing an easy to consume guideline that holds manufacturers accountable for actually implementing better security measurements is a low-hanging fruit with incredible amounts of return.
One option that manufacturers and developers can take is to work more closely with their security providers. These security experts can provide insight into security that might not be native to a manufacturer as well as integrate security from the ground up within the development cycle. PKI certificates, for example, can be baked into IoT processors using API requests to the security vendor without the need for a developer to manually place it on there, let alone know much about certificates. Granted this requires cryptographic support already being implemented within the process or using an additional processor such as Trusted Platform Module (TPM) on the same device.
The key to securing the IoT will be security-by-design. That is to say security which is built in from the very beginning of the development process. This will be a new concept for many who are unfamiliar with the field of connected devices, let alone information security. Problems in the IoT might start with the manufacturer, but with the right guidance, they can end there, too.
