Was ist der Secure Software Development Lifecycle (Secure SDLC)?

Einige Praktiken zur Verbesserung der Softwaresicherheit

Bevor wir uns eingehend damit beschäftigen, wie sich die Sicherheit in den SDLC integrieren lässt, sollten wir klarstellen, was in diesem Kontext mit „Sicherheit“ gemeint ist. Deshalb beschreiben wir im Folgenden kurz einige Praktiken, die vielerorts bereits in der einen oder anderen Form genutzt (oder zumindest in Erwägung gezogen) werden. Diese Liste ist nicht vollständig und soll nur veranschaulichen, welche Arten von Aktivitäten die Softwaresicherheit stärken können.

Statische Analyse

Bei einer statischen Analyse wird der Quellcode gescannt, um Fehler und Sicherheitslücken aufzudecken. Das geschieht normalerweise in einem automatisierten Prozess, der Infrastructure-as-Code (IaC), Anwendungscode und andere Softwareprojekte nach bekannten, für unsicheren Code typischen Mustern durchsucht, damit die Entwicklerteams diese beheben können, bevor die ersten Endnutzer mit der Software in Berührung kommen.

Sicherheitsscan

Ähnlich wie die statische Analyse ist auch der Sicherheitsscan in der Regel ein automatisierter Prozess, doch hier wird nicht nur die gesamte Anwendung, sondern auch die ihr zugrunde liegende Infrastruktur nach Sicherheitslücken und Fehlkonfigurationen durchforstet. Ein Sicherheitsscan kann zur Analyse der Anfälligkeit für XSS (Cross-Site-Scripting) oder Port-Scan-Angriffe oder auch zur Suche nachContainerschwachstellen durchgeführt werden (um nur einige Beispiele zu nennen).

Codereview

Automatisierte Scans sind zwar nützlich, doch es ist immer empfehlenswert, Code vor der Überführung in eine Produktionsumgebung auch von Menschen inspizieren zu lassen. Die meisten Entwicklerteams führen bereits Codereviews durch, um logische und Programmierfehler zu identifizieren. Wenn sie dabei auch an die Sicherheit denken, kann ein Codereview einen wichtigen Beitrag dazu leisten, dass auch seltenere Sicherheitslücken gar nicht erst in den produktiv genutzten Quellcode gelangen.

Penetrationstests

Penetrationstests sind ein deutlich aufwendigeres Verfahren, für das ein Cybersicherheitsexperte damit beauftragt wird, die Sicherheit der Produktionsumgebung eines Unternehmens zu testen. Ein Penetrationstester darf alle Methoden, von der Schwachstellenanalyse bis zu echten Exploits, nutzen, um zu ermitteln, welche Probleme die internen Sicherheitsteams bei ihren eigenen Tests übersehen haben, und sie mit einem klaren Bericht auf diese hinzuweisen.

Bug Bounties

Eine neuere Methode, die Penetrationstests in gewisser Weise ähnelt, sind sogenannte Bug Bounties. Damit werden Endnutzer ermutigt (und dafür belohnt), dass sie Sicherheitslücken, die sie finden, dem Softwarehersteller melden, statt sie zur persönlichen Bereicherung auszunutzen.

Schulungen

Es sollte nicht unterschätzt werden, wie nützlich die kontinuierliche Sensibilisierung der Benutzer für Sicherheitsfragen ist. Die Cybersicherheitslage ändert sich ständig. Viele der Empfehlungen und Fachkenntnisse, die vor zehn Jahren relevant waren, sind heute nicht mehr aktuell – und das Wissen, dass wir heute vermitteln, wird in zehn Jahren vermutlich ähnlich überholt sein. Regelmäßige Sicherheitsschulungen können einen entscheidenden Beitrag dazu leisten, der wichtigsten Ursache von Sicherheitsverstößen entgegenzuwirken: Benutzerfehlern.

Der (sichere) Softwareentwicklungszyklus

Die Entwicklung von Sicherheitsmaßnahmen sollte in den Softwareentwicklungszyklus eingewoben und nicht auf ihn aufgesetzt werden. Es geht also nicht darum, einen „Sicherheitsschritt“ anzuhängen oder einzuschieben, sondern darum, Best Practices und Tools auszuwählen, die in den bereits vorhandenen Schritten des SDLC eingesetzt werden können (und sollten). Wenn sicherheitsfördernde Maßnahmen wie die Einbeziehung von Stakeholdern aus dem Sicherheitsteam, die Nutzung automatisierter Tools oder die Sensibilisierung der Benutzer als Verbesserungen des SDLC betrachtet werden und nicht als weitere Punkte, die abgehakt werden müssen, ist die Chance viel besser, dass sie dort Bestand haben und, was noch wichtiger ist, ihren Zweck erfüllen.

1. Anforderungen

   In der ersten Phase des SDLC definieren Sie, was genau das Problem ist, welche Sicherheitsanforderungen beachtet werden müssen und anhand welcher Kriterien Sie später entscheiden werden, ob diese Anforderungen erfüllt sind. Das ist der Punkt, an dem Berichte über Bugs und Sicherheitslücken sowie Bitten um zusätzliche Features von Supporttickets zu Teilen eines Projekts werden. Im Kontext eines sicheren Softwareentwicklungszyklus ist die Setzung der richtigen Prioritäten die größte Herausforderung in diesem Schritt. Deshalb sollten Sie Mitglieder Ihres Sicherheitsteams in diese Diskussion einbeziehen, um besser beurteilen können, wie sich jedes behobene Problem und jedes neue Feature auf die Sicherheit auswirken wird.

2. Planung

   Nachdem Sie das Problem identifiziert haben, gilt es zu ermitteln, wie es gelöst werden kann. In der Planungsphase entscheiden Sie also, was entwickelt werden soll. Wie bei der Ermittlung der Anforderungen sollten Sie auch hier Meinungen und Feedback von Mitgliedern des Sicherheitsteams einholen, um sicherzustellen, dass die geplante Lösung das Problem auf eine sichere Art und Weise behebt und gleichzeitig nützlich für Ihre Kunden ist.

3. Entwicklung

   Wenn die Sicherheitsanforderungen definiert sind, muss als Nächstes ermittelt werden, wie die angestrebte Funktionalität in der Anwendung umgesetzt werden kann. Aus der Perspektive der Softwarearchitektur betrachtet bedeutet das in der Regel, dass eine völlig neue Lösung von Anfang bis Ende entwickelt werden muss. Welche Systeme werden davon betroffen sein? Welche Services müssen erstellt oder verändert werden? Wie werden Benutzer dieses Feature nutzen? Dabei sollte es selbstverständlich sein, dass das Design nicht nur von anderen Mitgliedern des Entwicklerteams, sondern auch vom Sicherheitsteam überprüft und angenommen wird, damit etwaige Schwachstellen identifiziert werden können. In diesen ersten drei Phasen spielt die Kommunikation eine entscheidende Rolle, denn ohne eine enge Zusammenarbeit besteht die Gefahr, dass Sicherheitsprobleme erst viel zu spät erkannt werden.

4. Implementierung

   In dieser Phase wird das Design zur Realität. Die Entwürfe werden in Quellcode umgewandelt und dabei können und sollten einige der oben erwähnten Praktiken zur Verbesserung der Softwaresicherheit eingesetzt werden. Die statische Analyse ist eine einfache und kostengünstige Methode, die bei jedem Commit oder Push eingesetzt werden kann, um den Entwicklerteams nahezu in Echtzeit Feedback über die Sicherheit des Codes zu geben, den sie schreiben.

   Wenn die Programmierung abgeschlossen ist und der Codereview beginnt, sollte das damit betraute Team die erforderlichen Sicherheitsschulungen absolviert haben, um sowohl logische Fehler als auch potenzielle Sicherheitsprobleme zu erkennen. In einem gut funktionierenden Unternehmen sollten alle Mitarbeitenden – und nicht nur die Mitglieder des Sicherheitsteams – sich für die Sicherheit verantwortlich fühlen, genau wie das bezüglich der Produktqualität bereits üblich ist.

5. Tests und Bereitstellung

   Nachdem der Code entwickelt und überprüft wurde, sollte die Lösung gründlich getestet und dann veröffentlicht werden. An dieser Stelle sollten Tools eingesetzt werden, die gründlichere, zuverlässigere Sicherheitsscans ermöglichen, um die Sicherheit der neuen Anwendung auf Herz und Nieren zu prüfen. Wenn der Umfang der neuen Funktionalität dies rechtfertigt und die erforderlichen Ressourcen verfügbar sind, ist dies auch ein guter Zeitpunkt für manuelle Sicherheitstests. Wenn dabei Sicherheitslücken aufgedeckt werden, sollten die vorhandenen automatisierten Tools so aktualisiert werden, dass sie diese finden, falls sie in einer späteren Produktversion erneut auftauchen.

6. Wartung

   Ihre Arbeit an einer Softwarelösung endet nicht mit deren Veröffentlichung. Sie muss gehegt und gepflegt werden, wenn sie langfristig einwandfrei funktionieren soll. Vielleicht werden einige der genutzten Ressourcen aktualisiert oder ersetzt, Bugs gemeldet oder Sicherheitslücken entdeckt. Traditionell gilt die Wartung als die Phase, in der Programmierfehler identifiziert und behoben werden, aber in dieser Phase werden vermutlich auch Sicherheitslücken zutage treten.

   Es ist wichtig, sich keinen Illusionen hinzugeben, dass einmal als sicher eingestufter Code für immer sicher bleibt. Die Sicherheitslage ändert sich ständig und neue Bedrohungen, von Risiken in der Lieferkette bis hin zu Zero-Day-Exploits, können jederzeit auftreten. Deshalb ist ein Prozess zur umgehenden Identifizierung und Behebung neuer Probleme ein wichtiger Bestandteil eines sicheren Softwareentwicklungszyklus.

7. Zurück zu Schritt 1

   Denken Sie daran, dass Secure SDLC ein Zyklus und kein einmaliger Prozess ist. Wenn Sie am Ende angekommen sind, geht es wieder von vorn los. Für jeden Fehler, jeden Verbesserungsvorschlag und jede Sicherheitslücke, die beim Testen oder in der Wartungsphase zutage treten, beginnt die Ermittlung der Anforderungen für eine neue Runde. Die sichere Softwareentwicklung sollte in der Praxis ein ständiger Kreislauf fortlaufender Veränderungen sein.

Fazit: Die nächsten Schritte

Sie können die Sicherheit auf unzählig viele verschiedene Arten in Ihren derzeitigen Softwareentwicklungszyklus integrieren, aber es gibt einige robuste Rahmenwerke, an denen Sie sich orientieren können, damit Ihre Secure-SDLC-Initiativen den größtmöglichen Erfolg erzielen. Deshalb empfehlen wir Ihnen, die folgenden Ressourcen als Anregung und Anleitung zu nutzen, wenn Sie die Sicherheit in Ihren Softwareentwicklungsprozess einflechten.

OWASP SAMM

Das OWASP Software Assurance Maturity Model (SAMM) ist der Nachfolger des OWASP Comprehensive, Lightweight Application Security Process (CLASP). Dieses robuste Modell bietet klare Anleitungen für die Integration von Sicherheitspraktiken in den Softwareentwicklungsprozess und hebt dabei besonders hervor, dass die Sicherheitsmaßnahmen an das Risikoprofil der jeweiligen Organisation angepasst werden müssen.

NIST SSDF

Das NIST Secure Software Development Framework (SSDF) ist eine Suite grundlegender Praktiken für die Entwicklung sicherer Software, die auf Best Practices verschiedener renommierter, sicherheitsorientierter Organisationen (darunter auch OWASP) basieren. Das NIST SSDF spaltet den Softwareentwicklungszyklus in die folgenden vier Kategorien auf, die alle zur Verbesserung des Sicherheitsniveaus der Organisation beitragen sollen:

• Vorbereitung der Organisation: Sorgen Sie dafür, dass Ihre Mitarbeitenden, Prozesse und Technologien auf die sichere Softwareentwicklung vorbereitet sind – sowohl auf Unternehmensebene als auch in den einzelnen Entwickler- oder Projektteams.
• Schutz der Software: Schützen Sie sämtliche Softwarekomponenten vor Manipulationen und unbefugtem Zugriff.
• Erstellung sicherer Software: Erstellen Sie sichere Software mit minimalen Schwachstellen in den veröffentlichten Versionen.
• Reaktion auf Schwachstellen: Identifizieren Sie die verbleibenden Schwachstellen und leiten Sie angemessene Maßnahmen ein, um diese zu beheben und zu verhindern, dass zukünftige Softwareversionen ähnliche Schwachstellen enthalten.