Praxisnah sicher entwickeln mit IEC 62443-4-1

Normen für sichere Softwareentwicklung gelten oft als notwendiges Übel – doch was, wenn ein Team sie tatsächlich schätzen lernt? Die Umsetzung der IEC 62443-4-1 kann zum Katalysator für bessere Zusammenarbeit werden, wenn Prozess-Trainings mit praktischen Test-Strategien verbunden und Security-Requirements systematisch in testbare Features übersetzt werden. Entscheidend ist dabei nicht die perfekte Erst-Zertifizierung, sondern ein lebendiger Prozess mit internen Audits, dediziertem Wissenstransfer und dem Mut, auch in kleinen Teams Unabhängigkeit im Software Testing kreativ zu lösen.

Podcast Episode: Praxisnah sicher entwickeln mit IEC 62443-4-1

In dieser Episode spreche ich mit Holger Santelmann darüber, wie sein Team die Norm IEC 62443-4-1 für sichere Softwareentwicklung nicht nur umgesetzt, sondern tatsächlich lieben gelernt hat. Holger zeigt, wie sie aus einem gefürchteten Papier-Monster einen lebendigen Prozess gemacht haben, der die Zusammenarbeit zwischen Entwicklung und Software Testing verbessert statt behindert. Besonders spannend: Statt trockene Compliance-Übungen haben sie Trainings entwickelt, die jedes Security-Requirement praktisch aufschlüsseln, Test Collaboration Meetings etabliert und die Independence of Testers kreativ über Kompetenz-Center gelöst.

„Wenn beim Pull-Request viele Issues aufgetreten sind, dann hat ein Entwickler gar nicht getestet, ob das noch läuft." - Holger Santelmann

Holger Santelmann ist Dipl.-Medieninformatiker (FH) und verfügt über mehr als 20 Jahre Erfahrung in der Softwareentwicklung. Er hat als Senior Software Developer bei der Firma M&M Software GmbH angefangen und sich in den letzten Jahren immer mehr auf das Thema Release- bzw. Testmanagement spezialisiert. Als Leiter des Competence Centers Quality Engineering treibt er das Thema Qualitätssicherung innerhalb der Firma M&M Software GmbH weiter voran und unterstützt den Softwareentwicklungsprozess.

Highlights der Episode

• Norm 62443-4-1 erfüllt fast vollständig den Cyber Resilience Act – perfekter Werkzeugkasten für sichere Entwicklung.
• Dedizierte Security-Trainings pro Requirement sind wirksamer als abstrakte Cert-Schulungen für alle Mitarbeitenden.
• Test Collaboration Meetings vor jedem Feature eliminieren Überraschungen im Pull Request und schaffen echte Unabhängigkeit.
• Security-Features müssen geflagged, gereviewt und von qualifizierten Testern abgenommen werden – Vier-Augen-Prinzip ist Pflicht.
• Gap-Analyse zeigt: Bestehenden Prozess bewerten, dann Norm wählen – nicht umgekehrt, sonst wird's teuer.

Mit Normen zu mehr Sicherheit: Warum IEC 62443-4-1 uns hilft, wach zu bleiben

Warum Normen mehr als lästige Pflicht sein können

Viele erstarren regelrecht, wenn sie das Wort "Norm" hören. Verständlich, bringt so ein Schriftstück doch selten Spielfreude in den Alltag. Trotzdem werden Normen immer wichtiger, wenn es um die Entwicklung von sicherer Software geht. Das merkt gerade jede Firma, die Produkte für die Industrie entwickelt. Im Gespräch zwischen Speaker A und Speaker B beim QS-Tag in Frankfurt ging es genau darum: Ist Sicherheit nur Bürokratie, oder kann dahinter Mehrwert für die ganze Organisation stecken?

Was steckt hinter IEC 62443-4-1?

Die IEC 62443-4-1 ist ein Prozessstandard, der beschreibt, wie man sichere Software speziell im industriellen Bereich entwickelt. Es geht um Sicherheit – von der ersten Idee über das Design, die Umsetzung, Tests und bis hin zur Wartung. In jedem Schritt fragt die Norm: Ist alles so gestaltet, dass es vor Angriffen schützt und Risiken mindert? Auch Dokumentation und die Frage, welche Komponenten (beispielsweise Third Party Libraries) zum Einsatz kommen, werden kritisch betrachtet.

Neu ist: Mit dem Cyber Resilience Act (CRA), der Ende 2024 in der EU eingeführt wird, wird vieles davon Pflicht. Hersteller müssen nachweisen, dass sie Sicherheitstechniken bereits beim Ausliefern aktivieren, Schwachstellen offenlegen und Nachbesserungen bereitstellen. Die IEC 62443-4-1 hilft als Leitfaden, all diese Anforderungen zu erfüllen.

Sicherheit als gemeinsamer Prozess im Team

Normen kann man natürlich wie ein Muss einfach abarbeiten. Genau das haben Speaker B und sein Team aber nicht gemacht. Sie nutzten die Gelegenheit, um interne Prozesse zu durchleuchten und zusammen neu aufzubauen. Zuerst legten sie fest, wie Unabhängigkeit beim Testen gelingt. Man braucht verschiedene Blickwinkel: Wer entwickelt, testet nicht das eigene Werk allein. Vier-Augen-Prinzip, Rollenverteilung, und regelmäßige Reviews sind Pflicht.

Ein spannender Punkt: Nicht nur die Technik entscheidet, sondern auch, wie Teams lernen, mit Sicherheit umzugehen. Deshalb starteten sie mit Prozesstrainings für alle: Entwickler, Requirements Engineers, Quality Engineers – jeder bekam eine Schulung darüber, was nun wichtig ist und wie es im Alltag umgesetzt wird.

Praktische Tipps aus der Umstellung

Natürlich dauert so ein Wandel. Das Team von Speaker B investierte ein Jahr in die Anpassung der Prozesse, bevor die dedizierten Trainings kamen. Statt alle ins kalte Wasser zu werfen, begann man mit einer Lückenanalyse: Was machen wir schon, was fehlt noch für die neue Norm? So wurden bestehende gute Praktiken erhalten und nur ergänzt, was wirklich fehlte.

Mit Handbüchern, Vorlagen und Schulungen wurde Sicherheit zu etwas Greifbarem. Jeder Schritt – vom Requirements Engineering übers Testdesign bis zum Review – wurde dokumentiert und diskutiert. So bleiben Abläufe transparent und niemand steht auf dem Schlauch, wenn es ernst wird.

Zusätzlich dokumentierte das Team beispielhafte Testfälle für Sicherheitsanforderungen in einem Wiki. Wer fragt: "Wie prüfe ich eigentlich Audit Logging?" – findet dort Antworten und kann sich inspirieren lassen.

Zusammenarbeit und Feedback: Warum daraus Lernen entsteht

Der eigentliche Wert des Prozesses zeigt sich bei der Zusammenarbeit. In sogenannten Test Collaboration Meetings tauschen sich Entwickler und Tester aus: Welche Testarten passen, was gibt es zu beachten, wo lohnt sich Automatisierung und was bleibt manuell? Das Ziel ist, Überraschungen auszuschließen – am besten so früh wie möglich. Fehler, Missverständnisse oder Unsicherheiten werden vor der Umsetzung aufgedeckt. Das spart Zeit und Nerven, und schafft am Ende Vertrauen in das Produkt.

Lernen endet nach dem Rollout nicht. Interne Audits, Feedbackrunden und das Einholen von Expertenmeinungen bringen neue Erkenntnisse. Kein Prozess ist jemals fertig – und genau das macht ihn lebendig.

Wer Normen nur als Last sieht, übersieht einen wichtigen Vorteil: Sie bieten Struktur und zwingen zu Reflexion. Wenn Teams die Anforderungen gemeinsam angehen, sie anpassen und leben, entsteht mehr als nur eine abgehakte Checkliste. Es geht um Beständigkeit, Transparenz und ein Miteinander, das am Ende nicht nur vor Hackern schützt, sondern den Alltag im Unternehmen klarer und sicherer macht. Und manchmal kommt dabei auch Freude auf – selbst bei einer Norm wie der IEC 62443-4-1.