IoT devices repeatedly exhibit security flaws, damaging consumer confidence and endangering adoption of smart technology. Security is the number one concern according to a recent survey by Gemalto which found 90% of consumers and 96% of organisations were concerned and saw a need for regulation and government involvement. Ken Munro, Partner, Pen Test Partners.
The UK Government has since issued its Secure Design Framework, feedback on which is now being collated, but the draft omits some key technical areas, such as mobile app security and generating sufficient entropy for device passwords. It also doesn’t acknowledge flaws inherent in the IoT business model which will continue to see systemic security failures.
The way IoT products are designed and brought to market means security can become marginalised. IoT brands build product to a price, manufacturers deliver to a specification and price, and have to adjust their plans to do so, and consumers buy on price. Consequently security is often demoted during the process.
Having spoken with IoT vendors, hardware manufacturers, IoT integrators and platform suppliers over the last four years, Pen Test identified seven key issues with the IoT business model that need to be remedied in order to bolster security:
1. Security is not on the radar: assumptions are made that security will be tackled further down the line i.e. by another party or in the supply chain. This is often due to the fact that many IoT devices start life as non-smart products which have IoT functionality added.
- Solution: To understand IoT security, one needs to have an understanding of hardware, firmware, RF, API, mobile app and web app security as a minimum and so personnel with these skillsets must be involved in the IoT design.
2. Production takes priority: The most common problem is that the security issue noted during production simply got forgotten about in the rush to release the product. 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 nine months ahead in the Far East. Mobile app developers create an amazing app and social media is galvanised to create awareness. The PR machine goes into 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.
- Solution: Security processes have to be in place that see issues not just flagged but recorded. Ideally we need regulation that obligates the manufacturer to remedy flaws before and after the product comes to market.
3. Post-production fixes: In software products, security is often overlaid later (never a great idea) but where there is product involved, not just code, this becomes problematic. In software or a mobile app one can quickly push out an update but that doesn’t work so well over the IoT. 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. Numerous IoT products have been bricked simply trying to update them in line with manufacturer instructions. Sometimes the update process itself isn’t fit for purpose and the hardware isn’t even capable of receiving an update, or has significant functionality problems, leaving no option but for a product recall.
- Solution: Test the firmware update process and make sure it is user friendly.
4. Insufficient funds: Unforeseen circumstances can impinge cashflow. Perhaps prototyping didn’t go to plan meaning a major selling opportunity like Black Friday is missed. This is when corners are cut, app development gets offshored, and there’s no money left to spend on security or security validation.
The business plan called for a comprehensive security review before launch at the insistence of the backers but instead the product is supported by a bug bounty scheme. Even if bugs are reported to the vendor, only those found are fixed, with no further proactive security work undertaken.
On one occasion when an issue had been disclosed, further investigation by a consumer publication found more security holes leading to the product being delisted by several large retailers, putting the start-up IoT vendor out of business.
- Solution: Ringfence funds for security testing. Never substitute testing with a bug bounty program as there is no guarantee your product will be probed by white hats, particularly if the bug bounty is too small or the brand name is not well-known. That said, the security community is all too happy to help, making bug bounty programs a useful add-on.
5. Recall or reassure: If the security flaws are so bad that they can’t be fixed with an OTA update, a recall is the only option. This presents the vendor with a quandary: recall the product and go bust or don’t and receive bad PR that could damage the business irreparably. This is why vendors continue to ship insecure product even when they know it is vulnerable. Sometimes it’s the only option. A good example was the WiFi kettle from Smarter, which suffered a PSK theft issue and then launched the iKettle 2.0 with improved security. Had they recalled the 1.0 version, they probably wouldn’t be here today. It’s a difficult position to be in, and one can see why vendors are reluctant to do a recall.
- Solution: A Crisis Response Plan can provide the vendor with the process to handle disclosure swiftly, mitigating any fallout. Be prepared also to work with the security community and to be honest with your customers. Being proactive in alerting the customer base can win back confidence.
6. Lack of standards and guidance: Most vendors find themselves all at sea when it comes to adding IoT functionality so they will often go to a startup agency who claims to be able to do it all for them. In fact, they’d often be better off working with IoT platform providers such as the Electric Imp platform which offers ease of implementation, light touch configuration and good security, although there are plenty of good providers out there.
- Solution: The IoT community needs more information and guidance on where it can look to for support and the different platform partners available. Until such information becomes more readily available IoT vendors will continue to go it alone.
7. Quick buck vendors: Some vendors just don’t care about security and 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 mobile app that hardly works. Once banned, these are removed from the shops, but there’s always another vendor waiting to take their place.
- Solution: Without regulation enforcing IoT standards and giving them some teeth we will continue to see ‘fly by night’ IoT vendors peddling items that aren’t fit for purpose, robbing consumers, and legitimate vendors of a sale, and damaging the credibility of the technology. This is why the DCMS Secure Design guidance won’t change anything.
It’s only by understanding these causes that we can put in place the channels and resources vendors need to prevent insecure IoT products coming on to the market. It won’t be easy and will require guidance and standards such as those developed by the IoT Security Foundation together with market regulation and enforcement. But it’s clear that the current IoT business model needs to change if the IoT is to overcome these teething difficulties and fulfil its potential.
