IoT testing can be a complex process and as a result many vendors aren’t yet onboard with it. Concerns over their intellectual property, the level of commitment required and how to interpret and act upon the results deter many from embarking upon breakpoint testing.
But, as Andrew Tierney, consultant at Pen Test Partners says, in the long run, the process is beneficial, providing the vendor with the opportunity to correct issues that could compromise the brand.
Nearly all of the published research on IoT vulnerabilities focuses on the device and training on attacking the device. But when it comes down to it, a real-world IoT system is far more complex. There’s the devices, the operating system and software that runs on those, the mobile application, the servers and the build on the server, to name but a few. Compounding this, the devices can be placed in physically exposed locations and on potentially hostile networks that you have no control over. They are installed by people with no networking knowledge. And the painful fact is that you have placed your system directly in the hands of the attacker. This is very, very different to normal infrastructure IT.
There are three methodologies that can be used to test IoT systems, each with their own advantages. Black box testing sees the testers approach the system as real-world attackers. The only knowledge they have is what is publicly available. Often, the testing will focus on recovering firmware or rooting the device to obtain information about how the system operates, including APIs. This can be crucial in finding serious systemic issues. It tends to be time-boxed rather than task-driven and the testing will flow in an organic manner, following paths most likely to yield vulnerabilities.
Alternatively, white box testing sees the testers given access to design documentation, specifications, data sheets, schematics, architectural diagrams, firmware, and even potentially source code. Using this knowledge, they attack the system. Unlike black testing, it can be task driven, as the open access to documentation allows the tester to develop a plan before testing starts.
Between the two is grey-box testing. Some information is provided and this avoids unnecessary time being wasted on reverse engineering. A typical scenario might involve a period of black box testing which, if it fails to yield access to the device/firmware, leads to “break glass access” at which point grey-box testing continues. Grey testing often offers some of the best results, providing confidence that the device will withstand attack from real-world attackers using defence-in-depth.
Concerns over testing expressed by vendors include whether the test will lead to a compromise so extreme that their product is pushed back to the drawing board. In reality, tests tend to discover vulnerabilities that can be fixed that then prevent mass compromise, stopping the kind of take-down achieved by proof-of-concept hacks like the Miller and Valasek Jeep attack.
Will testing find all the issues? That’s unlikely but white box testing will nearly always find more issues than black box testing. Should you fix even low […]
The post Put to the test: Why vendors shouldn’t shy away from attack testing appeared first on IoT Now – How to run an IoT enabled business.