What could (possibly) go wrong? - Threat Modeling spielerisch mit einem Kartenspiel gestalten

What could (possibly) go wrong? - Diese Frage sollte man sich bei der Entwicklung einer Anwendung besser früher als spät stellen, denn einige Schwachstellen lassen sich in einem späten Stadium der Entwicklung nur noch schwierig und mit hohem Aufwand beseitigen. Einige Entscheidungen sind sogar so tief im System verankert, dass sie bereits in der Architektur bedacht werden müssen. Deshalb sollte Sicherheit schon weit im Voraus, bevor die erste Zeile Code geschrieben wird, in der Planungs- und Architekturphase betrachtet werden: Security by Design. Dabei gilt es, möglichst alle Bedrohungen für die Anwendung zu bedenken und Gegenmaßnahmen zu planen. Dies geschieht im sogenannten Threat Modeling.

Threat Modeling

Beim Threat Modeling werden Bedrohungen ausfindig gemacht und eine Risikobewertung dieser vorgenommen, um priorisierte Gegenmaßnahmen mit möglichst großem Wirkungsgrad entwickeln zu können. Dabei kann die Methodik je nach Anwendungsfall ganz verschiedene Formen annehmen: So können zum Beispiel die Gefahren für ein ganzes Unternehmen oder auch kleinere Bausteine wie beispielsweise ein einzelnes Modul einer Webanwendung betrachtet werden. Im Folgenden soll es exemplarisch um das Threat Modeling einer Webanwendung gehen. Aufgrund einiger Sicherheitslücken bei Anwendungen für Corona-Testzentren, die in den Zeiten der Pandemie die Gesundheitsdaten vieler Menschen bedroht hatten, soll genau eine solche Anwendung mit besserem Sicherheitsstand entwickelt werden.

Obwohl es praktisch unmöglich ist, alle potentiellen Schwachstellen einer Anwendung ausfindig zu machen, wurden in der Vergangenheit Frameworks entwickelt, welche sicherstellen sollen, dass zumindest die wichtigsten Schwachstellen beim Threat Modeling bedacht werden. Eines dieser Frameworks ist die von Microsoft entwickelte STRIDE-Mnemonik. Dabei ist STRIDE ein Akronym für die Kategorien von verschiedenen Angriffstechniken auf Anwendungen und Systeme und steht für:

• Spoofing (Fälschung von Identitäten)
• Tampering with Data (Manipulation von Daten)
• Repudiation (Verhinderung der Nachweisbarkeit)
• Information Disclosure (Offenlegung von Informationen)
• Denial of Service (Einschränkung der Verfügbarkeit)
• Elevation of Privilege (Umgehung von Zugriffskontrollen)

Diese Mnemonik soll die Teams beim Threat Modeling unterstützen und insbesondere sicherstellen, das keine Kategorie von Angriffstechniken übersehen wird. Das Framework selbst erhebt dabei aber nicht den Anspruch auf Vollständigkeit. Trotz der Standardisierung der Methodik muss immer individuell auf die Gegebenheiten geachtet werden und jedes Framework kann begründet abgewandelt werden. Hinzu kommt, dass sich auch Angriffstechniken immer weiterentwickeln und sich somit auch die Frameworks weiterentwickeln. Neben STRIDE gibt es eine Reihe von weiteren Modellen und Frameworks für das Threat Modeling wie beispielsweise Kill Chains, Attack Trees, PASTA, et cetera.

Gamification

Um den Threat-Modeling-Prozess nicht nur als „notwendiges Übel“ für die Erfüllung von Compliance-Checklisten umzusetzen und ihn gleichzeitig effektiver zu gestalten gibt es schon seit längerer Zeit den Ansatz der Gamification. Durch das Einsetzen spielerischer Elemente kann die Motivation der Beteiligten steigen und ein nachhaltigeres Ergebnis erzielt werden. Hierzu wurden in der Vergangenheit bereits mehrere Kartenspiele entwickelt, die auf unterschiedliche Bereiche abzielen. Beispiele hierfür sind Elevation of Privilege von Microsoft und Cornucopia von OWASP. Weitere Security-relevante Spiele findet man hier.

Um die Anforderungen an die Threat-Modeling-Projekte von aramido mit Fokus auf Webanwendungen ideal abdecken zu können, wurde ein eigenes Kartenspiel hierzu entwickelt.

Das Kartenspiel

Das Kartenspiel besteht aus 39 Spielkarten, die jede einen bestimmten Angriff darstellen. Die Karten haben folgenden Aufbau:

• STRIDE-Kategorie: Die STRIDE-Kategorie, die der Angriff zuzuordnen ist. Durch diese Kategorie werden die Karten gruppiert.
• Angriffstitel: Der Titel des konkreten Angriffs.
• Angriffsbeschreibung: Eine kurze Beschreibung des Angriffs.
• CVSSv3-Score: Der CVSSv3-Score der Karte schätzt die Gefährlichkeit eines Angriffs. Dieser Score wird auch bei der Einordnung von Schwachstellen verwendet, hierzu weiter unten mehr. Im Kartenspiel dient diese Zahl vor allem dazu die Karten einer Kategorie in eine Reihenfolge zu bringen.
• Kartennummer: Eine eindeutige Nummer für jede Karte, die für den Spielverlauf nicht relevant ist.

Der Joker hat als einzige Karte mit der Bedrohung des unbekannten Zero-Day-Exploits den CVSS-Score 10 und sticht somit jede der übrigen Karten.

Spielablauf

1. Das Kartenspiel wurde dazu konzipiert, um das Threat Modeling für eine reale Applikation spielerisch zu gestalten. Deshalb sollte zu Beginn die Architektur der Anwendung graphisch zum Beispiel durch ein Diagramm dargestellt werden. Dies erleichtert im Folgenden die Diskussion und die Nachvollziehbarkeit für alle Beteiligten.
2. Die Karten werden gemischt und an die Spieler ausgeteilt. Alle Spielende erhalten möglichst die gleiche Anzahl Karten. Da Threat Modeling praktisch beliebig ausgedehnt werden kann, ist es wichtig eine maximale Spielzeit zu bestimmen.
3. Im Uhrzeigersinn wird nacheinander eine Karte ausgespielt und dann laut vorgelesen.
4. Gemeinsam wird überlegt, ob die bereits geplanten oder implementierten Schutzmaßnahmen den Angriff ausreichend abwehren. Dabei soll die Karte möglichst auf die Anwendung und Organisation angepasst werden, ohne das Wesen der Bedrohung zu verändern. In dieser Diskussion können und sollen Hypothesen und Abwägungen getroffen werden, um einen möglichst kreativen Angriff zu entwickeln.
5. Kann der Angriff nicht sicher abgewehrt werden, verbleibt die Karte offen auf dem Tisch. Ist der Angriff unmöglich, wird die Karte umgedreht und auf einen Stapel gelegt.
6. Die offen liegende Karte kann nun reihum von allen Spielenden übertrumpft werden, indem man eine Karte der gleichen Kategorie mit gleichem oder höherem CVSS-Score spielt. Ist der Angriff nicht möglich wird die Karte umgedreht und die Trumpf-Runde fährt mit der nächsten Person fort. Sofern der Angriff nicht abgewehrt werden kann, darf die Karte offen auf die bereits liegende gelegt werden. Es besteht keine Pflicht, eine Karte zu legen, Karten dürfen strategisch behalten werden. Die Trumpf-Runde ist beendet wenn niemand die zuoberst liegende Karte mehr übertrumpfen kann oder will. Die Person, die die oberste Karte mit dem höchsten CVSS-Score gelegt hatte, darf den gesamten offenen Stapel an sich nehmen und ihren Punkten zuschreiben.
7. Nach dem Ende der Trumpf-Runde fährt das Spiel in der ursprünglichen Reihenfolge, also als hätte es keine Trumpf-Runde gegeben, fort. Es darf nun eine Karte beliebiger Kategorie gespielt werden.
8. Der Joker kann unabhängig von der aktuellen Kategorie gespielt werden und übertrumpft alle anderen Spielkarten.
9. Das Spiel ist beendet, wenn alle Karten gespielt wurden oder wenn die Spielzeit abgelaufen ist.
10. Gewonnen hat, wer die meisten Punkte sammeln konnte.

Der Fokus dabei sollte klar auf der Diskussion der Machbarkeit der unterschiedlichen Angriffe, Gegenmaßnahmen und dem Austausch unter einander liegen.

Hintergrundwissen: CVSSv3-Score

Der CVSS-Score ist eine Kennzahl, um die Schwere von Schwachstellen zu klassifizieren. Dabei fließen im Wesentlichen zwei Komponenten in dessen Berechnung ein: die Auswirkung und die Ausnutzbarkeit. Zum einen werden die Auswirkungen einer Schwachstelle bewertet, also der Schaden, der bei einer erfolgreichen Ausnutzung eintreten kann. Zum Beispiel sind die Auswirkungen deutlich größer, wenn durch die Schwachstelle beliebiger Programmcode auf dem System ausgeführt werden kann (Remote Code Execution), als wenn die Angreifer nur in der Lage wären, einzelne Benutzernamen aus der Datenbank auszulesen. Die zweite Komponente ist die Ausnutzbarkeit, wie einfach es also ist, die Schwachstelle einzusetzen. Eine Schwachstelle, die aus dem öffentlichen Internet heraus ausgenutzt werden kann, hat eine höhere Ausnutzbarkeit als eine, die nur mit physischem Zugriff auf den Server vor Ort möglich ist.

Aus diesen zwei Komponenten errechnet sich ein Wert zwischen null und zehn. Je höher der Score ist, desto höher ist das Risiko der Schwachstelle und desto wichtiger ist es, Gegenmaßnahmen dagegen zu finden.

Let's Play

Um das Spiel einmal exemplarisch durchzuspielen soll das Szenario vom Beginn noch einmal aufgegriffen werden. Alice, Bob und John sind Webentwickler bei der Musterfirma GmbH. Sie sind gerade dabei, eine Webanwendung für ein Corona-Testzentrum zu entwickeln. Da sie die Anwendung sicher betreiben möchten, führen sie ein Threat Modeling durch und beschließen, hierzu das Kartenspiel zu verwenden, um den Prozess spielerisch zu gestalten.

Die Anwendung

Bei der Anwendung handelt es sich um eine gewöhnliche, vielen schon bekannte Applikation, um Termine für Corona-Tests zu vereinbaren und die Ergebnisse abzurufen. Dabei hat die Anwendung folgende Eigenschaften:

Arten von Benutzern:

• Admin (legt Testzentren an)
• Testpersonal (trägt Stammdaten und Testergebnisse ein)
• Patienten (buchen Termine, rufen Ergebnisse ab)

Funktionen der Anwendung:

• Terminplanung und -buchung
• Bereitstellen der Testergebnisse per E-Mail
• Meldung an Gesundheitsamt per E-Mail

Alice, Bob und John haben bereits die wichtigsten Schutzziele identifiziert und eine Priorisierung vorgenommen. Dies soll dabei helfen die Kritikalität von möglichen Schwachstellen im Zusammenhang mit ihrer Applikation besser beurteilen zu können.

Um die Diskussion zu vereinfachen haben die Entwickler die Infrastruktur-Architektur mit einem Diagramm visualisiert:

Die Anwendung wird in einer modernen Cloud-Umgebung mit folgenden Eigenschaften gehostet:

• Datenbank für Texte und nicht-binäre Inhalte (User, Passwörter, Stammdaten zu Testzentren, ...)
• Blob Storage für Dateien (Testergebnisse als PDF)
• E-Mail-Versand-Service
• Anwendung:
• Webserver (nginx)
• Webanwendung: React im Frontend, Java Backend
• Externe User:
• Testzentren (shared account für jedes Testzentrum, PW klebt unter der Tastatur)
• Patienten (keine richtigen Accounts, Authentifizierung nur für Testergebnis: PDF ist mit Geburtsdatum verschlüsselt)
• Interne User:
• Admins, die neue Teststationen anlegen

Das Spiel

Alice, Bob und John setzen sich im Besprechungsraum gemeinsam an einen Tisch und projizieren das Diagramm der Anwendung auf den großen Bildschirm. Anschließend werden die Karten von Bob gemischt und möglichst gleichmäßig auf alle drei Mitspieler verteilt. Für den Anfang einigen sich die Spieler die Spielzeit zunächst auf eine Stunde zu begrenzen und stellen hierzu einen Timer. Nach Absprache mit den anderen beginnt Alice, legt die erste Karte und liest diese laut vor:

Gemeinsam diskutieren die Spieler nun, ob eine Überlastung der Anwendung durch Aufruf einer rechenintensiven Funktion möglich ist. Alice meint, dass die PDF-Generierung eine aufwendige Funktion ist. Bisher wird mit der E-Mail ein Link zum PDF verschickt und das PDF wird bei jedem Aufruf des Links neu mit dem Ergebnis aus der Datenbank generiert. Dies könnte ein Angreifer verwenden um sehr oft den Link automatisiert aufzurufen und somit die Anwendung überlasten. Bob gibt Alice recht und stellt gleich eine mögliche Lösung für das Problem vor. Indem das PDF nur einmal generiert und dann abgespeichert wird, entfällt die rechenintensive PDF-Generierung bei jedem Linkaufruf. John bestätigt dies und stellt eine weitere Lösungsmöglichkeit vor. Statt einen Link mit der E-Mail zu verschicken, könnte man das PDF einmal generieren und dann als Anhang direkt verschlüsselt mit der E-Mail an den Endnutzer schicken. Um das Problem nicht zu vergessen werden kurz sowohl das Problem als auch mügliche Lösungen notiert. Da es sich um einen potentiell möglichen Angriff gehandelt hat, verbleibt die Karte offen auf dem Tisch.

Als nächstes ist Bob an der Reihe. Da Bob nur eine einzige Karte der Kategorie Denial of Service auf der Hand hält, welche auch noch einen höheren CVSS-Score als die zuvor von Alice gelegte Karte hat, beschließt er diese auch zu legen:

Die drei sind sich schnell einig, dass dieser Angriff bei ihrer Applikation nicht möglich ist, da es keine Möglichkeit gibt Dateien hochzuladen. Die PDF-Generierung findet von der Anwendung selbst statt. Deshalb wird die Karte umgedreht und auf einen separaten Stapel gelegt.

John legt nun folgende Karte, um damit die zuvor von Alice gelegte Karte zu übertrumpfen:

John begründet die Machbarkeit des Angriffs damit, dass der verwendete Webserver nginx in der Standardkonfiguration anfällig gegenüber Slow-HTTP-Angriffen ist. Nach einer kurzen Recherche geben Alice und Bob ihm recht und John legt die Karte auf die von Alice und fügt zu den Notizen hinzu, dass die Standardeinstellungen von nginx vor dem Deployment zu ändern sind. Da keiner der Spieler eine Karte der Kategorie Denial of Service mit einem höheren CVSS-Score als 7,5 auf der Hand hält, bekommt John die zwei Punkte und legt die beiden Karten vor sich ab.

Nun ist Bob an der Reihe eine Karte zu legen. Er entschließt sich mit einem geringen CVSS-Score zu beginnen und legt die folgende Karte auf den Tisch:

John meint, dass die Cloud-Instanz über eine Firewall verfügt und deshalb kein Scan der Anwendung möglich ist. Bob widerspricht dem und weist daraufhin, dass es zwar eine Firewall gibt, diese aber nicht so konfiguriert ist, dass Schwachstellenscans automatisch erkannt werden (Intrusion Detection System) sondern bisher nur auf Basis von Ports der Netzwerkverkehr gefiltert wird. Alice gibt Bob recht und auch John sieht ein, dass er mit seiner anfänglichen Behauptung falsch lag. Die drei fügen die Konfiguration der IDS-Funktion auf der Firewall zu ihrer Liste hinzu.

John beschließt die Karte von Bob zu übertrumpfen und legt:

Alle sind sich einig, dass die geteilten Accounts der Testzentren ein Problem darstellen. Somit kann nicht nachvollzogen werden welcher Mitarbeiter im Testzentrum ein Testergebnis hinzufügt oder ändert. Die Karte wird also auf die zuvor gelegte Karte gelegt.

Nun hat Alice die Möglichkeit die Karte zu übertrumpfen. Sie sieht, dass bald eine Stunde seit Beginn des Spiels vergangen ist und entscheidet sich deswegen nun den Joker zu legen. Der Joker übertrumpft die Karte mit einem unbekannten Zero-Day-Exploit und Alice bekommt die drei Karten und drei Punkte.

Da die Stunde nun vorbei ist, beschließen die drei das Threat Modeling für heute zu beenden und möchten die Notizen gleich als Tickets in das Projektmanagementsystem überführen. Alice hat mit drei Punkten vor John mit zwei Punkten das Spiel gewonnen. Da sie alle die Erkenntnisse aus dem Spiel für sehr gewinnbringend halten, nehmen sie sich vor in der nächsten Woche ein etwas ausgiebigeres Threat Modeling von drei Stunden Dauer wieder mit Hilfe des Kartenspiels durchzuführen.