Skip to content

Microsofts SDL, Phase 1 (Training) und 2 (Requirements)

Microsofts Security Development Lifecycle besteht aus 7 Phasen, die ich ab dieser Folge vorstelle. Los geht es natürlich mit

Phase 1: Training

Die erste Phase des SDL schafft die Voraussetzungen dafür, ihn überhaupt implementieren zu können. Sie besteht nur aus einem einzigen Schritt: Dem "Core Security Training". Bei Microsoft bedeutet das: Alle Personen mit technischen Aufgaben wie Entwickler, Tester und Programm-Manager müssen mindestens einmal im Jahr einen entsprechenden Kurs besuchen.

Der Grund dafür ist ganz einfach: Nur wenn Sie überhaupt wissen, was für Sicherheitsprobleme und Schwachstellen es gibt, können Sie sie in Ihrem Programm erkennen und vermeiden. Und da sich die Sicherheitswelt rasend schnell weiterdreht, reicht es nicht, einmal einen Kurs zu besuchen, um dann für alle Zeiten genug zu wissen. Stattdessen müssen Sie sich auf dem Laufenden halten, damit Ihr Programm nicht plötzlich Angriffen bzw. Schwachstellen zum Opfer fällt, von denen Sie nie gehört haben.

Ein gutes Beispiel für einen solchen Angriff bzw. eine solche Schwachstelle ist das Clickjacking, das Umleiten von Mausklicks in einen unsichtbaren iframe: Das wurde 2008 entdeckt, und keine einzige Webanwendung enthielt einen Schutz vor diesen Angriffen. Dass zumindest damals Framebuster, die aus anderen Gründen implementiert wurden, einen Schutz darstellten, ist reiner Zufall. Inzwischen bieten Framebuster keinen Schutz mehr, so dass auch alle nach 2008 mit einem Framebuster vor Clickjacking geschützten Webanwendungen inzwischen erneut angreifbar sind. Heute bietet nur ein X-FRAME-OPTIONS-Header Schutz vor einem Clickjacking-Angriff, aber das wissen nur die Webentwickler und Webadministratoren, die sich laufend informiert haben.

Ein weiteres Beispiel ist das "Binary Planting", der Missbrauch unsicherer Suchpfade aus der Ferne. Unsichere Suchpfade galten bis zur Entdeckung dieses neuen Angriffsvektors 2010 als rein lokales Problem, dass lediglich im Rahmen einer Privilegieneskalation für einen lokalen Angreifer interessant war. Was zur vor 2010 korrekten Schlussfolgerung führte, dass eine entsprechende Schwachstelle in einem Programm, dass ohne besondere Rechte ausgeführt wird, zwar unschön, aber weitgehend ungefährlich ist. Seitdem unsichere Suchpfade auch aus der Ferne ausgenutzt werden können, sieht das natürlich ganz anders aus, und viele Programme mussten (und müssen teilweise immer noch) nachgebessert werden.

Falls Sie jetzt stöhnen "Ein Sicherheitstraining? Irgend so eine öde Fortbildung, die ich eigentlich gar nicht will?" - warum denn so pessimistisch? IT-Sicherheit ist ein äußerst spannendes Thema, und außerdem: Wer sagt denn, dass Sie gleich zu einem Fortbildungskurs müssen? Sie können sich durchaus auch aus Büchern und Magazinen oder Online informieren.

Phase 2: Requirements

In der zweiten Phase werden die Sicherheits- und Datenschutz-Anforderungen des Programms spezifiziert, so dass sie optimal in das Projekt integriert werden können. Die Phase besteht aus drei Schritten, für die Process Templates für Visual Studio Team System (VSTS) und Team Foundation Server (TFS) sowohl für konventionelle als auch agile Entwicklung zur Verfügung stehen. Aber auch ohne Process Templates lassen sich die Schritte recht einfach durchführen.

Schritt 1: "Establish Security Requirements"

Welche minimalen Sicherheits- und Datenschutz-Anforderungen muss das Programm in der vorgesehenen Arbeitsumgebung erfüllen?

Überlegen Sie einfach, welche der Schutzziele der IT-Sicherheit (die drei "Klassiker" Vertraulichkeit, Verfügbarkeit und Integrität, ggf. ergänzt um Nichtabstreitbarkeit) durch Ihr Programm gefährdet werden können. Dann wissen Sie auch, welche Anforderungen es erfüllen muss: Alle, die nötig sind, um diese Gefahren zu eliminieren.

Außerdem wird in diesem Schritt ggf. der zuständige Sicherheitsexperte benannt und ein Tracking-System zum Verfolgen von Schwachstellen eingeführt. Der Experte werden Sie meist selber sein, und irgend eine Art von Bugtracking-System werden Sie sowieso benötigen. Notfalls im Form einer Liste, in die Sie gefundene Fehler eintragen.

Schritt 2: "Create Quality Gates/Bug Bars"

Welche Sicherheits- und Datenschutz-Anforderungen muss das Programm mindestens erfüllen, damit es veröffentlicht werden kann?

Damit sind z.B. Forderungen wie "Es darf bei der Veröffentlichung keine bekannten kritischen Schwachstellen geben" gemeint, was eigentlich eine Selbstverständlichkeit sein sollte. Aber um die zu erfüllen, müssen Sie erst mal wissen, welche Schwachstellen es überhaupt geben kann und welche davon kritisch sind.

Das lässt sich alles sehr gut (mehr oder weniger) informell festlegen. Wenn Sie eine technische Lösung vorziehen, finden Sie im "Microsoft Security Development Lifecycle (SDL) - Process Guidance" u.a. Beispiele für eine "Privacy Bug Bar" und eine "Security Bug Bar", die Sie z.B. im Microsoft Team Foundation Server verwenden können.

Schritt 3: "Perform Security and Privacy Risk Assessment"

Mit Security Risk Assessments (SRAs) und Privacy Risk Assessments (PRAs) werden die funktionalen Aspekte des Programms identifiziert, die besonders sorgfältig untersucht werden müssen. Mit anderen Worten: Welche Funktionen lassen sich besonders leicht missbrauchen oder stellen bei einem Missbrauch eine besonders große Gefahr dar?

Sie können sich hierfür einfach in die Rolle eines Angreifers versetzen und überlegen, welche Funktionen Ihres Programms sie wie für böse Zwecke missbrauchen können.

In der nächsten Folge stellen ich Ihnen die Phasen 3 und 4 vor: "Design" und "Implementation".

Carsten Eilers

>
        </div>
                
        <footer class= Kategorien: Grundlagen

Trackbacks

Keine Trackbacks