When Cybersecurity Becomes a Safety Issue: Protecting Autonomous and Critical Systems

Speaker A: Exploited the Cyber Truth, a podcast by RunSafe Security. Welcome back everybody to Exploited the Cyber Truth. I am Paul Dudlin, joined as usual by Joe Saunders, CEO and founder of Run Safe Security. Hello Joe.

Speaker B: Greetings Paul. Great to be here.

Speaker A: And we have, uh, a repeat guest in this episode, Haymonth Tadapalli, who is senior cybersecurity and compliance Manager at at May Mobility. Welcome back.

Speaker C: Hey month, thank you so much, Paul. I am super excited to be back here and looking forward to this discussion with Joe that we have today.

Speaker A: Yes, it's an interesting topic that we have brought up, but not discussed specifically as the episode topic many times before, touching on where safety and security mesh and do not collide. So our title is When Cyber Security Becomes a Safety Issue with a subtitle of how do we Protect Autonomous and Critical Systems? So without further ado, hey Month, why don't you kick us off by talking a little bit about the difference between today's autonomous or even self driving vehicles and vehicles of the past. Inasmuch as they have become essentially computers on wheels or software defined vehicles, what differences has that made in the cybersecurity world?

Speaker C: Computers on wheels, right. That's what autonomous vehicles and connected vehicles are. And I think the modern vehicle that contains hundreds of millions of lines of code, dozens of electronic, uh, control units, high speed networks, cloud connectivity. We're looking at AI models, we're looking at sensors, we're looking at over their updates.

Speaker A: So this is more complicated than a typical business network was perhaps 20 or 25 years ago.

Speaker C: Oh, for sure, definitely. We are having a lot more connected vehicles on the road and the attack surface has expanded dramatically. Security is no longer limited to the vehicle itself.

Speaker A: Yes.

Speaker C: We also have to secure cloud infrastructures, we need to secure APIs, mobile applications, supply chains.

Speaker B: Right.

Speaker C: You've been seeing the news of how outrageous supply chain attacks are happening.

Speaker A: Yes, and some of them are very old school, old tech, aren't they? Somebody calls up a senior developer on a project, convinces them they want to have some work done because it's open source. Hey, let's get into an interview, maybe we'll sponsor some development. Could you just open up this GitHub project and tell us what you think? And of course the project's poisoned. And that person then invites malware into their own project without any real hacking needed. How do you defend against that?

Speaker C: The code that you're pushing from GitLab, GitHub, uh, wherever that is going to be one piece that is going to affect the entire ecosystem inside of a Vehicle. Yes, because code is going to be connected to other repositories, other repositories are going to be connected to other IoT products. And so protecting autonomous vehicles will require securing an entire ecosystem rather than a single product.

Speaker A: At the end of the day, it's not just that. It is as complex an ecosystem as your mobile phone, which everyone is concerned about. It's probably got a mobile phone built into it as well as everything else, plus an infotainment system, plus the cloud connection that lets you manage not just one vehicle, but fleets of them.

Speaker C: All these devices are going to communicate with one another and threat vector and the threat risk landscape is getting even bigger day by day.

Speaker A: Now that interconnection of all of these vehicles to monitor that things are working correctly, even that can become a weak link, can't it? We had Gabriel Gonzalez on the podcast. He's a well known hardware hacker. He said in a recent Red Team exercise that he was involved in, they didn't need to attack the vehicle at all. They found a bug in an MQTT server that was used to collect data from the vehicles simply for telemetry and fleet management. And from that bug they were actually able to issue commands to individual vehicles up to and including unlock uh, the vehicle and start it.

Speaker C: What we're seeing here is that cybersecurity is becoming a safety issue with a cyber attack can especially direct influence the physical world.

Speaker A: Yes.

Speaker C: In autonomous vehicles, compromised software isn't just about data loss. At the end of the day it can impact the steering, it can impact the braking, the acceleration, or even the decisions an AI system makes in real time. At that point the conversation shifts from protecting information to protecting human lives. And that's why cybersecurity has to be treated as a core safety engineering discipline, not just an IT function.

Speaker A: So that's what is generally known by the term, um, secure by design or security by design. You don't build the thing and then think where can we add security afterwards? You think about it, you at ah, least build it in as part of the project from the very, very beginning.

Speaker C: Yes, it has to be a shift left approach. Start security when you start development. There's a reason there is SaaS solutions and dynamic application security testing software. Application security testing being done in real time on the compute. Developers are actually pulling code and pushing code. There is a reason why those tools exist and it's because we need engineers, we need software engineers to adapt security best practices from the very beginning. We cannot have cybersecurity be a later thought. It has to be an early one.

Speaker A: So Joe, you like to talk about building resilience into software, not least so that we don't have to patch it all the time, which tends to be more difficult for devices that are out in the field. Where does resilience fit into protecting not just autonomous vehicles and vehicle fleets, but also cyber physical or OT systems in general? So including things like the electricity grid, water supply, water drainage, all of that vital stuff for society.

Speaker B: Yeah, I think the common denominator first of all in all cyber physical systems, but obviously automotive included, is exactly what Amanth had said, which is there are consequences that are pretty serious in all these systems and they can disrupt the way society operates, they can disrupt the quality of life, they can disrupt the passenger safety in a, uh, vehicle. What comes with safety then for secure by design, for shift left for how you build high quality code that can be reliable and predictable and deterministic is having good fundamental practices, a good culture, a good software development framework in which you are ensuring that your processes are going to enable great quality code and therefore safe code and code that meets compliance, not because you're trying to check the boxes. When you do the right things in that software development process, you will be incorporating good security practices, incorporating ways to create resilient software that achieves that safety in, uh, the long run?

Speaker A: Now you do hear a lot of people, particularly in IT systems, getting concerned about things like checkbox compliance. Now there are different regulations in the automotive industry particularly, aren't there, such as ISO 21434. And there are also changes, certainly in Europe, in laws about liability coming from the eucra, the Cyber Resilience Act. Do you think those will change that compliance landscape?

Speaker B: Yeah, I think, uh, the old adage that security is always compliant but compliance isn't always secure.

Speaker A: Yes, that's one of those thumbs and fingers analogies, isn't it?

Speaker B: As I like to say in the States, why do we park on driveways and drive on parkways? But here we've got security and compliance going hand in hand. Anybody approaching a compliance program, yes, it's one thing to be compliant, it's another thing to be secure and safe.

Speaker A: So the compliance should not be a, uh, goal in itself. It should be something that your business or your software development practices or your products naturally tend to do because you started from the right place.

Speaker B: And yet it's hard to do. It's hard to do because we have competing interests, different priorities across multifunctional organizations. That's part of the reason why compliance is Interesting. And maybe Hemant can talk about it more because he's a much greater expert than I am.

Speaker A: Hemant, you used. And Joe, you also use this term, um, shift left, which is a bit of a jargon security term. My understanding is that the idea simply is that if you're thinking about a software ah, or product development timeline, you normally start that map or that timeline at the left and go towards the right. The further you shift left with your security, the earlier it starts. And it seems to me that if you do that it's much more likely that you will find compliance comes almost as a matter of culture rather than as something that you just have to try and do later.

Speaker C: Uh, I think compliance has to be driven into like any framework. If you're looking at ISO 21434, if you're looking at the Cyber Resilience act, if for you're looking, if you're looking at a SOC 2 type 2 or an ISO 27001, those have to be embedded in the engineering cycle. And I think the industry is moving in the right direction because you need some guardrails, you need frameworks to adhere to. That is where trust is built in within cybersecurity. For example, any vehicle, autonomous, uh, vehicle that wants to actually go ahead and roll out a specific municipality, they care about these regulations. Any city that we go down to, we have to actually adhere to these best standards and practices. But compliance alone doesn't equal security. A lot of these frameworks are establishing a common language and what I would say, minimum expectations. This is going to be valuable. However, I think organizations shouldn't build security programs around passing audits. The strongest organizations treat compliance as the baseline and continuously improve beyond the regulatory requirements because threats evolve much faster than the regulations do.

Speaker A: Yes. In other words, pass your audit because that is the natural way of things for the way you conduct your business. Rather than cram for the examination at the last minute, put on a nice suit and tie when the auditors arrive and then the day after go back to the way you were. I, uh, think there was an element of that in cybersecurity in the past, particularly in it. Do you think we've got rid of that in OT and um, in cybercritical systems?

Speaker C: I think it's part of the journey. We look at ISO 21434 regularly. If it's doing the penetration testing, if it's doing the threat analysis, risk assessment on OT devices, the reason a lot of those practices are existent was because of these frameworks in the first place. Companies were demanding them to be adhered to. A lot of engineers started actually practicing this. The regulation is definitely helpful, and I think we are here, and as an industry, as cybersecurity practitioners, we're here in this moment because of regulation. It's helped our job to actually be important, and we have a reason to exist. When it comes down to these efforts in ensuring a secure culture, how is AI, uh, changing?

Speaker A: Not just the defenses, what about the threat side of it? Because not only can the attackers use AI to find vulnerabilities and speed up their attacks, they don't have to get their attacks perfect. They just have to have them succeed a bit of the time or much of the time. How do we balance that out so that we stay ahead rather than falling behind?

Speaker C: AI is accelerating both sides of cybersecurity. Attackers are using AI to automate phishing, generating malware, discover vulnerabilities faster, and even create more convincing social engineering campaigns. At the same time, a lot of the defenders are using AI to improve their threat detection. They're finding ways to automate investigations, prioritize those vulnerabilities that they find, identify any anomalies, and I would also say reduce the response times of getting to the attack. I think the challenge here is making sure that AI itself is trustworthy. We also need to secure AI models against any adversarial attacks, any prompt injection, any data poisoning, and even model manipulation going forward.

Speaker A: Yes. And there have been quite a few recent examples of where it's almost like we were in malware detection 20 or even 30 years ago, as though the AI models are only just beginning to get there. Where people have discovered that if they're filtering the text that you put in as your prompt, really carefully stick in an image. And that won't get verified by the text pre checker, but the AI might notice, hey, there's text in there. I can extract it. Let me use that. It's almost like we have to revisit some of the lessons that we learned in the past pretty quickly.

Speaker C: Absolutely, absolutely. I think the lessons that we're learning right now is just the beginning. This landscape is going to be evolving very fast. And as we find more threats, as we find more vulnerabilities, compliance is going to be a really big vector here that's going to govern how we actually deploy AI systems. How are we deploying autonomous vehicles? Because autonomous vehicles is made up of artificial intelligence. We're using different models, different tools, different libraries. To have a car drive by itself.

Speaker A: Yes.

Speaker C: It used to be computer on Four wheels. Now it's AI on four wheels.

Speaker A: So Joe, do you want to say something about how you maintain innovation in a world where we also have increasing compliance pressures, where we have liability threats in the Cyber Resilience act, and in all this concern about, oh, uh, what if the crooks use AI and just defeat us at machine speed, how do you get the best of both worlds so that you can actually become more resilient, deal with compliance and all the work that that requires while still being innovative and future looking and for that matter, fixing some of the sins of the past while you're about it from an engineering point of view, we do

Speaker B: have a shock to the system. AI is here and is changing a lot of the processes.

Speaker A: Yes.

Speaker B: That means it's a great opportunity to kind of revisit your approach and it's a good time to take inventory of your processes and look for changes. You can boost resilience and free up resources at the same time to allow you to take advantage even more of, uh, the opportunity to drive innovation and new features and new development specifically. What I mean with that is historically we've gotten to the point where we're in a rat race. We find a new vulnerability, we figure out how to fix it, we figure out how to test it, we figure out or how to patch it, we figure out how to test all that, then we figure out how to get it deployed, and then we make sure and support people. And if you look at that economic equation, the vulnerability discovery and the rewriting of code is only a portion of it. It might be 15, 20% of the overall economic cost to change. How can you change those economics more completely so you free up resources? And in my mind I'd like to, instead of chasing fixes and patches and chasing bugs consistently, is find a way to eliminate entire classes of vulnerabilities in the first place. And we can see that that's possible today with memory safety vulns. We can see that with AI tools scanning your code bases, finding those vulnerabilities earlier, but doing a better job assessing reachability and exploitability so you know which vulnerabilities truly need to be fixed. Those are areas of opportunity where you can be more resilient because you're getting more precise in where you're focused or eliminating entire classes of problems so you don't have to really worry about them as much anymore because they're no longer exploitable. So I think those are opportunities. One, we have a shock to the system. AI is everywhere. We need to adapt. Two, Eliminate classes of vulnerabilities and then three, leverage the tools. As Hemant has said, look for ways that you can leverage AI on the defense side. And in my case, I would say part of that opportunity then is to help prioritize which vulnerabilities to pay attention to in the first place.

Speaker C: You will see high critical alerts, you're going to see high critical vulnerabilities. Those are the ones that you really need to take a look at. If there is a supply chain compromise happening in the industry, probably take a look at the ones that are being affiliated to that. I think the disruption is really big right now. Paul and Joe, we have seen a number of attacks skyrocketing from suppliers to manufacturing companies, and they're all being connected to one another. This is kind of where SBOM comes into place, making sure that you're doing your system builds and material scanning early on on the process. The last thing that you want to see is one of your sboms being compromised. Doing that security monitoring throughout the lifecycle of your SAST and DAST scanning. It's going to be important too.

Speaker A: You do hear some evangelical type saying, right, what we need to do is we need to throw out the baby, the bath, water the bath and redo the plumbing, rebuild the operating system from scratch. We do everything in Rust. Not only can we not do that for economic reasons, sometimes we can't even do it for physical reasons, particularly in critical infrastructure. You can't just stop all of those things working. You can't drive to each one and replace everything.

Speaker B: Yeah, uh, because part of the problem, if you were, say, for example, to rewrite all your software in Rust, for example, there may be a lot of open source software components that are not yet rewritten in Rust, nor would they necessarily be compatible. And so there are architectural questions that you might have to knock down the whole house just to get to a new bathroom, which would be an absolute disaster for everyone.

Speaker A: And for systems where you don't have the luxury perhaps of either redesigning them to include or retrofitting them so that they have modern add on protections in the IT world, you might think of, hey, let's just install EDR on every endpoint. For systems where you can't do that. Joe, do you want to say a little bit about RASP or runtime application self protection?

Speaker B: One of the angles historically with RASP is that you may be adding additional software on a target system and that would change devices or system behavior. It also could affect overhead, much like the idea that Hemant had Talked about earlier of uh, kind of shifting left. If you can build in security without affecting runtime performance, but enables the ability to prevent exploitation of a majority of vulnerabilities, you really have advanced the resilience of the systems long term. You have built in security that can enable protection at runtime even if a vulnerability exists, then you can see how you can extend the life of legacy code or code that needs to be maintained for 25 years. So the idea then Paul, to your point, is to insert security protections at build time that don't affect system performance, don't change behavior and provide that increased exploit prevention at runtime.

Speaker A: It's not just that, oh, I don't have 4 gig of Ram spare, we all know what price of RAM is like these days. You might literally might not have 4k of RAM spare. So this is an ideal way of healing some problems of the past that uh, ultimately actually gives you more time to do things like change the operating system rewrite in Rust if you want to, rather than having to try and panic and do everything at once to

Speaker B: extend the life of your code. And you have constrained power, constrained compute resources, memory. There are certainly options to do that and to add in security without affecting system behavior or requiring uh, additional compute resources. Historically, if people just assume people would upgrade to new hardware, that's just not the case.

Speaker A: Hey Month, I want to come back to you now. What do you think it will take for the public, consumers and OEMs and suppliers in the space to trust autonomous vehicles and software defined systems? How close are we to people going, you know what, I actually think that I'm less likely to get run over by an autonomous taxi than by someone who's popping down to the shops on every occasion.

Speaker C: That's a great question, Paul.

Speaker A: No pressure,

Speaker C: right? No pressure. I think it's the biggest question that people are still trying to navigate today. There's two sides of it. First side is that what you see on the news is going to make the news bigger and bigger versus what you don't see on the news. If you see somebody get into a car accident with a person behind the wheel, hits another car, that's not going on the news. What's going to go on the news is an autonomous vehicle hitting a car. And that's because of trust. Trust comes from consistency and transparency. Go visit a trust center, see what makes part of the cybersecurity behind the vehicle and the company. People need confidence that these systems are secure, that they're tested, that they're resilient and that organizations can actually respond responsibly when problems occur. Public trust won't come from marketing. It will come from years of demonstrating safe operations, transparency, transparent incident handling, independent validation. For us, we go through a SOC 2 type 2 audit and then the continuous improvement over time. You are building a connection with the passenger that steps inside the vehicle and that is what really matters. At the end of the day, it's serving the public securely and building trust.

Speaker B: Yeah, I do think it's trust in the brand, and the brand has consistent delivery and expectations. I do have an optimistic view on people finding trust in autonomous systems. The example I like to use is that I used to play this flag football game and the rules were that the little kids under 10 years old or whatever had to touch the ball once per possession. And guess what? Those little kids grew up and the rules flipped. Where it became the rule that the parents or uh, the adults who became 40 or 50 or 60 years old, one of them had to touch the ball. I do think there's kind of a key thing in this for autonomous systems. We build determinism into safety programs, knowing that you know how a system's going to behave given a set of constraints or inputs. Yes, that is certainly the case in the autonomous driving world. It's true in safety of flight and even in other areas, safety is paramount and our engineers building these systems do need to adhere to those expectations. And so ultimately I believe that autonomous vehicles will behave in a predictable nature. And at some point we're all going to realize that humans are not deterministic. How many times have you driven down the road and you have found someone swerving in and out of lanes and going crazy and going 50% faster than anybody else on the road this afternoon? I'm afraid there is safety in autonomous driving, in my view. And at some point we'll flip and the little kids will grow up and be the star football players on the field, and we will all be shifting to trusting autonomous driving.

Speaker A: Do you think that part of some people's skepticism about self driving vehicles might come down to perhaps confusing experiences that they've had when they've tried AI themselves? For example, I asked Claude the same question an hour apart from two different browsers, and it gave me an answer that was completely correct one time and a completely different answer that was utterly wrong the next time. What happens if autonomous driving systems behave in the same way? So how do you think vendors and suppliers and automotive manufacturers can convince people that the way AI works in their cars in terms of safety, isn't as prone to mistakes as perhaps people may have experienced when things don't matter so much.

Speaker B: Yeah, I think we may have sort of the near term bias. Generative AI is certainly one of the more recent experiences most people have in interacting with AI systems in general. But if you go back to the automotive industry, there has been a lot of artificial intelligence generally or machine learning, even computer vision and other things in systems. You look at these cars with sensors with anti lock brakes and controls that help control the vehicles, that there are lots of artificial intelligence systems that are really not meant to be general purpose systems, but they're built around certain functions and those functions in a uh, safety construct where determinism by engineers is the gold standard and is expected, means that there is a lot of predictability and a lot of reliability in these systems, in these vehicles and these components.

Speaker A: Yes, I must say because I don't own a car, so I hire cars occasionally when I need them, say once a year. I'm amazed at how some of the driver aids have improved each time. Thinking about abs, I know we've had it for ages, but I used to like old classic cars that didn't have it. I prided myself on um, being able to brake reasonably well manually, but when I compare it to my experience driving non electric vehicles these days, there's no way I could beat a modern automated system that's reading the road more predictably than I would. How will we know when we've arrived though?

Speaker B: Well, I do think when you can't live without something, you have certainly arrived. And if you go back say 25 years, did people think they needed smartphones? No. At some point that kind of flipped and it flips. When there's benefits and great value and great experience and great outcomes that have changed and improved the quality of your life and mobility in general helps improve the quality of the life. And I like to say that security is a key element to mobility. But mobility is something that drives a, uh, tremendous value and quality of life for people. It can affect people at all different ages and stages of life. My wife made the comment to me, let's say in 25, 30 years certain mobility questions are not going to be a concern of ours. Even if we are sick and needing a lot of care, having great mobility enhances the quality of life, uh, for people at all stages. So I think it comes down to then ultimately need and benefit and experience that creates value for individuals and consumers in organizations.

Speaker A: Gentlemen, I'm conscious of time. So hey month, I'd like to finish up by asking you another of the very open ended questions put you on the spot. Again, if you could just give one piece of advice to an organization that wants to get into building and delivering components for software defined anything in general or automotive in particular, where perhaps they haven't gone as far down the road or has shifted as far left as they really ought to have, where would you start?

Speaker C: We would need to build security into your culture, not just your product. I think the organizations that succeed won't be the ones with the biggest security teams. They'll, uh, be the ones where every engineer, product manager, executive and supplier understands that cybersecurity is part of delivering a safe and trustworthy product. Because when security, safety and engineering work together from day one, organizations can really innovate faster while earning the trust of customers and society.

Speaker A: I think that is a fantastic way to put it and an, uh, excellent way to conclude. So Heymann, thank you for those very resonant words. That is a wrap for this episode of Exploited the Cyber Truth. Thanks to everybody who tuned in and listened. If you like and enjoy this podcast, please like and share us on social media. Tell your friends, your colleagues, and most importantly, your boss about the podcast. And remember, stay ahead of the threat. See you next time. Uh,