Es vergeht keine Woche, in der die Medien nicht von neuen, sicherheitskritischen Softwareproblemen berichten. Die grossen Software-Hersteller veröffentlichen im Monatstakt ganze Fluten wichtiger Updates. Weshalb ist es trotz der riesigen Fortschritte in der IT-Welt immer noch so schwierig sichere Software zu entwickeln?
Sicherheit ist kein Feature
Software-Sicherheit ist schwer fassbar, denn sie ist nicht auf den ersten Blick erkennbar. Leider ist es mit ihrer Abwesenheit genauso. Auch wenn uns Schlösser, grüne Ampeln und andere grafische Elemente zuweilen Sicherheit vorgaukeln, können wir diese in den seltensten Fällen wirklich beurteilen.
Diese Unschärfe macht es schwierig, die Sicherheit in der Softwareentwicklung zu adressieren. Für funktionale Anforderungen lassen sich klare Tests durchführen: Stimmt die Berechnung, wird oben links ein roter Knopf angezeigt, usw. Aber wie testet man die Sicherheit? Selbstverständlich kann man bekannte Angriffsmuster anwenden, oder die Anwendung mit Zufallseingaben bombardieren (sogenanntes "fuzzing"). Dazu gibt es auch entsprechende Werkzeuge. Nur stellt auch das nicht sicher, dass ein kreativer Angreifer keine übersehene Schwachstelle mehr findet. Eine weitere Schwierigkeit ist, dass die Sicherheit im Gegensatz zu einer definierten Programmfunktion nie fertig implementiert ist. Der Softwareentwickler kann nicht sagen: "So, Sicherheit ist drin, nun arbeite ich an weiteren Funktionen". Vielmehr steigt mit jeder zusätzlichen Funktion das Risiko neue sicherheitsrelevante Fehler einzubauen.
Sicherheit ist ein Prozess
Das Thema Sicherheit muss deshalb nicht nur bei der Entwicklung, sondern während des gesamten Lebenszyklus einer Software mit berücksichtigt werden. Man spricht dabei vom "Secure Software Development Lifecycle", kurz S-SDLC. Der S-SDLC reichert die Schritte des normalen Entwicklungszyklus mit Kontrollen an, die gewährleisten, dass die Sicherheit von Anfang bis Schluss mit einbezogen wird:
Anforderungen: Bereits beim Erstellen des Pflichtenhefts sollte man sich Gedanken zu den Sicherheitsanforderungen machen: Gibt es sensible Daten die geschützt werden müssen? Kann ein Missbrauch zu grossen Schäden führen? Solche Fragen werden durch eine Risikoanalyse beantwortet. Daraus lassen sich anschliessend die Sicherheitsanforderungen definieren.
Design: In dieser Phase müssen die Sicherheitsanforderungen in der Architektur und dem Design berücksichtigt werden. So sollte zum Beispiel die Wahl der zu verwendenden Technologien wie Programmiersprachen, Bibliotheken, etc. auf die Anforderungen abgestimmt sein.
Implementation: In "Secure Coding" geschulte Entwickler reduzieren die Wahrscheinlichkeit von sicherheitskritischen Fehlern signifikant. Deshalb ist es wichtig, dass entsprechende Ausbildungen immer wieder durchgeführt werden. Geschulte Entwickler kennen potentielle Fehlerquellen und vermeiden triviale Fehler, weil sie wissen worauf zu achten ist. Spezifische Werkzeuge unterstützen den Entwickler dabei. Sie erkennen bekannte Fehlermuster und geben eine entsprechende Warnung aus (statische Code-Analyse). Die Entwickler brauchen das nötige Wissen und die Fähigkeiten, diese Werkzeuge richtig einzusetzen. Sie müssen die Warnungen verstehen und entsprechende Massnahmen treffen, aber auch ihre Grenzen kennen. Kontinuierliche Code-Reviews steigern die Qualität zusätzlich.
Qualitätssicherung/Testen: Vor Auslieferung oder Inbetriebnahme der Software muss geprüft werden, ob die definierten Sicherheitsanforderungen erfüllt und keine Sicherheitslücken mehr vorhanden sind. Dazu gibt es verschiedene Methoden, die je nach Technologie, vorhandenen Werkzeugen und Wissen zur Anwendung kommen. Man unterscheidet zwischen automatisierten Tests (Dynamic Scanning, Fuzzing) und manuellen Penetrationstests. Dabei versucht ein erfahrener Tester Schwachstellen in der Software zu finden und auszunutzen. Automatisierte Tests führen rasch zu einem Resultat und sind kostengünstig. Die Qualität und Tiefe eines manuellen Tests ist bisher jedoch unerreicht. Der Mensch ist einem automatischen Werkzeug immer noch überlegen. Durch seine Erfahrung kann er die Funktion einer Softwareanwendung besser erfassen und potentielle Schwachstellen finden. Möglicherweise ändert sich das jedoch in Zukunft mit dem Fortschritt in der künstlichen Intelligenz.
Inbetriebnahme: Selbst wenn bis zu diesem Punkt alles richtig gemacht wurde, können Fehler bei der Inbetriebnahme die Sicherheit gefährden. So könnte die Anwendung durch Fehler in der Betriebssystem-Konfiguration oder der Zugriffskontrolle komplett umgangen werden und einem unerlaubten Zugriff auf sensitive Daten ermöglichen. Oder im Fall einer Web-Anwendung können durch fehlende oder falsch konfigurierte SSL/TLS Verschlüsselung vertrauliche Daten auf dem Netzwerk abgehört werden. Deshalb empfiehlt es sich in dieser Phase ein Review der Server- und Netzwerk-Konfiguration durchzuführen.
Die Zukunft?
Das Sicherheitsbewusstsein bei den Softwareherstellern ist in den letzten Jahren stark gewachsen. So hat zum Beispiel Microsoft mit ihrer "Trustworthy Computing Initiative" in den letzten 14 Jahren viel in sichere Software und Systeme investiert. Moderne Programmiersprachen und Frameworks lassen gewisse Fehler inzwischen gar nicht mehr zu. Zudem werden die Entwicklungswerkzeuge intelligenter und warnen vor potentiellen Fehlern bevor es zu spät ist.
Warum gibt es trotzdem noch so viele kritische Sicherheitsprobleme und monatliche Software-Updates? Ein Grund ist der weitverbreitete Einsatz von teilweise jahrzehntealter Software. Diese entstand in einer Zeit, in der das Sicherheitsbewusstsein noch gering und die Entwicklungswerkzeuge weniger ausgereift waren. Auch in den aktuellsten Betriebssystemen steckt zum Teil noch Programmcode aus den achtziger und neunziger Jahren. Wir sind momentan in einer Abbau-Phase dieser Hypothek von unsicherer "Legacy Software". Dies zeigen die zahlreichen Initiativen, welche die Softwarehersteller ins Leben gerufen haben. "Bug Bounty Programme" zum Beispiel belohnen das Auffinden von Programmfehlern mit bis zu mehreren tausend Dollar.
Die Ausbildung von Entwicklern bleibt jedoch ein zentrales Element der sicheren Softwareentwicklung. Daran wird und soll sich in der nahen Zukunft nichts ändern. Zusammen mit der übergreifenden Begleitung und Überprüfung der Sicherheitsaspekte während des ganzen Entstehungs- und Lebenszyklus einer Software (S-SDLC), sorgt dies in Zukunft für ruhigere "Patch-Days".