Mehr als Prinzipien: Wie man Security by Design endlich anpackt [German version]
Modellbasierte Cybersecurity-Entscheidungen treffen in 3 Schritten
Hast du auch so eine Autovervollständigung im Kopf: Sobald du “Security by Design” denkst, spuckt dein Hirn “Prinzipien” aus? Laut Google bist du damit nicht allein:
Das ist ein Problem. Denn wenn alles, was du mit “Security by Design” verbindest, eine Reihe hehrer Prinzipien ist, wie willst du es dann in deinen Engineeringprozess einbauen? Ich habe Ingenieurwesen studiert und ich kann mich nicht erinnern, dass irgendein Professor oder Lehrbuch gesagt hätte: “Wenn du diese 10 Prinzipien befolgst, kommt am Ende ein Auto dabei raus.”
Security by Design hat den unglücklichen Status eines unbestreitbaren Ideals. Über seine Wichtigkeit sind sich alle einig — und gleichzeitig ist die Einstellung akzeptabel geworden, dass Security by Design eben ein Ideal ist, also etwas, das man in der Realität ohnehin nie erreichen wird. Schuld an diesem Status ist auch, dass einem niemand sagt, wie man Security by Design tatsächlich umsetzt — und zwar so, dass am ein System dabei herauskommt, das man “secure by design” nennen könnte. Stattdessen werden Ingenieure mit dem hilfreichen Ratschlag allein gelassen, sie sollten “Secure Design Principles” beherzigen oder, noch schlimmer, im Hinterkopf behalten: “Defense in Depth”, “Least Privilege”, “Zero Trust”, “Input Validation”, “Fail Secure” usw.
Ganz ehrlich, was sollen Ingenieure damit anfangen? Über ihre Schreibtische kleben oder unter ihre Kissen legen und hoffen, dass diese Prinzipien in ihre Köpfe diffundieren und sie auf magische Weise Security im Kopf haben, während sie ihrem Engineering-Prozess wie gewohnt folgen?
Ich habe mich in den letzten drei Jahren mit Security by Design für industrielle Leitsysteme beschäftigt. Gleich zu Beginn, als wir den Status quo analysierten, seufzten Ingenieure mir entgegen, was ich schon seit Jahren immer wieder höre: “Wir würden ja gerne Security bei der Entwicklung berücksichtigen. Wenn uns nur jemand sagen würde, wie…”
Cybersecurity decision diagrams: In drei Schritten zu Security by Design
Das hier ist mein Versuch, mit diesem Wie zu helfen. In diesem Text werde ich die Vorgehensweise auf das absolut Nötige beschränken, um sie leichter verdaubar zu machen. Also, hier ist Ihr Security-by-Design-Workflow:
- Security-Entscheidungsbasis erstellen. Sie enthält alles, was beeinflussen könnte, wie Security-Entscheidungen getroffen werden.
- Das zu entwickelnde System in einem Cybersecurity-Entscheidungsmodell (“cyber model”) modellieren, das Architektur, Funktion (einschließlich Menschen!) und explizit gekennzeichnete Cybersecurity-Entscheidungen beinhaltet. Mit diesem Cyber-Modell kann man so früh wie möglich anfangen, immer so weit modellieren, wie das Engineering fortgeschritten ist, und es während des üblichen Engineeringprozesses Stück für Stück iterieren.
- Security-Entscheidungen treffen (und dokumentieren) — immer so weit es mit dem bis dahin existierenden Cyber-Entscheidungsmodell geht und natürlich auf Grundlage der Entscheidungsbasis.
- Schritte 2 und 3 wiederholen, bis das Engineering abgeschlossen ist.
Das ist alles. Security by Design tatsächlich umzusetzen, besteht im Kern aus zwei Dingen: die Entscheidungsbasis für Security-Entscheidungen im Voraus zu kennen und ein Cyber-Modell mit bewusst getroffenen Cybersecurity-Entscheidungen zu entwickeln, während man seinem üblichen Engineering-Workflow folgt.
Im Folgenden werde ich anhand eines Beispiels veranschaulichen, wie Security by Design in der Realität aussehen kann. Im Beispiel werden Teile eines industriellen Leitsystems (ICS) entwickelt, aber die gleichen drei Schritte können auch für andere Systeme verwendet werden.
1. Security-Entscheidungsbasis erstellen
Auch wenn viele Security-Methoden suggerieren, dass nur eine risikobasierte Entscheidung methodisch sauber ist, gibt es in der Realität viele Wege, auf denen Security-Entscheidungen getroffen werden.
Die vier Security-Entscheidungspfade, die ich in der Realität antreffe, sind
- zielbasierte Entscheidungsfindung
- risikobasierte Entscheidungsfindung
- compliance-basierte Entscheidungsfindung
- Entscheidungen basierend auf funktionalen Anforderungen oder Restriktionen
Security-Entscheidungen in deiner Organisation werden höchstwahrscheinlich eine gute Mischung aus den vier Kategorien sein. Jedes Unternehmen, das ich bislang gesehen habe, nutzt alle vier Entscheidungspfade gleichzeitig — und die Entscheidungen aufgrund von funktionalen Anforderungen machen einen erstaunlich hohen Prozentsatz aus. Es ist also sinnvoll, über alle vier Entscheidungspfade nachzudenken, wenn die Cybersecurity-Entscheidungsgrundlage erstellt wird:
Security-Ziele geben an, was die Cybersecurity für eine Organisation / das betrachtete System erreichen soll. Sie können mit Aussagen zur Verfügbarkeit, Integrität und Vertraulichkeit formuliert werden (“Verfügbarkeit der Safety-SPS und des Alarmservers”) oder auch freier (“Kein Zugriff auf die Safety-SPS von außerhalb der Anlage”).
High-Consequence Events (HCEs, auch bekannt aus INL CCE / CIE) sind unerwünschte Zustände des zu schützenden Systems (“Ethylenoxidanlage explodiert”).
Angriffsszenarien sind Szenarien, die für das betrachtete System schädlich sind und zu einem High-Consequence-Event führen können (“ein kritischer Wert wird gebrückt, sodass die Safety-Funktion im Anforderungsfall nicht ausgelöst wird”).
Security-Standards / Regulierungen, die eine Organisation befolgen will oder muss (“Gesetzgebung zum Schutz kritischer Infrastrukturen des Staates XY”/ “ISA/IEC 62443–3–3”).
Security-Anforderungen sind einzelne Anforderungen aus einem dieser Standards oder Regulierungen (“SR 5.1: Netzsegmentierung”).
Funktionale Anforderungen / Restriktionen definieren eine Systemfunktionalität — im Gegensatz zu nicht-funktionalen Anforderungen, die z.B. Sicherheit oder Zuverlässigkeit betreffen. Funktionale Anforderungen können den für Security-Entscheidungen zur Verfügung stehenden Lösungsraum einschränken (“Für die Wartung müssen alle Signale gebrückt werden können” / “Der Dienstleister kann Dateien nur über FTP empfangen”).
2. / 3. Cyber-Modell pflegen und Security-Entscheidungen treffen
Frühes Stadium des Engineering-Projekts
In einem frühen Stadium des Engineering-Projekts ist meist klar, was die gewünschten Systemfunktionen sind, aber es ist vielleicht noch nicht entschieden, wie die Funktionen ausgeführt werden sollen. Die Erstellung des Cybersecurity-Entscheidungsmodells kann und sollte jedoch bereits in diesem frühen Stadium beginnen, da hier bereits sehr grundlegende Cybersecurity-Entscheidungen getroffen werden — und die sollte man lieber bewusst treffen.
Als Beispiel schauen wir und diese Funktion an:
Auch wenn noch nichts über die Netzwerkarchitektur oder die verwendete Hard- und Software bekannt ist — dass Steuerungen programmiert werden müssen, steht wahrscheinlich schon früh fest und diese Funktion kann schon auf einem hohem Abstraktionsniveau modelliert werden.
Fragen, die bereits auf der Grundlage dieses sehr einfachen Cyber-Entscheidungsmodells diskutiert werden können: Wollen wir die Tatsache akzeptieren, dass es wahrscheinlich ein proprietäres Protokoll zwischen Engineering-Station und Safety-Steuerung geben wird? Wollen wir zusätzliche Security-Anforderungen wie Authentifizierung an das proprietäre Protokoll knüpfen? Soll dieselbe Engineering-Station auch für nicht safety-relevante SPSen verwendet werden? Wer außer dem Ingenieur wird noch mit der Engineering-Station interagieren? Soll ein physischer Schlüsselschalter an die Safety-SPS angeschlossen werden?
Die Antworten auf all diese Fragen sind Cybersecurity-Entscheidungen, und sie sollten als solche dokumentiert werden. So sieht zum Beispiel die Dokumentation für das proprietäre Protokoll und den physischen Schlüsselschalter im Beispiel aus:
Beide Entscheidungen sind in der Zeichnung explizit durch petrolblaue Icons gekennzeichent, und die Begründungen für die Entscheidungen werden durch Referenzieren von Elementen der Cybersecurity-Entscheidungsbasis geliefert (jetzt ist auch klar, warum in Schritt 1 diese Entscheidungsbasis feststehen muss, bevor die Modellierungsarbeit beginnt). Die Schlüsselschalterentscheidung ist auch ein gutes Beispiel dafür, wie Security-Entscheidungen zu Änderungen am Cyber-Modell (und damit dem System, das gerade designt wird) führen können.
Spätere Phase des Engineering-Projekts
In einer späteren Phase des Projekts wird das Systemmodell wahrscheinlich detaillierter sein. Möglicherweise wurde für die Komponenten in unserer Beispielfunktion jetzt bereits ein Hersteller ausgewählt:
Und auch die Netzwerkarchitektur, die unsere Beispielfunktion umgibt, könnte festgelegt worden sein:
Mit diesen zusätzlichen Informationen müssen weitere Security-Entscheidungen getroffen werden. In der Architektur ist das Hinzufügen oder Entfernen von Netzwerksegmenten fast immer eine Security-Entscheidung, z. B. die Hinzufügen eines separaten COM-Netzwerks für Schnittstellen zwischen SPS (blau) und Leitsystemkomponenten (grün). Die Security-Entscheidung wird nachstehend dokumentiert:
Außerdem sind viele Entscheidungen für die einzelnen Komponenten zu treffen. Beispiele für Security-Entscheidungen, die für die HIMAX X-CPU getroffen werden, werden hier aufgelistet:
Und hier ist ein Beispiel für eine dieser detaillierten Entscheidungen— der Mechanismus zur Integritätsprüfung. Die Entscheidung wurde im Beispiel (wenig überraschend) auf der Grundlage einer funktionalen Einschränkung getroffen:
Das Cybersecurity-Entscheidungsmodell kann geändert und verfeinert werden, bis das Engineering-Projekt abgeschlossen ist. Bis zum Abschluss des Engineering sollten alle Cybersecurity-Entscheidungen (gekennzeichnet durch die roten und petrolfarbenen Symbole in den Zeichnungen) getroffen und zusammen mit einer Begründung (Referenz auf die Entscheidungdbasis) dokumentiert sein.
Die Designphase ist nur ein kleiner Teil des Lebenszyklus eines jeden Systems. Cybersecurity ist dynamisch, und wahrscheinlich werden nicht alle Cybersecurity-Entscheidungen während des gesamten Lebenszyklus gültig bleiben. Ist das Cybersicherheits-Entscheidungsmodell jedoch erst einmal erstellt, können die Ingenieure es während des Betriebs weiter verwenden, z. B. wenn das System im Rahmen kleinerer Re-Engineering-Projekte geändert wird oder wenn sich der Kontext des Systems ändert, z. B. wenn neue Schwachstellen bekannt werden oder wenn die Entscheidungsbasis um zusätzliche Elemente wie neu in Kraft getretene Vorschriften ergänzt wird.
Die drei Schritte (1 — Entscheidungsbasis, 2 — modellieren, 3 — entscheiden) können für die Cybersecurity-Entscheidungsfindung während des Betriebs genauso angewendet werden wie während des Designs.
Schlussbemerkung
Der beschriebene Workflow ist die Minimalversion, die man kennen sollte, wenn man anfängt, Security in den eigenen Engineering-Workflow zu integrieren. Um ihn so verständlich wie möglich zu beschreiben, habe ich bewusst einige Details weggelassen, zum Beispiel:
- Es gibt noch mehr über die Entscheidungsbasis zu sagen, z. B. die Entscheidungswege, auf denen sie beruht. Außerdem können Angriffsszenarien auch im Cyber-Modell visualisiert werden.
- Es gibt noch mehr zu der Frage zu sagen, wie Sie die Punkte in Ihrem üblichen Engineering-Workflow identifizieren können, die eine Überarbeitung Ihres Cybersecurity-Entscheidungsmodells auslösen sollten — wir nennen sie Cybersecurity-Entscheidungspunkte.
- Es gibt noch mehr darüber zu sagen, wie das Cyber-Modell schneller erstellt werden kann und wie die Cybersecurity-Entscheidungen im Modell auch von Nicht-Security-Experten identifiziert und getroffen werden können.
Zu jedem dieser Themen werde ich eigene Beiträge veröffentlichen.
Die beschriebenen Methoden sind im Rahmen des Forschungsprojekts “IDEAS” entstanden. Alle Veröffentlichungen im Zusammenhang mit dem Projekt sind unter diesem Link zu finden.
