WHY is consumer IoT insecure?

We all know that the majority of consumer smart IoT products are insecure, but I wanted to investigate WHY security of these devices is so bad.

What are the underlying causes? Why and how does insecure product get to market?

I’ve spoken to numerous IoT vendors, hardware manufacturers, IoT integrators and platform suppliers over the last 4 years. Here’s what I’ve concluded:

No one even thinks about security, or assumes that someone else in the supply chain addressed it

In my experience, by far the most common reason is that ‘we thought someone else was doing it’ or ‘we didn’t know about security’. Neither are an acceptable excuse, but when one considers that many IoT market entrants are usually taking a non-smart product and bolting smarts to it, it starts to make sense.

In order to address IoT product security, one needs to have an understanding of hardware, firmware, RF, API, mobile app and web app security as a minimum. That’s a big ask for an entrepreneur who decides to create say a smart toilet.

With their amazing business plan for a smart urinal they go to the finance market for funding. ‘We’re going to create a new market for analysing urine, create a community of users and sell them health products based on the analysis we carry out’.

Backers see dollar signs. The business plan is costed, the cashflow is forecasted and the money is invested.

Suppliers are contracted, the prototype works, marketing starts and production is booked 9 months ahead in the Far East.

Mobile app devs create an amazing app, social media is galvanised to create awareness. The PR machine goes in to overdrive with a live demo at CES.

The product hits the market to great fanfare. Then someone flags a serious security flaw in the hardware.

Nobody paid any attention to security. No-one even thought about it.

Software start-ups are used to moving fast and getting product to market quickly. Security is often overlaid later (not a great idea, but hey). That can’t be done as easily in IoT, as there is product involved, not just code. That leads to my next point:

“We’ll fix the problem once it’s shipped”

This works fine in software as one can quickly push out an update. This works fine in mobile apps too.

But it doesn’t work so well in IoT products.

IoT firmware updates can be painful for the user, as many IoT products rely on the consumer pushing an update from their phone to the device. We’ve bricked numerous IoT products through simply trying to update them in line with manufacturer instructions!

But the most common problem is that the security issue noted during production simply got forgotten about in the rush to release the product.

Finally, the worst issue is when the update process doesn’t even work. Again, we’ve looked at plenty of IoT kit where the hardware wasn’t capable of receiving an update, or had such significant functionality problems that the update process was effectively broken.

“We don’t have any money left for security”

You’ve got your funding costed, the business plan and finance is in place. Prototyping doesn’t quite go to plan, so cash is burned faster than you planned.

Now you’re in to a tight corner: you will be late to market. You will miss Black Friday or CES etc. Sales revenue will be delayed and you’re going to run out of cash.

How do you cut corners? You switch app development agencies from the whizzy, security savvy agency to a unknown least-cost offshore dev house. You have no money to spend on security or security validation. You need to get the product to market, the profits from sales can be used to fix security issues, right?

Your business plan called for a comprehensive security review before launch (because your backers were bright enough to insist on it). Instead you put your product on a bug bounty scheme. Pay for results; much cheaper right? No-one pays much attention to your product because you can’t afford to pay bug bounties. No bugs reported = good security?

I know of one vendor who had poor IoT product security exposed by a consumer publication. They had used the bug bounty approach through lack of cash.

Even after numerous bugs had been reported to the vendor by the consumer publication, only those found were fixed by the vendor. No further proactive security work was done by the vendor. A further review by the consumer publication found more holes. Result? The product was delisted by several large retailers, effectively putting a start-up IoT vendor out of business. Everyone loses.

Do you recall the product and go bust, or carry on shipping regardless?

I have some sympathy for IoT vendors who have a ‘run in’ with security researchers like myself. Responsible disclosure is a process that IoT vendors will never want to go through and was probably never on their radar when starting up.

If the security flaws are so bad that they can’t be fixed with an OTA update, a recall is the only option.

Here’s the quandary: if you do the right thing and recall the product you may well go bust. If you don’t recall the product you will receive bad PR that could damage your business enough for you to go bust.

That’s why all of the vendors I’ve had cause to report vulnerabilities to (with one exception: Aga) have continued to ship IoT product for a period of time, even though they knew it was vulnerable.

A good example was the Wi-Fi kettle from Smarter, who I’m now on reasonably good terms with. Not long after we reported the PSK theft issue, they launched the iKettle 2.0 with improved security. It still wasn’t perfectly secure, but was a lot more robust. The latest iKettle 3.0 is a good, secure product in my opinion.

Had they recalled the 1.0 version after we reported flaws in it, they probably wouldn’t be here today. We wouldn’t have their latest innovations such as the rather cool FridgeCam.

Is that any excuse? No, but I understand why it happened.

A lack of standards and guidance

There has been a lack of standards for IoT security for some time. Several standards are WIP or are already out there. I really like the IoT Security Foundation standard, as it’s geared towards helping IoT manufacturers get it right.

How is an manufacturer who has expertise in making say toilets, going to find out how to cover the full spectrum of IoT security? They probably go to a start-up who claims to be able to do it all for them.

We’ve seen this numerous times – agencies who do mobile apps trying to implement IoT for their clients. Security is an afterthought, if at all.

Personally, I would advise manufacturers to work with IoT platform providers. I really like the Electric Imp platform for its ease of implementation, light touch configuration and good security, but there are plenty of other good platforms out there.

There is good guidance out there, but you have to go find it. It’s no longer an excuse to say that you didn’t know about security or didn’t understand it.

BUT, without regulation enforcing these standards, nothing will actually change for IoT vendors. That’s why the DCMS Secure by Design guidance won’t change anything.

Then we find IoT vendors that don’t care about security

All too often we encounter IoT product manufacturers who are after making a quick buck. They will keep shipping until lawyers or regulators take them down.

It’s usually a rebadged product that has been bought in from the Far East with a shonky mobile app that hardly works. We find a security flaw, try responsible disclosure, get royally ignored. Only when privacy flaws are so serious that a regulator bans a product or lawyers start a class action do they finally stop.

Our research has been involved in a couple of those bans; I was very pleased to see product being removed from the shelves of retailers.

Conclusion

If one doesn’t consider WHY manufacturers create insecure IoT devices, then one can’t fix the underlying problems.

Fixing this requires guidance (which is already out there) and standards to follow (already out there, e.g. IoTSF).

However, without enforcement and market regulation, nothing much will change.

IoT brands will still build product to a price, manufacturers will cut corners to deliver to a specification and price, consumers will buy on price.

And we wonder why there’s a problem with IoT security?