Die Qual der Wahl

Nicht selten versagen alle gängigen Programmierstandards. So verwundert es kaum, dass rund 80% aller webbasierten Applikationen als "löchriges Einfallstor" für Malware aller Art gelten. Als einer der probaten Notnägel, um nachträglich Schwachstellen beim Software-Design aufzuspüren, gilt bislang "Fuzzing".

Das Ganze funktioniert seit nahezu zwei Jahrzehnten immer noch nach einer Art Zufallsprinzip. Fuzzing ist eine spezielle Technik für Software-Tests. Hierfür werden automatisch mit Tools zufällige Daten erzeugt, die über Eingabeschnittstellen eines Programms verarbeitet werden, wie durch das Öffnen einer Datei, deren Datenformat das jeweilige Programm unterstützt.

Fuzzing wird in Software-Entwicklungs-Projekten 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. Bekanntere Tools aus der IT-Welt sind etwa AxMan, FTP Stress Fuzzer oder File Fuzz (iDefense).

Das gängige Prinzip funktioniert meist so: Verursacht das Programm bei bestimmten gelieferten Daten ein Problem - etwa einen Systemabsturz, so lässt sich darauf aufbauend, anhand von White-Box-Tests, die genaue Ursache erforschen, um die Fehlerquelle einzugrenzen. Unternehmen setzen auf dieses Analyse- und Testverfahren, weil es als preisgünstig gilt. Insbesondere Tools aus der Open Source sind sogar meist gratis erhältlich.

Alternativen zum Prinzip "Trial and Error" gibt es ohnehin meist kaum. Oftmals kommen derartige Produkte bereits unmittelbar in der Testphase vor dem Launch eines neuen Produkts zum Einsatz. Hat der Betrieb erst einmal ein klares Prozedere festgelegt, die passenden Werkzeuge, Regeln und Abläufe beschrieben, lässt sich hernach das "Fuzz-Testing", anhand der vorgegebenen Regeln und Sets rasch durchführen, beziehungsweise sukzessive im Laufe der Softwareentwicklung um neue Elemente erweitern.

Fuzzing hat sich etabliert, bleibt aber umstritten

"Fuzzing allein ist jedoch keine zuverlässige Methode zur Qualitätssicherung von Software", sagt Sicherheitsberater Brian Chess, Unternehmensgründer von Fortify Software. Der Trend gehe dahin, nicht nur von außen auf die Applikationen zu schauen, sondern die Schwachstellen früher zu erkennen. Chess läutet somit eine neue Runde im Wettstreit um die beste Methode in der sicheren Softwareentwicklung ein.

Schaute man sich den Markt für gängige durchaus professionelle Tools genauer an, dann zeigten sich anhand von Werkzeugen wie Spike, Peach, Protos und vielen anderen mehr, dass sich daraus 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.

Dies sei auch deshalb der Fall, weil die Werkzeuge sogar ein latentes neues Managementproblem generierten, ähnlich wie bei der automatischen Einbruchsabwehr. Denn zahlreiche Fehlalarme gebe es nicht nur bei der Intrusion Detection, sondern auch beim Fuzzing. Die mit allerlei Informationen gespickten und überbordenden Fehlerberichte gelte es jedoch nur nach sinnvollen Kriterien auszuwerten, so dass der Aufwand aus dem Ruder laufe.

Doch auch bei anderen Methoden wie der statischen Quellcodeanalyse machen Experten durchaus ähnliche Vorbehalte geltend. Wie also sollen die Betriebe gezielt in die sichere Softwareentwicklung investieren?

---

Problemfeld Testautomation

Welche wirtschaftlich sinnvollen Planungs- und Analyseinstrumente dazu bereit stehen, erläutert Wolfgang Platz, Geschäftsführer der Tricentis Technology & Consulting GmbH in Wien.

Er benennt zunächst einmal die wichtigsten Herausforderungen. Dies sei generell der unkoordinierte Prozess von der Anforderung bis zum Entwicklungsauftrag, der sich im fehlenden TestCase-Design und seiner Spezifikation auswirke. "Die Tests geschehen vielfach immer noch intuitiv", bilanziert der Experte. Infolgedessen greife die mangelnde Testabdeckung selbst bei vorhandenem methodischem TestCase-Design um sich, speziell durch ineffiziente oder gar fehlende Regressionstests.

Dies zieht weitere Folgeprobleme nach sich. "Mit zunehmender Komplexität steigt der Bedarf an regressiven Tests massiv an", gibt Platz zu bedenken. Das zentrale Problem liege darin, dass sich zwar die Softwarequalität deutlich verbessert habe, jedoch die Testautomation seit gut zwei Jahrzehnten nach wie vor auf "Skripten" basiere. "Die Abdeckungsgrade, die Testautomaten erreichen konnten, sind mit script-basierten Vorgehensweisen aufgrund des Wartungsproblems sehr gering", kritisiert der Experte.

Diesem latenten Missstand will Tricentis durch seine TOSCA TestsuiteTM entgegenwirken. Diese ermöglicht laut Anbieter durch eine auf das Business ausgerichtete dynamische Steuerung einen Paradigmenwechsel. So sei ein Testfall in TOSCA rein fachlich aufgebaut, gewartet und ausgeführt. "Es ist dafür kein Programmieraufwand nötig, es können fachliche Tester vollinhaltlich zum Test herangezogen werden - und die Wartungskosten der Testautomation sinken auf einen Bruchteil gegenüber der individuellen Test-Frameworkprogrammierung", argumentiert Wolfgang Platz.

Dadurch sei es möglich, die Effizienz im SW-Entwicklungs- und -wartungszyklus deutlich zu erhöhen. Am besten in den Griff bekommen lässt sich die komplexe Materie aber mit Hilfe einer durchgängigen klassischen Projektplanung. Unternehmen sollten dazu nach Auffassung von Tricentis bereits im Vorfeld eine funktionale Gliederung aufbauen und diese mit ihren Geschäftsrisiken gewichten. "Daraus entsteht eine Priorisierung, die konsequent eingehalten werden muss", sagt Wolfgang Platz.

Auf der anderen Seite gilt es jedoch bestimmte Limits einzuhalten und etwa darauf zu achten, dass die Kosten nicht allzu sehr aus dem Ruder laufen. Insbesondere kleinere Unternehmen können sich aufwändige Tests etwa zu Webapplikationen ohnehin kaum leisten. "Die schlechte Nachricht ist die, wer sich den Test nicht leisten kann, der sollte erst gar nicht entwickeln", fasst der Geschäftsführer von Tricentis zusammen.

Mit der TOSCA-Testsuite stehe jedoch eine hocheffiziente Testautomation als "Standard-Lösung" bereit. Die SW-Testautomation sei somit analog zu den heutigen Anbietern skriptbasierter Lösungen auch für kleinere Unternehmen erschwinglich, bilanziert Wolfgang Platz. Trotz dieser graduellen Fortschritte stellt sich für jedes Unternehmen die Qual der Methodenwahl.

Fachabteilungen einbinden

Unabhängig davon, ob sich diese für Fuzzing, statische Quellcodeanalyse oder automatisierte Steuerung mit Hilfe funktionaler Prüfungen entscheiden: Es gilt, die jeweiligen Fachabteilungen umfassend in den Prozess einzubinden. Dazu gehören neben der Definition der fachlichen Anforderungen, der Ausarbeitung der fachlichen Spezifikation und dem TestCase-Design bzw. -Spezifikation auch manuelle Tests.

Das aufwändige Verfahren der statischen Quellcodeanalyse dürfte sich derzeit nur für Big Player rechnen, die zahlreiche eigene und sicherheitskritische Applikationen entwickeln. Ansonsten genießen klassische Methoden der Codeprüfung durch menschliche Ressourcen den Vorzug, da diese wesentlich effizienter zu steuern sind. Nach dem Test ist jedoch bekanntlich vor dem Test. Und nicht immer bedeutet der Systemabsturz eines Programms auch tatsächlich die ursprünglich befürchtete Katastrophe.

Das Eis zwischen Exploit und real ausgenutzter Schwachstelle ist dementsprechend dünn. Für die Spezialisten bedeutet dies, die kritische von der unkritischen Bestandsaufnahme heraus zu filtern. "Invalider Input ist reine Zeitverschwendung" bilanziert Brian Chess. Der Sicherheitsexperte plädiert deshalb für ein friedliches Nebeneinander von statischer Quellcodeanalyse und flexiblem Testen. Insbesondere bei großen Konzernen und Unternehmen, die eigene Applikationen entwickelten und betrieben, greife Fuzzing oftmals zu kurz.

Koexistenz unterschiedlicher Methoden zeichnet sich ab

Die offenbar erhöhte Nachfrage nach neuen Werkzeugen ist allerdings auch 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 eingegrenzten Lösungsbeitrag voraus. Simple Tests seien kein Ersatz, um extensive formale Testverfahren und -prozeduren zu ersetzen.

Nach Brian Chess ist die statische Quellcodeanalyse auf dem Vormarsch, weil sie besser funktioniere, als wenn der Input beim Fuzzing zweimal nicht über ein stimme, formuliert er sein unternehmerisches Credo. So könnte der Nischenmarkt in den nächsten Jahren weiter reifen.

Denn auch andere Anbieter wie Coverity, Klocwork, Ounce oder FindBugs haben sich auf ähnliche Dienstleistungen spezialisiert, jedoch mit feinen aber gewichtigen Unterschieden. So setzt Coverity etwa gegenüber anderen Spezialisten aus dem Spektrum der Architekturanalyse vor allem auf seine Pfadsimulations-Maschine "Boolean Satisfiability Engine" (SAT-Engine).

Mit deren Hilfe soll sich die falsche Positivrate weiter nach unten drücken und es sollen sich zusätzliche Defekte auf neuartige Weise identifizieren lassen, etwa Pufferüberläufe und Integerüberläufe. "So stellen wir sicher, dass die meisten Punkte, die wir melden, auch tatsächlich relevante Probleme sind", bringt Unternehmenschef Ben Chelf von Coverity die Vorteile auf den Punkt.

Aus Sicht der Anwender gilt vor allem ein Gebot, nämlich die derzeit dargebotene Vielfalt genauer unter die Lupe zu nehmen. Etwa auf die Aspekte Zielgenauigkeit (False-Positive-Rate), die Bandbreite und Tiefe der Analysewerkzeuge, die Skalierbarkeit bzw. die Anpassungsfähigkeit. Hinzu kommen weitere und zusätzliche Sicherheitsmerkmale nach dem Motto "Wer testet eigentlich die Testwerkzeuge?"

Schließlich sind bei der statischen Quellcodeanalyse nur jene Informationen zu greifen, die Spezialisten für das Auffinden von bestimmten Fehlerarten benötigen. Lediglich diese Informationen bilden jedoch das Rohmaterial für die weitere Analyse. Letztlich kommen auch bei der Quellcodeanalyse, ähnlich wie beim Fuzzing, immer wieder stark vereinfachte Annahmen zum Einsatz. Dies geschieht mit dem Ziel, etwa die Anzahl der möglichen Benachrichtigungen zu einem bestimmten Teilaspekt oder Programm möglichst niedrig zu halten.

---

Fazit: Statische Quellecodeanalyse neuer Schlüssel zur sicheren Softwareentwicklung?

Letztlich stellt sich zudem die Frage, welche Kosten ein derart aufwendiger Monitoring-Prozess am Ende für die Betriebe verursacht, mit Blick auf die Kalkulier- und Steuerbarkeit des Return-on-Invest (ROI). Steigende regulatorische Auflagen etwa im Sinne der IT-Compliance dürften dem Markt für neuartige Analysewerkzeuge zwar einen gewissen Auftrieb verleihen.

Dies geschieht jedoch etwa bei Banken vor allem mit dem Motiv, hinterher umfassend dokumentieren zu können, alles Erdenkliche getan zu haben. Sollte ein Angreifer tatsächlich die eine oder andere Schwachstelle ausnutzen, bliebe den Betrieben zumindest ein allzu leichter Rückgriff auf mangelnde interne Prozesse in der Softwareentwicklung erspart. Ob die Produkte dadurch sicherer sind, steht auf einem anderen Blatt.

Bilanzierend lässt sich feststellen, dass sich ein derartiger "Full-Service" rund um das sichere Softwaredesign auf Basis der statischen Analyse allenfalls für größere Unternehmen und Konzerne lohnt, die ohnehin mit einem größeren Aufwand eigene Applikationen entwickeln und betreiben. Letztlich lassen sich dadurch im einen oder anderen Fall zumindest hohe Folgekosten für die spätere Fehlerbeseitigung von Bugs sparen. Für kleinere Betriebe wäre dies hingegen kein schlagendes Argument, weil der Aufwand bei der Anpassung in der Regel eindeutig zu hoch wäre.