Secure Software Development Lifecycle, Teil 3 SSDL-Implementierung, Testing und Nachsorge

Um einen sichere Softwareentwicklungs-Lebenszyklus richtig umzusetzen, bedarf es einiger Planung. Doch damit mit der Implementierung allein ist es noch nicht getan, im Nachgang sind noch weitere Schritte erforderlich.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Windhoff Group

Bundesamt für Sicherheit i.d.Informationstechnik

Im ersten Teil dieser Serie haben allgemeine Rahmenbedingungen und erste Denkanstöße für sichere Software-Entwicklung geliefert. Der zweite Teil drehte sich um die zweite Phase der tiefgreifenden Planung und Konzeption des Secure Software Development Lifecycle (SSDL). Nun widmen wir uns mit Blick auf die Empfehlungen des BSI den übrigen drei Phasen.

Phase 3: Implementierung.

Über die Phase der Implementierung soll sichergestellt werden, dass Sicherheit bei der Umsetzung im „erforderlichen Rahmen“ berücksichtigt wird. Die Phase gliedert sich in vier Aktivitäten: Nutzung von „Security APIs“, also beispielsweise das Einsetzen etablierter Verschlüsselungsbibliotheken, statt der Neuerfindung des Rads.

Beim „sicheren Umgang mit Sourcecode“ geht es um Zugriffsregelungen, definiertes Change Management, sichere Produktionssysteme, Signaturen für Patches und so weiter – im Grunde Basics aus der Entwicklung. Es sollen desweiteren „Secure Coding Standards“ genutzt werden, die etwa bei Kryptographie, Validierung oder Zugriffskontrolle zum Einsatz kommen.

Im Paper selbst finden sich im Anhang entsprechende Richtlinien, ansonsten sind erneut die Development Guidelines der Carnegie Mellon University ein guter Ansatzpunkt. Die letzte Aktivität dieser Phase sind die „Security Pushes“: Diese Microsoft-Errungenschaft dient schlicht dazu, die Sicherheit in bestimmten Phasen der Entwicklung zu priorisieren und das gesamte Team auf einzelne Sicherheitsrisiken anzusetzen – was eben entsprechend eingeplant werden muss.

Phase 4: Testen

Die Testing-Phase unterteilt das BSI-Papier in drei Aktivitäten, die weitgehend selbsterklärend sein dürften: „Security Tests“ der definierten Sicherheitsanforderungen, „Penetrationstests“ aus Angreifersicht und abschließend ein „Final Security Review“, der noch offene Lücken aufführt beziehungsweise abschließend zur Freigabe der Anwendung führt.

Phase 5: Auslieferung und Betrieb

In Phase 5 wird es noch einmal sehr ausführlich, vor allem aber sehr spannend – denn vielerorts wird eine erfolgreich entwickelte und letztlich freigegebene Anwendung mehr oder weniger abgehakt. Das genügt aus Sicherheitserwägungen heraus nicht und wird auch anspruchsvollere Kunden nicht befriedigen.

Secure Software Development Lifecycle, Teil 1

Umsetzung eines SSDL nach BSI-Empfehlung

Die neun Aktivitäten dieser Phase dürften an sich ziemlich selbsterklärend sein. Hier geht es eher darum, ein Bewusstsein für wichtige Aspekte zu schaffen, daher das Ganze wieder in Kurzform:

Aktivität 1 – Sichere Auslieferung der Software

Der Kunde muss die Software so erhalten, dass sie unterwegs nicht manipuliert werden kann; Stichwort Prüfsummen.

Aktivität 2 – Sicherheitsdokumentation

Alle sicherheitsrelevanten Einstellungen, Funktionen und Grundregeln für Nutzung und Betrieb müssen (gegenüber dem Kunden) dokumentiert werden.

Aktivität 3 – Plattformhärtung

Server und Arbeitsplatzrechner, auf denen die Anwendung läuft, sollen gehärtet, also auf das Nötigste abgespeckt und sicher konfiguriert werden – was natürlich gegebenenfalls vom Kunden selbst durchgeführt werden muss.

Aktivität 4 – Security Change Management

Über ein ordentliches Change Management können Sie gewährleisten, das neue Features, Sicherheitspatches und triviale Änderungen Sicherheitsprozesse durchlaufen und entsprechend überwacht klassifiziert, umgesetzt und geprüft werden. Bei größeren Individualprojekten kann es sinnvoll sein, auch den Kunden selbst mit ins Boot zu holen (beispielsweise sollten Patches nicht unbedingt zu Zeiten eingespielt werden, in denen die Anwendung beim Kunden regelmäßig auf Hochtouren läuft).

Aktivität 5 – Security Response

Hier geht es im Wesentlichen um ein verantwortungsvolle Incident Management, also die Überwachung, Überprüfung und Weiterverarbeitung (zum Beispiel durch Weitergabe an das Change Management) jeglicher Störungen und Ausfälle – wofür wiederum ein eigenständiger Prozess aufgesetz werden muss.

Aktivität 6 – 3rd Party Software Vulnerability Monitoring

Alle Komponenten von Dritthersteller müssen ebenfalls überwacht werden. Zur weiteren Lektüre: Security Alerts auf GitHub erledigen genau das für Open-Source-Bibliotheken.

Aktivität 7 – Sichere Standardkonfiguration

Bei Auslieferung der Software muss auf sinnvolle, sichere Defaults geachtet werden, also beispielsweise, dass neue Nutzer standardmäßig nur minimale Rechte haben und keine unsicheren Standardpasswörter verwendet werden.

Aktivität 8 – Web Application Firewall

Dieser Punkt ist eindeutig sehr speziell auf Web-Anwendungen bezogen, generell ist aber der Einsatz einer Firewall sinnvoll. Dies obliegt natürlich wieder meist dem Kunden selbst, der Entwickler sollte aber zumindest entsprechende Dokumentationen und Empfehlungen mitliefern, sofern die Verträge nicht sowieso die vollständige Inbetriebnahme vorsehen.

Aktivität 9 – Wartung

Gleich ob lokale Wartung durch den Kunden oder Fernwartung über einen Servicevertrag, die Arbeiten müssen selbstverständlich ebenfalls sicher durchgeführt werden. Das heißt, es muss ein Berechtigungskonzept vorliegen, Arbeiten und handelnde Personen müssen protokolliert werden und natürlich sollten technische Maßnahmen getroffen werden, dass die Arbeiten auch wirklich nur unter diesen kontrollierten Bedingungen stattfinden können (bei Fernwartung etwa über entsprechend konfigurierte Firewalls).

SDL als andauernder Prozess

Vielleicht ist es Ihnen an einigen Stellen aufgefallen: Immer wieder werden insbesondere in den Planungsphasen Daten erhoben, die in früheren Schritten hätten nützlich sein können. Und mindestens ab Auftragserteilung sollte man SSDL als iterativen Prozess betrachten. Natürlich sind zunächst allgemeine Management-Meetings vonnöten, um Konzept und Ressourcen zu entwickeln und dann in die technischen Details zu gehen.

Mit den technischen Details mehren sich dann aber häufig die Wünsche nach Budget-Aufstockung. Anders ausgedrückt: Mit der entsprechenden Erfahrung lässt sich der Secure Software Development Lifecycle in Projekten vielleicht Wasserfallmodell-artig umsetzen, angemessener scheint mindestens abseits aller Routine aber der agile Ansatz.

Eines sollte selbstverständlich sein: Auch wenn das BSI-Paper nicht explizit darauf eingeht, sollte man nach Abschluss der Entwicklung und nach Auslaufen etwaiger Wartungsverträge Ressourcen für eine Lessons-Learned-Dokumentation einplanen, um bei künftigen Projekten effizient daraus lernen zu können. Aber planen Sie dies von vorneherein mit ein! Ressourcen für bereits an Kunden übergebene Projekte zu bekommen, fällt wohl in den Bereich der reinen Theorie.

Secure Software Development Lifecycle, Teil 2

Konzeption und Planung eines SSDL nach BSI

(ID:45625802)