FE: How seriously do you think makers of IoT devices take security today? Is it perceived as a cost versus a benefit?
HAYDN POVEY: Most IoT device manufacturers do take security seriously. However, the reality is that it is not the highest priority versus getting a product to market and meeting tight timelines. This is changing, especially with the advent of legislative frameworks for consumer IoT. Alongside this there is a growing realization that security creates a high value point rather than just being a cost to the organization. For example, security is critical to enabling devices to work together in trusted networks, to share personal data within your network, and to enable private operation with cloud services.
Similarly, the management of updates and procurement of additional services can only be done with a secure foundation. It is the move to these ongoing lifecycle management value points that will enable the value of security to come to the fore. In addition, IoT device vendors understand that the value of their IP is the value of their company. The possibility of IP theft is very real, and the European Union estimates that this may be as high as $60 billion per year, according to their latest research. This also has a potential impact of nearly 300,000 jobs just in that region. By doing security right we not only secure the application and the data, but we also secure the intellectual property and the supply chain.
FE: And speaking of cost, what kind of cost does building in security add to an IoT device?
HP: Security doesn't have to cost a lot. It is certainly possible to lockdown an existing mainstream device to ensure that intellectual property can't be sucked out, and to ensure that rogue code cannot be injected. The baseline cost therefore is very low and may actually have zero cost on the product being created. Of course, there is additional effort in developing and testing a device to ensure it's secure and in the production of the device to ensure that IP cannot leak. However, it is our strong belief that the total cost of security should be less than 1% of the cost of the end device.
There are more secure chips coming to the marketplace and we would absolutely encourage any developer to rigorously look at these platforms. For example, the secure firmware install (SFI) technology in the latest ST devices is a great step forward for secure manufacturing. Similarly, the implementation of secure enclaves such as the Renesas TSIP (Trusted Secure IP) secures information far better. Additionally, new security technologies integrated into mainstream devices, such as the physically unclonable functions (PUF) in the NXP LPC55S family also add significant protection and are definitely worth reviewing.
From a development perspective security can have a major impact but with better “security out of the box,” such as Embedded Trust and IAR Systems C-Trust, the majority of the heavy lifting is already done. This means that developers can focus on their applications rather than on the intricate details of security, which is just as well given there are over 3.5 million cybersecurity roles open globally. To achieve this, we need to bring security to the start of the development process with the concept of a secure context, or profile, which defines how security is implemented across an organization’s products. This approach makes security painless and fast, which helps to minimize the costs.
FE: Does the European standard EN303645 have real teeth?
HP: Great question! The reality is that EN303645 is now a clear requirement for any consumer electronics shipped into Europe. However, IoT devices are still subject to the privacy legislation outlined in the GDPR regulations, and if we look at the legislation, we see consumer protection is still at the center of these. For example, there is a clear requirement to hold all personal user data securely and to enable this to be erased at end of life, or when a device is sold on. Similarly, any data supplied as part of a service, for example even managing voice control of a coffee machine, is very much within the auspices of the legislation. GDPR has clear penalties for breaches, with a minimum fine of €10 million, which can escalate to 4% of company global revenue, if the company has been shown to be purposefully delinquent.
The goal here is to demonstrate that clear attention has been given to the security requirements, and this can be done either with formal certification, or through a self-certification process, such as the IoT Security Foundation’s Conformance Framework. For IoT, given the breadth of innovation, this makes sense as an easy first step for every organization. Secure Thingz has recently announced our Compliance Suite which aligns the development tools and security profiles alongside the compliance framework, demonstrating the ability for companies to align to the standards in a matter of hours.
FE: How do you think the new California and Oregon laws that hold device makers responsible for the inclusion of reasonable security features are impacting or will impact design practices?
HP: Given the size of the Californian and Oregon economies there is a clear hope that organizations will evolve to service the higher standard, rather than differentiating the marketplace inside the US. The challenge for most developers is understanding what is meant by “reasonable” security features, as opposed to “unreasonable.” There is a clear need to be specific about what reasonable means – and personally I treat this needing to at least show an analysis of what the risk profile and attack surfaces of the device are. If the attacker can only compromise the specific device they have physical access to, that is probably OK in most IoT applications. It is the ability to carry out class breaks, or compromises of all attached devices that carry the highest risk. Ultimately this is largely a financial equation: if there is lots of money to be made, by harvesting information or ransomware, then bad actors will always find a way. If it is expensive to compromise one or two devices, then it is far less likely, but not impossible.
FE: Why is the U.S. taking so long on their federal guidance?
HP: The U.S. took a long time to achieve its federal guidance, but the IoT Cyber Security Improvement Act was finally signed into law in December 2020. This was a rare example of bi-partisan legislation, but it did nearly die many times along the way. The challenge, much as we have seen in Europe, California and Oregon is defining what is a “must have” for security, versus the “nice to haves,” especially in the highly litigious U.S. frameworks.
The frameworks evolved in the UK and Europe have provided a good framework of “good, better, best” which fits well into the IoT Cybersecurity Improvement Act, and the work that NIST is doing to implement this as actual technical policy. In the EN 303645 standard there are three or four core requirements which are the “must haves,” and the remainder represent best practice that organizations should be aware of and aim for. The four core requirements are simple to present but still complex in the implementation. They are:
- The need to implement cryptograph authentication to avoid fixed passwords and enable the migration to more robust identity – a bedrock of trust across IoT devices
- The requirement to disclose vulnerabilities to customers, with clear communication of the support, update and patching agreement
- The obvious need to release updates which must be delivered securely and be sufficiently simple for a consumer to install
- The requirement to ensure provisioned credentials and private data are robustly protected within the device – ensuring privacy for the user and protection against class attacks
FE: When do you think legislation will really start biting into the consumer electronics domain and is that what it will take to achieve wide-scale development of secure IoT products?
HP: Legislation and standards are already starting to impact the marketplace, but there is a significant lack of knowledge, and experience, which is acting to slow this down. Organizations who understand that security is a critical differentiation are now moving quickly, given there is a clear set of standards. For example, the largest shipper of connected lights, or lumens-as-a-service, has adopted a security-first methodology, and they are shipping in the hundreds of millions of devices every year. Of course, there will be laggards, but the market will act over the next two years to resolve this, primarily through consumer orientated stickers, or markings, and the implementation of a level playing field in Europe, the U.S. and large parts of Asia Pacific. In the discussions with major retails we have had, both directly and via the IoT Security Foundation, it is clear that most retailers want to do the right thing but have been waiting on the legislation now rolling out.
FE: Who is responsible for security – is it just for engineers? What is the role of management and leadership?
HP: Security must come from the top of the organization, with leadership playing a major role, and COOs & CISOs being responsible for both inbound IT threats and the security of their own products. These stakeholders are critical in defining the organization’s security profile, and ensuring common standards for product update support, patching and customer management. The engineers can implement the technology, but creating corporate policy is not really in their job descriptions. This is why we have worked with many organizations to create standard, but flexible, security contexts. This enables organizations to quickly adopt a standard model for identity, authentication, updates and management of devices, either via a cloud provider or direct, and subsequently tune it to their specific needs. This process used to take months to resolve, but can now be completed in less than a day, providing a clean framework for the engineers to build upon within the standard development tools they know and trust.
Of course, not every organization has a gold standard functioning CISO, and here the policy is often unfairly delegated to the engineers. Again, they can do it, most embedded engineers are extremely capable, but being able to adopt standard policies that already meet many of the requirements for EN 303645 makes life significantly easier.
FE: Around what topics do you think engineers need better information today?
--Best Practices for designing a secure IoT product
--Interpretation of standards
--Basic information on standards
--All of the above
--None of these – but something else?
HP: The simple answer is definitely “All of the above.” Security does impact every aspect of how a device functions over its lifetime and understanding the context for the standards is important. However, even the most talented engineers are only human, and have to focus on getting their product completed and into manufacturing, so while a clear understanding and interpretation of the standard is important, this--for most organizations--has to be so they can use the right tools to achieve their goals. Getting educated quickly is important, and new resources, such as the training we carry out with IAR Systems via their online academy, really do help close the knowledge gap.
Ultimately the goal is to ensure the product is compliant, demonstrating that common attack vectors have been though about and closed off, and that the four core requirements have been met. If the industry can get to this point it will be a great start!
FE: Where does an engineer even get started with designing a secure IoT device?
HP: As always knowledge is key. I would recommend reading the IoT Security Foundation guidelines or attending online training on the guidelines and compliance frameworks, which are free to access. Furthermore, the EN303645 standard is freely available online, and whilst a little dry, does identify the 13 best practices with individual requirements. Once educated, the next goal is to understand the need to protect key assets from the potential bad actors across the globe. Whilst consumer electronics is less likely to be subject to the pervasive state-sponsored attack, it is likely that smart homes could be held to ransom – especially on very cold days when heating is a necessity.
The next step, of course, is to look at implementation and there are two or three major stakeholders here – the silicon platform, the tools, and potentially the cloud. The silicon platform is simple – does the chip have the security features you need? If this is a simple application, then existing mainstream devices can be made somewhat secure though disabling the debug ports and installing secure boot frameworks. More advanced devices offer advance cryptography, secure enclaves, and integrated TPMs. The tools are critically important in supporting implementation, and here new tools such as Embedded Trust and C-Trust make a significant impact, reducing the overhead of implementing security from months to hours. Finally, there may be a desire to connect to the cloud, and of course credentials need to be provisioned, either in manufacturing, or once connected.
FE: Are there one or two things that an engineer could do that would make the biggest difference in device security such as attack surface reduction, hardware resource partitioning or other?
HP: The biggest single thing an engineer can do is to presume every device is, or will be, compromised. This slightly negative perspective is critical in starting the journey to a more secure IoT, as it then drives the implementation of a Root of Trust with properly encrypted and signed updates. If we presume we will be compromised we can ensure we design a safe-space to recover into, to regain control of the device, and remediate with patches and updates. We can achieve this on the majority of microcontrollers on the market already, so the cost is minimal, but the benefits are huge. Again modern tools will now implement these frameworks for you, with simple configuration and unlimited flexibility, so security is easily within every engineer’s reach.
Haydn Povey is CEO of Secure Thingz and holds an MSc in electrical engineering from the University of Kent. He serves on the board of the IoT Security Foundation. He has held positions at global technology companies for more than 20 years, including more than a decade at Arm where he led the company’s security strategy in mobile and IoT. He also helped lead development and introduction of the Cortex-M processor family, now dominating embedded systems and IoT markets.