Threat Modeling - weshalb ist es notwendig?

Wir leben in und mit einem hochverdichteten digitalen Infrastrukturnetz. Dieses Netz wird kontinuierlich dichter geknüpft, eine Menge neuer mobiler und immobiler Geräte, Anlagen und Systeme kommen täglich dazu. In dem Netz werden gigantische Volumina an Daten bewegt und Kommandos abgesetzt. Daten haben mittlerweile den Stellenwert eines hochwertigen Rohstoffs, weswegen es große Begehrlichkeiten gibt, diesen Rohstoff außerhalb legaler Wege anzuzapfen und für nicht immer lautere Zwecke zu verwenden. Die Möglichkeit, theoretisch jedes mit dem Netz verknüpfte Gerät ansprechen zu können, verleitet Akteure dazu, damit Unfug zu treiben oder aber großen Schaden anzurichten. Die ungeheure Vielfalt der Möglichkeiten, Freiheiten und Bequemlichkeiten, die dieses Netz uns bietet, ist also verknüpft mit einer großen Bandbreite von intrinsischen Vulnerabilitäten, derer wir uns ebenso bewusst sein sollten wie der Möglichkeiten.

Europäische Cyberresilienz-Verordnung

Das ist nichts Neues. Parallel zu der Verdichtung des Netzes ging auch die Entwicklung verschiedenster Schutz- und Abwehrstrategien gegen die Bedrohungen (engl. Threats) aus dem Netz einher. Einer der jüngsten Schritte hierbei ist der im Sommer 2024 in Kraft getretene European Cyber Resilience Act (CRA), zu deutsch Cyberresilienz-Verordnung. Da er den rechtlichen Status einer Verordnung hat, ist er direkt umzusetzen ohne den Umweg über die nationale Gesetzgebung. Dies hat unmittelbare Auswirkungen auf die Wirtschaft: Kurz gesagt sind Unternehmen, die mit dem oder über das Internet verbindbare Produkte herstellen, ab jetzt verpflichtet, die Cybersicherheit dieser Produkte zu verbessern. Dabei spielt weder die Größe der Produkte eine Rolle noch ob es Endprodukte sind, die an den Verbraucher gehen, oder selbst zur Herstellung von Produkten verwendet werden.

Threat Analysis (TA) als Teil des Threat Modeling (TM)

Einer der Wege zur Verbesserung der Cybersicherheit besteht in der Durchführung von Bedrohungsanalysen (engl. Threat Analysis, TA). Dabei wird für ein Gerät oder System - vereinfacht ausgedrückt - festgestellt,

• welche Art von Cyberangriff
• auf welchem Weg und
• wie ausgeführt werden könnte
• und welche Maßnahmen dagegen ergriffen werden sollten.

Die während einer solchen TA festgestellten potentiellen Bedrohungsszenarien werden tabellarisch und/oder graphisch dargestellt, bewertet und Gegenmaßnahmen festgelegt. So erhalten wir ein konsistentes Bild über die möglichen Bedrohungen und Gegenmaßnahmen sowie deren aktuell implementierten Stand. Dieser ganze Vorgang, der in der Regel mehrere Iterationen durchläuft, ist das Threat Modeling, TM.

Bei der kurzen Liste oben fällt auf, dass die Betrachtung, von wem der Angriff auf ein Gerät oder System ausgeführt werden könnte und warum bzw. wozu, nicht enthalten ist. Hier kann man geteilter Meinung sein, aber in unserer Firma wird bei Bedrohungsanalysen auf diesen Aspekt aus mehreren Gründen eher nicht eingegangen. Zum einen ist eine aussagekräftige Bedrohungsanalyse auch bei kleineren Geräten schon eine ziemlich aufwendige Angelegenheit, sodass wir den Aufwand lieber in die produktive Entwicklung der Schutzmaßnahmen stecken. Es ist zum anderen wohl auch kaum möglich, sich in all die möglichen Ursachen und Motive von Angreifern hineinzudenken und schließlich ist es auch wenig zielführend. Zentraler Denkansatz sollte aus meiner bzw. unserer Sicht vielmehr sein: Was könnte meinem System angetan werden und wie schütze ich es. Das bedeutet auch: Auch wenn es diese europäische Verordnung nicht gäbe, sollte uns der Schutz unserer internetverbundenen Geräte und Produkte am Herzen liegen.

Wie wird ein Threat Modeling gemacht?

So sehr unterschiedlich die Geräte und Systeme auch sind, die bei einem TM untersucht werden, so gibt es doch einige gemeinsame Herangehensweisen. Im Detail werden die Analysen dann natürlich je nach Art des betrachteten Systems sehr unterschiedlich.

Ziel und Ende eines Threat Modeling

Die Frage nach dem genauen Ziel eines TM ist eng mit der Frage verbunden, wann sie fertig ist. Hier kann man zunächst die salopp erscheinende Antwort "Definiere mir "fertig"?!" geben. Tatsächlich ist eine Threat Analyse mit einigen Stolperfallen versehen. Eine davon ist die Gefahr, dass man irgendwann den Wald vor lauter Bäumen nicht mehr sieht und sich in Details verliert bzw. das große Ganze nicht mehr im Blick hat.

Um dieser Gefahr zu begegnen, sollten wir ein TM grundsätzlich iterativ anlegen. Das bedeutet, dass man sich ein System in mehreren Annäherungs- und Detaillierungsschritten ansieht. Das Budget für eine TA ist in der Regel relativ knapp, aber darauf ist die folgende Herangehensweise ausgerichtet.

Das System kennenlernen

Die Qualität eines TM steht und fällt mit der genauen und detaillierten Kenntnis des zu analysierenden Systems, um mögliche Angriffspunkte und -szenarien identifizieren zu können. Das bedeutet, dass es für ein TM einen guten kommunikativen Draht zu den Leuten braucht, die diese Kenntnisse besitzen; kaum jemand wird auch bei der Mitarbeit an einer Entwicklung alles in der nötigen Detailtiefe kennen. Außerdem sollte man über Arten und Mechanismen von Bedrohungen soweit vertraut sein, dass man entscheiden kann, ob sie für das zu analysierende System relevant sind.

Die zu betrachtenden Komponenten und Systemanteile definieren

Zuvor müssen aber im Fall eines komplexen Systems in jedem Fall mit dem Auftraggeber zusammen die Anteile des Gesamtsystems definiert werden, die in der jeweiligen Iteration betrachtet werden und welche nicht, sowie die Detailtiefe, ob es also eher eine Übersicht oder eine wirklich detailliert ausgearbeitete Analyse sein soll.

Daran sollte man sich auch strikt halten, um der Gefahr zu begegnen, sich in der Komplexität zu verlieren. Allerdings kann es in Einzelfällen sinnvoll sein bzw. wird sich in der Praxis herausstellen, dass noch einzelne nicht berücksichtige Systemanteile zumindest für eine überblicksartige Analyse betrachtet werden. Das zu analysierende System wird ab hier als SUA (System under Analysis) bezeichnet.

Fertig - um auf die oben gestellte Frage zu antworten - ist jeweils nur die Iteration, sobald die festgelegten Anteile so detailliert wie vereinbart analysiert und beschrieben sind und die dazugehörigen Gegenmaßnahmen festgehalten und bewertet. Dies folgt dem agilen Motto "good for now". Dies ist einer der schwierigsten Punkte in einem TM: Eine Analyse bzw. die Modellierung der Bedrohungen vorläufig zu beenden, obwohl klar ist, dass es noch tausende von Aspekten gibt, die noch nicht berücksichtigt sind. Das ist aber in Ordnung, diese Aspekte sollen in den darauffolgenden Iterationen behandelt werden.

So weit hergeholt ist der Vergleich mit der agilen Herangehensweise übrigens nicht, denn es gibt ein Threat Modeling Manifesto, das sich in Aufmachung und Ansatz deutlich an das Agile Manifest anlehnt. Aus meiner Erfahrung ist es ganz hilfreich, sich das Manifest zur Einstimmung in ein TM durchzulesen.

Die vier Schritte eines Threat Modelings

Es ist üblich, ein TM in folgenden vier Schritten anzulegen (in Englisch, um die übliche Terminologie beizubehalten):

• What are we working on?
• What can go wrong?
• What are we going to do about it?
• Have we done a good enough job?

What are we working on?

In diesem Schritt sehen wir uns das SUA genauer an, beschreiben es bzw. legen eine Systemskizze an, falls nötig. Die einzelnen Komponenten erhalten eindeutige Bezeichner (IDs), damit in den folgenden Schritten immer klar ist, über welche Komponente gesprochen wird. Nach diesem Schritt sollte eine gewisse Vertrautheit mit dem SUA erreicht sein, um sich die nächste Frage zu stellen.

What can go wrong?

Das bedeutet: Wie kann das System, das SUA oder eine Komponente davon, eine Schnittstelle, ein Kommunikationsweg usw. attackiert und kompromittiert werden und welches schädliche Ergebnis kann dabei erzielt werden? Die Motivation des Angreifers sollte dabei, wenn überhaupt, nur eine untergeordnete Rolle spielen. Man kann sie heranziehen, solange dies dabei unterstützt, mögliche Bedrohungen und Angriffe zu identifizieren. In dem Schritt spielen dagegen Gegenmaßnahmen sowie Wahrscheinlichkeit und Schwere der Auswirkung noch überhaupt keine Rolle: Hier sollen zunächst möglichst umfassend alle halbwegs realistischen und relevanten Bedrohungsszenarien erarbeitet und ebenfalls mit IDs versehen aufgelistet werden. Da Angriffe so gut wie immer aus mehreren Schritten bestehen, kann man Angriffsszenarien in Attack Trees graphisch darstellen. Das hat den Vorteil, dass verschiedene Angriffsansätze, die zum selben schädlichen Ergebnis führen, in einem Diagramm veranschaulicht werden können.

Auch hier lauert die Gefahr, dass man sich in zuvielen Details verliert. Deshalb immer das große Ganze bzw. die zur Verfügung stehende Zeit im Auge behalten.

What are we going to do about it?

Im nächsten Schritt überlegen wir uns, welche Maßnahmen gegen die einzelnen Bedrohungen und komplexen Bedrohungsszenarien ergriffen werden können. Das sind im Wesentlichen:

• Eliminate: Eine Bedrohung dadurch eliminieren, dass sie einfach nicht mehr stattfinden kann, z.B. eine ungenutzte IO-Schnittstelle abklemmen.
• Mitigate: Eine Bedrohung durch geeignete Gegenmaßnahmen reduzieren, dass sie zumindest unwahrscheinlicher wird. Dafür gibt es eine ganze Reihe von Maßnahmen, was hier aber zu weit führen würde.
• Transfer: Die Verantwortung für die Schritte Eliminate oder Mitigate nach Rücksprache einer dritten Partei übertragen, z.B. weil dies in deren Aufgabenbereich fällt oder weil es einfacher ist.
• Accept: Akzeptieren, dass es die jeweilige Bedrohung gibt, entweder weil ihre Minderung/Eliminierung unverhältnismäßigen Aufwand bedeutet im Vergleich zum Risiko, oder weil es schlicht unmöglich ist.

Have we done a good enough job?

Dieser Schritt wird aufgrund seiner unklaren Zielrichtung kontrovers diskutiert, manche TMler lassen ihn offenbar als expliziten Schritt weg, führen ihn stattdessen in Form von prozessbegleitenden Reviews, Daylies etc. durch. In unserer Praxis bedeutet er ein zeitlich begrenztes Review des erstellten Threat Models inklusive erarbeiteter Gegenmaßnahmen auf mindestens folgende Fragen:

• Sind alle vereinbarten Komponenten des SUA erfasst und in der vorgesehenen Detailtiefe analysiert?
• Ist das Threat Model in sich konsistent?
• Ist jede Bedrohung bezüglich Gegenmaßnahmen bewertet?
• Sind alle vorexistenten Sicherheitsmaßnahmen mit aufgenommen?
• Welche Komponenten sollten in der nächsten Iteration detaillierter betrachtet werden?

Iteratives Vorgehen

Diese vier Schritte werden einige Male wiederholt, immer in Absprache mit dem Auftraggeber, bis letztlich gemeinsam festgelegt wird, dass das Ergebnis "good for now" ist. Zwischen den einzelnen Iterationen kann durchaus einige Zeit liegen, da die Ergebnisse eines TM bei größeren SUA ziemlich umfangreich werden können. Außerdem werden die Gegenmaßnahmen zwischen den Iterationen implementiert, ausgewertet und danach kann es sinnvoll sein, eine neue Bedrohungsanalyse desselben SUA unter Einbeziehung der implementierten Gegenmaßnahmen durchzuführen. Letztlich bekommt jedes Threat Modeling trotz der anfänglich ziemlich gleichen Herangehensweise immer sein eigenes Gesicht.