Management und Wissen / Sichere Softwareentwicklung

Security Development Lifecycle

Wann kommt die sichere Entwicklung von Software in Deutschland wirklich an?

Vor acht Jahren hat Microsoft begonnen, die meisten seiner Produkte einem besonderen Prozess für sichere Softwareentwicklung zu unterwerfen. Dieser "Security Development Lifecycle" (SDL) dient jedoch mehr als nur der internen Qualitätssicherung: Er ist umfassend öffentlich dokumentiert und für Dritte kostenlos nutzbar.

Von Michael Kranawetter, Unterschleißheim

Trotz einer umfassenden Diskussion über Sicherheitslücken fehlt weiterhin sehr oft eine wesentliche Maßnahme an der Quelle der verwundbarsten Angriffsziele: ein sicherer Entwicklungsprozess für Applikationen. Denn längst nicht nur Betriebssysteme stehen im Fokus der Angreifer: Das größere Risiko "gehackt" zu werden und Daten zu "verlieren", liegt in der Software, die darauf läuft – egal ob gekauft oder selbst entwickelt. Abhilfe verspricht die Einführung von Rollen und Regeln sowie die Integration von Sicherheit in den Entstehungsprozess selbst.

Ein Prozess wie der von Microsoft definierte "Security Development Lifecycle" (SDL) – zu deutsch der sichere Lebenszyklus der Entwicklung oder Sicherheits-Entwicklungszyklus – klingt zwar vielversprechend, gleichzeitig aber auch komplex und nach "nicht in überschaubarer Zeit umsetzbar". Dem ist aber nicht so! Die entscheidenden Fragen sind, wie man damit anfängt und welche wichtigen Eckpunkte man kennen und beachten sollte.

Beim SDL handelt es sich zum einen um Prozessergänzungen und Rollenbeschreibungen, zum anderen um Hilfsmittel und Tools – sowie Empfehlungen und Erfahrungen im Umgang mit Softwareentwicklung (siehe www.microsoft.com/sdl). Ziel ist es, die Anzahl der Verwundbarkeiten so gering wie möglich zu halten und im Notfall gut reagieren zu können.

Dabei geht es um drei Kernkonzepte: Schulung, kontinuierliche Prozessverbesserung und Verantwortlichkeit. Angemerkt sei, dass hier zwar immer von Software die Rede ist, der SDL aber durchaus auch für andere Unterfangen verwendet werden kann und sollte, beispielsweise für Infrastrukturprojekte. Als Basis dienen dem SDL die Grundsätze des sicheren Einsatzes von Software, Sicherheit im Design, als Standardeinstellung und im Betrieb, flankiert von geeigneten Kommunikations-Maßnahmen (vgl. Kasten).

SDL – Definition und Prinzipien

Der "Security Development Lifecycle" (SDL) ist ein Prozess zur Gewährleistung von Sicherheit mit Schwerpunkt auf der Softwareentwicklung. Kernpunkt ist die Integration von Informations-Sicherheit und Datenschutz in die Software und Unternehmenskultur. Durch die Kombination ganzheitlicher und praktischer Verfahren zielt der SDL darauf ab, die Anzahl und den Schweregrad von Sicherheitsschwachstellen innerhalb der Software zu verringern. Durch den SDL werden Sicherheit und Datenschutz in allen Phasen des Entwicklungsprozesses eingeführt – bis hin zur Reaktion bei Vorkommnissen im laufenden Betrieb.

Unter dem Kürzel SD³C sind folgende Prinzipien im SDL verankert:

Secure by Design: Beim Design der Software wird die Sicherheit der Daten, der Architektur und der Schnittstellen von Anfang an berücksichtigt.

Secure by Default: Die Grundeinstellungen der Software werden so gesetzt, dass Daten, Privilegien und Schnittstellen auf niedrigstmöglichem Niveau sind oder gar deaktiviert werden, wenn es sich um zusätzliche Funktionen handelt.

Secure in Deployment: Installation, Dokumentationen und Hilfsprogramme sind so gestaltet, dass eine einfache, nachvollziehbare und sichere Verwaltung sowie sicherer Betrieb möglich sind.

Communications: Wenn Vorfälle oder Sicherheitslücken auftreten, dann wird offen und zeitnah darüber berichtet und Updates oder Workarounds werden zur Verfügung gestellt.

Schulungen

Initiale und begleitende Schulungen spielen bei der Softwareentwicklung eine wichtige Rolle. Eine angemessene Investition in Wissensaufbau und -transfer ist notwendig, um auf dem aktuellen Stand der technischen Entwicklungen zu bleiben und auf neue Bedrohungen zu reagieren. Alle Mitglieder eines Softwareentwicklungsteams müssen eine geeignete Schulung erhalten, um über Grundlagen und aktuelle Trends in Sicherheit und Datenschutz auf dem Laufenden zu bleiben. Mitarbeiter in technischen Funktionen (Entwickler, Tester und Programmmanager), die direkt an der Entwicklung von Softwareprogrammen beteiligt sind, müssen mindestens einen Sicherheitstrainingskurs im Jahr besuchen.

Da Sicherheitsrisiken nicht statisch sind, legt SDL besonderen Wert auf das Verständnis von Ursache und Wirkung bei Sicherheitsschwachstellen. Daher ist auch eine regelmäßige Bewertung der SDL-Prozesse und Anpassung als Reaktion auf technologische Fortschritte oder neue Bedrohungen unerlässlich.

Um die Wirksamkeit von Schulungen bewerten zu können, ist eine Erhebung und Archivierung von Daten erforderlich, mit deren Hilfe man die Einhaltung der Prozesse überprüfen kann. Diese Daten werden dann auch zur Wartung oder Reaktion im Fehlerfall herangezogen, um fundiert reagieren zu können. Entsprechend vorab definierter Reaktions- und Kommunikationspläne für Sicherheitsvorfälle kann man so allen Beteiligten eine präzise und überzeugende Hilfestellung bieten. Zudem werden die Schulungen im Nachgang an den festgestellten Mängeln kontinuierlich verbessert und weiterentwickelt.

Kontinuierliche Prozessverbesserung

Damit sich die Einhaltung der Prozessschritte nachvollziehen lässt, benötigt die Organisation eine Anwendung, in der sie die Entwicklungs- und Testdaten für eine Sicherheitsüberprüfung zentral speichert. Hier werden alle Artefakte des SDL-Prozesses, wie beispielsweise Design- und Implementierungsnotizen, Bedrohungsmodelle, Testprotokolle und andere Prozessbescheinigungen erfasst. Wie in jeder kritischen Anwendung wird auch hier ein funktionierendes Identitäts- und Zugriffs-Management vorausgesetzt, das nur autorisierte Mitarbeiter die Anwendung verwenden lässt. Der Entwicklungsprozess wird demnach überwacht und überprüft – unter Berücksichtigung der Sicherheits- und Datenschutzanforderungen der Organisation, der funktionalen und technischen Anforderungen und des betrieblichen Kontexts der sich in Entwicklung befindlichen Anwendung.

Erstellt beispielsweise ein Entwicklungsteam eine Prozesssteuerungsanwendung für eine kritische Umgebung, muss man auch angemessene Zeit und Ressourcen für die Erstellung und Wartung des Überwachungsprozesses zuweisen. Nur so werden objektive Analysen durch die verantwortlichen Sicherheits- und Datenschutzmitarbeiter der Organisation, die Unternehmensführung sowie beteiligte Dritte (z. B. Auditoren) ermöglicht.

Anders ausgedrückt führt das Sparen am Überwachungsprozess später unvermeidlich zu Problemen und "explodierenden" Investitionen, meist bei einem Notfall. Daher sollten jede Organisation rechtzeitig dafür sorgen, dass zuverlässige Systeme installiert werden, um zu kritischen Zeitpunkten kritische Fragen beantworten zu können.

Dabei spielt zur Gewährleistung der Softwaresicherheit auch die Fehlerursachenanalyse eine wichtige Rolle: Bei der Entdeckung einer bisher unbekannten Schwachstelle sollte man genau untersuchen, an welcher Stelle die Sicherheitsprozesse fehlgeschlagen sind. Diese Schwachstellen können unterschiedlichsten Ursachen zugeschrieben werden, von menschlichem Fehlverhalten bis hin zu Fehlern in Tools oder Richtlinien. Ziel der Fehlerursachenanalyse ist es, die genaue Art des Fehlers zu verstehen. Anhand dieser Informationen lässt sich sicherstellen, dass der überarbeitete SDL-Prozess Fehler desselben Typs zukünftig berücksichtigt.

Ebenso wichtig ist die Etablierung eines regelmäßigen Updateprozesses – denn Softwarebedrohungen sind nicht statisch, demzufolge darf auch der Prozess zur Sicherung von Software nicht statisch sein. Organisationen sollten die gewonnenen Erkenntnisse aus Methoden wie Fehlerursachenanalyse, Richtlinienänderungen und Verbesserungen in Technologie und Automatisierung in regelmäßigen Abständen auf den SDL übertragen – im Allgemeinen sollte ein jährliches Update ausreichen. Wenn jedoch neue, zuvor unbekannte Schwachstellentypen aufgedeckt werden, ist eine sofortige außerplanmäßige Überarbeitung des SDL erforderlich, damit man fortan geeignete Gegenmaßnahmen ergreifen kann.

Verantwortlichkeit

Die dritte Säule des SDL setzt sich aus definierten und zugewiesenen Verantwortlichkeiten zusammen. Der Prozess umfasst hierzu allgemeine Kriterien und Tätigkeitsbeschreibungen für Sicherheits- und Datenschutzrollen. Die Rollen bilden die erforderliche Organisationsstruktur zum Identifizieren, Katalogisieren und Beheben von Sicherheits- und Datenschutzproblemen in dem Softwareentwicklungsprojekt.

Dabei gibt es Rollen innerhalb und außerhalb des Projekts: Innerhalb des Projektes sind Gutachterrollen mit mandatierter Autorität zu etablieren, Sicherheits- und Datenschutzpläne des Projektteams anzunehmen oder abzulehnen. Diese Rollen sollten fachliche Experten aus dem Projektteam einnehmen – sie sind verantwortlich für die Aushandlung, Annahme und Überwachung minimaler Sicherheits- und Datenschutzanforderungen sowie für die Einhaltung klarer Kommunikationswege mit Beobachtern und Entscheidungsträgern.

Zudem solle man Sicherheits- und Datenschutz-"Champions" etablieren, die im Projekt verantwortlich für die Koordination, Nachverfolgung und Kategorisierung von Sicherheitsproblemen sind, darüber hinaus aber auch für die Eingabe in die Überwachungsanwendung, die zur objektiven Beurteilung der identifizierten Risiken notwendig ist. Die Champions sind darüber hinaus verantwortlich für Statusberichte an den Sicherheitsbeobachter und andere relevante Parteien (z. B. Entwicklungs- und Testleiter) innerhalb und außerhalb des Projekts.

Außerhalb sind als Projektbeobachter Sicherheits- und Datenschutzexperten notwendig – speziell qualifizierte Mitarbeiter, die in einer unabhängigen, zentralisierten Gruppe der Organisation das Thema vertreten. Sie werden deshalb als Beobachter bezeichnet, weil sie im Projekt selbst keine Verantwortung tragen, jedoch die Projektergebnisse stetig im Auge behalten.

Hier finden sich zwei Funktionen, zum einen die Auditierung, zum anderen die Beratung: Auditiert werden muss jede Phase des Softwareentwicklungsprozesses mit einer Bescheinigung über die Erfüllung jeder Sicherheitsanforderung. Hierbei muss die Freiheit bestehen, die Konformität (oder Nichtkonformität) mit Sicherheits- und Datenschutzanforderungen ohne Beeinflussung durch das Projektteam festzuhalten. Die Beraterrolle hat indes über nachweisbare Fachkenntnisse in Sicherheits- und/oder Datenschutzfragen zu verfügen – denn die Berater sind dafür verantwortlich, dass das Projekt notwendige Informationen zur Umsetzung von Sicherheits- und Datenschutzanforderungen bekommt und kontinuierlich up-to-date bleibt.

Die SDL-Methoden

Einfach ausgedrückt ist der SDL, wie bereits erörtert, eine Sammlung erforderlicher Sicherheitsmaßnahmen. Diese werden im Folgenden in der Reihenfolge dargestellt, in der sie ausgeführt werden sollten – zusätzlich gruppiert nach den Phasen des traditionellen Softwareentwicklungszyklus (Software-Development-Life-Cycle, SDLC).

Viele der erörterten Maßnahmen würden bereits als eigenständige Aktivität einen gewissen Sicherheitsgewinn bewirken. Die Praxis hat jedoch bei unterschiedlichen Unternehmen gezeigt, dass im Rahmen eines Softwareentwicklungsprozesses ausgeführte Sicherheitsmaßnahmen zu größeren Sicherheitsvorteilen führen als einzeln oder ad hoc implementierte Maßnahmen. Dazu hat der SDL 16 Methoden definiert, die in den einzelnen Phasen zur Anwendung kommen sollen. Zudem gibt es optionale Sicherheitsmaßnahmen, die nach den Anforderungen des Projektteams oder des Sicherheitsbeobachters hinzugefügt werden können, um die angestrebten Sicherheits- und Datenschutzziele zu untermauern.

[Illustration - Quelle: Microsoft]
Der Security-Development-Lifecycle -(SDL)-Prozess mit seinen Methoden

Phase "Null": Schulung

SDL-Methode 1: Schulungsanforderungen

Eine Softwaresicherheitsschulung sollte folgende Grundlagen behandeln:

  • Sicheres Design: Verringerung der Angriffsfläche, Defense-in-Depth, Prinzip der geringsten Rechte, Sicherheits-Standards
  • Bedrohungsmodellierung: Übersicht, Auswirkungen eines Bedrohungsmodells auf das Design, auf einem Bedrohungsmodell basierende Programmierungseinschränkungen
  • Sichere Programmierung: Pufferüberläufe (für Anwendungen in C und C++), Fehler bei der Arithmetik ganzer Zahlen (für Anwendungen in C und C++), Cross-Site-Scripting, SQL-Injection, schwache Kryptografie
  • Sicherheitstests: Unterschiede zu Funktionstests, Risikobewertung, Methoden
  • Datenschutz: sensitive Datentypen, bewährte Designmethoden, Risikobewertung, bewährte Entwicklungs- und Testmethoden für Datenschutzbelange

Durch die hierdurch beschriebene Schulung erhalten technische Mitarbeiter das erforderliche Basiswissen. Wenn es Zeit und Ressourcen zulassen, ist unter Umständen eine weitere Schulung in fortgeschrittenen Konzepten erforderlich – Beispiele hierfür sind unter anderem:

  • Sicherheitsdesign und -architektur für Fortgeschrittene,
  • Design vertrauenswürdiger Benutzeroberflächen,
  • Sicherheitsschwachstellen im Detail,
  • Implementieren benutzerdefinierter Bedrohungsabwehr.

Phase Eins: Anforderungen

SDL-Methode 2: Sicherheitsanforderungen

Die Notwendigkeit, Sicherheit und Datenschutz im Voraus zu berücksichtigen, stellt einen wesentlichen Aspekt der sicheren Softwareentwicklung dar. Der optimale Zeitpunkt für die Definition von Anforderungen an die Vertrauenswürdigkeit liegt noch vor dem Projektstart, gegebenenfalls sollte man das spätestens in den ersten Planungsphasen nachholen.

Die frühe Definition von Anforderungen ermöglicht es den Entwicklungsteams wichtige Meilensteine und Arbeitsergebnisse festzulegen. Außerdem wird so die Integration von Sicherheit und Datenschutz bei minimalen Auswirkungen auf Projekt und Zeitplan ermöglicht. Die Analyse der Sicherheits- und Datenschutzanforderungen erfolgt zu Projektbeginn: Sie umfasst die Spezifikation von Mindestanforderungen an die Sicherheit der Anwendung, die bei der Ausführung in ihrer geplanten Betriebsumgebung erfüllt sein müssen, sowie die Spezifikation und Bereitstellung eines Überwachungssystems für Sicherheitsschwachstellen und Betriebsaufgaben.

SDL-Methode 3: Quality-Gates und Bug-Bars

Quality-Gates und Bug-Bars definieren die niedrigsten akzeptablen Qualitätsgrade für Sicherheit und Datenschutz. Das Festlegen dieser Kriterien zu Beginn eines Projekts verbessert das Verständnis der Risiken, die mit Sicherheitsherausforderungen verbunden sind, und ermöglicht den Teamsdas Erkennen und Beheben von Sicherheitsverwundbarkeiten noch während der Entwicklung.

Das Projektteam muss für jede Entwicklungsphase Quality-Gates aushandeln (z. B. "alle Compiler-Warnungen müssen vor dem Einchecken von Code klassifiziert und behoben werden") und dann vom Sicherheitsbeobachter genehmigen lassen. Dieser kann gegebenenfalls projektspezifische Erläuterungen und strengere Sicherheitsanforderungen hinzufügen. Darüber hinaus muss das Projektteam die Einhaltung der ausgehandelten Quality-Gates nachweisen, um die abschließende Sicherheitsüberprüfung (Final Security-Review, FSR – s. u.) absolvieren zu können.

Eine Bug-Bar ist ein Quality-Gate, das sich auf das gesamte Softwareentwicklungsprojekt bezieht: Sie dient zur Definition der Schweregrad-Schwellenwerte von Sicherheitsschwachstellen, (z. B. "keine bekannten Schwachstellen in der Anwendung mit Bewertung 'kritisch' oder 'wichtig' bei der Veröffentlichung"). Die einmal festgelegte Bug-Bar sollte niemals gelockert werden!

SDL-Methode 4: Risikobewertung

Sicherheitsrisikobewertungen (Security-Risk-Assessments, SRAs) und Datenschutz-Risikobewertungen (Privacy-Risk-Assessments, PRAs) sind obligatorische Prozesse, die funktionale Aspekte der Software identifizieren, welche einer genauen Überprüfung bedürfen. Diese Bewertungen müssen die folgenden Informationen umfassen:

  • Für welche Teile des Projekts sind Bedrohungsmodelle vor der Veröffentlichung erforderlich? (Sicherheit)
  • Für welche Teile des Projekts sind Überprüfungen des Sicherheitsdesigns vor der Veröffentlichung erforderlich? (Sicherheit)
  • Für welche Teile des Projekts (wenn überhaupt) sind Penetrationstests durch einen gemeinsam bestimmten Tester außerhalb des Projektteams erforderlich? (Sicherheit)
  • Gibt es zusätzliche Test- oder Analyseanforderungen, die der Sicherheitsbeobachter zur Verringerung von Sicherheitsrisiken für nötig erachtet? (Sicherheit)
  • Welchen speziellen Bereich betreffen die Anforderungen für Fuzzingtests? (Sicherheit)
  • Wie lautet die Bewertung der Datenschutzrisiken (Privacy-Impact-Rating)? (Datenschutz)

Die Antwort auf die letzte Frage beruht auf folgenden Schweregraden:

  • P1 – hohes Datenschutzrisiko: Das Feature, das Produkt oder der Service speichern oder übertragen personenbezogene Informationen, ändern Einstellungen oder Dateitypzuordnungen beziehungsweise installieren Software.
  • P2 – mittleres Datenschutzrisiko: Das einzige Verhalten in dem Feature, Produkt oder Service, das sich auf den Datenschutz auswirkt, ist eine einmalige, vom Benutzer initiierte, anonyme Datenübertragung (z. B. wenn der Benutzer auf einen Link klickt, greift die Software auf eine Website zu).
  • P3 – niedriges Datenschutzrisiko: Kein Verhalten in dem Feature, Produkt oder Service wirkt sich auf den Datenschutz aus – es werden keine anonymen oder persönlichen Daten übertragen, keine personenbezogenen Daten auf dem Computer gespeichert, keine Einstellungen im Namen des Benutzers geändert und keine Software installiert.

Phase Zwei: Design

SDL-Methode 5: Designanforderungen

Die Vertrauenswürdigkeit eines Projektdesignslässt sich am einfachsten in frühen Phasen des Lebenszyklus beeinflussen – die Berücksichtigung von Sicherheits- und Datenschutzaspekten in der Designphase ist von entscheidender Bedeutung und Sicherheits- und Datenschutzprobleme zu beheben, ist weit weniger aufwändig, wenn dies in den Eröffnungsphasen eines Projekts erfolgt. Projektteams sollten daher dringend von der üblichen Praxis Abstand nehmen, Sicherheits- und Datenschutzfeaturesund die Behandlung entsprechender Probleme bis zum Ende der Projektentwicklung aufzuschieben.

Zudem ist es von zentraler Bedeutung, dass Projektteams den Unterschied zwischen "sicheren Features" und "Sicherheitsfeatures" verstehen: Es ist durchaus möglich, nicht-sichere Sicherheitsfeatureszu implementieren. Sichere Featuressind solche, deren Funktionalität bezüglich der Sicherheit zuverlässig entwickelt wurde, einschließlich einer strikten Validierung aller Daten vor der Verarbeitung oder einer kryptografisch robusten Implementierung von Bibliotheken für Verschlüsselungsdienste. Der Begriff Sicherheitsfeaturesbeschreibt hingegen eine Programmfunktionalität mit Auswirkungen auf die Sicherheit (z. B. Kerberos-Authentifizierung oder Firewall).

Die Methode der Designanforderungen umfasst eine Reihe obligatorischer Maßnahmen – Beispiele sind die Erstellung von Designspezifikationen für Sicherheit und Datenschutz, die Spezifikationsüberprüfung und die Spezifikation minimaler Designanforderungen. Designspezifikationen sollten Sicherheits- und Datenschutzfeaturesbeschreiben, die direkt für Benutzer verfügbar gemacht werden. Dies umfasst zum Beispiel jene, die eine Benutzerauthentifizierung zum Zugriff auf bestimmte Daten oder die Zustimmung des Benutzers für ein Datenschutzfeature mit hohem Risiko erfordern.

Darüber hinaus sollten alle Designspezifikationen beschreiben, wie die gesamte Funktionalität eines Featuresoder einer Funktion sicher zu implementieren ist. Es ist eine bewährte Methode, Designspezifikationen mit der funktionalen Spezifikation der Anwendung zu vergleichen – diese sollte Folgendes enthalten:

  • eine genaue und vollständige Beschreibung der beabsichtigten Verwendung eines Featuresoder einer Funktion sowie
  • eine Beschreibung, wie das Feature oder die Funktion auf sichere Weise bereitgestellt werden kann.

SDL-Methode 6: Verringerung der Angriffsfläche

Die Verringerung der Angriffsfläche ist eng mit der Bedrohungsmodellierung verknüpft, auch wenn sie Sicherheitsprobleme von einer anderen Perspektive betrachtet. Sie dient zur Reduktion des Risikos, indem Angreifern weniger Gelegenheit geboten wird, eine potenzielle Schwachstelle auszunutzen. Zur Verringerung der Angriffsfläche gehören das Abschalten oder Einschränken des Zugriffs auf Systemdienste, die Anwendung des Prinzips der geringsten Rechte (Least-Privilege-Principle) sowie gegebenenfalls der Einsatz multipler Verteidigungsschichten.

SDL-Methode 7: Bedrohungsmodellierung

Die Bedrohungsmodellierung wird in Umgebungen eingesetzt, in denen ein signifikantes Sicherheitsrisiko besteht. Sie ermöglicht Entwicklungsteams die Berücksichtigung, Dokumentation und Erörterung der Sicherheitsauswirkungen eines Designsim Kontext der geplanten Betriebsumgebung auf strukturierte Art und Weise. Die Modellierung ermöglicht es auch, Sicherheitsaspekte auf Komponenten- oder Anwendungsebene zu berücksichtigen. Sie ist eine Teamübung, die Programm- und Projektmanager, Entwickler und Tester einbezieht. Außerdem stellt sie den wichtigsten Sicherheitsanalysevorgang in der Softwaredesignphase dar.

Phase Drei: Implementierung

SDL-Methode 8: Verwenden genehmigter Tools

Alle Entwicklungsteams sollten eine Liste genehmigter Tools und der zugehörigen Sicherheitsüberprüfungen – wie Compiler-/Linker-Optionen und -Warnungen – definieren und veröffentlichen. Diese Liste sollte vom Sicherheitsbeobachter für das Projektteam genehmigt werden. Grundsätzlich sollten Sicherheitsbeobachter bestrebt sein, jeweils die neueste Version der Tools zu genehmigen, um neue Funktionen und Schutzmechanismen der Sicherheitstools zum Einsatz zu bringen.

SDL-Methode 9: Verbieten unsicherer Funktionen

Viele vordefinierte Funktionen und APIs sind angesichts aktueller Bedrohungen nicht mehr sicher – Projektteams sollten alle verwendeten Funktionen und APIs analysieren und als unsicher erkannte verbieten. Nachdem die Verbotsliste bestimmt wurde, sollten Projektteams allen Code (ggf. auch übernommenen älteren Code) anhand von Headerdateien (wie banned.h und strsafe.h), mithilfe aktueller Compiler oder Codescanningtools auf verbotene Funktionen hin untersuchen und diese gegebenenfalls durch sichere Alternativen ersetzen.

SDL-Methode 10: Statische Analyse

Projektteams sollten eine statische Analyse von Quellcode durchführen: Diese bietet eine skalierbare Möglichkeit für Sicherheitscodeüberprüfungen und trägt dazu bei, die Einhaltung von Richtlinien für sicheres Kodieren sicherzustellen. Die statische Codeanalyse selbst ist jedoch im Allgemeinen nicht ausreichend, um eine manuelle Codeüberprüfung zu ersetzen.

Das Sicherheitsteam und die Sicherheitsbeobachter sollten die Stärken und Schwächen statischer Analysetools kennen und diese nach Bedarf durch andere Tools oder manuelle Überprüfung ergänzen.

Phase Vier: Überprüfung

SDL-Methode 11: Dynamische Programmanalyse

Die Überprüfung von Softwareprogrammen zur Laufzeit ist erforderlich, um sicherzustellen, dass ein Programm die Funktionalität aufweist, für die es entworfen wurde. Bei diesem Überprüfungsvorgang sollten auch Tools zum Einsatz kommen, die das Verhalten der Anwendung auf Speicherbeschädigung, Probleme mit Benutzerrechten sowie auf andere kritische Sicherheitsprobleme hin überwachen. Im SDL-Prozess werden Laufzeittools wie AppVerifier zusammen mit anderen Techniken wie Fuzzingtests verwendet, um die gewünschten Levels an Sicherheitstests zu erzielen.

SDL-Methode 12: Fuzzingtests

Fuzzingtests sind eine spezialisierte Form der dynamischen Analyse, bei der Programmfehler durch absichtliches Einbringen fehlerhafter oder zufälliger Daten in eine Anwendung verursacht werden (vgl. <kes>2011#5, S. 66). Die Strategie der Fuzzingtests ist abgeleitet von der beabsichtigten Verwendung der Anwendung und der funktionalen wie der Designspezifikation für die Anwendung. Unter Umständen fordert der Sicherheitsbeobachter weitere Fuzzingtests oder eine Bereichserweiterung bestehender Tests.

SDL-Methode 13: Überprüfung von Bedrohungsmodell und Angriffsfläche

In der Regel weicht eine Anwendung signifikant von der funktionalen und der Designspezifikation ab, wie sie in der Anforderungs- und Designphase erstellt wurden. Daher ist es von entscheidender Bedeutung, die Bedrohungsmodelle und die Messung der Angriffsfläche einer Anwendung nach Abschluss der Codeerstellung erneut zu überprüfen. Dies stellt sicher, dass vorgenommene Design- oder Implementierungsänderungen am System berücksichtigt und durch Änderungen entstandene neue Angriffsvektoren überprüft und bekämpft wurden.

Phase Fünf: Veröffentlichung

SDL-Methode 14: Vorfallreaktionsplan

Jede Softwareveröffentlichung, die den Anforderungen des SDL unterworfen ist, muss einen Vorfallreaktionsplan (Incident-Response-Plan) vorsehen. Auch Programme, die zum Zeitpunkt der Veröffentlichung keine bekannten Schwachstellen aufweisen, können im Lauf der Zeit neuen Bedrohungen ausgesetzt sein oder Sicherheitsverwundbarkeiten aufweisen. Der Vorfallreaktionsplan sollte Folgendes enthalten:

  • ein festgelegtes Sustained-Engineering-(SE)-Team oder – falls das Team zu klein für SE-Ressourcen ist – einen Notfallreaktionsplan (Emergency-Response-Plan, ERP), der die geeigneten Mitarbeiter aus Technik, Marketing, Kommunikation und Management benennt, die bei einem Sicherheitsnotfall als Erstkontakte fungieren,
  • Bereitschaftskontakte mit Entscheidungsbefugnis, die entsprechend verfügbar sind (z. B. 24/7),
  • Sicherheitswartungspläne für Code, der von anderen Gruppen in der Organisation übernommen wurde,
  • Sicherheitswartungspläne für lizenzierten Drittanbietercode, einschließlich Dateinamen, Versionen, Quellcode, Drittanbieterkontakten und gegebenenfalls der vertraglichen Genehmigung, Änderungen vorzunehmen.

SDL-Methode 15: Abschließende Sicherheitsüberprüfung

Die abschließende Sicherheitsüberprüfung (Final Security-Review, FSR) ist eine sorgfältige Untersuchung aller Sicherheitsmaßnahmen, die für eine Softwareanwendung vor der Veröffentlichung durchgeführt wird. Der FSR wird vom Sicherheitsbeobachter unter Mitwirkung der normalen Entwicklungsbelegschaft sowie der Sicherheits- und Datenschutz-Beobachter ausgeführt. Es handelt sich dabei weder um eine "Penetrationstest und Patch"-Übung noch bietet der FSR die Gelegenheit, zuvor vernachlässigte oder vergessene Sicherheitsmaßnahmen nachzuholen. In der Regel umfasst die Prüfung eine Untersuchung von Bedrohungsmodellen, Ausnahmeanforderungen, Toolausgaben und Leistungsmessungen im Vergleich zu den zuvor bestimmten Quality-Gates oder Bug-Bars. Der FSR führt zu einem von drei möglichen Ergebnissen:

  • FSR bestanden: Alle durch den FSR-Prozess gefundenen Sicherheits- und Datenschutzprobleme wurden behoben.
  • FSR mit Ausnahmen bestanden: Alle durch den FSR-Prozess gefundenen Sicherheits- und Datenschutzprobleme wurden behoben und/oder alle Ausnahmen zufriedenstellend gemindert – nicht-behebbare Probleme (z. B. Schwachstellen aufgrund problematischer Designaspekte älterer Versionen) werden protokolliert und in der nächsten Version korrigiert.
  • FSR mit Eskalation: Wenn ein Team nicht alle SDL-Anforderungen erfüllt und der Sicherheitsbeobachter und das Projektteam keinen akzeptablen Kompromiss finden, kann der Sicherheitsbeobachter das Projekt nicht genehmigen und das Projekt kann nicht veröffentlicht werden – Teamsmüssen nach Möglichkeit entweder die SDL-Anforderungen zur Produkteinführung erfüllen oder das Problem zur Entscheidung an die Unternehmensführung eskalieren, die dann schriftlich das Risiko mit allen potenziellen Folgen übernimmt.

SDL-Methode 16: Veröffentlichung und Archivierung

Die Veröffentlichung der Software ("Release to Manufacturing" – RTM oder "Release to Web" – RTW) ist vom Abschluss des SDL-Prozesses abhängig: Der zugeordnete Sicherheitsbeobachter muss hierzu (anhand des FSR und anderer Daten) bescheinigen, dass das Projektteam die Sicherheitsanforderungen erfüllt hat. Entsprechend muss der Datenschutzbeobachter für alle Produkte, die mindestens eine Komponente mit der Datenschutz-Risikobewertung (Privacy-Impact-Rating) P1 enthalten, bescheinigen, dass das Projektteam die Datenschutzanforderungen erfüllt hat. Erst dann darf die Software ausgeliefert werden.

Darüber hinaus müssen alle relevanten Informationen und Daten für die Wartung nach der Veröffentlichung archiviert werden. Hierzu gehören sämtliche Spezifikationen, der Quellcode, Binärdateien, "Private Symbols", Bedrohungsmodelle, die Dokumentation, Notfallreaktionspläne, Lizenz- und Wartungsbedingungen für Drittanbietersoftware sowie alle anderen Daten, die für Wartungsvorgänge und den Betrieb nach der Veröffentlichung erforderlich sind.

Optionale Maßnahmen

Optionale Sicherheitsmaßnahmen werden im Allgemeinen ausgeführt, wenn eine Softwareanwendung voraussichtlich in sicherheitskritischen Umgebungen oder Szenarien verwendet wird. Sie werden häufig durch einen Sicherheitsbeobachter im Rahmen von Zusatzanforderungen festgelegt, die für bestimmte Softwarekomponenten eine strengere Sicherheitsanalyse fordern. Die nachfolgend aufgelisteten Methoden sind Beispiele für optionale Vorgänge und sollten nicht als erschöpfende Liste betrachtet werden.

Manuelle Codeüberprüfung

Eine manuelle Codeüberprüfung wird in der Regel durch hochspezialisierte Experten im Anwendungssicherheitsteam und/oder durch den Sicherheitsbeobachter durchgeführt. Auch wenn Analysetools einen wesentlichen Beitrag zum Auffinden und Kennzeichnen von Schwachstellen leisten, sind sie nicht perfekt.

Demzufolge konzentriert sich die manuelle Codeüberprüfung gewöhnlich auf die "kritischen" Komponenten einer Anwendung. Meist wird sie verwendet, wenn sensitive Informationen wie personenbezogene Daten verarbeitet oder gespeichert werden. Auch zur Untersuchung anderer kritischer Funktionen (z. B. kryptografischer Implementierungen) wird sie eingesetzt.

Penetrationstests

Bei Penetrationstests handelt es sich um eine Whitebox- und/oder Blackbox-Sicherheitsanalyse eines Softwaresystems, bei der spezialisierte Sicherheitsexperten die Aktionen eines Angreifers simulieren. Das Ziel besteht darin, durch Kodierfehler, Systemkonfigurationsfehler oder andere Bereitstellungsschwächen verursachte potenzielle Schwachstellen aufzudecken. Penetrationstests werden häufig zusammen mit automatisierten und manuellen Codeüberprüfungen ausgeführt, um eine umfassendere Analyse zu erzielen, als es ohne sie möglich wäre.

Schwachstellenanalyse ähnlicher Anwendungen

Im Internet finden sich zahlreiche angesehene Quellen zu Softwareschwachstellen. In manchen Fällen kann die Analyse von Schwachstellen in ähnlichen Anwendungen Hinweise auf mögliche Design- oder Implementierungsprobleme in der gerade entwickelten Software liefern.

Fazit

Schon eine teilweise Verwendung der hier beschriebenen Techniken wirkt sich in der Regel positiv auf die Sicherheit und den Datenschutz einer in der Entwicklung befindlichen Anwendung aus. Die einfache Orchestrierung von Sicherheitsprozessen zur Verbesserung der Informationssicherheit und des Datenschutzes stellt mehr dar als die Summe der einzelnen Teile.

Statt den Angriffen von "Skriptkiddies" sehen sich Entwickler mittlerweile durchorganisierten Verbrecherbanden mit finanziellem Interesse gegenüber – Cybercrime ist alltäglich, teils entwickelt sich ein regelrechter Cyberwar. Diese Entwicklung der Bedrohungen verlangt dringend nach wirksameren Maßnahmen und strukturierten Ansätzen für die Softwaresicherheit und nicht einen leider noch immer üblichen "Eins-links-eins-rechts-zwei-fallen-lassen"-Ansatz.

Der "Security Development Lifecycle" (SDL) ist ein frei verfügbarer Prozess für die Verbesserung der Softwaresicherheit und des Datenschutzes. Er wurde mittlerweile auf hunderte Softwareprogramme und hunderte von Millionen Codezeilen angewendet. Er besteht aus obligatorischen Maßnahmen, die dem traditionellen Softwareentwicklungsprozess folgen – dennoch ist er flexibel genug, um die Hinzunahme weiterer Richtlinien und Techniken zu ermöglichen, um eine spezielle Softwareentwicklungsmethodik für eine Organisation zu erstellen.

Die Kombination aus Prozess, Schulung und Tools bietet verschiedene Vorteile, wie erhöhte Transparenz, verbesserte technische Kompetenz und sicherere Software sowie adäquate Reaktion. Das hat wiederum ein geringeres Risiko für die Organisation sowie auch für den Benutzer der Software zur Folge und dient somit insgesamt einer Verbesserung der Informations-Sicherheit im Cyberraum. Ist das genug? Nein – aber ein wichtiger Schritt vorwärts, der für alle Organisationen zur Pflicht werden sollte!

Michael Kranawetter ist Head of Information Security sowie Chief Security Advisor der Microsoft Deutschland GmbH.