Sichere Softwareentwicklung
Catch me if you can
Das sichere Programmieren mithilfe statischer Analyseverfahren gilt als relativ neue Disziplin. Wieweit es gegenüber klassischen Methoden des "Fuzzings" ein probates Mittel ist, um sicherheitsrelevante Defizite im Source Code zu untersuchen und dadurch einer wasserdichten Produktentwicklung den Boden zu bereiten, ist unter Experten noch umstritten.
Das "Fuzzing" gilt als probater Notnagel, um Schwachstellen beim Softwaredesign nachträglich
aufzuspüren. Fuzzing ist eine Technik für Softwaretests. Es funktioniert seit nahezu zwei
Jahrzehnten immer noch nach einer Art Zufallsprinzip. Hierfür werden mit speziellen Tools
automatisch zufällige Daten erzeugt, die über Eingabeschnittstellen eines Programms verarbeitet
werden.
Fuzzing wird in Softwareentwicklungsprojekten in der Regel im Rahmen eines Black-Box-Tests
durchgeführt, um neue Software auf Fehleranfälligkeit zu prüfen sowie um eventuelle
Sicherheitslücken aufzuspüren. Bekannte Tools aus der Praxis sind etwa Ax Man, FTP Stress Fuzzer
oder File Fuzz (I-Defense).
Das gängige Testprinzip sieht dabei im Detail folgendermaßen aus: Verursacht das Programm bei
bestimmten gelieferten Daten ein Problem – etwa einen Systemabsturz – erforscht man darauf
aufbauend anhand von White-Box-Tests die genaue Ursache, um die Fehlerquelle hoffentlich
einzugrenzen. Die Unternehmen setzen vor allem deshalb so gern auf dieses Analyse- und
Testverfahren, weil es als preisgünstig gilt. Open-Source-Tools sind dafür sogar meist gratis
erhältlich.
Alternativen zum Prinzip "Trial and Error" gibt es ohnehin kaum (siehe dazu auch die
Berichterstattung zur IT Defense 2007,
www.lanline.de/kn30997182). Oftmals kommen
Fuzzing-Tools in der Testphase unmittelbar vor dem Launch eines neuen Produkts zum Einsatz. Hat ein
Betrieb erst einmal ein klares Prozedere festgelegt und die passenden Werkzeuge, Regeln und Abläufe
beschrieben, lässt sich danach das "Fuzz-Testing" anhand der vorgegebenen Regeln und Sets rasch
durchführen beziehungsweise sukzessive im Laufe der Softwareentwicklung um neue Elemente
erweitern.
Etablierter Notnagel
"Fuzzing allein ist jedoch keine zuverlässige Methode zur Qualitätssicherung von Software", gab
Sicherheitsberater Brian Chess auf der diesjährigen Konferenz IT Defense in Hamburg zu bedenken.
Der Trend gehe dahin, sagt der Unternehmensgründer von Fortify Software, nicht nur von außen auf
die Applikationen zu schauen, sondern die Schwachstellen früher zu erkennen.
Schaue man sich den Markt für gängige durchaus professionelle Tools genauer an, dann zeigten
sich anhand etwa von Spike, Peach, Protos und vielen anderen Werkzeugen, dass sich aus deren
Ergebnissen nur begrenzte Rückschlüsse auf die Softwaresicherheit ziehen ließen, bekräftigt Chess.
Auch Black-Box-Scanning-Tools wie Cenzic, SPI Dynamics oder Watchfire lösten das Problem nur
bedingt.
Hinzu kommt, dass diese Tools gegebenenfalls auch neue Managementprobleme generieren, die die
Spezialisten bereits von der automatischen Einbruchsabwehr (Intrusion Detection) her kennen.
Zahlreiche Fehlalarme gibt es nicht nur dort, sondern auch beim Fuzzing. Die mit allerlei
Informationen gespickten und überbordenden Fehlerberichte gilt es nämlich zusätzlich noch nach
sinnvollen Kriterien auszuwerten.
Nach dem Test ist überdies bekanntlich vor dem Test. Und nicht immer bedeutet der Systemabsturz
eines Programms tatsächlich die ursprünglich befürchtete Katastrophe. Für die Spezialisten bedeutet
dies, dass sie angesichts der Testresultate oft den Wald vor lauter Bäumen nicht mehr sehen und
erhebliche Probleme haben, in der Bestandsaufnahme die kritischen von den unkritischen
Testergebnissen zu trennen. "Invalider Input ist einfach reine Zeitverschwendung", bilanziert Brian
Chess.
Methoden kombinieren
Der Sicherheitsexperte plädiert deshalb für ein friedliches Nebeneinander von statischer
Quellcodeanalyse und dem flexiblen Testen. Ob damit den Unternehmen allerdings schon geholfen ist,
bleibt zunächst eine offene Frage. Schaut man sich etwa das denkbare Spektrum an Exploits bei
Windows Vista an, so dürfte dies den dafür zuständigen Spezialisten angesichts der bevorstehenden
Tests wohl buchstäblich den Schweiß auf die Stirn treiben. Wer mag da noch von einem "Sexy
Development Cycle" sprechen, wie es in einem
MSDN-Blog von Microsoft der Fall ist (Eintrag
vom 29.01.08, 05.37 pm)?
Auch Stefan Strobel, Geschäftsführer von Cirosec, hält das bisherige Instrumentarium für nicht
ausreichend. Insbesondere bei großen Konzernen und Unternehmen, die eigene Applikationen entwickeln
und betreiben, greife Fuzzing zu kurz. Der Sicherheitsberater sieht die statische Quellcode-Analyse
durchaus als viel versprechendes Instrument an, das eine Lücke in der sicheren Softwareentwicklung
schließen könne. "Erste Anfragen von Unternehmen gibt es bereits, und wir sondieren den Markt und
die angebotenen Lösungen", erklärt Strobel.
Die offenbar erhöhte Nachfrage nach neuen Werkzeugen ist allerdings auf den zweiten Blick
weniger überraschend als vermutet. Bereits Barton Miller, der das Prinzip Fuzzing schon Ende der
achtziger Jahre propagierte, sah frühzeitig den begrenzten Lösungsbeitrag voraus. Simple Tests
seien kein Mittel, um extensive formale Testverfahren und -prozeduren zu ersetzen. Brian Chess hält
dennoch insbesondere Open-Source-basierte Tools für ein probates Mittel, um reale Bugs in realen
Programmen besser aufspüren zu können.
Passenderweise hatte er zum Vortrag aus seinem eigenen Unternehmen Fortify Software ein
entsprechendes Produkt als Alternative zum Fuzzing im Gepäck mitgebracht. Er zögert allerdings
noch, Fuzzing pauschal zu verdammen oder für nutzlos zu erklären.
Die entsprechend aktualisierte Lösung "
Fortify SCA 5.0" ist
bereits seit November 2007 verfügbar und soll mithilfe der Quellcodeanalyse alle erdenklichen
Schwachstellen und Sicherheitslücken einer Applikation bereits während des Entwicklungsprozesses
erkennen und beseitigen. Die Messlatte liegt hoch, denn die Schwachstellen sollen bereits während
des Entwicklungsprozesses erkannt und ausgemerzt werden.
Bislang sei der Anbieter weltweit damit einzigartig, rührte Chess auf der IT-Defense weiter die
Werbetrommel. Fortify SCA 5.0 stelle gegenüber früheren Lösungsansätzen einen erweiterten
Funktionsumfang bereit, wie Wizards zur Erstellung individuell angepasster Sicherheitsregeln, die
auch von den Anwendern selbst vorgenommen werden könnten.
In dem Lösungspaket enthalten sind auch Teamfunktionen für die übergreifende Zusammenarbeit von
Software-Entwicklungsteams und Schutzelemente vor neuen, für die Applikationssicherheit
maßgeblichen Schwachstellenklassen. Durchaus auch dem Hype ums Web 2.0 geschuldet, unterstützt das
Konzept außerdem die vier zusätzlichen Programmiersprachen PHP, Javascript (Ajax), Classic ASP/VB
Script (VB 6) sowie Teile von Cobol.
Um seinen hohen Anspruch zu untermauern, bezieht sich Fortify Software im Übrigen nur allzu gern
auf die Expertise der Marktforscher von Gartner. Danach seien die Unternehmen aufgefordert,
Technologien und Prozesse zur Kontrolle des Quellcodes einführen, da diese einen strategischen
Nutzen hätten, so die Auguren in der Studie "Market Definition and Vendor Selection Criteria for
Source Code Security Testing Tools" vom Mai 2007.
Kommerzialisierungstrend
Die Wahrung der Applikationssicherheit habe sich für Organisationen, die eigene Anwendungen
erstellten, als unverzichtbar erwiesen, lassen die Marktforscher verlauten. Sichere
Entwicklungsprozesse müssten sich danach auch nahtlos in die Unternehmensaktivitäten integrieren
lassen.
Fortify Software sieht sich, gestärkt durch die Salbung der Auguren, als Vorreiter auf diesem
Gebiet an. Das Unternehmen hat dementsprechend für die Version 5.0 neue Teamwork- und
Anpassungsfunktionen integriert und gleichzeitig die Palette der unterstützten Technologien
vergrößert (siehe Kasten). Diese sei gleich in drei Kernbereichen erweitert worden, um die sichere
Applikationsentwicklung in Unternehmen zu beschleunigen.
Für den einen oder anderen aus der kritischen Szene mag das Bemühen von Fortify Software um
einen sicheren Produktlebenszyklus zwar arg "handbuchartig" lesen – aber Brian Chess glaubt an
seine Mission. "Die statische Quellcodeanalyse ist absolut auf dem Vormarsch, weil sie besser
funktioniert als das Fuzzing mit immer anderem Input", so sein unternehmerisches Credo.
So könnte der Markt in den nächsten Jahren weiter reifen. Auch andere Anbieter wie Coverity,
Klocwork, Ounce oder Find Bugs haben sich auf ähnliche Dienstleistungen wie Chess‘ Unternehmen
spezialisiert. Aus Sicht der Anwender gilt es jedoch, die derzeit dargebotene Bandbreite etwas
genauer unter die Lupe zu nehmen, um nicht zu früh auf einen nur dahinholpernden Zug aufzuspringen,
der dann am Ende womöglich entgleist. Achten muss man etwa auf Aspekte wie die Zielgenauigkeit
(False-Positive-Rate), die Bandbreite und Tiefe der Analysewerkzeuge, die Skalierbarkeit
beziehungsweise die Anpassungsfähigkeit sowie weitere, zusätzliche Sicherheitsmerkmale nach dem
Motto: "Wer testet eigentlich die Testwerkzeuge?"
Immerhin sind bei der Quellcodeanalyse nur jene Informationen wirklich zu greifen, die
Spezialisten für das Auffinden ganz bestimmter Fehlerarten benötigen und auf die sie sich
konzentrieren. Lediglich diese Informationen bilden dann wiederum das Rohmaterial für die weitere
Analyse. Letztlich kommen auch bei der Quellcodeanalyse, ähnlich wie beim Fuzzing, immer wieder
stark vereinfachte Annahmen ins Spiel. Dies geschieht auch mit dem Ziel, die Anzahl der möglichen
Benachrichtigungen zu einem bestimmten Teilaspekt oder Programm möglichst niedrig zu halten.
Setzt sich statische Code-Analyse durch?
Es stellt sich zudem die Frage, welche Kosten ein aufwendiger Monitoring-Prozess für die
Betriebe verursacht – mit Blick auf die Kalkulierbarkeit des Return-on-Invest (ROI). Steigende
regulatorische Auflagen im Sinne der Compliance oder Basel II dürften dem Markt sicherlich
zusätzlichen Auftrieb verleihen – vor allem, damit Unternehmen besser dokumentieren können, alles
Erdenkliche getan zu haben, um so den schwarzen Peter von sich wegzuschieben. Dies ist für sie
wichtig, sollte die eine oder andere Schwachstelle tatsächlich einmal ausgenutzt werden. Dann
nämlich könnte man auf mangelhafte interne Prozesse in der Softwareentwicklung schließen.
Laut Stefan Strobel von Cirosec ist ein echter Full-Service rund um das sichere Softwaredesign
auf der Basis einer statischen Analyse derzeit allenfalls für größere Unternehmen und Konzerne zu
empfehlen, die ohnehin mit größerem Aufwand eigene Applikationen entwickeln und betreiben.
Letztlich ließen sich dadurch aber hohe Kosten für die spätere Beseitigung von Bugs sparen. Für
kleinere Betriebe sei dies hingegen kein schlagendes Argument, weil für sie der Aufwand bei der
Anpassung in der Regel eindeutig zu hoch sei, bilanziert der Experte.
Abschreckender Aufwand
Ob Big Player oder der kleine Nachbar von nebenan: Abschreckend dürfte in jedem Falle der hohe
Aufwand für die individuelle Anpassung der Testverfahren und -Tools wirken. Auch Brian Chess weiß,
dass sein Produkt keine vollständige "Anleitung zum Glücklichsein" liefern kann. "Die statische
Analyse ist nicht alles", bringt er es auf den Punkt. Er räumt gerne ein, dass die Semantik eines
Codes letztlich "ein soziales Konstrukt" darstelle, das es im jeweiligen Kontext zu analysieren und
bewerten gelte.
Diese Komplexität kann alle Kostenvorteile dann auch wieder zunichte machen Es kann sich etwa
herausstellen, dass sich das Testsystem nur allzu aufwendig an die eigene Entwicklungsumgebung
anpassen lässt. Oder die Installation und Konfiguration könnte die eine oder andere zusätzliche
Nachtschicht verursachen, die der externe Dienstleister dann gern zusätzlich in Rechnung
stellt.
Lesen Sie mehr zum Thema
