Skip to main content

Trainings und Tools zum SDL (Phase 4 bis 7)

Microsoft hat eine Reihe von Trainingsmaterialien und Tools veröffentlicht, die Sie in den verschiedenen Phasen des Software Development Lifecycle (SDL) bei der Arbeit unterstützen. Im Folgenden werden die Materialien und Tools für die Phasen 4 bis 6 (Implementation, Verification, Release und Response) vorgestellt.

4. Implementation

Das Trainingsmaterial für die Implementierungsphase ist identisch mit dem für die Design-Phase, lediglich die Einführung in Threat Modeling ist nun nicht mehr relevant. Das Lernen lohnt sich also, das einmal erworbene Wissen können Sie immer wieder einsetzen.

Das " SDL Developer Starter Kit" enthält für diese Phase zusätzliches Material zu den Secure Implementation Principles, unerwünschten APIs, zur Code-Analyse, der Source Code Annotation Language und den Compiler Defenses.

Speziell für den ersten Schritt "Use Approved Tools", enthält der Anhang der "SDL Process Guidance" eine Aufführung für den SDL erforderlicher und empfohlener Compiler, Tools und Optionen für 32- und 64-Bit-Windows (und Windows CE).

Für den zweiten Schritt "Deprecate Unsafe Functions" enthält die Präsentation " Basics of Secure Design, Development and Test" einige Hinweise auf den unsicheren Einsatz der unerwünschten Funktionen und welche Folgen dieser Einsatz hat. Eine Liste unerwünschter C-Funktionsaufrufe gibt es in der MSDN Library: " Security Development Lifecycle (SDL) Banned Function Calls". Als Tools stellt Microsoft das Headerfile banned.h bereit, das alle verbannten APIs enthält und Sie ggf. darauf hinweist, dass Sie eine unerwünschte Funktion verwenden. Strsafe.h stellt eine Reihe sicherer String-Funktionen als Ersatz für die unsicheren C-Funktionen bereit. Die C Runtime Libraries wurden um verschiedene Sicherheitsmaßnahmen erweitert.

Für den dritten Schritt "Perform Static Analysis" gibt es zwei Webcasts zum Einsatz von CAT.NET (Code Analysis Tool .NET). Dieses Tool für 32 Bit und 64 Bit ist für Entwickler von Desktop-Anwendungen auf den ersten Blick nur mäßig interessant, da es vor allem die Suche nach typischen Web-Schwachstellen unterstützt. Diese sind aber unter Umständen auch für Ihr Programm relevant, denn z.B. ist eine SQL Injection bei jeder Art von SQL-Datenbank möglich, nicht nur beim Einsatz in Verbindung mit einer Webanwendung. Das gleiche gilt für XPath- und LDAP-Injection: Werden die entsprechenden Techniken verwendet, können Sie unter Umständen auch über eine Desktop-Anwendung angegriffen werden, wenn diese eine entsprechende Schwachstelle enthält.

Die Anti-Cross Site Scripting Library (AntiXSS) werden allerdings wirklich nur die wenigsten Entwickler von Desktop-Anwendungen benötigen. Sie hilft Ihnen ggf. bei der Umkodierung von Ein- und Ausgaben in einer ASP.NET-Anwendung, um XSS zu verhindern. Falls Sie Ihre Desktop-Anwendung mit einer Weboberfläche versehen wollen, z.B. um einen Audio-Player auch über eine Webseite im lokalen Netz zu steuern, müssen Sie natürlich auch auf XSS-Schwachstellen achten. Sonst könnte z.B. über den angezeigten Titel der gerade gespielten MP3-Datei in die Steuerung des Audio-Players eingegriffen werden. Das ist zwar unwahrscheinlich, aber möglich, und wenn es um Sicherheit geht, sollte es egal sein, wie wahrscheinlich oder unwahrscheinlich ein Angriff auf eine Schwachstelle ist (denken Sie nur an die unsicheren Suchpfade für Bibliotheken, die für nur mit normalen Benutzerrechten ausgeführten Programme lange Zeit nicht als wirkliche Schwachstelle angesehen wurden - bis ihre mögliche Ausnutzung aus der Ferne erkannt wurde, wodurch schlagartig dutzende Programme kritische Schwachstellen enthielten).

FxCop ist ein Tool zur statischen Code-Analyse von .NET-Code und besteht aus einer grafischen Oberfläche und Kommandozeilentools. Die Durchführung der Analyse wird in der Anleitung zu Visual Studio 2010 beschrieben, das es diese Funktionen in der Premium- und Ultimate-Edition bereits enthält.

Sollte Ihre Desktop-Anwendung schlöießlich ein ActiveX-Control enthalten, können Sie mit dem ATL-Template SiteLock unter Windows XP, Server 2003 und Vista festlegen, welche Domains darauf zugreifen können.

5. Verification

Auch für die Verifikationsphase ist das Trainingsmaterial das gleiche wie für die Design-Phase, abzüglich der Einführung in Threat Modeling:

Das " SDL Developer Starter Kit" enthält für diese Phase zusätzliches Material zu Secure Verification Principles, Security Code Review und dem wichtigen Fuzz Testing.

Für den ersten Schritt "Perform Dynamic Analysis" stellt Microsoft zwei Tools zur Verfügung. 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?

Für den zweiten Schritt "Fuzz Testing" gibt es reichlich Trainingsmaterial. Ein Artikel aus dem MSDN Magazine beschreibt das Fuzzy Testing mit Visual Studio Team System, und ein Security Brief Denial-of-Service-Angriffe über reguläre Ausdrücke und deren Abwehr. Im MSDN Test Center gibt es eine allgemeine Einführung in Fuzzing, und in der MSDN Library wird " Automated Penetration Testing with White-Box Fuzzing" beschrieben.

Auch zwei Fuzzing-Tools stellt Microsoft bereit: 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.

Auch für den dritten Schritt "Attack Surface Review" hat Microsoft ein Tool bereit gestellt, den Attack Surface Analyzer. Dieser 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 z.B. prüfen, ob der Ist-Zustand mit dem gewünschten Soll-Zustand übereinstimmt. So können Sie z.B. unsichere Zugriffsrechte erkennen, ohne jede Datei einzeln prüfen zu müssen.

Nach der Installation des Attack Surface Analyzers (oder vor der Installation Ihres Programms, falls der Analyzer bereits installiert ist) führen Sie einen Scan durch, der den aktuellen Stand des Systems ermittelt. Danach installieren Sie Ihr Programm und starten einen zweiten Scan. Dabei werden alle sicherheitsrelevanten Änderungen erfasst und nach Ablauf des Scans angezeigt. Das klingt einfach und ist es auch - entsprechend kurz ist auch die Anleitung des Analyzers.

6. Release

Für die Release-Phase gibt es im Prinzip keine neuen Trainingsmaterialien oder Tools, jetzt gilt es ja im wesentlichen auch "nur" sicher zu stellen, dass sowohl das Programm als auch die Entwickler wirklich bereit für die Veröffentlichung sind und alle vorhergehenden Schritte korrekt durchlaufen wurden.

Für den ersten Schritt "Incident Response Plan" gibt es im Anhang der "SDL Process Guidance" ein Beispiel für das "SDL Privacy Escalation Response Framework" mit Hinweisen, wie auf ein Datenschutz-Problem reagiert werden sollte. Weitere Informationen gibt es im entsprechenden Abschnitt des Anhangs " SDL Privacy Questionnaire". Im Wesentlichen geht es jetzt nur noch darum, Sie auf die Folgen eines möglichen Fehlers vorzubereiten. Das klingt überflüssig, schließlich sind Sie ja sicher, keinen Fehler gemacht zu haben. Aber im Falle eines Falles ist es besser, sich schon vorher ein paar Gedanken darüber zu machen, wie man mit einem Problem umgeht. Denn wenn es soweit ist, ist dafür wahrscheinlich keine Zeit mehr.

Für den zweiten Schritt "Final Security Review" gibt es zwei Tools: Die bereits in der Anforderungsphase zum Einsatz gekommenen Process Templates für Visual Studio Team System (VSTS) und Team Foundation Server (TFS) für konventionelle und agile Entwicklung, die auch im dritten und letzten Schritt "Release/Archive" zum Einsatz kommen.

7. Response

Für die letzte Phase "Response", also das Reagieren auf gefundene Schwachstellen, gibt es keine zusätzlichen Trainingsmaterialien oder Tools. Im Wesentlichen besteht die Phase aus zwei Schritten: Zum einen muss eine gefundene Schwachstelle erfasst, ermittelt und beseitigt werden, zum anderen müssen die Benutzer darüber informiert werden.

Dabei gibt es je nach Gesichtspunkt zwei oder drei Möglichkeiten für die Entdeckung einer Schwachstelle:

  1. Die Schwachstelle kann bei internen Tests gefunden oder den Entwicklern vertraulich vom Entdecker gemeldet werden, sodass sie in der Öffentlichkeit nicht bekannt ist. Das bedeutet natürlich nicht, dass sie nicht evtl. doch einem Dritten bekannt ist, der sie ebenfalls entdeckt.
  2. Die Schwachstelle wurde im Rahmen einer "Full Disclosure" von ihrem Entdecker veröffentlicht, der evtl. auch einen sog. Proof Of Concept mitliefert, der die Ausnutzung der Schwachstelle demonstriert. Für Buffer Overflow-Schwachstellen wird dafür dann z.B. Code verwendet, der den Windows 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.
  3. 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, kann man meist sogar auf die eigene ausführliche Überprüfung verzichten. Anders sieht es aus, wenn die Meldung der Schwachstelle unklar ist und z.B. nur auf einen möglicherweise ausnutzbaren Buffer Overflow hinweist. Dann sollte man sich davon überzeugen, ob es sich wirklich um einen solchen handelt und nicht nur um einen nur DoS-Angriffe ermöglichenden Stacküberlauf. Die Erweiterung !exploitable Crash Analyzer für den Windows Debugger kann bei der notwendigen Prüfung eines Absturzes helfen.

Für Benutzer besonders wichtig sind dann auch Informationen über mögliche Workarounds und das voraussichtliche Erscheinen eines Patches zur Korrektur der Schwachstelle. Denn Sie möchten ja nicht, dass die Benutzer den einfachsten Workaround nutzen und auf die Nutzung Ihres Programms verzichten und sich dann möglicherweise generell einem Konkurrenzprodukt zuwenden.

Danach geht es dann so weiter, wie sie bei einer nur Ihnen und ggf. dem Entdecker bekannten Schwachstelle vorgehen: Wenn die Schwachstelle durch einen Patch oder ein Update behoben wurde, werden die Benutzer sowohl über die Schwachstelle als auch deren Beseitigung informiert. Weisen Sie dabei auch darauf hin, wie dringend die Installation des Patches bzw. Updates ist. Verlassen Sie sich nicht darauf, dass ein dringender Patch zum Beheben einer zum Ausführen von Code ausnutzbaren Schwachstelle sofort installiert wird.


 

Autor des Artikels

Dipl.-Inform. Carsten Eilers ( www.ceilers-it.de) ist als freier Berater und Coach für IT-Sicherheit und technischen Datenschutz tätig und als Autor verschiedener Artikel und des Buches "Ajax Security" bekannt.  Seinen Blog finden Sie hier.

 



These postings are provided "AS IS" with no warranties, and confers no rights. Use of included code samples are subject to the terms specified at Microsoft - Information on Terms of Use. The content of these security articles are the own personal opinions from Carsten Eilers.

Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur -Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die -Website verlassen.

Möchten Sie teilnehmen?