Die Europäische Cybersecurity-Behörde ENISA hat den Entwurf für ein "Secure by Design and Default Playbook" veröffentlicht.

Ich empfehle die Lektüre, denn die Idee ist gut: Der Kern des Dokuments ist eine Checkliste mit den wichtigsten Secure-by-Design-Prinzipien samt Prüffragen (Release Gates), die Hersteller vor jedem Release durchgehen können. Das hilft sicher vielen Herstellern, nicht nur den kleinen und mittleren Unternehmen, an die sich das Dokument explizit richtet.

Stärken und Schwächen im Überblick

Vieles an dem Entwurf ist gut, aber einiges ginge besser.

Seine Stärken liegt in der sehr konkreten Checklisten (Kapitel 4) und in der so wichtigen wir richtigen Entscheidung, trotz Checkliste einen risikobasierten Ansatz beizubehalten. Gerade letzteres kann man nicht positiv genug hervorheben.

Seine Schwächen liegen in Scope und Struktur der Checklisten: Beim Versuch, mit dem Begriff "Security by Design" irgendwie doch die komplette Security (und alle Essential Requirements des CRA) zu erschlagen, sind einige methodische Stilblüten entstanden, die Leser ordentlich verwirren dürften.

Im Folgenden sehen wir uns einige dieser Punkt detaillierter an.

Risikobasierter Ansatz

Es ist gut, dass der risikobasierte Ansatz ein eigenes Kapitel bekommen hat. Es ist auch gut, dass dieses Kapitel sehr konkrete Lieferleistungen (Deliverables) beinhaltet, die aus der Risikoanalyse herauskommen sollten — und dass diese sehr konkret und sehr schlank gehalten sind; das nimmt dem Thema Risikoanalyse den Schrecken.

Was im Dokument vorkommt, aber klarer werden könnte: Welche Rolle der risikobasierte Ansatz denn nun für Security-Entscheidungen spielt, nämlich: Security-Anforderungen zu priorisieren und sich auch mal GEGEN bestimmte Anforderungen zu entscheiden — auch wenn sie in irgendwelchen Security-Prinzipien-Listen stehen. In der Checkliste können aus dem Threat Modelling zusätzliche Requirements kommen — aber es können keine als "aufgrund der Risikoanalyse nicht relevant" markiert werden. Da wären wir dann auch bei den Grenzen einer Checkliste.

Was gut ist: Das Threat Modeling ist direkt das erste Grundprinzip der Checkliste, und bei den Prüffragen (Release Gates) müssen Produktdiagramm und Threat Model aktualisiert werden. Und dann fehlt der wichtigste Schritt: Was heißt das denn nun für meine Security-Anforderungen / den Rest der Checkliste? So bleibt das Threat Model nur Beschäftigungstherapie und wird — meine Prognose — spätestens beim dritten Durchlauf der Checkliste nicht mehr aktualisiert. Warum auch? Es hat ja keinerlei Auswirkungen. Nun stellen wir uns vor, wie motiviert Entwickler wären, ein Threat Model zu aktualisieren, wenn sich damit potenziell ein Haufen Security-Anforderungen erledigt hätten…

Risikoanalyse vs Threat Modeling

Das ist die erste begrifflich-methodische Unschärfe: Risikoanalyse und Threat Model stehen im Dokument seltsam nebeneinander, mit dem Satz, ein Threat Model wäre "eine Form der Risikoanalyse". Können wir diesen Mythos bitte endlich beerdigen? Zu einer Risikoanalyse gehören mindestens

1 — Beschreibung des Systems und seines Kontexts inkl. Schutzzielen, 2 — die Beschreibung und Bewertung von Risikoszenarien, 3 — die Festlegung von Security-Anforderungen und 4 — die Kommunikation der Ergebnisse.

Und das Threat Modeling? Genau, das ist ein Teil von Punkt 2. Threat Modeling ist ein Teil der Risikoanalyse. Die Begriffe werden sowieso schon ständig durcheinandergeworfen. Gerade in der Software-Entwicklung, vermutlich weil viele Secure-Development-Lifecycle-Standards nur Threat Modeling, nicht aber Risikoanalysen kennen. Es wäre wichtig, dass eine ENISA-Publikation nicht noch zur Verwirrung beiträgt.

Security by Design vs Secure Operations

A propos Verwirrung: Noch viel wichtiger als die Unschärfen zwischen Risikoanalyse und Threat Modeling ist die Unschärfe, die das Playbook in den Begriff "Security by Design" bringt.

Die Definition ist in Ordnung: "Security by Design embeds protective measures into products during development". Aber dann hält sich das Dokument leider nicht an seine eigene Definition. Stattdessen wird Security by Design aufgeteilt in "Architectural Foundations" und "Operational Integrity" — wahrscheinlich Zeugnis des Versuchs, Security by Design so weit zu fassen, dass alle Essential Requirements des CRA damit abgedeckt werden. Da wird plötzlich Lifecycle Management, Change Management und sogar Incident Response als Teil von "Security by Design" deklariert.

Wenn man mich fragt (nicht, dass das jemand getan hätte): "Secure by Design" braucht keine weitere Aufteilung, und was nicht zum Design gehört, gehört nicht in diese Checkliste.

Das führt nämlich dazu, dass in der Release-Checkliste plötzlich Fragen auftauchen, die für Security sicher wichtig sind, aber weder mit Security by Design noch mit dem einzelnen Release viel zu tun haben: Zum Beispiel die Frage, ob die Kontaktadresse für Schwachstellenmeldungen noch korrekt ist. Es täte dem Dokument gut, solche Fragen wegzulassen oder vor die Klammer zu ziehen.

Prüffragen (Release Gates)

Damit wären wir auch beim letzten Kritikpunkt: Die Checkliste, gedacht als schlankes Instrument für kleine Unternehmen, ist zu lang.

Vorab: Die Checkliste, und insbesondere die Release Gates (Prüffragen), sind ein echter Mehrwert und solide Arbeit der ENISA. Wenn ein Hersteller nichts anderes mit diesem Dokument tut, als diese Prüffragen vor jedem Release durchzugehen, ist er mit seiner Security ein ordentliches Stück weiter.

Aber: Die Liste enthält 22 Prinzipien mit je 4–6 Prüffragen. Das sind weit über hundert Fragen, die Entwickler durchgehen müssen. Bei. Jedem. Release.

Dabei wäre viel Kürzungspotenzial da. Die organisatorischen Themen, die mit dem Release nichts zu tun haben (s.o.) könnten raus. Und es ist viel Redundanz in der Liste: Die Frage, ob die SBOM neu generiert wurde, habe ich mindestens drei Mal gefunden.

Premium wäre: Wenn es ein paar Vorab-Fragen gäbe, durch die die Liste klug vorgefiltert würde, soll heißen: Wenn bestimmte Fragen mit "Nein" beantwortet werden, sind die Punkte nicht mehr relevant. Denn: Auch Entwickler sind Menschen….je kürzer und relevanter die Checkliste, je höher die Chance, dass Entwickler sie auch wirklich ernsthaft durchgehen.

Beispiel für so eine Vorab-Frage: "Hat sich die Authentifizierung in diesem Release verändert?" Falls nein, fällt der ganze Teil zu Multifaktorauthentifizierung etc. weg. Wenn man es ganz klug macht, verknüpft man diese Fragen mit dem Update des Produktdiagramms im Rahmen der Risikoanalyse. Aber dazu, schwant mir, muss ich zukünftig mal einen eigenen Beitrag schreiben.

Software-Fokus

Letzer Punkt aus OT-Sicht: Das Playbook hat einen deutlichen Fokus auf Software — und zwar natürlich Software im IT-Sinne. Hersteller von eingebetteten / feldnahen Komponenten und industriellen Steuerungen dürften sich mit der Anwendung der Checkliste schwerer tun, weil sie eher nicht mitgemeint sind.

Dieser Text ist Teil meines monatlichen "Security Briefing für Hard Hats". Kostenlos abonnieren können Sie es hier (auf Deutsch) oder hier (auf Englisch).

Wer Software sucht, mit der man Produktdiagramme, Threat Modeling, Requirements Engineering und CRA-Compliance effizient hinbekommt, werfe einen Blick auf unser Security Engineering Tool.