Praxisnah sicher entwickeln mit IEC 62443-4-1

Die IEC 62443-4-1 ist ein Prozessstandard für sichere Software-Entwicklung im industriellen Automatisierungsumfeld. Er beschreibt den gesamten Entwicklungsprozess von Design bis Wartung und erfüllt dabei viele Anforderungen des Cyber Resilience Act. Kernelemente sind Security Requirements, unabhängige Tester, Review-Prozesse, Threat-Modellierung und eine lückenlose Traceability zwischen Anforderung, Umsetzung und Test.

Das Wichtigste in Kürze

• Die IEC 62443-4-1 deckt als Prozessstandard einen Großteil der Anforderungen des Cyber Resilience Act ab, der ab Dezember 2027 verpflichtend wird und Hersteller digitaler Produkte zur nachweisbaren Cybersicherheit zwingt.
• Independence of Testers bedeutet konkret, dass Tester und Entwickler nicht an dieselbe Führungskraft berichten dürfen, was besonders in kleinen Unternehmen organisatorische Lösungen wie ein Kompetenzzentrum erfordert.
• Eine Gap-Analyse des bestehenden Prozesses vor der Norm-Einführung spart erheblichen Aufwand, weil sie zeigt, wie groß das tatsächliche Delta ist, bevor man in Trainings und Zertifizierung investiert.
• Test-Collaboration-Meetings, in denen Entwickler und QA-Ingenieure gemeinsam Teststrategien pro Backlog-Item festlegen, verhindern späte Überraschungen im Pull-Request und verschieben ungeklärte Fragen bewusst nach links im Prozess.
• Prozess-Trainings dienen nicht nur der Norm-Erfüllung, sondern reaktivieren implizites Prozesswissen, das im Arbeitsalltag verloren gegangen ist, und schaffen Traceability-Bewusstsein quer durchs Team.

Was die 62443-4-1 regelt und wofür sie steht

Die IEC 62443-4-1 ist ein Prozessstandard für sichere Softwareentwicklung im industriellen Automatisierungs- und Steuerungsumfeld. Sie beschreibt, wie Software vom Design über die Implementierung bis in die Wartungsphase sicher zu entwickeln ist.

Der Standard ist Teil einer größeren Normenfamilie. Die “-1” ist der Prozessteil, also die Vorgaben für die Art und Weise, wie entwickelt wird. Die “-2” liefert einen Anforderungskatalog für Produkte und Komponenten, die als sicher gelten sollen.

Beide Teile greifen ineinander. Wer sich nach der 62443-4-2 zertifizieren lassen will, muss vorher den Prozess aus der “-1” vollständig durchlaufen und alle Anforderungen erfüllt haben.

Wie sich Norm und Cyber Resilience Act ergänzen

Die 62443-4-1 funktioniert als Werkzeugkasten für die Prozessanforderungen des Cyber Resilience Act. Der CRA bildet den rechtlichen Rahmen, die Norm liefert das Werkzeug, um die geforderten Prozesse umzusetzen.

Der Cyber Resilience Act trat im Dezember 2024 in Kraft. Er verpflichtet Hersteller digitaler Produkte, Cybersicherheit in ihren Produkten nachzuweisen, also secure zu entwickeln. Das betrifft auch bestehende Produkte. 2026 beginnen die ersten Meldepflichten zur Offenlegung von Schwachstellen, ab Dezember 2027 soll der CRA voll greifen.

Konkret verlangt der CRA mehrere Dinge: Software soll im Auslieferungszustand sicher sein, Verschlüsselung soll aktiviert, die Angriffsfläche durch das Abschalten unnötiger Interfaces minimiert sein. Dazu kommen ein Schwachstellenmanagement mit Bewertung und Updates für Endkunden sowie Anforderungen an die Dokumentation.

Ein Punkt zwingt Hersteller zur Disziplin bei externen Komponenten. Über ein Bewertungsschema muss geprüft werden, ob eine Third-Party-Library im aktuellen Umfeld überhaupt geeignet ist. Zusätzlich verlangt der CRA eine Software Bill of Materials, kurz S-BOM, die alle verbauten Komponenten beschreibt, eigene wie externe.

Die Norm deckt den Prozessteil ab, nicht das Ganze. Für die inhaltlichen Security Requirements kommt die 62443-4-2 ins Spiel, ihr Anforderungskatalog wird in die eigene Entwicklung importiert und ergänzt.

Warum Security Requirements zu markierten Features werden

Sicherheit wird in dieser Arbeitsweise sichtbar gemacht, statt implizit mitzulaufen. Ein Security Requirement führt zu einem Security Feature, und beides wird eindeutig als sicherheitsrelevant markiert.

Diese Markierung schafft Traceability. Ein Feature, das ein Security Requirement wie Logging umsetzt, gilt als sicherheitsrelevant. Die Tests, die dieses Feature prüfen, sind mit dem Requirement verlinkt und ebenfalls als sicherheitsrelevant gekennzeichnet.

Die Requirements stammen aus mehreren Quellen: aus dem Katalog der 62443-4-2, aus dem Cyber Resilience Act, aus hausinternen Vorgaben oder direkt vom Kunden. Sie können auch aus einem Threat-Model entstehen. Jedes Requirement wird daraufhin analysiert, ob es zum Produkt passt. Manche sind technischer Natur und zielen auf Hardware-Ebene, die dann nicht zutrifft.

Vor der Umsetzung steht ein Review. Beteiligt sind unter anderem ein Security-Verantwortlicher oder Architekt, der Product Owner und ein QA-Ingenieur. Ziel ist, Fehler im Dokument früh aufzudecken, bevor sie in den Code wandern. Alle Beteiligten zeichnen das Feature ab.

Security Level entscheidet über den Schutzaufwand

Das Security Level legt fest, wie viel Aufwand in die Absicherung fließt. Die 62443-4-2 kennt vier Stufen: von SL1 bei intentional use bis SL4, wo ein Geheimdienst als Angreifer angenommen wird.

Jedes Produkt muss sich in diesem Raster verorten. Dafür entsteht ein Dokument, das den Security-Kontext und das Environment beschreibt und daraus das passende Level ableitet. In der Praxis liegen viele Produkte zwischen SL1 und SL2, wenn keine hochsicherheitskritischen Werte zu schützen sind.

Das gewählte Level steuert, welche Security Requirements relevant sind und wie hoch der Absicherungsaufwand ausfällt. Bei SL2 ist dieser Aufwand bereits spürbar höher als bei SL1.

Wie ein kleines Unternehmen die Unabhängigkeit der Tester sicherstellt

Die Norm verlangt Independence of Testers für sicherheitsrelevante Anforderungen, sinnvoll ab dem Integrationstest-Level. Unabhängigkeit heißt hier ein Vier-Augen-Prinzip, bei dem Tester und Entwickler nicht an denselben Gruppenleiter berichten.

Für ein kleines Unternehmen ist genau das ein Problem, weil die personelle Trennung schnell eng wird. Eine Lösung läuft über die Organisationsstruktur. Bei M&M Software ruht diese auf drei Säulen: den Mitarbeitern mit ihren Gruppenleitern, dem Projektgeschäft und den Kompetenzzentren.

Die Gruppen sind klein, im Schnitt bis zu acht oder etwas mehr Mitarbeiter, die sich einmal pro Woche mit dem Gruppenleiter austauschen. Weil die Teams fachlich gemischt sind, sinkt die Wahrscheinlichkeit, dass Tester und Entwickler einer Aufgabe demselben Gruppenleiter unterstehen.

Greift die Trennung doch nicht, übernimmt das Kompetenzzentrum eine zweite Funktion. Das Kompetenzzentrum Quality Engineering bündelt die Qualitätsingenieure und kann als Schiedsgericht eintreten, wenn ein Entwickler und ein Qualitätsingenieur sich streiten und beide an dieselbe Person berichten.

Wieso Trainings das schwierigste Stück der Einführung sind

Der Prozess selbst war schnell aufgesetzt, die Trainings waren die eigentliche Arbeit. Während die Prozessdokumentation grob in einem Jahr stand, sind die fachlichen Security-Trainings deutlich aufwendiger zu erstellen.

Die Einführung begann mit einer benannten Person, die sich vollständig in das Thema Security eingearbeitet hatte. Danach folgte eine Gap-Analyse: Der bestehende Prozess wurde dem Zielprozess gegenübergestellt und nur das Delta neu aufgebaut. Security war vorher schon als Qualitätsattribut mitgelaufen, aber nicht eigens gekennzeichnet.

Dieser Schritt ist der wichtigste Rat für jeden, der eine Norm einführen will. Sieh dir deinen vorhandenen Prozess an, bestimme das Delta zur Zielnorm und rechne die Kosten gegen den Nutzen. Manche Normen erwähnen im Nebensatz eine weitere Norm, die einen ganzen Rattenschwanz nach sich zieht.

Die Trainings teilten sich in zwei Gruppen. Die Prozesstrainings holten Entwickler, Requirements Engineers, Product Owner und Qualitätsingenieure ab. Die QA-Ingenieure durchliefen zusätzlich die Prozesstrainings von POs und Entwicklung, damit sie wissen, was beim Review eines Security Features auf sie zukommt.

Die Standorte in China und Indien mussten gesondert überzeugt werden, weil die lokalen Märkte anders testen und die Begründung für EU-Anforderungen dort nicht selbstverständlich ist. Trainings sind deshalb auch ein Mittel, Leute davon zu überzeugen, dass eingebaute Security sinnvoll ist.

Pseudo-Features als praktischer Test-Fundus

Statt jeden Qualitätsingenieur bei jedem Security Requirement bei null anfangen zu lassen, wurde ein wiederverwendbarer Wissensspeicher aufgebaut. Jedes sicherheitsrelevante Requirement wurde in ein Pseudo-Feature zerlegt und dokumentiert.

Der Auslöser war eine konkrete Kostenfrage. Eine abstrakte Security-Schulung wie die CSSLP bringt persönlich viel, hilft aber nicht direkt beim Testen eines einzelnen Requirements. Ohne Vorlage müsste sich jeder QA-Ingenieur in jedes Requirement neu eindenken, um die passenden Abuse-Tests zu finden.

Die Lösung orientierte sich an der Implementation Guidance, die es für viele Requirements schon gab. Zu jedem Requirement entstand ein Pseudo-Feature mit Test Conditions, Test Objectives und Beispiel-Testfällen, hinterlegt in einem zentralen Wiki.

Der Nutzen zeigt sich im Alltag. Wer Audit-Logging testen soll und nicht weiß, wo er ansetzt, findet im Wiki Ideen, eine Referenz und die Quintessenz des Requirements zum Nachschlagen. Die Trainings dazu wurden auf rund sieben Einheiten verteilt, an denen jeder teilnehmen konnte.

Das Test Collaboration Meeting bringt Security nach links

Der größte praktische Hebel ist ein Meeting, in dem Entwickler und QA-Ingenieur die Teststrategie für ein Arbeitspaket gemeinsam festlegen. Das verschiebt Klärung und Sicherheitsfragen an den Anfang der Umsetzung statt ans Ende.

Im Test Collaboration Meeting trifft sich das Team eines Product Backlog Items mit dem QA-Ingenieur, der dort als Quality Coach auftritt. Er bringt die Akzeptanzsicht ein, die Entwickler kennen die technische Spezifikation. Gemeinsam wird geklärt, ob das Arbeitspaket verstanden ist und welche Fragen noch an den Product Owner gehen.

Ein hilfreiches Bild dafür: Jedes Backlog Item ist wie ein kleines Wasserfallmodell. Oben stehen die Akzeptanzkriterien, darunter ein kleines Systemdesign, dann die Komponentenebene mit Integrationstests, ganz unten die Unit-Test-Ebene.

Aus diesem Meeting fällt die Teststrategie als dokumentiertes Ergebnis. Sie legt fest, welche Testarten und Verfahren genutzt werden und was auf welcher Ebene geprüft wird. Manuelle Akzeptanztests sind teuer, deshalb geht es darum, durch geschicktes Schneiden möglichst viele Permutationen auf den unteren Ebenen abzudecken.

Die Reihenfolge folgt einem klaren Prinzip:

Wer den Standard-Workflow ohnehin dutzendfach durchgespielt hat, sollte ihn automatisieren und die manuelle Energie in einen sauberen explorativen Test stecken. So bleibt am Ende keine Überraschung übrig, kein nachträgliches “Soll sich das so verhalten?” beim Product Owner.

Wie Vorgaben für Coverage und Code-Reviews greifen

Die Umsetzung folgt festen Best Practices, und der Code wird grundsätzlich gereviewt. Für sicherheitskritische Komponenten gilt eine Branch Coverage von möglichst 100 Prozent, für weniger relevante Teile wie Getter kann sie unter 80 Prozent liegen.

Das Code-Review im Pull Request ist der Ort, an dem sich Schwächen der Vorarbeit zeigen. Treten dort viele Issues auf, wurde entweder nicht sauber getestet oder die Strategie war nicht klar genug niedergeschrieben.

Wer Testfälle für sicherheitsrelevante Features schreibt, muss qualifiziert sein und die passenden Trainings durchlaufen haben. Fehlt die Qualifikation, müssen die Testfälle von jemandem mit Qualifikation abgenommen werden. Penetrationstests werden aus Unabhängigkeitsgründen vollständig an einen akkreditierten Partner ausgelagert, der zugleich die objektive Abnahme liefert.

Warum eine Norm zum lebenden Prozess werden muss

Eine Norm bringt nur dann Nutzen, wenn sie gelebt wird, statt als Papierware in der Ablage zu liegen. Die 62443-4-1 verlangt selbst, dass man reflektiert und sich verbessert, und genau dieser Mechanismus hält den Prozess am Leben.

Interne Audits prüfen die hauseigenen Projekte auf Prozesskonformität und decken auf, wo die Leute in der Praxis Probleme haben. So entsteht eine kontinuierliche Verbesserung, und das Feedback wird als Ratschlag zurückgespielt, nicht als Vorwurf.

Ein wiederkehrendes Muster: Ältere Mitarbeiter arbeiten oft implizit längst nach dem Prozess, sind sich aber nicht bewusst, dass es ihn überhaupt gibt oder wo sie ihn finden. Den Prozess sichtbar zu machen und Traceability zu schaffen, ist die eigentliche Aufgabe.

Der Sinn dieser Traceability wird im Ernstfall greifbar. Kommt es zu einem Unfall, wird in Design, Implementierung und Tests hineingeschaut. Ein Testergebnis, das nur “passed” sagt, hilft dann nicht. Bei Security zählen die einzelnen Test-Steps als Nachweis, dass wirklich geprüft wurde.

Wenn ich pauschal sage, der Test ist passed, ich habe aber nicht wirklich getestet, wie kann ich das verantworten? Dieses Misstrauen will man ausräumen. — Holger Santelmann

Der TÜV als früher Indikator vor dem Audit

Eine Vorprüfung durch den TÜV zeigt früh, worauf es beim späteren Audit ankommt. Der TÜV darf nicht beraten, aber Feedback geben, und schon dieses Feedback ist ein nützlicher Indikator.

Man geht mit dem Vorschlag für den angepassten Prozess in die Vorprüfung und sieht, worauf der Prüfer achtet und was er sich zeigen lässt. Das macht die Erwartungen für das eigentliche Audit konkret.

Der erste Anlauf läuft selten ohne Abweichung. Bei der Prüfung ein Jahr später kommt es darauf an, dass die Abweichungen behoben und adäquat angegangen wurden. Die Annahme, beim ersten Mal falle nichts auf, wäre vermessen. Auch das ist Lernprozess.

Wie kleine Projekte mit dem Overhead umgehen

Je kleiner das Projekt, desto stärker drückt der Overhead der Norm, und genau dort braucht es eine schlanke Antwort. Bei großen Projekten etabliert sich der Prozess fast von selbst, bei kleinen kommt schnell die Frage, ob ein eigenes Testkonzept wirklich sein muss.

Die Lösung ist ein vorausgefülltes Mastertest-Konzept, intern QA-Plan genannt, das Master- und Stufentestkonzept in einem Dokument vereint. Es ist eng auf den eigenen Prozess zugeschnitten und verweist auf die bestehenden Prozeduren, sodass man es für kleine Projekte zügig durchgehen kann.

Dazu kommen wenige Pflichtdokumente wie das Projekthandbuch und das Dokument zum Secure Context und Environment. Der Aufwand bleibt damit handhabbar, ohne dass die Nachvollziehbarkeit verloren geht.