IoT Business News: We know that IoT device security is an ongoing challenge. How does Ripple20 complicate matters?
Brad Ree (ioXt Alliance): Ripple20 is another reminder that companies need to take security seriously and need to manage their supply chains.
A core problem with these vulnerabilities is that it may take some time for manufacturers to identify if they are impacted as the core problem started in a software library, which was put into modules, and then finally into end products.
This problem has existed for over 20 years, and many of the companies that have shipped vulnerable products may not even have a relationship with the customers. Further, tools and code libraries from 20 years ago will be a challenge to create patches. Most important, many companies have not implemented any means to isolate devices that are no longer being supported.
IoT Business News: Why have the Ripple20 vulnerabilities gone undetected for so long?
Brad Ree: The core issue was a lack of error checking on packets received from a network in a very specific manner, which resulted in the potential for code to be injected into the device.
Most quality assurance teams look at testing for the positive things, such as when I send “turn on the light”, the light turns on. Instead of sending “turn on the light” to a device that does have a light.
Further, 20 years ago, code size and speed were the primary concerns for developers of early IoT devices. Thus, error checking and security often got pushed to the back burner. With today’s hardware, these constraints have been removed, and now we simply need to change the development culture to include security during the development process.
The other danger of this type of defect is that it may have taken a long time to detect, but it is very easy to build code to exploit the problem. Sharing a good hack spreads faster than applying patches to 20-year-old equipment.
IoT Business News: What should the device manufacturers do to protect equipment if they can’t easily or immediately patch?
Brad Ree: The ioXt Alliance advocates that device manufacturers must secure their products and provide a means for software updates in the field. Further, we require manufacturers to state how long they will support the security of the device, or at least provide end of life notices.
For users of legacy products, we would recommend that the devices are isolated on the network. A simple segmentation of IoT devices from other operating systems and computers can be done easily in a company’s switches and routers. Also, many IoT devices were deployed in an isolated network, which does not connect to other equipment or the internet. We recommend that companies periodically verify that these networks have remained isolated. A lot of tribal knowledge about the network can be lost over 20 years.
IoT Business News: What about retailers that are selling a variety of different devices that could be impacted? What are they liable for?
Brad Ree: Retailer liability is a concern if they continue to knowingly sell impacted products. The concerns would be two-fold: FTC action and class-action lawsuits. FTC action will require a significantly higher bar of negligence than a class-action lawsuit, in which the opposing attorney can pull in all parties involved.
The ioXt Alliance advocates the adoption of a security stamp, in which consumers can clearly see if the products they purchase are known to be secure, and which products are undeclared. Providing consumers with the information they need to make purchasing decisions is not only important for the consumer but goes a long way in protecting retailers.
IoT Business News: This is the latest of many issues – both widespread and isolated – that we’ve seen with IoT devices. Why is IoT device security so difficult to solve?
Brad Ree: IoT devices are often highly constrained devices and thus require programmers who have typically spent their careers learning to build a closed embedded system. The addition of internet connection is often bolted onto existing systems or devices. In fact, Digi (one of the impacted devices) is a module that provides internet connectivity for device manufacturers who don’t have communication engineers.
Another major issue is a misalignment of incentives for device manufacturers. Often, they are not the service provider, and thus do not have a reoccurring relationship (or revenue) with the end customer. Thus, the companies creating these issues often launch products, and then move their development teams to the next new device. Staffing a support team represents an ongoing cost, which is hard to justify for a manufacturer operating on skinny margins who only receives a one-time payment at the time of sale.
IoT Business News: How do vulnerabilities like Ripple20 or other flaws play into data security and privacy regulations? Could there be regulatory repercussions for something like this?
Brad Ree: There are strong movements toward regulations in many parts of the world. Recently, both NIST and ETSI released potential regulatory frameworks. They have made great steps forward, but differ in fundamental ways, which will be difficult for global IoT systems.
We believe an industry-led method, with clear consumer labeling, is a large step in the right direction. We also see regulations are going to happen at some point, but we want to make sure that they are reasonable, testable, and impactful for the consumer.
IoT Business News: Are you taking newly-discovered vulnerabilities into account in your standards work at the ioXt Alliance? What changes might you think about making in the future to strengthen device security?
Brad Ree: Most newly discovered vulnerabilities can be traced back to the same set of root causes. This vulnerability was a lack of bounds checking which allowed for remote code execution. Our compliance program already addresses this type of issue. However, as part of the compliance program, we request that manufacturers register their software bill of material and list any security (or communications) libraries contained in the product. Our back end systems provide integrations to network and ecosystem operators, such that they will receive security alerts when security issues arise in devices running on their networks. Further, our compliance program is based on a subscription method in which we provide updates of any vulnerabilities which are discovered in any registered library.
