Softwareentwicklung: In vier Schritten zu Sicherheit von Anfang an

In vielen Softwareprojekten ist Sicherheit eine nicht funktionale Anforderung, die implizit vom Auftraggeber eingefordert wird. Auf Sätze wie, "Das ist doch selbstverständlich, dass die Anwendung sicher sein muss" trifft man bei einer Anforderungsanalyse sehr häufig. Aber was genau bedeutet "sicher" und wie erreicht man das geforderte Maß an Sicherheit? Im folgenden Blogeintrag stellt viadee IT-Security Consultant Martin Müller ein Vorgehensmodell vor, das sich sowohl für agile als auch klassische Projekte eignet und sich am Security Development Lifecycle (SDL) von Microsoft orientiert.

1. Die Analyse: Wie sicher soll es denn nun sein?

Am Anfang eines Softwareprojektes, egal ob klassisch oder agil, gibt es immer zumindest eine grobe Vision für ein Produkt oder die zu erstellende Software. Dabei hat der Auftraggeber bzw. Product Owner bereits die Idee in welchem Umfeld die Software eingesetzt werden soll und welche Art von Daten zukünftig verarbeitet werden sollen. Ein Beispiel ist ein Webportal, in dem Kunden einer Versicherung eine Übersicht über ihre Verträge erhalten. Sie können im Portal bestimmte Angelegenheiten, wie z. B. Adressänderungen online durchführen können. Bereits anhand dieser kurzen Beschreibung kann man den Schutzbedarf der Anwendung und ihrer Daten entsprechend einstufen. Das BSI schlägt hierfür im Rahmen des IT-Grundschutzes die sogenannte Schutzbedarfsfeststellung vor, die jeweils für die drei primären Schutzziele, Vertraulichkeit, Integrität und Verfügbarkeit durchzuführen ist. Für jedes dieser Schutzziele sieht das BSI die drei Schutzbedarfskategorien "normal", "hoch" oder "sehr hoch" vor und bietet einen exemplarischen Fragenkatalog zur Einstufung der Anwendung an.

Auf Basis des ermittelten Schutzbedarfs können im Projekt frühzeitig entsprechende Aufwände und Maßnahmen zu dessen Erreichung eingeplant werden. So können viele Sicherheitsanforderungen bereits beim Design oder der Architektur der Anwendung adressiert werden. Doch welche konkreten Anforderungen ergeben sich aus dem ermittelten Schutzbedarf? Hierfür liefert das IT-Grundschutz-Kompendium des BSI einen guten Startpunkt. Dort gibt es für diverse Bausteine wie z.B. Betrieb (OPS), Anwendungen (APP) oder Net­ze und Kom­mu­ni­ka­ti­on (NET) Sicherheitsanforderungen die in die Kategorien "Basis-Anforderungen", "Standard-Anforderungen" und "Anforderungen bei erhöhtem Schutzbedarf" aufgeteilt sind. Grundsätzlich gilt hierbei, dass die Basis- und Standard-Anforderungen bereits für den Schutzbedarf "normal" umgesetzt werden sollten. Für den Schutzbedarf "hoch" ist die zusätzliche Umsetzung der Anforderungen bei erhöhtem Schutzbedarf sinnvoll. Bei Schutzbedarf "sehr hoch" ist darüber hinaus eine Analyse der Bedrohungen zur Identifikation von individuellen Maßnahmen erforderlich.

2. Das Design: Wie geht es weiter?

Nachdem die Sicherheitsanforderungen definiert sind, erfolgt in der Regel zumindest ein grobes Design der geplanten Zielarchitektur der Anwendung. Viele Anforderungen haben einen maßgeblichen Einfluss auf Architekturentscheidungen und müssen daher frühzeitig berücksichtigt werden. An dieser Stelle empfiehlt es sich, die geplante Architektur auf die Einhaltung der Sicherheitsanforderungen zu überprüfen. Dafür bietet sich z. B. eine Bedrohungsanalyse an. Aber auch bei der fachlichen Spezifikation sollten die Sicherheitsanforderungen einfließen. Dabei ist es egal, ob es sich um ein klassisches Projekt mit einem ausführlichen Pflichtenheft oder ein agiles mit User Stories handelt. In beiden Fällen haben Sicherheitsanforderungen häufig Folgen für Dialoge, Benutzerführung oder Geschäftsprozesse. Dies kann von einer zusätzlichen 2-Faktor-Authentifizierung für bestimmte Aktionen bis zur asynchronen Anbindung von Backendsystemen über Messaging-Queues und den damit verbundenen Auswirkungen auf die Benutzerinteraktion führen.

Sollte es im Rahmen von neuen, fachlichen Anforderungen im Projekt zu Änderungen an der Architektur kommen und z. B. ein weiteres Backendsystem angebunden werden, muss erneut eine Bedrohungsanalyse durchgeführt werden. Dies soll sicherstellen, dass die Sicherheitsanforderungen weiterhin eingehalten werden oder zusätzliche Maßnahmen eingeplant werden, um die Sicherheitsanforderungen zu erfüllen.

3. Die Implementierung: Und während der Entwicklung?

Grundsätzlich sollten Entwickler immer die typischen Bedrohungen für Anwendungen, speziell Webanwendungen kennen und entsprechend gut geschult sein. Darüber hinaus sollten sie über die Sicherheitsanforderungen für die zu erstellende Anwendung informiert sein, um bei der Umsetzung darauf zu achten. Dadurch sind sie in der Lage, die fachlichen Anforderungen kritisch zu hinterfragen und ggf. frühzeitig fehlende oder inkonsistente zu erkennen (z. B. für Berechtigungsprüfungen oder Eingabevalidierungen) und die notwendigen Informationen bei der Fachseite einzufordern. Gerade beim agilen Vorgehen mit Scrum bieten User Story-Reviews den idealen Rahmen, um ungenaue oder fehlende Spezifikationen zu erkennen und zu adressieren. Spezielle Sicherheitsanforderungen sollten in den User Stories als Akzeptanzkriterien erfasst werden, damit bei der Entwicklung und beim Test entsprechend darauf geachtet wird.

Als Grundlage für die sichere Softwareentwicklung sollten allen Beteiligten die 15 Prinzipien für eine sichere Softwareentwicklung bekannt sein. 

Darüber hinaus gibt es beim entwickelten Quellcode diverse Metriken, die automatisiert erfasst und kontinuierlich gegen im Vorfeld definierte Schwellwerte geprüft werden sollten. Dazu gehören die durch statische Codeanalysewerkzeuge wie z. B. Find Security Bugs gefundenen Sicherheitsfehler genauso, wie Schwachstellen in den verwendeten Bibliotheken, die von Tools wie beispielsweise dem OWASP Dependency Check gemeldet werden. Weitere Metriken, die die generelle Codequalität widerspiegeln runden hier das Gesamtpaket ab. In unverständlichen und schlecht wartbaren Quellcode schleichen sich sehr schnell Sicherheitsfehler ein. Daher sind automatisierte Sicherheits- und Qualitätsprüfungen unabdingbare Bestandteile im Continous Integration Prozess. Builds sollten frühzeitig fehlschlagen, sobald die vorher definierten Schwellwerte überschritten werden.

Mit etwas Aufwand lassen sich neben der statischen Codeanalyse auch dynamische Tests automatisieren. Der OWASP Zed Attack Proxy (ZAP) bietet hierfür eine REST-Schnittstelle an, mit der Anwendungen automatisiert auf bekannte Schwachstellen überprüft werden können.

Ein weiterer Baustein bei der Entwicklung sicherer Software sind automatisierte Tests mit einer hohen Testabdeckung. Diese helfen den Entwicklern, entdeckte Sicherheitsprobleme im eigenen Quellcode und in verwendeten Bibliotheken zeitnah zu beseitigen und ggf. in Minuten eine neue, gepatchte Version der Software in Produktion zu bekommen. Die Alternative wären langwierige manuelle Tests oder der bekannte Sprung ins kalte Wasser. "Wir haben ja nur eine verwendete Bibliothek durch eine neue Version ersetzt, da dürfte eigentlich nichts schief gehen" sind Sätze, die man in solchen Fällen häufig hört. Eine ausreichende Anzahl an automatisierten Tests ermöglichen es, dabei möglichst wenig dem Zufall zu überlassen. Automatisierte Oberflächentests können außerdem im Rahmen der dynamischen Sicherheitstests wiederverwendet werden und liefern so Input für die entsprechenden Tools.

4. Testing: Wie wird getestet?

Neben den automatisierten Tests im Rahmen der Entwicklung ist es sinnvoll, zusätzliche manuelle Sicherheitstests zu etablieren. Auch die besten Werkzeuge finden nicht alle Fehler. Gerade fachliche Sicherheitslücken, wie z. B. ein, durch den Benutzer manipulierbaren Bezahlvorgang, sind für automatisierte Tools schwierig zu erkennen. Dafür müssten sie die fachlichen Anforderungen verstehen können. Aus diesem Grund sind regelmäßige manuelle Sicherheitstests zu empfehlen. Bei agilen Projekten bietet es sich an, jede fertiggestellte User Story im Nachgang oder sogar im Rahmen der Definition of Done einem kurzen, manuellen Sicherheitstest zu unterziehen. Für die Tester ist u. a. der OWASP Application Security Verification Standard (ASVS) mit den dort beschriebenen Prüfungen ein guter Leitfaden zur Durchführung dieser Sicherheitstests.

Trotz aller bisher erwähnten Maßnahmen zur Entwicklung von sicherer Software ist ein zusätzlicher, durch externe Spezialisten durchgeführter Penetrationstest unabdingbar. Dieser sollte, sofern alle anderen Maßnahmen nach bestem Wissen und Gewissen durchgeführt wurden, nur noch Kleinigkeiten finden. Diese sollten entweder schnell zu beheben sein oder nur ein geringes Risiko darstellen, welches akzeptiert werden kann. Aber auch hier gilt es, diesen Test nicht eine Woche vor der geplanten Produktivnahme der Software einzuplanen. Sollten wider Erwarten einmal schwerwiegende Sicherheitsmängel festgestellt werden, wird die Behebung dieser innerhalb weniger Tage eine sportliche Herausforderung für alle Projektmitglieder.

FAZIT

Sichere Software ist keine Zauberei. Aus Sicht der IT-Sicherheit ist sie imminent. Wichtig ist, dass alle Beteiligten an einem Strang ziehen und Sicherheit nicht als etwas verstanden wird, dass am Ende der Entwicklung durch einen Pentester in die Anwendung hineingetestet wird. Vielmehr lässt sich mit einer Handvoll gezielter Maßnahmen, die von Beginn an in ein Entwicklungsprojekt integriert sind und von allen Stakeholdern mitgetragen werden, ein hohes Sicherheitsniveau erreichen.

Der nächste Schritt: Unser Seminar IT-Sicherheit für Entwicklerteams

Wenn Sie oder Ihr Team sich tiefer mit dem Thema sichere Softwareentwicklung beschäftigen möchten, dann empfehlen wir unser . In zwei ganzen bzw. vier halben Tagen vermitteln wir die Grundlagen der IT-Sicherheit — zusammen mit vielen Tipps und Tricks aus der Praxis. Das Seminar findet auf Anfrage und auf Ihre Bedürfnisse angepasst bei Ihnen im Haus, online oder an unseren Standorten in Münster, Köln und Dortmund statt.