Unternehmen sind mehr denn je auf verlässliche und vor allem sichere Anwendungen angewiesen: zum Beispiel beim Projektmanagement in der Cloud, bei vernetzten Anlagen in einer Smart-Factory und beim Umgang mit sensiblen Daten im Kundenservice. Doch auch die besten Softwarekonzepte nützen nichts ohne eine effektive Erprobung. Um bereits vor der Softwareentwicklung Gefahren ausfindig zu machen und Schwachstellen zu identifizieren, gibt es das sogenannte Threat-Modeling, auf Deutsch eine Art „Bedrohungssimulation“.
Rückrufaktionen für Produkte sind nicht nur teuer, sondern für die verantwortlichen Unternehmen oft mit einem erheblichen Imageschaden verbunden. Ist eine fehlerhafte Software auf den Markt gelangt, kann der Schaden sogar irreparabel sein: Geraten zum Beispiel durch ein Sicherheitsleck sensible Daten in Umlauf, macht dies auch ein Update des bislang unsicheren Programms nicht rückgängig. Das sogenannte Threat-Modeling soll diese und möglichst alle anderen Gefahren von vornherein ausschließen.
Was Threat-Modeling genau ist und welche Schritte es beinhaltet, erfahren Sie in diesem Artikel.
Was ist Threat-Modeling?
Konkret handelt es sich bei Threat-Modeling um eine Analyse potenzieller Bedrohungen für Anwendungen, Prozesse und Schnittstellen, aber auch für komplette IT-Systeme. Threat-Modeling kommt also vor allem in der Softwareentwicklung zum Einsatz. Für das Konzept gibt es außerdem auch die Bezeichnung Security-Threat-Modeling (STM).
Entwickler:innen können auf diese Weise Einsatzszenarien simulieren und dabei Schwachstellen und Gefahren identifizieren, bevor sie eine Anwendung programmieren. Eine umfangreiche Bedrohungsanalyse mittels Threat-Modeling ist heutzutage gewöhnlich ein zentraler Bestandteil innerhalb des Entwicklungsprozesses einer Software.
Um die Risiken mittels Threat-Modeling zu identifizieren, starten Entwickler:innen einen strukturierten Prozess mittels einer systematischen Analyse. Hilfe leistet dabei die von Microsoft entwickelte sogenannte „STRIDE-Methode“, die wir weiter unten im Einzelnen erläutern.
Die Gründe für Threat-Modeling
Durch Threat-Modeling erstellen Entwickler:innen bereits möglichst früh eine Bedrohungsanalyse in Bezug auf den Einsatz ihrer Anwendung. So können sie beispielsweise falsche Architekturentscheidungen hinsichtlich der Struktur eines Programms oder IT-Systems schon vermeiden, bevor sie die erste Zeile Code dafür schreiben.
Vor allem ist es weitaus teurer, Schwachstellen und Sicherheitsrisiken einer komplexen Anwendungsarchitektur erst im Nachhinein zu beheben. Dann entstehen zusätzliche Kosten für deren Beseitigung, etwa durch umfangreiche Bugfixes und Updates – gegebenenfalls aber auch durch Erstattungsforderungen für geschädigte Personen beziehungsweise Firmen. Zudem kann der Ruf von Entwicklungsabteilungen oder Firmen enormen Schaden nehmen, wenn nachgewiesenermaßen unsichere Produkte auf den Markt gelangen.
Für den Einsatz von Anwendungen in Unternehmen ist besonders der Aspekt interessant, vorab Sicherheitsanforderungen an ein System zu definieren. Damit können Entwickler:innen Analysen in einem spezifischen Umfeld vornehmen.
Wichtige Fragen können in diesem Zusammenhang zum Beispiel lauten:
- Wo speichert die Anwendung die Daten – online oder lokal?
- Wer hat darauf Zugriff – nur Mitarbeiter:innen oder auch externe Personen?
- Wie sensibel sind die verarbeiteten Daten?
- Ist eine Verschlüsselung erforderlich?
- Sollen die Daten auch mobil verfügbar sein?
Threat-Modeling ist allerdings keine ausschließlich freiwillige Angelegenheit, damit Hersteller Kosten minimieren. Softwareentwicklung unterliegt gesetzlichen Pflichten: Anwendungen müssen den Anforderungen an IT-Sicherheit genügen, um in den Verkauf zu gelangen. Diese können unterschiedlich ausfallen: Für Software, die beispielsweise mit kritischen Daten von Kund:innen arbeitet, sind die Anforderungen strenger als etwa für ein Unterhaltungsprogramm.
Der richtige Ablauf mit Hilfe der „STRIDE-Methode“
Ein effektives Threat-Modeling folgt einem strikt schematischen Ablauf in fünf Schritten. Dieser dient dazu, keine wichtigen Dinge innerhalb der Bedrohungsanalyse zu übersehen. In der konkreten Anwendung beinhaltet diese Analyse meist weitere detaillierte und zum Teil aufwendige Maßnahmen. Die grundsätzliche Vorgehensweise beim Threat-Modeling ist jedoch in jedem Falle gleich und läuft wie im folgt ab.
Schritt 1: Wie sieht die Entwicklung aus?
Zunächst skizzieren die Entwickler:innen Sinn und Einsatzzweck ihrer Anwendung. Anschließend geht es um die Frage, wie die Software konkret aussehen soll. Im Rahmen des Threat-Modeling geht es zunächst um die Darstellung der Software-Architektur mithilfe eines technischen Diagramms.
In der Anwendungsentwicklung kommen dabei meistens Datenflussdiagramme zum Einsatz. Mit diesen können die an der Risikoanalyse beteiligten Personen Schnittstellen und Datenflüsse visualisieren. Bedrohungen entstehen meistens dort, wo vorhandene Daten „fließen“, also von einer Instanz zu einer anderen geschickt oder von dieser angefordert werden.
Bei einer typischen Internetanwendung beispielsweise greifen User:innen über das Netz mittels der Applikation auf einen Proxy-Server zu. Dort lagern die Daten in einer Datenbank, die die Anwender:innen verwenden, verändern, abspeichern und gegebenenfalls versenden.
Um bei einem solchen Standardprozess mögliche Schwachstellen aufzudecken, sollten am ersten Schritt sowohl die Architekt:innen der Anwendungsinfrastruktur als auch Entwickler:innen und Systemadministrator:innen beteiligt sein. Erst durch deren unterschiedlichen Perspektiven auf den Aufbau der Anwendung entsteht ein Diagramm, das die benötigten Prozesse korrekt abbildet. Dies ist wichtig für die folgenden Schritte des Threat-Modelings.
Schritt 2: Was kann passieren?
Aufbauend auf dem Diagramm der Anwendung erfolgen im nächsten Schritt mögliche Szenarien, denen die Architektur ausgesetzt sein kann. Mithilfe von Annahmen grenzt dieser Schritt des Threat-Modelings mögliche Bedrohungen ein.
Grundlegende Fragen können zum Beispiel sein: Sind Bedrohungen beim Einsatz bestimmter Gerätekategorien auszuschließen? Sorgen aktuelle Betriebssysteme für den Ausschluss bestimmter Gefahren?
Aufbauend auf grundlegenden Fragen zum Einsatz einer Anwendung können theoretisch unendlich viele Detailprobleme überprüft werden. Beispiele bei einer Webanwendung sind:
- Ist die Identität des Web-Servers der Benutzer:innen korrekt?
- Können Benutzer:innen auch die Infrastruktur hinter dem Frontend sehen?
- Können Dritte auf den Datentransfer zwischen Webanwendung und Proxy-Server zugreifen?
- Verkraftet die Web-Applikation einen hohen Workload, etwa bei einem Online-Shop?
- Sind User:innen nur zu Dingen berechtigt, die für sie vorgesehen sind?
Diese Liste kann je nach Anwendung viele weitere Fragen nach sich ziehen. Um allerdings keine wichtigen Dinge innerhalb dieses Prozesses zu übersehen, haben Entwickler:innen bei Microsoft die sogenannte „STRIDE-Methode“ etabliert. Damit entstehen Kategorien für die oben beispielhaft vorgestellten Fragen, die ein strukturiertes Vorgehen ermöglichen.
Üblicherweise folgt dieses Vorgehen demnach dem folgenden Prozess:
- S = Spoofing (Identitätsverschleierung)
- T = Tampering (Manipulation)
- R = Repudiation (Verleugnung der Urheberschaft)
- I = Information Disclosure (Datenpannen)
- D = Denial of Service (Verweigerung des Dienstes)
- E = Elevation of Privilege (Ausweitung der Rechte)
Jedwede Schnittstelle muss also bei der Überprüfung diesen sechs bei Angriffen üblichen Methoden standhalten. Ist dies nicht der Fall, liegt eine Bedrohung vor.
Schritt 3: Wie sehen Gegenmaßnahmen aus?
Am Ende des STRIDE-Prozesses bleiben üblicherweise eine Reihe von Bedrohungen übrig. Diese lassen sich anhand des Datenfluss-Diagramms meist genau lokal zuordnen – oder können sogar übergeordnete Fragen nach sich ziehen, die die Struktur der gesamten Anwendung betreffen.
Die gefundenen Bedrohungen werden auf die folgenden vier Arten adressiert:
- Mitigation: Dies beinhaltet die Ergreifung von Maßnahmen, die eine Bedrohung abschwächen. Dies kann zum Beispiel einen zusätzlichen Passwortschutz an einer bestimmten Schnittstelle beinhalten oder eine Zwei-Faktor-Authentifizierung für einen bereits bestehenden Kennwortzwang.
- Eliminierung: Potenziell gefährliche Funktionalitäten, wie zum Beispiel Programmierschnittstellen, können durch zusätzliche Authentifizierungen geschützt werden. Eine Überprüfung kann sie aber auch gänzlich in Frage stellen: Benötigt die Anwendung die Funktionalität zwingend? Eine Entfernung oder Deaktivierung der Schnittstelle könnte das Problem unter Umständen leicht beheben und zu keiner (signifikanten) Reduzierung des Funktionsumfangs führen.
- Transfer: Muss eine potenziell gefährliche Funktion genau an dieser Stelle der Anwendung stattfinden? Muss der konkret dafür beauftragte Dienst dies tun? Könnte beispielsweise ein Transfer der Authentifizierung zu einem Active-Directory-Verzeichnisdienst die Schnittstelle schützen?
- Akzeptanz: Auch wenn die Gefahr adressiert ist, können die Entwickler:innen entscheiden, sie dennoch nicht zu beseitigen. Dies kann sein, weil sie diese als sehr gering einschätzen oder die Kosten für eine solche Maßnahme in keiner Relation zum Nutzen stehen.
Schritt 4: Lagebewertung
Wenn die bisherigen Schritte erfolgt sind, liegt gewöhnlich eine Liste mit möglichen Gefahren inklusive passender Gegenmaßnahmen vor. Bevor sie diese umsetzen, priorisieren die Entwickler:innen allerdings die identifizierten Bedrohungen. Dafür definieren sie einen Faktor für einen Bedrohungsrisiko, der sich aus der Wahrscheinlichkeit des Eintritts der Bedrohung multipliziert mit deren potenziellen Auswirkungen ergibt:
Bedrohungswahrscheinlichkeit x potenzielle Auswirkungen
Ein Beispiel: Können Hacker:innen auf einfache Weise über eine administrative Schnittstelle den Account eines Online-Shops kapern, damit Kundendaten auslesen und sogar fingierte Bestellungen tätigen, ergibt dies einen enorm hohen Bedrohungsfaktor.
Entsprechend niedriger fällt der Faktor aus, wenn etwa ein inkompatibles Skript unter bestimmten Voraussetzungen bei einem Bestellvorgang von Kund:innen für einen Grafikfehler sorgen könnte, aber abgesehen davon keinen Schaden anrichtet.
Die konkrete Kategorisierung des Bedrohungsrisikos hängt üblicherweise von der Security-Policy des jeweiligen Unternehmens ab, fällt aber meist grob in vier Kategorien: niedrig, mittel, hoch, sehr hoch. Microsoft bietet mit dem Programm Bug Bar ein Analyse-Tool, um das Risiko richtig einzuschätzen. Eine andere Methode ist der Industriestandard Common Vulnerability Scoring System (CVSS) von Unternehmen wie Cisco, CERT, IBM und weiteren.
Wichtig ist bei diesem Schritt des Threat-Modelings vor allem, die Reihenfolge der Gegenmaßnahmen auf Basis der Priorisierung und Kategorisierung festzulegen und entsprechend aufeinander abgestimmt durchzuführen. Dieses Vorgehen sollte dokumentiert werden, um es später nachvollziehen zu können.
Schritt 5: Evaluation
Im abschließenden Schritt erfolgt eine Qualitätsbewertung der Analyse, sozusagen die Evaluation der vorangegangenen Schritte. Dazu gehören:
- Überprüfung der Architektur: Erneut überprüfen die Entwickler:innen, ob die im Datenfluss-Diagramm entwickelte Architektur der Anwendung noch präzise ist. Außer den Gegenmaßnahmen können beispielsweise andere Faktoren die Struktur geändert haben, wie etwa Use-Cases oder Kundenwünsche. In diesen Fällen kommt es zu einer Wiederholung der vorherigen Schritte.
- Überprüfung der Bedrohungen: Durch Änderungen der Architektur können neue Bedrohungen entstanden sein. Die am Threat-Modeling beteiligten Personen sollten sowohl diese als auch die tatsächliche Beseitigung bereits identifizierter Bedrohungen überprüfen.
- Tests: Schließlich müssen die Entwickler:innen sämtliche Maßnahmen überprüfen und ausführlichen Tests unterziehen. Dies kann im Rahmen der normalen Anwendungstests des Entwicklers erfolgen, aber auch durch zusätzliche Use-Cases und Stresstests.
Welche Vorteile bietet Threat-Modeling in der Praxis?
Threat-Modeling in der Anwendungsentwicklung bietet Ihnen als Unternehmen vor allem eines: Die Gewissheit, dass die von Ihnen verwendete Software nahezu keine augenfälligen Gefahrenpotenziale für Ihren Geschäftsprozess und die Sicherheit der von Ihnen verarbeiteten Daten aufweist. Angreifende haben es damit wesentlicher schwerer, Schwachstellen in Ihrer betrieblichen Software zu identifizieren und zu Ihrem Schaden auszunutzen.
Die „Reparatur“ einer unausgereiften und unsicheren Anwendung im laufenden Betrieb wäre stattdessen sowohl für Sie als auch für den Hersteller der Anwendung mit enormen Kosten, Aufwand und höchstwahrscheinlich Ärger verbunden.
Je besser Entwickler: innen also ihr Programm vor der Markteinführung im Rahmen des Threat-Modelings auf Bedrohungen hin überprüft haben, desto unnötiger sind zudem umfangreiche Sicherheitsupdates. Diese können nicht nur die täglichen Arbeitsabläufe stören, sondern ihrerseits zu neuen Instabilitäten und vor allem Inkompatibilitäten im Zusammenspiel mit anderen Anwendungen führen.
Sie erwerben auf diese Weise neben der reinen Funktionalität des Programms vor allem Verlässlichkeit. Sie können sich darauf verlassen, dass die Software je nach Einsatzbereich Ihre Geschäftsabläufe gewinnbringend unterstützt. Somit können Sie sich damit befassen, die Funktionen für den Einsatz in Ihrem Unternehmen zu optimieren; anstatt sich um die Sicherheit der Prozesse und Daten sorgen zu müssen.
Im Übrigen beinhaltet Threat-Modeling auch die Überprüfung standardisierter Updates und Programmerweiterungen – spätere Softwareaktualisierungen sollen ja vor allem deren bessere Funktionalität und größere Sicherheit gewährleisten.
Threat-Modeling: Das Wichtigste in Kürze
- Threat-Modeling ist eine Bedrohungsanalyse von Anwendungen, Schnittstellen und IT-Systemen schon vor der Erstellung der ersten Codezeilen.
- Auf diese Weise vermeiden Entwickler: innen falsche Entscheidungen hinsichtlich der Struktur und Sicherheit eines Programms oder IT-Systems.
- Die meisten Gefahrenpotenziale sind also beseitigt, wenn Sie die Anwendung für den Einsatz in Ihrem Unternehmen erwerben.
- Das Threat-Modeling folgt einem in Grundzügen standardisierten Verfahren, das aus fünf Schritten besteht. Diese reichen von der Identifizierung und Adressierung potenzieller Bedrohungen über deren Beseitigung bis hin zu einer Evaluation des gesamten Analyseprozesses.
- Sorgfältiges Threat-Modeling sorgt dafür, dass Sie sich beim Einsatz von Anwendungen in Ihrem Unternehmen auf deren Sicherheit verlassen und auf die Kerntätigkeiten Ihres Geschäftsprozesses konzentrieren können.
Quelle:
https://www.vodafone.de/business/featured/digitales-business/digitaler-arbeitsplatz/threat-modeling-wie-sie-it-risiken-bekaempfen-bevor-sie-akut-werden/