Wenn ich als Security-Berater in Projekte komme und nach dem Threat Model frage, ist die Antwort häufig: „Haben wir eingeplant! Den Penetration-Test machen wir kurz vor Go-Live.” Während Pentests kurz vor dem Go-Live eines Projekts gemacht werden, wird ein Threat Model bereits am Anfang in der Design-Phase durchgeführt. Das hat den Vorteil, dass konzeptionelle Schwächen von vorneherein aufgedeckt werden. Eine Sicherheitslücke, die ansonsten einen enormen Aufwand in der Behebung bedeuten würde, kann geschlossen werden. Was ein Threat Model ist und wie es die Risiken deiner Anwendungen signifikant reduzieren kann, zeigt dieser Beitrag.
Was ist Threat Modeling?
Threat Modeling oder zu Deutsch Bedrohungsanalyse klärt die Frage: Was kann eigentlich schief gehen? In der Regel sind Entwickler:innen und Product Owner:innen eher darauf fokussiert, wie ein Feature im Best-Case funktioniert. Klassischerweise werden in User Stories die Akzeptanzkriterien in der Form angeben, dass beschrieben wird, was Benutzer:innen erwarten. Wenn ich z. B. in einer User Story ein Avatar-Bild hochladen kann, dann ist ein Akzeptanzkriterium, dass danach mein neues Avatar-Bild im Profil angezeigt wird. Aber was ist, wenn ein böswilliger Angreifer nicht eine Grafik als Avatar-Bild hochlädt, sondern eine Malware, beispielsweise eine Web-Shell? Wie verhält sich dann das System? Es geht bei einem Threat Model also darum, sich im Vorfeld zu überlegen, was alles schief gehen könnte und sich dann geeignete Gegenmaßnahmen zu überlegen. Das sagte auch schon Adam Shostack, einer der Begründer des Threat Modeling: „What can possibly go wrong?”
Der große Vorteil bei dieser Herangehensweise ist, dass man bereits in der Design-Phase eines Software-Projektes mögliche Risiken bezüglich der IT-Security identifizieren und einplanen kann. In dieser Phase sind diese meist deutlich einfacher und kostengünstiger zu beheben.
Wie mache ich denn so ein Threat Model für mein Projekt?
Wenn man sich bei einem neuen Feature die Frage stellt „Was kann eigentlich schief gehen?“, ist es wichtig, sich vom Gedanken zu verabschieden “Warum sollten Benutzer:inenn so etwas abwegiges tun?” Man muss sich eines klar machen: Wenn man in einem IT-System etwas falsch oder fehlerhaft benutzen kann, dann wird das auch früher oder später jemand machen. Das ist Murphys Law. Dabei muss das noch nicht einmal mit krimineller Absicht passieren, sondern kann schlicht und ergreifend versehentlich passieren, ein sogenanntes Fat-Finger-Problem.
Allerdings macht es bei größeren Software-Projekten Sinn, das Threat Modeling strukturierter und geordneter anzugehen. Es gibt hierzu diverse elaborierte und zum Teil auch akademische Ansätze wie PASTA oder OCTAVE. Allerdings bringen diese Frameworks relativ viel Aufwand mit sich. Das macht Sinn, wenn man Software z. B. für eine Flugzeug oder ein Röntgengerät erstellt. Bei einem Web-Shop mutet dieser Ansatz aber eher einem Kanonen-auf-Spatzen-schießen an. Hinzu kommt, dass solche Threat Models oft extern angefertigt werden. Das heißt, es gibt eine Gruppe von Security Expert:innen, die die Design Dokumente sichten und als Ergebnis ein Dokument mit dem Threat Model über den Zaun werfen. Ein Beispiel, dass das sehr gut illustriert, stammt von der ETH Zürich. Dort haben Security-Forscher den Messenger Threema analysiert: Three Lessons From Threema: Analysis of a Secure Messenger. Das Problem mit so einem Dokument ist, dass man es als Security Experte super versteht, aber als Entwickler:in oder gar Product Owner:in nur noch bedingt nachvollziehen kann. So ein Dokument landet dann gerne mal in der Schublade mit dem hehren Ziel, es durchzuarbeiten, wenn noch Zeit am Ende des Projekts übrig ist. Wir alle wissen, dass am Ende eines Projektes noch nie Zeit übrig war.
Wie machen wir Threat Modeling?
Wir bei iteratec haben langjährig sehr gute Erfahrungen damit gemacht, Threat Modelings in einem Workshop durchzuführen. Dabei legen wir sehr großen Wert auf eine möglichst diverse Zusammensetzung der Teilnehmenden. Oftmals besteht der initiale Reflex nur Entwickler:innen in so einen Workshop zu schicken, da diese ja schließlich die Software sicher programmieren sollen. Aber gerade wenn es darum geht, sich zu überlegen, was alles schief gehen kann, wie man die Software austricksen kann, sind auch die unterschiedlichen Blickwinkel aller Stakeholder hilfreich. Beispielsweise wissen oft die Fachanwender am besten, wie man die Prozesse kreativ umgehen kann. Daher empfehlen wir immer, dass neben Entwickler:innen auch Personen aus Operations, Fachabteilung, Projektmanagement usw. anwesend sind.
Initial gehen wir dann die wichtigsten Anwendungsfälle des Systems auf einem White Board durch. Dabei betrachten wir vor allem, wer mit wem kommuniziert, welche Akteure mit dem System interagieren und welche Assets – die Kronjuwelen – wo verarbeite werden. Allein das Big Picture aufzumalen, bietet einen großen Mehrwert, weil danach allen Beteiligten klar ist, wie das System in Gänze funktionieren soll und wie die einzelnen Komponenten miteinander interagieren. Nicht selten hören wir Aussagen wie “Jetzt verstehe ich, warum ihr das so haben wollt und das nicht einfacher geht.”
Anschließend schlüpfen wir in die Rolle eines böswilligen Angreifers. Wir überlegen uns, wie wir Schaden in der Rolle eines Akteurs anrichten können und formulieren sogenannte Evil User Stories. Ein Beispiel einer solchen Evil User Story ist: Als Datenbankadministrator ziehe ich eine Kopie der Kundendatenbank, um diese im Darknet zu verkaufen. Also entweder der sogenannte Insider oder, was viel häufiger der Fall ist, ein Datenbankadministrator wurde kompromittiert, und der Angreifer ist in dessen Rolle unterwegs. Beim gemeinsamen schreiben der Evil User Stories orientieren wir uns an dem STRIDE Model. Anschließend werden die Evil User Stories nach dem DREAD Model in der Kritikalität bewertet.
Im letzten Schritt definieren wir dann für jede entwickelte Evil User Story geeignete Gegenmaßnahmen und besprechen sie. Dadurch können die Teams die Gegenmaßnahmen direkt priorisiert in ihr Backlog übernehmen.
In der Regel führen wir solche Workshops halb- oder ganztägig mit zwei Security Expert:innen durch. Diese Vorgehensweise hat nach unserer Erfahrung den großen Mehrwert, dass Angriffsszenarien gemeinsam im Team durchgesprochen werden. Wir erklären dabei tiefergehende Rückfragen. Das erhöht die Awareness und das Verständnis gegenüber Security-Risiken im Gegensatz zu einem abstrakten Papier ganz massiv. Zudem ist es für die Teams extrem hilfreich, auch gleich mit uns Security Experten die konkrete Umsetzung von Gegenmaßnahmen zu diskutieren. So können projektspezifische Randbedingung berücksichtigt werden und Gegenmaßnahmen landen nicht einfach als nicht machbar in der Schublade.
Neugierig geworden und Lust auf ein Threat Model für dein Software Projekt? Sprich mich gerne an.
Sven Strittmatter - ist Software-Architekt und Security-Consultant bei der iteratec GmbH. Er entwickelt seit rund 20 Jahren professionell Software im agilen Umfeld. Dabei hat er schon sehr früh Security “the hard way” gelernt. Seit dem betrachtet er Security als einen wesentlichen Bestandteil von Software-Projekten und hilft Teams mit Trainings, Beratung und hands-on sichere Software zu entwicklen.
Haben Sie Fragen oder benötigen Sie Unterstützung?
Mehr zu den Möglichkeiten von Threat Modeling für Ihr Unternehmen finden Sie auf unserer Webseite.
Sprechen Sie uns gerne an oder vereinbaren Sie einen Termin.