Predictions from Statista state that there could be as many as 30.73 billion IoT devices online by the year 2020, and the number will only increase from then onwards. Engineers must embrace at the design level the importance of security standards in IoT, particularly in view of the following major security breaches.
Among many other applications, IoT devices are making great strides in the spheres of entertainment, connected automotive, and precision guidance systems. The below covers three device types that fall into each of these respective areas and ultimately considers why such security breaches have proved an almost inevitable occurrence in recent years.
Consumer Entertainment: ‘CloudPets’ connected toys
Made by manufacturer Spiral Toys, CloudPets are children's soft toys that, via a Bluetooth-connected smartphone app, allow their young users to record and send voice messages between their friends and family.
Image courtesy of Spiral Toys, via BBC News.
But in what led to CloudPets’ widespread withdrawal from retailers (including Tesco and eBay), it transpired that the URIs of the voice data were being stored insecurely: namely on an unauthenticated database segment on MongoDB.
Such database insecurity enabled hackers to then access the files themselves on their final destination, AWS S3. This was achieved with further ease, as the CloudPets’ account registration stage involved no password rules, meaning that many users’ passwords were as guessable as ‘a’, ‘12345’ and ‘cloudpets’.
Ultimately, half a million users’ details were leaked and over 2 million of their recordings and other information were made accessible to malicious actors, some of whom even held the data to ransom. Spiral Toys’ eventual solutions were made a week after renowned security researcher Troy Hunt made his first of many urges for Spiral Toys to combat the breaches of sensitive consumer data.
Connected Automotive: The Jeep Cherokee
The vulnerabilities that come with vehicles’ increasing IoT connectivity have already been well publicized. The hacking of a Jeep Cherokee in 2015 showed just how breachable connected cars can be when ethical hackers Charlie Miller and Chris Vasalek exploited the internet connectivity made possible by the Cherokee’s head unit infotainment system, Uconnect.
Image courtesy of Wikimedia Commons.
Using only a laptop and a remote connection to the never-before-tampered Jeep, it was through weaknesses in the car’s IP configuration and CAN that the infotainment system proved a point of access to manipulate numerous ECUs. These included those responsible for the very powering of the car: the researchers were able to turn off the engine while willing journalist Andy Greenberg drove the test car on a freeway.
This controlled yet valid experiment supported Miller and Vasalek’s concerns of IoT vulnerabilities, particularly over transport safety. Said the former researcher: "Consumers ... should start complaining to carmakers. This might be the kind of software bug most likely to kill someone."
Smart Consumer Firearms: Wi-Fi-connected Sniper Rifle
Texas-based applied technology company TrackingPoint offer publicly-available precision guidance sniper rifles: Linux-powered devices whose connectivity applications include a simple domestic Wi-Fi connection.
Image courtesy of Pixabay.
As hacking researchers Runa Sandvik and Michael Auger demonstrated at 2015’s Black Hat conference, the weapon’s Wi-Fi functionality meant a point of access for hackers. This is primarily as the gun’s network connection had a default password: anyone within range and with the right know-how could then use the rifle essentially as a web server, leading to the weapon’s APIs being at the hackers’ disposal.
Through such access to the application programming interfaces, the device’s self-aiming calculations, namely the variables involved (such as wind and ammunition weight) could then be altered by the hackers. And while the operator will always have to be the one to pull the trigger, without their knowledge of the tampered calculations, dangerous firearm misuse could be mistaken for a safe shot. Sandvik and Auger’s research is another example, therefore, of how seemingly innocent IoT functions could bring dangers to both the users and those around them.
Weighing up the IoT Security Concerns
The above three entries demonstrate that what makes IoT devices vulnerable is far from a uniform pitfall in their design. In fact, the security weaknesses in the IoT span from the most basic of consumer-grade devices (children’s toys) to life-critical applications (driving and firearm use.)
Although the latter two examples introduce controlled research into IoT device weaknesses, such scenarios may soon prove increasingly less hypothetical given the exponential growth in store for the internet of things and, with it, the potential for cybercriminal activity.
So, the question again arises: ‘Why are we designing IoT devices without a solid plan to secure them?’
Image courtesy of Bigstock.
At their worst, IoT security breaches stem from human error itself. Consider Spiral Toys’ lack of preparation over data protection measures (which also applies to some of the consumers, given their choice of weak passwords) and, ultimately, the manufacturers’ delay in troubleshooting it, even when such design flaws were brought to the fore.
Other times, IoT breaches, of course, occur even in spite of good intentions at the design level; after all, even the strict compliance involved in the smart automotive and firearms industries could not change just how penetrable the connected Jeep Cherokee and Tracking Point’s smart rifle both proved to be.
Where IoT Security Proves More Complicated Still
All three of the above security oversights reflect an industry-wide design approach that is reactive rather than proactive. IoT devices are designed with future breaches being treated as an inevitability—a necessary evil that has to essentially be ‘taken as it comes’.
The reasons for this are primarily to do with manufacturing complexity and the resource concerns that come with it, especially the ‘build versus buy’ dilemma, but also simply a lack of concrete rules to uncloud such confusion.
Image courtesy of Bigstock.
The IoT has become increasingly multi-faceted in its growth: unlike traditional internet-based technology, the network connectivity of the former is far from direct and uniform and so a one-size-fits-all design solution is out of the question.
This, unless the manufacturer already has a fixed idea of how best to implement native IoT security measures, then calls for a solution in the form of third-party IoT security specialists (such as AWS IoT.)
In view of this, design engineers are therefore faced with a double-edged sword, the said ‘build versus buy’ dilemma. They can save time and money by ensuring security measures in-house but put their company’s reputation on the line in the (likely, or even inevitable) event of a breach, or, they can outsource their vulnerability protection demands, but know that their prospective IoT device could require up to 6 to 12 months longer to manufacture and, of course, cost a lot more money.
No Simple Solution
Whichever action is taken, there again remains no guarantee that the IoT device you’re designing could ever be fully impenetrable and, all the while, further questions of occupational liability persist, even after the ‘build or buy’ dilemma has been settled.
Consider the diffusion of responsibility that may arise from the UK government’s ‘Code of Practice for Consumer IoT Security’ (among other regulatory precautions). Given the complexity of the IoT, such a code of practice is understandably a self-proclaimed “outcome-focused, rather than prescriptive” set of guidelines; but perhaps the rate of IoT device growth and the unanswered questions over manufacturers’ duty of care calls for more categorical approaches to modern security demands.
Whether this will be achieved through revised legislation, or simply an improved dialogue between designers and end-users, it is clear that system security needs to grow at the same speed as the IoT itself.