Microsofts SDL, Phase 5 (Verification) und 6 (Release)
Microsofts Security Development Lifecycle besteht aus 7 Phasen, von denen ich Phase 1 und 2 sowie Phase 3 und 4 bereits beschrieben habe. Weiter geht es mit
Phase 5: Verification
In der fünften Phase wird geprüft, ob alle aufgestellten Sicherheits- und Datenschutz-Anforderungen eingehalten werden. Auch diese Phase besteht wieder aus drei Schritten:
Schritt 1: "Perform Dynamic Analysis"
Bei der dynamischen Analyse wird während der Laufzeit des Programms geprüft, dass alle Funktionen wie vorgesehen arbeiten und es z.B. keine Pufferüberläufe und Privilegienverletzungen gibt.
Vom Microsoft werden Sie in diesem Schritt z.B. durch zwei Tools unterstützt: Der Application Verifier oder kurz AppVerifier dient der Suche nach typischen Schwachstellen, indem die Interaktion der zu untersuchenden Anwendung mit dem Betriebssystem überwacht wird. Werden Objekte, die Registry, das Dateisystem und die Windows-APIs sicher eingesetzt? Außerdem kann geprüft werden, wie sich das Programm beim Einsatz mit verschiedenen Benutzerrechten verhält.
Der BinScope Binary Analyzer prüft die Binärdateien auf Einhaltung der Regeln des SDL: Wurden die Compiler-/Linker-Flags korrekt gesetzt? Werden die Namensregeln für Assemblies eingehalten? Wurden die aktuellen Versionen der Tools verwendet? Wurde die aktuelle Version der ATL-Header verwendet?
Schritt 2: "Perform Fuzz Testing"
Beim Fuzzing wird das Programm mit zufällig erzeugten Eingaben getestet. Die meisten Fehler und sich daraus ergebenden Schwachstellen beim Verarbeiten von Daten werden entweder durch Zufall oder durch Fuzzing gefunden.
Für diesen Schritt wurden von Microsoft schon kurz nach der Vorstellung des SDL zwei Fuzzer veröffentlicht: Der MiniFuzz File Fuzzer erstellt Dateien mit zufälligen Inhalten, um den Code zur Dateiverarbeitung zu testen. Und der SDL Regex Fuzzer dient der Suche nach möglichen DoS-Schwachstellen in regulären Ausdrücken. Und darüber hinaus gibt es natürlich für so ziemlich jeden denkbaren und auch undenkbaren Anwendungsfall Fuzzer.
Schritt 3: "Conduct Attack Surface Review"
Im letzten Schritt wird die Angriffsfläche überprüft, um sicher zu stellen, dass sich während der Entwicklung nicht durch Änderungen am Entwurf oder der Implementierung neue, bisher nicht berücksichtigte Angriffspunkte ergeben haben.
Für diesen Schritt stellt Microsoft ein sehr praktisches Tool bereit, den Attack Surface Analyzer. Der zeigt nach der Installation einer Anwendung neu hinzugekommene Dateien, Registry-Keys, Dienste, ActiveX-Controls und offene Serverports an und weist auf Änderungen an Access Control Lists und weiteren sicherheitsrelevanten Parametern hin. Damit können Sie feststellen, ob und ggf. wie die Installation Ihrer Anwendung die Angriffsfläche der Windows-Installation vergrößert und prüfen, ob der Ist-Zustand mit dem gewünschten Soll-Zustand überein stimmt oder ob es Abweichungen gibt.
Phase 6: Release
In der sechsten Phase wird das Programm für die Veröffentlichung vorbereitet. Wieder einmal in drei Schritten:
Schritt 1: "Create an Incident Response Plan"
Der erste Schritt befasst sich vereinfacht mit der Frage "Was passiert, wenn etwas passiert?"
Wie können Ihnen gefundene Fehler, insbesondere natürlich Schwachstellen, gemeldet werden, und wie reagieren Sie auf diese Meldungen. Zum einen muss es einen erreichbaren Ansprechpartner für Probleme geben, zum anderen Pläne, wie auf gefundene Schwachstellen, sowohl im eigenen Programm als auch in Komponenten von Drittherstellern, reagiert werden soll.
Für Sie bedeutet das: Sehen Sie eine E-Mail-Adresse vor, an die Schwachstellen gemeldet werden können, und überlegen Sie sich, wie Sie auf so eine Meldung reagieren. Wenn Sie sich jetzt vorbereiten, brechen Sie später nicht in Panik aus, sondern können beruhigt ihrem vorbereiteten Plan folgen. Denn im schlimmsten Fall haben Sie dann keine Zeit mehr, sich erst einmal Gedanken über die notwendigen Reaktionen zu machen, sondern müssen schnell auf eine womöglich bereits für Angriffe ausgenutzte Schwachstelle reagieren.
Berücksichtigen Sie bei Ihrer Planung, dass es mehrere Möglichkeiten für die Entdeckung einer Schwachstelle gibt:
- Die Schwachstelle kann von Ihnen selbst bei internen Tests gefunden oder Ihnen vertraulich vom Entdecker gemeldet werden, sodass sie in der Öffentlichkeit nicht bekannt ist. Das bedeutet natürlich nicht, dass sie nicht evtl. zusätzlich unabhängig davon von einem Dritten entdeckt wird, der sie sofort veröffentlicht oder gar für Angriffe ausnutzt.
- Die Schwachstelle wurde im Rahmen der "Full Disclosure" von ihrem Entdecker veröffentlicht, der evtl. auch einen sog. Proof Of Concept zur Demonstration eines Angriffs mitliefert. Für Pufferüberlauf-Schwachstellen wird dafür dann z.B. Code verwendet, der unter Windows den Taschenrechner oder Notepad öffnet. Dieser PoC-Code lässt sich meist durch minimale Änderungen in tatsächlichen Schadcode umwandeln, der z.B. eine Hintertür öffnet.
- Die Schwachstelle wurde bekannt, weil sie von Cyberkriminellen ausgenutzt wird.
Möglichkeit 2 und 3 sind eigentlich identisch, die Schwachstelle ist öffentlich bekannt und kann oder wird bereits für Angriffe ausgenutzt. Bei einer bereits öffentlich bekannten Schwachstelle sollten die Benutzer schnellstmöglich informiert werden, spätestens, wenn die Schwachstelle durch eigene Untersuchungen bestätigt wurde. Bei einer Schwachstelle, die bereits für Angriffe ausgenutzt wird, können Sie darauf meist verzichten. Die Angriffe beweisen ja, dass die Schwachstelle existiert und ausnutzbar ist.
Anders sieht es aus, wenn die Meldung der Schwachstelle unklar ist und z.B. nur auf einen möglicherweise ausnutzbaren Pufferüberlauf hinweist. Dann sollten Sie sich durch eigene Tests davon überzeugen, ob es sich wirklich um einen solchen handelt und nicht nur um einen nur DoS-Angriffe ermöglichenden Stacküberlauf.
Informieren Sie die Benutzer unverzüglich zumindest über das Vorhandensein der Schwachstelle und die sich ergebenden Gefahren und stellen Sie möglichst auch einen Workaround bereit, der Angriffe bis zum Erscheinen eines Patches oder Updates zumindest erschwert.
Danach geht es dann so weiter, wie sie auch bei einer nur Ihnen und ggf. dem Entdecker bekannten Schwachstelle vorgehen sollten: Wenn die Schwachstelle durch einen Patch oder ein Update behoben wurde, werden die Benutzer über die Beseitigung der Schwachstelle informiert. Sofern die Schwachstelle zuvor nicht veröffentlicht wurde, gehört dazu auch eine zumindest allgemeine Beschreibung und Hinweise auf mögliche Angriffe. Weisen Sie dabei auch darauf hin, wie dringend die Installation des Patches bzw. Updates Ihrer Ansicht nach ist.
Mehr über Incident Response Planung können Sie auch in meinem Artikel auf entwickler.de zum Thema lesen: "Incident Response: Was passiert, wenn etwas passiert?".
Schritt 2: "Conduct Final Security Review"
Im "Final Security Review" (FSR) werden alle bisherigen sicherheitsrelevanten Aktivitäten ein letztes Mal überprüft: Wurden die gesetzten Ziele erreicht, so dass das Programm veröffentlicht werden kann?
Microsoft stellt hierfür zwei Tools bereit: Die bereits in der Anforderungsphase zum Einsatz gekommenen Process Templates für Visual Studio Team System (VSTS) und Team Foundation Server (TFS), die auch im nächsten Schritt verwendet werden können.
Schritt 3: "Certify Release and Archive"
Jetzt ist es geschafft: Das Programm kann veröffentlicht werden. Alle angefallenen Informationen und Daten wie Spezifikationen, Quelltexte, Binärdateien, Dokumentationen etc. müssen nun archiviert werden, damit im Fall später auftretender Probleme, insbesondere natürlich gefundenen Schwachstellen, darauf zurückgegriffen werden kann. Verfahren Sie hier ruhig nach dem "Viel hilft viel"-Ansatz: Jede jetzt gelöschte Datei kann später die sein, die Ihnen bei der Korrektur einer Schwachstelle entscheidend geholfen hätte.
In der nächsten Folge stellen ich Ihnen die letzte Phase vor: 7., "Response". Die erscheint aber erst am 10. Januar 2019, denn die nächsten 2 Wochen macht das Blog eine kleine Weihnachtspause. Lediglich morgen erscheint aus dann aktuellem Anlass noch ein Text.
Ich wünsche Ihnen allen ein frohes Fest, einen guten Rutsch ins neue Jahr und ein gesundes und erfolgreiches 2019!
Trackbacks