Der SDL am Beispiel eines Gästebuchs, Teil 3
Die Demonstration von Microsofts SDL am Beispiel eines PHP-Gästebuchs geht in die dritte Runde. Nachdem Sie sich in der ersten Phase über die nötigen Grundlagen wie mögliche Schwachstellen und Angriffe informiert und in der zweiten Phase die nötigen Anforderungen an die Webanwendung festgelegt haben kommen sie nun zur Phase 3, Design. Und in der können Sie nun ein Bedrohungsmodell für die Anwendung erstellen.
Phase 3: Design - Bedrohungsmodell erstellen
Um alle möglichen Bedrohungen für ein Programm zu erfassen kann z.B. die sog. "Entwurfsgesteuerte Bedrohungsmodellierung" verwendet werden. Die besteht aus fünf Schritten:
- "Vision" - Welche Sicherheitsanforderungen muss das Programm in der geplanten Einsatzumgebung erfüllen?
- "Model" - Erstellen Sie ein Diagramm ihres Programms mit allen
Datenflüssen
Üblich ist die Verwendung von Kreisen für Code, Kästen für externe Dinge wie Personen, Server usw., Zylinder (oder einfach parallele Linien) für Datenspeicher wie z.B. Datenbanken etc. und Pfeile für Datenflüsse.
Zeichnen Sie Vertrauensgrenzen zwischen den Komponenten ein. Vertrauensgrenzen befinden sich überall da, wo mehr als eine Person oder ein Prozess auf ein Objekt, z.B. eine Datei oder einen Prozess, zugreifen kann. Kreuzen Vertrauensgrenzen etwas anderes als Datenflüsse, muss dies in zwei logische Komponenten aufgeteilt werden. Gegebenenfalls muss das Diagramm verfeinert werden. - "Identify Threats" - Ermitteln Sie für jeden Datenfluss, der eine Vertrauensgrenze überschreitet, mögliche Bedrohungen
- "Mitigate" - Minimieren Sie die erkannten Bedrohungen
Prüfen Sie, ob sich die möglichen Bedrohungen bündeln lassen. Sind die Bedrohungen über alle oder zumindest viele Komponenten verstreut, müssen Sie sie an vielen Stellen abwehren. Können Sie sie in einer oder wenigen Komponenten bündeln, müssen Sie nur diese schützen.Verwenden sie, soweit möglich, Standard-Gegenmaßnahmen. Entwickeln Sie neue Gegenmaßnahmen nur wenn das nötig ist. Prüfen Sie, ob die verbleibenden Risiken akzeptiert werden können. - "Validate" - Prüfen Sie das Ergebnis
Prüfen Sie, ob die Diagramme korrekt sind. Prüfen Sie, ob für jeden Datenfluss, der eine Vertrauensgrenze überschreitet, und für jedes damit verbundene Element alle Bedrohungen ermittelt wurden. Prüfen Sie, ob für jede Bedrohung Gegenmaßnahmen ergriffen wurden oder das Risiko akzeptabel ist. Gegebenenfalls geht es dann wieder beim zweiten Punkt los.
Fangen wir mit dem ersten Punkt an: Welche Sicherheitsanforderungen muss das Programm in der geplanten Einsatzumgebung erfüllen?
Hier gilt zuerst mal eine Abwandlung des altbekannten Grundsatzes "Traue nie dem Client": Bösartige Eingaben dürfen nicht gespeichert oder anderweitig verarbeitet werden. Außerdem muss sicher gestellt werden, dass nur die jeweils dazu befugten Benutzer Zugriff auf die Informationen erhalten. Und natürlich müssen die Datenschutzvorschriften am Einsatzort eingehalten werden.
Damit kommen wir zum zweiten Schritt, der Modellierung. Ein mögliches, sehr einfaches Ergebnis sehen Sie in Abb. 1.
Abb. 1: Das Ergebnis der Bedrohungsmodellierung
Mögliche Bedrohungen / Angriffe ermitteln
Als nächstes müssen alle möglichen Bedrohungen, d.h. Angriffe, ermittelt werden. Dazu kann z.B. das sog. STRIDE-Modell verwendet werden.
STRIDE ist ein von Microsoft entwickeltes System zur Einordnung von Bedrohungen in sechs Kategorien. Der Name "STRIDE" wurde aus den Anfangsbuchstaben der Kategorien gebildet:
- Spoofing (Angriffe auf die Authentifizierung, z.B. Vortäuschen einer falschen Benutzeridentität)
- Tampering (Angriffe auf die Integrität, d.h. die unbefugte Manipulation von Daten)
- Repudiation (Angriffe auf die Nicht-Abstreitbarkeit (Non-repudiation), z.B. Abstreiten der Urheberschaft)
- Information Disclosure (Angriffe auf die Vertraulichkeit, z.B. Preisgabe bzw. Ausspähen von Daten)
- Denial of Service (Angriffe auf die Verfügbarkeit)
- Elevation of Privilege (Angriffe auf die Autorisierung, d.h. Privilegieneskalation, das Erlangen höherer Benutzerrechte)
Für jeden Datenfluss, der eine Vertrauensgrenze überschreitet, und für jedes damit verbundene Element des Diagramms müssen alle sechs Kategorien des STRIDE-Modells überprüft werden: Welche Angriffe sind möglich? Wie können sie durchgeführt werden?
Für die praktische Umsetzung bedeutet das: Für jeden Funktionsaufruf und alle vom Benutzer manipulierbaren Daten müssen alle sechs Kategorien des STRIDE-Modells überprüft werden: Welche Angriffe sind möglich? Wie können sie durchgeführt werden?
Mit der Beantwortung dieser Fragen geht es in der nächsten Folge weiter.
Trackbacks
Dipl.-Inform. Carsten Eilers am : Der SDL am Beispiel eines Gästebuchs, Teil 2
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Der SDL am Beispiel eines Gästebuchs, Teil 5
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Der SDL am Beispiel eines Gästebuchs, Teil 6
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Der SDL am Beispiel eines Gästebuchs, Teil 7
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Der SDL am Beispiel eines Gästebuchs, Teil 8
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Der SDL am Beispiel eines Gästebuchs, Teil 9
Vorschau anzeigen