Rebuilding a PC-Based Vehicle Diagnostic Tool as a Least-Privilege Cloud Service

A vehicle diagnostic application is one of the most privileged pieces of software an OEM writes. It authenticates to the vehicle and issues commands across systems a driver never touches. Ship it as a compiled program that runs on a technician's laptop, and the authentication logic and the command set ship with it, onto a machine the OEM does not control.

That was the problem a top-5 global multi-brand automotive OEM brought us after one of its diagnostic tools was exploited. The fix started as one project and grew into seven service lines, delivered for less than a tenth of what a traditional consulting firm had bid for the same outcome. It became the foundation of the service portfolio we run today and the reason we later built VSEC. Here is that engagement, with the customer anonymized.

Why a PC-based diagnostic tool is vulnerable by design

A compiled binary on a local machine belongs to whoever has the machine. Reverse-engineer it, read how the tool proves to the vehicle that it is allowed to talk, and reproduce that handshake in your own code. Every capability the OEM built for diagnosing the car is then available to an attacker who wrote none of it. They never had to learn the vehicle's protocols. The tool taught them.

"Vulnerable by design" is how we described it to the customer. It describes the architecture, not the people who built it.

The organizational split made it harder, and it is worth naming because the same shape shows up elsewhere. The diagnostic tool did not report to IT Security. It sat in the a different division, outside the security team's scope (who only dealt with IT-related security anyway), and that team had its own fires. The most privileged interface to the vehicle was owned by a group not chartered to secure it and secured by a group that could not see or understand it.

A least-privilege architecture for diagnostic tooling

We migrated the critical diagnostic infrastructure from the local application to a cloud architecture built on least privilege.

The difference shows up in what sits on the technician's machine. In the PC-based version, the machine holds the binary, and with it the authentication logic and the full command set, whether the person using it needs any of that or not. In the cloud version, the machine holds a thin client. A user receives only the commands required for the job in front of them, issued by infrastructure they do not control and cannot decompile. Nothing privileged lands on the endpoint, so there is nothing privileged to pull off it.

That architecture has held up. Years later it is still ahead of most OEM diagnostic systems in the field.

Assess it, watch it, and be able to stop it

A rebuild closes the door that was open. It does not tell you when someone starts working on the next one. Three capabilities grew on top of it, and each does a different job.

Ongoing security assessment: continuous testing against the new system, to find holes before anyone outside found them.

A vehicle security operation center, whose purpose is operational awareness of the security of vehicles and vehicle systems in the field. Here that meant watching the diagnostic infrastructure for signs of active exploitation.

Incident response: cutting off an attacker while they are still working.

That third capability is the exception rather than the rule, and the reason is worth stating. You cannot isolate a vehicle in the field. Disabling a car at highway speed or a machine mid-operation is a safety incident rather than containment, and response for a fielded product runs on engineering timelines measured in months. What the rebuild produced was a target the OEM operates. The diagnostic infrastructure is server-side, so a session can be killed and an account locked while the attack (or developing attacks in this case) is in progress. Moving the privileged logic off the endpoint is what made real-time response possible here, and it is also why the same capability does not transfer to the vehicle itself.

Why it cost less than a tenth of the consulting bid

A traditional consulting firm had bid this work at more than ten times what we delivered it for, for the same outcome.

That gap was not a discount. It came from a different shape of engagement. Rather than staffing up multiple teams of people and billing hours against a large statement of work, we ran it week by week, working with the actual engineering teams as colleagues, not a consultant to analyze, report, and advise. We did the work that needed to be done. No one bought seven service lines up front. They bought the solution to a problem, watched it work, and bought the next solution when needed. What compounded out of that engagement was: Security Engineering as a Service, VSOC build and deploy, VSOC analyst operations, VSOC incident response, targeted cybersecurity assessment and consulting, penetration assessment, and regression testing, all some of our strongest and most mature services today (except TARA which came from similar problems at different OEMs).

We did not walk in with a thesis about small teams and specialized technology beating large consulting firms on cost. This engagement is where we got one, and the incentive it created is the direct reason we built VSEC, which started as tools we needed to scale our own operations.

‍

If your diagnostic tooling puts privileged logic on an endpoint you don't control, talk to us about what it exposes today and what moving it would take.

‍

‍

‍

Related reading: Bridging the Gap: VSOC and PSIRT in Automotive Cybersecurity, Continuous Monitoring Isn't 24/7, Know the "Where" of your Firmware.

‍