Bedrohungsmodellierung

Das Bild von Microsoft auf der Threat Modeling Seite kennt wohl fast jeder, der sich mit Bedrohungsmodellierung (englisch Threat Modeling) auseinandersetzt.

© Microsoft Corporation

Und eigentlich ist es auch wirklich einfach. Fünf Schritte schlägt Microsoft vor:

• Definiere Sicherheitsanforderungen (Defining security requirements)
• Modelliere Deine Anwendung (Creating an application diagram)
• Identifiziere die Bedrohungen (Identifying threats)
• Mitigiere die Bedrohungen (Mitigating threats)
• Validiere dass die Bedrohungen mitigiert sind (Validating that threats have been mitigated)

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.

Definiere Sicherheitsanforderungen

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:

• Natürlich beeinflusst die Definition oder Interpretation der Risken auch die Maßnahmen. Wenn Sie auch Kommunikationsmetadaten bei „Information Disclosure“ einbeziehen, dann reicht Verschlüsselung nicht aus, dann brauchen Sie vielleicht ein zusätzliches virtuelles privates Netzwerk oder auch etwas wie Tor. Oder Sie vertrauen an der Stelle auf das Fernmeldegeheimnis, ab 01.12.2021 in Deutschland geregelt in §3 des Gesetz zur Regelung des Datenschutzes und des Schutzes der Privatsphäre in der Telekommunikation und bei Telemedien (TTDSG).
• Authentifizierung und Verschlüsselung gehören immer zusammen. Authentifizierung ohne Verschlüsselung → der Angreifer kann mitlesen oder die Authentifizierung umgehen. Verschlüsselung ohne Authentifizierung des Kommunikationspartners → ich vertraue meine Informationen einem Unbekannten an. Also immer beides zusammen.
• Ich bin kein Freund von Multi-Faktor-Authentifizierung (MFA) und bevorzuge es, Anwender auszubilden. Ob Sie MFA wollen oder sogar müssen ist eher eine Business- oder Compliance-Entscheidung. Wenn Sie MFA brauchen, dann folgen Sie bitte der Payment Card Industry Data Security Standard Empfehlung Multi-Factor Authentication — Sie werden überrascht sein, wie oft Multi-Step- statt Multi-Faktor-Authentifizierung verwendet wird.
• Verschlüsselung vs. Digitale Signaturen: Verwendet man Transport Layer Security (TLS) mit aktuellen Chiffren für die Kommunikation, dann verwendet man eine sogenannte 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.
• Eine digitale Signatur – zusätzliche zur Verschlüsselung – hat nur dann einen Mehrwert, wenn persönliche Zertifikate verwendet werden und die auch zusammen mit den signierten Nutzdaten aufbewahrt werden – beides eher eine Seltenheit. Anders bei offiziellen Dokumenten, da kann man sehr wohl eine Vertrauenskette etablieren und damit eine online- oder auch offline-Prüfung realisieren — Schlagzeilen wie Digitaler Führerschein hatte keinen Schutz vor Identitätsdiebstahl sind vermeidbar.
• Authentifizierung, Verschlüsselung, und digitale Signaturen sollten Sie möglichst nicht selbst implementieren — da gibt es einfach zu viele Fallstricke.
• Filter oder Quota: das realisiert man typischerweise systemübergreifend über Protokollierung mit Anschluss an ein Security Information and Event Management (SIEM) oder Intrusion Detection System (IDS).
• Das Schutzziel Verfügbarkeit kommt in STRIDE – abgesehen von Schutz vor Denial-Of-Service – zu kurz — aber nachrüsten können Sie das auch nicht nebenbei.
• Weitere Details z.B. in Uncover Security Design Flaws Using The STRIDE Approach.

Modelliere Deine Anwendung

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.

Identifiziere die Bedrohungen

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.

Mitigiere die Bedrohungen

Wird eine Sicherheitsanforderung nicht erfüllt kommt klassisches Risikomanagement ins Spiel. Die Handlungsoptionen sind typischerweise:

• Elimination — man bessert nach und erfüllt die Anforderung doch
• Mitigation — durch eine Maßnahme an anderer Stelle
• Transfer — eine Versicherung abschließen oder den Verantwortlichen (Kunde) informieren
• Akzeptieren — Unsicherheit in Kauf nehmen

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.

Validiere dass die Bedrohungen mitigiert sind

Zusammenfassung

• Sicherheitsanforderungen — überschaubar, vollständig, präzise (kein Raten ob erfüllt oder nicht). Risikobetrachtung nur bei nicht-Erfüllung oder neuen Angriffsszenarien
• Anwendungsmodell — Bewährt: FMC Blockdiagramme. Notfalls: Rechtecke, C4, UML Component/Deployment-Diagramme
• Qualitätsmanagement — Teststrategie und Ausnahmeprozess