ECU-Security-Tests intern vs. externes Prüflabor

Was ist der Unterschied?

Interne Tests heißt: Steuergerät, Prüfstand und Engineer gehören dir. Du entscheidest, wann ein Test läuft, du siehst das Ergebnis am selben Nachmittag, und nichts von Firmware oder Diagnosebeschreibung verlässt das Haus. Die Grenzen sind Expertise und Unabhängigkeit: Dein Team kennt dein Steuergerät, aber vielleicht nicht, was Angreifer mit den Steuergeräten anderer Leute machen, und ein Zulieferer, der sein eigenes Produkt bewertet, ist nicht das, was ein OEM unter Validierung versteht.

Ein externes Prüflabor ist von Haus aus unabhängig. Es bringt Leute mit, die das ganze Jahr Steuergeräte vieler Zulieferer testen, Hardware, die du nicht besitzt (Klimakammern, Busanalysatoren für jeden Transport, Seitenkanal- und Fault-Injection-Aufbauten, wo nötig), und einen Bericht, den OEM oder Assessor als Nachweis Dritter akzeptieren. Die Grenzen sind Zeit und Kosten: Ein Laborauftrag ist ein Projekt mit Scope, Starttermin und Lieferergebnis, und das Steuergerät, das du schickst, ist eine Momentaufnahme. Sechs Wochen später gibt es eine neue Firmware, und der Bericht beschreibt die alte.

Nebeneinander

	Interne Tests	Externes Prüflabor
Findet	Alles, was deine Tools und Leute abdecken, bei jedem Build: Diagnoseoberfläche, SecurityAccess-Schwächen, Robustheit beim Fuzzing, Ethernet-Exposition, IVI-Härtung, Regressionen	Alles, was ein erfahrener Außenstehender an einer Momentaufnahme findet: das oben Genannte plus Schwächen auf Firmware-Ebene, verkettete Angriffe, Hardware-Angriffe, Vergleich mit dem, was andere Zulieferer tun
Übersieht	Blinde Flecken eines Teams, das das Produkt zu gut kennt; die Unabhängigkeit, die ein Assessor für die Validierung will	Regressionen nach dem Bericht; deinen internen Kontext; alles außerhalb von Scope und gebuchten Wochen
Wer macht es	Deine Test- und QA-Engineers, idealerweise mit einem Security-affinen Verantwortlichen	Die Security Engineers des Labors, unter einer Vereinbarung mit Scope und Spielregeln
Prüfstandszeit	Minuten bis Stunden pro Lauf, sobald ein Build fertig ist	Zwei bis sechs Wochen pro Auftrag inklusive Bericht, plus Versand der Muster
Kosten	Prüfstandshardware, die du meist hast, Engineer-Zeit, eine Tool-Lizenz pro Komponente	Projektpreis pro Auftrag; ECU-Penetrationstests typischerweise 20.000 bis 45.000 Euro in Deutschland und der EU, kein Angebot
Passt in den Release-Zyklus	Ja, das ist der Sinn der Sache	Nein; einmal pro Plattformgeneration, vor SOP und nach großen Änderungen
Verlangt von	Die Verifikation nach ISO/SAE 21434 Clause 10.4.2 ist Aufgabe des Zulieferers selbst; das CSMS nach UN R155 verlangt vom Hersteller, Tests entlang der Lieferkette zu steuern	Unabhängigkeit für die Validierung (Clause 11) verlangen viele OEM-Anforderungskataloge und in der Praxis die Assessoren der Typgenehmigung
Ergebnis	Scan-Historie, PDF und SARIF pro Lauf, ein Fix Plan, den deine Engineers abarbeiten	Ein unterschriebener Bericht mit Methode, Findings, Reproduktion und Empfehlungen; Präsentation und Retest

Nimm interne Tests, wenn

• du öfter als einmal im Jahr Firmware freigibst oder ein Steuergerät in mehreren Varianten auslieferst. Jedes Release braucht dieselben Checks, und ein Labor lässt sich nicht jeden Sprint buchen.
• Vertraulichkeit streng ist. ODX- und CDD-Dateien, Vorserien-Firmware und Seed/Key-Material bleiben auf deinen eigenen Servern; nichts muss verschickt oder hochgeladen werden.
• Findings gefixt werden sollen, solange der Entwickler die Änderung noch im Kopf hat. Ein Ergebnis am selben Tag ist mehr wert als ein besseres in sechs Wochen.
• dein Team lernen soll. Engineers, die jede Woche Enumeration fahren und Negative Response Codes lesen, werden zu den Leuten, die das nächste Steuergerät besser entwerfen.
• die Checks wiederholbarer Art sind: Sessions, Services, DIDs, SecurityAccess-Zähler, Fuzzing-Robustheit, DoIP-Routing, SOME/IP-Exposition. Tools können das gut, und ein Labor würde auch Tools nehmen.

Nimm ein externes Prüflabor, wenn

• Unabhängigkeit die Anforderung ist. Der eigene Bericht eines Zulieferers erfüllt selten die Validierungsklausel eines OEM, und ein Assessor für die UN-R155-Typgenehmigung wird fragen, wer getestet hat.
• die Plattform neu ist und intern noch niemand so eine angegriffen hat. Ein erster externer Pentest setzt die Basis, die die interne Suite später schützt.
• du Hardware oder Fähigkeiten brauchst, die du für ein Projekt nicht aufbaust: Firmware-Extraktion aus einem gesperrten Mikrocontroller, Fault Injection, Seitenkanäle, Umwelttests.
• du noch keinen Prüfstand hast. Ein Laborauftrag ist auch ein Weg zu lernen, wie ein Prüfstand für dieses Steuergerät aussehen sollte.

Beides zusammen

Die Kombination, die funktioniert: Ein externes Labor testet jede neue Plattform einmal, tief und unabhängig, vor SOP. Der interne Prüfstand fährt ab dann die wiederholbare Suite bei jedem Build und verhindert, dass die Labor-Findings zurückkommen. Wenn der nächste Laborauftrag ansteht, bekommt der Tester die interne Scan-Historie und steckt die Tage in das, was Automatisierung nicht sehen kann.

AutoST bedient beide Seiten davon. Zulieferer und OEMs fahren es an eigenen Prüfständen; Prüflabore fahren es an den Steuergeräten ihrer Kunden, um den wiederholbaren Teil über Aufträge hinweg gleich zu halten und PDF und SARIF mit dem Bericht zu übergeben. Die Penetrationstester von Zyberum sind in diesem Sinn ein Labor, und wir sagen klar: AutoST ist das Werkzeug für ihren ersten Tag, kein Ersatz für die folgenden Wochen.