Exploited: The Cyber Truth,  a podcast by RunSafe Security. 

Paul Ducklin (00:04)

Welcome back everybody to Exploited: The Cyber Truth. I am Paul Ducklin, joined as usual by Joe Saunders, CEO and founder of RunSafe Security. Hello Joe.

Joe Saunders (00:17)

Greetings, Paul. Great to be here.

Paul Ducklin (00:20)

And we have a repeat guest in this episode, Hemanth Tadepalli, who is Senior Cybersecurity and Compliance Manager at May Mobility. Welcome back, Hemanth.

Hemanth Tadepalli (00:32)

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.

Paul Ducklin (00:38)

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 Cybersecurity Becomes a Safety Issue, with a subtitle of: How Do We Protect Autonomous and Critical Systems?

So without further ado, Hemanth, 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, in as much as they have become essentially computers on wheels or software defined vehicles? What differences has that made in the cybersecurity world?

Hemanth Tadepalli (01:30)

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

Paul Ducklin (01:50)

So this is more complicated than a typical business network was perhaps twenty or twenty-five years ago.

Hemanth Tadepalli (01:58)

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. We also have to secure cloud infrastructures. We need to secure APIs, mobile applications, supply chains, right? You’ve been seeing the news of how outrageous supply chain attacks are happening.

Paul Ducklin (02:24)

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?

Hemanth Tadepalli (02:57)

The code that you’re pushing from GitLab, GitHub, wherever, that is going to be one piece that is going to affect the entire ecosystem inside of a vehicle. 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 at the end of the day.

Paul Ducklin (03:20)

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.

Hemanth Tadepalli (03:39)

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

Paul Ducklin (03:48)

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 unlocking the vehicle and starting it.

Hemanth Tadepalli (04:27)

What we’re seeing here is that cybersecurity is becoming a safety issue when a cyberattack can especially directly influence the physical world. 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.

Paul Ducklin (05:02)

So that’s what is generally known by the term 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 least build it in as part of the project from the very, very beginning.

Hemanth Tadepalli (05:20)

Yes, it has to be a shift left approach. Start security when you start developing. There’s a reason there is SaaS solutions and dynamic application security testing, software application security testing being done in real time on the computer when 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.

Paul Ducklin (05:48)

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.

Joe Saunders (06:18)

Yeah, I think the common denominator, first of all, in all cyber physical systems, but obviously automotive included, is exactly what Hemanth 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 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 and incorporating ways to create resilient software that achieves that safety in the long run.

Paul Ducklin (07:19)

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 EU CRA, the Cyber Resilience Act. Do you think those will change that compliance landscape?

Joe Saunders (07:48)

Yeah, I think the old adage that security is always compliant, but compliance isn’t always secure.

Paul Ducklin (07:56)

That’s one of those thumbs and fingers analogies, isn’t it?

Joe Saunders (07:59)

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 a compliance program, yes, it’s one thing to be compliant, it’s another thing to be secure and safe.

Paul Ducklin (08:17)

So compliance should not be a 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.

Joe Saunders (08:31)

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 Hemanth can talk about it more because he’s a much greater expert than I am.

Paul Ducklin (08:48)

Hemanth, you used, and Joe, you also use this term 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 or a 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.

Hemanth Tadepalli (09:27)

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 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 within cybersecurity. 

For example, any vehicle, autonomous vehicle that wants to actually go ahead and roll out in 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.

Paul Ducklin (10:36)

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 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 in cybercritical systems?

Hemanth Tadepalli (11:04)

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 it’s 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 and ensuring a secure culture.

Paul Ducklin (11:40)

How is AI changing, 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?

Hemanth Tadepalli (12:04)

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.

Paul Ducklin (12:47)

Yes, and there have been quite a few recent examples of where it’s almost like we were in malware detection twenty or even thirty 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 it 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.

Hemanth Tadepalli (13:25)

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 are made up of artificial intelligence. We’re using different models, different tools, different libraries to have a car drive by itself.

It used to be a computer on four wheels, now it’s AI on four wheels.

Paul Ducklin (13:58)

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, 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 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?

Joe Saunders (14:39)

We do have a shock to the system. AI is here and is changing a lot of the processes. 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 of even more of 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 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 fifteen, twenty percent of the overall economic cost to change. How can you change those economics more completely?

So you can free up resources. And in my mind, I’d like to, instead of chasing fixes and patches and chasing bugs consistently, 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 eliminate 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 Hemanth 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 is to help prioritize which vulnerabilities to pay attention to in the first place.

Hemanth Tadepalli (16:51)

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 the 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 in the process. The last thing that you want to see is one of your SBOMs being compromised. Doing that security monitoring throughout the life cycle of your SAST and DAST scanning is going to be important too.

Paul Ducklin (17:31)

You do hear some evangelical type saying, right, what we need to do is we need to throw out the baby, the bathwater, 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.

Joe Saunders (18:01)

Yeah, 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. 

Paul Ducklin (18:27)

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?

Joe Saunders (18:55)

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 Hemanth had talked about earlier of 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. 

Do 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.

Paul Ducklin (19:54)

It’s not just that I don’t have four gig of RAM spare. We all know what the price of RAM is like these days. You might literally might not have four K of RAM spare. So this is an ideal way of healing some problems of the past that 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.

Joe Saunders (20:19)

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

Paul Ducklin (20:43)

Hemanth, 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.

Hemanth Tadepalli (21:14)

That’s a great question, Paul.

Paul Ducklin (21:17)

No pressure.

Hemanth Tadepalli (21:19)

Right, no pressure. I think it’s the biggest question that people are still trying to navigate today. There’s two sides to it. The 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, 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.

Joe Saunders (22:38)

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 ten 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 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. 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?

Paul Ducklin (24:04)

This afternoon, I’m afraid.

Joe Saunders (24:06)

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.

Paul Ducklin (24:20)

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?

Joe Saunders (25:09)

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, and 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 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 and this vehicles and these components.

Paul Ducklin (26:05)

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 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?

Joe Saunders (26:42)

Well, I do think when you can’t live without something, you have certainly arrived. And if you go back, say twenty-five 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 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 for people at all stages. So I think it comes down to the ultimately need and benefit and experience that creates value for individuals and consumers and organizations.

Paul Ducklin (27:50)

Gentlemen, I’m conscious of time, so Hemanth, 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 got as far down the road or as shifted as far left as they really ought to have. Where would you start?

Hemanth Tadepalli (28:22)

We would need to build security into your culture, not just your products. I think the organizations that succeed won’t be the ones with the big security teams. They’ll 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.

Paul Ducklin (28:53)

I think that is a fantastic way to put it and an excellent way to conclude. So Hemanth, 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 to stay ahead of the threat. See you next time.