Haftung und Penalties für Softwarehersteller oder…durchstarten mit Thread Modeling und Fuzzing – Teil 2

Teil 1 http://secunews.de/wordpress/?p=1275 des Artikels vom 25.1. sollte den Mißstand in der heutigen Softwareentwicklung aufzeigen, suchte nach Maßstäben, wie man Software kritisch bewerten sollte, und wie man die Hersteller in die Haftung einbeziehen könnte. Die nächsten bedeutenden Fragen lauten, „was können wir besser machen“ und vor allem „wie schützen wir uns“ in der Übergangsphase bis die Hersteller auch wirklich haften?

In der Softwareentwicklung wird massiv eingespart. Daran gibt es keinen Zweifel. Die großen Unternehmen und mittlerweile auch immer mehr Mittelständler lassen in Indien entwickeln. In Indien entwickeln zu lassen, bedeutet nicht zwangsweise, dass die Software auch geographisch in Indien hergestellt wird. Das meist angewandte Mixmodell, das ich bei meinen Sicherheitsberatungen immer zur Kenntnis nehme ist, dass Inder beim Kunden in Deutschland sitzen, vor Ort entwickeln, und Teile der zu erstellenden Software aus Indien anfordern, in dem Beschreibungen oder angefangene Entwicklungen (Programmcode) in Indien erstellt – bzw. weiter- oder fertigentwickelt – werden. Diese hergestellten Programmteile oder ganze Programme, Routinen, etc. aus Indien, werden dann wieder in Deutschland beim Kunden eingearbeitet. Das macht das Ganze noch billiger, aber es birgt eine große Gefahr. Inder sprechen zweifelsohne verdammt gut Englisch, dennoch entstehen aus dem „Stille Postspiel“ auch viel mehr Mißverständnisse, was die Anforderungen an die zu erstellen Software angehen. Man ist nicht mehr so zufrieden wie in den Anfangsphasen der Auslagerung nach Indien. Immer mehr Fehler, immer mehr Sicherheitslücken werden durch dieses Modell eingebaut. Häufig wechselnde Programmierer, Zeitverschiebung, die Nichtteilnahme an den kritischen Meetings in Deutschland von den in Indien ansässigen Programmierern, die alles vom Kollegen vor Ort in Deutschland mitgeteilt bekommen, tragen dazu bei. Und es ist menschlich. Und es ist billig. Es ist gewollt.

Mittlerweile ist das Verhältnis in den Dax-Unternehmen derart, dass man 60% nach Indien auslagert, und versucht 40% durch lokale Ressourcen abzudecken. Die 40% Ressourcen vor Ort haben den Auftrag, 90% der aufkommenden Fehler aus den 60% Outsourcing zu kompensieren. Das ist das Ziel. Eine schwierige Aufgabe. Doch es wird nur zu nicht einmal 30% erreicht. Das ist die Statistik, die durch die Aussage der Manager zustande kam, die für die Vergabe der Aufträge verantwortlich sind. Und das sehe ich Tag für Tag. Immer wieder.  

Die Unternehmen, die einheimische Ressourcen zur Softwareentwicklung heranziehen, weichen meist auf Rapid Prototyping aus. Eine Methode, mit der man billig und gut, ziemlich schnell voran kommt in der Softwareentwicklung, die aber immer noch doppelt so teuer ist wie eine Entwicklung in Indien. Setzt man Rapid Prototyping ein, ist nach der ersten Entwicklungsphase ein Softwarereview fällig. Viele Unternehmen lassen nach einer Rapid Prototyping-Entwicklung“ einen Source-Code-Review sowie klassiche Pentests durchführen. Doch noch wenige denken an Fuzzing. Thread-Modeling ist bei z.B. Rapid Prototyping keine Option. Rapid Prototyping zielt darauf ab, möglichst schnell von 0 auf 100 zu kommen in der Softwareentwicklung. Dadurch bleibt Thread Modeling erst einmal auf der Strecke, es würde behindern.  

Die Sache wie wir entwickeln – entwicklen lassen – hat noch eine weitere Komponente. Eine soziale Komponente, die wir immer wieder vergessen bzw. außer Acht lassen, weil sie uns nicht direkt berührt. Welcher CIO kümmert sich nach Abschluss eines Vertrages schon darum, in welcher sozialen Umgebung diese Programmierer leben? Als ich bei meinem Kunden vor Ort in der Weihnachtszeit einen wirklich sehr freundlichen indischen Programmierer kennen lernte, fragte ich ihn, ob er am Abend auch zur Weihnachtsfeier des Kunden käme. Er wußte nichts davon, bejahte aber, dass er gerne mitkommen wolle. Da er kein Auto hatte bot ich ihm an, ihn abzuholen. Er freute sich und so geschah es. Ich holte ihn an der besagten Adresse in Köln ab. Dabei bot sich mir ein wirklich grausames Bild. In einer 3-Zimmer-Wohnung teilten sich ungelogen 11 Programmierer die ca. 80 Quadratmeter. Fast 4 Personen teilten sich einen Raum. Da ging mir ein völlig anderes Licht auf. Die meisten dieser Helden hatten in Indien Familen und Kinder. Als ich das sah, war mein erster Gedanke, dass wir etwas ganz Großes, was mit sparen oder Technologie nichts zu tun hat, falsch machen. Ich nahm ihm mit, wir fuhren in den Medienpark in Köln, und auf dem Weg dorthin erzählte er mir, dass dieser Lebensstil Usus wäre. Mich erinnerte es irgendwie an Kinderarbeit. Es wurde dennoch ein schöner Abend.

Ich arbeite seit 20 Jahren in der Informationssicherheit. Ich habe ein wirklich gutes Auskommen damit, schon immer gehabt. Gäbe es keine schlechte Software, wäre ich vermutlich ein armer Mann, oder Berufspilot. Doch mir kommt immer wieder die Aussage, die Bruce Schneier machte, in den Sinn. Wir geben wirklich weltweit Milliarden Euro aus, um Unternehmen abzusichern. Das, allein aus dem Grunde, dass es keine sicheren Produkte gibt. Dass die Softwareherstellung schlecht ist. Doch das muss nicht sein. Wenn wir bei der Entwicklung von Software schon auf die Sicherheit achten, müssen wir nicht nachsichern. Wir können uns das ganze Sammelsurium an Sicherheitsmaßnahmen im (nicht nur!) Nachgang sparen.

Hierzu möchte ich Ihnen unbedingt die Methoden Threat Modeling und Fuzzing näher bringen. Die nachfolgenden Zeilen sind von dem Mann, der in dieser Disziplin in Deutschland den Hut auf hat. Hr. Prof. Dr. Hartmut Pohl. Hr.Prof. Pohl packt das Übel an der Wurzeln. Er hat mit seinem Institut in Bonn-Siegen mittlerweile eine Kompentenz erlangt, die einzigartig ist in der geographischen Forschungslandschaft in Deutschland. Durch einen riesigen Forschungsauftrag, konnte er Einsicht nehmen in nahezu alle gängigen Fuzzing-Tools der Welt. Es kennt jedes, und er weiß, was welches Tool kann. Er hat so viele Details im Kopf, dass er das ultimative Thread Modeling und Fuzzing Tool bauen könnte. Die GFFT e.V. sucht dafür aktuell einen Industriesponsor für das Institut von Herrn Prof. Dr. Pohl.

Mit dem Einsatz von Tools zum Threat Modeling (Designphase) und Fuzzing (Verifikationsphase) werden auch bisher nicht veröffentlichte Sicherheitslücken identifiziert. Sie erfordern einen weitaus geringeren Aufwand, als wenn die Software schon ausgeliefert ist (Release-Phase) und erst dann korrigiert werden kann – vgl. Abb. 1: Lebenszyklus der Entwicklung sicherer Software. Zudem lassen sich diese Verfahren für alle Anwendungsbereiche einsetzen: Individualsoftware, Standardsoftware wie ERP, CRM und auch unternehmensspezifische Ergänzungen, Betriebssysteme, Webbrowser, Webapplikationen, Netzwerk-Protokolle etc. einsetzen.

Der Einsatz herkömmlicher Verfahren zur Behebung von Fehlern und insbesondere nicht veröffentlichten Sicherheitslücken ist sehr kostenaufwändig – viele Sicherheitslücken werden erst nach der Auslieferung der Software an die Kunden – z.T. auch von Dritten erkannt.

Den exponentiell steigenden Aufwand zur Behebung (Patchen) von Sicherheitslücken zeigt Abb. 2: Kosten der Behebung von Sicherheitslücken in den Software-Entwicklungsphasen. Tatsächlich steigt der Patchaufwand nach einigen Untersuchung – u.a. des National Institute of Standards and Technology (NIST) – in der Designphase zur Release-Phase auf das 100-fache.

Aus eigenen Untersuchungen wissen wir, dass der Aufwand zur Identifizierung von Sicherheitslücken mit Threat Modeling und Fuzzing sehr kostengünstig durchgeführt werden kann – auch wenn sich die Software schon auf dem Markt befindet.

Sicherheitslücken werden wie folgt erkannt:

1.  Systematische Suche nach Sicherheitslücken mit den Verfahren Threat Modeling und Fuzzing.

2.  Identifizieren der wesentlichen, schwerwiegendsten, (remote) aus dem Internet leicht ausnutzbaren Sicherheitslücken und bewerten der übrigen Sicherheitslücken (Priorisierung).

Fuzzing benötigt zum Erfolg keinen Quellcode (Blackbox-Test): Die Software wird während Ihrer Ausführung untersucht. Hierzu kann die Software in einer Virtuellen Maschine oder auf einem anderen Testsystem ausgeführt werden.

 

Abb. 1: Lebenszyklus der Entwicklung sicherer Software

1    Keine Software ohne Fehler?

Software kann nicht fehlerfrei erstellt werden. Dies macht eine Überprüfung der Software erforderlich, wobei eine enge Bindung zur Qualitätssicherung besteht. Manuelle Überprüfungen sind angesichts des meist großen Code-Umfangs nicht praktikabel.

In der Welt des traditionellen Software Testing gibt es keine Sicherheitslücken im Design und in der Software Implementierung und (unter Sicherheitsaspekten) nur vollkommene Benutzer. Ziele von Tests sind allein die spezifizierten Funktionalitäten, die getestet werden. Nicht-funktionale Tests werden vernachlässigt.

Mit den Verfahren Threat Modeling und Fuzzing können Sicherheitslücken erkannt werden, die die beispielsweise die folgenden Angriffe ermöglichen:

  • Verletzung der Zugriffsregeln
  • Formatstring-Angriffe
  • SQL-Injections
  • Buffer Overflows.

Beim Fuzzing werden hierzu die Eingabeschnittstellen (Attack Surface) gerade mit solchen Eingaben attackiert, die nicht spezifiziert sind, wodurch ein Fehlverhalten der Software provoziert wird. Beim Threat Modeling werden auch Design-Fehler erkannt, indem z.B. Angriffsbäume und Datenflussdiagramme ausgewertet werden.

2    Software-Entwicklungszyklus

Software wird unter Einsatz von Methoden hergestellt, die Sicherheitslücken nicht vollständig vermeiden können – menschliche Fehler können nicht ausgeschlossen werden; selbst wenn Programmierrichtlinien vorhanden sind, werden sie nicht (vollständig) eingehalten und nicht (vollständig) kontrolliert. Dabei existieren wirkungsvolle Tools weit über klassische Verfahren des Testing hinaus, die Sicherheitslücken bereits in der Designphase identifizieren (Threat Modeling) oder spätestens in der Verifikationsphase (Fuzzing und Penetration Testing) – allzu viele Sicherheitslücken werden aber nach wie vor erst dann identifiziert, wenn Software an den Kunden ausgeliefert ist. Im Folgenden werden die Methoden zur Identifizierung von Sicherheitslücken dargestellt und einige bekannte Tools genannt.

Die Kosten zur Beseitigung von Softwarefehlern, sind abhängig von deren zeitlicher Entdeckung im Software Development Lifecycle (SDLC).

Werden Fehler erst nach dem Release – beim Endkunden – entdeckt, steigen die Kosten um den Faktor 100 – vgl. Abb. 2: Kosten der Behebung von Sicherheitslücken in den Software-Entwicklungsphasen.

Die Qualität von Softwareprodukten ist häufig auf mangelnde Ressourcen in den entwickelnden Unternehmen zurückzuführen. Zudem werden vom Markt sehr kurze Produktlebenszyklen vorgegeben. Dadurch lassen sich Fuzzing und Threat Modeling, als marktgerechte Methode zur Entdeckung von Softwarefehlern nutzen. Hier werden im Vergleich zu traditionellen Methoden nur wenige Ressourcen benötigt – so zeigen Untersuchungen in Projekten von softScheck.

Mittels Fuzzing und Threat Modeling werden Softwarehersteller, Nutzer und solche, die Standardsoftware anpassen (Customizing) in die Lage versetzt, Software-Tests wirkungsvoller und kostengünstiger mit den für ihre Aufgabenstellung geeigneten Tools durchzuführen und dadurch die Software sicherer zu machen: Mit Hilfe dieser Tools lassen sich bisher nicht erkannte Fehler und Sicherheitslücken erkennen.

Im Rahmen des vom Bundesministerium für Bildung und Forschung an der Hochschule Bonn-Rhein-Sieg geförderten Projektes (FKZ 01 IS 09030) softScheck werden über 100 weltweit verfügbare Tools zum Threat-Modeling und Fuzzing analysiert und bewertet.

Abb. 2: Kosten der Behebung von Sicherheitslücken in den Software-Entwicklungsphasen

3    Threat Modeling

Dieses proaktive und heuristische Verfahren unterstützt die methodische Entwicklung eines vertrauenswürdigen Systementwurfs oder einer Architektur in der Design Phase – sodass dies am kosteneffizientesten ist.

Gleichermaßen lassen sich bereits bestehende Systementwürfe und Architekturen verifizieren, mit dem Ziel der Identifizierung, Bewertung und Korrektur von Sicherheitslücken.

Abb. 3: Fehlerbäume im Threat Modeling

  • Vorgehen beim Threat Modeling
  • Analyse der Dokumentation (falls vorhanden) – insbesondere des Sicherheitsdesigns oder des Quellcodes.
  • Untersuchung der Programmablaufpläne
  • Beschreibung und Priorisierung erkannter sicherheitsrelevanter Designfehler
  • Entwicklung von Fehler Bäumen (attack trees) – vgl. Abb. 3: Fehlerbäume im Threat Modeling
  • Report Generation: Bericht und Vorgehensempfehlungen für erkannte Sicherheitslücken

Ziel ist weiterhin das Verständnis der Sicherheitsarchitektur, das Erkennen von Designfehlern und die Minimierung möglicher Angriffspunkte (Attack Surface).

Einige Threat Modeling Tools

  • Microsoft Threat Analysis & Modeling
  • Microsoft SDL Threat Modeling Tool
  • Trike

Die Anzahl an gefundenen Sicherheitslücken durch Threat Modeling ist erheblich. So wurden in einem Projekt der Autoren kritische Sicherheitslücken bereits in der Designphase identifiziert, die aus dem Internet ausnutzbar wären – vgl. Abb. 4: Mit Threat Modeling erkannte Sicherheitslücken in Standardsoftware.

Abb. 4: Mit Threat Modeling erkannte Sicherheitslücken in Standardsoftware

4    Static Analysis

Dieses Verfahren analysiert den Quellcode, ohne ihn auszuführen (im Gegensatz zur Dynamic Analysis, wozu u.a. Fuzzing zählt). Dabei wird in der Implementierungsphase die Konformität mit der Programmiersprache und den Programmierrichtlinien überprüft – wie ein Parser, der eine lexikalische, syntaktische und semantische Analyse des Programmcodes durchführt.

Einige Static Analysis Tools

  • Pixy
  • XDepend

5    Fuzzing

Beim Fuzzing wird die Robustheit der untersuchten Software mit willkürlichen oder auch zielgerichteten Daten überprüft.

So kann sporadische Betriebsausfällen und unbeabsichtigten Datenabflüssen – den häufigsten Folgen sicherheitsrelevanter Softwarefehler – entgegengewirkt werden und so proaktiv hohe Umsatzausfälle, Datenschutzprobleme und Reputationsschäden gemindert werden.

Dazu werden beim Fuzzing Eingabeschnittstellen identifiziert, an die die Daten gesendet werden.

Die Qualität von Fuzzern hängt im Wesentlichen von der Größe des getesteten Eingaberaums (der unendlich ist) und der Qualität der erzeugten Daten ab.

Der Fuzz-Testing Prozess ist in der Verifikationsphase des SDLC angesiedelt – vgl. Abb. 1: Lebenszyklus der Entwicklung sicherer Software. Hier sollten Fehler spätestens behoben werden, da die Kosten nach dem Release erheblich ansteigen wenn Fehler erst später gefunden werden – siehe Abb. 2: Kosten der Behebung von Sicherheitslücken in den Software-Entwicklungsphasen.

Wurden die Eingabeschnittstellen der Zielanwendung identifiziert und die vom Fuzzer erzeugten Daten an die Zielanwendung geschickt, überwacht ein Monitoring-Tool die Zielanwendung und meldet dem Tester Anomalien wie z.B. Programmabstürze, hohe CPU- oder Speicher-Auslastung etc. – vgl. Abb. 5: Fuzzing-Prozess.

Im Anschluss erfolgt durch den Security Analyst eine Analyse, in der u.a. die Reproduzierbarkeit, Ausnutzbarkeit aus dem Internet und die Schwere der Sicherheitslücke bestimmt werden.

Für das Fuzzing wird der Quellcode der Zielanwendung nicht benötigt, was die Einbeziehung externer Security Analysten vereinfachen kann.

Abbildung 5: Fuzzing-Prozess

Je nach Typ lassen sich Fuzzer lokal und remote einsetzen. Zu den lokalen Fuzzern werden z.B. die Kommandozeilen-Fuzzer gezählt.

Netzwerkbasierte Anwendungen werden remote gefuzzed. Dazu kommen Fuzzer, die Web-Applikationen und Browser fuzzen.

Weiterhin können sog. dumb und smart Fuzzer unterschieden werden.

Smart-Fuzzer testen programmgesteuert selbständig ein Zielprogramm – oftmals ohne weitere Vorbereitung oder Begleitung durch den Anwender; sie sind häufig lizenzpflichtig. Ein wichtiges Bewertungskriterium für Fuzzer ist die Testabdeckung (code coverage); häufig ermöglichen nur smart Fuzzer das Eindringen in das Zielprogramm und Austesten des Programmcodes.

Dumb-Fuzzer können den Aufbau des Zielprogramms nicht erkennen und sie generieren nur ungesteuerte Eingabedaten. Wegen dieser fehlenden Programmsteuerung setzen sie eine erhebliche Erfahrung beim Anwender voraus; dafür sind sie häufig entgeltfrei aus dem Internet herunterladbar – vgl. Abb. 6: Divergenz Produktkosten – Personalaufwand.

Fuzzing Frameworks bieten die beste Möglichkeit der eigenen Zielanwendung angepasste Fuzzer zu entwickeln – ähnlich einem Baukasten. Der Entwicklungsaufwand ist jedoch verhältnismäßig hoch – zumal für alle gängigen Anwendungen bereits fertig nutzbare Fuzzer existieren. Fuzzing Frameworks eignen sich besonders bei neuen proprietären Zielanwendungen wie z.B. neue Netzwerkprotokolle.

Kommerzielle Tools zeichnen sich häufig durch die Abkehr von der Kommandozeilensteuerung zu einer graphischen Benutzeroberfläche aus.

Einige Fuzzing Tools

  • AxMan
  • beSTORM
  • Defensics
  • FileFuzz
  • FTPStress Fuzzer
  • Fuzz
  • Peach
  • SPIKE
  • SPIKEfile

 

Abb. 6: Divergenz Produktkosten – Personalaufwand

6    Ergebnisse

Mit Fuzzing und Threat Modeling stehen Tool-gestützte Verfahren zur Detektion von insbesondere sicherheitsrelevanten Softwarefehlern zur Verfügung. So kann Zero-Day-Angriffen, welche eine der zwanzig am häufigsten auftretenden Angriffsformen sind, entgegenwirkt und die Anwendungssicherheit effizient und marktgerecht gesteigert werden. Dabei lässt sich der Fuzzing Ansatz durch die zur Verfügung stehenden Methoden, adäquat auf die kürzer werdenden Software-Entwicklungszyk­len skalieren.

Ergebnisse des Verfahrenseinsatzes

  • Systematische Suche und auch erfolgreiche (!) Identifizierung der wesentlichen Sicherheitslücken.
  • Und zwar in jeder Software: Individualsoftware, Standardsoftware wie ERP, CRM und auch unternehmensspezifische Ergänzungen, Betriebssysteme etc.
  • Kein Quellcode wird zum Threat Modeling und Fuzzing benötigt – ausführbare Dateien reichen völlig aus: Black-Box.

Bei Softwareherstellern kann durch die Kombination der erläuterten Verfahren und die Integration in den SDLC eine höhere Return on (Security) Investment erreicht werden. Zudem kann proaktiv die Qualität der Software gesteigert, Markteinführungszeiten reduziert und Kosten gespart werden.

Neben der Kostenersparnis kann die Reputation des Softwareherstellers – durch sicherere Software – gesteigert werden.

Threat Modeling und Fuzzing kann für alle Anwendungsarten eingesetzt werden – von Protokollen bis hin zur Individualsoftware und Webapplikationen. Zur Unterstützung bei einer bedarfsgerechteren Auswahl von geeigneten Tools hat das Projekt softScheck eine Taxonomie entwickelt, die gesondert veröffentlicht wird.

Die Anzahl an gefundenen Sicherheitslücken durch Fuzzing (meist ohne Vorliegen des Quellcode) ist enorm. Dies ist der Grund für die zunehmende Verbreitung und Beliebtheit des Verfahrens.

So wurden in einem Projekt der Autoren in bereits an Kunden ausgelieferter Standardsoftware fünf kritische (bisher nicht unveröffentlichte) Sicherheitslücken identifiziert, die aus dem Internet ausnutzbar waren – vgl. Abb. 7: Mit Fuzzing erkannte Sicherheitslücken in Standardsoftware. Dies obwohl beim Hersteller ein umfangreiches Richtlinienwerk auch hinsichtlich der Programmierung ’sicherer‘ Software existiert.

Abb. 7: Mit Fuzzing erkannte Sicherheitslücken in Standardsoftware

Die erfolgreichen Verfahren

  • Threat Modeling: Sicherheitslücken werden bereits in der Designphase identifiziert.
  • Systematische und Tool-gestützte Verfahren.
  • Sicherheitslücken können priorisiert werden: Aus dem Internet ausnutzbar und/oder geringer Aufwand für den Angreifer.
  • Fuzzing
  • Black-Box – kein Quellcode erforderlich – ausführbare Dateien reichen völlig aus!
  • Gängige Verfahren – seit mehr als 5 Jahren bei den weltweit größten Softwarehäusern im Einsatz – auch in KMU.
  • Static Analysis
  • Tool-gestütztes Code Reading ergänzt die beiden Verfahren.

Dies sind die kostengünstigsten Verfahren zur erfolgreichen Identifizierung von Sicherheitslücken.

In den bisher mehr als 40 durchgeführten Software-Prüfungen wurden von uns durchschnittlich pro Produkt mehr als 50 kritische – aus dem Internet ausnutzbare – Sicherheitslücken identifiziert.

Alexander Tsolkas