How Building a VSOC for an EV Fleet Changed the Way We Build Product Cybersecurity Monitoring

A pure-play EV OEM asked us to stand up a VSOC, and we built the one it asked for. We onboarded its vehicle and cloud logs and wrote detection tuned to its platform. At its request, we ran monitoring nearly 24/7. The system met the UN R155 requirement and held up in audit. For the daily work of keeping those vehicles secure, however, it mostly added alerts and cost.

That early engagement changed the order we build monitoring in. We now choose the use cases worth monitoring first, then check the data against them, and every signal the data is missing becomes a requirement for the engineering team.

Most of the build was getting the data in order

The OEM's logs sat in cloud and vehicle systems, each in its own format, with no common schema and no single place to see vehicle security data. Normalizing those sources and onboarding them into the SIEM was the hardest part of the engagement, and it had to be done. We drew a line between general product-engineering telemetry and security-relevant events and set a security data schema on that line. Detection tuned to the platform was written on top of it.

Detection written from the data alone made noise

Although our use-case database already had useful alerts, the OEM's security team could only use existing data so every rule we wrote came from those logs. The monitoring therefore covered whatever the fleet already recorded, and other use cases that didn't have data coverage were dropped.

Furthermore, nobody at the leadership level agreed on incident response and the security team had little actions they could take on the fleet level. As a result, rules fired on events nobody at the business level would act on, and the alerts landed on a cyber team of a few people who already owned everything from TARA to security specifications. Each alert took time that team needed for the rest of its work.

We now start from the use cases worth a response

The starting list comes from our own monitoring use-case library, built up over this engagement and others like it. It covers the basic use cases most fleets need, and it opens the conversation about incident response and mitigation timelines early. A TARA and the vehicle maker's vulnerability management then decide which of those use cases get detection and a response plan.

Some use cases do not make the cut for immediate alerts and instead become part of thresholds and data collection (things that would impact warranty or potential milage blocking are good examples). If the vehicle maker cannot reach that vehicle and respond in time, or if it's not safety critical, an immediate alert read by a human at 2:00 am does little good. Many use cases forward to the vulnerability management side of the house (and/or the PSIRT), which can be fixed in an update (how the VSOC and PSIRT divide the work).

That still counts as monitoring. R155 paragraph 7.2.2.2(g) asks for "the processes used to monitor for, detect and respond to cyber-attacks, cyber threats and vulnerabilities on vehicle types". A PSIRT that takes in reports through coordinated vulnerability disclosure is one of those processes (where a PSIRT starts).

Then the data is checked against them, and gaps become requirements

The same data work still happens, now aimed at named use cases. For each one, we compare the signals it needs with what the fleet logs today. A missing signal becomes a functional requirement for the engineering team, and the list of requirements becomes a roadmap for monitoring what matters most.

Even today, newer vehicle and other cyber-physical system makers still ask us for the same kind of P/V-SOC this OEM asked for. If you are scoping one for your own fleet, talk to us. We will start from your maturity level to see what 'monitoring' would actually meet your compliance needs and move the needle to a more secure product. We can even help with the RFI before you send out requests to other vendors for noise management alone.

‍