Identifizierung bisher nicht erkannter Sicherheitslücken

Software-Sicherheit Identifizierung bisher nicht erkannter Sicherheitslücken und Fehler in Standard- und Individualsoftware sowie Hardware mit den Verfahren Threat Modeling, Static Source Code Analysis und Dynamic Analysis: Fuzzing Prof. Dr. Hartmut Pohl Geschäftsführender Gesellschafter softscheck GmbH Köln Hartmut.Pohl@softScheck.com www. softscheck.com

Software-Sicherheit Identifizierung bisher nicht erkannter Sicherheitslücken und Fehler in Standard- und Individualsoftware sowie Hardware mit den Verfahren Threat Modeling, Static Source Code Analysis und Dynamic Analysis: Fuzzing Hartmut Pohl 1 Software enthält Fehler und kann nicht fehlerfrei erstellt werden. Das macht eine Überprüfung der Software erforderlich. Manuelle Überprüfungen sind angesichts des meist großen Code-Umfangs nicht praktikabel. Der Einsatz herkömmlicher Verfahren zur Behebung funktionaler Fehler und insbesondere nicht-erkannter Sicherheitslücken (Vulnerabilities) ist sehr kostenaufwändig - viele Vulnerabilities werden daher erst nach der Auslieferung der Software an Kunden - z.t. auch von Dritten erkannt. Die Identifizierung bisher nicht erkannter Vulnerabilities ist wichtig, weil sie das (einzige technische) Einfallstor für Angriffe sind: Ohne Vulnerability kein erfolgreicher Angriff. Bisher nicht erkannte Fehler und Vulnerabilities können kostensparend Tool-gestützt identifiziert werden: Mit den drei Verfahren Threat Modeling, Static Source Code Analysis und Dynamic Analysis: Fuzzing letzteres sogar ohne den Quellcode zu kennen. Diese Verfahren werden von einer ganzen Reihe von Anwender- Unternehmen und großen und kleinen Software-Herstellern zur rechtzeitigen Identifizierung von Vulnerabilities und damit auch Kostenreduzierung des gesamten Patchverfahrens erfolgreich eingesetzt. Endanwender nutzen das Verfahren auch zur Abnahmeprüfung von Software. Sicherheitslücken können so in jeder Art Software - angefangen von Protokollen bis hin zu Individualsoftware, Standardsoftware wie ERP, CRM, Datenbanksystemen und auch für unternehmensspezifische Anpassungen an Standardsoftware (Customizing), Web-Applications, Betriebssysteme und auch in Hardware und Embedded Systems sowie Industriesteuerungssystemen (ICS) kostensparend identifiziert werden. Klassisches Penetration Testing dagegen umfasst nur die Suche nach bekannten (!) Vulnerabilities (Vulnerability Scanner), nach offenen Ports, bekannten Sicherheitslücken etc. Inhaltsverzeichnis 1. Identifizierung von Vulnerabilities 2 1.1. Kosten der Fehlerbehebung in den Software-Entwicklungsphasen 2 1.2. Ohne Vulnerability kein erfolgreicher Angriff 2 1.3. Software-Entwicklungszyklus 2 1.4. Verfahren zur Identifizierung von Vulnerabilities 3 2. Threat Modeling 4 2.1. Verfahren 4 2.2. Analyse der Datenflüsse 5 2.3. Ausgewählte Tools des Threat Modeling 6 2.4. Threat Modeling Ergebnisse 6 3. Static Source Code Analysis 6 3.1. Verfahren 6 3.2. Ausgewählte Static Source Code Analysis Tools 7 3.3. Static Source Code Analysis Ergebnisse 7 4. Dynamic Analysis: Fuzzing 8 4.1. Verfahren 8 4.2. Typisierung von Fuzzern 8 4.3. Fuzzer und Fuzzing Frameworks 10 4.4. Monitoring der Zielsoftware (Debugger, Profiler, Tracker) 10 4.5. Nachweis von Vulnerabilities 11 4.6. Code Coverage 11 4.7. Wirksamkeit von Fuzzern: Generierung von Fuzz-Daten 12 4.8. Fuzzing Ergebnisse 12 5. Herausforderungen der Identifizierung von Sicherheitslücken 13 5.1. Verfahrenskombination 13 5.2. Tool-Kombination 14 5.3. Monitor Kombination 14 5.4. Expert Advice - Manual Auditing durch IT-Sicherheitsexperten 14 5.5. Rating identifizierter Vulnerabilities 14 6. Erfolge der Tool-gestützten Verfahren 14 1 Prof. Dr. Hartmut Pohl, Informationssicherheit, Fachbereich Informatik, Hochschule Bonn-Rhein-Sieg. softscheck GmbH, Köln

1. Identifizierung von Vulnerabilities 1.1. Kosten der Fehlerbehebung in den Software-Entwicklungsphasen Fehlerbehebung ist umso kostengünstiger, je früher Vulnerabilities in der Software-Entwicklung behoben werden möglichst also in der Requirements- oder Designphase; spätestens aber in der Verifikationsphase und vor dem Release. Den exponentiell steigenden Aufwand zur Behebung (Patchen) von Vulnerabilities zeigt Abb. 1:. Tatsächlich steigt der Aufwand zur Fehlerbehebung (Patch) nach einigen Untersuchungen - u.a. des National Institute of Standards and Technology (NIST) - von der Designphase zur Release-Phase bis auf das 35- bis 100- fache. Costs 35 x Application in the Field 15 x 6 x 1 x Threat Modeling Static Analysis Fuzzing Requirements / Design Implementation Verification / Testing Release Phase Abb. 1: Kosten der Fehlerbehebung in den Software-Entwicklungsphasen Am teuersten wird die Fehlerbehebung, wenn das Produkt schon ausgeliefert ist und beim Kunden mit einem Workaround, temporären Fix oder Patch korrigiert werden muss. Eigene Untersuchungen in Projekten von softscheck zeigen, dass der Aufwand zur rechtzeitigen Identifizierung kritischer Vulnerabilities mit Threat Modeling, Static Source Code Analysis und Fuzzing nur vergleichsweise wenig Ressourcen erfordert; daher lassen sich Threat Modeling, Static Source Code Analysis und Fuzzing als marktgerechte Methode zur Entdeckung von Softwarefehlern nutzen: Der durchschnittliche Personalaufwand pro identifizierter kritischer Sicherheitslücke beträgt etwa 8 Stunden. 1.2. Ohne Vulnerability kein erfolgreicher Angriff Noch wichtiger als die Erkennung funktionaler Fehler ist die Identifizierung und Behebung von Vulnerabilities, weil Angriffe gegen Software und IT-Systeme ausschließlich unter Ausnutzung von Vulnerabilities erfolgreich sind. Für Angreifer relevant sind Vulnerabilities, die noch nicht korrigiert (gepatcht) oder sogar noch nicht veröffentlicht sind. Gegen derartige Angriffe gibt es keine Schutzmöglichkeiten - diese Angriffe können von Anwendern auch gar nicht erkannt werden! 1.3. Software-Entwicklungszyklus Bei der Softwareentwicklung können Vulnerabilities auf Grund menschlicher Fehler nicht vollständig vermieden werden. Selbst wenn vollständige 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 Vulnerabilities bereits in der Designphase (Threat Modeling) oder spätestens in der Verifikationsphase (Fuzzing) identifizieren - allzu viele Vulnerabilities werden aber nach wie vor erst dann identifiziert, wenn Software schon an den Kunden ausgeliefert ist. Im Folgenden werden die Methoden zur Identifizierung von bisher nicht-erkannten Vulnerabilities dargestellt und einige wirkungsvolle Tools genannt. 1. August 2012 Software-Sicherheit: Identifizierung bisher nicht erkannter Sicherheitslücken Seite 2 von 15

Threat Modeling Static Analysis Fuzzing Requirements Design Implementation Verification Release Patch, Fix etc. Abb. 2: Vulnerability Identification im Software Development Process 1.4. Verfahren zur Identifizierung von Vulnerabilities Bisher nicht-erkannte Vulnerabilities lassen sich mit - für die jeweiligen Softwareentwicklungsphasen - speziellen Verfahren identifizieren (Softwareentwicklungsphase und Verfahren zur Identifizierung von Vulnerabilities): 1. Systematische Suche nach Vulnerabilities mit den Verfahren Threat Modeling, Static Source Code Analysis und Dynamic Analysis (Fuzzing). 2. Identifizieren der wesentlichen, schwerwiegendsten, (remote) aus dem Internet leicht ausnutzbaren Vulnerabilities und Bewerten aller anderen Vulnerabilities (Priorisierung). So können Vulnerabilities identifiziert werden, die beispielsweise die folgenden Angriffe ermöglichen: Verletzung der Zugriffsregeln Formatstring-Angriffe SQL-Injections Buffer Overflows. In der Welt des traditionellen Software Testing wird allein die spezifizierte Funktionalität getestet. Nichtfunktionale Tests werden vernachlässigt. Software Development Requirements Design Implementation Verification Release Process Methods Threat Modeling Static Analysis Dynamic Analysis (Fuzzing) Abb. 3: Softwareentwicklungsphase und Verfahren zur Identifizierung von Vulnerabilities 1. August 2012 Software-Sicherheit: Identifizierung bisher nicht erkannter Sicherheitslücken Seite 3 von 15

Beim Threat Modeling werden Design-Fehler identifiziert, indem z.b. Angriffsbäume und Datenflussdiagramme ausgewertet werden. Beim Fuzzing werden hierzu die Eingabeschnittstellen (Attack Surface) gerade mit solchen Eingaben attackiert, die nicht spezifiziert sind, wodurch ein Fehlverhalten der Software provoziert wird. 2. Threat Modeling Im traditionellen Softwareentwicklungszyklus werden Maßnahmen zur Erhöhung des Sicherheitsniveaus von Software meist erst kurz vor Auslieferung der Software - häufig aber auch erst nach Auslieferung der Software - umgesetzt. Da etwa die Hälfte der Fehler auf Designfehler zurückzuführen ist, müssten Sicherheitsmaßnahmen bereits vor bzw. während der Designphase implementiert werden. Threat Modeling unterstützt als heuristisches Verfahren die methodische Entwicklung eines vertrauenswürdigen Systementwurfs und einer Architektur in der Designphase der Softwareentwicklung die Fehlerbehebungskosten sind in dieser Entwicklungsphase noch sehr gering. Der systematische Ablauf des Threat Modelings ist in vier Stufen in Abb. 4 grafisch dargestellt. Sicht eines Angreifers verstehen Sicherheit charakterisieren genutzte Methoden und Threats (Bedrohungen) und Sicherheitslücken identifizieren. In jeder Stufe werden zugehörige Aktionen durchgeführt, mit dem Ziel, das Threat Model genauer zu spezifizieren und weiter auszubauen. Gleichermaßen lassen sich schon bestehende Systementwürfe und Architekturen verifizieren, mit dem Ziel der Identifizierung, Bewertung und Korrektur von Vulnerabilities. Understand the Adversary s View Characterize the System Security Methods used Determine Threats Identify Threats Entry Points Use Scenarios Data Flow Diagram Threat Categorization Assets Assumption Dependencies Threat Analysis Identify Vulnerabilities Trust Levels Modeling Security System Attack Trees DREAD Ranking Abb. 4: Threat Modeling Prozess 2.1. Verfahren Nach vollständiger Identifizierung schützenswerter Komponenten (Assets) sowie zugehöriger Bedrohungen beginnt die Identifizierung von Sicherheitslücken mit der Analyse der Dokumentation insbesondere des Sicherheitsdesigns - sowie einer Untersuchung der Programmablaufpläne. 1. August 2012 Software-Sicherheit: Identifizierung bisher nicht erkannter Sicherheitslücken Seite 4 von 15

1 Abb. 5: Datenflussdiagramm mit Vertrauensgrenzen Die Identifizierung und Bewertung der Bedrohungen und Sicherheitslücken kann z.b. durch die Auswertung von Datenflussdiagrammen (Abb. 5) und Angriffsbäumen (Attack Trees) erfolgen (Abb. 6). Threat #1 Decrypt Company Secrets and 1.1 Obtain Encrypted File 1.2 Obtain Password/Key 1.1.1 Bribe the Sysadmin 1.1.2 Hack the Database 1.2.1 Brute Force Passwd/Key 1.2.2 Use Keylogger Abb. 6: Fehlerbaum im Threat Modeling Auf der Grundlage dieser Analysen erfolgt die Behebung der Sicherheitslücken. Neben den unterschiedlichen, in die Threat Modeling Tools implementierten Maßnahmen (z.b. redesign, standard mitigation, custom mitigation oder accept risk) ist eine individuelle Behandlung einzelner Bedrohungen und Sicherheitslücken sowie die Kontrolle der implementierten Sicherheitsverfahren erforderlich. Im abschließenden Bericht werden die identifizierten Vulnerabilities beschrieben und priorisiert zusammen mit den identifizierten sicherheitsrelevanten Designfehlern und es werden Empfehlungen zur Behebung der identifizierten Vulnerabilities ausgesprochen. 2.2. Analyse der Datenflüsse Datenflussdiagramme unterstützen die Zerlegung eines Systems in überschaubare Teile zur Überprüfung auf Vulnerabilities. Vertrauensgrenzen kennzeichnen die Grenze zwischen vertrauenswürdigen und nicht vertrauenswürdigen Komponenten. Die Erstellung eines korrekten Datenflussdiagramms ist Voraussetzung für ein korrektes Bedrohungsmodell. Ziel ist ein Verständnis der Sicherheitsarchitektur, die Identifizierung von Designfehlern und die Minimierung möglicher Angriffspunkte (Attack Surface). 1. August 2012 Software-Sicherheit: Identifizierung bisher nicht erkannter Sicherheitslücken Seite 5 von 15

2.3. Ausgewählte Tools des Threat Modeling Nützliche Tools sind neben den beiden Microsoft Threat Analysis & Modeling und Microsoft SDL Threat Modeling Tool noch Attack Tree, CORAS, Practical Threat Analysis, Seamonster, SecureITree, Skybox Secure und Trike. 2.4. Threat Modeling Ergebnisse In Untersuchungen wurden in bereits ausgelieferten Systemen jeweils bis zu 30 kritische (aus dem Internet ausnutzbare) Vulnerabilities und high-risk Vulnerabilities sowie 26 medium-risk Vulnerabilities mit Threat Modeling identifiziert (vgl. Abb. 7). Rating the Vulnerabilities critical 1 high 29 medium 26 low 129 Number of Vulnerabilities identified Abb. 7: Mit Threat Modeling identifizierte Vulnerabilities eines Internet-Marktplatzes 3. Static Source Code Analysis Dieses Verfahren analysiert den Quellcode, ohne ihn auszuführen (im Gegensatz zur Dynamic Analysis, wozu u.a. Fuzzing zählt). Ab der Implementierungsphase wird die Konformität des Quellcodes der Zielsoftware (White-Box Test!) mit formalen Methoden auf Einhaltung syntaktischer Programmierkonventionen der Programmiersprache und auf Einhaltung der Programmierrichtlinien überprüft - vergleichbar einem Parser, der eine lexikalische, syntaktische und semantische Analyse des Programmcodes durchführt. Aufgrund lexikalischer Regeln der verwendeten Programmiersprache und den semantischen Zugehörigkeiten benötigen die einzelnen Fehler im Allgemeinen einen manuellen Audit, um false Positives auszuschließen und entsprechende Behebungsstrategien zu entwerfen. Die Qualität und Quantität des Analyse-Resultats hängt somit maßgeblich von der Auswahl geeigneter Tools (und geschultem Fachpersonal) ab. 3.1. Verfahren Static Source Code Analysis (Code Review, statische Source Code Analyse) wird Tool-gestützt automatisiert bzw. semi-automatisiert durchgeführt; die Befunde der Tools werden gesammelt und manuell ausgewertet. Analysiert wird der Quellcode der Zielsoftware ohne ihn auszuführen (vergl. aber Dynamic Analysis: Fuzzing). Der systematische Ablauf der Static Source Code Analysis ist in Abb. 8 grafisch dargestellt. 1. August 2012 Software-Sicherheit: Identifizierung bisher nicht erkannter Sicherheitslücken Seite 6 von 15

Establish Goals Run Tools Review Code Fixing Bugs Reporting Code Understanding Static Analyzer Find Bugs Find Vulnerabilities Generate Report Difference to Specification Target Application Source Code Abb. 8: Static Source Code Analysis Prozess [nach Chess 2007] Im Bereich Static Source Code Analysis werden drei Tool-Klassen unterschieden: Style Checking Tools verifizieren den Source-Code bezüglich der Einhaltung syntaktischer Programmier- Richtlinien. Diese einfachen Tools finden meist keine Fehler, die einen Software-Defekt hervorrufen. Semantic Analysis Tools fügen zusätzliche semantische Informationen zum Syntaxbaum des Compilers hinzu. Diese werden mithilfe verschiedener Regeln auf statisch feststellbare Fehler verifiziert. Typische Fehler sind Datentyp-Probleme, nicht initialisierte Variable und ungenutzte Methoden. Deep Flow Static Source Code Analysis ist die effektivste Toolklasse: Die semantische Analyse wird um eine control-flow graph -Generierung und eine Data Flow Analyse ergänzt. Somit ist es möglich, komplexe Fehler, die etwa auf race conditions, deadlocks oder falscher Pointerverwendung basieren, zu identifizieren. Die Verwendung eines für das jeweilige Zielsoftware geeignete Static Source Code Analysis Produkt ermöglicht die Identifikation folgender Fehlerarten: Uninitialized Variable Null Pointer Dereference Null Test After Dereference Negative Character Value Ignored Return Value Cast Alters Value Unused Value Buffer overflows Integer Overflow of Alocation Size File System Race Condition, Deadlocks, Livelocks Memory Leaks Double Unlock Unreachable Data Flow Unreachable Call Unreachable Control Flow Redundant Condition Use After Free Negative File Descriptor Useless Assignment Unreachable Computation Double Close Security vulnerabilities (z.b. unsichere Funktionen) Aufgrund lexikalischer Regeln der verwendeten Programmiersprache und semantischen Zugehörigkeiten benötigen die einzelnen Fehler im Allgemeinen einen manuellen Audit durch entsprechendes Fachpersonal (Software- Engineering und IT Security), um false Positives auszuschließen und entsprechende Behebungsstrategien zu entwerfen. Die Qualität und Quantität der Analyse-Resultate hängt somit maßgeblich von der Auswahl geeigneter Tools in Verbindung mit angemessen geschultem Fachpersonal ab. Mit Static Source Code Analysis lassen sich komplexere Fehler, die beispielsweise auf der Interaktion verschiedener Module beruhen, nur schwer identifizieren; solche Fehler erfordern den Einsatz von Verfahren wie Fuzzing. 3.2. Ausgewählte Static Source Code Analysis Tools Es existiert eine große Menge von Static Source Code Analysis Tools u.a. Coverity Findbugs, FxCOP, LAPSE, Pixy (open source), RATSs (entgeltfrei), XDepend. Tools sind grundsätzlich spezialisiert auf eine Programmiersprache; nicht alle Tools identifizieren dieselben Fehler, so dass der Einsatz komplementärer Tools nützlich ist. 3.3. Static Source Code Analysis Ergebnisse In einer Reihe von Projekten wurden pro 1.000 Codezeilen bis zu 50 Vulnerabilities identifiziert allerdings mussten darüber hinaus (zeitaufwändig!) ca. 30 false Positives untersucht werden. 1. August 2012 Software-Sicherheit: Identifizierung bisher nicht erkannter Sicherheitslücken Seite 7 von 15

Der Security Analyst muss also die identifizierten Anomalien verifizieren hinsichtlich false Positives und muss mit false Negatives rechnen! False Negatives können noch mit dem Verfahren Dynamic Analysis: Fuzzing identifiziert werden. 4. Dynamic Analysis: Fuzzing Die Robustheit der untersuchten Zielsoftware wird mit zielgerichteten Eingabedaten überprüft; dabei sollen vorhandene Fehler und Sicherheitslücken ausgenutzt und ein anomales Verhalten der Zielsoftware provoziert werden. Beispielsweise können in die Eingabedaten Sonderzeichen eingestreut, bestimmte Zeichen mehrfach wiederholt oder auch überlange Eingaben generiert werden, um z.b. Buffer Overflows zu erreichen. 4.1. Verfahren Die Zielsoftware wird in einem Testbed ausgeführt und untersucht. Hierzu kann die Software in einer virtuellen Maschine oder auf einem anderen Testsystem ausgeführt werden. Das Verfahren Fuzzing benötigt also keinen Quellcode (Black-Box Test). Das häufig vorgeschlagene Brute Force Verfahren, alle Eingabeschnittstellen mit allen technisch möglichen Eingaben (Bit-Kombinationen) zu bombardieren (1. Fuzzer-Generation: Recursive Fuzzing), führt nur selten zum Erfolg und benötigt einen überaus hohen Rechenzeitaufwand. Daher werden Fuzzer eingesetzt, denen Rahmendaten wie z.b. ein Protokollaufbau vorgegeben werden oder die aus regulären Eingabedaten lernen, die relevanten - und damit die zur Identifizierung von Vulnerabilities führenden - Eingabedaten auszuwählen und einzusetzen (2. Fuzzer-Generation: Replacive Fuzzing). Test System Identification Code Coverage Input Interfaces Proprietary Developed Fuzzer Proprietary Developed Attack Strings Fuzzer 0000 0000 1111 1111 Target System Target Application Target Processor ARM, AMD, IBM, Intel, PLC, Sun, Target OS Android, CardOS, JCOB, Nucleus, OS X, QNX, Unix, VxWorks, Windows, S7, Monitor/Debugger Monitor Client Expert Advice: Identification, Rating Proof of Concept: Exploits Report Abb. 9: Fuzzing-Prozess Dazu werden beim Fuzzing Eingabeschnittstellen identifiziert, an die die Daten gesendet werden (vergl. Abb. 9). Eingabeschnittstellen können sein: Netzwerkprotokollaufrufe (HTTP, SMTP, SIP, LDAP etc.), RPC, Web Services, File Formats, Command Line Parameters etc. Im Anschluss erfolgt durch den Security Experten eine Analyse der vom Monitor bereitgestellten Daten, aus denen u.a. die Reproduzierbarkeit (Reproducibility), Ausnutzbarkeit (Exploitability) aus dem Internet und die Schwere von Sicherheitslücken (severity) bestimmt werden. Dies ist der zeitlich aufwändigste Teilprozess des Fuzzing. 4.2. Typisierung von Fuzzern Die Vielzahl auf dem Markt entgeltfrei und entgeltlich erhältlichen Fuzzer ( über 300) macht eine Auswahl der für die jeweilige Zielsoftware geeigneten Fuzzer erforderlich. Je nach Typ lassen sich Fuzzer lokal, remote (network) oder gegen Web-Applications einsetzen. Zu den lokalen Fuzzern werden z.b. die Kommandozeilen-Fuzzer gezählt. Netzwerkbasierte Anwendungen werden remote gefuzzed. Mit speziellen Fuzzern können Vulnerabilities in Web-Applications oder Betriebssystemen identifiziert werden. 1. August 2012 Software-Sicherheit: Identifizierung bisher nicht erkannter Sicherheitslücken Seite 8 von 15

Brute-Force- Static Dumb Smart Intelligent Capture Replay Session-Data Mutation- Stateless Stateful Call-Flow Aware Model- Grammar Block Generation Dynamic Generation Model- Inference Traffic-Analysis Evolutionary Abb. 10: Fuzzer Taxonomie Unterschieden werden können sog. Dumb und Smart Fuzzer: Dumb-Fuzzer (1. Fuzzer-Generation) können die Struktur der Zielsoftware nicht erkennen und generieren nur ungesteuerte Eingabedaten. Wegen dieser fehlenden Programmsteuerung setzen sie eine erhebliche Erfahrung der Anwender bei der Auswertung der Ergebnisse voraus; dafür sind sie häufig entgeltfrei aus dem Internet herunterladbar (vgl. Abb. 10). Smart-Fuzzer (2. Fuzzer-Generation) dagegen testen programmgesteuert eine Zielsoftware - auf der Basis bereitgestellter oder durch Sniffing erkannter Spezifikationen über die Zielsoftware. Smart Fuzzer durchdringen damit auch Sicherheitsmaßnahmen wie Identifizierung und Authentifizierung, (kryptographische) Prüfsummen etc. und prüfen logisch 'dahinter' liegenden Code. Mutation Fuzzer verändern einen korrekten Eingabestrom von Fuzz-Daten und Generation Fuzzer generieren neue Eingabedaten auf der Basis einer vorhandenen Protokollspezifikation. Dynamic Generation Fuzzer analysieren die Protokollspezifikation während ihrer Laufzeit. Stateless Fuzzer modellieren nur Daten und keine Zustände. Block Fuzzer verändern Nutzdaten- und Parameterfelder in einem Protokollblock (nicht die Adressfelder o.ä.). Stateful Fuzzer berücksichtigen interne Zustände des Zielprogramms. Klassifizierung nach Einsatzzweck Fuzzer unterstützen entweder konkret definierte Schnittstellen oder sie sind universell einsetzbar. Schnittstellenunabhängige Fuzzer werden Generic Fuzzer genannt. Dem gegenüber stehen Specialised Fuzzer, deren Einsatzzweck definierte Schnittstellen sind: So unterstützt ein Protocol Specific Fuzzer eine einzelne bestimmte Schnittstelle und ein Multi Protocol Fuzzer unterstützt mehrere Schnittstellen. Klassifizierung nach Schnittstellen Schnittstellen lassen sich nach Art und Zugänglichkeit unterscheiden. Local Fuzzer eignen sich für lokal ausnutzbare Schnittstellen und Remote Fuzzer für remote ausnutzbare Schnittstellen. Zu den Local Fuzzern zählen File System Fuzzer, Environment Variable Fuzzer, Command Line Fuzzer, File Format Fuzzer, API Fuzzer, Web Browser Fuzzer und Database Fuzzer. So testen File System Fuzzer z.b. die Implementierung des Dateisystemtreibers eines Betriebssystems. File Format Fuzzer überprüfen die Bereiche einer Software zur Verarbeitung von Dateien. Environment Variable Fuzzer testen durch Veränderung der Umgebungsvariablen und Command Line Fuzzer durch Veränderung der Kommandozeilenparameter. API Fuzzer testen Programmschnittstellen wie z. B. DLL-Exporte. Zudem existieren Fuzzer zum Testen der Komponenten von Web Browsern. Datenbank Fuzzer testen Software, die auf die Daten in der Datenbank zugreift. Remote Fuzzer sind nach den Protokollen benannt, die sie testen - z. B. HTTP Fuzzer. Weiterhin werden Remote Fuzzer nach Protokollgruppen benannt, so z. B. die VoIP Fuzzer, die ein oder mehrere IP-Telefonie- Protokolle testen. In-Memory Fuzzer Diese Fuzzer identifizieren Fehler in der Zielsoftware unabhängig von Eingabeschnittstellen, indem funktionale Parameter und Nutzdaten der Zielsoftware im Hauptspeicher mutiert werden. Statt der Fokussierung auf ein spezifisches Protokoll oder Dateiformat, wird der zugrundeliegende Code betrachtet. Bei diesem Verfahren werden die Funktionen einer Anwendung und die dazugehörigen Assembler-Instruktionen zum Parsen von Eingabedaten betrachtet. Zwei verschiedene Ansätze von In-Memory-Fuzzern lassen sich unterscheiden 1. August 2012 Software-Sicherheit: Identifizierung bisher nicht erkannter Sicherheitslücken Seite 9 von 15

Fixkosten Automatische Fuzzer Manuelle Fuzzer Variable Kosten / Benötigte Expertise Abb. 11: Divergenz Produktkosten Personalaufwand Mutation Loop Insertion: Nach erfolgreicher Lokalisierung führt der Fuzzer eine Mutation-Routine im Speicherbereich des Clients aus. Diese Routine transformiert die Daten, die von der jeweiligen Parser-Funktion behandelt werden. Es werden unbedingte Sprungbefehle vom Endpunkt der Parser-Funktion zum Startpunkt der Mutation-Routine, und vom Endpunkt der Mutation-Routine zum Startpunkt der Parser-Funktion eingefügt, um ein kontinuierliches Fuzzing zu ermöglichen. Snapshot Restoration Insertion: Vom Prozess der Zielanwendung wird ein Snapshot erstellt, sobald der Startpunkt der Parser-Funktion erreicht ist. Nach Abschluss das Parsing stellt der Client den Snapshot wieder her, mutiert die originalen Eingabedaten und führt den Parser wieder aus. 4.3. Fuzzer und Fuzzing Frameworks Einige Fuzzing Tools sind: bestorm, Defensics, File Fuzz (idefense), FTPStress Fuzzer. Fuzzing Frameworks bieten die Möglichkeit speziell für die jeweilige Zielsoftware angepasste Fuzzer entwickeln zu lassen. Der Entwicklungsaufwand ist jedoch für Nicht-Experten ausgesprochen hoch zumal für gängige Anwendungen bereits fertig nutzbare Fuzzer existieren. Fuzzing Frameworks eignen sich besonders für neue proprietäre Zielanwendungen wie z.b. eine neue Implementierung eines Netzwerkprotokolls. Frameworks sind beispielsweise Autodafe, Peach, SCRATCH, SPIKE, SPIKEfile und Sulley. Kommerzielle Tools zeichnen sich meist durch eine vergleichsweise hervorragende Usability aus (graphische Benutzeroberfläche statt nur einer Kommandozeilensteuerung) (vergl. Abb. 11). Auch die Eigenentwicklung (Einmalentwicklung, Single Use, One-Off Fuzzer) kann nützlich sein, wenn geeignete Fuzzer für die Zielsoftware nicht erhältlich sind; üblicherweise ist die Anpassung eines vorhandenen Fuzzers oder die Generierung eines Fuzzers mit einem Framework einfacher und schneller als eine Eigenentwicklung aber nicht immer hinreichend wirkungsvoll. 4.4. Monitoring der Zielsoftware (Debugger, Profiler, Tracker) Die Identifizierung von Sicherheitslücken beim Fuzzing-Prozess erfolgt auf der Grundlage des Monitorings der Zielsoftware. Wurden die Eingabeschnittstellen der Zielsoftware identifiziert und die vom Fuzzer erzeugten Daten an die Zielsoftware gesendet, überwacht ein Monitoring-Tool die Zielsoftware, diagnostiziert und meldet dem Experten (Tester) die erkannten Anomalien und Exceptions wie Ursache (Programmabsturz, hohe CPUund Speicher-Auslastung), Speicheradresse, Exception Type, Registry Values, Register-, Speicher- und Stackzustände etc. (vgl. Abb. 9). Ein Monitor ist unverzichtbar zum Verständnis der Fuzzer-induzierten Anomalien; naturgemäß setzt die Nutzung eines Monitors ein gewisses Verständnis seiner Funktionen voraus. Nur einige Fuzzer verfügen über integrierte Monitoring-Funktionalität, was den Arbeitsaufwand eines Fuzzing- Tests reduziert: bestorm, Peach, Defensics, Sully. Einige Fuzzer sind in der Lage, mehrere Monitore zu nutzen. Andere Fuzzer benötigen ein externes Monitoring. Wegen der unterschiedlichen Funktionen und Funktionsausprägungen von Monitoren ist der Einsatz mehrerer dieser Tools empfehlenswert. Es können System Monitoring, Application Monitoring und Valid Case Instrumentation unterschieden werden. System Monitoring 1. August 2012 Software-Sicherheit: Identifizierung bisher nicht erkannter Sicherheitslücken Seite 10 von 15

System Monitoring bezeichnet die Überwachung von Systemressourcen wie die Anzahl gleichzeitig geöffneter Dateien, CPU-Auslastung oder Arbeitsspeichernutzung der Zielsoftware. Sind die Werte ungewöhnlich hoch oder niedrig deutet dies auf die Identifizierung einer Sicherheitslücke in der Zielsoftware. Die Überwachung von Logfiles oder das Auswerten von Systemmeldungen zählt ebenfalls zum System Monitoring. Denial of Service Probleme können dadurch einfach, File-System und Memory Related Probleme eingeschränkt erkannt werden. Application Monitoring Beim Application Monitoring werden Monitore verwendet, um das Verhalten der Zielsoftware zu untersuchen. Ist das Verhalten anomal, deutet dies auf eine Sicherheitslücke in der Zielsoftware hin. Weiterhin kann das Verhalten der Zielsoftware beobachtet werden, z. B. ist eine automatisierte Auswertung der von der Software erzeugten Logdateien möglich. Mit Application Monitoring können Denial of Service, File-System Related Problems, Metadata Injection Vulnerabilities und Memory Related Problems identifiziert werden. Für das Application Monitoring können u.a. Funktionen des Reverse Engineering Tool PaiMei eingesetzt werden. Valid Case Instrumentation Die Zielsoftware wird mit regulären Aufrufen während des Fuzzings überwacht. Die Ausgaben der Zielsoftware werden mit hinterlegten (korrekten) Ausgaben abgeglichen. So kann die korrekte Funktionsweise der Zielsoftware überprüft werden: Ist sie noch verfügbar oder wurden durch das Fuzzing Anomalien provoziert? Durch Valid Case Instrumentation können Denial of Service (z.b. bei zu langsamem Antwortverhalten der Software) und Metadata Injection Vulnerabilities (z.b. bei unbeabsichtigter Ausgabe sensitiver Daten) erkannt werden. Memory Related Vulnerabilities sind durch diese Methode eingeschränkt erkennbar (z.b. bei Absturz der Zielsoftware). Eine ganze Reihe von Fuzzern beinhaltet bereits eine Monitor-Funktion, so dass auf einen separaten Monitor verzichtet werden könnte. Diese integrierten Monitore sind auf die speziellen Fähigkeiten des Fuzzers ausgerichtet und weisen daher leichter auswertbare Ergebnisse auf. Integrierte Monitore weisen u.a. die beiden Fuzzer Mu-4000 und bestorm auf. Separate Monitore müssen naturgemäß eine Schnittstelle zu den eingesetzten Fuzzern besitzen. Die folgenden Monitore können eingesetzt werden: Debug.exe, Gnu Debugger gdb, IDA Pro, IBM PurifyPlus, Immunity Debugger, OllyDbg, Parasoft Insure, SoftICE, TOD, Turbo Debugger, Visual DuxDebugger, WinDbg.exe, W32DASM. 4.5. Nachweis von Vulnerabilities Vom Monitor wird ausschließlich anomales Verhalten der Zielsoftware erkannt und gemeldet. Diese Anomalien stellen nur Hinweise auf Vulnerabilities dar, die noch von Sicherheitsexperten verifiziert werden müssen. Notwendige Voraussetzung für eine Vulnerability ist die Reproduzierbarkeit einer Anomalie sowie die Erreichung eines sicherheitsrelevanten (ausnutzbaren) Zustands des Zielprogramms (Buffer Overflow, Code Injection etc.). Erkannte Anomalien müssen durch den Fuzzer reproduzierbar und auch verifizierbar sein. Allerdings ist eine Verifizierung in der Praxis nicht immer möglich. So kann beispielsweise die Prozessorlast des Zielsystems durch äußere Einflüsse ansteigen; dies könnte ein Monitor fälschlicherweise dem Fuzzing-Test anlasten und daraus folgend eine Anomalie anzeigen. Funktionen zur Fehlerreproduktion ersparen also dem Sicherheitsexperten Zeit. 4.6. Code Coverage Grundsätzlich könnte Fuzzing unendlich lange fortgesetzt werden. In der Praxis wird nach x (für x > 100.000) Iterationen ohne Hinweis auf eine weitere Sicherheitslücke abgebrochen. Endebedingung für Fuzzing Mit Code Coverage (Überdeckungstest) steht im Grundsatz eine quantitative Metrik zur Bewertung der Testabdeckung (ausgeführte Codezeilen) der Zielsoftware zur Verfügung: Bewertet wird der Prozentsatz des ausgeführten Codes des Zielprogramms (vgl. Abb. 9). Es können umso mehr Vulnerabilities identifiziert werden, je mehr Code der Zielsoftware untersucht, je höher also die erreichte Code Coverage ist. Nur in der Static Source Code Analysis kann eine Code Coverage von 100% erreicht werden. Fuzzing-Tests sollten nach einer vereinbarten Code Coverage abgebrochen werden. Unterschieden werden diese drei Klassen von Code Coverage: Line, Branch und Path Coverage letztere stellt die detailliertesten Informationen zur Verfügung. Code Coverage Tools sind beispielsweise Bullseye Coverage (C++), Clover (Java,.NET), coverage.py (Python), Devel::Cover (Perl), Gcov (C), IBM PurifyPlus, Rcov (Ruby), VBWatch (Visual Basic), Xdebug (PHP). Gezieltes Fuzzing Path Coverage gibt Auskunft darüber, welche Pfade (noch) nicht gefuzzed wurden und gibt damit eine Anleitung zu weiterem, gezielterem Fuzzing. Path Coverage kann über Code Coverage hinausgehen. 4.7. Wirksamkeit von Fuzzern: Generierung von Fuzz-Daten 1. August 2012 Software-Sicherheit: Identifizierung bisher nicht erkannter Sicherheitslücken Seite 11 von 15

Die wesentliche Funktion von Fuzzern ist die Generierung wirkungsvoller Fuzz-Daten (Eingabedaten für das Zielprogramm). Die Qualität von Fuzzern hängt damit direkt ab von der Größe des getesteten Eingabe- Datenraums (der auch unendlich sein kann) und der Qualität der erzeugten Fuzz-Daten: Diese Fuzz-Daten- Generierung ist entscheidend für den Fuzzing-Erfolg. Tatsächlich unterscheiden sich Fuzzer hinsichtlich ihrer Wirksamkeit (bei jeweils demselben Zielprogramm) erheblich: Verschiedene Fuzzer identifizieren unterschiedliche Sicherheitslücken! Dabei identifizieren eine ganze Reihe von Fuzzern nur wenige oder keine Sicherheitslücken. Dies liegt an den generierten Fuzz-Daten bzw. an dem Fuzz-Daten-Generator, dem Algorithmus zur Generierung dieser Fuzz-Daten. softscheck kann dazu einen auf das Zielprogramm hin optimierten eigenen Fuzz-Datensatz einsetzen. 4.8. Fuzzing Ergebnisse Aus der großen Menge im Internet angebotener entgeltfreier und kostenpflichtiger Tools lassen sich die relevanten Tools auf der Webseite http:// softscheck.inf.h-brs.de parametrisiert je nach den individuellen Bedürfnissen anhand einer ganzen Reihe entwickelter Bewertungsparameter entgeltfrei auswählen (vgl. Abb. 12). Die Eignung eines Fuzzers kann nämlich nicht pauschal angegeben werden, da sie von der Zielsoftware und den individuellen Anforderungen des Testers abhängt. Daher empfiehlt es sich in der Praxis, Zielsoftware-spezifische Bewertungen durch die anwendungsfallbezogene Gewichtung numerischer Parameter und deren Kategorien vorzunehmen. Bewertungs- und Beschreibungsparameter für Fuzzer können sein: Verfügbare Sprachen Betriebssysteme Protokollmodellierung (Art der Eingabeerzeugung) Fuzzing-Daten Erzeugung Einsatzzweck Schnittstellen Anwendungsinterpretation Kosten und Lizenz Lizenzform- und Name Kosten für Lizenz Kosten für Updates Kosten für Support Funktionsumfang Unterstützte Monitoring- Verfahren Erkennung von Sicherheitslücken Zurücksetzung der Zielsoftware Exception-Analyse Erstellung von Berichten Parametrisierbarkeit Fehlerreproduktion Zeitgesteuerte Aufgaben Paralleles Fuzzing Software-Ergonomie Effektivität Effizienz Zufriedenheit Funktionen Dialogkriterien Ein- und Ausgabekriterien Dokumentation Benutzerhandbuch Technische Dokumentation Qualität des integrierten Hilfesystems Zusätzliche Dokumentation Qualität des öffentlichen Supportforums Qualität des Herstellersupports Umfang an Drittdokumentation Web-Seminare / Schulungen Weiterentwicklung, Status, Aktivität Schnittstellen zur eigenen Weiterentwicklung Spezielle Entwickler-Tools Verwendete Programmiersprache 1. August 2012 Software-Sicherheit: Identifizierung bisher nicht erkannter Sicherheitslücken Seite 12 von 15

Functions, Innovative Ability Tool E Tool A Tool B Tool D Tool F Tool C Achievements Abb. 12: Bewertung von Fuzzing Tools Für diese Webseite http:// softscheck.inf.h-brs.de wurden im Rahmen eines vom Bundesministerium für Forschung und Technologie (BMFT FKZ 01 IS 09030)) umfangreich geförderten Projekts an der Hochschule Bonn- Rhein-Sieg etwa 300 weltweit verfügbare Tools zum Threat-Modeling und Fuzzing analysiert, ausgewählt und zusammen mit großen Software-Herstellern als Projektpartnern bewertet. In einer Reihe von Projekten wurden in bereits an Kunden ausgelieferte Standardsoftware bis zu 50 kritische Vulnerabilities identifiziert. Allerdings mussten darüber hinaus ca. 100 false Positives untersucht werden, die zwar nicht auf Sicherheitslücken hinwiesen aber eben doch auf Anomalien. 5. Herausforderungen der Identifizierung von Sicherheitslücken Mit den 3 Verfahren Threat Modeling, Static Source Code Analysis und Dynamic Analysis (Fuzzing) werden jeweils unterschiedliche Sicherheitslücken wirkungsvoll identifiziert. Allerdings erbringt erst die Kombination aller 3 Verfahren das bestmögliche Ergebnis: Mit Threat Modeling werden Designfehler identifiziert, mit Static Source Code Analysis funktionale Fehler und Codierungsfehler und mit Dynamic Analysis (Fuzzing) Implementierungsund Sicherheitsfehler. 5.1. Verfahrenskombination Wird auf eins der 3 Verfahren Threat Modeling, Static Source Code Analysis und Dynamic Analysis: Fuzzing verzichtet, so können spezifische Vulnerabilities nicht erkannt werden. In jedem Fall sollten diese 3 Verfahren parallel zur Software-Entwicklung eingesetzt werden: Am besten beginnend schon in der Requirements- oder Designphase möglichst aber spätestens in der Verifikationsphase und (kostenaufwändiger) nach dem Release können und müssen Vulnerabilities identifiziert werden, um den ansonsten erheblichen Fehlerbehebungs- und Patch-Aufwand gering zu halten. Acquisition of new DA-Tools Developed Evaluation Parameters for DA-Tools Updated Data Base: All Open Source and proprietary Fuzzers Target Application specific Selection DA-Tools Updated Data Base: All evaluated DA-Tools Target Application Automatic Selection of Target Application specific DA-Tools Abb. 13: Automatisierter Zielsoftware-spezifischer Auswahlprozess 1. August 2012 Software-Sicherheit: Identifizierung bisher nicht erkannter Sicherheitslücken Seite 13 von 15

5.2. Tool-Kombination Allerdings werden weder mit einem einzigen Tool der Static Source Code Analysis noch der Dynamic Analysis: Fuzzing alle Vulnerabilities identifiziert. Erst eine gezielt vorgenommene Kombination geeigneter Static Source Code Analysis und Fuzzing-Tools identifiziert ein Optimum bisher nicht-erkannter Vulnerabilities in einer angemessen kurzen Zeit. 5.3. Monitor Kombination Zur Interpretation des Fuzzing Prozess sollten mehrere Monitore eingesetzt werden, um den manuellen Aufwand der Interpretation der Fuzzing-Ergebnisse beim Sicherheitsexperten klein zu halten. 5.4. Expert Advice - Manual Auditing durch IT-Sicherheitsexperten Leicht unterschätzt wird die erforderliche Expertise der Mitarbeiter (Security Analysten), um die Ergebnisse der Tools auszuwerten. Im Einzelfall können die von den Static Source Code Analysis Tools gemeldeten Anomalien nur zu etwa einem Drittel als tatsächliche Vulnerabilities reproduziert und verifiziert werden die anderen Hinweise stellen false Positives dar. Für Sicherheitsexperten ist dazu ein erhebliches Know-How im Bereich der sicheren Programmierung, von Programmierfehlern und den aktuellen Angriffstechniken unverzichtbare Voraussetzung. Dieser manuelle Aufwand muss dabei auf zwei Drittel des Gesamtaufwands zur Identifizierung und Verifizierung von Vulnerabilities geschätzt werden. Der gesamte Personalaufwand pro identifizierter kritischer (bisher nicht-erkannter) Vulnerability konnte bei wirkungsvoller Verfahrens- und Toolauswahl auf durchschnittlich nur 8 Personenstunden gesenkt werden! Davon müssen ca. 5 Stunden für den Expert Advice das manuelle Auditing der Monitorhinweise aufgewandt werden. 5.5. Rating identifizierter Vulnerabilities Die Vielzahl der identifizierten Vulnerabilities macht eine Bewertung jeder einzelnen Vulnerability erforderlich, weil meist aus Wirtschaftlichkeitsgründen nicht alle behoben werden können. Die Bewertung der Vulnerabilities wird nach internationalen Standards wie DREAD (einfach) [Microsoft] oder dem Common Vulnerability Scoring System (CVSS) oder (mit zusätzlicher Bewertung sicherheitskritischer Funktionen) Common Misuse Scoring System (CMSS) (komplexer) vorgenommen. Security Analysten bewerten die identifizierten Vulnerabilities in einer Untersuchung hinsichtlich ihrer Bedeutung (severity) anhand einer Vielzahl von Bewertungsparametern die z.t. zustandsabhängig sind und auch an die Benutzerumgebung angepasst werden können wie z.b.: Erkennbarkeit für Dritte Reproduzierbarkeit Ausnutzbarkeit (Exploitability) lokal, im Netzwerk und aus dem Internet Notwendige Zugriffsrechte Generierbarer Schaden, Art und Umfang der Auswirkungen auf die Integrität, Verfügbarkeit und Vertraulichkeit der Daten. Das Common Weakness Scoring System (CWSS) lässt darüber hinaus eine Bewertung nur auf Umwegen erreichbarer ('chained') Vulnerabilities zu. 6. Erfolge der Tool-gestützten Verfahren Die Verfahren Threat Modeling, Static Source Code Analysis und Dynamic Analysis: Fuzzing stellen Toolgestützte Verfahren zur Identifizierung insbesondere sicherheitsrelevanter Softwarefehler zur Verfügung. Die Methode Dynamic Analysis: Fuzzing benötigt noch nicht einmal den Quellcode der Zielsoftware - ausführbare Dateien reichen aus: Black-Box Tests (entsprechend der Sicht eines Angreifers). Damit kann die Anwendungssicherheit wirkungsvoll gesteigert werden. 1. Verfahrenskombination: Es werden erfolgreich diese 3 Verfahren genutzt: Threat Modeling: Logische Fehler, Designfehler Static Source Code Analysis: Implementierungsfehler, Verstöße gegen Programmierrichtlinien, Syntaxfehler und Dynamic Analysis Fuzzing: Laufzeitfehler, Vulnerabilities Erst diese drei Verfahren gemeinsam eingesetzt identifizieren die unterschiedlichen Fehler und Vulnerabilities; insgesamt wurden in vielen Projekten in marktüblicher Software jeweils pro Zielsoftware bis zu 50 kritische (aus dem Internet ausnutzbare) Vulnerabilities identifiziert. 2. Tool-Kombination: Dazu werden je Verfahren eine Reihe von Tools bedarfsgerecht also die für die jeweilige Zielsoftware speziell geeigneten Tools gezielt ausgewählt und eingesetzt: Unterschiedliche Tools identifizieren verschiedene Vulnerabilities! Im Einzelfall ist erst der Einsatz von weit über 50 Tools erfolgreich. 3. Die Wirksamkeit der Fuzzer unterscheidet sich maßgeblich durch die generierten Fuzz-Daten (Eingabedaten in das Zielprogramm) bzw. den Algorithmus zur Generierung dieser Fuzz-Daten. softscheck kann dazu einen auf das Zielprogramm hin optimierten eigenen Fuzz-Datensatz einsetzen. 4. Fuzzing unterstützt zwar Black-Box-Tests allerdings können die wirkungsvollen Fuzzer umso besser ausgewählt werden, je umfassender die Spezifikation der Zielsoftware erfolgt: Grey Box Tests. 5. Diese Verfahren können erfolgreich für jede Art Software eingesetzt werden: Angefangen von Protokollen 1. August 2012 Software-Sicherheit: Identifizierung bisher nicht erkannter Sicherheitslücken Seite 14 von 15

bis hin zu Individualsoftware, Standardsoftware wie ERP, CRM, Datenbanksysteme und auch für unternehmensspezifische Anpassungen an Standardsoftware (Customizing), Web-Applications, Betriebssysteme und auch in Hardware und Embedded Systems sowie in Pder Prozesssteuerung (Industrial Control Systems) etc. 6. Die 3 Verfahren werden von großen und kleinen Softwareherstellern mit Erfolg eingesetzt, um die Kosten zur Fehlerbehebung und die Kosten für Patches nachhaltig zu senken. Die Methode wird gleichermaßen von internationalen Anwendern auch zur Abnahme von Software - eingesetzt. 7. Das systematische Vorgehen erfordert pro identifizierter (bisher nicht-erkannter) kritischer, aus dem Internet ausnutzbarer Vulnerability durchschnittlich nur 8 Personenstunden. Wegen des meist eng begrenzten Test-Budgets ein wichtiges Argument. 8. Verbände bieten Ausbildungskurse für diese 3 Verfahren an. 1. August 2012 Software-Sicherheit: Identifizierung bisher nicht erkannter Sicherheitslücken Seite 15 von 15

Prof. Dr. Hartmut Pohl Geschäftsführender Gesellschafter soft check GmbH Köln www. soft check.com Büro: Bonner Str. 108. 53757 Sankt Augustin Tel.: +49 (2241) 255 43-12 Mobil: +49 (172) 9437-329 Fax: +49 (2241) 255 43-28 Hartmut.Pohl@soft check.com