Secure Software Development Lifecycle, Teil 2 Konzeption und Planung eines SSDL nach BSI

Hier stellen wir das Konzept des sicheren Softwareentwicklungs-Lebenszyklus nach BSI in der zweiten Phase, sprich Konzeption und Planung vor. In der ersten Phase, die wir bereits kennengelernt haben, ging es nämlich nur darum, die Rahmenbedingungen festzulegen.

Anbieter zum Thema

Insider Research

OutSystems

Bundesamt für Sicherheit i.d.Informationstechnik

Im ersten Teil dieser Serie haben wir bereits den Secure Software Development Lifecycle (SSDL) kennengelernt und uns mit der initialen Planung sowie Reifegraden auseinandergesetzt. Bevor wir mit der eigentlichen Umsetzung beginnen können, ist eine detailliertere Planung vonnöten. Im dritten Teil widmen wir uns dann der Einführung des SSDL, dem Testing und dem Betrieb der entwickelten Produkte.

Phase 2: Konzeption und Planung

Die initiale Planung war im Grunde nur darauf bedacht, die Rahmenbedingungen mit dem (potenziellen) Kunden abzustecken. Nun folgt der zweite Planungsteil, der sich in neun Aktivitäten unterteilt, die von der Grobbeschreibung der Anwendung bis hin zur quantitativen Messung der Sicherheit reichen.

Aktivität 1 – Beschreibung der Anwendung

Zunächst sollte das Was geklärt werden: Was will der Kunde, was wollen weitere Stakeholder, was soll die Software leisten und welche Funktionen können diese Anforderungen erfüllen? Bei simplen Standardanwendungen – wie einem statischen Webauftritt für ein einzelnes Projekt – lässt sich diese Aktivität recht fix und grob abhandeln. Das Mapping von Kundenwunsch auf Funktion ist hier weitgehend Routine. Je komplexer das Projekt, desto besser sollten Sie die Grundlagen setzen, um später auch wirklich in Zeit- und Budgetplan zu bleiben.

Aktivität 2 – Datenbehandlungsstrategie

In diesem Schritt klassifizieren Sie die in der Anwendung auftretenden Datenarten (etwa öffentlich, vertraulich etc.) und legen passende Schutzbedarfe fest. Beispielsweise hohen Schutzbedarf für Login-Daten und normalen Bedarf für reine Infotexte.

Aktivität 3 – Rollen- und Berechtigungskonzept

Da Anwendungen in der Regel von mindestens zwei unterschiedlichen Personengruppen genutzt werden, nämlich Nutzer und Betreiber, müssen Rollen definiert werden, die ganz klar festlegen, wer wie mit der Anwendung interagieren darf. Zum Beispiel könnten hier Unternehmenshierarchien als Vorlage für die Abbildung dienen.

Secure Software Development Lifecycle, Teil 1

Umsetzung eines SSDL nach BSI-Empfehlung

Aktivität 4 – Sicherheitsanforderungen überprüfen und ergänzen

Dieser Schritt baut im Wesentlichen auf die Erhebungen aus der initialen Planung und der Beschreibung der Anwendung auf. Sie erarbeiten konkrete Anforderungen, die später auch die Grundlage für die Bedrohungsmodellierung stellen. Für das genaue Vorgehen gibt es unterschiedliche, ausführlich beschriebene Methoden, beispielsweise SQUARE vom Carnegie Mellon Software Engineering Institute, das auch für konkrete Coding-Richtlinien bekannt ist.

Aktivität 5 – Erstellung von Abuse Cases

Use Cases kennen Sie aus der Entwicklung, es werden wünschenswerte Interaktionen zwischen Nutzer und Anwendung beschrieben. Abuse Cases beschreiben hingegen, wie diese einzelnen Use Cases missbraucht werden könnten – und liefern somit einen weiteren Baustein für das Verständnis aller möglichen Bedrohungen und können später als nicht-wünschenswerte Interaktion konkret unterbunden werden.

Aktivität 6 – Bedrohungsmodellierung

Spätestens ab diesem Schritt verlassen Sie die abstrakte Planung steigen in technische Details ein. Bislang haben Sie die Software beschrieben, Schnittstellen, Funktionen und Datenarten identifiziert, Nutzer klassifiziert und so weiter. Auf dieser Basis modellieren Sie nun ganz konkrete Bedrohungen in Zusammenarbeit mit Experten, etwa Software-Architekten und Entwicklern.

Um eine Vorstellung zu bekommen: Ein guter Ausgangspunkt ist beispielsweise die OWASP Top 10, die die häufigsten Bedrohungen auflistet, etwa SQL-Injection-Attacken. Auch das CVE-System liefert den nötigen Detailgrad für den Einstieg.

Bei diesem Prozessschritt wird Wissen aus der Praxis benötigt – auch der hauseigene IT-Betrieb kann hier wertvollen Input liefern. Am Ende des Schrittes sollte eine Liste priorisierter sowie zu billigenden Bedrohungen stehen, die entsprechend abgearbeitet bzw. ignoriert und dokumentiert werden.

Aktivität 7 – Erstellung der Sicherheitsarchitektur

Über die Sicherheitsarchitektur wird das grundlegende Zusammenspiel der Komponenten festgelegt, unter Berücksichtigung aller in dieser Phase bereits gewonnenen Erkenntnisse. Die Relevanz sollten Sie aus der regulären Softwareentwicklung kennen: Die hier beschlossenen Konzepte und dadurch auftretende Risiken können später oft nur unter enormem Aufwand verändert beziehungsweise behoben werden. Ist eine solche Sicherheitsarchitektur einmal entwickelt, kann sie natürlich auch bei zukünftigen Projekten eingesetzt werden und so die vorgelagerten Phasen um einiges verkürzen.

Aktivität 8 – Sicherheitstestplanung

Lange bevor Sie testen, sollten Sie einplanen, was und wie Sie testen werden. Neben technischen Aspekten, die gewisse Testszenarien schlicht voraussetzen, geht es hier auch um Ressourcen wie Personal, Tools und Rechenzeiten. Grundsätzlich sind diese natürlich bereits bei der initialen Planung soweit möglichst einzurechnen, letztlich ist der gesamte SDL-Prozess aber iterativ angelegt – es lohnt sich an etlichen Stellen, mit neuen Erkenntnissen nochmal einen Schritt zurück zu gehen.

Aktivität 9 – Software-Security-Metriken

Auch Sicherheit lässt sich quantitativ messen, über Werte wie die Dauer zwischen Identifikation und Korrektur einer Sicherheitslücke oder den Anteil sicherheitsrelevanter Defekte. Einen Einstieg in das Thema finden Sie, wie so oft, beim OWASP.

Secure Software Development Lifecycle, Teil 3

SSDL-Implementierung, Testing und Nachsorge

(ID:45625493)