Secure Software Development Lifecycle, Teil 1 Umsetzung eines SSDL nach BSI-Empfehlung

Ein Secure Software Development Lifecycle, kurz SSDL, setzt einen kompletten Sicherheitsprozess über die eigentliche Software-Entwicklung und sollte in keinem Unternehmen fehlen. Einerseits, um teure Behebung von Sicherheitslücken zu verhindern, andererseits weil es von vielen Auftraggebern schlicht erwartet wird.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FIS Informationssysteme und Consulting GmbH

Bundesamt für Sicherheit i.d.Informationstechnik

Einen guten Ansatzpunkt für sichere Entwicklung liefert das Bundesamt für Sicherheit in der Informationstechnik (BSI) mit dem „Leitfaden zur Entwicklung sicherer Webanwendungen”. Dessen Modell lässt sich nämlich generell auf Softwareentwicklung anwenden.

Hilfreich ist er in zweierlei Hinsicht: Er bietet eine sehr gute Begründung für SSDL und somit ein gutes Argument für Entwickler und IT-Leiter gegenüber dem Management. Außerdem führt er ein pauschales Phasenmodell für einen SSDL auf, dem auch das Hauptaugenmerk dieses zweiteiligen Artikels gilt.

Doch zunächst zur Argumentation: Natürlich ist sichere Softwareentwicklung unter Umständen ziemlich ressourcenintensiv und insbesondere bei kleineren Unternehmen nicht unbedingt ein willkommener neuer Kostenfaktor im Management. Neben rein fachlichen Argumenten für SSDL liefert das Paper aber vor allem einen Aspekt: Das BSI empfiehlt Auftraggebern aus der öffentlichen Verwaltung, die SSDL-Umsetzung bei Ausschreibungen vorauszusetzen.

Im Auftraggeber-Teil des Papers, das sich ebenfalls unter obiger Adresse findet, hat das BSI auch entsprechende Prüfempfehlungen definiert. Soll heißen: Wer für Bund oder auch Länder und Kommunen arbeiten will, dürfte früher oder später nicht mehr an dem Thema vorbei kommen. Und freilich sieht es in der freien Wirtschaft oft nicht anders aus.

Das 70-seitige PDF beinhaltet neben dem Phasenmodell, einigen Grundlagen, allgemeinen Ratschlägen rund um die Einführung von SSDL und technischen Anforderungen an die Implementierung auch ausführliche Checklisten, die auch einen guten Einblick in die ganz praktischen Maßnahmen liefern – definitiv ein Lesetipp!

Secure Software Development Lifecycle, Teil 2

Konzeption und Planung eines SSDL nach BSI

Im Folgenden lernen wir zunächst alle Phasen in der Übersicht kennen, dazu gibt es ein paar Worte zur eigentlichen Besonderheit des Modells. Anschließend kommen die einzelnen Aktivitäten der Phasen in den Fokus.

Die Phasen in der Übersicht

Die BSI-Studie setzt direkt beim Auftragnehmer an, also quasi mit den Anforderungen des Auftraggebers als Grundbaustein. Um einen Überblick über den gesamten Prozess zu bekommen, hier also stichpunktartig die Phasen im Einzelnen:

• 1. Initiale Planung und Vergabe: Planung benötigter Ressourcen für die Projektplanung beziehungsweise Angebotserstellung.

• 2. Konzeption und Planung: Technische Planung zur konkreten Umsetzung der Sicherheitsanforderungen.

• 3. Implementierung: Umsetzung des Sicherheitskonzepts während der Entwicklungsarbeit.

• 4. Testen: Prüfung der implementierten Sicherheitskonzepte, Berichtserstellung.

• 5. Auslieferung und Betrieb: Gewährleistung eines sicheren Betriebs beim Kunden (Wartung, Change Management etc.)

Die Phasen gewährleisten – sauber umgesetzt – letztlich ein verlässliches Sicherheitskonzept von der der Bewerbung für einen Auftrag bis hin zum laufenden Wartungsvertrag beim Kunden. Welche Aktivitäten in den Phasen wie genau umgesetzt werden müssen, hängt freilich auch vom Schutzbedarf der jeweiligen Anwendung ab. Hilfestellung leisten die Checklisten im Anhang.

Reifegrade

Das Phasenmodell basiert in Teilen auf OWASP SAMM und auch BSIMM, hinzu kommt jedoch ein Reifemodell, um Aussagen darüber zu treffen, wie weit die einzelnen Phasen umgesetzt werden. Gerade im behördlichen Umfeld sind solche Aussagen für die komplexen Ausschreibungsprozesse unerlässlich. Doch es ist generell nur von Nutzen, gegenüber Kunden genau beschreiben zu können, wie weit der eigene Sicherheitsprozess gediehen ist.

Reifegerade

0 – Nicht vorhanden: Mit der Umsetzung wurde noch nicht begonnen.

1 – Ad-Hoc: Teilweise, informell umgesetzt; 0 bis 50 Prozent der Punktezahl für verpflichtenden Aktivitäten.

2 – Partiell: Umsetzung begonnen; 50 bis 99 Prozent der Punktezahl für verpflichtenden Aktivitäten.

3 – Vollständig: Alle Aktivitäten wurden umgesetzt.

4 – Best in Class: Zusätzliche, optionale Aktivitäten wurden umgesetzt.

Über diese Reifegerade können Auftraggeber zum einen das Maß der SSDL-Umsetzung einschätzen und zum anderen potenzielle Auftragnehmer in der Vergabe vergleichen. Die genauen Auswirkungen auf die Vergabe lassen sich dabei eher schwierig prognostizieren: Zumindest die öffentliche Hand ist angewiesen, die „wirtschaftlichsten“ Angebote zu akzeptieren.

Das Einrechnen eines SSDL in eine Wirtschaftlichkeitsbetrachtung ist noch dazu durchaus subjektiv. Generell kann es bei Angeboten aber nur von Vorteil sein, wenn Sie Ihre Expertise bezüglich der Anwendungssicherheit belegen können.

Phase 1: Initiale Planung und Vergabe

Die initiale Planung setzt sich aus insgesamt fünf Aktivitäten zusammen und kann sowohl bei der Angebotserstellung als auch nach Auftragserteilung ansetzen, wenn beispielsweise über einen bestehenden Rahmenvertrag gearbeitet wird. So oder so beginnt der ganze SSDL-Prozess mit der „Analyse der Anforderungen des Auftraggebers“, um überhaupt eine Aussage über Termine und benötigte Ressourcen machen zu können.

Weiter geht es mit der „Identifikation und Bewertung existierender Sicherheitsanforderungen“. Hier werden bereits bestehende Anforderungen möglichst genau definiert aufgelistet. Dazu gehören gesetzliche Bestimmungen wie die DSGVO, innerbetriebliche Vereinbarungen, Rahmenwerke, die allgemein für die Software-Entwicklung angelegt werden müssen, mit verbundenen Unternehmen vereinbarte Standards und so weiter.

Konkret sind das beispielsweise im Bereich funktionaler Sicherheitsanforderungen, Allgemeinplätze wie Passwortanforderungen und bei den gerne vernachlässigten nicht-funktionalen Anforderungen Aspekte wie Zugriffskonzepte für Quellcode oder Serverräume. Im Grunde läuft es auf eine kleine Bestandsaufnahme aller Aspekte hinaus, die „ohnehin“ berücksichtigt werden müssen.

Sofern nicht bereits vom Auftraggeber zur Verfügung gestellt, sollte im nächsten Schritt in Zusammenarbeit mit diesem eine „Business Impact Analyse“ erstellt werden, um klar und deutlich aufzuführen, welche Auswirkungen eine Kompromittierung der allgemeinen Schutzziele Integrität, Vertraulichkeit und Verfügbarkeit auf das Unternehmen haben würde.

Dies ist insbesondere hilfreich, um gegenüber dem Management darzulegen, warum bestimmte Ressourcen benötigt werden und wo die Vorteile der (teuren) SSDL-Maßnahmen liegen. Bei größeren, fachlich versierten Auftraggebern sollten Sie eine solche Analyse bereits im Vorfeld von diesen bekommen können.

Als Aktivität Nummer 4 führt das Paper die „Erstellung des Sicherheitsprojektplans“ auf. Hier kommt also die gute alte Projektplanung zu ihrem Recht: Auf Basis der bislang aufgestellten Anforderungen sollten nun möglichst konkrete Aufwandsschätzungen für alle Aktivitäten in allen Phasen folgen. Unterteilen lässt sich das wie üblich in personelle, finanzielle und sachliche Ressourcen, also alles von der benötigten Arbeitszeit, über Schulungskosten bsi hin zu Sachmitteln wie Räumen, Lizenzen oder Arbeitsmitteln.

Als finalen Schritt empfiehlt das BSI die „Definition einer Software Security Group (SSG)“. Abhängig von der Größe des Unternehmens, beziehungsweise der Entwicklungsabteilung, handelt es sich dabei um eine bereichsübergreifend besetzte Gruppe von Mitarbeitern, die voll- oder teilzeitlich über Sicherheitsmaßnehmen entscheiden beziehungsweise Projektgruppen beraten. In dieser querschnittlichen Organisation sollen Sicherheitsaspekte aus allen Perspektiven (Entwicklung, Betrieb, Management, Kundenbetreuung etc.) diskutiert und (auch projektübergreifend) Maßnahmen beschlossen werden.

Die initiale Planung ist mit vielen Unwägbarkeiten gepflastert, insbesondere, wenn SSDL völlig neu ins Unternehmen kommt. Gerade in dieser Phase sollten Sie genügend Zeit aufwenden, um alle Beteiligten „auf Kurs“ zu bringen – nicht zuletzt, weil einige Mitarbeiter unmittelbar produktive Arbeiten zu Gunsten der Sicherheit reduzieren werden müssen.

Die weiteren Phasen sind meist deutlich konkreter und technischer, so dass sie sich besser planen lassen können. Funktionieren kann es aber nur, wenn alle an einem Strang ziehen und vor allem auch Sinn und Zweck des ganzen Aufwands verstehen – hier unterscheidet sich die SSDL-Einführung nicht im Geringsten von anderen größeren Projekten.

Im nächsten Teil stellen wir die zweite Phase samt ihrer neun Aktivitäten im Detail vor, anschließend folgen die nächsten Phasen und insgesamt 14 weitere Aktivitäten in etwas geraffter Form.

Secure Software Development Lifecycle, Teil 3

SSDL-Implementierung, Testing und Nachsorge

(ID:45624936)