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

[Paul] (00:02)

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

[Joe] (00:03)

Greetings, Paul. Great to be here today.

[Paul] (00:22)

And we have a guest for this episode from none other than the mighty state of Michigan. So a very big welcome to Hemanth Tadepalli,  Senior Cybersecurity and Compliance SME at May Mobility. Hello Hemanth. 

[Joe] (00:29)

Go blue.

[Hemanth] (00:42)

Nice to meet you, Paul. Nice to meet you, Joe. Thank you, guys, so much for having me.

[Paul] (00:46)

It’s a great pleasure, so why don’t we kick off with our title for this week, which is “Beyond Defense Building Cyber Resilience in Autonomous Mobility.” But Hemanth, before we start, why don’t you tell us how you got into cybersecurity in the first place and from there what it was that led you into cybersecurity in autonomous vehicles, particularly.

[Hemanth] (01:15)

I really did not know I was going to go into cybersecurity, to be completely honest. Who’s a South Asian American, typical family members are forcing you to become a doctor or a lawyer or whatever. And I took anatomy in high school, and then I had to dissect a cat, and I said, this is not for me.

[Paul] (01:32)

So you ended up dissecting code instead?

[Hemanth] (01:36)

Exactly. The dissecting code and finding what’s within code. I took a computer course, loved computer science, but I also had a big passion for public policy and the legal landscape. You know, I really wanted to go into political science and public policy, but I just loved tech so much growing up. And I said, where can I really bridge the gap between technology and policy? I started working at my first job at Alex Partners, the management consulting firm, from Incident Response to threat detection, to GRC, risk management, network security. And then later on, I went to work at Mandiant, which is now part of Google. Really seeing the breaches real time made me realize how important this work really is. Fast forward, what am I doing with self-driving cars?

[Paul] (02:24)

There’s a natural bridge there, given the safety and security risks that exist with autonomous and or connected vehicles.

[Hemanth] (02:34)

Working in the state of Michigan, Detroit’s known as Motown, at the end of the day. Motor City. So you work for a self-driving car company, but you live in Detroit, Michigan. People usually think of Detroit, Michigan as the Woodward Dream Cruise, the people that are riding the loud cars down 75 or I-69 or Woodward. I really believe that this state has a future with autonomous vehicles and connected vehicles. I was actually part of a student organization back in college that focused on autonomous driving at Kettering University. Here I am actually doing it for a living.

[Paul] (03:10)

Cars have had software in them for decades now. We’ve had the CAN bus, we’ve had software that took over from things like contact breaker points and managed things like ignition timing and emissions controls. But these days it’s sort of turned on its head because the car is playing second fiddle to the software and they’re software defined vehicles that happen to have a car involved with infotainment, with driver aids, with satellite navigation, with telematics about almost everything you do all the time and increasing levels of autonomy where either the car helps you a bit or it drives the whole jolly thing for you.

[Hemanth] (03:53)

A vehicle is more like a computer on four wheels. The same way you protect your computer, you need to protect the vehicle. There’s been a lot of attacks on tire pressure monitoring systems, believe it or not, or even navigation GPS units as people are traveling to different locations. Those have been spoofed. We saw what happened with the G-PAC that happened many years ago, right? That’s really where vehicle security started taking more precedence when it comes down to our governance model.

The ISO 21434, the ISO 26262, that’s kind of the GRC part of automotive autonomous vehicle security. How are we making sure that our passengers are safe from cyber attacks?

[Paul] (04:36)

Do you want to say something about how ISO 21434 is changing and hopefully improving engineering and security decisions for the automotive industry in general and for self-driving cars in particular?

[Hemanth] (04:51)

It’s playing a big role in guiding the controls that are needed for engineers to implement before production, protection around the vehicle, internal from a software side, as well as external, who has access to the vehicle. Where’s the key fob being placed inside an autonomous vehicle? UL4600 is more specific to AVs.

[Paul] (05:13)

AV it can mean audiovisual antivirus but to you I guess autonomous vehicle.

[Hemanth] (05:19)

That is correct, autonomous vehicles.

[Paul] (05:21)

They actually drive for you. Yes. You don’t even have to be in the front seat.

[Hemanth] (05:25)

They are there to give you transportation from point A to point B. We’ve seen a lot of companies already putting AVs on the market. The Waymo, see Zucs, May Mobility. We’re in a critical area right now, Paul, because a lot of states are allowing autonomous vehicles to be operating and social media takes a big effect on a lot of this too. You see people on TikTok or on Instagram, they’re posting, ride with me as I’m going in my first autonomous vehicle ride.

It’s a life-changing moment for many people because they didn’t expect this to be happening in the year of 2025.

[Paul] (06:02)

So how do you think the standards are helping? Joe, maybe I can ask you here, because Hemanth talked about security before production, secure by design rather than by a sea of retrofits that come later.

[Joe] (06:16)

There’s no mobility without safety and security. And the standards that Hemanth has mentioned obviously help achieve that. The safety expectations in autonomous vehicles, but in all automobiles, is high, and building in security is a good part of that strategy. So, you know, I do think it’s a comprehensive approach to think about your software development life cycle and how you build security into your products, into your components. How you manage looking at the supply chain to understand where security risks could be coming from and what approaches you take between OEM and suppliers to manage all that, navigate all that. 

Security and safety then help drive the necessary changes in not only the software architectures, but the software development practices so that security is built in. We can’t assume there will always be a patch and that will just automatically be updated. There are challenges even in that realm. Building security and safety into the process is an obvious necessity in the automotive market.

[Paul] (07:25)

What about threat response as it applies not just to autonomous vehicles but also to connected fleet management? Although a lot of the social media excitement about autonomous vehicles and cybersecurity concerns, what if someone hacks into the vehicle and suddenly swerves it off the freeway while I’m in it? At the same time, even if you don’t actually take any control, just being able to get your hands on all that telemetry would seem to be a bit of a pot of gold, not just for cyber criminals but certainly for state-sponsored actors.

[Hemanth] (08:01)

I guess from an IT security side, we’ve heard the term SOC, Security Operations Center. Believe it or not, a lot of OEMs and companies have something called a VSOC, which stands for Vehicle Security Operations Centers. And their goal is to monitor the vehicle 24/7. They are going to be monitoring the APIs that are being transactional, the different calls that are being put together between vehicle to vehicle and from the call center to the vehicle.

That’s the job of a VSOC is to make sure that companies are securing their vehicle communication pipelines as well as the vehicles itself. Another thing in practice is penetration testing on the vehicle.

[Paul] (08:45)

In traditional SOC, if there’s some kind of anomaly detected or some kind of threat response needed, it’s annoying but not the end of the world if everyone gets the message, Zoom is going to be down for the next 60 to 90 minutes while we investigate. It’s very different if you’ve got some threat response that’s needed for vehicles. Well, we’re going to pull you all over to the side of the road wherever you are right now, even if you’re on the freeway in the middle of a junction or wherever you might be.

It’s a very different sort of world, isn’t it?

[Hemanth] (09:15)

Yeah, absolutely. I think the incident response plan, you know, has to be triggered then. Just as a company triggers incident response procedure when a security attack happens. I’d also say disaster recovery is going to be important here too. In this situation, a vehicle is attacked, autonomous or not.

[Paul] (09:35)

Yes, it gives a whole new meaning to the word system crash, doesn’t it? A collision where there’s actual hard physics.

[Hemanth] (09:44)

This is where the procedure of disaster recovery comes into place is how are you going to get back on your feet and having vehicles drive again? I think this is where critical infrastructure is also being impacted right now in our world. Trains, power grids, these are all connected at the end of the day.

[Paul] (10:01)

So in something like an autonomous vehicle fleet, let’s extrapolate that on our minds to things like power grids, wastewater control systems, anything that’s very distributed. How do you deal with things that could be very, very beneficial by letting you push out fixes really quickly, like over-the-air updates, like we’re used to on our phones or for our web apps, in a way that doesn’t actually hurt safety?

[Hemanth] (10:28)

I mentioned this before: security before production. Security has to start from the very beginning of the life cycle. When it comes down to the vehicle architecture, the vehicle system integration cycle, it has to be from the beginning all the way to the end. I wish I could just say one word, and that’s just patch management, but at the end of the day, it’s not just patch management. There’s a lot more that comes down to making sure that vehicles are being secured.

I think a lot of companies are focusing on doing static code analysis on the repositories of code that’s being put into production. I think the open web application security program does an excellent job just kind of navigating what threats and vulnerabilities are out there and ways that companies can address them from an engineering side. Another big thing too, Paul, is learning from the mistakes that are happening in the industry and what can companies do to do a better job in fixing those incidents.

[Paul] (11:26)

Joe, do you want to say something about the concept of patch management and vehicles in particular or embedded devices in general? Because even if you had a vehicle that can take over-the-air updates, there can be significant safety and regulatory challenges that make it difficult to do even if you think you’ve got a patch ready. Patch management, even if you want to do it, can be out of reach, can’t it?

[Joe] (11:52)

Well, it can be out of reach and it also can be quite onerous given the safety requirements that are needed. The automakers are obviously certifying their, say their autonomous software platform to be safety certified at different levels, depending on the nature of the controls in place. And that’s why I think it is an end end process. And you think about all the risks that could be in the software supply chain, whether it’s open source software or third-party proprietary software or the software that’s written by the OEM themselves, they all need to, if they’re going on to a safety certified platform, need to adhere to those standards. And when you introduce changes, you need to ensure that the proper testing is done, the proper accreditation safety is done. And if you can’t navigate distributing patches quickly, because you do need to ensure that you’ve got the safety measures in place.

What it means is you have to think about your overall architecture and your overall software development process in the first place so that you can have resilient systems that don’t run into problems with bugs in with patches that are unproven or untested or not safe. I much prefer to run safe than be not safe.

[Paul] (13:10)

So not saying that we need a world where patches are no longer necessary because that’s unlikely to be reached. But what I think you are saying is we need a world that if a patch is very difficult, we still need to have some measure of protection in place so that we can concentrate on the things that really matter instead of just trying to paper over cracks all the time. Which seems to be how it works in the operating systems we run on our laptops sometimes.

[Joe] (13:36)

Yeah, 100%. As you know, Paul, I’m a firm believer in having a robust, secure software development framework and set of processes and building in security as part of the process to help you smooth out those patching requirements and ease the burden of that mad scramble in order to get something out the door.

[Paul] (13:58)

Now, coming back to supply chains, which you touched upon, Joe, which are ever more complex, not just for embedded devices, but for everybody. Hemanth, this does seem to be a real sea change for the automotive industry because a lot of the software that you get in cars these days is pretty much everything you get on your mobile phone. Yeah. Plus all the stuff that goes into the embedded devices.

So it seems like you have the worst of both worlds. How do you stay on top of that?

[Hemanth] (14:31)

Yeah, and I think Joe talked about it a little bit. You know, I think in the automotive sector of connected vehicles and just in general, systems build materials. SBOM plays a big role from the third-party risk side. You do have to vet your vendors, the people that are giving you components inside the vehicle. Let’s say one of them has a cyberattack. It is still your job to making sure that the people that are riding or driving those vehicles are responsibly acknowledged that these type of incidents are occurring.

And I think it’s also up to the company to move on and see what would be the better secure supplier. I think this plays a big role, especially with Software Bills of Materials, right? Those are kind of your ingredients. As you look at a cereal box, you see the different ingredients on the back. Same thing applies here when you’re looking at Software Bills of Materials. Third-party risk is going to be important. At the end of the day, I think a lot of these companies need to focus on third-party risk because we’ve seen a lot of supply chain cybersecurity attacks, especially the past two to three years.

And I think this is just a critical time to making sure that you’re doing the vetting process properly and securely.

[Paul] (15:34)

And those supply chain attacks don’t necessarily have to be targeting any industry sector to affect that sector. So the attackers might just be putting some malware out there into the ecosystem to see where it ends up. And then harvesting the concomitant evil from that, the more difficult that environment is to fix if something goes wrong, the more likely it is to attract the next generation of cyberattacks that follow on from that one.

Or they could be simply poisoning the supply chain in the hope of selling on the malware that they’ve implanted to the highest bidder. Whether that’s a cyber criminal who wants to blackmail a fleet manager to keep their cars on the road, or a state-sponsored actor who wants to find out which cars are taking which people where and when and why.

[Hemanth] (16:24)

I think it’s the hole that’s going to get bigger if a threat actor made their way into the supply chain. It’s not just going to focus one industry, Paul. It’s going to focus many other industries. There’s different supply chain companies out there that are not just assisting one company. It’s their entire ecosystem. It can be from automotive to medical to food and beverage, whatever it may be.

[Paul] (16:45)

So maybe we can move on now to what might be considered by some people the elephant in the room. What about AI and machine learning in the automotive industry particularly? How does that benefit and potentially hinder us? What are the defensive and the offensive risks and benefits of that?

[Hemanth] (17:07)

Companies today are using AI right throughout the process. They’re using artificial intelligence to gather data, to make models, to have engineers work faster. From a security side, I’m a big advocate in making sure that AI is being implemented securely. Because at the end of the day, AI is bringing some new risks. We’re looking at model poisoning.

[Paul] (17:28)

So model poisoning would be where you deliberately feed in bogus results. Such as, hey, did you know that some stop signs are triangular, not octagonal? You’re trying to skew, if you like, the statistics that make up the model that you might rely on for determining hazards in real time while driving. Something that dramatic. Is that correct?

[Hemanth] (17:53)

I guess I do want to shift the table a little bit, Paul. I think AI also brings more of a defensive approach. There’s been anomaly detection capabilities for spoofing. There’s been predictive maintenance. There’s also been more of like machine learning driven attack surface mapping. There’s a lot of tools right now from the EDR side that have been implementing AI SOC capabilities for less intervention. From a defensive side, it also brings some good capabilities for connected vehicles.

[Paul] (18:23)

Do you want to say something about how AI might help things like preventative maintenance? I believe train operators really find this because of the very high energies involved and the complexity of doing human inspections, that sometimes they can actually head off trouble at the pass that would have been probably only spotted after something had gone wrong using the old methods. Is that correct?

[Joe] (19:14)

It can be an indicator that something has gone amiss.

[Paul] (19:18)

Yes, that could be a bug or it could be a deliberate attempt to poke knitting needles into the software to make it misbehave with more malevolent intent, couldn’t it?

[Joe] (19:28)

Exactly right. Again, going back to sort of automated testing and your software development process, the more data you can collect in a simulated environment and in a true runtime environment, collecting that data and analyzing, I think, only enhances your ability to have a full perspective on how a connected vehicle or software-defined vehicle is operating. So AI can play a very important role as can AI play a very important role in helping to automate some of the steps in your process to ensure that you are completing them not only in a timely fashion, but in a very consistent fashion over and over and over again.

[Paul] (20:07)

That tends to stifle innovation by making things more formalized, or could it actually set you free to be a little more inventive without harming safety or without trying to sidestep the regulators?

[Joe] (20:21)

Well, I do think over time, there’s even the culture aspects of your software development teams. As your methodologies get more robust and you’re relying on automation, what you end up doing is having a higher bar for security, higher performance on security and safety. But it also then over time improves your overall efficiency and productivity in software development so that you can spend more time on innovation and less time chasing vulnerabilities, chasing security issues, chasing incidents. If you can minimize the incidents and the bugs and the vulnerabilities, that means you can spend more time on innovation and driving new features. For me, if you look at it comprehensively, building security in, having a robust methodology, using automation where appropriate, complying certainly, and leveraging compliance for safety and security in a way that actually boosts your overall methodology so that you can focus on that innovation as much as automating some of these other tasks that don’t necessarily lead to more innovation.

[Paul] (21:28)

Now, Hemanth, I’m conscious of time, so I’d like to finish up by asking you a question which is not directly relevant to automotive security or even to cybersecurity at all if you don’t want it to be. I’m looking for a way of enthusing our listeners who might be interested in getting into cybersecurity or getting better at cybersecurity by learning something from what you do in your spare time. So outside of work, what hobbies and interests do you have that not only help you relax but also perhaps improve your perspective on doing your job better?

[Hemanth] (22:08)

Thank you, Paul. And I think cybersecurity at the end of the day is stressful, especially if an incident is happening. The psychology part of it really plays a big role.

[Paul] (22:17)

Have you heard some of the call recordings of CISOs being called by ransomware scammers for the blackmail demands? So I hear you. I hear you very much. And that’s just for a ransomware attack. In the automotive industry, there could be much more at stake.

[Hemanth] (22:33)

What I like to do my free time, so I’m actually a musician outside of work. I’m actually a violist of the Troy Metro Symphony Orchestra. We have six concerts a year, every Friday night in rehearsal, cyber by day and musician at night cycle. But I also, I’m a big advocate of giving back because security hasn’t been even more important than right now. I think the past 10 years has played a huge role to our environment.

[Paul] (22:37)

Really?

[Hemanth] (22:58)

You know, really helping the future generation of cybersecurity leaders, know, mentorship is going to be critical. And so I serve on different boards and committees at Kettering University. on the alumni board and helping their curriculum out, but also serving as a mentor just across various nonprofits and organizations to really bolster the security ecosystem. 

Right now, the job market might not be the best, but there’s a lot of students out there that want to get into cybersecurity. And so now I’m a resource there that really helps. AI is just taking one part of the ecosystem of technology, but you need cybersecurity if there’s going to be AI. I also serve in office, believe it or not. I used to serve on the city’s planning commission. Now I serve on the city’s redevelopment authority. It’s really philanthropy, volunteering, and music. That’s what I really like to do in my free time.

[Paul] (23:50)

Yes, that saying that cyber security is best played as a team sport, it may be a cliché, but it’s certainly true. It’s quite clear who the good guys are and who the bad guys are. And that’s not a battle that we’re ever going to win all on our own. I’m delighted to hear that you have not only interests, but reinvestment up your sleeve for the hours when you’re not working on cyber security as your day job. 

Joe and Hemanth, thank you so much for your time and for your passion. Hemanth, thank you so much for talking up the community side of this. As you say, the mentorship of others coming along in cybersecurity really is important because it is a super-fast-changing field. So that is a wrap for this episode of Exploited: The Cyber Truth.

[Hemanth] (24:20)

Absolutely.

[Paul] (24:47)

Thanks to everybody who tuned in and listened. If you find this podcast insightful, please subscribe so you know when each new episode drops. Please like and share us on social media as well. Please don’t forget to share us with everybody in your team so they can enjoy Joe and Hemanth’s enthusiasm for this important subject. And remember, everybody, stay ahead of the threat. See you next time.