In part 1 of this interview with Jason Soroko, CTO of IoT for Sectigo, and Alan Grau, former president and owner of Icon Labs and now VP of IoT/Embedded solutions at Sectigo, we learned how the acquisition of Icon Labs by Sectigo was a strategic move to being able to offer end-to-end and purpose-built IoT issuance from a trusted third-party Certificate Authority (CA), what a CA brings to IoT security challenges, and what to expect going forward with enterprise security, in particular. In part 2, we learn a bit more about security platforms, purpose-built IoT issuance, and their take on the unique security challenges facing the industrial IoT market, as well as other verticals.
The term heavily-bantered-around term “IoT security platforms,” seems very murky for a lot of people. They are being told they need it but aren’t quite sure what that means. How would you define it?
Alan: As Jason said, there are many different needs out there and many different solutions, and vendors tend to take whatever it is they’re offering and call it their IoT security platform. It is important to understand what’s underneath that.
From my point of view, an IoT security platform needs to incorporate a few key elements to order to be seen as a comprehensive security platform. It needs to provide the capabilities necessary to harden a device, to add in secure boot, secure updates, integration with secure elements, and do secure storage on the device. It also needs to be able to provide manageability — to manage the certificates on a device for the lifecycle of the device, to revoke and renew those certificate, and so on.
One of the unique things that Icon Labs and Sectigo provide as a whole is that we do have Sectigo as a public CA company that’s got a deep PKI infrastructure capability. We can not only provide issuance with a cloud based or on-premise CA but also the tools to utilize those certificates in a hardened device.
You mention “purpose-built IoT issuance” in your acquisition announcement. Can you put that in layman’s terms?
Jason: The background behind that is this: some people are very familiar with PKI from 15, 10, or even five years ago. PKI traditionally has been implemented for human use cases — authentication, finance systems, citizen ID, passports, you name it. For all those things people take for granted daily, there’s typically a PKI, behind it. That’s why these systems work, and that’s why it’s secure.
The problem with those use cases is that they were typically very large, complex, risky, and expensive implementations. Anybody who’s ever worked on a PKI before may get frightened by them because of the perceived expense and risk surrounding the term PKI. It’s an incredibly powerful technology, but, historically, it was quite complex. What we’ve done with our PKI offering is to make it purpose-built for IoT vendors. In other words, purpose-built IoT issuance means complexity and cost have been removed so that you can get on with the business of putting your device on the market securely, as quickly and as safely as possible.
Five, six, seven years ago, when vendors were getting on this security bandwagon, I feel like they were kludging things together. They spun the story that they’ve got all of this excellent security, but I sensed that it wasn’t specifically for IoT. However, if you throw IoT and security into the same sentence, well, it’s an SEO king. But that doesn’t help someone who’s designing a device and who has no clue. They know that they need security and are looking to have this one-stop shop. That brings me to the conversations around ecosystems. How do you define a wide-reaching platform ecosystem, and what value does it have to the customer?
Alan: Let me say what a wide-reaching platform ecosystem isn’t. Let’s take an example of a vendor who has an excellent secure boot. Their engineer wrote some code-signing code, implemented it on their device, and started shipping devices, and said, “Wow, it’s a great, secure device, because we have secure boot, and it’s code-signed.” Then they stored all their tools on a public repository, like most people do, that later gets hacked, and in there, they had their private code- signing key hardcoded into their code-signing tool. A hacker could say, “Huh, if I take that key, I can go write code, sign it with their key, I can pretend I’m one of their devices, I’ll look like authentic firmware, and I can reprogram their device with it.
That’s the kind of problem which has existed. We’ll start with phase zero, people saying, “I don’t need any security,” or “I’ve got a secure token,” or “I’ve got a hardcoded password, and that’s better than nothing.” Then people that say, “I can glue something together and make it work.” But the world has changed. There are a lot of well-known attacks that people can just rerun because they’ve been scripted into these automated hacking tools. There’s a lot of really clever people that are motivated to try to hack into these devices because they envision significant economic gain from doing so.
The world’s changed, and you need a solution that will be able to withstand broad attacks from people that are willing to buy one of your devices, download the firmware, tear it apart, and reverse engineer it. To do that, you start to look at things like when the chips are first produced in the foundry by the chip manufacturer, and they’ve got a secure element. Can you insert a certificate at that early stage so that you can validate the chip when it goes to manufacturing as an authentic chip from whoever it is you bought it from and start to secure the supply chain? When the device comes off the production facility, can you use that chip identifier, that chip’s ID certificate, to validate that it’s an authentic part?
There are some of the things that you start to talk about as you look at a broad ecosystem and having partnerships that play across those vast ecosystems. We’re working on those things, we have some of those in place, but it requires a lot of integration and a lot of players to get that complete and robust solution.
Jason: Here is one more example of an ecosystem — and that term does have an actual meaning in PKI from the CA point of view. Think of yourself as a large service integrator. Maybe you have several industrial campuses that you manage, and perhaps you even manage other campus groups, as well. You want to have your finger on the pulse of all these things. You want to segregate each of your clients from each other, but you want your remote management tools to be able to reach out and touch all of the devices on those campuses.
What a device ecosystem gives you is precisely that ability to segregate trust. The term ecosystem is really a term used as an umbrella for a trust model. A consortium is another example where I want all devices for consortium members to trust each other in a defined way, but I don’t want these devices to trust anything outside of that consortium. Even large companies within the consortium —even if they stood up their own PKI and managed it themselves with their vast resources — won’t be trusted to extend trust across corporate boundaries.
Therefore, you need to have a PKI that extends across all of them and needs to be from a trusted third-party. That’s what Sectigo is — a trusted third-party CA. It’s quite natural for large enterprises to come to us to be able to interoperate together. Again, this goes back to purpose-built PKI. Our purpose-built certificate issuance system handles ecosystems by default. In other words, this ability to not only separate and segregate trust through certificate issuance, but even who can administrate various levels of the hierarchy as part of the platform. In other words, being able to handle a device ecosystem of trust is directly part of what makes a purpose-built PKI for IoT.
You mentioned industrial and the various campuses and being able to manage it at one end. I’m wondering what you’re finding with your customers in the industrial market where the IT and the floor management have never historically worked together much. While IT may know about certificates and security, the VP of manufacturing, say, may not necessarily have had to deal with it. Even legacy IT departments have not necessarily had to deal with the challenges of connected devices and all the different protocols, the legacy protocols, and the interfaces. When it comes to securing this digital transformation in manufacturing, what would you say to those people, again, who may not have the skill sets?
Alan: I think what you outlined is reality. It is an area where security is sorely needed, where there are large interoperability and educational issues, but there’s also tremendous opportunities. You’re figuring out ways to work with people in that space, and, as you say, make it so that it’s easier to understand what is critical. I think that’s another one of the motivations for pulling the two companies together because companies don’t want to work with five different vendors and integrate everything themselves. They want to be able to come to one company and say, “Okay, go make it work for me.”
That’s one of the significant advantages that we bring to the table. I was on a call yesterday with a company, and I could tell by their questions that they really didn’t understand some of the nuances of what they needed. The nice thing is, now we can come in together and provide a solution that covers the concerns that they have, and along the way, they’re learning. They’re smart people; they’ll come up to speed on it. If I had to try to sell them half the solution and then find somebody else to sell them the other half and educate them along the way, it’s much more challenging.
Jason: Let me give you one analogy of what’s happened in some other verticals. Stuxnet was, I think, ground zero for the a-ha moment for the industrial vertical going back to 2007. I believe Charlie Miller and Chris Valasek did an excellent job at teaching the same lesson to the automotive industry, specifically GM Chrysler. Keen Labs did the same thing for Tesla, and now the automotive industry is a leader in thinking about these problems. They’re no longer neophytes to PKI and security. In the healthcare market, Billy Rios was the one who caused the recall of the Hospira infusion pump. Medical now has had their wake-up moment, as well. There have been others.
I think legislation is forcing a lot of consumer-level devices to address security, as well. I think even some of the consumer IoT device vendors see the writing on the wall. They can’t just ship product now with minimal or no security anymore. Those days are numbered.
There’s an enormous amount of learning that has to be done. Many verticals have had their wake-up moments and are moving in the right directions. The bright light to me is the consortiums in these verticals. We are telling people, “Hey, security is hard.” Alan just talked about implementing secure boot. Even if you’re a big vendor, you might get it wrong. Come to the 20-year-plus experts. Come to the PKI vendor who’s been doing it for 20 years plus. We’re your security partner.
Alan Grau is the VP of IoT, Embedded Solutions IoT at Sectigo. Alan joined Sectigo in May 2019 as part of the company’s acquisition of Icon Labs, a leading provider of security software for IoT and embedded devices, where he was CTO and co-founder, as well as the architect of Icon Labs’ award-winning Floodgate Firewall. He is a frequent industry speaker and blogger and holds multiple patents related to telecommunication and security. Prior to founding Icon Labs, he worked for AT&T Bell Labs and Motorola. Alan has an MS in computer science from Northwestern University.
Jason Soroko is CTO of IoT at Sectigo. Adept in solving business problems by synthesizing security with real-world operational needs, Soroko contributes to strategy, intellectual property development and consortium standards that advance private trust certificate management across industries. Prior to Sectigo, Soroko served in senior cybersecurity roles at Entrust, including Head of Malware Research, where he continually analyzed the cyber threat landscape and developed product strategy. He is also a frequent industry speaker, blogger, contributor to IoT Agenda and IoT for All publications, and co-host of the popular PKI and security podcast “Root Causes.”
Leave a Reply