Getestet wird bei fast jedem Hersteller. Eine SCA läuft im Build, dazu ein SAST-Werkzeug, ein paar eigene Testfälle vor dem Release, und irgendwo steht ein Verfahren, wer das wann macht. Was fehlt, ist die Zuordnung. Welche dieser Fähigkeiten deckt welche Anforderung ab, und in welcher Tiefe? Im selben Unternehmen sieht die Antwort von Produkt zu Produkt anders aus. Vergleichen lässt sich das nicht, auditieren nur mühsam, und in IEC 62443-Zertifizierungen kostet es regelmäßig Diskussionszeit mit den Prüfern.
Hier setzen die beiden Entwürfe an, die CLC/TC 65X im März 2026 zur Umfrage gestellt hat. Ein Security Test Grade (STG) ist eine definierte Menge von Security Test Modules (STM). Jedes Modul beschreibt eine einzelne Testaktivität mit Ziel, Anforderung, Anwendbarkeitskriterium und festen Bedingungen für PASS und FAIL. EN IEC 62443-4-1:2018/prAA:2026 verankert das Verfahren im Entwicklungsprozess, EN IEC 62443-4-2:2019/prAA:2026 liefert drei Grade und 21 zugeordnete Module für Komponenten.
Der Cyber Resilience Act fordert in Anhang I Teil II Nummer 3, die Sicherheit des Produkts „regelmäßig und wirksam” zu testen und zu überprüfen. Anhang VII Nummer 6 verlangt die Testberichte als Bestandteil der technischen Dokumentation. Was „wirksam” heißt, wie tief geprüft werden muss und woran ein Prüfer das erkennt, steht in der Verordnung nicht.
Diese Lücke füllt der Normenweg. Annex ZZ der 4-2 weist die Norm als Mittel zur Konformitätsvermutung aus, sobald ihre Fundstelle im Amtsblatt der EU steht, und zwar für die in Tabelle ZZ.1 aufgeführten normativen Abschnitte im Rahmen ihres Anwendungsbereichs. Bis dahin ist sie ein Entwurf, an dem sich planen lässt, mehr nicht.
Neun Anforderungen sortieren, was Testen umfasst
Die 4-1 ersetzt ihre Practice zur Verifikation und Validierung vollständig. Aus fünf Anforderungen werden neun, und die Nummerierung verschiebt sich dabei durchgehend.
| Anforderung | Inhalt | Herkunft |
|---|---|---|
| SVV-1 | Unabhängigkeit der Tester | vorher SVV-5 |
| SVV-2 | Test der funktionalen Sicherheitsanforderungen | vorher SVV-1 |
| SVV-3 | Test der Wirksamkeit von Bedrohungsminderungen | vorher SVV-2 |
| SVV-4 | Schwachstellentests, inklusive Angriffsflächenanalyse und Software Composition Analysis | vorher SVV-3 |
| SVV-5 | Robustheitstests für Last, Skalierung und Fuzzing | neu zusammengesetzt |
| SVV-6 | Penetrationstests | vorher SVV-4 |
| SVV-7 | Ableitung des Security Test Grade | neu |
| SVV-8 | Testpläne und Testberichte | neu |
| SVV-9 | wiederkehrendes Testen über den Unterstützungszeitraum | neu |
Wer heute nach der Fassung von 2018 arbeitet, muss die Verweise in seiner Prozessdokumentation also anfassen. Die neuen Robustheitstests sind dabei der unangenehmste Fall, weil sie aus zwei alten Anforderungen zusammenwachsen: Fuzzing und Netzlasttest standen bisher unter SVV-3 Buchstabe a), Performance, Skalierung und Stresstests unter SVV-1 Buchstaben b) und c).
Der Testgrad wirkt nur auf SVV-3 bis SVV-6. Die funktionale Prüfung der Sicherheitsanforderungen nach SVV-2 bleibt davon unberührt. Ob eine Rollenverwaltung tut, was sie soll, hängt nicht am gewählten Testgrad.
Drei Grade legen fest, wie tief geprüft wird
Die Grade bauen aufeinander auf. STG-2 enthält alle Module aus STG-1, STG-3 alle aus beiden.
Ein Detail entscheidet über die Verbindlichkeit: Annex G ist als informativ gekennzeichnet, doch die normative Klausel 4.4 der 4-2 verlangt, ihn anzuwenden und die Abnahmekriterien aller anwendbaren Module zu erfüllen. Wer nur auf das „(informative)” in der Anhangsüberschrift schaut, unterschätzt die Wirkung.
STG-1 umfasst überwiegend werkzeuggestützte Tests ohne Anmeldung am Produkt: Portscan, Schwachstellenscan, Prüfung der Kryptoprotokolle, Basis-Fuzzing, Basis-Lasttest. STG-2 wiederholt dieselben Techniken mit Anmeldung, denn ein authentifizierter Scanner sieht Patchstände und Konten, die von außen unsichtbar bleiben. STG-3 bringt das Manuelle: risikoorientiertes Pentesting, maßgeschneidertes Fuzzing, anwendungsspezifische Lasttests und eine binäre Software Composition Analysis.
Dieselbe Testart, drei Tiefen
Annex G ordnet 21 Module den drei Graden zu: elf in STG-1, sechs weitere in STG-2, vier in STG-3. Ein 22. Modul steht außerhalb der Grade und ist optional. Interessanter als die Liste ist, wie dieselbe Testart über die Grade wächst. Fünf Beispiele:
| Testart | STG-1 | STG-2 | STG-3 |
|---|---|---|---|
| Schwachstellenscan | unauthentifiziert, je nach Produkt allgemein, Web oder OT | dieselben Scans authentifiziert | Teil des manuellen Pentests |
| Fuzzing | standardisierte Protokolle, für die Testsuiten existieren | zusätzlich proprietäre Protokolle und solche ohne fertige Suite | auf die Bedrohungsszenarien des Produkts zugeschnitten |
| Lasttest | generische Netzlast über OSI-Schichten 2 bis 4 | kein zusätzliches Modul | manuell und anwendungsspezifisch |
| Komponenten und Patchstand | SBOM validieren und gegen Schwachstellendatenbanken abgleichen | authentifizierter Scan des Patchstands | binäre Software Composition Analysis über alle ausführbaren Dateien |
| Undokumentierte Konten | unauthentifizierte Suche mit Standardwerkzeugen | authentifizierte Suche | manuelle Suche nach dem, was die Werkzeuge nicht finden |
Dazu kommen Module, die es nur einmal gibt: Portscan, Malware-Scan und die Prüfung der kryptografischen Kommunikationsprotokolle sitzen alle in STG-1. Das optionale Modul zur dynamischen Ressourcenverwaltung zur Laufzeit wird angewandt, wenn passende Werkzeuge verfügbar sind.
Wo sich das Ergebnis objektivieren ließ, steht es im Modul
Bisher entschied der Tester, was ein akzeptables Ergebnis ist, und der Prüfer entschied es später noch einmal. Bei den technisch eindeutigen Modulen ist damit Schluss:
- STM-2: Kein undokumentierter offener TCP- oder UDP-Port. Einer reicht für ein FAIL.
- STM-8 und STM-17: Keine dauerhaften kritischen Befunde, und die spezifizierte Mindestfunktion des Produkts bleibt erhalten. Abstürze und Neustarts sind unzulässig. Sporadische Befunde, die in fünf Wiederholungen nicht mehr auftreten, zählen nicht als Schwachstelle.
- STM-9: Das Produkt hält unter Last seine Mindestfunktion und erholt sich danach ohne Eingriff. Ist keine Erholungszeit spezifiziert, gilt ein Standardwert von 120 Sekunden.
Für eine Maschinensteuerung mit Web-Interface heißt das: Wer bisher „Fuzzing lief durch, ein paar Reconnects” dokumentiert hat, muss künftig belegen, dass es keine Neustarts waren und die Mindestfunktion erhalten blieb.
Bei der Mehrzahl der Module bleibt allerdings Spielraum. Deren PASS-Kriterium knüpft an das im Produktkontext akzeptable Restrisiko an, und das bewertet weiterhin der Hersteller. Die Grade schaffen also einen gemeinsamen Umfang, keine gemeinsame Messlatte für jeden Einzelbefund.
Der Testgrad folgt dem Risiko
SVV-7 verlangt einen Prozess, der den Grad aus Bedrohungsmodell und Risikobeurteilung ableitet, ausdrücklich unter Berücksichtigung der angenommenen Angreifer. Intensität und Abdeckung der Tests sollen zu den Akteuren passen, die das Bedrohungsmodell unterstellt.
Wer also mit einem Angreifermodell arbeitet, das gezielte manuelle Angriffe einschließt, kommt mit werkzeuggestützten Modulen nicht aus. Dieselbe Logik kennen Sie von den Security Leveln der IEC 62443.
Danach folgt die Anwendbarkeitsprüfung nach Annex D der 4-1, und dieser Annex ist normativ:
- ASTM-1 prüft die sachlichen Kriterien des Moduls. Ein Produkt ohne Web-Oberfläche braucht STM-6 nicht.
- ASTM-2 prüft die Anwendbarkeit anhand der Risikobeurteilung.
- ASTM-3 verlangt die Dokumentation: Ausgangsmenge der Module, Begründung für jedes gestrichene Modul, resultierende Menge.
Diese dritte Stufe nimmt der Diskussion mit dem Prüfer die Grundlage. Bisher lief der Streit darüber, ob ein Test nötig gewesen wäre. Künftig liegt eine begründete Streichung vor oder eben nicht, und der Prüfer bewertet die Begründung statt das Bauchgefühl.
Pentest heißt manuell, alles andere ist ein Scan
Die Norm kennt drei Spielarten des Penetrationstests (englisch Penetration Testing, kurz Pentest): rein werkzeuggestützt, manuell und die Kombination aus beidem. Die werkzeuggestützte Variante ist dabei nichts anderes als eine Bündelung von Modulen aus STG-1 und STG-2, für die zusätzlich die höhere Unabhängigkeit der Tester erfüllt sein muss. Das manuelle Testen steckt in STM-18 in STG-3, wo erfahrene Tester die spezifischen Funktionen und Angriffsszenarien des Produkts durchgehen und dabei anerkannte Frameworks heranziehen können, etwa das OWASP Testing Framework.
Aus unserer Sicht verdient nur die manuelle Variante den Namen. Der Begriff wird so wirr verwendet, dass er kaum noch etwas aussagt, und wer einen Werkzeuglauf als Pentest verkauft, nutzt genau diese Unschärfe. Penetrationstest heißt manuelle Arbeit, bei der Werkzeuge unterstützen.
Wann er fällig ist, lässt sich gut abgrenzen. Wesentliche Änderungen gehören getestet, also neue oder vollständig überarbeitete Funktionen mit Sicherheitsbezug wie ein neuer Update-Mechanismus, Secure Boot oder eine neu angebundene Authentifizierung über Keycloak. Dazu jedes Major Release, das per Definition viel verändert hat. Das kostet Geld, findet aber Dinge, die die eigenen Tests übersehen haben. In der Safety ist dieses Vorgehen längst normal. Bei größeren Änderungen lässt man den TÜV auch dann drüberschauen, wenn keine Pflicht dazu besteht, weil man Risiken ausschließen will.
Beim Fuzzing entscheidet das Verfahren
Annex G nennt acht Stunden je Schnittstelle und Protokoll als Richtwert für die Mindestdauer, sofern keine anderen Gründe für eine kürzere oder längere Dauer sprechen.
Der Wert passt, denn diese Normen werden von erfahrenen Praktikern geschrieben. Länger laufende Fuzzer finden natürlich mehr, aber die Stundenzahl ist die kleinere Stellschraube. Wichtiger ist, wie der Fuzzer arbeitet. Wer falsch ansetzt, fuzzt die CRC32-Prüfsumme und nie die Datenverarbeitung dahinter: Das Produkt verwirft jedes Paket sofort, der Testbericht ist sauber, und die eigentliche Parsing-Logik hat nie ein ungültiges Byte gesehen.
Die Norm bildet die Steigerung ab. STM-8 deckt standardisierte Protokolle mit vorhandenen Testsuiten ab. STM-17 verlangt zusätzlich proprietäre Protokolle und solche ohne fertige Suiten, wofür sie drei Wege nennt: Tests aus mitgeschnittenem Verkehr, selbst entwickelte Tests aus kombinierten Fuzzing-Modulen oder auf Basis von Fuzzing-SDKs, oder manuelles Fuzzing durch erfahrene Tester. STM-19 geht darüber hinaus und passt die Tests an die Bedrohungsszenarien des Produkts an.
Unabhängigkeit ist Pflicht, Eignung eine Auswahlfrage
SVV-1 staffelt, wie weit der Tester vom Entwickler entfernt sein muss.
| Testart | Geforderte Unabhängigkeit |
|---|---|
| Statische Codeanalyse (SAST) | keine |
| Software Composition Analysis | keine |
| Angriffsflächenanalyse, Schwachstellenscan, Abuse-Case-Tests | unabhängige Person |
| Robustheitstests | unabhängige Person |
| Test der Sicherheitsanforderungen, Test der Bedrohungsminderungen | unabhängige Abteilung |
| Penetrationstests | unabhängige Abteilung oder Organisation |
In der Praxis läuft die oberste Stufe auf Einkauf hinaus. Nur die ganz großen Konzerne halten eigene Pentester vor, alle anderen bedienen sich am Markt. Dort ist Vorsicht angebracht, weil den Begriff jeder bewirbt und viel Mist dabei ist. Zwei Prüfsteine helfen. Testet ein Anbieter überwiegend Phishing, klassische IT und Webanwendungen, ist er für Geräte und Maschinen typischerweise ungeeignet. Und ein geeigneter Tester kann seine Methode vorzeigen. Wer das nicht kann, schaut kursorisch drüber und kreidet eine veraltete Cipher Suite an, statt echte Probleme im Gerät zu finden. Wie ein Pentest im industriellen Umfeld abläuft, haben wir in Penetrationstests im Maschinenbau beschrieben.
Der Prüfer trennt Methodik und Ergebnis
Die 4-2 bringt mit Annex B eine normative Evaluierungsmethodik mit. Deren Block EA-9 gliedert das Testen in 15 Prüfaktivitäten. Vier davon tragen die Last:
- Unabhängigkeit der Tester nach SVV-1.
- Gewählter Testgrad: Ist er dokumentiert, passt er zum Ergebnis der Risikobeurteilung, wurde die Anwendbarkeitsprüfung nach Annex D angewandt?
- Vollständigkeit der Testartefakte gegen den Inhalt, den SVV-8 vorgibt.
- Danach je Testart zwei getrennte Aktivitäten: einmal die Methodik, einmal das Ergebnis.
Der letzte Punkt erklärt, warum ein Testbericht ohne dokumentiertes Vorgehen durchfällt, obwohl nichts gefunden wurde. „Keine Befunde” lässt ohne die zugehörige Methodik offen, ob überhaupt an der richtigen Stelle gesucht wurde. SVV-8 verlangt deshalb für Testpläne und Testberichte mindestens Ziele, Abdeckung, Methodik, Ressourcen samt Werkzeugen, Liefergegenstände, den gewählten Grad mit den anwendbaren Modulen, die Abnahmekriterien und die Ergebnisse.
Was Hersteller jetzt vorbereiten können
Der Entwurf ist noch keine Norm, aber die Struktur dahinter ist stabil genug, um daran zu arbeiten. Vier Schritte lassen sich ohne die endgültige Fassung erledigen.
Legen Sie zuerst Ihre vorhandenen Testfähigkeiten gegen die Module. Meist deckt der Ist-Zustand STG-1 weitgehend ab, STG-2 lückenhaft und STG-3 gar nicht. Leiten Sie dann je Produkt einen Grad aus Bedrohungsmodell und Risikobeurteilung ab, schriftlich begründet, denn diese Begründung wird der Prüfgegenstand. Dokumentieren Sie jedes gestrichene Modul mit Grund, was Fleißarbeit ist und im Audit Zeit spart. Und stellen Sie Testplan und Bericht auf den Inhalt um, den SVV-8 vorgibt, statt Werkzeug-Exporte zu sammeln.
Wer den sicheren Entwicklungsprozess ohnehin gerade aufsetzt, sollte die Teststruktur direkt mitdenken. Nachträglich Testgrade in einen laufenden Prozess einzuziehen ist teurer, als sie von Anfang an mitzuführen.
Kommentar hinzufügen