Our website uses cookies

Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing Infosecurity Magazine, you agree to our use of cookies.

Okay, I understand Learn more

Super Systemic IoT Issues

Security issues are notoriously systemic in the Internet of Things. What do I mean by this? That a security flaw in one product will affect every device within that product line. So, the ability to compromise a thermostat will affect all those thermostats or a CCTV DVR all those CCTV DVRs until they are patched or, in most cases, superseded by the following generation.
 
It’s a problem that also affects high-end products such as connected cars. Take vehicle telematics platforms. We discovered two telematics service providers that didn’t implement platform segregation between vehicle brands, let alone client segregation between vehicles, making it possible to view commands for one brand of vehicle while connected to another from a completely different manufacturer.
 
Security awareness is on the increase in the IoT sector. Manufacturers can’t afford the bad publicity surrounding data loss or a vulnerability that could see an entire product line be rendered obsolete overnight. Recognizing that they need to implement better security, but that this is does not play to their strengths, they are increasingly turning to third party providers. These take care of the whole shebang from chip set specification to the mobile app, API, and testing the resilience of the device. 
 
Super size me
This is to be commended but outsourcing the problem doesn’t outsource the risk. Manufacturers are simply wiping their hands of the issue. By not understanding the machinations of security, they are exposing themselves to greater risk and that risk is now being amplified by a considerable magnitude due to ‘super systemic’ issues

Whereas before an issue with a device compromised the whole product line, now security flaws from these third party solutions providers are going across entire swathes of devices. It’s the IoT equivalent to a disease that can cross the species barrier. This not only vastly increases the number of vulnerable devices but can make it very complex to isolate these flaws by tracing them back to source.
 
Take the first iteration of Mirai: This infected over 600,000 devices, initially believed to include cameras, printers, routers and other peripherals making it hard to determine the source of the malware. It wasn’t until later that it became clear Mirai was using exploiting flaws in DVR firmware created by XiongMai, then rebranded to well over 60 different CCTV DVR brands.
 
Evidence of escalation
There’s now real evidence that we’re on the cusp of these super systemic flaws. We recently came across a third party provider who had authentication and authorization flaws affecting 300 devices from 100 manufacturers, showing the scale of the issue. Despite these manufacturers having their own APIs, the issue resided on the third party’s backend systems and so came to affect every IoT product it serviced.
 
It’s also extremely hard to discern whether a provider is likely to let you down in this way. Many seem above reproach. The same service providers website featured an email address for responsible disclosure, outlined a pen testing policy and lauded the merits of its in-house security team. Yet despite this, the provider had a huge authorization flaw affecting every single one of the products it interfaced with.
 
So how do you determine whether a provider is likely to land you with a systemic flaw? The solution lies in the manufacturer carrying out their own due diligence.
 
Vetting the vendors
Standards such as the Code of Practice for consumer IoT security issued by the Department for Digital, Culture, Media and Sport (DCMS) last year, and the ETSI specification TS 103 645 released in February, are directly applicable.

For instance, the latter refers to the need for IoT devices that cannot be updated to be “isolable” so that they can be removed from the network or isolated so that “any compromise affects only itself”. Both standards also cover the need to validate data input which can prevent systems being subverted by code being “transferred across different types of interfaces”, suggests the DCMS. Such guidelines provide manufacturers with a ready-made framework with which to assess whether third party providers have taken sufficient steps to guard against systemic issues.  
 
There are of course, excellent third party security providers out there. We’ve worked with several who have done some stellar work in ensuring robust configuration. We also have to recognize that these ‘one stop shops’ are providing an indispensable service to manufacturers who simply don’t have the depth of knowledge required.

The issue now becomes how we support this outsourcing relationship and promote security best practice. For this to happen we must apply and enforce the standards we have at hand.

What’s Hot on Infosecurity Magazine?