Einmaliger Penetrationstest vs. kontinuierliche ECU-Security-Tests

Was ist der Unterschied?

Ein einmaliger Penetrationstest beantwortet “Wie sicher ist dieses Steuergerät heute?” Ein Engineer bekommt das Muster, die Dokumentation und ein paar Wochen, findet, was zu finden ist, und schreibt es auf. Der Bericht ist gründlich und unabhängig, und er beschreibt genau eine Firmware-Version an einem Datum. Alles danach, der Fix, der einen Service in der Default Session wieder geöffnet hat, die neue Variante mit anderer Seed/Key-Konfiguration, das Zulieferer-Update, das XCP wieder aktiviert hat, liegt außerhalb seines Wissens.

Kontinuierliches Security-Testen beantwortet “Ist dieses Steuergerät noch so sicher wie damals?” Dieselbe Suite an Prüfungen läuft bei jedem Build oder Release: Sessions und Services, DIDs, SecurityAccess-Zähler und Seed-Zufälligkeit, ein geseedeter Fuzzing-Lauf, DoIP-Routing, SOME/IP-Exposition, IVI-Härtung. Jeder Lauf hinterlässt einen datierten Bericht und eine SARIF-Datei, Risikoakzeptanzen werden übernommen, und eine Regression zeigt sich an dem Tag, an dem sie entsteht. Was es nicht kann, ist denken: Es findet die bekannten Klassen und die Regressionen, nicht den neuen Angriffspfad.

ISO/SAE 21434 Clause 8 beschreibt Schwachstellenanalyse und -management als fortlaufende Aktivitäten über den Lebenszyklus, und UN R155 verlangt vom CSMS des Herstellers, Entwicklung, Produktion und Nachproduktion abzudecken. Ein Bericht von einem Datum ist eine Momentaufnahme darin; die Regelung beschreibt einen Prozess.

Nebeneinander

	Einmaliger Penetrationstest	Kontinuierliche Security-Tests
Findet	Logikfehler, aus der Firmware rekonstruierte Seed/Key-Algorithmen, Bootloader- und Update-Schwächen, verkettete Angriffe über Schnittstellen, alles Neue, auf einer Firmware-Version	Regressionen bei Sessions, Services und DIDs, SecurityAccess-Zählern und Seed-Zufälligkeit, Crashes und Hänger beim Fuzzing, DoIP-Routing und SOME/IP-Exposition, IVI-Härtung, auf jeder Version
Übersieht	Alles nach dem Berichtsdatum; Regressionen; Varianten außerhalb des Scopes	Logik, Kontext, Ketten, Firmware-Interna; alles ohne bekanntes Muster
Wer macht es	Externe oder interne Security Engineers mit Scope und Deadline	Deine Test-Engineers, ausgelöst von der Pipeline oder einem Zeitplan
Prüfstandszeit	Zwei bis sechs Wochen pro Auftrag	Minuten bis Stunden pro Lauf, unbeaufsichtigt, bei jedem Build
Kosten	20.000 bis 45.000 Euro pro Steuergerät, typische Spanne für Deutschland und die EU, kein Angebot	Lizenz pro getesteter Komponente, Preis auf Anfrage; der Prüfstand, den du schon hast
Passt in den Release-Zyklus	Nein, er ist ein Meilenstein: pro Plattformgeneration, vor SOP, nach großen Änderungen	Ja, dafür ist es da
Verlangt von	ISO/SAE 21434 Clause 11 [RQ-11-01] nennt Penetrationstests für die Validierung; OEM-Anforderungskataloge	ISO/SAE 21434 Clause 8 fortlaufende Aktivitäten und Clause 10.4.2 [RC-10-12]; UN R155 CSMS über den Lebenszyklus; UN R156 für jedes Software-Update
Ergebnis	Ein Bericht mit Methode, Findings, Reproduktion, Schweregrad und Fixes; Debrief und Retest	Datierte Scan-Historie, PDF und SARIF pro Lauf, ein Fix Plan mit Status über Läufe hinweg, JUnit-XML im Build

Nimm einen einmaligen Penetrationstest, wenn

• die Plattform neu ist oder sich grundlegend geändert hat: neuer Mikrocontroller, neuer Bootloader, erste Ethernet-Schnittstelle, neues Security-Konzept. Jemand muss sie verstehen, bevor eine Suite sie schützen kann.
• die Validierung ansteht. Vor SOP und für die Typgenehmigungsakte ist ein unabhängiger Test mit benanntem Tester das, was Clause 11 und die meisten OEM-Anforderungskataloge meinen.
• das Risiko in Logik und Design liegt: Wer darf welches Level entsperren, wem vertraut der Update-Pfad, wie routet das Gateway. Automatisierung weiß nicht, was erlaubt sein soll.
• du einen Verdacht hast, der einen Menschen braucht: eine seltsame Routine, ein Diagnoseservice, der sich je Variante anders verhält, ein Seed, der zufällig aussieht, es aber vielleicht nicht ist.

Nimm kontinuierliche Tests, wenn

• das Steuergerät mehr als einmal freigegeben wird. Ab der zweiten Firmware-Version ist ein Bericht über die erste Geschichte, und jemand muss prüfen, ob die Fixes gehalten haben.
• viele Varianten eine Plattform teilen. Dieselbe Suite über alle laufen zu lassen findet die eine, bei der ein Zulieferer die Programming Session offen gelassen hat.
• Nachweise nachvollziehbar sein müssen. Ein Assessor, der fragt “Was habt ihr auf dieser Version getestet, und was ist aus den Findings geworden”, bekommt die Antwort aus Scan-Historie, SARIF und einem Fix Plan mit Status, nicht aus einem PDF mit dem Datum vom letzten Jahr.
• du ein Gate in der Pipeline willst: Build brechen, wenn der Risiko-Score eine Schwelle überschreitet, mit JUnit-XML dort, wo die Build-Ergebnisse ohnehin liegen.
• niemand im Team Security-Spezialist ist. Eine Suite, die Test-Engineers aus einem Dashboard fahren, ist der Weg, auf dem die Prüfungen überhaupt stattfinden.

Beides zusammen

Das Muster, das funktioniert, ist ein tiefer Test pro Plattformgeneration und kontinuierliches Testen dazwischen. Der Pentest setzt die Basis und findet, was Tools nicht können; die kontinuierliche Suite macht aus den Pentest-Findings Tests, die bei jedem Release laufen, und hält neue Regressionen draußen. Wenn der nächste Pentest ansteht, bekommt der Tester die Historie und steckt die Tage dorthin, wo sie zählen. Der Bericht hört auf abzulaufen, weil der Prozess darum herum es nicht tut.

AutoST ist die kontinuierliche Hälfte. Es fährt die wiederholbaren Prüfungen bei jedem Build über API oder Bamboo-Plugin, führt die datierte Historie und exportiert PDF und SARIF; die Penetrationstester von Zyberum sind die andere Hälfte, und wir behaupten nicht, das Produkt könne deren Arbeit übernehmen. Wird ein Steuergerät einmal freigegeben und nie aktualisiert, reicht ein einzelner Pentest, und kontinuierliches Testen braucht dafür niemand.