Das Bild von Microsoft auf der Threat Modeling Seite kennt wohl fast jeder, der sich mit Bedrohungsmodellierung (englisch Threat Modeling) auseinandersetzt.
Und eigentlich ist es auch wirklich einfach. Fünf Schritte schlägt Microsoft vor:
Es gibt unzählige Varianten von diesem Vorgehen im Internet, die sich meist auf diese Schritte abbilden lassen. Ich werde im Folgenden auch die Parallelen zum OWASP Threat-Modeling-Cheat-Sheet aufzeigen.
Schnell fertig: Meine Sicherheitsanforderungen. Natürlich dürfen Sie auch andere nehmen oder ergänzen. Bei OWASP finden Sie hier Define Business Objectives
und darunter identify security and compliance requirements
.
Wichtig ist, dass die Sicherheitsanforderungen die Schutzziele und Risiken adressieren. Wenn man sich hier auch an Microsoft STRIDE orientiert, kommt man zu einer Zuordnung wie z.B. auf Threat Modeling 101: Ten Common Traps Not to Fall Into oder Threats and Security Properties:
Risiko | Schutzziel oder Gewünschte Eigenschaft | Vorgeschlagene Maßnahme im Threat Modeling 101 | Sicherheitsanforderungen (mein Vorschlag) |
---|---|---|---|
Spoofing – Identitätsverschleierung | Authenticity – Authentifizierung | Passwörter, Multi-Faktor-Authentifizierung, Digitale Signaturen | Authentifizierung (Single-Sign-On, Kerberos, oder X.509), Session Management |
Tampering – Manipulation | Integrity – Integrität | Berechtigungen, Digitale Signaturen | Berechtigungen, Verschlüsselung |
Repudiation – Verleugnung | Non Repudiation – Nicht-Abstreitbarkeit | Protokollierung, Digitale Signaturen | Protokollierung, Verschlüsselung |
Information Disclosure – Datenpanne | Confidentiality – Vertraulichkeit | Verschlüsselung, Berechtigungen | Verschlüsselung, Berechtigungen |
Denial-Of-Service – Verweigerung des Dienstes | Authentication – Authentifizierung Availability – Verfügbarkeit | Berechtigungen, Filtering, Quota | Authentifizierung, Berechtigungen, Protokollierung (ggfs. mit Filter oder Quota), Eingabevalidierung |
Elevation of Privileges – Rechteausweitung | Authorization – Berechtigung | Berechtigungen, Eingabevalidierung und Ausgabeaufbereitung | Berechtigungen, Eingabevalidierung und Ausgabeaufbereitung |
Multi-Factor Authentication— Sie werden überrascht sein, wie oft Multi-Step- statt Multi-Faktor-Authentifizierung verwendet wird.
authentifizierte Verschlüsselung, d.h. eine Manipulation des Datenstroms wird erkannt. Bei Festplattenverschlüsselung wird leider nicht automatisch kryptographisch authentifiziert, aber das ist aufgrund der Verwendung von Prüfsummen und fehlerkorrigierenden Codes auf Festplatten oder im Speichersystem meist akzeptabel.
Digitaler Führerschein hatte keinen Schutz vor Identitätsdiebstahlsind vermeidbar.
Den Unterschied zwischen Modell und Diagramm brauchen wir nicht vertiefen. Genaugenommen wollen wir ein Diagramm, also ein Bild. Wie heißt es so schön, ein Bild sagt mehr als tausend Worte. Also z.B. das folgende für eine typische Webanwendung:
Dieses Diagramm ist ein Blockdiagramm aus Fundamental Modeling Concepts. Da zeigt sich halt, dass ich lange Jahre bei SAP gearbeitet habe. Sie können aber auch Datenflussdiagramme (dann sind Rechtecke und Ovale gegenüber Blockdiagrammen vertauscht), C4, UML Komponenten- oder Deploymentdiagramme mit geeigneter Beschriftung der Pfeile, oder einfach Rechtecke verwenden.
Wichtig ist, dass alle Kommunikationsbeziehungen oder Speicher enthalten sind. Man kann die einzelnen Agenten auch in kleinere Einheiten zerlegen, insbesondere sollte man das tun, wenn sie als verteiltes System realisiert sind. Wenn Sie fremde Komponenten wie z.B. Open-Source-Pakete verwenden, dann sollten sie sich über die vom Anbieter verfolgten Sicherheitsanforderungen informieren und mit Ihren vergleichen. Zusätzlich müssen Sie darauf vorbereitet sein, neue Versionen zu verbauen. Achten Sie auch darauf, ob die Knoten Ihrer Webanwendung oder des Anwendungsservers auf dem sie läuft eine Cluster-Kommunikation hat (im Bild rechts) – diese Cluster-Kommunikation hat in den letzten Jahren immer mal wieder den maximalen Wert auf der CVSS-Skala erreicht – weil sie so gerne vergessen wird.
Bei OWASP sind hier die Schritte Identify application design
, Create design documents
, und Decompose and Model the System
relevant. Leider wird dort nicht klar getrennt zwischen diesem und dem nächsten Schritt.
Jetzt ersetzen wir gedanklich den normalen Anwender durch einen Angreifer und prüfen ob alle Sicherheitsanforderungen oben richtig umgesetzt wurden. Die Bedrohung oder das Risiko ergibt sich, in dem man bei jeder nicht erfüllten Anforderung in der Tabelle oben nachsieht.
Eine ganz wichtige Frage dabei ist, ob die verwendeten Identitäten an der Anwenderschnittstelle mit denen bei der Nutzung anderer Dienste übereinstimmt — wenn nicht, muss die Anwendung alle Prüfungen selbst erledigen und darf nicht auf Unterstützung durch das Betriebssystem oder anderer Dienste vertrauen.
Manche Bedrohungen oder Verletzungen der Anforderungen müssen Sie nicht unbedingt selbst suchen – Tools für Static-Application-Security-Testing (SAST) (ein automatisierter Code-Review), automatische Tests (aka DAST) , Fuzzy Testing, Pen-Test-Tools, etc. können Ihnen helfen. Je genauer Sie Ihre Vergangenheitssünden kennen, desto besser kann ein dezidiertes Tool helfen – ggfs. auch selbst gebaut z.B. als Roslyn Analyzer, während Sie bei eingekauften Tools prüfen müssen, ob Sie nicht mehr false-Positives als reale Probleme finden. Vorteil ist aber immer, dass Sie das automatisieren können – siehe unten Validiere dass die Bedrohungen mitigiert sind.
Ressourcen spielen eigentlich nur für Denial-Of-Service eine wichtige Rolle. Wenn Sie einem Angreifer erlauben, beliebig viele oder beliebig große Anfragen zu senden, dann kann er Ihre Anwendung lahmlegen. Also grundsätzlich Eingabevalidierung und Protokollierung, und je nach Risiko auch Filter oder Quota. Und große Dokumente, insbesondere auch XMLs, sollten Sie inkrementell verarbeiten statt versuchen, sie vollständig in den Hauptspeicher zu laden – die werden ja auch in kleinen Häppchen übertragen.
Eine Einschränkung muss hier auch gemacht werden: bei dieser Prüfung kann festgestellt werden, ob beispielsweise das Berechtigungskonzept implementiert wurde, nicht aber ob das Berechtigungskonzept adäquat für den Prozess ist. Auch müssen Sie die Frage aufwerfen, welche Berechtigungen Administratoren in jeder Komponente haben und wie die kontrolliert werden. Idealerweise haben Administratoren nur anlassbezogen Berechtigungen, und alles was Administratoren tun, sollte in einem Protokoll auftauchen und auditiert werden.
Wenn die Anwendung Daten außerhalb der Vertrauenszone speichern muss – auf dem Client oder einem nicht vertrauenswürdigen Dienst – dann müssen Sie ggfs. über zusätzliche Verschlüsselung oder Signaturen nachdenken, um auch dort Bedrohungen auszuschließen. Für den Client leistet das oft die Authentifizierung und das Session-Management – aber davon sollten Sie sich selbst überzeugen. Verschlüsselung ist auch eine Möglichkeit, den Zugriff von Administratoren zu begrenzen. Im Extremfall verwenden Sie ein Konzept wie bei Tresorit, in dem das Berechtigungskonzept auf Schlüsselmanagement abgebildet ist. Das gilt aber nur für Dienste die remote verwendet werden, der Plattform unter der Anwendung – der müssen Sie vertrauen können. Löcher der Plattform können Sie nicht in der Anwendung korrigieren. Was auch immer Sie beschließen – holen Sie sich Hilfe bei jemandem der sich damit auskennt.
Bei OWASP dürfen sie nochmal über Decompose and Model the System
und anschließend über ”Identify Threat Agents
gehen, immer mit dem Wissen, dass Bedrohung und nicht-erfüllte Anforderung in einem Zusammenhang stehen. Ob Sie wirklich Attack-Wälder aufstellen wollen und ”Write your Threat traceability matrix
bleibt Ihnen überlassen. Investieren Sie doch im nächsten Schritt Energie auf die Elimination der Bedrohung.
Wird eine Sicherheitsanforderung nicht erfüllt kommt klassisches Risikomanagement ins Spiel. Die Handlungsoptionen sind typischerweise:
Tatsächlich hilft Bedrohungsmodellierung in vielen Fällen das Problembewusstsein zu verbessern und führt oft dazu, dass die Probleme eliminiert oder zumindest mitigiert werden anstelle dass sie unbewusst akzeptiert werden. Leider ist Mitigation nicht immer eine gute Strategie. Konsequente Verschlüsselung durch Zutrittskontrolle oder Netzwerksegmentierung zu ersetzen — wie das der Grundschutz durchaus erlaubt — ist keine wirklich sichere Lösung. Jetzt brauchen Sie vielleicht auch den Rat eines Sicherheitsexperten.
Bei OWASP sind Sie bei Determine countermeasures and mitigation
angelangt.
Periodically retest risk, dann sind dabei automatische Tests sinnvoll sowie gelegentlich mal exploratives Testen – auch Penetrationstests gibt es in beiden Varianten. Mein mentales Bild dazu ist das folgende:
Veröffentlicht am 10.10.2021, zuletzt geändert am 15.12.2021.
© 2021 Joachim Lindenberg. Diese Seite spiegelt meine persönliche Meinung wieder. Sie stellt keine Rechtsberatung dar. Fragen Sie doch einen Anwalt der sich damit auskennt.