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 zwei Änderungsentwürfe an, je einer zur IEC 62443-4-1 und zur IEC 62443-4-2. Beide liegen als prAA vor. 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 Bedingungen für PASS und FAIL. Die Ergänzung zur IEC 62443-4-1 verankert das Verfahren im Entwicklungsprozess, die zur IEC 62443-4-2 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 schließt erst die Norm: Sie beschreibt, welche Tests in welcher Tiefe zu fahren sind. Eine Konformitätsvermutung folgt daraus allerdings nicht automatisch. Annex ZZ der IEC 62443-4-2 ordnet die normativen Abschnitte der Norm den grundlegenden Anforderungen aus Anhang I Teil I zu, sobald ihre Fundstelle im Amtsblatt der EU steht. Die Testpflicht aus Teil II Nummer 3 steht in dieser Tabelle nicht. Bis dahin lässt sich damit planen, mehr nicht.
Neun Anforderungen sortieren, was Testen umfasst
Die IEC 62443-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 IEC 62443-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. Dieselbe Testart wächst über die Grade mit:
| 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. Zwei Hersteller können damit denselben Testgrad fahren und denselben Befund trotzdem unterschiedlich bewerten.
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.
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 IEC 62443-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 eine Begründung, die er nachlesen kann.
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.
Wann er fällig ist, lässt sich gut abgrenzen. Größere Funktionsänderungen mit Sicherheitsbezug gehören getestet, etwa 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 holen Hersteller den TÜV auch ohne Pflicht dazu, um Restrisiken auszuschließen.
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.
Acht Stunden sind ein brauchbarer Ausgangswert. 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 lohnt genaues Hinsehen, weil den Begriff jeder bewirbt und viel Mist dabei ist. Testet ein Anbieter überwiegend Phishing, klassische IT und Webanwendungen, ist er für Geräte und Maschinen typischerweise ungeeignet. Ein geeigneter Tester kann außerdem 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 IEC 62443-4-2 bringt mit Annex B eine normative Evaluierungsmethodik mit. Deren Block EA-9 gliedert das Testen in 15 Prüfaktivitäten. Vier davon sind entscheidend:
- 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.
Ein Testbericht ohne dokumentiertes Vorgehen fällt damit durch, 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
An der Teststruktur lässt sich schon jetzt arbeiten.
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.
