Microsofts SDL, Phase 7 (Response)
Microsofts Security Development Lifecycle besteht aus 7 Phasen, von denen ich Phase 1 und 2, Phase 3 und 4 sowie Phase 5 und 6 bereits beschrieben habe. Jetzt fehlt nur noch die letzte Phase:
Phase 7: Response
Die siebte Phase bildet den Abschluss des SDL: Reagieren Sie auf nach der Veröffentlichung des Programms bekannt gewordene Schwachstellen. Allgemein kann man das auch als "Befolgen Sie den 'Incident Response Plan'" zusammenfassen. Was natürlich voraussetzt, dass Sie in Phase 6 einen entsprechenden Plan erstellt haben.
Microsoft hat zu diesen Zweck das Microsoft Security Response Center (MSRC) zur Identifikation, Überwachung und Lösung von sicherheitsrelevanten Vorfällen eingerichtet. Eine vergleichbare Lösung mag für Ihr Programm ein zu großer Aufwand sein, aber eine speziell für solche Zwecke vorgesehene Seite Ihrer Website oder zumindest ein Abschnitt in der Seite mit der Programmbeschreibung sollte Ihnen die Sicherheit ihres Programms wert sein. Geben Sie dort die E-Mail-Adresse an, an die Schwachstellen gemeldet werden können, und informieren Sie über gefundene Schwachstellen, mögliche Workarounds und bereit stehende Patches oder Updates.
Ein oft übersehener Punkt: Irgendwann wird der Zeitpunkt kommen, zu dem Sie ein Programm oder eine bestimmte Version davon nicht mehr weiter entwickeln und mit Patches versorgen wollen. Das sollten Sie dann auch öffentlich bekannt geben, damit sich die Benutzer darauf einstellen können. Ein einfacher Hinweis wie
"Nach dem 20.9.2019 wird das Programm/die Version von mir nicht mehr unterstützt, es wird dann auch keine Patches für evtl. auftretende Schwachstellen mehr geben"
gibt den Benutzern die Chance, rechtzeitig zu einem anderen Programm zu wechseln und bringt sie nicht in die Verlegenheit, im Falle einer kritischen Schwachstelle kurzfristig einen Ersatz suchen zu müssen.
Fazit
Der Security Development Lifecycle ist ein sehr guter Ansatz zur Entwicklung sicherer Software, der sich durchaus auch im Kleinen einsetzen lässt.
Wenn Sie bereits Wert auf die Sicherheit Ihrer Programme legen, liefert Ihnen der SDL ja vielleicht Anregungen, um Ihre Vorgehensweisen zu optimieren.
Wenn Sie sich bisher keine Gedanken über die Sicherheit gemacht haben, sollten Sie über eine Änderung Ihrer bisherigen Vorgehensweise dringend nachdenken. Sie müssen den SDL ja nicht zwingend 1:1 übernehmen, sondern können ihn problemlos an Ihre eigenen Bedürfnisse anpassen. Wichtig ist nur, dass Sie dabei das Ziel "Sicherheit" nicht aus den Augen verlieren.
Wenn Sie sich z.B.
- einen Überblick über mögliche Schwachstellen und Angriffe verschaffen (Phase 1, die können Sie schlecht einsparen),
- sich Gedanken über mögliche Angriffe auf bzw. über Ihr Programm machen (die Bedrohungsanalyse aus Phase 3),
- diese Angriffe bei der Implementierung berücksichtigen und dabei sichere Tools sicher einsetzen (Phase 4)
- und nach der Veröffentlichung des Programms schnell auf evtl. entdeckte Schwachstellen reagieren (Phase 7),
ist Ihr Programm schon deutlich sicherer, als würden Sie einfach nach der Devise "Es reicht, wenn es tut, was es soll" drauf los programmieren. Das ein Programm mit richtigen Eingaben richtige Ergebnisse liefert, ist ja wohl eine Selbstverständlichkeit. Aber genau so wichtig ist, dass bei falschen Eingaben nichts Unerwünschtes passiert.
Ab der nächsten Folge beschreibe ich den Einsatz des SDL an einem kleinen Beispiel. Und um zu zeigen, dass der SDL nicht nur für Windows und Windows-Programme funktioniert, anhand eines kleinen PHP-Gästebuchs.
Trackbacks