Editorial response to BBC Click article on IoT Device Security
Last week, we read in a BBC Click article how security researchers were able to access two different home EV chargers and take control of them. They were able to switch the devices on and off, remove access from the owners and they were also able to successfully demonstrate how these vulnerabilities could be used to access the home network, potentially eavesdropping, via the chargers.
Rpi Compute Module 3 unsuitable for EV charger use case
When both device manufacturers were contacted by the white hat penetration testers who conducted the penetration testing, the response was typically reactive seeing the device makers put in place a new server, app updates and firmware updates to the chargers. This is symptomatic of the general lack of strategic security thinking that goes into the manufacture of many embedded devices today. For example, one of the chargers had a Raspberry Compute Module 3 (CM 3) which lacked the necessary security features for such a use case.
Reactive infrastructure and firmware upgrades
Despite their proven security flaws, both these charging products had been approved for use by the UK Department of Transport which suggests there is still a gap between the emerging cybersecurity legislation and the practical effects of having these devices in the field. There are 1,000s of poorly protected devices out in the field in consumers’ homes and in fleet depots and other locations.
Need for zero trust architecture (people and devices)
The need to implement a zero trust architecture in IoT product design is urgent. From our perspective, it is a question of defence in depth and applying best practices on the human and non-human side. Selling EV charging products based on Raspberry Pi, which is a prototyping board, is unwise. Almost daily we read about error prone chargers, worst case going up in flames. It is truly wild-west, and like with all industries it goes from wild-west to regulation. We are in the midst of first generation regulation. Unfortunately, a long way remains due to many different reasons. Why regulate with cybersecurity legislation when we continue to allow insecure "smart" products to connect to critical infrastructure? The problem is now almost ubiquitous. The legislation needs to be turned into concrete action quickly. In Europe, ENISA - the EU Agency for Cybersecurity now has a permanent mandate with “more resources and new tasks.” There will be a certification framework to ensure that device makers who want to do business within the European Union will have to certify their products, processes and services. But again, how long will it take to turn mandates and certification into concrete action to solve a problem that is here now and not tomorrow? In the US, finances have been promised for cybersecurity protection of critical infrastructure such as electric grid in the US and the implications of the Cybersecurity Defense Act are percolating into agency policy such as the Zero Trust Architecture planning guidance from NIST in the US . These are grand scale initiatives and so are slow by nature. They take time to pass through the bureaucracy into the agency guidelines and eventually into customer and industry group requirements for the device makers and service providers to integrate into their products and services.
Triangle of Trust™ and IoT Device Security best practices
In the face of the immediate threats, we also advocate that device makers and their customers take practical steps now to secure their devices by investing in upfront planning and a system for delivering secure updates. We want to take this opportunity to again point device manufacturers and their customers who must utilise their products in the field to the Triangle of Trust™. This is a security framework for both the people who can access the devices and the devices themselves. Considering a framework such as the Triangle of Trust™ is an essential strategic input upfront at the start of IoT project planning.
We have also gathered and synthesised key advice on IoT device security and provided a checklist for the implementation of a robust and secure system for OTA software updates. This goes hand in hand with the need for a mechanism for keeping software in IoT devices in optimal state and patching known vulnerabilities systematically.
In conclusion, the planning frameworks and tools such as OTA software update managers are available to enable deep defence against cybersecurity threats. Device makers should in their own right take a proactive stance on implementing best of best breed cybersecurity protections in their products and services. The legislation is a great enabler but there is no need for device makers to wait until the legislation is enforced to do the right thing for their customers now. Procrastination will not provide the badly needed protection.