Das Akronym SDLC steht traditionell für Systems Development Life Cycle. Ein solcher wird etabliert, um Systeme fachgerecht aufbauen, erweitern und betreiben zu können. Durch die verschiedenen Phasen des Kreislaufs sollen Optimierungen in Bezug auf Effizienz und Zuverlässigkeit erlangt und aufrechterhalten werden. Gleichzeitig wird damit aber auch die Möglichkeit geschaffen, Security konsequent einzubringen. Dieser Artikel bespricht das Prinzip des Security Development Lifecycle, der sich auf die Sicherheitsaspekte entsprechender Lösungen fokussiert.

SDLC Kreislauf

SDLC besteht aus einem Kreislauf, der im Minimalen aus den folgenden fünf sich stetig wiederholenden Phasen besteht:

1. Planung
2. Analyse
3. Design
4. Implementierung
5. Unterhalt

Der Kreislauf führt dazu, dass nach dem Unterhalt stets die Planung für die nächste Iteration stattfindet. Damit wird mit SDLC einem klassischen Prinzip der Informationssicherheit Rechnung getragen, das fortwährend durch den US-amerikanischen Kryptologen Bruce Schneier gepredigt wurde:

Sicherheit ist ein Prozess, kein Zustand.

Und in der Tat kann man Sicherheit nicht nur einfach erzeugen und diese nach Erreichen fortan erwarten. Interne und externe Einflüsse können es erforderlich machen, dass die Sicherheit stetig neu erreicht und bewirtschaftet werden muss.

Security Development Lifecycle

Der Security Development Lifecycle soll dabei helfen, die Planung, Umsetzung und Bewirtschaftung von Systemen nachvollziehbar sicher durchführen zu können. Hierzu werden die folgenden sieben Phase etabliert (angelehnt an den von Microsoft propagierten Ansatz):

1. Training
2. Anforderungen
3. Design
4. Implementierung
5. Prüfung
6. Veröffentlichung
7. Reaktion

Es ist zu sehen, dass sich hier im Prinzip die ursprünglichen Phasen des klassischen SDLC wiederfinden. Diese werden jedoch mit Fokus auf die Sicherheit erweitert.

Anforderungen designen und implementieren

Beim Security Development Lifecycle dreht sich eigentlich alles um die Sicherheitsanforderungen. In Phase 2: Anforderungen werden diese eruiert. Dabei werden Fragen beantwortet, wie zum Beispiel:

In Phase 3: Design werden diese losen Anforderungen dann in das konkrete Design für die Lösung miteinbezogen. Frage 1 erfordert zum Beispiel ein Rollen- und Berechtigungskonzept, Frage 2 setzt ein Zugriffs- und Authentisierungskonzept voraus und Frage 3 muss sich mit Verfügbarkeit, Backup/Restore und Business Continuity Management (BCM) auseinandersetzen.

Konnten sämtliche Anforderungen im Design berücksichtigt werden, gilt es diese organisatorisch, konzeptionell und technisch in Phase 4: Implementierung umzusetzen.

Prüfung der Umsetzung

Der Security Development Lifecycle führt mit Phase 5: Prüfung ein wichtiges Werkzeug ein, damit über Sicherheitsanforderungen nicht nur diskutiert wird, sondern diese auch wirklich umgesetzt werden. In diesem Schritt wird nämlich verifiziert, ob die zuvor definierten und implementierten Sicherheitsmechanismen auch wirklich umgesetzt wurden. Dabei werden die Postulationen aus den vorangegangenen Phasen mit dem aktuellen Stand verglichen und Abweichungen dokumentiert. Hierzu bieten sich die klassischen Werkzeuge des Security Testing an. Zum Beispiel:

• Source Code Analyse
• Reverse Engineering
• Vulnerability Scanning
• Penetration Testing
• Config Reviews
• Firewall Rule Reviews
• Konzept Review

Es gibt keine pauschale Definition, mit welchem Ansatz und in welchem Umfang getestet werden soll. Das Ziel einer jeden Analyse soll die Vereinheitlichung von Zuverlässigkeit und Wirtschaftlichkeit sein. Falls zum Beispiel der Quelltext einer Lösung vorhanden ist, ist die Analyse davon zu bevorzugen. Falls nicht, kann auf ein zeitaufwendigeres Reverse Engineering zurückgegriffen oder auf dynamische Tests (z.B. Vulnerability Scanning und Penetration Testing) ausgewichen werden.

Wichtig dabei ist zu verstehen, dass jeder Testmechanismus unterschiedliche Voraussetzungen stellt und Abdeckungen gewährleisten kann. Die Verifikation auf eine Source Code Analyse einzuschränken ist genauso gefährlich, wie sich nur auf einen netzwerkbasierten Vulnerability Scan zu verlassen. Hier ist technisches Verständnis, Erfahrung und Fingerspitzengefühl erforderlich.

Patches, Releases und Vulnerabilities

Sowohl in der Phase der Verifikation als auch während der Bewirtschaftung der etablierten Lösung können sicherheitstechnische Anpassungen erforderlich werden. Dies geschieht aus zwei Gründen:

• Externe Einflüsse: Es werden neue Angriffsszenarien relevant (z.B. neue Angriffstechniken, Geschäftsprozesse, Arbeitsabläufe).
• Interne Einflüsse: Es werden neue Funktionen erforderlich, bestehende Prozesse angepasst oder Schwachstellen in der gegebenen Lösung gefunden.

Damit diese Einflüsse wahrgenommen und zeitnah auf diese reagiert werden kann, muss in regelmässigen Abständen die Bedrohungslage im Rahmen des Risk Managements neu eingeschätzt werden. Der Markt für Angriffswerkzeuge (Techniken, Tools und Exploits) muss im Auge behalten und relevante Veränderungen berücksichtigt werden.

Das Vulnerability Management ist dafür zuständig, Schwachstellen in den eingesetzten Produkten wahrnehmen, dokumentieren und berücksichtigen zu können. Hier werden einerseits verschiedene Quellen bewirtschaftet (z.B. Verwundbarkeitsdatenbanken, Mailinglisten, Social Media), um neu veröffentlichte Schwachstellen frühstmöglich feststellen zu können. Andererseits können mit zusätzlichem Aufwand aktive Programme wie Bug Bounties ins Leben gerufen werden. Das Melden von neu gefundenen Schwachstellen durch Dritte wird entlöhnt, wodurch ein Dialog entstehen und Zeitfenster für einen Missbrauch reduziert werden können.

Das Patch- und Release Management ist zusätzlich dafür zuständig, dass adressierte Schwachstellen durch Bugfixes und neue Versionen eliminiert werden können. Das Vorbereiten, Testen, Ausrollen und Verifizieren dieser Optimierungen muss ebenfalls professionalisiert werden.

Fazit

Mit dem Security Development Lifecycle ist ein mächtiges Werkzeug gegeben, mit dem Sicherheit etabliert und gelebt werden kann. Indem der Lebenszyklus eines Produkts von Beginn weg mit Berücksichtigung der Sicherheitsanforderungen begleitet wird, kann ein gutes Niveau erreicht und gehalten sowie dieses auch geprüft werden.

Es steht ausser Frage, dass dieses Mass an Professionalisierung in die heutige Zeit gehört. Ohne SDLC fusst die Sicherheit einer Lösung in erster Linie auf Glück. Und die Zeit arbeitet konsequent dafür, dass dieses irgendwann ausläuft.

Über den Autor

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

• https://vuldb.com/de/
• https://www.computec.ch/projekte/tractatus/?s=tractatus
• https://www.microsoft.com/en-us/sdl/
• https://www.schneier.com/crypto-gram/archives/2000/0515.html