Dipl.-Inform. Carsten Eilers

In der dritten Phase wird die Sicherheitsarchitektur des Programms definiert und dokumentiert. Eine Entwurfsphase benötigen Sie sowieso, schließlich müssen Sie ja wissen, was Sie überhaupt implementieren wollen oder sollen. Sie müssen also nur ein paar zusätzliche Punkte berücksichtigen.

Auch diese Phase besteht aus drei Schritten:

Schritt 1: "Establish Design Requirements"

In diesem Schritt werden Sicherheits- und Datenschutz-Spezifikation erarbeitet: Wie können die benötigten Features des Programms sicher implementiert werden?

Mit einer einfachen Faustregel decken Sie i.A. einen großen Teil der Datenschutz-Forderungen ab: Speichern Sie so wenig vertrauliche Daten wie möglich, und sichern Sie die gespeicherten Daten so gut wie möglich vor unbefugten Zugriffen, oder kurz: "So wenig vertrauliche Daten wie möglich, so sicher wie möglich".

Damit haben sich auch gleich einen Teil der Sicherheits-Spezifikation. Die müssen Sie dann noch um die Abwehr weiterer möglicher Angriffe wie z.B. DoS-Angriffe, das Einschleusen von Schadcode usw. erweitern.

Schritt 2: "Perform Attack Surface Analysis/Reduction"

Welche Angriffsflächen bietet das Programm, und wie können sie reduziert werden? Angriffsflächen ergeben sich überall da, wo das Programm Anweisungen oder Daten entgegen nimmt. Betrachten Sie z.B. ein simples Programm, dass MP3-Dateien abspielt und über die Kommandozeile gesteuert wird. Angriffe sind dann zum einen über die Kommandozeilenparameter und zum anderen über die verarbeiteten MP3-Dateien möglich. Werden auch Wiedergabelisten verarbeitet, sind auch darüber Angriffe möglich, usw. usf.

Reduzieren lässt sich die Angriffsfläche z.B. durch das Entfernen nicht zwingend notwendiger Funktionen.

Schritt 3: "Use Threat Modeling"

Dieser Schritt ist m.E. einer der wichtigsten Schritte im Rahmen des SDL: Welchen Bedrohungen ist das Programm in der geplanten Einsatzumgebung ausgesetzt?

Um Schwachstellen zu vermeiden und Angriffe abzuwehren, müssen Sie zum einen wissen, welche Angriffe es überhaupt gibt (was Teil der Trainings-Phase ist), zum anderen, mit welchen Angriffen es Ihr Programm zu tun haben wird. Denn nur Gefahren, die Sie kennen, können Sie abwehren. Siehe die obigen Beispiele Clickjacking und Binary Planting: Gegen unbekannte Angriffe bzw. Schwachstellen kann man im Grunde keine Gegenmaßnahmen ergreifen.

Microsoft unterstützt Sie in diesem Schritt z.B. durch das Threat Modeling Tool Außerdem gibt es eine Mischung aus Tool und Training: Das "Elevation of Privilege (EoP) Card Game", ein Kartenspiel für 3-6 Mitspieler zur spielerischen Erkundung von Privilegieneskalationen.

Phase 4: Implementation

In der vierten Phase wird das Programm sicher implementiert, wieder in drei Schritten. Auch hier gilt: Implementieren müssen Sie das Programm sowieso, warum sollten Sie es also nicht sicher tun?

Schritt 1: "Use Approved Tools"

Eine Liste zulässiger Tools und zugehöriger Sicherheitsprüfungen und -meldungen, die regelmäßig aktualisiert wird, sorgt dafür, dass sichere Werkzeuge sicher verwendet werden. Das klingt "doppelt gemoppelt", ist es aber nicht: Zum einen gibt es das Konzept des "transitiven trojanischen Pferds" bei dem z.B. ein präparierter Compiler Schadcode in die damit erstellten Programme einfügt. Und das auch "in the Wild", z.B. 2009 in der Delphi-Entwicklungsumgebung und 2015 in Apples Entwicklungsumgebung Xcode. Zum anderen kann auch ein sicheres Tool unsicher eingesetzt werden, z.B. indem Compiler- oder Linkerwarnungen ignoriert oder falsch interpretiert werden.

Auch die Nutzung aller in Ihrem Programm einsetzbaren Mitigations, um Angriffe zu erschweren (wie z.B. DEP, ASLR, usw.), gehört zu diesem Schritt.

Der "Microsoft Security Development Lifecycle (SDL) - Process Guidance" enthält einen Anhang mit einer Zusammenfassung der für den SDL erforderlichen und empfohlenen Compiler, Tools und Optionen.

Schritt 2: "Deprecate Unsafe Functions"

Manche Funktionen führen zu bekannten Schwachstellen, z.B. provozieren viele Kopierfunktionen in C Pufferüberlauf-Schwachstellen. Diese unsicheren Funktionen sollten Sie nicht mehr verwenden.

Eine Liste unerwünschter C-Funktionsaufrufe gibt es in der MSDN Library, und als Tool stellt Microsoft das Headerfile banned.h bereit, das alle verbannten APIs enthält und Sie ggf. darauf hinweist, dass Sie eine unerwünschte Funktion verwenden.

Wenn sie manche Funktionen nicht mehr benutzen sollen, brauchen Sie dafür natürlich Ersatz: Strsafe.h stellt eine Reihe sicherer String-Funktionen als Ersatz für die unsicheren C-Funktionen bereit.

Schritt 3: "Perform Static Analysis"

Eine statische Analyse des Codes vor dem Kompilieren stellt sicher, dass die Regeln für die sichere Entwicklung des Programms eingehalten wurden. Dafür gibt es eine Vielzahl von Tools, so enthält z.B. Visual Studio inzwischen sehr solide Analyse-Tools.

In der nächsten Folge stellen ich Ihnen die Phasen 5 und 6 vor: "Verification" und "Release".

Carsten Eilers

Kategorien: Grundlagen

Trackbacks

Trackback-URL für diesen Eintrag

Keine Trackbacks