Roland Lindsey at Embedded World: Redefining IoT Security with Compliance, AI, and Reachability
Watch Finite State’s Roland Lindsey discuss SBOM-driven compliance, reachability analysis, and AI-enhanced remediation at Embedded World. Learn how connected device security is evolving.
•6:29•HD•0 views
Roland Lindsey at Embedded World: Redefining IoT Security with Compliance, AI, and Reachability
Transcript
I'm Keith Kreischer, Executive Director of the IoT M2M Council, coming to you from Embedded World North America in Anaheim, California. And I'm here with my good friend Roland Lindsey of Finite State. Roland, good to see you. Good to see you. How's the show going? It's a new venue, new show?
It's great. Yeah. It's our first time here, and we've had great interactions with customers. One of the great things about this show, the folks are really well qualified. They care about embedded systems, they care about developing, and it's fun. They're just walking around with their engineering samples saying, look at this thing I work on, can you help me? It's good stuff.
Right.
Talk to us, I mean, Finite State, obviously, well known in security circles for IoT and embedded.
You know, you guys are doing audits, you're doing real time monitoring, testing, all sorts of things. Talk to us about the concept of meeting compliance.
How does finite state facilitate that for its customers?
Yes. So compliance is an area where a lot of our brings a lot of our customers to us. They need to meet NIST, they need to meet CRA, they have a number of different governmental requirements that they need to meet. So they come to us and they say, hey, look. We've been doing this manually.
Is there a better way to to meet these requirements? So what we do is, number one, all of our work is around filling up an SBOM with what's inside that firmware along with its related security information. That that then gives the various regulatory bodies what they need to meet their their needs. In addition, we also, in our product, will say, hey. This is outside of the you know, this particular regulation, and so you can get a report and fix those missing gaps. Ultimately, our product is built primarily primarily to solve those compliance problems and get people to what they need to get through those those processes quickly.
And talk to us about the progression from compliance to security or or the other way around.
No. Absolutely right. So a number of a number of clients, I would say most clients start off with clients. That's what they need to get done. And then they find out, hey, you know, you know, security information, and that security information becomes very relevant, very valid, and so they move deeper and deeper into that.
And then we have other customers who they come in and they say we want security. We heard that we can get a lower risk, a higher security profile if we use your product and that's generally what they find.
Terrific.
I'm curious about the concept of reachability in a security platform. So what is it, how does it work, why is it important?
Speaker We're really excited about this. I've been working in this field for a long time and this is one of the most exciting advancements I've seen. And the reason why is because, you know, when you've been working in security for a while, all these tools provide here, we scan this thing, and there's a thousand findings or ten thousand findings.
look at that and you just go, how do I Findings mean vulnerabilities.
Vulnerabilities.
And you go, is it possible there's this many and how how does it matter?
So what we do with reachability is we did we look at it and we say, you know, during our process that we use to fill up that SBOM, we do a full binary analysis and static analysis to say, what's going on with this firmware? And then we look at how whether or not the code in your project actually touches those vulnerable parts. And where they do, we say, yes, that's reachable. Where they don't, we say it's not reachable. Sometimes we can't tell either way, but oftentimes we get great value because, let's say we have those three thousand results, we might cut that down to forty that really matter because those are actually reachable. Those are actually have known exploits. These are the most important ones to look at.
Of course, win and win out things that are not reachable.
Exactly. By the same token, we very frequently find that the vast majority of findings are not reachable, which means most of the products that do what we do, they're saying three thousand vulnerabilities, but really most of them are not gonna be reachable. So what we do with that is we we mark we're able to look at those, identify them, mark them, and then into the SBOM, we're able to enter VEX entries that say, hey. We have this vulnerability technically, but it's not reachable. Here's our evidence. And so now when I produce that SBOM to FDA or someone else that needs to see it, they can see that we've done our due diligence, that we actually worked hard to mitigate the issues that there are, we know there are with these particular components.
Great. I would be remiss if I did not mention AI and it's the eight hundred pound gorilla.
How is that affecting security for embedded systems?
In a few words as possible. I'll try. I know it's a big stuff.
I'll try. It's significantly.
I mean, sense that it is everything and everyone wants it to be everything. And the thing about AI is, you know, you have that eighty twenty thing going on. Has eighty percent of the job really well. That last mile is hard.
And so what we found is still what most of us have found in our lives working with AI so far. LLMs do a really good job of organizing and summarizing. And so we find when we feed it the context that we get out of our process, all of the varying levels of analysis we do, reachability among them. We pull it together and we say, okay.
Can you help us triage this? And it comes back and says, yeah. These four are the most important. You should hit those first, and here's why based on this data we provided.
And then it will say, now for each one of these four, here are your options. You could upgrade your component. You could try to no. Don't use that kernel module.
There's different things you could do. And because of the context we're able to give that LLM, we're able to get really on target useful remediation advice.
Great stuff. Hey, once again, I'm Keith Krasher here at Embedded World with Roland Lindsay of Finite State And Roland, hey, thanks so much for your time.
Roland Thank you.
Have a great show.
All right. Thanks.


