Page 26

EETE DEC 2014

TEST & MEASUREMENT Adapting test strategies to IoT By Mike Bartley and Declan O’Riordan The internet of things (IoT) brings with it the ability to build more flexible and responsive control systems in which devices from many different vendors are brought together to deliver more functionality than is possible with traditional, standalone embedded systems. But this shift raises a number of issues for effective validation and verification. A key difference between devices designed for the IoT and classic embedded systems lies in the explosion of their possible use-cases. Traditionally, embedded systems were often designed to run in a standalone context or if they were networked would run in a small set of predefined contexts. Such designs could be supported by a relatively straightforward strategy of testing at the unit level, followed by testing the integration of those units and finally testing at the subsystem and system levels. The IoT redefines the concept of ‘system’. It brings with it the possibility of building much TVS’ asureSIGN dashboard. larger-scale, emergent systems in which interactions between independently designed devices on the network deliver the system functions. Incorrect functionality within one device can result in unpredictable behaviour at the system level, or may have little to no impact because other devices in the system can respond appropriately. A number of IoT applications rely on the concept of sensor fusion in which readings from many different sources are combined to build what should be a more accurate picture of what is happening around them. Errant devices may inject noise or incorrect data into the network that causes other devices to respond inappropriately, resulting in the wrong outputs being generated. Because IoT devices will be designed independently it is almost impossible for the device design team to test for specific problems caused by other systems. Even if some of those systems are available for test before product delivery, a fundamental tenet of the IoT is that new applications will be developed over time that may stress the device in unforeseen ways. The problems of testing for the IoT raise issues of responsibility. Who is at fault if a single device starts emitting erroneous data that causes a gateway device to report non-existent events that destabilise the control loops used by other components of the system, causing a failure that leads to an accident? Is it the vendor of the faulty device, is it the developer of the gateway for failing to filter the bad data or the controllers for being unable to cope with extraneous events? A large number of IoT systems will also need to be able to cope with user-written software. Those used in home automation, for example, may be controlled by a combination of downloadable apps and user-written or customised scripts. Errors in these may, if not guarded against, could cause IoT nodes to behave unpredictably. Developers of IoT devices not only need to consider the stability of their design when used in a networked context but their vulnerability. When things become financially important, they will become enticing targets to hackers. Even those without a direct financial benefit for successful attackers, some devices may provide an avenue for hackers to gain personal data that can be used for phishing attempts or simply be attractive targets for digital vandalism. In the wake of security disclosures about an internetenabled thermostat, showing how it was possible to load a web page showing the password it required, some users reported their devices misbehaving. In one case, a home user woke up in the early morning to find theirs had been set to 35°C. In the world of personal computers and servers, the idea of regularly patching the software to counter types of attacks as they become known has become entrenched. But devices that do not have any form of high-bandwidth connection to the internet or which cannot suffer the downtime associated with a firmware update and reboot cannot realistically be treated the same way. An IoT device may have no high-bandwidth connection to load new software other than a custom connector inside the package that was used during factory configuration, and after commissioning in the field may be installed out of easy reach. Because many of the devices will often be practically inaccessible, the “patch and pray” strategy used for many desktop software packages is unlikely to be an effective strategy for many forms of IoT device. They will need to be shown to be secure against a wide range of attacks. Patching can only be used for extreme situations where certain types of hack were unforeseeable at the time of design. Because of the factors outlined above, there is a strong requirement for the firmware inside IoT devices to demonstrate trustworthiness. This has led, in the UK, to the release of a standard designed to improve the ability of software to avoid failures and resist attacks. The Trustworthy Software Initiative has backed the British Standards Institute’s PAS 754:2014 standard, Mike Bartley is Founder and CEO of Test and Verification Solutions Ltd (TVS) - www.testandverification.com Declan O’Riordan is Head of Security Testing at TVS. 26 Electronic Engineering Times Europe December 2014 www.electronics-eetimes.com


EETE DEC 2014
To see the actual publication please follow the link above