Bedrohungsmodellierung

Kapitel 1. Systeme modellieren

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Alle Modelle sind falsch, aber einige sind nützlich.

G. E. P. Box, "Science and Statistics", Journal of the American Statistical Association, 71 (356), 791-799, doi:10.1080/01621459.1976.10480949.

Die Systemmodellierung (Erstellung von Abstraktionen oder Darstellungen eines Systems) ist ein wichtiger erster Schritt im Prozess der Bedrohungsmodellierung. Die Informationen, die du aus dem Systemmodell sammelst, dienen als Grundlage für die Analyse während der Bedrohungsmodellierung.

In diesem Kapitel geht es um die verschiedenen Arten von Systemmodellen, die Gründe, warum du dich für eine bestimmte Art von Modell entscheidest, und die Anleitung zur Erstellung der effektivsten Systemmodelle. Wenn du die Konstruktion von Systemmodellen beherrschst, kannst du deine Bedrohungsmodelle präziser und effektiver analysieren und Bedrohungen erkennen.

Hinweis

In diesem Kapitel verwenden wir die Worte Modell oder Modellierung für eine Abstraktion oder Darstellung eines Systems, seiner Komponenten und Interaktionen.

Warum wir Systemmodelle erstellen

Stell dir eine Gruppe von Benediktinermönchen vor, die sich die Klosterkirche von St. Gallen und dann ein Manuskript anschauen, hin und her. Irgendwann wendet sich einer an die anderen und sagt: "Also, hört mal, das war kein Plan per se. Es war eher eine 'zweidimensionale Meditation über die ideale frühmittelalterliche Mönchsgemeinschaft'."¹ Das ist der Sinn des Plans von St. Gallen, der als älteste erhaltene zweidimensionale Visualisierung und Plan eines Gebäudekomplexes gilt. Die Kirche sieht ganz anders aus als auf dem Plan.

Menschen erstellen Modelle, um vorauszuplanen oder um zu entscheiden, welche Ressourcen benötigt werden, welche Rahmenbedingungen geschaffen werden müssen, welche Hügel versetzt und welche Täler aufgefüllt werden müssen und wie unabhängige Teile zusammenwirken werden, wenn sie einmal zusammengefügt sind. Menschen erstellen Modelle, weil es einfacher ist, Veränderungen in einem schematischen, kleineren Maßstab zu visualisieren, als sofort mit dem Bau zu beginnen. Es ist einfacher und billiger, Änderungen an diesem Schema vorzunehmen und das Zusammenspiel dieser Teile zu verändern, als nachträglich Wände, Rahmen, Schrauben, Motoren, Böden, Flügel, Firewalls, Server, Funktionen oder Codezeilen zu verschieben.

Wir sind uns auch bewusst, dass das Modell und das Endergebnis zwar voneinander abweichen können, aber ein Modell hilft immer dabei, Nuancen und Details zu verstehen, die für den Herstellungs- und Bauprozess relevant sind. Für Sicherheitszwecke modellieren wir vor allem Software- und Hardwaresysteme, weil wir so die Systeme theoretischen Belastungen aussetzen können, um zu verstehen, wie sich diese Belastungen auf die Systeme auswirken, bevor sie implementiert werden, und weil wir die Systeme ganzheitlich betrachten können, um uns bei Bedarf auf Details der Schwachstellen zu konzentrieren.

Im weiteren Verlauf dieses Kapitels zeigen wir dir die verschiedenen visuellen Formen, die dein Bedrohungsmodell annehmen kann, und erklären dir, wie du die notwendigen Informationen für die Systemanalyse sammelst. Welche Maßnahmen du nach der Erstellung deines Modells ergreifst, hängt von der Methodik ab, für die du dich entscheidest; wir werden in den nächsten Kapiteln auf die Methoden eingehen.

Arten der Systemmodellierung

Wie du weißt, können Systeme komplex sein, mit vielen beweglichen Teilen und Wechselwirkungen zwischen den Komponenten. Menschen werden nicht mit umfangreichem Sicherheitswissen geboren (auch wenn wir einige kennen, bei denen das durchaus der Fall war), und die meisten Systemdesigner und -entwickler wissen nicht genau, wie Funktionen missbraucht werden können. Wer also sicherstellen will, dass seine Systemanalyse sowohl praktisch als auch effektiv ist, muss die Komplexität und die Menge der zu berücksichtigenden Daten für die Analyse reduzieren und die richtige Menge an Informationen bereithalten.

An dieser Stelle kommt die Systemmodellierung oder eine Abstraktion eines Systems, die seine wichtigsten Teile und Eigenschaften beschreibt, zum Tragen. Mit einer guten Abstraktion des Systems, das du analysieren willst, erhältst du genügend Informationen, um fundierte Sicherheits- und Designentscheidungen zu treffen.

Modelle werden seit Jahrhunderten verwendet, um Ideen auszudrücken oder anderen Wissen zu vermitteln. Die Grabbaumeister im alten China fertigten Modelle von Gebäuden an,² und Architekten haben seit den alten Ägyptern routinemäßig maßstabsgetreue Modelle erstellt, um die Machbarkeit und die Absichten eines Entwurfs zu demonstrieren.³

Bei der Erstellung eines Systemmodells - einer Abstraktion oder Darstellung eines Systems, das auf Bedrohungen hin analysiert werden soll - können ein oder mehrere Modelltypen verwendet werden:⁴

Datenflussdiagramme

Datenflussdiagramme (DFDs) beschreiben den Datenfluss zwischen den Komponenten eines Systems und die Eigenschaften der einzelnen Komponenten und des Datenflusses. DFDs sind die am häufigsten verwendete Form von Systemmodellen in der Bedrohungsmodellierung und werden von vielen Zeichenpaketen nativ unterstützt; Formen in DFDs sind auch für Menschen leicht von Hand zu zeichnen.

Sequenzdiagramme

Dies sind Aktivitätsdiagramme in der Unified Modeling Language (UML), die die Interaktionen der Systemkomponenten in geordneter Weise beschreiben. Sequenzdiagramme können dabei helfen, Bedrohungen für ein System zu erkennen, weil sie es einem Designer ermöglichen, den Zustand des Systems im Laufe der Zeit zu verstehen. So kannst du sehen, wie sich die Eigenschaften des Systems und die damit verbundenen Annahmen oder Erwartungen im Laufe seines Betriebs ändern.

Prozessablaufdiagramme

Prozessablaufdiagramme (PFDs) zeigen den Betriebsablauf durch Aktionen zwischen den Komponenten eines Systems.

Bäume angreifen

Angriffsbäume stellen die Schritte entlang eines Pfades dar, die ein Angreifer versuchen könnte, um sein Ziel zu erreichen und Aktionen mit schändlichen Absichten durchzuführen.

Fishbone-Diagramme

Diese Diagramme, die auch als Ursache-Wirkungs-Diagramme oder Ishikawa-Diagramme bezeichnet werden, zeigen die Beziehungen zwischen einem Ergebnis und den Ursachen, die das Eintreten dieses Ergebnisses ermöglicht haben.

Einzeln oder in Kombination kannst du diese Systemmodellierungstechniken einsetzen, um die Veränderungen in der Sicherheitslage zu erkennen, die einem Angreifer die Arbeit erleichtern. Das ist wichtig, damit Designer/innen potenzielle Probleme erkennen und beseitigen können, indem sie ihre Entwürfe oder Annahmen über das System ändern. Verwende verschiedene Modelltypen für die Zwecke, für die sie am besten geeignet sind. Verwende z. B. DFDs, um die Beziehungen zwischen Objekten zu beschreiben, und Sequenzdiagramme, um die Reihenfolge von Vorgängen zu beschreiben. Wir werden jeden dieser Modelltypen im Detail untersuchen, damit du die Vorteile jedes einzelnen verstehen kannst.

Datenflussdiagramme

Bei der Modellierung eines Systems zur Durchführung einer Sicherheitsanalyse haben Experten DFDs als eine nützliche Methode zur visuellen Beschreibung eines Systems identifiziert. DFDs wurden mit einer Symbolik entwickelt, die die Komplexität von Systemen ausdrückt.

Die Verwendung von Modellen zum Verständnis der Komponenten eines Systems und ihrer Beziehungen zueinander wurde in den 1950er Jahren mit dem Funktionsablaufplan eingeführt. Später, in den 1970er Jahren, wurde mit der strukturierten Analyse- und Entwurfstechnik das Konzept des DFD eingeführt.⁵ DFDs sind zu einer Standardmethode geworden, um ein System zu beschreiben, wenn eine Bedrohungsanalyse durchgeführt wird.

DFDs haben Levels

Datenflussdiagramme ergeben oft mehrere Zeichnungen, von denen jede eine Schicht oder Abstraktionsebene darstellt. Die oberste Ebene wird manchmal als Kontextebene, Ebene 0 oder einfach L0 bezeichnet und enthält das System aus einer übergeordneten Sicht und seine Interaktionen mit externen Einheiten wie entfernten Systemen oder Benutzern. Nachfolgende Schichten, die als L1, L2 usw. bezeichnet werden, gehen detaillierter auf die einzelnen Systemkomponenten und Interaktionen ein, bis der angestrebte Detaillierungsgrad erreicht ist oder durch eine weitere Zerlegung der Systemelemente kein zusätzlicher Nutzen mehr erzielt werden kann.

Es gibt zwar keinen formalen Standard, der die Formen definiert, die bei der Modellierung des Datenflusses eines Systems verwendet werden, aber viele Zeichnungspakete verwenden eine Konvention, um Formen und ihre Bedeutung und Verwendung zuzuordnen.

Bei der Erstellung von DFDs ist es sinnvoll, bestimmte Architekturelemente neben den Datenflüssen hervorzuheben. Diese zusätzlichen Informationen können hilfreich sein, wenn duversuchst, genaue Entscheidungen zu treffen, während du das Modell im Hinblick auf Sicherheitsaspekte analysierst oder wenn du das Modell verwendest, um Personen, die neu im Projekt sind, zu unterrichten. Wir stellen dir drei nicht standardisierte Erweiterungsformen zur Verfügung. Sie dienen als Abkürzungen, mit denen du deine Modelle leichter erstellen und verstehen kannst.

Ein Element (in Abbildung 1-1 dargestellt) ist eine Standardform die einen Prozess oder eine Betriebseinheit innerhalb des betrachteten Systems darstellt. Du solltest dein Element immer beschriften, damit du in Zukunft leicht darauf zurückgreifen kannst. Elemente sind die Quelle und/oder das Ziel für Datenflüsse (später beschrieben) zu und von anderen Einheiten im Modell. Um menschliche Akteure zu identifizieren, verwendest du das Akteurssymbol (siehe Abbildung 1-4 ).

Abbildung 1-1. Elementsymbole zum Zeichnen von Datenflussdiagrammen

Du solltest auch jedes Objekt mit einer Beschreibung seiner grundlegenden Eigenschaften und Metadaten versehen. Du kannst die Anmerkungen auf dem Diagramm selbst oder in einem separaten Dokument anbringen und dann die Beschriftung verwenden, um die Anmerkung mit dem Objekt zu verknüpfen.

Im Folgenden findest du eine Liste möglicher Informationen, die du in Anmerkungen zu Objekten im Modell erfassen möchtest:

Hinweis

Diese Liste möglicher Metadaten, die du über ein Element als Anmerkungen zum Modell erhalten kannst, ist nicht vollständig. Die Informationen, die du über die Elemente in deinem System wissen musst, hängen von der Methodik ab, für die du dich letztendlich entscheidest (siehe Kapitel 3 bis 5), sowie von den Bedrohungen, die du zu identifizieren versuchst. Diese Liste enthält einige der Optionen, die dir begegnen können.

• Name der Einheit. Wenn es sich um eine ausführbare Datei handelt, wie wird sie genannt, wenn sie erstellt oder auf einem Datenträger installiert wird?

• Wer ist in deinem Unternehmen dafür zuständig (normalerweise das Entwicklungsteam)?

• Wenn es sich um einen Prozess handelt, mit welcher Berechtigungsstufe läuft er (z. B. immer root, setuid oder ein nicht privilegierter Benutzer)?

• Wenn es sich um ein binäres Objekt handelt, muss es digital signiert werden, und wenn ja, mit welcher Methode und/oder welchem Zertifikat oder Schlüssel?

• Welche Programmiersprache(n) werden für das Element verwendet?

• Welcher Laufzeit- oder Bytecode-Prozessor wird für verwalteten oder interpretierten Code verwendet?

Hinweis

Oft wird übersehen, welchen Einfluss die Wahl der Programmiersprache hat. C und C++ sind zum Beispiel anfälliger für speicherbasierte Fehler als eine interpretierte Sprache, und ein Skript lässt sich leichter zurückentwickeln als eine (möglicherweise verschleierte) Binärdatei. Dies sind wichtige Eigenschaften, die du bei der Entwicklung des Systems kennen solltest, vor allem wenn du sie bei der Bedrohungsmodellierung feststellst, um häufige und ernsthafte Sicherheitsprobleme zu vermeiden. Wenn du diese Informationen nicht früh genug im Systementwicklungsprozess erfährst, um sie in das Bedrohungsmodell aufzunehmen (denn, wie du vielleicht schon weißt, sollte die Bedrohungsmodellierung früh und oft durchgeführt werden), ist dies ein perfektes Beispiel dafür, warum Bedrohungsmodelle auf dem neuesten Stand gehalten werden sollten , wenn sich das System weiterentwickelt. ⁶

Es gibt einige zusätzliche Metadaten, die Kontext und Möglichkeiten für eine tiefergehende Bewertung sowie die Diskussion zwischen den Entwicklungsteams und den Stakeholdern des Systems bieten, die du in Betracht ziehen solltest:

• Ist die Einheit produktionsbereit oder eine Entwicklungseinheit oder existiert das Element nur in Teilzeit? Existiert die Einheit zum Beispiel nur in Produktionssystemen, aber nicht im Entwicklungsmodus? Das kann bedeuten, dass der Prozess, der durch das Element repräsentiert wird, in bestimmten Umgebungen nicht ausgeführt oder initialisiert werden kann. Oder er ist nicht vorhanden, z. B. weil er herauskompiliert wird, wenn bestimmte Kompilierflags gesetzt sind. Ein gutes Beispiel dafür ist ein Testmodul oder eine Komponente, die nur in einer Staging-Umgebung ausgeführt wird, um Tests zu erleichtern. Es wäre wichtig, sie im Bedrohungsmodell aufzuführen. Wenn das Modul über bestimmte Schnittstellen oder APIs arbeitet, die in der Staging-Umgebung offen sind, um das Testen zu erleichtern, aber in der Produktionsumgebung offen bleiben, obwohl das Testmodul entfernt wurde, dann ist dies eine Schwachstelle, die behoben werden muss.

• Gibt es Informationen über den erwarteten Ausführungsablauf, und kann er durch einen Zustandsautomaten oder ein Sequenzdiagramm beschrieben werden? Sequenzdiagramme können dabei helfen, Schwachstellen zu erkennen, wie wir später in diesem Kapitel erläutern werden.

• Optional: Verwendet sie bestimmte Flags beim Kompilieren, Linken oder Installieren oder hat sie diese aktiviert,⁷ oder wird sie von einer SELinux-Richtlinie abgedeckt, die sich von der Standardeinstellung des Systems unterscheidet? Wie bereits erwähnt, weißt du das vielleicht noch nicht, wenn du das erste Bedrohungsmodell erstellst, aber es bietet dir eine weitere Möglichkeit, das Bedrohungsmodell im Laufe des Projekts auf dem neuesten Stand zu halten.

Verwende das Elementsymbol, um eine in sich geschlossene Verarbeitungseinheit darzustellen, z. B. eine ausführbare Datei oder einen Prozess (je nach Abstraktionsebene), bei der eine Unterteilung des Elements in repräsentative Komponenten wahrscheinlich nicht dazu beiträgt, zu verstehen, wie die Einheit funktioniert und für welche Bedrohungen sie möglicherweise anfällig ist. Das kann etwas Übung erfordern - manchmal musst du die Unterelemente der Verarbeitungseinheit beschreiben, um die darin enthaltenen Wechselwirkungen besser zu verstehen. Um Unterelemente zu beschreiben, verwendest du ein Container-Symbol.

Ein Container oder Containerelement, wie in Abbildung 1-2 dargestellt, ist eine weitere Standardform, die eine Einheit innerhalb des betrachteten Systems darstellt, die zusätzliche Elemente und Flüsse enthält. Diese Form wird normalerweise in der Kontextebene (siehe "DFDs haben Ebenen") eines Modells verwendet, um die wichtigsten Einheiten innerhalb des Systems hervorzuheben. Wenn du Containerelemente erstellst, signalisierst du damit, dass du die enthaltenen Elemente verstehen musst und dass der Container die kombinierten Interaktionen und Annahmen aller enthaltenen Elemente darstellt. Es ist auch eine gute Möglichkeit, die Unübersichtlichkeit eines Modells zu reduzieren. Container können die Quelle und/oder das Ziel für Daten sein, die zu und von anderen Modellelementen fließen, wenn sie auf einer bestimmten Abstraktionsebene vorhanden sind.

Abbildung 1-2. Container-Symbole zum Zeichnen von Datenflussdiagrammen

Wie bei dem zuvor beschriebenen Element solltest du deinen Container-Objekten eine Bezeichnung zuweisen,, und Metadaten für das Objekt in seine Anmerkungen aufnehmen. Die Metadaten sollten (mindestens) die oben beschriebenen Metadatenelemente des Elements sowie eine kurze Zusammenfassung des Inhalts enthalten (d. h. die wichtigsten Subsysteme oder Subprozesse, die sich darin befinden könnten).

Im Gegensatz zu einem Element, das eine Einheit innerhalb des betrachteten Systems darstellt, repräsentiert ein External Entity Shape ( ), wie in Abbildung 1-3 dargestellt, einen Prozess oder ein System, der/das am Betrieb oder der Funktion des Systems beteiligt ist, aber nicht Gegenstand der Analyse ist. Eine externe Entität ist ein Standard-Shape. Zumindest bieten externe Entitäten eine Quelle für Datenströme, die von einem entfernten Prozess oder Mechanismus in das System gelangen. Beispiele für externe Entitäten sind häufig Webbrowser, die für den Zugriff auf Webserver oder ähnliche Dienste verwendet werden, aber auch jede andere Art von Komponente oder Verarbeitungseinheit.

Abbildung 1-3. Externes Entitätssymbol zum Zeichnen von Datenflussdiagrammen

Akteure (siehe Abbildung 1-4), die in erster Linie menschliche Benutzer des Systems darstellen, sind Standardformen, die Verbindungen zu Schnittstellen haben, die vom System angeboten werden (direkt oder über eine zwischengeschaltete externe Einheit wie einen Webbrowser), und werden oft auf der Kontextebene der Zeichnung verwendet.

Abbildung 1-4. Akteurssymbol zum Zeichnen von Datenflussdiagrammen

Das in Abbildung 1-5 gezeigte Datenspeichersymbol ist eine Standardform , die eine funktionale Einheit darstellt, die anzeigt, wo "große" Daten gespeichert werden, wie z. B. eine Datenbank (aber nicht immer der Datenbankserver). Du kannst das Datenspeichersymbol auch verwenden, um eine Datei oder einen Puffer mit kleinen Mengen sicherheitsrelevanter Daten zu kennzeichnen, z. B. eine Datei mit dem privaten Schlüssel für das TLS-Zertifikat deines Webservers,⁸ oder für einen Objektdatenspeicher wie einen Amazon Simple Storage Service (S3) Bucket, in dem die Logdateien deiner Anwendung gespeichert sind. Datenspeichersymbole können auch einen Nachrichtenbus oder einen gemeinsamen Speicherbereich darstellen.

Abbildung 1-5. Datenspeicher-Symbole zum Zeichnen von Datenflussdiagrammen

Datenspeicher sollten beschriftet sein und Metadaten wie die folgenden enthalten:

Art der Speicherung

Handelt es sich dabei um eine Datei, einen S3-Bucket, ein Service-Mesh oder einen gemeinsamen Speicherbereich?

Art und Klassifizierung der gespeicherten Daten

Sind die Daten, die an dieses Modul gesendet oder von ihm gelesen werden, strukturiert oder unstrukturiert? Liegen sie in einem bestimmten Format vor, z. B. XML oder JSON?

Empfindlichkeit oder Wert der Daten

Sind die verwalteten Daten personenbezogene Informationen, sicherheitsrelevant oder anderweitig sensibel?

Schutzmaßnahmen für den Datenspeicher selbst

Bietet der Mechanismus der Root-Speicherung beispielsweise eine Verschlüsselung auf Laufwerksebene?

Replikation

Werden die Daten auf einen anderen Datenspeicher repliziert?

Backup

Werden die Daten zur Sicherheit an einen anderen Ort kopiert, aber mit möglicherweise reduzierten Sicherheits- und Zugriffskontrollen?

Tipp

Wenn du ein System modellierst, das einen Datenbankserver enthält (z. B. MySQL oder MongoDB), hast du zwei Möglichkeiten, ihn in einem Modell darzustellen: (a) du verwendest den Datenspeicher, um sowohl den DBMS-Prozess als auch den Ort der Datenspeicherung darzustellen, oder (b) ein Element für das DBMS und einen verbundenen Datenspeicher für die eigentliche Datenspeichereinheit.

Jede Option bringt Vorteile und Kompromisse mit sich. Die meisten Menschen würden sich für Option (a) entscheiden, aber Option (b) ist besonders nützlich bei einer effektiven Bedrohungsanalyse für Cloud- und eingebettete Systemmodelle, bei denen die Daten auf gemeinsam genutzten Datenkanälen oder temporären Speicherknoten liegen können.

Wenn ein Element in sich abgeschlossen ist und keine Verbindung zu externen Entitäten hat, beschreibt das Element eine sichere, aber wahrscheinlich ziemlich nutzlose Funktionalität innerhalb des Systems (hoffentlich ist das nicht deine einzige Einheit innerhalb des Systems!). Damit eine Einheit einen Wert hat, sollte sie zumindest Daten liefern oder eine transformative Funktion erzeugen. Die meisten Einheiten kommunizieren auch auf irgendeine Weise mit externen Einheiten. In einem Systemmodell beschreibst du mit Hilfe von Datenflusssymbolen, wo und wie Interaktionen zwischen den Einheiten stattfinden. Der Datenfluss ist eigentlich eine Reihe von Symbolen, die die verschiedenen Möglichkeiten der Interaktion zwischen Systemkomponenten darstellen.

Abbildung 1-6 zeigt eine einfache Linie, die eine Verbindung zwischen zwei Elementen im System anzeigt. Sie vermittelt keine zusätzlichen Informationen und kann diese auch nicht vermitteln. Deshalb ist dieses Symbol eine ausgezeichnete Wahl, wenn dir diese Informationen zum Zeitpunkt der Modellierung nicht zur Verfügung stehen.

Abbildung 1-6. Ein Liniensymbol für einen einfachen ungerichteten Datenfluss

Abbildung 1-7 zeigt eine einfache Linie mit einem Pfeil an einem Ende, die verwendet wird, um einen unidirektionalen Informations- oder Handlungsfluss darzustellen.

Abbildung 1-7. Ein Pfeilsymbol für einen einfachen gerichteten Datenfluss

In Abbildung 1-8 zeigt die linke Seite des Bildes eine Grundlinie mit Pfeilen an beiden Enden, die einen bidirektionalen Kommunikationsfluss darstellt. Auf der rechten Seite des Bildes ist ein alternatives Symbol für einen bidirektionalen Kommunikationsfluss zu sehen. Beides ist akzeptabel, obwohl die rechte Version traditioneller ist und in einem unübersichtlichen Diagramm leichter zu erkennen ist (auch auf die Gefahr hin, dass das Diagramm dadurch zu unübersichtlich wird).

Abbildung 1-8. Zweiköpfige Pfeile für bidirektionalen Datenfluss

Die Abbildungen 1-6, 1-7 und 1-8 sind Standardformen bei der Erstellung von Datenflussdiagrammen.

Hinweis

Denke daran, dass wir hier Konventionen und keine Regeln vorstellen. Diese Formen und was sie darstellen oder wie sie in einem Diagramm verwendet werden, entstammen der kollektiven Praxis, nicht einem offiziellen Standarddokument.⁹ In unserer Praxis der Bedrohungsmodellierung finden wir es manchmal nützlich, die konventionellen Formen und Metadaten zu erweitern, um unseren Anforderungen besser gerecht zu werden. Du wirst einige dieser Erweiterungen in diesem Kapitel und im gesamten Buch sehen. Sobald du dich mit den Zielen und erwarteten Ergebnissen der Aktivität vertraut gemacht hast, kannst du nach eigenem Ermessen Änderungen vornehmen. Anpassungen können die Aktivität, die Erfahrung und die gewonnenen Informationen für dich und die beteiligten Teammitglieder wertvoll machen.

Abbildung 1-9 zeigt eine nicht standardisierte Erweiterungsform (siehe vorherige Anmerkung), die wir über die normalen DFD-Formen hinaus vorschlagen. Diese Form ist ein einspitziger Pfeil, der anzeigt, wo die Kommunikation ihren Ursprung hat. Wir haben ihn eingekreist, um die Markierung hervorzuheben. Die Markierung ist in den technischen Schablonen für Übertragungsflüsse in den wichtigsten Grafikpaketen verfügbar.

Abbildung 1-9. Optionale Markierung des Initiators

Die Datenflüsse sollten mit einem Etikett versehen werden, das als Referenz dient, und du solltest die folgenden wichtigen Metadaten angeben:

Typ oder Art des Kommunikationskanals

Handelt es sich um einen netzwerkbasierten Kommunikationsfluss oder eine lokale Interprozesskommunikation (IPC)?

Verwendete(s) Protokoll(e)

Werden die Daten zum Beispiel über HTTP oder HTTPS übertragen? Wenn sie über HTTPS übertragen werden, werden dann Client-seitige Zertifikate verwendet, um einen Endpunkt zu authentifizieren, oder wird TLS verwendet? Sind die Daten selbst auf irgendeine Weise unabhängig vom Kanal geschützt (z. B. durch Verschlüsselung oder Signierung)?

Übermittelte Daten

Welche Art von Daten wird über den Kanal gesendet? Wie sensibel und/oder klassifiziert sind sie?

Reihenfolge der Vorgänge (falls zutreffend oder nützlich für deine Zwecke)

Wenn die Anzahl der Datenflüsse im Modell begrenzt ist oder die Interaktionen nicht sehr komplex sind, kann es möglich sein, die Reihenfolge der Operationen oder des Datenflusses als Teil der Anmerkungen zu jedem Datenfluss anzugeben, anstatt ein separates Sequenzdiagramm zu erstellen.

Hinweis

Sei vorsichtig, wenn du Authentifizierungs- oder andere Sicherheitskontrollen für den Datenfluss selbst ausdrückst. Die Endpunkte (Server oder Clients) sind für die Zugriffskontrollen verantwortlich und/oder "bieten" diese an, unabhängig von möglichen Datenflüssen zwischen ihnen. Ziehe in Erwägung, das später in diesem Abschnitt beschriebene erweiterte Modellierungselement "Schnittstelle" als "Port" zu verwenden, um deine Zeichnung zu vereinfachen und eine effektivere Analyse von Bedrohungen zu ermöglichen.

Beachte die folgenden Punkte, wenn du Datenflüsse in deinen Modellen verwendest.

Verwende zunächst Pfeile, um die Richtung des Datenflusses in deinem Diagramm und in deiner Analyse anzugeben. Wenn du eine Linie hast, die bei Element A beginnt und zu Element B führt, wo sie in einem Pfeil endet (wie in Abbildung 1-7 gezeigt), bedeutet das, dass der Fluss sinnvoller Kommunikation von A nach B geht. Das ist der Austausch von Daten, die für die Anwendung oder einen Angreifer von Wert sind, aber nicht unbedingt einzelne Pakete, Frames und Acknowledgments (ACKs). Ebenso würde eine Linie, die bei B beginnt und in einem Pfeil bei A endet, bedeuten, dass die Kommunikation von B nach A fließt.

Zweitens kannst du zwischen zwei grundlegenden Ansätzen wählen, um bidirektionale Kommunikationsflüsse in deinem Modell darzustellen: Verwende eine einzelne Linie mit einem Pfeil an jedem Ende, wie in Abbildung 1-8 (links) gezeigt, oder verwende zwei Linien, eine für jede Richtung, wie in Abbildung 1-8 (rechts) gezeigt. Die Methode mit den zwei Linien ist traditioneller, aber sie sind funktional gleichwertig. Ein weiterer Vorteil der zweizeiligen Methode ist, dass jeder Kommunikationsfluss unterschiedliche Eigenschaften haben kann, so dass deine Anmerkungen im Modell sauberer sind, wenn du zwei Zeilen statt einer verwendest. Du kannst dich für eine der beiden Methoden entscheiden, aber sei in deinem Modell konsistent.

Der Zweck eines Datenflusses in einem Modell besteht schließlich darin, die Hauptrichtung der Kommunikation zu beschreiben , die für die Analyse relevant ist. Wenn ein Kommunikationspfad ein beliebiges Standardprotokoll darstellt, das auf dem Transmission Control Protocol (TCP) oder dem User Datagram Protocol (UDP) basiert, laufen Pakete und Frames auf dem Kanal von der Quelle zum Ziel hin und her. Dieser Detailgrad ist für die Identifizierung von Bedrohungen in der Regel jedoch nicht wichtig.

Stattdessen ist es wichtig zu beschreiben, dass Daten oder Kontrollnachrichten auf Anwendungsebene über den etablierten Kanal weitergeleitet werden; das ist es, was der Datenfluss vermitteln soll. Für die Analyse ist es jedoch oft wichtig, zu verstehen, welches Element den Kommunikationsfluss initiiert. Abbildung 1-9 zeigt eine Markierung, die du verwenden kannst, um den Initiator des Datenflusses anzugeben.

Das folgende Szenario zeigt, wie nützlich diese Markierung für das Verständnis des Modells und die Analyse des Systems ist.

Element A und Element B sind durch ein unidirektionales Datenflusssymbol verbunden, wobei die Daten von A nach B fließen, wie in Abbildung 1-10 dargestellt.

Abbildung 1-10. Musterelemente A und B

Element A wird als Dienst A annotiert, während Element B der Logger-Client ist. Du könntest zu dem Schluss kommen, dass B als Empfänger der Daten den Kommunikationsfluss initiiert hat. Du könntest aber auch zu dem Schluss kommen, dass A den Datenfluss initiiert hat, indem du deine Analyse auf die Kennzeichnung jedes Endpunkts stützt. In beiden Fällen könntest du richtig liegen, denn das Modell ist mehrdeutig.

Was ist nun, wenn das Modell die zusätzliche Markierung Initiator enthält, die an den Endpunkt von Element A angehängt ist? Dies zeigt eindeutig an, dass Element A und nicht Element B den Kommunikationsfluss initiiert und Daten an B weiterleitet. Dies kann in den Fällen, die du modellierst, vorkommen, z. B. wenn du einen Microservice modellierst, der Log-Informationen an einen Logger-Client weiterleitet. Dies ist ein gängiges Architekturmuster, das in Abbildung 1-11 dargestellt ist.

Abbildung 1-11. Probeelemente A und B, mit Initiatormarkierung bei Element A

Wenn die Markierung des Initiators jedoch auf B und nicht auf A liegt, würdest du zu einer anderen Schlussfolgerung bezüglich der potenziellen Bedrohungen in diesem Modellsegment kommen. Dieser Entwurf würde ein alternatives Muster widerspiegeln, bei dem der Logger-Client, der sich vielleicht hinter einer Firewall befindet, nach außen zum Microservice kommunizieren muss, anstatt umgekehrt (siehe Abbildung 1-12).

Abbildung 1-12. Probeelemente A und B, mit Initiatormarkierung bei Element B

Das in Abbildung 1-13 gezeigte Symbol wird traditionell verwendet, um eine Vertrauensgrenze abzugrenzen: Alle Elemente hinter der Linie (die Krümmung der Linie bestimmt, was hinter der Linie und was vor der Linie liegt) vertrauen sich gegenseitig. Die gepunktete Linie kennzeichnet eine Grenze, an der alle Entitäten auf der gleichen Ebene vertrauenswürdig sind. Du könntest zum Beispiel allen Prozessen vertrauen, die hinter deiner Firewall oder deinem VPN laufen. Das bedeutet nicht, dass die Datenströme automatisch nicht authentifiziert sind. Stattdessen bedeutet eine Vertrauensgrenze, dass Objekte und Entitäten, die innerhalb der Grenze operieren, auf der gleichen Vertrauensstufe arbeiten (z. B. Ring 0).

Dieses Symbol sollte verwendet werden, wenn du ein System modellierst, bei dem du von symmetrischem Vertrauen zwischen den Systemkomponenten ausgehen möchtest. In einem System mit asymmetrischem Komponentenvertrauen (d.h. Komponente A kann Komponente B vertrauen, aber Komponente B vertraut Komponente A nicht), wäre das Zeichen für die Vertrauensgrenze unangemessen. Du solltest eine Anmerkung zum Datenfluss mit Informationen über dieVertrauensbeziehung verwenden.

Abbildung 1-13. Symbole für Vertrauensgrenzen zum Zeichnen von Datenflussdiagrammen

Das gleiche Symbol wird manchmal auch verwendet, wie in Abbildung 1-14 gezeigt, um das Sicherheitsschema eines bestimmten Datenflusses zu kennzeichnen, z. B. die Kennzeichnung des Datenflusses als vertraulich und integer durch die Verwendung von HTTPS. Eine Alternative zu diesem Symbol und den Anmerkungen, die in Modellen mit einer großen Anzahl von Komponenten und/oder Datenflüssen zu einem großen Durcheinander führen können, ist die Angabe einer Anmerkung zum Datenfluss selbst.

Die notwendigen Metadaten für eine Vertrauensgrenze, wenn sie im traditionellen Sinne verwendet wird (um eine Grenze zu bezeichnen, jenseits derer alle Entitäten die gleiche Vertrauensstufe haben), ist eine Beschreibung der symmetrischen Vertrauensbeziehung der Entitäten. Wenn dieses Symbol verwendet wird, um eine Kontrolle eines Kanals oder eines Datenflusses zu kennzeichnen, sollten die Metadaten das/die verwendete(n) Protokoll(e) (z. B. HTTP oder HTTPS, gegenseitiges TLS oder nicht), die Portnummer, wenn es sich nicht um die Standardeinstellung handelt, und alle zusätzlichen Informationen zur Sicherheitskontrolle, die du ausdrücken möchtest, enthalten.

Abbildung 1-14. Symbol für eine kommentierte Vertrauensgrenze

Ein Schnittstellenelement, das in Abbildung 1-15 eingekreist ist, ist eine weitere nicht standardisierte Erweiterungsform, die einen definierten Verbindungspunkt für ein Element oder einen Container anzeigt. Dies ist nützlich, um Ports oder Service-Endpunkte anzuzeigen, die das Element anbietet. Dies ist besonders hilfreich, wenn die spezifische Verwendung des Endpunkts zur Entwurfszeit nicht definiert oder unbestimmt ist, oder anders gesagt, wenn die Clients des Endpunkts im Voraus nicht bekannt sind, was bedeutet, dass es schwierig ist, einen bestimmten Datenfluss zu zeichnen. Auch wenn dies trivial erscheinen mag, kann ein offener Listening-Endpunkt eines Dienstes ein großes architektonisches Risiko darstellen, so dass es wichtig ist, dies im Modell erkennen zu können.

Abbildung 1-15. Symbol für ein Schnittstellenelement

Jede Schnittstelle sollte ein Label und Metadaten haben, die ihre wichtigsten Eigenschaften beschreiben:

• Wenn die Schnittstelle einen bekannten Port darstellt, gib die Portnummer an.

• Identifiziere den Kommunikationskanal oder -mechanismus - z. B. PHY oder Layer 1/Layer 2: Ethernet, VLAN, USB Human Interface Device (HID) oder ein softwaredefiniertes Netzwerk - und gib an, ob die Schnittstelle außerhalb des Elements liegt.

• Kommunikationsprotokoll(e), das/die von der Schnittstelle angeboten wird/werden (z. B. Protokolle auf Schicht 4 und höher; oder TCP, IP, HTTP).

• Zugriffskontrollen für eingehende Verbindungen (oder potenziell ausgehende Datenströme), z. B. jede Art von Authentifizierung (Passwörter oder SSH-Schlüssel usw.) oder wenn die Schnittstelle von einem externen Gerät wie einer Firewall beeinflusst wird.

Die Kenntnis dieser Informationen kann die Analyse erleichtern, da alle Datenflüsse, die mit der Schnittstelle verbunden sind, diese Merkmale übernehmen können. Deine Zeichnung wird dadurch auch einfacher und verständlicher. Wenn du dieses optionale Element nicht verwenden möchtest, erstelle eine Dummy-Entität und einen Datenfluss zum offenen Service-Endpunkt, was die Zeichnung komplexer erscheinen lassen kann.

Warnung

Die Form in Abbildung 1-16 - derBlock - ist nicht Teil der üblichen DFD-Formen. Er ist hier enthalten, weil Matt ihn für nützlich hält und zeigen wollte, dass die Bedrohungsmodellierung nicht nur an die traditionelle Schablone gebunden sein muss, wenn es eine Möglichkeit gibt, den Wert und/oder die Klarheit der eigenen Modelle zu erhöhen.

Ein Blockelement, wie in Abbildung 1-16 dargestellt, stellt ein Architekturelement dar, das den Datenfluss, an den es angehängt ist, selektiv verändert. Blöcke können auch einen Port an der Verbindung eines Datenflusses oder einer Prozessgrenze verändern. Diese Form hebt hervor, wenn eine Host-Firewall, ein anderes physisches Gerät oder ein logischer Mechanismus als Funktion der Architektur vorhanden und für die Analyse wichtig ist. Blockelemente können auch optionale oder zusätzliche Geräte anzeigen, die das System auf eine Art und Weise beeinflussen können, die außerhalb der Kontrolle des Projektteams liegt, aber keine externen Einheiten im traditionellen Sinne sind.

Abbildung 1-16. Blocksymbole

Zu den Metadaten, die du für die Blöcke sammeln solltest, gehören die üblichen Bezeichnungen sowie diefolgenden:

Die Art des Blocks

Ein physisches Gerät oder eine logische Einheit und ob die Einheit eine optionale Komponente für das System ist.

Verhalten

Was der Block tut und wie er den Fluss oder den Zugriff auf den Port oder Prozess verändert. Verwende ein Sequenzdiagramm oder einen Zustandsautomaten, um zusätzliche Details über die Verhaltensänderung zu liefern, die von der Einheit, die der Block darstellt, unterstützt wird.

Tipp

Wenn du ein Modell deines Systems entwickelst, solltest du immer entscheiden, ob du und das Projektteam ein bestimmtes Symbol verwenden wollen und ob du seine Bedeutung abändern willst (du machst also quasi deine eigenen Hausregeln für die Bedrohungsmodellierung, was völlig in Ordnung ist!). Sei konsequent bei der Verwendung des Symbols, damit die Aktivität effektiv und wertvoll ist.

Sequenzdiagramme

Während DFDs die Interaktionen und Verbindungen zwischen den Systemkomponenten und den Datenverkehr zwischen ihnen darstellen, zeigen Sequenzdiagramme eine zeit- oder ereignisbasierte Abfolge von Aktionen. Sequenzdiagramme stammen aus der UML und sind eine Spezialisierung des Interaktionsdiagrammtyps in der UML. Die Ergänzung von DFDs durch Sequenzdiagramme im Rahmen der Modellierung zur Vorbereitung einer Bedrohungsanalyse kann dazu beitragen, den notwendigen Kontext über das Verhalten deines Systems und alle zeitlichen Aspekte zu liefern, die für eine angemessene Analyse erforderlich sind. DFDs können dir zum Beispiel zeigen, dass ein Client mit einem Server kommuniziert und eine Form von Daten an den Server weitergibt. Ein Sequenzdiagramm zeigt dir die Reihenfolge der Operationen, die in diesem Kommunikationsfluss verwendet werden. Daraus können wichtige Informationen hervorgehen, z. B. wer die Kommunikation initiiert und welche Schritte im Prozess ein Sicherheits- oder Datenschutzrisiko darstellen können, z. B. wenn ein Protokoll nicht korrekt implementiert wurde oder eine andere Schwachstelle vorliegt.

In der Sicherheitscommunity wird darüber diskutiert, ob das Sequenzdiagramm für die Durchführung dieser Aktivität tatsächlich wichtiger ist als die Entwicklung von DFDs. Das liegt daran, dass ein richtig erstelltes Sequenzdiagramm wesentlich mehr nützliche Daten liefern kann als DFDs. Das Sequenzdiagramm zeigt nicht nur, welche Daten an einem Fluss beteiligt sind und welche Entitäten involviert sind, sondern erklärt auch , wie die Daten durch das System fließen und in welcher Reihenfolge. Fehler in der Geschäftslogik und der Protokollabwicklung sind daher mit einem Sequenzdiagramm leichter zu finden (und in manchen Fällen die einzige Möglichkeit, sie zu finden).

Sequenzdiagramme zeigen auch kritische Designfehler auf, wie z. B. Bereiche ohne Ausnahmebehandlung, Fehlerpunkte oder andere Bereiche, in denen Sicherheitskontrollen nicht konsequent angewendet werden. Sie können auch Kontrollen aufdecken, die unterdrückt oder versehentlich außer Kraft gesetzt werden, oder potenzielle Fälle von Wettlaufbedingungen - einschließlich der gefürchteten Schwäche "time of check time of use" (TOCTOU) -, bei denen das bloße Wissen, dass Daten fließen, aber nicht die Reihenfolge, in der sie fließen, diese Schwachstellen nicht erkennen lässt. Es bleibt abzuwarten, ob sich die Verwendung von Sequenzdiagrammen als gleichberechtigter Partner bei der Bedrohungsmodellierung durchsetzen wird.

Die formale Definition eines Sequenzdiagramms in der UML umfasst eine beträchtliche Anzahl von Modellierungselementen, aber für die Erstellung eines Modells, das für die Bedrohungsanalyse geeignet ist, solltest du dich nur mit der folgenden Teilmenge beschäftigen.

Abbildung 1-17 zeigt ein Beispiel für ein Sequenzdiagramm, das einen möglichen Kommunikations- und Anruffluss eines mythischen Systems simuliert.

Abbildung 1-17. Formen des Sequenzdiagramms

Zu den in Abbildung 1-17 dargestellten Modellierungselementen gehören die folgenden:

Entitäten (Objekte A und B)

Innerhalb des Geltungsbereichs des betrachteten Systems, und ihre "Lebensader" für die Verbindung zu Interaktionen mit anderen Einheiten.

Schauspieler (Menschen)

Sie sind hier nicht dargestellt, aber sie befinden sich außerhalb der Systemkomponenten und interagieren mit den verschiedenen Einheiten innerhalb des Systems.

Nachrichten

Nachrichten mit Daten ("Aufruf A", "Rückgabe B"), die von einer Entität an eine andere weitergegeben werden. Nachrichten können zwischen den Entitäten synchron oder asynchron sein; synchrone Nachrichten (dargestellt durch durchgezogene Pfeilspitzen) blockieren, bis die Antwort fertig ist, während asynchrone Nachrichten (dargestellt durch offene Pfeilspitzen, nicht abgebildet) nicht blockieren. Gestrichelte Linien, die in Pfeilspitzen enden, stellen Rückmeldungen dar. Nachrichten können auch von einer Entität ausgehen und enden, ohne an eine andere Entität weitergegeben zu werden. Dies wird durch einen Pfeil dargestellt, der auf der Lebenslinie der Entität, von der die Nachricht ausgeht, zurückläuft.

Bedingte Logik

Diese kann in Nachrichtenflüsse eingefügt werden, um Einschränkungen oder Vorbedingungen zu schaffen, die dabei helfen, Probleme zu erkennen, die durch Fehler in der Geschäftslogik und deren Auswirkungen auf die Datenflüsse entstehen. Diese bedingte Logik (in Abbildung 1-17 nicht dargestellt) hätte die Form von [condition] und würde inline mit dem Meldungslabel platziert werden.

Zeit

In einem Sequenzdiagramm fließt die Zeit von oben nach unten: Eine Nachricht, die weiter oben im Diagramm steht, tritt zeitlich früher auf als die folgenden Nachrichten.

Ein Sequenzdiagramm zu erstellen ist ziemlich einfach. Der schwierige Teil ist die Entscheidung, wie du es zeichnen willst. Wir empfehlen dir, ein gutes Zeichenprogramm zu finden, das gerade Linien (sowohl durchgezogene als auch gestrichelte), einfache Formen und Pfeile, die gebogen oder geknickt werden können, verarbeiten kann. Microsoft Visio (oder eine der Libre- oder offenen Alternativen wie draw.io oder Lucidchart) oder ein UML-Modellierungstool wie PlantUML sollten gut geeignet sein.

Du musst auch entscheiden, welche Aktionen du als Sequenz modellieren willst. Eine gute Wahl sind Authentifizierungs- oder Autorisierungsabläufe, da diese mehrere Entitäten (mindestens einen Akteur und einen Prozess oder mehrere Prozesse) einbeziehen, die wichtige Daten auf eine vordefinierte Weise austauschen. Du kannst auch Interaktionen modellieren, an denen ein Datenspeicher oder ein asynchrones Verarbeitungsmodul beteiligt ist, sowie alle Standardarbeitsabläufe, an denen mehrere Entitäten beteiligt sind.

Wenn du dich für die Aktionen entschieden hast, die du modellieren willst, musst du die Interaktion und die Funktionsweise der Elemente innerhalb deines Systems bestimmen. Füge jedes Element als Rechteck am oberen Rand des Diagramms hinzu (siehe Abbildung 1-17) und ziehe eine lange Linie von der unteren Mitte des Rechtecks des Elements gerade nach unten. Beginne schließlich oben im Diagramm (entlang der langen vertikalen Linien) mit Linien, die in Pfeilen in die eine oder andere Richtung enden, um zu zeigen, wie die Elemente zusammenwirken.

Beschreibe die Interaktionen weiter unten im Modell, bis du die natürliche Schlussfolgerung der Interaktionen auf der erwarteten Granularitätsebene erreichst. Wenn du ein Whiteboard oder ein ähnliches Medium verwendest, um dein Modell zu zeichnen und dir Notizen zu machen, musst du dein Modell möglicherweise auf mehreren Tafeln fortsetzen oder ein Bild des unvollständigen Modells machen und es ausradieren, um deine Modellierung zu erweitern und zu vertiefen. Später musst du dann die Teile zu einem vollständigen Modell zusammenfügen.

Prozessablaufdiagramme

Prozessflussdiagramme (PFDs) werden traditionell in der Prozessplanung und der chemischen Verfahrenstechnik verwendet und zeigen die Reihenfolge und die Richtung des Flusses von Vorgängen durch ein System. PFDs ähneln Sequenzdiagrammen, befinden sich aber in der Regel auf einer höheren Ebene und zeigen eher die Aktivitätskette von Ereignissen im System als den Fluss bestimmter Nachrichten und Zustandsübergänge von Komponenten.

Wir erwähnen Prozessabläufe hier nur der Vollständigkeit halber, aber die Verwendung von PFDs bei der Bedrohungsmodellierung ist nicht üblich. Das ThreatModeler-Tool verwendet jedoch PFDs als primären Modelltyp, so dass sie für manche von Nutzen sein könnten.

PFDs können eine Ergänzung zu Sequenzdiagrammen sein. Manchmal kannst du die Aktivitätskette aus einem PFD mit einem Sequenzdiagramm beschreiben, indem du Beschriftungen verwendest, die angeben, welche Segmente des Nachrichtenflusses an eine bestimmte Aktivität oder ein Ereignis gebunden sind. Abbildung 1-18 zeigt ein PFD für die Ereignisse einer einfachen Webanwendung.

Abbildung 1-18. Beispiel für ein Prozessflussdiagramm

Abbildung 1-19 zeigt das gleiche PFD als Sequenzdiagramm mit zusätzlichen Aktivitätsrahmen.

Abbildung 1-19. Sequenzdiagramm als PFD

Angriffsbäume

Angriffsbäume werden seit mehr als 20 Jahren in der Informatik eingesetzt. Sie sind nützlich, um zu verstehen, wie ein System verwundbar ist, indem sie modellieren, wie ein Angreifer ein System beeinflussen kann. Angriffsbäume sind der wichtigste Modelltyp in der Bedrohungsanalyse, wenn ein angreiferzentrierter Ansatz verwendet wird.

Diese Art von Modell beginnt mit dem Wurzelknoten, der das Ziel oder das gewünschte Ergebnis darstellt. Erinnere dich daran, dass das Ergebnis bei diesem Modelltyp ein negatives Ergebnis für die Systembesitzer, aber ein positives Ergebnis für die Angreifer ist! Die Zwischen- und Blattknoten stellen mögliche Wege dar, um das Ziel des übergeordneten Knotens zu erreichen. Jeder Knoten ist mit einer Aktion beschriftet, die ergriffen werden muss, und sollte Informationen wie die folgenden enthalten:

• Die Schwierigkeit bei der Durchführung der Aktion, um das Ziel des übergeordneten Knotens zu erreichen

• Die damit verbundenen Kosten

• Besondere Kenntnisse oder Bedingungen, die erforderlich sind, damit der Angreifer erfolgreich sein kann

• Alle anderen relevanten Informationen, um die Gesamtfähigkeit für Erfolg oderMisserfolg zu bestimmen

Abbildung 1-20 zeigt einen generischen Angriffsbaum mit einem Ziel und zwei Aktionen und zwei Unteraktionen, die ein Angreifer verwendet, um das Ziel zu erreichen.

Abbildung 1-20. Ein allgemeines Angriffsbaumdiagramm

Angriffsbäume, die für die Analyse von Bedrohungen und für das Verständnis des tatsächlichen Ausmaßes und Grades der Gefährdung eines Systems durch Angreifer wertvoll sein können, benötigen eine Reihe von Dingen, um gut konstruiert zu sein und die richtige Analyse der Auswirkungen zu liefern:

• Vollständiges Wissen darüber, wie etwas kompromittiert werden kann - Bevorzugung der Vollständigkeit und des "Möglichen" gegenüber dem "Praktischen"

• Ein Verständnis für die Motivationen, Fähigkeiten und Ressourcen, die den verschiedenen Arten und Gruppen von Angreifern zur Verfügung stehen

Du kannst einen Angriffsbaum relativ einfach erstellen, indem du die folgenden Schritte befolgst:

1. Bestimme ein Ziel für einen Angriff.

2. Bestimme, welche Maßnahmen ergriffen werden müssen, um das Ziel zu erreichen.

3. Ausspülen und wiederholen.

Identifiziere ein Ziel für einen Angriff

Nehmen wir an, dass ein Angreifer über Remote Code Execution (RCE) auf einem eingebetteten Gerät eine dauerhafte Präsenz auf einem System aufbauen möchte. Abbildung 1-21 zeigt, wie dies in einem sich entwickelnden Angriffsbaum aussehen könnte.

Abbildung 1-21. Beispielhafter Angriffsbaum, Schritt 1: Identifizierung des übergeordneten Ziels

Maßnahmen zur Erreichung des Ziels festlegen

Wie kommst du zu RCE auf diesem System? Eine Möglichkeit ist, einen ausnutzbaren Stack-Pufferüberlauf zu finden und ihn zu nutzen, um eine ausführbare Nutzlast zu liefern. Oder du könntest einen Heap-Überlauf finden und ihn auf ähnliche Weise nutzen. An dieser Stelle denkst du vielleicht: "Aber Moment mal, wir wissen doch gar nichts über das System, um zu wissen, ob das überhaupt machbar ist!" Und du hast Recht.

Wenn du diese Übung in der Praxis durchführst, solltest du realistisch sein und sicherstellen, dass du nur Ziele und Aktionen identifizierst, die für das zu bewertende System sinnvoll sind. Für dieses Beispiel nehmen wir also an, dass auf diesem eingebetteten Gerät ein in C geschriebener Code läuft. Außerdem gehen wir davon aus, dass auf diesem Gerät ein Linux-ähnliches Betriebssystem läuft - entweder ein Echtzeitbetriebssystem (RTOS) oder eine andere ressourcenbeschränkte Linux-Variante.

Was könnte eine weitere Aktion sein, um die RCE-Fähigkeit zu erlangen? Erlaubt das System eine Remote Shell? Wenn wir davon ausgehen, dass das Gerät über einen Flash-Speicher und/oder bootfähige Medien verfügt und Over-the-Air-Updates (OTAs) akzeptiert, können wir auch Dateimanipulation und OTA-Firmware-Spoofing oder -Modifikation als Aktionen hinzufügen, um RCE zu erreichen. Alle möglichen Aktionen, die du identifizieren kannst, sollten als Elemente in den Angriffsbaum aufgenommen werden, wie in Abbildung 1-22 dargestellt.

Abbildung 1-22. Beispiel eines Angriffsbaums, Schritt 2: Erforderliche Maßnahmen zum Erreichen des Ziels festlegen

Ausspülen und wiederholen

Hier wird es wirklich interessant! Versuche, dir Wege auszudenken, wie du die nächste Reihe von Ergebnissen erreichen kannst. Mach dir keine Gedanken über die Machbarkeit oder Wahrscheinlichkeit; die Analyse und die daraus resultierenden Entscheidungen werden später getroffen. Denke über den Tellerrand hinaus. Erinnere dich daran, dass du den Hackerhut aufgesetzt hast, also denke wie sie es tun würden. Egal wie verrückt deine Ideen sind, jemand könnte etwas Ähnliches versuchen. In diesem Stadium ist eine vollständige Liste von Möglichkeiten besser als eine unvollständige Liste von Machbarkeiten.

Dein Baum ist fertig, wenn keine weiteren Teilschritte mehr nötig sind, um eine Aktion abzuschließen. Mach dir keine Sorgen, wenn dein Baum einseitig aussieht; nicht alle Aktionen brauchen den gleichen Grad an Komplexität, um Ergebnisse zu erzielen. Mach dir auch keine Sorgen, wenn du hängende Knoten hast - es ist vielleicht nicht einfach, alle möglichen Szenarien für einen Angreifer zu identifizieren, um ein Ziel zu erreichen (es ist gut, an so viele Szenarien wie möglich zu denken, aber du wirst vielleicht nicht alle identifizieren können). Abbildung 1-23 zeigt einen weiterentwickelten (und möglicherweise vollständigen) Angriffsbaum, der die Methoden aufzeigt, mit denen ein Angreifer sein Ziel erreichen kann.

Abbildung 1-23. Beispielhafter Angriffsbaum, Schritt 3 und darüber hinaus: Teilaktionen zum Erreichen von Teilzielen identifizieren

Es ist einfacher zu lernen, wie man etwas knackt oder bestimmte Ziele erreicht, wenn man ein Gruppen-Brainstorming durchführt. So können Personen mit technischem und sicherheitsrelevantem Wissen ihr Fachwissen in die Gruppe einbringen, damit ihr alle möglichen Knoten und Blätter des Angriffsbaums identifizieren könnt. Wenn du die Risikobereitschaft deines Unternehmens kennst, d.h. das Ausmaß des Risikos, das dein Unternehmen zu akzeptieren bereit ist, kannst du herausfinden, wie viel Zeit du für die Übung aufwenden solltest und ob das Unternehmen bereit ist, die notwendigen Maßnahmen zu ergreifen, um die festgestellten Probleme zu lösen.

Zu wissen, wie sich Angreifer verhalten, ist für die meisten Unternehmen und Sicherheitsexperten eine große Herausforderung, aber Community-Ressourcen wie das MITRE ATT&CK-Framework machen die Identifizierung und Charakterisierung der Techniken, Fähigkeiten und Motivationen von Bedrohungsakteuren sehr viel einfacher. Es ist sicherlich kein Allheilmittel, denn es ist nur so gut wie die Gemeinschaft, die es unterstützt. Wenn du aber nicht weißt, wie sich Angreifergruppen in der realen Welt verhalten, ist dieser Blogeintrag von Adam Shostack, der einen Vortrag von Jonathan Marcil zusammenfasst, eine hervorragende Ressource, die du in Betracht ziehen solltest.

Fishbone-Diagramme

Fischgrätdiagramme, auch bekannt als Ursache-Wirkungs-Diagramme oder Ishikawa-Diagramme, werden hauptsächlich für die Ursachenanalyse einer Problemstellung verwendet. Abbildung 1-24 zeigt ein Beispiel für ein Fischgrätdiagramm.

Ähnlich wie Angriffsbäume können Fischgräten-Diagramme dir helfen, Schwachstellen im System für einen bestimmten Bereich zu identifizieren. Diese Diagramme sind auch nützlich, um Fallstricke oder Schwachstellen in Prozessen zu identifizieren, z. B. in der Lieferkette eines Systems, wo du die Lieferung oder Herstellung von Komponenten, das Konfigurationsmanagement oder den Schutz kritischer Vermögenswerte analysieren musst. Dieser Modellierungsprozess kann dir auch dabei helfen, die Kette von Ereignissen zu verstehen, die zur Ausnutzung einer Schwachstelle führen. Wenn du diese Informationen kennst, kannst du bessere DFDs erstellen (indem du weißt, welche Fragen du stellen oder welche Daten du suchen musst) und neue Arten von Bedrohungen sowie Sicherheitstestfälle identifizieren.

Die Erstellung eines Fischgräten-Diagramms ähnelt der Erstellung von Angriffsbäumen, nur dass du statt eines Ziels und der Maßnahmen zum Erreichen des Ziels die Wirkung identifizierst, die du modellieren willst. In diesem Beispiel werden die Ursachen für die Datenexposition modelliert.

Definiere zunächst den Effekt, den du modellieren willst; Abbildung 1-24 zeigt die Technik mit der Datenexposition als zu modellierendem Effekt.

Abbildung 1-24. Beispiel für ein Fischgrätdiagramm, Schritt 1: Haupteffekt

Dann musst du eine Reihe von Hauptursachen identifizieren, die zu diesem Effekt führen. Wir haben drei identifiziert: zu ausführliche Protokolle, verdeckte Kanäle und Benutzerfehler, wie in Abbildung 1-25 dargestellt.

Abbildung 1-25. Beispiel für ein Fischgrätdiagramm, Schritt 2: Hauptursachen

Schließlich identifizierst du die Ursachen, die zu den Hauptursachen führen (und so weiter). Wir haben festgestellt, dass eine der Hauptursachen für Benutzerfehler eine verwirrende Benutzeroberfläche ist. In diesem Beispiel werden nur drei Bedrohungen erkannt, aber du wirst größere und umfangreichere Modelle erstellen wollen, je nachdem, wie viel Zeit und Mühe du im Vergleich zur Granularität deiner Ergebnisse aufwenden willst. Abbildung 1-26 zeigt das Fischgrätdiagramm in einem vollständigen Zustand, mit der erwarteten Wirkung, den primären und sekundären Ursachen.

Abbildung 1-26. Beispiel für ein Fischgrätdiagramm, Schritt 3: Sekundäre Ursachen

Wie man Systemmodelle erstellt

Der grundlegende Prozess zur Erstellung von Systemmodellen beginnt mit der Identifizierung der wichtigsten Bausteine des Systems - das können Anwendungen, Server, Datenbanken oder Datenspeicher sein. Dann identifizierst du die Verbindungen zu jedem Hauptbaustein:

• Unterstützt die Anwendung eine API oder eine Benutzeroberfläche?

• Lauscht der Server auf irgendwelchen Ports? Wenn ja, über welches Protokoll?

• Was spricht mit der Datenbank und was kommuniziert mit ihr? Liest es nur Daten oder schreibt es auch Daten?

• Wie wird der Zugriff auf die Datenbank kontrolliert?

Verfolge die Gesprächsfäden weiter und durchlaufe jede Entität auf dieser Kontextebene im Modell, bis du alle notwendigen Verbindungen, Schnittstellen, Protokolle und Datenströme abgeschlossen hast.

Als Nächstes wählst du eine der Entitäten - in der Regel eine Anwendung oder ein Serverelement - aus, die zusätzliche Details enthält, die du aufdecken musst, um Problembereiche zu identifizieren, und schlüsselst sie weiter auf. Konzentriere dich auf die Eingangs- und Ausgangspunkte zur/von der Anwendung und darauf, wo diese Kanäle miteinander verbunden sind, wenn du die Teilbereiche betrachtest, aus denen die Anwendung oder der Server besteht.

Überlege auch, wie die einzelnen Teilbereiche miteinander kommunizieren können, einschließlich der Kommunikationskanäle, Protokolle und der Art der Daten, die über die Kanäle übertragen werden. Je nach Art der dem Modell hinzugefügten Form solltest du alle relevanten Informationen hinzufügen (später im Kapitel erfährst du, wie du das Modell mit Metadaten versiehst).

Wenn du Modelle erstellst, musst du dein Urteilsvermögen und dein Wissen über Sicherheitsprinzipien und -technologien nutzen, um Informationen für eine Bedrohungsanalyse zu sammeln. Im Idealfall führst du diese Bedrohungsanalyse sofort nach der Erstellung deines Modells durch.

Bevor du beginnst, solltest du entscheiden, welche Modelltypen du benötigst und welchen Symbolsatz du für jeden Modelltyp verwenden möchtest. Du kannst dich zum Beispiel dafür entscheiden, das DFD als primären Modelltyp zu verwenden, aber den Standardsymbolsatz des von dir verwendeten Zeichenpakets zu nutzen. Oder du entscheidest dich, auch Sequenzdiagramme einzubeziehen, was sinnvoll wäre, wenn dein System nicht standardisierte Interaktionen zwischen Komponenten verwendet, in denen sich ausnutzbare Schwachstellen verbergen können.

Als Leiter einer Modellierungssitzung (für die Zwecke dieses Kapitels nehmen wir an, dass du das bist - du Glückspilz) musst du sicherstellen, dass du die richtigen Interessengruppen einbeziehst. Lade den leitenden Architekten, die anderen Designer und den/die Entwicklungsleiter zur Modellierungssitzung ein. Du solltest auch erwägen, den Leiter der Qualitätssicherung (QA) einzuladen. Ermutige alle Mitglieder des Projektteams, ihren Beitrag zur Erstellung des Modells zu leisten. Aus praktischen Gründen empfehlen wir jedoch, die Teilnehmerliste auf eine überschaubare Anzahl zu beschränken, um die Zeit und Aufmerksamkeit derjenigen zu maximieren, die teilnehmen.

Wenn dies das erste Mal ist, dass du oder dein Entwicklungsteam ein Systemmodell erstellt, fang langsam an. Erkläre dem Team die Ziele oder erwarteten Ergebnisse der Übung. Außerdem solltest du angeben, wie lange die Übung voraussichtlich dauern wird, wie ihr vorgehen wollt und welche Rolle du und die anderen Beteiligten dabei spielen. Für den unwahrscheinlichen Fall, dass die Teammitglieder nicht alle miteinander vertraut sind, solltest du dich vor Beginn der Sitzung im Raum vorstellen.

Du solltest auch festlegen, wer für das Zeichnen und die Notizen verantwortlich ist, die während der Sitzung benötigt werden. Wir empfehlen, dass du das Zeichnen selbst übernimmst, denn so stehst du immer im Mittelpunkt des Gesprächs und die Teilnehmer/innen können sich auf die anstehende Aufgabe konzentrieren.

Ein paar Punkte sind erwähnenswert, wenn du das System erkundest:

Das Timing der Übung ist wichtig

Wenn ihr euch zu früh trefft, ist der Entwurf noch nicht ausreichend ausgearbeitet, und es kommt zu einer Menge Unruhe, weil sich die Designer mit unterschiedlichen Ansichten gegenseitig herausfordern und die Diskussion in andere Richtungen lenken. Wenn ihr euch aber zu spät trefft, wird der Entwurf festgelegt und alle Probleme, die bei der Bedrohungsanalyse festgestellt wurden, werden möglicherweise nicht rechtzeitig gelöst, so dass euer Treffen eher zu einer Dokumentationsübung als zu einer Bedrohungsanalyse wird.

Verschiedene Stakeholder werden die Dinge unterschiedlich sehen

Wir haben festgestellt, dass die Stakeholder von nicht immer einer Meinung sind, wenn es darum geht, wie das System entworfen oder implementiert wurde, vor allem wenn die Teilnehmerzahl steigt. Möglicherweise musst du die Diskussion auch moderieren, um Kaninchenlöcher und kreisende Gesprächsfäden zu vermeiden, und dich vor Nebengesprächen hüten, da sie eine unnötige und zeitraubende Ablenkung darstellen. Eine gut moderierte Konversation zwischen den Interessengruppen im Systemmodellierungsprozess führt oft zu "Heureka!"-Momenten, da die Diskussion offenbart, dass die Erwartungen an den Entwurf und die Realität der Umsetzung kollidieren, und das Team kann die Stellen identifizieren, an denen die Einschränkungen den ursprünglichen Entwurf unkontrolliert verändert haben.

Lose Enden sind OK

Wie wir bereits erwähnt haben, solltest du zwar nach Perfektion streben, aber auch mit fehlenden Informationen leben können. Achte nur darauf, wissentlich falsche Informationen zu vermeiden oder zu minimieren. Es ist besser, einen Datenfluss oder ein Element im Modell zu haben, das mit Fragezeichen versehen ist, als wenn alles vollständig ist, aber einige bekannte Ungenauigkeiten enthält. In diesem Fall führen die Ungenauigkeiten zu einer mangelhaften Analyse, die zu mehreren falschen Ergebnissen führen kann, oder schlimmer noch, zu fehlenden Ergebnissen in einem potenziell kritischen Bereich des Systems.

Wir empfehlen, dass du die Systemmodellierung als angeleitete Übung präsentierst. Das ist besonders wichtig, wenn das Projektteam mit dem Modellierungsprozess nicht vertraut ist. Oft ist es von Vorteil, wenn eine Person, die nicht zum Produktentwicklungsteam gehört, die Modellierungsübung anleitet, da so ein Interessenkonflikt in Bezug auf das Systemdesign und seine möglichen Auswirkungen auf die Lieferanforderungen vermieden wird.

Das soll nicht heißen, dass jemand, der den Aufbau eines Modells unterstützt, völlig unparteiisch sein sollte. Die Führungskraft ist dafür verantwortlich, die notwendigen Teilnehmer/innen zu versammeln und mit diesem Team zusammenzuarbeiten, um das System, das das Team aufbauen will, so detailliert zu definieren, dass es später analysiert werden kann. Der Leiter sollte also die Ergebnisse fördern und nicht als unbeteiligter Dritter agieren. Er muss so weit von der Planung entfernt sein (und Annahmen, Abkürzungen oder Risiken ignorieren), dass er einen kritischen Blick auf das System werfen und Informationen herauskitzeln kann, die für die Bedrohungsanalyse nützlich sind.

Als Führungskraft ist es wichtig, dass du bei der Analyse deines Modells über möglichst genaue und vollständige Informationen verfügst. Deine Analyse kann zu Änderungen am Systemdesign führen, und je genauer die Informationen sind, mit denen du beginnst, desto bessere Analysen und Empfehlungen kannst du abgeben. Behalte die Details im Auge und sei bereit und in der Lage, "Felsen" umzuwerfen, um die richtigen Informationen zur richtigen Zeit zu finden. Außerdem solltest du mit den in Frage kommenden Technologien, dem Zweck des zu entwerfenden Systems und den an der Aufgabe beteiligten Personen vertraut sein.

Du musst zwar kein Sicherheitsexperte sein, um ein gutes Systemmodell zu erstellen, aber die Modellerstellung wird in der Regel als Voraussetzung für die Phase der Bedrohungsanalyse durchgeführt. Dies geschieht in der Regel in rascher Folge, was bedeutet, dass du wahrscheinlich auch für diesen Teil des Projekts der Sicherheitsverantwortliche sein solltest. Die Realität ist, dass du bei modernen Entwicklungsprojekten vielleicht nicht in allen Bereichen eines Systems Experte bist. Du musst dich auf deine Teamkollegen verlassen, um deine Wissenslücken zu schließen, und eher als Vermittler fungieren, um sicherzustellen, dass das Team effizient ein repräsentatives und genaues Modell entwickelt. Erinnere dich daran, dass du kein Automechaniker sein musst, um ein Auto zu fahren, aber du musst wissen, wie du dein Auto fährst und die Regeln der Straße kennen.

Tipp

Wenn du der Leiter bist, der ein Systemmodell für die Analyse bereitstellen soll, solltest du mit Unvollkommenheit zurechtkommen, vor allem, wenn du mit einem neuen Modell eines Systems beginnst. Du wirst die Möglichkeit haben, das Modell in aufeinanderfolgenden Iterationen zu verbessern.

Egal, wie geschickt du bist, wenn du Modelle zeichnest oder Konstrukteure zu den Systemen befragst, die sie dir vorlegen, es ist sehr wahrscheinlich, dass die Informationen, die du brauchst, nicht vollständig vorhanden sind, zumindest anfangs. Und das ist gut so. Systemmodelle stellen das betrachtete System dar und müssen nicht 100%ig genau sein, um von Nutzen zu sein. Du musst einige grundlegende Fakten über das System und die einzelnen Elemente des Systems kennen, um deine Analyse effektiv durchführen zu können, aber strebe nicht nach Perfektion, sonst wirst du entmutigt (das wissen wir leider aus Erfahrung).

Du kannst deine Erfolgschancen bei der Leitung dieser Aktivität verbessern, indem du ein paar einfache Dinge beachtest:

Eine tadelfreie Zone einrichten

Personen, die eine starke Bindung zu dem zu analysierenden System haben, werden Meinungen und Gefühle haben. Obwohl du von den Teilnehmern Professionalität erwarten solltest, können Streitigkeiten und hitzige Argumente die Arbeitsbeziehungen belasten, wenn du es nicht vermeidest, in einer Systemmodellierungssitzung persönlich zu werden. Sei darauf vorbereitet, die Diskussion zu moderieren, um zu verhindern, dass einzelne Personen für Fehler verantwortlich gemacht werden, und lenke das Gespräch auf die große Lernchance, die du jetzt hast.

Keine Überraschungen

Sage offen, was du vorhast, dokumentiere deinen Prozess und informiere deine Entwicklungsteams rechtzeitig.

Ausbildung

Hilf deinem Team, dir zu helfen, indem du ihnen zeigst, was zu tun ist und welche Informationen von ihnen verlangt werden, damit sie erfolgreich sein können. Praktische Schulungen sind besonders effektiv (z.B. "show one, do one"), aber im Zeitalter von Videologs (Vlogs) und Live-Streaming kannst du auch in Erwägung ziehen, eine Live-Modellierungssitzung im kritischen Rollenstil aufzunehmen und das Video deinen Entwicklungsteams zur Verfügung zu stellen. Das könnten die besten zwei bis drei Stunden sein, die du in deineAusbildung investieren kannst.

Sei vorbereitet

Erkundige dich im Vorfeld deiner Systemmodellierung nach Informationen über das Zielsystem, z. B. nach Systemanforderungen, funktionalen Spezifikationen oder User Stories. So bekommst du ein Gefühl dafür, wohin die Designer gehen könnten, wenn sie eine Reihe von Modulen in Betracht ziehen, und kannst Fragen formulieren, die dir dabei helfen, die notwendigen Informationen für ein gutes Modell zu erhalten.

Motiviere die Teilnehmenden mit Essen und Trinken

Bring Donuts oder Pizza (je nach Tageszeit) und Kaffee oder andere Snacks mit. Essen und Trinken trägt viel dazu bei, Vertrauen zu schaffen und die Teilnehmer/innen dazu zu bringen, auch schwierige Themen zu besprechen (wie z.B. die große Sicherheitslücke, die aus Versehen entdeckt wurde).

Akzeptanz bei der Führung gewinnen

Die Teilnehmer/innen werden sich wohler fühlen, wenn sie anwesend sind und ihre Gedanken und Ideen mitteilen (und sozusagen Leichen im Keller aufdecken), wenn sie wissen, dass ihr Führungsteam mit dieser Aktivität einverstanden ist.

Hinweis

Zum Zeitpunkt der Erstellung dieses Artikels zwingt uns die COVID-19-Pandemie dazu, kreativ darüber nachzudenken, wie wir uns sicher treffen und virtuelle Kameradschaft mit verschickten (oder lokal beschafften) Snacks und Gruppen-Videoanrufen aufbauen können. Das sind Lektionen, die du jederzeit auf die Zusammenarbeit in verteilten Teams anwenden kannst.

Wenn du ein Systemmodell erstellst, egal welcher Art, kannst du es auf einem Whiteboard oder in einer virtuellen Whiteboard-Anwendung zeichnen und in dein bevorzugtes Zeichenpaket übertragen. Aber du musst das nicht immer von Hand machen. Es gibt heute Online- und Offline-Hilfsprogramme¹⁰ die es dir ermöglichen, Modelle zu erstellen, ohne sie vorher manuell zu zeichnen.

Wenn du eines dieser Zeichenpakete verwendest, solltest du dir eine eigene Methode ausdenken, um Metadaten für jedes Element hinzuzufügen, wie oben beschrieben. Du kannst dies im Diagramm selbst als Textfeld oder Callout tun, was das Diagramm aber unübersichtlich machen könnte. Einige Zeichenprogramme führen ein automatisches Layout der Objekte und Verbindungen durch, was bei komplexen Diagrammen wie Spaghetti aussehen kann. Du kannst auch ein separates Dokument in deinem bevorzugten Texteditor erstellen und die notwendigen Metadaten für jedes Element im Diagramm angeben. Die Kombination aus Diagramm(en) und Textdokumenten wird zum "Modell", das es einem Menschen ermöglicht, eine Analyse durchzuführen, um Bedrohungen und Schwachstellen zu erkennen.

Wie sieht ein gutes Systemmodell aus?

Trotz deiner besten Bemühungen kann es zu Komplexität kommen, weil du zu viele Informationen hast oder, noch schlimmer, falsche Informationen. Manchmal ist der potenzielle Detaillierungsgrad des Modells selbst und der damit verbundene Aufwand für die Analyse des Modells eine willkommene Ablenkung von all den Bränden, die du bekämpfst. Es kann aber auch sein, dass ein extremer Detaillierungsgrad eine Anforderung deines Umfelds oder Marktsegments ist. In einigen Branchen wie dem Transportwesen oder der Medizintechnik ist ein höheres Maß an Analyse erforderlich, um ein höheres Maß an Sicherheit zu gewährleisten. Die meisten von uns empfinden die Modellierung von Bedrohungen jedoch oft als ungewohnt, nervig oder als unwillkommene "Ablenkung" von anderen, scheinbar wichtigeren Aufgaben. Aber inzwischen weißt du schon: Ein gutes Bedrohungsmodell macht sich bezahlt.

Aber was macht ein gutes Modell aus? Das hängt von verschiedenen Faktoren ab, unter anderem von der Methode, die du verwendest, von deinen Zielen und davon, wie viel Zeit und Energie du für die Erstellung des Modells aufwenden kannst. Ein gutes Modell ist zwar schwer zu beschreiben, aber wir können die wichtigsten Punkte hervorheben, die ein gutes Systemmodell ausmachen. Gute Modelle haben mindestens die folgenden Eigenschaften:

Genaue

Halte deine Modelle frei von ungenauen oder irreführenden Informationen, die zu einer unvollkommenen Bedrohungsanalyse führen. Das ist allein schwer zu bewerkstelligen, deshalb ist es wichtig, dass du die Unterstützung der Systemdesigner, Entwickler und anderer Projektbeteiligter hast. Wenn sich das Projektteam am Ende laut fragt: "Was ist das?", ist bei der Erstellung des Systemmodells etwas Schlimmes passiert und sollte überarbeitet werden.

Bedeutungsvoll

Modelle sollten Informationen enthalten, nicht nur Daten. Erinnere dich daran, dass du versuchst, Informationen zu erfassen, die auf "Bedingungen für eine mögliche Gefährdung" deines Systems hinweisen. Die Identifizierung dieser Bedingungen hängt von der Methodik der Bedrohungsmodellierung ab, die du letztendlich wählst. Die Methode, die du verwendest, bestimmt, ob du nur nach ausnutzbaren Schwachstellen (auch bekannt als Verwundbarkeiten) suchst oder ob du verschiedene Teile des Systems identifizieren willst, die das Potenzial haben, Schwachstellen zu enthalten, ob ausnutzbar oder nicht (weil sie theoretisch in der Praxis wahrscheinlich ausnutzbar werden, aber nicht auf dem Papier).

Manchmal möchte man so viele Metadaten über das System erfassen wie möglich. Bei der Modellierung geht es jedoch darum, ein Abbild des Systems zu erstellen, ohne es neu zu erschaffen, und genügend Daten bereitzustellen, um Rückschlüsse und direkte Urteile über die Eigenschaften des Systems zu ziehen.

Abgeordneter

Das Modell sollte versuchen, entweder die Absichten des Architektenoder die tatsächliche Umsetzung durch die Entwicklungsteams zu repräsentieren. Das Modell kann uns sagen, was wir von der Sicherheitslage des Systems erwarten können, entweder so wie es entworfen oder wie es umgesetzt wurde, aber normalerweise nicht beides. So oder so wird die Konversation am Konferenztisch im Unternehmen das Äquivalent von "er sagte, sie sagte" sein. Das Team sollte sein System in dem erstellten Modell klar erkennen.

Wohnen

Dein System ist nicht statisch. Dein Entwicklungsteam nimmt ständig Änderungen, Upgrades und Korrekturen vor. Da sich deine Systeme ständig verändern, müssen deine Modelle lebendige Dokumente sein. Überprüfe das Modell regelmäßig, um sicherzustellen, dass es korrekt bleibt. Es sollte das aktuell erwartete Systemdesign oder die aktuelle Systemimplementierung widerspiegeln. Modelliere, "was ist", statt "was sein sollte".

Zu entscheiden, wann dein Modell "gut" ist, ist nicht einfach. Um die Qualität und "Güte" eines Systemmodells zu bestimmen, solltest du Richtlinien entwickeln und sie allen Beteiligten zur Verfügung stellen. In diesen Richtlinien sollte festgelegt werden, welche Modellierungskonstrukte (d.h. Formen, Methoden) für welche Zwecke verwendet werden sollen. Sie sollten auch festlegen, welche Granularität anzustreben ist und wie viele Informationen zu viel sind. Sie sollten auch stilistische Hinweise enthalten, z. B. wie Anmerkungen aufgezeichnet oder Farben im Modelldiagramm verwendet werden sollen.

Die Leitlinien sind nicht per se Regeln. Sie sind dazu da, um bei der Modellierung für Konsistenz zu sorgen. Wenn die Teammitglieder jedoch von den Richtlinien abweichen, aber dennoch ein gutes Modell entwickeln, solltest du sie alle auf einen Drink einladen. Das erste von einem Team erstellte Modell gilt als erfolgreich, wenn die Teilnehmer - die Designer und andere Stakeholder des Systems sowie du selbst - sich einig sind, dass das Modell eine gute Darstellung dessen ist, was du aufbauen willst. Es kann sein, dass es noch Herausforderungen gibt und dass die Beteiligten Vorbehalte gegen ihre Schöpfung (das System, nicht das Modell) haben, aber das Team hat die erste Hürde überwunden und sollte beglückwünscht werden.

Zusammenfassung

In diesem Kapitel hast du einen kurzen Einblick in die Geschichte der Erstellung von Modellen komplexer Systeme erhalten und die Arten von Modellen kennengelernt, die in der Bedrohungsmodellierung häufig verwendet werden. Außerdem haben wir Techniken vorgestellt, die dir und deinem Team helfen, die richtige Menge an Informationen in deine Modelle zu bekommen. So findest du die Nadeln (Daten) im Heuhaufen der Informationen und vermeidest gleichzeitig eine Lähmung der Analyse.

Als Nächstes stellen wir in Kapitel 2 einen allgemeinen Ansatz für die Modellierung von Bedrohungen vor. In Kapitel 3 stellen wir eine Reihe von in der Branche anerkannten Methoden zur Identifizierung und Priorisierung von Bedrohungen vor.

¹ "Der Plan von St. Gallen", Karolingische Kultur auf der Reichenau und in St. Gallen, https://oreil.ly/-NoHD.

² A. E. Dien, Six Dynasties Civilization (New Haven: Yale University Press, 2007), 214.

³ A. Smith, Architectural Model as Machine (Burlington, MA: Architectural Press, 2004).

⁴ Es gibt noch andere Methoden zur Erstellung von grafischen Modellen, die sich für die Analyse eignen, z. B. andere UML-Modelltypen oder die System Modeling Language (SysML) sowie andere Modelltypen, die für eine effektive Analyse nützlich sein können, wie z. B. Kontrollflussgraphen und Zustandsautomaten. Diese Methoden gehen jedoch über den Rahmen dieses Buches hinaus.

⁵ "Datenflussdiagramme (DFDs): An Agile Introduction", Agile Modeling Site, https://oreil.ly/h7Uls.

⁶ Für eine ausführliche Diskussion des Themas siehe Brook S.E. Schoenfield, Securing Systems: Applied Security Architecture and Threat Models (Boca Raton, FL: CRC Press, 2015).

⁷ Übliche Flags sind zum Beispiel ASLR- oder DEP-Unterstützung oder Stack Canaries.

⁸ Wie bei Apache Tomcat, der diesen Mechanismus nutzt.

⁹ Adam Shostack, "DFD3", GitHub, https://oreil.ly/OMVKu.

¹⁰ draw.io, Lucidchart, Microsoft Visio, OWASP Threat Dragon und Dia, um nur einige zu nennen.