Was mir immer wieder auffällt: Sichere Entwicklung gelingt, wenn Interesse auf Expertise trifft

Ein Muster, das mir immer wieder begegnete

Ein sicherer Softwareentwicklungszyklus (Secure SDLC) soll aus „uns ist Sicherheit wichtig“ in jeder Phase wiederholbare, nachgewiesene Arbeit machen — Anforderungen, Design, Implementierung, Verifizierung, Freigabe und Wartung. Auf dem Papier hatten die Teams, mit denen ich arbeitete, genau das. In Wirklichkeit waren manche dieser Zyklen lebendig und manche nur laminiert. Der Unterschied lag nie am Diagramm. Er lag daran, ob hinter den Aktivitäten im Diagramm jemand stand, dem sie am Herzen lagen.

Als ich mich endlich richtig mit der IEC 62443-4-1 befasste, traf mich vor allem die Reihenfolge. Die Norm legt acht Praktiken dar, und sie beginnt nicht mit Bedrohungsmodellierung oder sicherer Programmierung — den Teilen, über die alle reden wollen. Sie beginnt mit dem Sicherheitsmanagement (Praktik 1). Zuerst fühlte sich das nach Bürokratie an. Heute lese ich es so, dass die Norm dasselbe an den Anfang stellt, was mich die Erfahrung auf die harte Tour gelehrt hat: Bringt man die Menschen in Ordnung, wird der Rest möglich. Lässt man das aus, greift keine der Praktiken darüber jemals wirklich.

Zwei Anforderungen in dieser ersten Praktik sind mir am wichtigsten. SM-2, Identifizierung der Verantwortlichkeiten, verlangt, dass Sie benennen, wer jede Sicherheitsaktivität verantwortet. SM-4, Sicherheitsexpertise, verlangt, sicherzustellen, dass diese Menschen die Kompetenz auch besitzen — und sie darauf hinzuschulen, falls nicht. Die eine benennt den Verantwortlichen; die andere macht ihn real. Sie klingen nach Verwaltung. Sie sind, meiner Erfahrung nach, der Ort, an dem sich das Ganze entscheidet.

SM-2: die Aktivitäten, die niemandem gehörten, verschwanden

Das Klarste, was ich je über SM-2 gelernt habe, lernte ich, indem ich zusah, wie es missachtet wurde. In mehr als einem Team gehörte irgendeine Sicherheitsaktivität — Triage von Abhängigkeiten, ein Bedrohungsmodell im Design-Review, die Freigabe zur Auslieferung — „dem Team“, also niemandem. Sie scheiterte nicht laut. Sie fand schlicht nie statt, Monat um Monat, und jeder nahm an, jemand anderes habe sie. Die Lücke tauchte erst auf, als ein Auditor fragte — oder schlimmer, als etwas durchrutschte, das ein benannter Verantwortlicher aufgefangen hätte.

Wenn SM-2 also darauf besteht, dass jede sicherheitsbezogene Aktivität einen benannten Verantwortlichen hat — eine konkrete Rolle, konkrete Personen, keine Geste in Richtung der Gruppe — dann lese ich das als eine Lektion, für die ich bereits bezahlt hatte, in Normform gegossen. Einen Verantwortlichen zu benennen ist das, was einer Aktivität einen Puls gibt. Es macht Verantwortung auch nachvollziehbar: Jemand kann jede Aktivität zu der Person zurückverfolgen, die dafür einsteht, und das Team erkennt seine eigenen Lücken, bevor es jemand von außen tut. Ich hielt das früher für Papierkram. Ist es nicht. Es ist der Unterschied zwischen einem Prozess, der existiert, und einem, der es bloß zu tun scheint.

SM-4: aber ein Name auf dem Kästchen genügte nie

Die andere Hälfte der Lektion war, dass es nichts bringt, einen Verantwortlichen zu benennen, wenn ihm nie gezeigt wurde, wie es geht. Ich sah fähige, willige Entwickler eine Verantwortung für Bedrohungsmodellierung übernehmen, ohne jede Grundlage darin, und etwas produzieren, das das Kästchen abhakte und nichts fing — nicht aus Nachlässigkeit, sondern weil niemand die Lücke zwischen der Aufgabe und ihrer Ausbildung geschlossen hatte. Genau dafür ist SM-4 da: die Sicherheitsexpertise der Personen bewerten, die jede Verantwortung tragen, und die Weiterbildung bereitstellen, die sie auf das von der Rolle geforderte Niveau bringt — das Ganze aufgezeichnet, sodass Kompetenz nachgewiesen und nicht unterstellt wird.

Legt man SM-2 und SM-4 zusammen, ergibt sich eine Schleife, die ich früher hätte verstehen sollen: Verantwortlichkeiten bestimmen, sie Personen zuweisen, prüfen, ob diese Personen qualifiziert sind, und schulen, wo sie es nicht sind. Diese Schleife ist das menschliche Fundament, auf dem die technischen Praktiken sitzen. Eine hervorragende Methode ist wertlos in den Händen von jemandem, dem nie beigebracht wurde, sie zu nutzen — und SM-4 existiert, damit sich diese Lücke nicht aus Versehen öffnet.

Wo es wirklich funktionierte: Interesse trifft Expertise

Hier kommt der Teil, den die Norm andeutet, den ich aber erst dadurch wirklich lernte, dass ich die Ergebnisse auseinanderlaufen sah. Wissen und Erfahrung sind notwendig, aber für sich allein waren sie nie das, was ein Team sicher machte. Die Teams, die es hinbekamen, hatten am Fundament Menschen, denen Sicherheit wirklich am Herzen lag — und ebenso sehr daran, sie im Team zu fördern und zu kontrollieren, statt sie zu horten. Ich sah reichlich qualifizierte Leute Sicherheit als lästige Pflicht behandeln, und ihr Kästchen-Abhaken schützte niemanden. Ich sah einige wenige Engagierte still das Niveau aller um sie herum anheben. Der Unterschied zwischen diesen beiden Ergebnissen war Interesse, nicht das Zertifikat.

Deshalb behandle ich SM-2, wenn es Sie auffordert, Verantwortlichkeiten zuzuweisen, inzwischen als Entscheidung von der Tragweite einer Einstellung und nicht als Eintrag im Organigramm. Die Menschen, die sichere Entwicklung zum Funktionieren brachten, waren erkennbar, bevor man ihnen den Titel gab: die Entwicklerin, die in Design-Reviews ohnehin die unbequemen Fragen stellt, neugierig, wie Dinge kaputtgehen, bereit, eine Linie zu halten, wenn ein Termin dagegen drückt. Kompetenz gepaart mit dieser Überzeugung verwandelte eine zugewiesene Verantwortung in eine gelebte. Kompetenz allein wurde meist zu Dokumentation.

• Wissen und Erfahrung — die Grundlage, die SM-4 bewertet. Notwendig und von den dreien am leichtesten zu prüfen. Zugleich, für sich allein, am wenigsten aussagekräftig dafür, ob es gut läuft.
• Echtes Interesse — das, was ich heute am stärksten gewichte. Es trägt die Arbeit durch die lange Strecke zwischen den Audits, wenn niemand hinsieht.
• Ein Gespür für Fördern und Kontrollieren — die Bereitschaft, bei Kolleginnen und Kollegen für sichere Praxis zu werben und das Team dazu anzuhalten, statt Sicherheit allein in einer Ecke zu verwalten.

Der Security Champion: die Rolle, in der ich es zusammenkommen sah

Der Ort, an dem ich Verantwortung und Expertise am häufigsten in einer Person zusammenfallen sah, war der benannte Security Champion — eingebettet im Produktteam, nicht abgestellt in einer abgekoppelten zentralen Funktion. Wo es funktionierte, war der Champion SM-2 und SM-4 in Fleisch und Blut: ein benannter Eigentümer der Sicherheit innerhalb des Teams, dessen Expertise tatsächlich entwickelt und gezeigt worden war. Er war der alltägliche Fürsprecher — moderierte Bedrohungsmodelle, pflegte den sicheren Programmierstandard, war erster Eskalationspunkt, bildete die Brücke zum verantwortlichen Eigner darüber. Teams mit einem echten Champion fühlten sich anders an. Sicherheit war ein Gespräch, keine Inspektion.

Hier änderte ich auch meine Meinung über Schulung und Zertifizierung. Ich war Zertifikaten gegenüber früher skeptisch. Was ich zu sehen lernte: Sie leisten zwei wirklich nützliche Dinge für einen Champion. Sie geben einen strukturierten Weg zu der von SM-4 geforderten Expertise — und, das habe ich unterschätzt, sie geben der Person Standing. Einem Champion, der eine anerkannte Zertifizierung für sichere Entwicklung oder Produktsicherheit erworben hat, wird in einem Design-Review anders zugehört. Das Zertifikat ist nicht der Punkt; der Punkt ist die Glaubwürdigkeit, sichere Praxis zu fördern, und die Autorität, ihre Einhaltung zu kontrollieren. Und praktischerweise wird eben diese Zertifizierung Teil des Nachweises, dass SM-4 erfüllt ist.

Was ich daraus mitnehme

Die IEC 62443-4-1 stellt das Sicherheitsmanagement an den Anfang, und nach allem, was ich gesehen habe, halte ich das für richtig. Ein Zyklus ist immer nur so solide wie die Menschen, die ihn betreiben. SM-2 lässt Sie benennen, wer jede Aktivität verantwortet; SM-4 lässt Sie nachweisen, dass diese Person dafür befähigt ist. Meine eigene Version derselben Idee ist schlichter: Es funktionierte am besten, wenn Interesse und Expertise in derselben Person zusammentrafen, und am schlechtesten, wenn wir das eine ohne das andere hatten. Wählen Sie Menschen mit Wissen, Erfahrung und einem echten Antrieb, Sicherheit zu fördern und zu kontrollieren; investieren Sie in ihre Schulung; benennen und befähigen Sie Champions wirklich; und halten Sie diese Entwicklung in Gang. Tun Sie das, haben die technischen Praktiken darüber endlich etwas Festes, worauf sie stehen.