Sichere Softwareentwicklung nach dem "Security by Design"-Prinzip

Inhaltsverzeichnis

Noch vor einigen Jahren war Sicherheit in der Softwareentwicklung eher ein Nischenthema. Die zunehmende Vernetzung mit dem Internet, die dadurch entstandene Gefährdung von Anwendungen und die steigende Komplexität in der IT haben jedoch zur Erkenntnis geführt, dass Sicherheit im Softwareentwicklungsprozess erheblich stärker zu beachten ist. Bis sich die Erkenntnis jedoch flächendeckend durchsetzt, vergehen wohl noch einige Jahre, obgleich es für das Vermeiden von Sicherheitslücken nachweislich effektive Methoden wie das in diesem Artikel vorgestellte "Security by Design"-Prinzip gibt.

Sicherheit und Software – passt das?

Beobachtet man Mailinglisten wie Bugtraq oder Full Disclosure, fällt auf, dass Sicherheitsprobleme in der Softwareentwicklung weder in vollem Ausmaß erkannt noch effektiv bekämpft werden. Zu oft liest man zum Beispiel von SQL-Injection und Cross-Site Scripting (XSS), obgleich beide Angriffsarten seit langer Zeit bekannt sind und sie sich effektiv verhindern lassen.

Gerade bei stark verbreiteter Software haben solche Schwachstellen teilweise verheerende Auswirkungen, denn mit einer einzigen Sicherheitslücke lassen sich oft mehrere tausend Installationen angreifen. Bei weniger stark verbreiteter Software ist das Schadenpotenzial jedoch nicht unbedingt geringer. Bei Programmen zur Steuerung oder Überwachung von Geschäftsprozessen helfen beispielsweise Verwundbarkeiten, die Prozesse zu manipulieren. Für bösartig gesinnte Mitarbeiter oder externe Angreifer (Stichworte Wirtschaftsspionage oder organisiertes Verbrechen) sind solche Sicherheitslücken willkommene Gelegenheiten für Angriffe.

Betrachtet man die aktuelle Situation, liegt die Vermutung nahe, dass in der Softwareentwicklung keine oder nur ineffiziente Sicherheitsmaßnahmen einsetzt werden. Doch kommen schon seit langem Sicherheitsmaßnahmen zum Einsatz, die vom Ansatz her effektiv sein könnten. Das Problem liegt weniger im Anwenden der Maßnahmen, sondern in der Wahl des falschen Einsatzzeitpunkts. Führt man bei Software kurz vor der Inbetriebnahme einen Penetrationstest durch, der viele denkbare Angriffen durchführt, ohne dass man die Sicherheit bei der Entwicklung explizit berücksichtigt hat, ist es für einen erfahrenen Tester meist leicht, in die Anwendung einzudringen. Somit ist fraglich, ob ein Penetrationstest überhaupt sinnvoll ist, wenn man das Thema Sicherheit nicht während des Entwicklungsprozesses dezidiert berücksichtigt hat. Hinzu kommt, dass schwerwiegende Sicherheitslücken sich kurz vor einer geplanten Auslieferung nicht mehr oder nur noch mit hohem und kostenintensivem Aufwand beheben lassen.

Eine weitere gängige Maßnahme, die Code-Review, bei der ein Gutachter einen Programmabschnitt nach oder während der Entwicklung Korrektur liest, um Fehler oder Vereinfachungen zu finden, leidet darunter, dass nur qualifiziertes Personal die Review durchführen kann, was ebenfalls mit hohen Kosten verbunden ist. Komplexe Programme sind damit kaum umfassend zu überprüfen. Zudem hilft eine Code-Review nur bei der Identifizierung von Implementierungsfehlern, deckt aber weder Design- noch Konfigurationsfehler auf.

Die Hauptursache heutiger Sicherheitsprobleme liegt darin, dass Unternehmen Sicherheit nur selten als explizite Anforderung definieren. Auftraggeber spezifizieren nicht selten nur funktionale Anforderungen und verlassen sich auf Sicherungsmethoden wie Code-Review oder Penetrationstests, die zwar effektiv und empfohlen sind, deren Effizienz aber von ihrer Kombination und dem Einsatzzeitpunkt abhängt.

Königsweg "Security by Design"

Firmen wie Microsoft, die früh mit den Auswirkungen unsicherer Software konfrontiert wurden, suchen seit Jahren nach Lösungen und haben sie für sich gefunden, umgesetzt und kontinuierlich überarbeitet. Microsofts Prinzip heißt "Security by Design" und steht für integrierte Softwaresicherheit beziehungsweise setzt voraus, Sicherheit als explizite Anforderung in den Entwicklungsprozess aufzunehmen sowie ganzheitliche Sicherheitsmaßnahmen von der Initialisierung an zu berücksichtigen, umzusetzen und zu testen. Konsequent realisiert, schiebt man sogar die Auslieferung von Software auf, bis Sicherheitsfehler, sofern sie einen definierten Schwellenwert überschreiten, behoben sind.

Security by Design ist keine Technik, sondern eine Sicherheitsmaßnahme, die den Entwicklungsprozess begleitet und oft als Security Development Lifecycle (SDL) bezeichnet wird. Die Maßnahmen sollen eine integrierte und nachhaltige Sicherheit der entwickelten Software zur Folge haben.

Das "Security by Design"-Prinzip praktizieren viele Unternehmen. Dazu gehören neben Microsoft Adobe, Apple, EMC, Google, Oracle/Sun und Symantec. Auch diverse Finanzdienstleister oder das Militär einiger Staaten bemühen sich um die Einführung eines SDL. Er ist im Grunde genommen eine Anleitung zum Bauen sicherer Systeme, die zugehörigen Maßnahmen sind nicht auf die IT beschränkt. Tatsächlich praktizieren andere Industriezweige die Vorgehensweise schon lange, aber erst in letzter Zeit hält sie verstärkt Einzug in die IT.

Generell umfasst SDL Sicherheitsmaßnahmen, die den herkömmlichen Softwareentwicklungsprozess ergänzen und gewährleisten, dass Sicherheit im notwendigen Umfang zu berücksichtigen und zu integrieren ist, unabhängig davon, ob man eine agile oder andere Entwicklungsvorgehensweise wählt. Die Sicherheitsmaßnahmen lassen sich immer parallel zu den Entwicklungsschritten ausführen.

Microsoft-SDL

Der Microsoft-SDL

Microsofts Security Development Lifecycle ist in vielen Aspekten als vorbildlich zu betrachten. Zahlreiche Sicherheitslücken brachten das Unternehmen zur Erkenntnis, dass die Sicherheit in ihrer Software nachhaltig zu verbessern sei. 2002 startete Microsoft deshalb eine Software-Sicherheitsinitiative.

Ihren offiziellen Beginn markierte eine E-Mail von Bill Gates. Er schrieb an sämtliche Mitarbeiter, dass Sicherheit von nun an für Microsoft ein wichtiges Thema und von jedem Mitarbeiter zu unterstützen sei. Der Nachricht folgte ein umfassendes Ausbildungsprogramm, in dem die Firma rund 9000 Software-Ingenieure in den Bereichen Awareness und sichere Programmierung ausbildete. Danach konnten die Entwicklerteams zusammen mit einer dezidierten Gruppe für Softwaresicherheit die benötigten Maßnahmen während des Entwicklungszyklus umsetzen.

Noch im gleichen Jahr fiel die Anzahl der Verwundbarkeiten Microsofts Softwareprodukten messbar. Wie konsequent der Konzern die neuen Prinzipien umsetzte, zeigte sich 2003: Die Release des Windows Server 2003 wurde aufgrund nicht behobener Sicherheitslücken verschoben. Betrachtet man die Anzahl der Verwundbarkeiten in Microsoft-Produkten auf einer Zeitachse, so ist nach der Einführung des SDL ein deutlicher Rückgang zu erkennen.

Die Grafik zeigt die Anzahl der Verwundbarkeiten in Microsofts IIS über mehrere Jahre hinweg. Unterhalb der Zeitachse wird Microsofts SDL- Initiative dargestellt. Auffallend ist der Rückgang der Fehler während und nach der Einführung des SDL. Die Anzahl der Verwundbarkeiten pro Jahr wurden der National Vulnerability Database (http://nvd.nist.gov/) entnommen (Abb. 1)

Der Microsoft-SDL (siehe Abb. 2) besteht aus 14 Maßnahmen, auch Stufen genannt:

• Stufe 0: Bewusstmachung und Schulung
• Stufe 1: Projektinitialisierung und Definition des Schutzbedarfs
• Stufe 2: Kostenschätzung für Sicherheitsmaßnahmen
• Stufe 3: Vorgaben für Entwurf sowie Etablieren und Befolgen von Best Practices für den Entwurf
• Stufe 4: Risikoanalyse für Design
• Stufe 5: Erstellen der Dokumentation für das sichere Anwenden der Software
• Stufe 6: Umsetzen und Befolgen der Best Practices, sichere Programmierung
• Stufe 7: Überprüfung von Sicherheit und Datenschutz
• Stufe 8: "Security Push" als letztes und intensives Suchen von Sicherheitslücken
• Stufe 9: Datenschutz-Review
• Stufe 10: Planung für Eintreten von Sicherheitsvorfällen
• Stufe 11: Letzte Sicherheits- und Datenschutzreview inklusive Abnahme
• Stufe 12: Ausliefern der Software
• Stufe 13: Reagieren auf Sicherheitsvorfälle

In den sieben Jahren seit Einführung des SDL hat Microsoft die Initiative weiterentwickelt und stellt inzwischen sogar Software zur Unterstützung gewisser SDL-Aktionen, etwa Threat Modeling, zur Verfügung.

Mini-SDL

Institutionalisierung

Microsofts SDL lässt sich als umfassender, reifer und detaillierter Ansatz zur konsequenten Verbesserung der Softwaresicherheit werten. Jedes Programm ist bei Microsoft SDL-konform zu entwickeln. Windows Vista war das erste Produkt, das die Firma von Beginn an so programmiert hatte. Das bedeutet nicht, dass Vista komplett fehlerfrei und ohne Sicherheitsfehler ist, denn hundertprozentige Sicherheit ist in der Praxis nur schwer realisierbar.

Die Einführung eines SDL ist eine komplexe Aufgabe, deren erfolgreiche Umsetzung meist eine Änderung der Softwareentwicklungskultur zur Folge hat. Deshalb empfiehlt es sich, klein zu beginnen und den SDL kontinuierlich auszuweiten.

Im Idealfall beginnt die Umsetzung eines SDL mit einer Software-Sicherheitsinitiative. Sie hat das Ziel, sichere Softwareentwicklung einzuführen. Hierfür benötigt man die Unterstützung des Managements. Ist sie gewährleistet, geht es an die Umsetzung. Microsofts SDL-Modell ist für den Einstieg zu umfangreich, zudem erfordert SDL einen hohen Grad an Individualisierung. Die einfache Übernahme einer existierenden Umsetzung ist daher nicht empfehlenswert.

Die ersten Maßnahmen sind zunächst an einer beschränkten Anzahl von Projekten und in einem reduzierten Umfang durchzuführen. Alternativ ließe sich breitflächig, jedoch mit reduzierten Maßnahmen beginnen. Auch eine Kombination beider Ansätze ist denkbar. Wichtig ist, die Sicherheitsmaßnahmen zu bestimmen, die während der Entwicklungsphase anzuwenden sind.

Einen praxiserprobten Ansatz könnte ein Mini-SDL darstellen, der nur die wichtigsten Sicherheitsmaßnahmen enthält. Wendet man sie in einem Softwareentwicklungsprozess an, lässt sich damit die Sicherheit deutlich verbessern. Mittelfristig sind die Grundansätze zu erweitern und auszubauen.

Die Minimalumsetzung besteht aus fünf Schritten:

1. Managementunterstützung sicherstellen
2. Awareness und Schulung
3. Risikoanalyse
4. sichere Programmierung anwenden
5. Test und Review

Schritt 1 ist die Grundlage für ein erfolgreiches Gelingen. Lässt sich die Initiative nicht mit Unterstützung des Managements starten, besteht die Gefahr, dass man unter Zeitdruck Sicherheitsmaßnahmen vernachlässigt. Um das zu verhindern, muss die Sicherheit eine Vorgabe sein, die im Abnahmeprozess geprüft werden muss.

Ist die Unterstützung gewährleistet, sollte man gewährleisten, dass alle Softwareentwickler die Sicherheitsgefahren kennen und wissen, wie sie den Gefahren begegnen können. Im Rahmen von Schulungen lassen sich Awareness und Wissen um sichere Programmierung vermitteln. Daraus hervorgehend sollte man Leitlinien oder Vorgaben definieren. Sie unterstützen später Review und Abnahme sowie erleichtern neuen Mitarbeitern den Einstieg in die sichere Programmierung. Beide Maßnahmen sind vor einem Projekt durchzuführen. Streng genommen gehören sie nicht in den Softwareentwicklungszyklus. Weil sie vor jedem Projekt von neuem zu prüfen und sicherzustellen sind, lassen sie sich einer Initialisierungsphase zuordnen.

Der erste Schritt der Entwicklung besteht in einer Risikoanalyse, die den Softwareentwurf auf Sicherheitsrisiken hin prüft. Dazu eignet sich das Threat Modeling. Das bei Microsoft eingesetzte Verfahren erlaubt die Identifikation von Risiken und Gefahren im Entwurfsstadium. Entdeckt man Sicherheitsrisiken, sind Maßnahmen zu definieren und umzusetzen. Das Durchführen der Sicherheitsmaßnahme ist neben der sicheren Programmierung wohl der effektivste Punkt des Ansatzes.

Hat man Sicherheitsaspekte im Entwurf berücksichtigen und einplanen können, gilt es, die Entwicklung nach den Vorgaben sicherer Programmierung durchzuführen. Die wichtigsten sind – unabhängig von der Programmiersprache – folgende fünf Punkte:

1. Prüfung von Ein- und Ausgaben
2. Authentisierung und Zugriffskontrollen
3. korrektes Handhaben und Schutz von sensitiven Informationen und Daten
4. Befolgen des "Least Privilege"-Prinzips, das die tiefstmöglichen Privilegien vergibt
5. Verhindern von Informationspreisgaben

Durch die Befolgung der Prinzipien lassen sich Sicherheitslücken in der Implementierungsphase wie SQL-Injection, Cross-Site Scripting oder Fehler in der Zugriffskontrolle vermeiden.

Der letzte Schritt umfasst Sicherheitstests der fertigen Anwendung, die prüfen sollen, ob die Vorgaben zur sicheren Programmierung eingehalten wurden, und gewährleisten, dass man keine Fehler, speziell keine sicherheitsrelevanten, implementiert hat. Das bedeutet beispielsweise die Prüfung des Sourcecodes. Es lassen sich nicht nur Konventionen und Qualität prüfen, sondern Entwickler können nach Sicherheitslücken suchen, sie dokumentieren und beheben. Geht man bei der Code-Review manuell vor, lassen sich die Resultate der Risikoanalyse aus Schritt 1 zum Identifizieren besonders kritischer Stellen beziehen. Das ermöglicht eine fokussierte und risikogetriebene Vorgehensweise.

Weil viele Sicherheitslücken speziell bei Eingaben auftreten, sind sie besonders abzufangen. Fuzzing ist hierfür eine wirksame und empfehlenswerte Maßnahme. Mit ihr lassen sich Eingabeschnittstellen mit generierten Eingaben beschicken und so lange testen, bis gewährleistet ist, dass das Programm bei unerwarteten Eingaben keine Probleme verursacht.

Fazit

Fazit

Mit den fünf Punkten des Mini-SDL lässt sich ein Kernsystem implementieren, das man im Lauf der Zeit überarbeiten und ausbauen kann. Für die Einführung eines umfassenden SDL stehen unterschiedliche freie Werkzeuge zur Verfügung. BSIMM (Building Security In Maturity Model) beispielsweise definiert ein Reifegradmodell für zwölf Praktiken, wie sie sich in der sicheren Softwareentwicklung anwenden lassen. Etwas weiter geht SAMM (Software Assurance Maturity Model). Es arbeitet ebenfalls mit Reifegraden, stellt aber zusätzliche Beschreibungen und Empfehlungen für eine Umsetzung und Weiterentwicklung zur Verfügung.

Bei allen Maßnahmen gilt: Es genügt nicht, nur die Werkzeuge anzuwenden, wie effektiv sie auch sein mögen. Erst das korrekte Vorgehen und das Know-how entscheiden über ihre Wirksamkeit.

Niklaus Schild
ist Senior Consultant für Informationssicherheit bei der Trivadis AG und arbeitet in den Fachgebieten der sicheren Softwareentwicklung und dem Security Management.

Links & Literatur (ane)

• Microsoft SDL
• SAMM
• BSIMM
• Michael Howard, Steve Lippner, The Security Development Lifecycle, Microsoft Press 2006
• Jerorme H. Saltzer, Michael D. Schroeder, The Protection of Information in Computer Systems (1975)