Don't Internet enable your device

Device builders, please, stop and think for a moment,

before you add Internet connectivity to yet another device.

Are you are fully prepared to wear the cost of securing that device on the Internet for its entire lifetime.

If you are not, you are avoiding the true cost of that device and you are blindly contributing to the massive security problem that we have already.

But c’mon, I know it seems like such a great idea! I know your device may be the next big thing. But …

9.7 billion gadgets in 2020, and their number is growing five times faster than we are.

When you link a device to the public Internet, you actually have a responsibility — not only to the owners and users of that device, but to all the other users and devices on the internet. If your device is hacked and subverted, the impact is far greater than the headache it gives you. And, yes, that headache might be a doozy.

When car manufacturers design and deliver a car, they assume the responsibility to issue and fund recalls for the lifetime of the car. Further, the NTSB mandates that car manufacturers promptly repair cars when design defects arise.

Similarly, device builders have a responsibility to care for the device they manufacture for the lifetime of the device. If a device is to be exposed on the public Internet, it must have the manufacturer standing behind the product to ensure public safety. As we embed devices deeper into the fabric of society — in hospitals, critical infrastructure and other safety essential equipment, how can would we tolerate anything less?

Crazy IoT devices and abysmal security

Over the past year, we’ve seen a crazy array of devices ‘enhanced’ by their Internet connectivity: egg trays, dog treat dispensers, dog fitness trackers, doggie doors, power tools (what could possibly go wrong there), kids stuffed toys, cars, innumerable web cameras, baby onesies, toothbrushes, hairbrushes, mirrors, toilets (mind boggles a bit with this one), beds, and of course, pillows. This may give entirely new meaning to pillow talk, I guess.

Do all these devices really need to be on the Internet?

For years, I’ve worked with embedded devices and I have enjoyed watching our family of device agents and embedded web servers gain market traction at Embedthis Software. Over time, I’ve seen numerous examples of horrendous security practices. I have lost count of the number of times I’ve seen devices with blank or trivial default passwords, easily breached back-door accounts, login forms without encryption, pervasive XSS flaws and so on. I’ve seen some shockingly bad security practices and a pervasive lack of understanding and appreciation of basic security practices. This is not only a problem with minor manufacturers either, I’ve seen it with major manufacturers shipping devices in volumes of tens of millions of units.

I can confidently say that many device builders, perhaps even a majority of device builders, are not building devices that are secure enough for the current hostile environment that is the public Internet.

So how do we create secure devices?

The good news is that the answers are well understood in the general web space. The bad news is they have not been applied widely by developers of IOT devices.

While this is not an exhaustive list, a device builder should at least do the following to ensure a secure design and implementation:

• Hire staff that are specifically trained and experienced in web security.

• Prioritize security and security features into the device from the get-go.

• Ensure devices can be automatically and securely updated and patched for the lifetime of the device for any discovered vulnerability without requiring any user intervention.

• Maintain staff and infrastructure to prepare and deliver security updates for the lifetime of the device.

• Use a connect-out model where the device does not listen for requests but rather initiates the connection itself.

• Secure data on the device and in flight using strong encryption.

• Use TLS to encrypt communications and to authenticate and authorize communications endpoints.

• Use best practices for user logon and password reset — don’t wing this.

• Store passwords using suitable cryptographic hashes with high work-factors like “bcrypt”.

• Perform a security audit of the entire design and implementation.

• Perform detailed penetration testing and fuzzing on the device.

A device builder should NEVER:

• Use default or blank passwords in factory settings.

• Have any undocumented and unpublicized means of access to the device including back-door accounts (like ‘field-service’).

• Use basic or digest HTTP authentication (these both have critical weaknesses in browser implementations and cannot reliably implement log out).

If all device builders do these things, and if users demand them, then the Internet of Things will flourish and we’ll all be the richer for it. Without this, ….. I don’t want to think what the future will look like.