Risikomanagement mit STRIDE und DREAD (IT-Sicherheit)

Sicherheit ist keine Funktion, die nachträglich in ein Softwareprodukt eingebaut werden kann. Durch die enge Vernetzung sind Computer heute ein leichtes Angriffsziel und die Verbreitungsgeschwindigkeit von Schädlingen hat enorm zugenommen. Auf der anderen Seite ist es nahezu unmöglich, 100% sichere Software zu schreiben. Die Kunst besteht darin, Angriffsszenarien zu kennen und deren Bedrohungspotential in Bezug auf die eigenen Anwendungen einzuschätzen. Nur dann können im Falle eines Angriffs wirksame Maßnahmen ergriffen werden. Kurzum: Sicherheit ist ein Prozess!

Oder anders ausgedrückt: Es gewinnt nicht derjenige, der Bedrohungen am besten verhindern kann, sondern derjenige, der am besten mit den Risiken umgeht.

Veränderte Entwicklung

Wenden wir uns zunächst der Frage zu, warum Anschläge heute eine solche Bedrohung darstellen. Die Welt hat sich verändert – auch im Bereich der Sicherheit. Im Zeitalter ohne Internet lief alles in einem geschlossenen lokalen System ab. Heute holen sich Programme Updates dynamisch aus dem Web oder werden komplett über das Internet installiert – die Vision vom „Internet aus der Steckdose“ ist Realität geworden. Web-Applikationen und Web-Services erhöhen das Sicherheitsrisiko zusätzlich. Damit ändern sich die Rahmenbedingungen grundlegend:

• Sicherheitsbedrohungen sind ständig präsent, da man „always online“ ist. Dadurch sind völlig neue Angriffsszenarien entstanden, deren Auswirkungen beim Design von Anwendungen (noch) nicht berücksichtigt wurden. Prominentestes Beispiel ist der sogenannte Buffer Overrun, mit dem fremder Code in ein System eingeschleust und ausgeführt werden kann. In einer geschlossenen Umgebung ein beherrschbares Problem, in einer offenen Umgebung nicht mehr beherrschbar.
• Das Internet ist ein ideales Medium für die Verbreitung von Angriffswerkzeugen. Nur der allererste Angreifer muss technisch versiert sein, alle anderen können seine Software z. B. per Download nutzen. Sobald der erste Angreifer seine Werkzeuge zum Download freigegeben hat, sind diese praktisch nicht mehr kontrollierbar. Mit anderen Worten: Computerbasierte Angriffe bedeuten heute nichts anderes, als dass die Täter keine technischen Kenntnisse mehr haben müssen, um erfolgreich zu sein. Man denke nur an die rasante Verbreitung von Schadskripten.
• Virenscanner helfen in absehbarer Zeit nicht mehr weiter, da die Abstände zwischen dem Auftreten einer Sicherheitslücke und einem Angriff, der diese Lücke ausnutzt, immer kürzer werden.
• Die Vernetzung hat zu immer komplexeren Systemen geführt. Eine einzelne Person ist nicht mehr in der Lage, alle Interna zu kennen. Das Wissen, wie Systeme miteinander interagieren, wird zum entscheidenden Faktor.
• Man kann sich nur gegen Bedrohungen schützen, die man bereits kennt. Da es aber unmöglich ist, 100% sichere und fehlerfreie Software zu entwickeln, bleibt nur eine Möglichkeit: Sie müssen die Anwendungsfälle (Use Cases) kennen! Nur dann können Sie systematisch vorgehen und Ihre Anwendung auf Schwachstellen untersuchen.

Zusammenfassend kann gesagt werden, dass die Prozesssicht enorm an Bedeutung gewinnt. Nur wenn man die Use Cases kennt, kann man die Schwachstellen analysieren. Es ist nicht damit getan, Use-Cases zu erfassen. Ein Beispiel: Das Abhören der Kommunikation zweier Partner kann durch Verschlüsselung verhindert werden. Das Problem dabei: Ein Angreifer überwacht die Kommunikation nicht passiv!

Er bricht in eine Firewall ein, er manipuliert ein digitales Netzwerk, er stiehlt mit fremden Zugangsdaten Geld von irgendwelchen Konten. Aber es geht nicht um „alles oder nichts“. Wenn man eine Kommunikation schützen will, funktioniert das so: Entweder ich kann mithören oder nicht. Ein Angreifer hingegen bricht vielleicht in ein Netzwerk ein und stiehlt ein bisschen Geld, aber eben nicht alles. Oder er bricht in ein Netzwerk ein und schaut sich vielleicht fünf Minuten um, bevor er entdeckt wird.

Kurz: Angriffe funktionieren fast nie nach dem Prinzip „alles oder nichts“. Deshalb reicht es nicht aus, nur Anwendungsfälle und Maßnahmen zu kennen. Oder um auf das Beispiel zurückzukommen: Die interessante Frage ist: Wenn es einem Angreifer gelungen ist, in ein Netzwerk einzudringen – wie lange darf er unentdeckt bleiben, bevor er Schaden anrichten kann? Fünf Minuten oder länger? Ist es vielleicht sogar egal, weil er keinen Zugriff auf wichtige Daten hat?

Kurz: Sicherheit ist Risikomanagement! Nur wer die Risiken eines Angriffs für seinen speziellen Anwendungsfall kennt, hat eine Chance auf erfolgreiche Abwehr.

Ein Prozess muss her – STRIDE und DREAD!

Zu dieser Erkenntnis kam Microsoft bei der Entwicklung des Betriebssystems Windows 2000. Im Zuge dieses Projektes wurde festgestellt, dass gravierende Sicherheitslücken in Bezug auf Internetszenarien bestehen. Als Hauptproblem hat sich herausgestellt, dass das Bewusstsein für Sicherheit erst noch geschaffen werden muss: Auch hier ein Beispiel: Das World Trade Center wurde unter höchsten Sicherheitsvorkehrungen gebaut. Niemand hatte jedoch damit gerechnet, dass es mit vollgetankten Passagierflugzeugen angegriffen werden könnte. Dieses Bedrohungsszenario schien zu abwegig.

Und genau deshalb wurde die Entwicklung von Windows für einen Monat gestoppt. Um die Entwickler zu schulen, um das Sicherheitsbewusstsein zu schärfen und um die Aufmerksamkeit für Sicherheitsprobleme zu erhöhen.

Das erhöht zwar langfristig die Qualität des produzierten Codes, geht aber zunächst mit einer erhöhten Anzahl von Bugfixes einher. Die Folge: die eingangs erwähnte „Patch-Welle“ als Konsequenz der neuen Denkweise in der Praxis.

Weit weniger öffentlichkeitswirksam wurde parallel zu dieser Vorgehensweise ein Prozess zur Identifikation von Sicherheitslücken und deren Schadensrisiko implementiert, der für jedes Produktteam innerhalb von Microsoft verbindlich ist. Er ermöglicht es allen Beteiligten, Sicherheitslücken nicht nur zu dokumentieren, sondern auch darzustellen, ob und wie hoch ihr Gefährdungspotenzial ist und welche Gegenmaßnahmen zu ergreifen sind. Die verwendeten Methoden tragen die Bezeichnungen STRIDE und DREAD.

STRIDE

STRIDE ist eine Abkürzung für folgende Begriffe:

• Spoofing Identity
• Tampering with Data
• Repudiation
• Information Disclosure
• Denial of Service
• Elevation of Privilege

Zum besseren Verständnis sollen diese Begriffe nun etwas näher erläutert werden.

Spoofing Identity
Ein Angreifer täuscht eine falsche Identität vor. Es gibt zwei Varianten:

• Vortäuschen einer falschen Client Identität
  • Zugriff auf einen Server als legitimer Benutzer
  • Zugriff auf sensitive Daten
• Vortäuschen einer falschen Server Identität
  • Einem Client einen legitimen Server vortäuschen
  • Vertrauliche Daten von einem Client erfragen

Gegenmaßnahmen: Starke Authentisierung, z. B. durch Kryptographie und Multi-Faktor-Authentisierung

Tampering with Data
Ein Angreifer manipuliert Daten. Auch hier gibt es im Wesentlichen zwei Formen:

• Manipulieren von persistenten Daten
  • Password-Datenbanken
  • Modifizieren von Preisen in einem Online-Shop
  • Modifizieren von Audit-Logs, um Spuren zu verwischen
• Manipulieren von Netzwerk-Paketen

Gegenmaßnahmen: Hash-Codes, digitale Signaturen, Verschlüsselung, Verwendung geeigneter Netzwerkprotokolle

Repudiation
Ein Angreifer führt eine Handlung aus, die das Opfer nicht beweisen kann. Ein Angreifer könnte behaupten:

• Eine Datei nicht gelöscht zu haben
• Eine Bestellung nicht getätigt zu haben
• Ware nicht entgegengenommen zu haben

Gegenmaßnahmen: Prüfprotokolle, Empfangsbestätigungen, digitale Signaturen, Zeitstempel

Information Disclosure
Ein Angreifer sieht Daten, die er nicht sehen sollte. Dazu gehören

• Lokale Dateien
• Daten, die zwischen Rechnern übertragen werden
• Unautorisierte Datenbank-Zugriffe
• Informationen über die Infrastruktur
• Sogar Fehlermeldungen sind vertrauliche Informationen

Gegenmaßnahmen: Starke Authentifizierung, Zugangskontrolle, Verschlüsselung, sensibler Umgang mit Informationen

Denial of Service (DoS)
Ein Angreifer stört die Verfügbarkeit einer Anwendung. Dies kann zum Beispiel geschehen durch:

• Distributed Denial of Service Attacks (DDoS)
• Ausnutzen von Race conditions

Allgemeines Ziel ist der Verbrauch von Bandbreite, Speicher und CPU-Zyklen.

Gegenmaßnahmen: Verfügbarkeit und Zuverlässigkeit erhöhen

Elevation of Privileges
Ein Angreifer findet einen Weg, seine Berechtigungen zu erhöhen.

• Administrative Rechte sind das End-Ziel
• “Buffer Overflow” ist das klassische Beispiel
• SQL Injection ist insbesondere bei Webanwendungen ein bewährtes Mittel

Gegenmaßnahmen: Robuster Code, Least Privilege, Eingabevalidierung

Anhand dieser Kriterien wird jede Anwendung auf Sicherheitslücken untersucht und die entsprechenden Maßnahmen dokumentiert.

DREAD

In einem zweiten Schritt werden die möglichen Gefährdungen mit Hilfe von DREAD bewertet und priorisiert. Konkret bedeutet dies, dass bei der Risikobewertung folgende Fragen berücksichtigt werden

• Damage (Schadens-) potenzial: Wie hoch ist der Schaden, wenn die Sicherheitslücke ausgenutzt wird?
• Reproducibility (Reproduzierbarkeit): Wie leicht lässt sich der Angriff reproduzieren?
• Exploitability (Ausnutzbarkeit): Wie einfach ist ein Angriff?
• Affected (betroffene) Benutzer: Wie viele Nutzer könnten ungefähr betroffen sein (in Prozent)?
• Discoverability (Auffindbarkeit): Wie leicht ist die Sicherheitslücke zu finden?

Die Bewertung sollte einem einfachen System folgen. Ein einfaches Bewertungsschema wie hoch (1), mittel (2) und gering (3) ist in der Regel ausreichend. Nachdem Sie sich die oben genannten Fragen gestellt haben, addieren Sie die Werte (1 bis 3) für die Gefährdung. Das Ergebnis kann zwischen 5 und 15 liegen. Das Risiko von Bedrohungen mit einem Gesamtwert von 12 bis 15 ist als hoch einzustufen, 8 bis 11 steht für ein mittleres Risiko und ein Wert von 5 bis 7 für ein geringes Risiko. Tabelle 1 zeigt zwei Beispiele.

Tabelle 1: DREAD-Bewertung

Die Anwendung dieser Verfahren führt zu einem klaren und für alle Beteiligten nachvollziehbaren Prozess der Identifizierung und Bewertung von Sicherheitslücken hinsichtlich des Risikos im laufenden Projekt und ermöglicht so eine systematische Vorgehensweise bei der Reaktion auf Angriffe bereits im Vorfeld. Mit anderen Worten: Sicherheit muss bereits in der Entwurfsphase eines Softwaresystems integraler Bestandteil sein. Dies bedeutet, dass:

• Assets und Sicherheits-Ziele formuliert werden
• Eine Risiko/Bedrohungs-Analyse durchgeführt wird
• Bedrohungen priorisiert werden
• Gegenmaßnahmen implementiert werden
• Überwachungs- und Reaktionsmaßnahmen entworfen, implementiert und getestet werden.

Dies ist jedoch keine statische Angelegenheit. Bei jeder Änderung der Software müssen diese Strategien neu überdacht werden..

Die Umsetzung dieses Prozesses führte bei Microsoft zunächst dazu, dass immer mehr Sicherheitslücken entdeckt und behoben wurden. Die Folge war zunächst eine erhöhte Anzahl von Patches.