The Device Chronicle interviews Jeff Crume, IBM Distinguished Engineer, CTO of IBM Security Technical Sales - Americas, and Cybersecurity Architect. Jeff is a technical executive with a Ph.D. in Cybersecurity and a focus on security architecture for external clients. His videos on Youtube for IBM, including a series for IBM on Cybersecurity Architecture Principles , have garnered over 3 million views. He is also the Author of "Inside Internet Security: What Hackers Don't Want You to Know," published by Addison-Wesley.
Securing IoT-connected devices is a timely topic to discuss with an expert such as Jeff. In March 2024, the European Parliament passed the EU Cyber Resilience Act (EU CRA). This follows device cybersecurity directives EU Radio Equipment Directive (RED), the EU NIS2 Directive and NERC CIP. All these directives are looking for OEM device makers to provide automated managed software updates to their customers and end users. The FCC also came to the table with a Cybersecurity Labeling Program for Smart Devices. The device OEM industry is also starting to self-regulate: The Connectivity Standards Alliance Product Security Working Group came with its IoT device security specification 1.0 in March 2024.
European Union Agency for Cybersecurity (ENISA), ETSI EN303645, NIST, ISA IEC 62443, and ISO 27001 standards and processes underpin all these directives. So what does an OEM device maker need to understand and do to ensure compliance with these new directives and standards so they can continue to trade in the two major global markets of the United States and the European Union?
Chapter 1 - Biggest threats to IoT-connected devices
Jeff begins by explaining that with IoT connectivity, we're turning everything into a computer. "My car is a computer that takes me places. My vacuum cleaner in my home is a computer that cleans up. My refrigerator is a computer that keeps my food cold. My DVR is a computer that shows me movies. So if everything becomes a computer, that's interesting. As a technologist, I'm encouraged by that. As a cybersecurity guy, when I look at it through that lens, I start to break out in hives because I know a hacker can break into every system. So if everything becomes a computer and every computer can be compromised, we're moving to a world with much higher risk. And stop and think about what the ramifications of that happening are."
Many of these will be network-based attacks because of all these devices getting networked. A lot of them need to be, a lot of them don't need to be, and some need to be, but they need to be protected in their particular network and may or may not need widespread internet access. There is also a big problem with patching and the growth in malware. Jeff adds “So, if it's a computer, guess what? It will suffer from all the same issues that every other computer and every other IT system we've ever seen has had. We're doing it on different platforms, which will be in more precarious places now. Yes, indeed, hard to reach and highly heterogeneous. And maybe the embedded space is relatively new for many organizations to get their heads around.”
Jeff then explores the optimal security-by-design strategy for an OEM device maker to follow for their connected products. He starts by saying that is not one thing, but there are a lot of really well-heeled best practices to be followed. In other words, IoT connectivity introduces some new things, but we still have to do everything we've always done in security, just a little bit more. And in a slightly more challenging space. This starts with the principle of least privilege. That is only giving access to what is necessary. It is defaulting to a fail-safe condition. It is only keeping features that are essential. There is also the notion of hardening of a system. Only turn everything on if you need all of those features. But often, device manufacturers turn everything on to impress because they want their product to look outstanding and shine in front of a client. But every one of those activated features is a potential attack factor. Jeff advises to be very selective about the features you need because each represents a particular risk. And be smart about whether those risks are worth the reward you will get back for them. “We should apply some zero trust principles here, the notion of identifying every place we have implicit trust, things we trusted without verifying. We should question those assertions and those assumptions. And assume that the bad guy has already breached specific components. Assume the bad guy's already on the network.” With this assumption made, Jeff reassures that you can design your device to operate in a hostile environment. Jeff Crume answers some critical questions and provides some key insights.
Chapter 2 - Best resources for devising a security-by-design approach for IOT-connected products
Jeff insists that standards are essential. The challenge with embedded product security is that many people say they would like to let the market dictate security decisions. However, sometimes the market pressures differ from what is required in terms of security. And IOT, especially consumer-grade IOT, is one of those places where OEM device makers don't necessarily have a strong financial incentive to put more security in because it costs more. “The effect then is that the consumer then will down-select that device. They're not going to pay more. They don't understand the value because they don't understand the threat. But the big message is that some of those resources we have traditionally used to secure by design and shift left.”
Jeff advises device makers that it is best to address security by design early on in the product development process; as something in the field costs more to fix and has a more harmful impact. “A defect that we detect at the test phase is cheaper. One that we still detect at the coding phase is more affordable, and one we detect at the design phase is a fraction of the cost of these others. So, to the extent that we can design in security and push that shifting left in the development process, those are the kinds of things. So look for the resources, secure coding and design practices, and let those guide you.”
Chapter 3 - Impact of EU CRA and the FCC cybersecurity labeling program on device security
Jeff believes that the approach to EU CRA and the FCC cybersecurity labeling program compliance will have a different answer, depending on whether the IoT-connected device is consumer- or industrial grade. “We're much more trained in the industrial grade sector to look for specific certifications and verifications. So it could carry more weight in that space. In the consumer area, education is even more critical. We need to educate the industry so that they look for the stamp of approval on these things.”
Jeff adds that in the consumer space right now, most end users wouldn't know what to look for in terms of security protection if they were buying a device. “There's no way a consumer can look at two security cameras for their home and decide which one is more secure. So they're just going to look at features and price. Once we get these standards in place and get enough people following them, we'll need to start marketing and educating them so that the consumers know to look for them.”
Jeff finds an analogy in bicycle riding: “There were international safety standards for helmets and you had to educate the consumer, so look for this stamp, and if you don't see it, it doesn't matter what the price is, don't buy that helmet. The product has not been certified; it won't protect you.” Jeff believes that similarly, we have to educate consumers that these are the indicators that security is in there. It doesn't mean it's perfect, but it means demonstrating product security much more than the other things. This will start assimilating into the marketing and branding of OEM device makers. “So they'll have to have the CE mark, of course, but then you might see things like the smart home secure connectivity standard Matter, for example, appearing on the product branding to show that the products are secure and compatible with such initiatives. Compatibility is what those things have communicated to people in the past, but we need them to carry the weight of security. Not only is it compatible, but it'll also work with your other stuff and be more secure. Again, we understand that there's no such thing as absolute security. We don't want to oversell the idea that every computer can be compromised. But if I have a choice between two devices, one with an industry-standard security stamp of approval and the other without, I know which one I'm buying.”
Chapter 4 - Software update ability & vulnerability management in EU CRA
Automated and managed software updates for IoT-connected products are essential. Jeff says that we cannot expect, especially when you talk about large distributions of devices, to put that burden on the user to go off and do these software updates.
Patching is critical; it's so vital that it has to happen automatically. If it doesn't happen automatically, the end user should assume it's not happening. And the devices need to be able to do that, and it just needs to happen in the background. “When we first came out with home internet, those routers and access points and things like that, for the most part, didn't update automatically. Now they do. We've done an excellent service to our user community by being able to build that in because expecting the end user to remember once a month to check for the patch level is not realistic, and it's not reasonable.” We also need to ensure that the patch is coming from a trusted source. “Someone can't compromise that update path. And we need to have the techniques to do this. They've existed for decades using things like public critical infrastructure and digitally signing the code, and then it's a matter of protecting the private keys and things of that sort. So, we have all these techniques in place. We need to leverage the best practices to ensure it happens.”
Get in touch with Jeff on LinkedIn or email him on: crume@us.ibm.com
Visit IBM on Cybersecurity Architecture Principles on YouTube
Visit ibm.com/security.