Latest / Cybersecurity Under Pressure. Real Attacks, Real Lessons / Automotive IDPS, VSOC and PSIRT: From Alert to Response

Transcript

Automotive IDPS, VSOC and PSIRT: From Alert to Response · Cybersecurity Under Pressure. Real Attacks, Real Lessons

0:47
Guten Morgen to our friends in Germany, Welcome to
0:49
cybersecurity, under pressure, real attacks, real lessons.
0:53
Today is Wednesday, June 17th, 2026.
0:56
And man, let me tell you, it really feels like a Wednesday
0:59
today. Like absolute peak midweek
1:01
exhaustion. If you've ever wondered how OT
1:03
security remote access actually works under the hood, today is
1:07
your day. Because right now, the most
1:10
dangerous point of entry into your vehicle isn't, you know, a
1:13
smash window or a picked lock. No, definitely not.
1:16
It is the electric charging cable you casually plug in at
1:19
the grocery store or the over the air updates silently
1:23
downloading while you sleep. So today we are tearing apart
1:28
the architecture of modern automotive systems.
1:30
Yeah, and like I said, I am running on about four hours of
1:32
sleep and far too much stale office coffee, mostly because
1:36
talking about these cascading systemic architectural failures
1:40
just, well, it keeps me up at night, honestly.
1:42
You and the rest of the security engineering industry, right?
1:44
It really is the perfect mood for digging into the 2026
1:47
reality. Check.
1:47
Oh, absolutely. We have the new data from the
1:50
Upstream and Vicone reports sitting right in front of us.
1:53
And looking at these numbers, I mean, leak doesn't even quite
1:57
cover it. For a long time we've thought of
2:00
cars as these isolated rolling metal boxes, but looking at this
2:05
data, the landscape has completely fractured.
2:08
Yeah, fractured is the polite word.
2:10
I mean, eviscerated might be a little closer to the truth.
2:13
The upstream researchers looked at hundreds of publicly reported
2:16
automotive and smart mobility incidents from just the last
2:19
year. Right?
2:20
And what we're seeing is that AI is fundamentally reshaping the
2:24
attack surface in real time. Like we aren't just dealing with
2:27
static scripts anymore. We aren't looking at some hacker
2:30
sitting in a hoodie manually probing a firewall.
2:32
So what are we looking? At we're looking at generative
2:34
AI and large language models orchestrating dynamic, context
2:38
aware attack paths. It's wild.
2:41
Wait, let me make sure I understand how that actually
2:43
changes the game for a physical vehicle because usually when
2:46
people hear AI hacking they think of, I don't know, deep
2:48
fakes or phishing emails. How does an LLM orchestrate an
2:52
attack on a car? It changes the speed and the
2:55
adaptability, really, of the reconnaissance phase.
2:57
Imagine an attacker wants to find a vulnerability in a cloud
3:00
platform that manages remote engine starts for a fleet of
3:05
rental cars. OK, I'm.
3:06
Picturing it. In the past, they would manually
3:08
poke at API endpoints, get an error message, analyze the error
3:12
and try again. It took days or weeks.
3:15
Now they feed the API documentation or even just the
3:18
raw network responses into a specialized large language
3:21
model. And the AI just does the heavy.
3:23
Lifting exactly. The AI instantly maps out the
3:26
logic flaws, generate thousands of highly specific context aware
3:30
payloads, and tests them simultaneously.
3:33
It adapts to the defense mechanisms on the fly.
3:35
Oh wow. It's actively evolving as it
3:37
probes environments across vehicles, cloud platforms and
3:40
back end APIs. That entirely explains why the
3:43
success rate they're having is just staggering right now,
3:45
because looking at the Vicone data, ransomware incidents have
3:48
literally doubled since 2024. Yep, doubled.
3:50
They now account for 44% of all reported automotive cyber
3:54
incidents. Almost half of everything
3:56
hitting your desk is ransom related.
3:58
Which is terrifying. But it's not just the frequency,
4:00
it's the scale, right? Like 61% of these incidents have
4:04
the potential to impact thousands, if not millions of
4:07
mobility assets simultaneously. Yeah, 20% are already classified
4:11
as massive scale events. Which is exactly why I am so
4:15
exhausted today. It is the complete
4:17
industrialization of cybercrime. Like 71% of these incidents are
4:23
attributed directly to well organized Black Hat threat
4:26
actors. And that's up from what, 65%
4:29
just a couple of years? Ago, right?
4:30
Exactly. They are treating the deep and
4:32
dark web like a highly efficient corporate supply chain.
4:36
You have different groups specializing in different parts
4:38
of the attack. That was divided labor.
4:40
Oh, completely. One group trades the initial
4:42
access, another operationalizes the ransomware campaign on
4:45
specialized forums, and a third exploits the back end systems.
4:48
The Vicone report called this the over overlap era and
4:51
honestly it is the absolute bane of my existence right now.
4:54
OK, let's unpack that term, the overlap era.
4:58
What does that actually mean for the physical architecture of a
5:01
modern vehicle? Because to you listening right
5:05
now, driving to work, your car probably just feels like a
5:08
steering wheel, some pedals, and a touch screen.
5:10
Right, So let's look at the old governance model. 10 years ago,
5:13
the industry managed risk as if digital domains were entirely
5:17
separate kingdoms. Separate kingdoms, OK.
5:20
Had your enterprise IT over here, so the corporate servers,
5:24
the HR databases, you had your off board cloud systems there,
5:27
the servers that process navigation data and then you had
5:30
the in vehicle systems, the actual computers inside the car
5:34
isolated somewhere. Else like waterproof
5:36
compartments on a submarine, if one floods, the others are
5:39
totally. Fine, that's a great way to put
5:41
it. But the overlap error means that
5:42
those bulkheads have been removed.
5:44
The domains have converged because consumers demanded
5:47
seamless integration. Right, everybody wants their
5:49
stuff connected. Exactly.
5:51
You want your phone to unlock your car, your car to talk to
5:53
your smart home, and your dealership to diagnose engine
5:56
trouble remotely over the air. Because of that, connectivity
6:00
attacks no longer respect those old boundaries.
6:03
That just flow right through, yeah.
6:05
A single incident now routinely spans enterprise.
6:08
IT jumps to the off board cloud services and pushes straight
6:12
down into the in vehicle systems all at the exact same time.
6:15
Which sounds like an organizational nightmare.
6:18
It is a technology has converged, but organizational
6:22
accountability is just entirely fractured.
6:24
The IT guys think the vehicle guys are handling it, the
6:27
vehicle guys think the cloud guys are handling it, and the
6:29
attacker just walks right through the middle.
6:31
And the impact numbers show that shift really clearly. 33% of
6:36
cyber risks now directly impact the driver experience.
6:40
It is no longer just about some dealership database getting
6:43
breached and credit card numbers leaking.
6:45
We are talking about operational paralysis.
6:48
Yes, attackers are moving upward in the vehicle architecture into
6:53
user facing integration layers. Nearly 40% of observed attacks
6:58
target in vehicle systems directly.
7:00
So what does that actually look like for the person sitting in
7:02
the driver's seat? I mean, we aren't just talking
7:04
about the radio station changing by itself.
7:06
No, no, we are talking about total loss of utility.
7:09
The infotainment system locks up and displays a ransom note.
7:13
The vehicle refuses to start because the immobilizer is
7:16
locked down by a malicious command.
7:18
Oh. Jeez.
7:19
The remote features like unlocking the doors or turning
7:22
on the heater are just dead. Or even worse, the vehicles
7:25
battery management system is manipulated so it refuses to
7:28
charge. And because of the overlap era,
7:30
this doesn't just happen to 1 car in a driveway.
7:32
Exactly. When an over the air update
7:34
server is breached, that centralized trust means one
7:38
failure impacts entire fleets at scale.
7:41
It turns what used to be a localized IT headache into a
7:44
massive boardroom crisis and a mass recall situation overnight.
7:48
To really understand these massive ecosystem events, we
7:51
need to stop looking at the cloud and look at the physical
7:54
entry points. How do these threat actors
7:57
actually cross the bridge from the Internet into the physical
7:59
vehicle network to 'cause this kind of chaos?
8:03
Puente on three podcasts. Esto connecta directamente con
8:06
lo que cubieron and the wire transfer Las mana pasada El
8:09
mismo Atta cante otro sector. Wait.
8:12
I love that connection because it's the exact same methodology,
8:15
just a entirely different target.
8:18
In banking, they target the payment gateway.
8:20
In automotive, the primary boundary we have to look at is
8:23
the telematics control unit, the TCU.
8:25
OK, let's breakdown the TCU for the listener.
8:27
What is it? The TCU is a piece of hardware
8:30
that sits right on the edge of the vehicle's internal network.
8:33
It is the literal bridge between the internal highly sensitive
8:36
computers running the car, which we call ECU's or electronic
8:39
control units, and the external chaotic world of the Internet.
8:43
So it's managing all the wireless stuff.
8:44
Right, it manages the cellular communication, the 5G
8:47
connection, the GPS or remote diagnostics and the over the air
8:51
or OTA updates. So it's.
8:53
Basically, the car's smartphone router.
8:55
Exactly that. And if you run a stride threat
8:58
model, which is just an engineering framework to
9:00
identify security threats like spoofing, tampering, repeating
9:03
deviation and so on, if you run that on the TCU interfaces, the
9:07
high impact threats are absolutely terrifying.
9:10
What are we looking at specifically?
9:11
You are looking at the potential for remote code execution
9:14
directly through the cellular stacks.
9:17
If an attacker finds a flaw in how the TCU parses incoming
9:21
cellular data, they can execute their own malicious code right
9:24
on that device, completely bypassing any external
9:27
firewalls. And once they're inside the TCU,
9:29
they have access to the internal network.
9:32
Which brings us to things like the OBD 2 bridge.
9:35
For anyone who doesn't know, the OBD 2 port is that little plug
9:37
under your steering wheel. When your check engine light
9:40
comes on, your mechanic plugs a diagnostic scanner into that
9:43
port to read the error codes. But if an attacker compromises
9:47
the TC, they can misuse that diagnostic bridge digitally.
9:50
Right. Yes, exactly.
9:51
They don't even need to be in the car, they can just start
9:53
injecting malicious can messages straight into the powertrain or
9:57
the body control modules. Right.
9:59
And let's explain what that means because the CAN bus, the
10:02
controller area network is really the most critical part of
10:05
this entire system. Think of the CAN bus as the car
10:08
spinal cord. OK.
10:09
The spinal. Cord.
10:10
It is the central nervous system that allows the brakes to talk
10:13
to the engine or the steering wheel to talk to the
10:15
transmission. Everything relies on it and.
10:17
From what I understand, the CAN bus was designed back in the
10:20
1980s. It was built to save physical
10:22
weight by reducing wiring. It was never designed with
10:25
cybersecurity in mind at all. That's the truly terrifying
10:29
part. By default the CAN bus has 0
10:32
authentication. None.
10:33
Wait. Really, none at all.
10:35
None. If a message is on the CAN bus,
10:37
the vehicle's computers implicitly trust it.
10:40
If the brakes receive a message that says engage immediately,
10:44
the brakes don't ask for a password, they just engage.
10:47
So the TCU's operation depends heavily on keeping external
10:50
traffic away from that CAN bus. It uses a secure cellular
10:53
identity anchored in a physical SIM or E SIM to authenticate
10:57
with the manufacturer's back end.
10:58
But if they bypass the TCU. If the attacker bypasses the TCU
11:02
protections, they hit that internal spinal cord and that
11:06
brings us to the next layer of defense, which is the boot
11:09
loader. OK, let's explain the boot
11:10
loader. I always think of the boot
11:11
loader like the ultimate bouncer at an exclusive nightclub.
11:14
Huh. I like that.
11:15
Right, because the boot loader is the very first piece of
11:18
software that runs when an electronic control unit powers
11:21
on. It's entire job is to verify the
11:24
security signature of the main application software before
11:28
handing over control and letting the software actually run.
11:31
If the bouncer checks the ID and the ID is fake, it refuses to
11:35
let the software boot up. But if the bouncer is
11:38
compromised or paid off, absolutely anyone gets in and no
11:42
security inside the club matters anymore.
11:44
That is a highly accurate, if kind of depressing, analogy.
11:48
The core risk with the boot loader is what happens when that
11:51
authentication mechanism is bypassed.
11:54
And let me tell you, attackers are incredibly creative here.
11:56
How so? Like what are they doing?
11:58
Sometimes they don't even need to hack the code itself.
12:02
They exploit physical debug ports or insecure recovery modes
12:06
that engineers just left open on the circuit board to execute
12:09
unsigned firmware flashing. They just write over it.
12:11
They just write their own malicious software over the
12:14
legitimate software, Or even worse, they use an OEM build
12:18
pipeline breach to sign their own malicious firmware with the
12:22
manufacturer's actual cryptographic keys.
12:24
So the bouncer thinks the ID is real because the attacker stole
12:28
the machine that literally prints the ID's.
12:31
Exactly. But there's another method that
12:33
is even more fascinating and frankly, much harder to defend
12:36
against. It's called hardware glitching
12:39
or fault injection. Wait, how does glitching
12:41
actually work? That sounds like a video game
12:43
term. You know, like glitching through
12:44
a wall. Literally messing with the
12:46
physical electricity of the microchip.
12:48
So imagine the chip is executing its code line by line.
12:52
It gets to the exact line of code that says check the digital
12:55
signature of this new software. At the exact microsecond the
12:59
chip is running that specific instruction, the attacker
13:01
momentarily drops the voltage going to the chip.
13:04
Just a tiny fraction of second power dip like a.
13:07
Brownout in your house that makes the lights flicker and the
13:10
microwave clock reset? Yes.
13:13
But highly targeted, that momentary voltage drop causes
13:17
the processor to essentially skip an instruction or evaluate
13:20
a false statement as true. It's like turning off the lights
13:24
in a bank vault for half a second just as the guard checks
13:26
your ID, confusing the system into letting you pass by
13:30
glitching the hardware. They bypass the Secure Boot
13:33
signature verification entirely without ever needing the
13:36
cryptographic keys. That is wild.
13:38
And once they are past the bootloader they own the device.
13:41
I read about downgrade attacks too, where they don't even
13:43
bother writing new malware. Oh, rollback attacks, yeah.
13:46
They just flash an older, known, vulnerable version of the
13:49
manufacturer's own firmware back onto the device to reintroduce
13:53
weaknesses you already spent months patching.
13:55
Which is exactly why hardware rollback counters are absolutely
13:58
critical. A hardware rollback counter is a
14:01
physical fuse inside the chip that gets permanently blown
14:04
every time you update to a new major security version.
14:07
Literally destroying a tiny fuse.
14:10
Literally the bootloader checks the fuses and if the software
14:13
version is older than the number of blown fuses, it refuses to
14:17
boot. NHTS AS2022 guidelines on layer
14:21
Protections hammered this exact point home.
14:24
The National Highway Traffic Safety Administration.
14:27
Right, they explicitly called out the need to limit or
14:30
entirely eliminate developer and debugging access in production
14:34
devices. Meaning close the physical ports
14:37
on the circuit boards before you sell the car to a customer.
14:40
Exactly. If there's no operational reason
14:42
for an open IP port or a serial console on a deployed unit
14:46
sitting in a customer's driveway, kill it.
14:48
They also address minimizing the use of global symmetric keys.
14:51
OK, explain symmetric keys for us.
14:53
A symmetric key means the same digital key is used to both lock
14:56
and unlock the system. The danger is using a global
14:59
symmetric. Key because it's shared
15:01
everywhere. Right.
15:02
If a dealership diagnostic tool uses a single master symmetric
15:06
key to authenticate with the EC use across half a million
15:09
vehicles, and someone reverse engineers that single diagnostic
15:13
tool, the entire fleet of half a million vehicles is instantly
15:17
compromised. So we've locked down the
15:21
internal software, we've blown the hardware fuses to stop
15:23
rollbacks, we've killed the debug ports.
15:25
But all that internal hardening feels completely useless the
15:28
second the driver physically connects the vehicle to an
15:32
untrusted external power source. Yeah, the charging cables.
15:35
Right, that brings us to an attack surface that feels like
15:38
it's being widely ignored. The EV charging cable.
15:41
The charging infrastructure. This is where my blood pressure
15:44
really spikes. People look at an EV charging
15:47
cable and they just see a heavy duty power cord.
15:49
They think it's like plugging in a toaster.
15:50
Sure, just moving electricity. But they don't realize it is a
15:53
live, highly complex data communication interface.
15:57
Imagine you just plug your EV into a public charger at a
16:00
grocery store parking lot. You think you're just
16:03
transferring electricity, but before a single Volt moves, your
16:06
car is secretly having a complex digital handshake with that
16:10
charger, right? It is entirely within the scope
16:12
of ISO 21434, which is the massive international standard
16:17
for automotive cybersecurity because the charging port is an
16:20
EE communication battery, electronic and electrical.
16:23
So what's happening during that handshake?
16:25
Before any energy transfers, the vehicle and the charging station
16:29
engage in what we call vehicle to grid or V2G communication.
16:34
They are exchanging identity capabilities and billing
16:38
parameters. Like handing over a credit card.
16:40
Basically the vehicle presents a contract certificate which is
16:44
like a digital passport saying I am this specific car attached to
16:47
this specific billing account. The charger presents its own
16:50
credentials saying I am a legitimate charging station
16:52
operated by this network and they have to establish mutual
16:55
authentication. Mutual TLS 1.3 right?
16:58
Transport Layer Security, the same encryption protocol that
17:01
protects your credit card when you buy something on a website.
17:04
Exactly. Both sides have to prove they
17:06
are who they say they are and then they create an encrypted
17:09
tunnel for all the data that follows.
17:11
But if that mutual TLS 1.3 isn't implemented properly.
17:15
What happens? If the manufacturer took
17:17
shortcuts to make the handshake happen faster, this session is
17:21
wide open. And what can an attacker
17:23
actually do? It's just a charger.
17:25
This session is wide open and the consequences are severe.
17:29
Attackers can set up fake charging stations with
17:31
fraudulent certificates to impersonate legitimate
17:34
infrastructure. Like a digital skimmer on a gas
17:37
pump. Exactly like a gas pump skimmer,
17:39
but much, much smarter. They could steal the vehicle's
17:42
contract certificate from accessible memory if the
17:45
manufacturer didn't store it inside a dedicated hardware
17:48
security module. Oh, and then they just steal
17:50
your electricity. Once they have your vehicle's
17:52
digital passport, they can clone it and charge their own fleets
17:56
of vehicles on your dime. Energy theft, but furthermore
17:59
they can execute man in the middle attacks to alter the
18:02
charging parameters mid session. Which means they could damage
18:04
the battery. They can tell the cars battery
18:07
management system to overcharge entirely, bypassing safety
18:10
limits which can physically damage the battery or even cause
18:14
thermal runaway. So a fire.
18:17
Potentially, yes. It is a live high voltage attack
18:20
surface sitting entirely unmonitored in public parking
18:23
lots. OK, let's step back and look at
18:25
the big picture here, because this is where my brain starts to
18:28
melt. You have the TCU's handling
18:30
cellular data, the boot loaders managing internal software, the
18:34
EE boundaries on the charging ports handling VDG
18:38
communications. It's a lot.
18:40
And knowing that all of these parts come from completely
18:42
different vendors, this sounds like an absolute organizational
18:46
nightmare. How do you even begin to secure
18:49
a vehicle when the parts are built by dozens of different
18:52
companies scattered across the globe?
18:53
You're touching on the exact reason my hair is turning Gray.
18:57
A modern vehicle doesn't have one or two software suppliers.
19:00
It is not like Apple building an iPhone where they control the
19:03
whole ecosystem from top to bottom.
19:05
Right, they don't make everything in house.
19:07
Not even close. A modern car has 20 to 40
19:10
different primary suppliers. You have Bosch building one
19:13
part, Continental building another, Denso building a third,
19:17
and each of them is writing their own software stack,
19:19
implementing their own hardware, using their own subcontractors.
19:22
So it's a massive tangled web of code.
19:25
It's a supply chain labyrinth. If just one Tier 2 supplier, a
19:30
company that makes a tiny subcomponent for the company
19:33
that makes the infotainment system.
19:35
If that Pier 2 supplier leaves a debug port open on a tertiary
19:38
ECU, the attacker uses that as a beachhead.
19:42
Just one forgotten door. They get in through that
19:44
forgotten open door, move laterally through the vehicle
19:46
central gateway, and suddenly the entire car is compromised
19:50
because of the supplier nobody even knew was in the software
19:52
bill of material. So how does the industry
19:54
actually manage that? You can't just operate on a
19:57
gentleman's agreement. You can't just shake hands and
19:59
trust that the supplier secured their code.
20:01
Oh, you don't operate on trust. You manage it with heavy,
20:05
relentless, unforgiving bureaucracy.
20:07
Specifically, you manage it through ISA 21434, clause 7.
20:11
Which dictates what exactly? Clause 7 dictates distributed
20:15
cybersecurity activities. This is the legal and
20:18
engineering framework for how automakers and suppliers
20:21
interact. This is where cybersecurity
20:23
interface agreements, or Cias, come into play.
20:27
So ACIA is a contract? A legally binding document that
20:30
explicitly maps out every single cybersecurity activity and
20:34
allocates responsibility between the OEM, the original equipment
20:37
manufacturer like Ford or Toyota, and the supplier.
20:41
So you can't just put a single line in a purchasing contract
20:44
that says supplier agrees to make the parts secure.
20:46
If you just write a vague contract that says supplier
20:49
shall ensure cybersecurity, you're guaranteeing a failed
20:52
compliance on it, and you were basically rolling out the red
20:55
carpet for an eventual catastrophic incident.
20:58
ACIA forces them to put specific names, e-mail addresses, and
21:02
concrete processes on paper. How detailed does that get?
21:05
Give me an example of what's in ACIA.
21:06
It gets down to the microscopic level.
21:08
Engineering teams build what's called a racic matrix RASIC.
21:12
It stands for Responsible Accountable Supports Informed
21:16
Consultant. Racic.
21:17
For every single security task, you assign one of those roles to
21:20
the OEM and one to the supplier. You have to explicitly name the
21:25
cybersecurity points of contact on both sides.
21:28
You map out exactly who handles the Terra.
21:30
The threat analysis and risk assessment.
21:32
Right. Who handles the incident
21:34
response if a flaw is found? Who is accountable for
21:36
vulnerability handling if a zero day drops on a Friday night?
21:40
What are the exact service level agreements for containment?
21:44
Does the supplier have to fix it right away?
21:46
Does the supplier have 24 hours to provide a patch or 72 hours?
21:51
All of this has to be negotiated and signed before a single line
21:54
of code is written. OK, let's talk about those
21:57
vulnerabilities, because there is a terrifying statistic in the
22:00
Vicone report regarding visibility, and honestly, it
22:03
completely undermines all this beautiful paperwork you just
22:05
described. I know exactly the stat you
22:07
mean. We rely so heavily on CV ES in
22:10
this industry. CV ES stands for Common
22:12
Vulnerabilities and exposures. It is the global database of
22:15
known software flaws. According to the report, 89% of
22:18
automotive vulnerabilities are visible through that CVE system.
22:22
Right, which sounds great until you do the math on the
22:24
remainder. Exactly.
22:26
That leaves an 11% blind spot. 11% of cyber risk lives entirely
22:30
outside the CVE system. That means one in 10
22:32
vulnerabilities that could crash a car isn't documented anywhere
22:36
that defenders can see it. And that 11% is where the real
22:39
nightmare fuel lives. These are 0 days vulnerabilities
22:43
that the software vendor has zero days to fix because they
22:46
don't know about them yet, but attackers do.
22:49
They're discovered the independent research, internal
22:51
penetration testing, or worse, they are actively being traded
22:55
on underground forums. The Vacone report noted 174 zero
23:01
day vulnerabilities uncovered just through the Punuan
23:04
automotive competitions recently.
23:06
Junto is that hacking competition where they literally
23:08
put a car on a stage and pay security researchers hundreds of
23:12
thousands of dollars if they can hack it right.
23:14
Yes, and they succeed constantly.
23:16
These zero day risks are sitting in production environments
23:18
embedded in vehicles driving on the highway right now, and the
23:21
standard governance systems are completely blind to them because
23:24
they aren't on a neat little CVE spreadsheet.
23:26
OK, but wait, if a vulnerability isn't in a database, how can an
23:30
automaker's Tara process their risk assessment even account for
23:34
it? If you don't know the flaw
23:36
exists, aren't you just guessing at the risk?
23:39
This is the exact core issue identified in the Chalmers Gap
23:42
Analysis research paper we reviewed.
23:45
The paper pointed out a fundamental flaw in how the
23:48
automotive industry handles risk.
23:49
Which is. Historically, engineers would do
23:52
Atara once during the concept phase of designing the car.
23:56
They would map out the theoretical threats, calculate
23:59
the risk, build the defenses and then put the Tara document in a
24:02
drawer for five years while the car was manufactured.
24:05
Which is completely useless the second a new zero day is
24:08
discovered. Precisely, you can't just do a
24:10
Tara once. Tar management has to be a
24:12
continuous living process. Wait, no, let me step back and
24:15
explain how it actually functions in practice because
24:17
it's deeply complex. When a zero day is discovered,
24:20
the vulnerability usually boils down to a single line of bad
24:24
code at a sub component level. Like say a buffer overflow in a
24:28
Bluetooth driver written by a tier 3 supplier.
24:31
You have to be able to mathematically track how that
24:33
single line of bad supplier code propagates upward through the
24:37
vehicles abstraction layers to understand the systemic threat
24:41
to the whole car. OK, let me try an analogy.
24:43
It's like tracking a hairline fracture in a single steel bolt
24:47
and calculating how that one tiny flaw shifts the weight
24:50
distribution all the way up to realizing that the entire
24:53
suspension bridge is going to collapse in high winds.
24:56
That is a perfect analogy. You need to know that the bolt
24:59
affects the beam, the beam affects the cable, and the cable
25:01
drops the bridge. In automotive software, we call
25:04
those abstraction layers. Makes sense.
25:06
The Bluetooth driver affects the infotainment system.
25:09
The infotainment system is connected to the central
25:11
gateway. The central gateway talks to the
25:13
brakes. The continuous tower management
25:15
process acts as a dynamic risk engine.
25:17
So Tara isn't a static blueprint you put in a drawer.
25:20
It's more like a live GPS for risk.
25:23
The moment a new zero day vulnerability is discovered, or
25:26
a new new attack method is posted on the dark web, it
25:29
recalculates the whole route, telling you exactly which parts
25:32
of the car are suddenly in the crash zone.
25:34
Exactly. When an incident occurs, the
25:37
threat model has to be dynamically recalculated in real
25:40
time. You take the operational
25:42
telemetry from the fleet, the new exposure data from the zero
25:45
day, and you feed it back into the risk computation.
25:48
So you have a real time view. Right.
25:50
That way, the executives can make actual containment
25:52
decisions based on the new reality, not a static
25:55
spreadsheet from three years ago.
25:57
Wow. OK, so the massive stack of
25:59
bureaucracy is signed, the CI as are in place, the continuous tar
26:03
GPS is running and recalculating, the car is out
26:07
there on the highway. But what actually happens when
26:09
the alarm bells ring? Because an anomaly alert popping
26:13
up on an analyst screen doesn't magically stop a hacker from
26:16
taking over the steering wheel. No, it certainly does not.
26:19
There's a quote from one of the engineering playbooks in our
26:21
source stack that I practically have framed in my mind.
26:24
An IDPS alert is not an incident response capability.
26:28
Idps being Intrusion Detection and Prevention system.
26:31
Right, it is just noise. You can have the most advanced
26:34
anomaly detection running on the canvas, flagging every
26:37
suspicious data packet, but if no one knows what to do with
26:40
that data, it is completely useless.
26:43
It's like a smoke detector going off in an empty house.
26:46
The first failure in automotive cybersecurity is almost always
26:49
ownership. When the red light flashes on
26:52
the dashboard in the security center, who actually owns the
26:54
alert? That's where the VSOC comes in,
26:56
right? The vehicle security Operation
26:58
center. How does a VSOC actually differ
27:02
from the standard ITSOC that a company already has running
27:06
their corporate network? Why can't the guys watching the
27:08
e-mail servers just watch the cars too?
27:10
Because the physics of the problem are entirely different.
27:13
An ITSOC is dealing with static infrastructure.
27:16
They are monitoring servers sitting in a climate controlled
27:19
data center where employee laptops connected via VPNs.
27:23
Exactly. If a server gets infected, they
27:25
isolate it from the network. The server doesn't physically
27:27
move. A VSOC is monitoring physical
27:30
two ton kinetic assets moving at 70 mph across different
27:34
geographic regions, experiencing varying cellular latency with
27:38
incredibly complex heterogeneous hardware configurations.
27:42
And the stakes are obviously different.
27:44
Entirely different. The ITSOC cares about data
27:47
exfiltration. Did someone steal our customer
27:49
database and server uptime? The VSOC cares about physical
27:53
safety, kinetic impact, and fleet wide operational
27:56
availability. The VSOC makes mistake.
27:59
People can physically get hurt. So the VSOC gets the alert, the
28:02
smoke detector goes off. What is their exact role
28:05
compared to the engineering teams?
28:07
We have these two acronyms constantly dancing around each
28:10
other in the source material, VSOC and PSIRT.
28:13
Let's breakdown this dance. It is a highly choreographed
28:16
dance and if they step on each other's toes, the response
28:18
fails. The VSOC, the vehicle SoC are
28:21
the tactical first responders. They're doing the 204 seven
28:24
continuous monitoring, the initial triage.
28:26
What does triage look like for a car?
28:28
When an alert fires from a vehicle, they determine the
28:31
immediate scope. Is this happening to 1 car in
28:34
Ohio or 10,000 cars across Europe?
28:37
They execute rapid containment and they do what we call First
28:40
Mile Forensics. First mile forensics How do you
28:42
even do forensics on a car driving down the highway?
28:45
You. Use remote telematics.
28:47
The VSOC secures the logs remotely, They pull the
28:51
telemetry data, grab crash dumps or memory images from the
28:54
vehicle's computer over the cellular connection, and they
28:57
try to rebuild the timeline line of the attack.
28:59
They are the paramedics stabilizing the patient at the
29:02
scene. And then the patient gets handed
29:03
off to the PSID, the product security incident response.
29:06
Team exactly. PSAT are the long term problem
29:09
solvers. They are the surgeons and the
29:11
geneticists. They take that packaged forensic
29:14
evidence from the VSOC and dive into the deep root cause
29:17
analysis. So they tear the malware apart.
29:20
Yes, the reverse engineer the malware, assess the
29:23
vulnerability at the base code level and then orchestrate the
29:26
development of the software patch across all those different
29:28
suppliers we talked about earlier.
29:30
And finally, they manage the long term product life cycle
29:33
changes to ensure this specific vulnerability isn't accidentally
29:37
reintroduced in the next model year.
29:39
But how do they communicate during an active crisis?
29:41
Because if you have a massive ransomware event spreading
29:44
through a fleet, the VSOC is desperately trying to stop the
29:47
bleeding and the PSOT is meticulously trying to sequence
29:50
the DNA of the virus, it seems like their priorities would
29:54
clash. That is exactly why the
29:56
communication has to be a formalized bidirectional flow.
29:59
Can't just be emails back and forth.
30:01
The VSOC sends structured incident summaries directly to
30:04
PSOT. What's in the summaries?
30:06
We're talking raw logs, exact vehicle counts, affected build
30:09
IDs, and provisional severity scores.
30:12
They also send containment notes.
30:14
This is crucial if the VSOC temporarily disabled a back end
30:18
cloud service to stop the attack from spreading.
30:20
PCRT needs to know that mitigation is in place.
30:23
Oh, because otherwise PCRT would be confused.
30:25
Right. Otherwise, PSRT might spend
30:28
hours trying to figure out why the vehicle randomly stopped
30:31
talking to the cloud. And what does PCRT send back
30:34
down to the VSSC? PSRT analyzes the code and sends
30:37
back confirmed vulnerability advisories with final CVSS
30:41
scores. CVSS, the Common Vulnerability
30:45
Scoring System, which is basically the Richter scale for
30:47
software bugs from 1:00 to 10:00.
30:49
OK, so they give them the real threat level.
30:51
They provide specific threat indicators like cryptographic
30:54
hashes of the malware, protocol markers or behavioral heuristics
30:57
so the VSOC can tune their detection rules to spot any
31:00
further exploitation attempts across the rest of the fleet.
31:04
And crucially, PCRT sends deployment milestones.
31:07
Meaning a schedule for the fix. Right as the patch clears lab
31:10
testing and moves to a pilot over the air release, the VSOC
31:13
dials their monitoring up or down based on that schedule.
31:17
They need to know exactly when the cars are getting the cure so
31:19
they can watch for any rejection of the update.
31:21
OK, but let's be realistic here. That bi directional flow sounds
31:26
great in a sterile lab environment or tabletop
31:29
exercise. But what happens out in the real
31:31
world when half a million cars are simultaneously targeted by a
31:35
ransomware group when the pressure is actually on?
31:38
It's pure chaos. I mean, you're talking about
31:41
flashing firmware on half a million cars at once.
31:43
How is that not a recipe for an absolute disaster?
31:46
If a single OTA up update gets corrupted during the download?
31:50
You haven't just contained a hack, you've created a 500,000
31:53
car traffic jam. How do they actually do this
31:55
safely? That is the nightmare scenario
31:57
and that is exactly where the fleet wide incident response
32:00
playbooks come out. The VX Labs engineering team
32:03
documented this perfectly in their research.
32:05
The sheer scale of the automotive problem breaks
32:08
traditional IT response models. Because of the numbers because.
32:10
Of the numbers in the physical reality, if you have to patch a
32:13
fleet of 500,000 vehicles, you cannot just push a big red
32:16
button update them all at once like you would with corporate
32:18
laptops. You have to use staged OTA
32:20
update to roll it out to 1000 cars.
32:22
First you monitor for bricks modules, then 10,000.
32:26
And there are physical constraints, right?
32:28
You can't just update a car anytime.
32:29
Massive physical constraints. You have to check the 12 Volt
32:33
battery levels of every single car before initiating a flash.
32:37
Wait, really? The battery level.
32:39
Yes, if the battery dies in the middle of writing the boot
32:42
loader, that ECU is permanently dead.
32:45
You have to deal with the vehicles stage RAT.
32:48
You have cars that are currently in motion on a highway.
32:51
You cannot reboot an engine control module while someone is
32:54
doing 75 mph in the fast lane. So you have to contain the
32:58
threat without breaking the fleet and without causing a pile
33:01
up. How do you actually isolate A
33:03
compromised car remotely? The VX Labs playbooks outline 4
33:08
strict levels of containment escalating in severity.
33:11
Level 1 is network level containment.
33:13
This is the least disruptive. You execute this at the cloud
33:16
level. You block specific WIC IPS,
33:19
malicious domains, or fraudulent certificate fingerprints at the
33:22
back end servers. You essentially stop the
33:24
compromise vehicle from talking to the attackers command and
33:27
control servers, but the car itself still drives normally.
33:30
The driver doesn't even know it's happening.
33:31
And if the attacker is already fully inside the car and doesn't
33:34
need to talk to the command server if network level isn't
33:37
enough. Then you move up to level 2,
33:39
feature level containment. You remotely disable a specific
33:43
app or service that the attacker is explaining.
33:46
Let's say they are using a vulnerability in the Wi-Fi
33:49
hotspot to pivot into the vehicle.
33:51
You just kill the Wi-Fi. Exactly.
33:54
You send a command to turn off the Wi-Fi hotspot module
33:56
entirely or disable the remote engine start capability while
34:01
leaving the core driving functions intact.
34:03
OK, get a more invasive What's Level 3?
34:05
Level 3 is ECU level containment.
34:07
This is much more aggressive. If a specific computer inside
34:10
the car is heavily compromised and acting erratically, you
34:14
remotely reset that specific component a targeted OTA update,
34:18
forcing it back to a known good factory state.
34:20
Does the car have to be parked for that?
34:22
Yes, the feature provided by that ECU goes completely offline
34:25
for maybe 20 minutes while it flashes.
34:28
You only do this when the car is parked, the engine is off.
34:30
And level 4, the absolute last resort.
34:33
Vehicle level containment. The nuclear option.
34:36
You instruct the vehicle to enter a degraded safe mode.
34:39
It intentionally drops all external connectivity.
34:41
It shuts down the telematics unit, drops the cellular
34:44
connection, kills the navigation, disables all remote
34:47
services it. Just goes dark.
34:49
It essentially air gaps itself from the Internet, but it
34:52
maintains core physical driving functionality.
34:54
Steering, breaking headlights so the user isn't stranded in the
34:58
middle of nowhere. You only pull that trigger if
35:01
there is clear evidence of an active safety threatening
35:03
kinetic attack. Which brings us to the most
35:06
critical point in the entire source stack.
35:09
It is the absolute bedrock of automotive engineering, the
35:12
golden rule of automotive incident response.
35:15
Never take an action that makes the vehicle less safe than the
35:18
attack itself. Exactly.
35:20
Safety engineering has to be in the room, physically or
35:22
virtually, when these VSOC containment decisions are made.
35:26
It cannot override safety. Let's give a concrete example of
35:29
that that because it's a fascinating dilemma.
35:31
Let's say an attacker is executing a CAN injection attack
35:35
and they are flooding the internal network with fake
35:38
messages to create terrifying warning lights on the driver's
35:41
dashboard. OK, I see where you're.
35:42
Going the engine temperature warning is flashing.
35:45
The brake failure light is on. The immediate reflex for an IT
35:49
security guy might be to isolate the compromised component
35:52
sending those fake signals. Right, but if that compromise
35:55
component is the instrument cluster itself, you cannot just
35:58
send a command to disable it. You cannot turn off the screen.
36:01
Because they wouldn't be able to see their speed.
36:03
Because removing the drivers actual visibility into their
36:06
true speed, their fuel levels, and their real warning systems
36:10
while they're driving is infinitely more dangerous than
36:13
the fake alerts the hacker is generating.
36:16
A confused driver is bad. A blind driver is a fatal
36:19
accident. Containment has to be surgical
36:22
and it always defers to the safety.
36:24
Case and while the VSOC is trying to be perfectly surgical
36:28
and the PSRT is trying to sequence the zero day and the
36:32
safety engineers are evaluating the risk is have the regulatory
36:35
agencies breathing down your neck with literal ticking
36:38
clocks. Oh, the legal pressure is
36:40
immense and has completely changed the timeline of incident
36:44
response. Under the European Union's NIS 2
36:47
directive, if you are an automaker running a connected
36:50
fleet, you have a strict 24 hour early warning requirement. 24
36:55
hours from discovery, that is nothing.
36:56
It's a blink of an eye during a crisis and under Units R155, the
37:00
UN regulation for vehicle cybersecurity, you have to
37:04
continually notify the type approval authorities to prove
37:06
your continuous risk management is working.
37:08
So you're writing reports while fighting the fire?
37:11
Plus you have to coordinate with data protection agencies for
37:13
GDPR if personal location data is touched by the breach.
37:17
So picture the scene. The VSOC analysts are staring at
37:21
screams trying to stop a 70 mile per hour moving metal box from
37:24
being hijacked by a generative AI script, and meanwhile the
37:28
corporate legal team is banging on the door demanding a root
37:31
cause analysis for a government compliance filing due in four
37:34
hours. Man, it is just sheer unfiltered
37:38
adrenaline and stress. No wonder you said Wednesday
37:41
feels like a Friday. In this industry.
37:43
Every single day is just managing the absolute brink of
37:46
systemic failure across millions of moving physical endpoints.
37:50
It's not just fixing bugs, it's keeping the physical world from
37:53
crashing. That's the job.
37:54
You build the best architecture you can.
37:56
You lock down the E boundaries, you sign the CI as with your 40
37:59
suppliers, you run the continuous dynamic tower to
38:02
track the zero days. And at the end of the day, you
38:05
just pray your VSOC analysts have enough coffee in their
38:08
system and that plume to own exploit actually drops into the
38:12
wild. That's all for this episode of
38:14
Cybersecurity Under Pressure. Real attacks, real lessons.
38:17
Check your PLCS, check your logs, and maybe, just maybe
38:20
question whether that air gap is really an air gap.
38:23
See you in the next chapter.