Gesamt-Schlussbericht des Verbundprojektes Deutsch - CC Gmbh

PH_GE_Titelseite 3.0, Master V3.0, Muster V0.1
Zusammenfassender Schlussbericht
zum Forschungsprojekt
SecFlow
Automatische Ermittlung sicherheitskritischer Datenflüsse in
Quellcode
Dana Richter
Version 1.0 / 2009-02-02
SecFlow_Gesamtschlussbericht_V10.odt
cc gmbh

.0 Mustervorlage V0.1
Beschreibung:
Vorhaben: SecFlow: Automatische Ermittlung sicherheitskritischer
Datenflüsse in Quellcode
Förderkennzeichen: 01 ISF 09A-D
Ausführende Stellen: Fraunhofer IESE, Kaiserslautern
ICT Solutions AG, Trier
SHE Informationstechnologie AG, Ludwigshafen
CC GmbH, Wiesbaden
Konsortialführer: CC GmbH, Wiesbaden
Laufzeit: 1.03.2006 – 30.11.2008
Kontakt:
CC GmbH
Johannes Fritz
Kreuzberger Ring 36
65205 Wiesbaden
Telefon: +49-611-942040
Fax: +49-611-9420444
E-mail: secflow@cc-gmbh.de
Web: www.secflow.de und www.sourceforge.net/projects/secflow/
© CC GmbH, Wiesbaden 2009. Alle Rechte vorbehalten.

Inhaltsverzeichnis
1 Kurze Darstellung................................................................................. .......................4
1.1 Aufgabenstellung .............................................................................. ...................4
1.2 Voraussetzungen, unter denen das Vorhaben durchgeführt wurde......................4
1.3 Planung und Ablauf des Vorhabens.................................................................. ....5
1.3.1 Analyse und Konzeption.............................................................. .............5
1.3.2 Entwicklung..................................................................... .........................5
1.3.3 Validierung................................................................................................ 6
1.3.4 Dissemination............................................................................. ..............6
1.3.5 Abweichungen zur ursprünglichen Planung........................................ ......6
1.3.6 Einsatz finanzieller Mittel....................................................... ...................7
1.4 Wissenschaftlicher und technischer Stand, an den angeknüpft wurde.................7
1.5 Zusammenarbeit mit anderen Stellen............................................. ......................8
2 Eingehende Darstellung............................................................................... ...............9
2.1 Erzielte Ergebnisse................................................................................. ..............9
2.1.1 Gesamtergebnis.................................................................... ...................9
2.1.2 Wichtige Teilergebnisse........................................................................... .9
2.2 Darstellung des voraussichtlichen Nutzens...................................................... ...19
2.2.1 Nutzen für die Allgemeinheit........................................................... ........19
2.2.2 Verwertbarkeit im Sinne des fortgeschriebenen Verwertungsplans .......20
2.2.3 Wissenschaftliche Verwertung der Projektergebnisse............................21
2.3 Fortschritt auf dem Gebiet des Vorhabens bei anderen Stellen..........................21
2.4 Erfolgte und geplante Veröffentlichungen des Ergebnisses................................22
3 Literaturverzeichnis........................................................................................ ...........25
© CC GmbH, Wiesbaden 2009
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
3 von 27

1 Kurze Darstellung
1.1 Aufgabenstellung
Ziel des Vorhabens war die Entwicklung und Erprobung eines Werkzeug-Frameworks samt
sprachspezifischer Module zur Sicherheitsanalyse von Programm-Quelltexten in
verschiedenen Programmiersprachen. Das Werkzeug dient der Ermittlung von Daten- und
Kontrollflüssen, auf denen böswillige Eingabe- und Umgebungsdaten ungeprüft sicherheitskritische
Operationen des Zielprogramms beeinflussen können. Solche Datenflüsse sind ein
maßgeblicher Ansatzpunkt für Angriffe auf Software. Das Prüfwerkzeug liefert deshalb einen
wesentlichen Sicherheitsgewinn für sicherheitskritische Software-Systeme.
1.2 Voraussetzungen, unter denen das Vorhaben durchgeführt wurde
Seit 2003 unterstützt das Bundesministerium für Bildung und Forschung (BMBF) mit der
Forschungsoffensive "Software Engineering 2006" Forschungsvorhaben zur Stärkung der
Softwaretechnik in Deutschland. Das Projekt SecFlow ("Security Flow") "Automatische
Ermittlung sicherheitskritischer Datenflüsse in Quellcode" wurde im Rahmen der zweiten
Auswahlrunde zur Forschungsoffensive 2006 in den Kreis der förderwürdigen Vorhaben
aufgenommen. Innerhalb der Forschungsoffensive "Software Engineering 2006" des BMBF
ist SecFlow dem Themenbereich II – Korrektheit, Sicherheit und Zuverlässigkeit von
Software-Systemen (inkl. Safety) – zugeordnet.
Das Vorhaben wurde im Juni 2006 rückwirkend für den Zeitraum vom 1. März 2006 bis
30. Juni 2008 genehmigt. Die Projektlaufzeit war ursprünglich für eine Dauer von
30 Monaten geplant. Aufgrund der rückwirkenden Genehmigung und dem damit
verbundenen späteren Start des Projektes wurde eine Verlängerung von 3 Monaten
beantragt und genehmigt. Es fand dabei eine kostenneutrale Umwidmung der Mittel statt.
Die Gesamtlaufzeit des Vorhabens betrug insgesamt 33 Monate, vom 1. März 2006 bis
30. November 2008.
SecFlow ist ein Verbundprojekt, an dem insgesamt vier Verbundpartner beteiligt waren:
� Fraunhofer Institut für Experimentelles Software Engineering (IESE), Kaiserslautern:
IESE übernahm im Projekt als Forschungspartner vornehmlich die forschungsintensiven
Anteile im Entwurf des Werkzeugs einschließlich der dazu erforderlichen
Referenzimplementierungen sowie die wissenschaftliche Begleitung der Validierung
des Werkzeugs.
� ICT Solutions AG (ICT), Trier:
ICT war im Projekt als Anwendungspartner vor allem für die praktische Validierung des
Werkzeugs bei der Sicherheitsüberprüfung ihrer kundenspezifischen Installationen
zuständig sowie für die Erarbeitung der plattformspezifischen Konzepte zur Analyse
von J2EE-Software.
� SHE Informationstechnologie AG (SHE), Ludwigshafen:
SHE übernahm im Projekt als zweiter Anwendungspartner vor allem die praktische
Validierung des Werkzeugs im Rahmen ihrer Beratungstätigkeit im Sicherheitsbereich
sowie die Erarbeitung der plattformspezifischen Konzepte für C# und .NET.
� CC GmbH (CC), Wiesbaden:
CC übernahm im Projekt als Technologiepartner vor allem die Implementierung des
Werkzeugs, war aber auch für Beiträge zu seinem Entwurf verantwortlich. Außerdem
leitete CC als Konsortialführer das Vorhaben.
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
4 von 27

1.3 Planung und Ablauf des Vorhabens
Die Planungen zum Projekt und seinem Ablauf sind im Rahmen des Projektantrages in Form
der Vorhabenbeschreibung dargestellt worden. Das Vorhaben wurde inhaltlich in nachfolgende
übergeordnete Arbeitspakete (Phasen) gegliedert:
� Analyse und Konzeption
� Entwicklung
� Validierung
� Verbreitung der Projektergebnisse
Die Ausgestaltung der einzelnen Phasen im Projektverlauf wird in den nachfolgenden
Abschnitten kurz beschrieben. Für eine detaillierte Darstellung der einzelnen Arbeiten wird
auf die Zwischenberichte zum Projekt verwiesen.
1.3.1 Analyse und Konzeption
Dieses Arbeitspaket beinhaltete vor allem die problem- bzw. projektbezogene detaillierte
Untersuchung von Themen zur Software-Sicherheit und die Ableitung von Anforderungen an
das geplante Werkzeug basierend auf den Zielsetzungen des Projektes.
IESE als Forschungspartner übernahm insbesondere die Erhebung und Definition von
Anforderungen an eine werkzeuggestützte Datenflussanalyse. Durch CC wurden zum einen
Anforderungen aus Sicht des Anwenders (z. B. hinsichtlich der Benutzerschnittstelle) zum
anderen aber auch Anforderungen zu Architektur und Technologie erfasst und eine
Abgrenzung des Vorhabens zu anderen, angrenzenden fachlichen Themengebieten
vorgenommen. In enger Zusammenarbeit wurden von IESE und CC verschiedene
Technologiealternativen recherchiert und hinsichtlich ihres Nutzens und der Einsatzfähigkeit
für das Projekt bewertet. Die Technologierecherche und Potentialbewertung bildete die
Basis für die Entscheidung zu einer Werkzeugarchitektur, die den Anforderungen an
Sprachunabhängigkeit, Flexibilität der Analyseregeln und Modularität des Werkzeugframeworks
genügt.
In dieser Projektphase wurde zudem untersucht, welche sicherheitskritischen Datenquellen
und -senken in den verschiedenen Programmierframeworks (Java/J2EE/JSP bzw.
C#/.NET/ASP.NET) relevant sind. Dazu brachten insbesondere die Praxispartner ICT und
SHE ihre Erfahrungen ein.
Weiterhin wurden sprachspezifische Validierungsmuster erhoben, d. h. typische Programmcode-Sequenzen,
die unsichere Datenflüsse durch Filterung oder Transformation in sichere
Datenflüsse verwandeln. Entsprechende Quellcode-Beispiele wurden von den
Anwendungspartnern aus real eingesetzter Software entnommen. Darauf aufbauend wurde
versucht, die gefundenen Beispiele zu verallgemeinern, um grundlegende Gesetzmäßigkeiten
ableiten zu können, und eine Beschreibungssprache für Datenflüsse und
Validierungen zu entwerfen (FLOW).
1.3.2 Entwicklung
Aufgabenschwerpunkt des Arbeitspaketes "Entwicklung" war die Umsetzung der Konzepte
und Entwürfe in ein funktionsfähiges Werkzeug (Implementierung).
Dabei wurden von IESE in verschiedenen Sondierungsimplementierungen Technologiealternativen
erprobt und schließlich die lauffähige Referenzimplementierung des Werkzeugs
für die Quellsprache Java erstellt. Diese Lösung bildete die Basis für die Realisierung des
Werkzeugs und wurde von CC als Implementierungspartner adaptiert und erweitert. Damit
wurde u. a. die Analyse von Programmiersprachen ermöglicht, die auf der .NET-Plattform
von Microsoft implementiert sind (u. a. C#, Visual Basic .NET).
Einen Teil der Implementierungsaktivitäten nahmen Test und Evaluierung der erstellten
Softwarekomponenten sowie Fehlerkorrekturen und erforderliche Anpassungen ein. Gemäß
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
5 von 27

den iterativ erfolgenden Verbesserungen an Teilen des SecFlow-Werkzeugkerns und des
SecFlow-eigenen Modellierungsformates FLOW waren Veränderungen an den erstellten
Komponenten notwendig.
In der letzten Phase der Programmierung wurde die Benutzerdokumentation erstellt. Diese
beinhaltet die grundlegenden Informationen zum Aufbau des SecFlow-Tools und seiner
Bedienung und sollen dem Anwender einen ordnungsgemäßen Betrieb des Werkzeugs
ermöglichen.
1.3.3 Validierung
Diese Phase galt der Evaluation des Werkzeugs anhand von Testfällen der
Anwendungspartner. Die dabei gewonnenen Einsichten führten zur Überarbeitung von
Konzept und Implementierung.
Höhepunkt dieser Phase war die Erprobung des Werkzeug-Prototyps über einen Zeitraum
von fünf Wochen von den Anwendungspartnern SHE und ICT unter kontrollierten, realitätsnahen
Versuchsbedingungen.
1.3.4 Dissemination
Das SecFlow-Werkzeug wird als freie Software zur Verfügung gestellt und steht unter der
GNU General Public License (GPL), Version 3 vom 29. Juni 2007. Es darf damit unter den
Bedingungen der GNU GPL, wie von der Free Software Foundation veröffentlicht,
weitergegeben und modifiziert werden, entweder gemäß Version 3 der Lizenz oder jeder
späteren Version.
Für die Bereitstellung des SecFlow-Werkzeugs und damit der zugrunde liegenden Konzepte
und Technologien musste eine geeignete Plattform gefunden werden. Die Projektpartner
entschieden sich bereits früh im Projekt für die Internetplattform SourceForge
(www.sourceforge.net). SourceForge ist ein Webportal zur Verwaltung einer Vielzahl an
Softwareprojekten. Es integriert eine große Anzahl von Open-Source-Anwendungen (z. B.
GNU Mailman, CVS, SVN). CC übernahm die Registrierung und Einrichtung der
SourceForge-Projektseite für SecFlow. Auf dieser Projektseite ist das SecFlow-Werkzeug in
den Softwarepaketen SecFlow-Backend, SecFlow-GUI (Eclipse-Plugin) und Testfälle zum
Download bereitgestellt.
Die Projektergebnisse werden zudem auf der Webseite des Projektes www.secflow.de
bereitgestellt.
1.3.5 Abweichungen zur ursprünglichen Planung
Der Projektverlauf folgte im Wesentlichen dem Projektplan. Neben Schwierigkeiten bei der
Fertigstellung des CIL-Compilers ergaben sich Verzögerungen im Projekt bei der
Evaluierung und Auswahl verwendbarer Testanwendungen. Weiter war die Suche nach
generalisierbaren Validierungsmustern weniger ergiebig als zunächst erwartet, und die
Generalisierung nicht-trivialer Muster erwies sich schwieriger als angenommen und musste
daher durch verstärkte Verwendung sprachspezifischer Muster kompensiert werden. Das
Feedback der Projektpartner aufgrund ihrer Evaluierung verschiedener Werkzeugprototypen
führte zudem zu mehrfachen Überarbeitungen der Datenfluss-Spezifikationssprache FLOW
und dadurch zu wiederholten Änderungen am Modellierungsformat für externe Funktionen
(Flow-Files bzw. "Summaries").
Aufgrund der rückwirkenden Genehmigung und der genannten technischen Probleme
entstand eine Differenz zwischen der ursprünglichen Planung und dem realen Projektverlauf,
die trotz der Bemühungen der Projektpartner nicht vollständig beseitigt werden konnte. Im
April 2008 wurde daher der Antrag auf kostenneutrale Verlängerung der Projektlaufzeit um
weitere drei Monate gestellt. Diesem wurde durch das BMBF/DLR stattgegeben.
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
6 von 27

Entgegen der ursprünglichen Planung wird für den realen praktischen Einsatz des
Werkzeugs eine Weiterentwicklung der Software (z. B. hinsichtlich von Usability,
Performanz, Dokumentation) notwendig werden. Diese wird jedoch keine grundlegende
Änderung der zugrunde liegenden Prinzipien oder Arbeitsweisen von SecFlow beinhalten,
sondern eher eine Verfeinerung und Ergänzung der bestehenden Funktionen und
praxisrelevante Anpassungen darstellen. Das Projekt liefert trotzdem ein wissenschaftlich
fundiertes und wirtschaftlich verwertbares Ergebnis.
1.3.6 Einsatz finanzieller Mittel
Das Projekt blieb seitens der Projektpartner IESE, SHE und CC im kalkulierten finanziellen
Rahmen. Die Kosten für die Projektdurchführung wurden gegenüber der Gesamtvorkalkulation
bei ICT leicht überschritten. Aufgrund der Wichtigkeit des Projekts und der zu
erwartenden positiven wirtschaftlichen Erfolgsaussichten nach Projektende wurde von ICT
jedoch entschieden, diese Kosten selbst zu tragen.
Die Laufzeitverlängerung konnte von allen Partnern kosten-neutral realisiert werden.
1.4 Wissenschaftlicher und technischer Stand, an den angeknüpft wurde
Anknüpfungspunkt für das Vorhaben waren einschlägige Vorarbeiten auf dem Gebiet der
statischen Programmanalyse sowie der Datenflussanalyse. Frühere Untersuchungen, die
gezeigt hatten, welche Vorzüge statische Analysen gegenüber konkurrierenden Ansätzen
aufweisen (siehe etwa [Engler&Musuvathi 2004]), hatten den Ausschlag gegeben,
grundsätzlich einen statischen Analyseansatz zu wählen. Verschiedene wichtige Bausteine
für eine Datenflussanalyse waren bereits aus vorangegangenen Forschungsarbeiten in den
Grundzügen bekannt. So konnte zum Beispiel in Bezug auf sogenannte "Points-to"-Analysen
auf vorhandene Methoden zurückgegriffen werden [Hind 2001, Whaley&Lam 2004]. Der
wissenschaftliche Schwerpunkt des Projekts lag vor allem in der Integration der vielen
partiellen Ansätze für statische Sicherheitsanalysen in ein Gesamtkonzept.
Die Projektpartner waren sich einig, dass – soweit dies möglich ist – bei der Realisierung
einzelner Teilkomponenten des SecFlow-Frameworks auch auf bereits existierende
Konzepte und Methoden zurückgegriffen werden sollte, um den Implementierungsaufwand
in Grenzen zu halten und das Projekt auf Aspekte der Sicherheitsanalyse zu konzentrieren.
Dazu wurden eine ausführliche Technologierecherche und -bewertung sowie eine
entsprechende Auswahl durchgeführt. Bei der Realisierung des Werkzeugkerns wurden
schließlich Teile verschiedener Open Source Software im Framework adaptiert und
integriert:
Um das Analysewerkzeug sprachunabhängig zu gestalten, wurden die Analysemodule von
den sprachabhängigen Compiler-Modulen getrennt. Dazu wurde der Quellcode der
unterstützten Programmiersprachen in ein gemeinsames Zwischenformat (Quad)
umgewandelt. Für diesen Transformationsschritt wurde auf Module der frei verfügbaren
Java-kompatiblen Implementierung der virtuellen Maschine "Joeq" zurückgegriffen [Whaley
2005]. Sie wurde für die Zwecke des Projekts entsprechend angepasst.
Zur Modellierung von Datenflüssen und Analyseregeln entschied sich das Konsortium nach
Abwägung und Erprobung verschiedener Realisierungsalternativen für eine deduktive
Datenbank. Die Wahl fiel schließlich auf die Datenbank-Programmiersprache "Datalog"
(http://de.wikipedia.org/wiki/Datalog) und die eigens für Analysezwecke entwickelte BDDbasierte
Deduktive Datenbank BDDBDDB (Binary Desicion Diagrams Based Deductive
DataBase) [Whaley 2004, Whaley et al. 2005].
Für die Realisierung eines Übersetzers für .NET-Bytecode in die Zwischendarstellung Quad
wurde ein Bytecodeparser benötigt, der in der Lage ist, Assemblyfiles zu lesen und zu
parsen. Mit MBEL (Microsoft Bytecode Engineering Library) fand sich eine Open-Source-
Bibliothek, die in Java programmiert und relativ unabhängig von der Ausführungsumgebung
ist [MBEL 2008].
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
7 von 27

Die Benutzeroberfläche des SecFlow-Werkzeugs wurde in das quelloffene IDE-Framework
"Eclipse" integriert [Eclipse 2008]. Die SecFlow-Funktionalität wird dabei mittels
verschiedener Eclipse-Plugins bereitgestellt.
Die Reportgenerierung in SecFlow basiert auf der Reportingengine JasperReports und
iReport [Jasper 2008].
1.5 Zusammenarbeit mit anderen Stellen
Ein Besuch von Prof. Dr. Jens Krinke von der Fern-Universität Hagen bei Fraunhofer IESE
wurde 2006 genutzt, um einen konstruktiven Erfahrungsaustausch durchzuführen. Prof. Dr.
Jens Krinke ist ein ausgewiesener Experte auf dem Gebiet des Program Slicing und
verwandter Techniken der statischen Programmanalyse. Gemeinsam wurden verschiedene
Analyseverfahren in Bezug auf die dem SecFlow-Projekt zugrunde liegende Zielsetzung
erörtert.
Neben der Nutzung von Diskussionsmöglichkeiten und Umfragen in einschlägigen Internet-
Foren wurde der Austausch mit anderen Wissenschaftlern insbesondere durch IESE auch
während der 23. Annual Computer Security Application Conference (ACSAC’07) in Miami,
Florida betrieben. Dabei wurde ein Zwischenstand der Forschungsarbeiten vorgestellt und
mit internationalen Wissenschaftlern diskutiert [Mandel&Peine 2007].
Initiiert durch den Projektpartner ICT wurde im Rahmen des Projektes mit dem Lehrstuhl
Wirtschaftsinformatik I, Prof.-Dr. Hans Czap der Universität Trier zusammengearbeitet. In
diesem Zusammenhang wurden zwei Studienprojekte durchgeführt, die eine ganzheitliche
Betrachtung des Projekts vor dem Hintergrund der optimalen Unterstützung der Entwickler
im gesamten Entwicklungsprozess und die Bereitstellung von Hilfestellungen und
Codebeispielen für sichere Programmierung thematisierten.
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
8 von 27

2 Eingehende Darstellung
2.1 Erzielte Ergebnisse
2.1.1 Gesamtergebnis
Im Rahmen des Projekts wurde ein konfigurierbares, programmiersprachenunabhängiges
Werkzeug-Framework entworfen und implementiert, das im Quellcode unsichere Datenflüsse
von ihren nicht vertrauenswürdigen Datenquellen bis zu sicherheitskritischen Datensenken
verfolgt. So kann ermittelt werden, ob unerwünschte Eingaben ungeprüft in
sicherheitsrelevante Systemfunktionen einfließen können. Unsichere Datenflüsse tragen in
der Praxis ganz maßgeblich zu den bisher bekannt gewordenen Angriffen auf Software bei.
Ein solches Werkzeug-Framework ist daher ein wichtiger Schritt zur Verbesserung der
Software-Sicherheit. Alleinstellungsmerkmal des Werkzeugs ist insbesondere seine
Sprachunabhängigkeit.
Zentrale, programmiersprachenunabhängige Funktionalitäten wurden im sogenannten Kern
des Werkzeugs verankert und programmiersprachenabhängige Funktionalität in sprachspezifische
Module gelagert. Derzeit ist das Tool für die Programmiersprache Java und alle
.NET-Sprachen verfügbar.
Die SecFlow-Analyse basiert auf einer statischen Daten- und Kontrollflussanalyse von
Quellcode. Dabei werden alle für die Analyse benötigten Codeinformationen, Zwischenergebnisse
als auch die Analyseregeln selbst in ein deduktives Datenbankmodel überführt,
das als Binary Decision Diagrams (BDDs) verwaltet wird. Damit konnte SecFlow als eines
der ersten Werkzeuge diese Schlüsseltechnologie erfolgreich verwerten.
Die verschiedenen SecFlow-Komponenten stellen ein vollständiges, funktionstüchtiges
Analyseframework dar. Beschränkungen bestehen derzeit noch durch die Analysegeschwindigkeit
und hinsichtlich spezieller technologischer Probleme wie z. B. der Auflösung von
reflektiven Aufrufen. Zum Teil existieren dazu bereits Lösungskonzepte. Auch wenn durch
die Einschränkungen eine volle Marktreife noch nicht gegeben ist, bietet SecFlow bereits
heute eine Hilfestellung bei der Sicherheitsanalyse von Softwaresystemen.
2.1.2 Wichtige Teilergebnisse
Anforderungserhebung
Als fachliche Basis für das SecFlow-Projekt wurden zu Projektbeginn die grundlegenden
Anforderungen an das zukünftige Werkzeug erfasst. Hinsichtlich der Analyse und Definition
von Anforderungen an das Werkzeug lassen sich grob zwei Richtungen unterscheiden. Zum
einen die eher wissenschaftlich getriebene Erarbeitung notwendiger technischer Konzepte
zu Analyseumfang und den benötigten Analysearten, zum anderen Anforderungen, die sich
aus dem späteren praktischen Einsatz des Werkzeugs z. B. in Kundenprojekten ergeben.
In der Rolle des Forschungspartners in diesem Projekt mit der Kompetenz für den State-ofthe-Art
von Konzepten, Methoden und Techniken hat IESE die grundlegenden Dimensionen
der Analyseschärfe bei der Programmanalyse im Hinblick auf das SecFlow-Projekt untersucht
und bewertet. Im Ergebnis wurde u. a. festgehalten, dass die Analysen des zukünftigen
Werkzeugs sowohl Kontextsensitivität als auch Flusssensitivität (siehe z. B. [Hind 2001])
berücksichtigen sollen. Zudem wurde die sog. SSA-Eigenschaft ("static single assignment")
als hilfreiche und notwendige Anforderung für die Repräsentation des Programmcodes
herausgearbeitet. Die SSA-Eigenschaft erleichtert die Datenflussanalyse erheblich. Insbesondere
sorgt sie dafür, dass viele Anweisungen innerhalb derselben Prozedur in einer für
Zwecke der Datenflussanalyse eindeutigen Weise geordnet werden, so dass eine intraprozedurale
Datenflussanalyse für diese Anweisungen automatisch auch flusssensitiv ist.
In der Praxis sind sowohl Fluss- als auch Kontextsensitivität jedoch nur bis zu einem
gewissen Grade erzielbar, da jede Sensitivitätssteigerung den Berechnungsaufwand für die
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
9 von 27

Analyse steigert. Es galt also eine vernünftige Abwägung zwischen Analysegenauigkeit und
Analyseaufwand zu finden. Ohne vorherige Erprobung war der bestmögliche Kompromiss
nicht absehbar. Daher bestand eine kritischen Anforderungen darin, eine flexible
Implementierungsstrategie zu finden, die jederzeit ein Nachjustieren der Fluss- und Kontextsensitivität
ermöglicht, ohne größere Änderungen am Framework vornehmen zu müssen.
Parallel zu den vorrangig wissenschaftlichen Anforderungen wurden im Projekt praxisorientierte
Anforderungen ermittelt. Diese spiegeln vor allem die Anwendersicht auf das
entsprechende Softwareprodukt wider und beziehen sich insbesondere auf systemtechnische
Anforderungen, die gewünschte Handhabung sowie die sinnvolle und verwertbare
Ausgabe der Arbeitsergebnisse des geplanten Frameworks.
Nicht nur, um den Prozess der Anforderungsabstimmung zu unterstützen, sondern auch um
die Kommunikation und den Ergebnisaustausch unter den Projektpartnern zu erleichtern und
zu fördern, wurde bereits zu Projektbeginn vom Konsortialführer CC ein projektinterner Wiki
eingerichtet. Damit war die Arbeit der verschiedenen Verbundpartner für alle Projektmitglieder
transparent und nachvollziehbar.
Beschreibungssprache FLOW
Das Vorhaben war von Beginn an darauf ausgerichtet, eine möglichst quellsprachenunabhängige
Analyseunterstützung bereitzustellen. Für die ins Auge gefassten Programmiersprachen-Frameworks
wurden dazu zunächst die sicherheitsrelevanten Datenquellen und
Datensenken erhoben. Die Anforderung bestand darin, für alle ermittelten Codemuster eine
einheitliche Darstellungsmöglichkeit zu schaffen, die den Besonderheiten der Quellsprachen
Rechnung trägt. Unter Mitwirkung und Anleitung von IESE sammelten die Anwendungspartner
ICT und SHE dazu typische Codebeispiele bzw. Validierungsmuster. Aus diesen
Codemustern sollten im Projekt allgemeine Merkmale für sicherheitskritische Datenquellen
und Datensenken abgeleitet werden. Zudem flossen Ergebnisse hieraus in die Konzeption
der Datenflussbeschreibungssprache FLOW ein.
Diese SecFlow-eigene Modellierungssprache FLOW dient dazu, die für eine Analyse
notwendigen Informationen über Datenflüsse von externe Funktionen zu hinterlegen, die von
SecFlow nicht analysiert werden können bzw. explizit von der Analyse ausgenommen
werden sollen. Diese Informationen werden in der FLOW-Sprache über sogenannte Flow-
Dateien (Summary Datei) an das SecFlow-Werkzeug weitergegeben.
Das Konzept wurde von IESE entwickelt. Dabei wurde zunächst ein relationales, dann ein
aspektorientiertes Beschreibungsformat für Datenfluss-Spezifikationen erprobt. Beide
Spezifikationsformate setzten jedoch ein hohes Maß an Abstraktionsvermögen und viel
Hintergrundwissen über Datenflussanalyse beim Anwender voraus und erwiesen sich daher
als nicht geeignet. Aufbauend auf diesen Erfahrungen entwickelte Fraunhofer IESE in
mehreren Iterationen schließlich die spezialisierte Datenfluss-Beschreibungssprache FLOW
[Mandel&Jawurek 2008]. Neben der Sprachunabhängigkeit soll mit dem Einsatz von FLOW
und mit der damit verbundenen intuitiven Ausdrucksweise und den minimalen, aber genau
erzeugten Informationen die Spezifikation des Datenflusses erleichtert werden. Die abstrakte
Darstellung erlaubt es, bekannte Datenflüsse, -quellen und -senken auf einfache Art
abzubilden.
Um zukünftigen Anwendern die Erstellung solcher Spezifikationen zu erleichtern, wurde von
ICT und SHE auf Basis des Konzeptes von IESE eine Dokumentation mit Beispielen
erarbeitet [Kalenborn et al. 2008].
Entwicklung des Analysewerkzeuges
Auf Grundlage der Ergebnisse aus der Anforderungsanalyse wurde durch IESE und CC die
Softwarearchitektur des SecFlow-Werkzeugs entworfen und verschiedene Technologiealternativen
recherchiert und hinsichtlich ihres Nutzens und der Einsatzfähigkeit für das
Projekt bewertet.
Der Architekturentwurf beinhaltete den modularen Aufbau des Frameworks mit
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
10 von 27

� einem sprachunabhängigen Werkzeugkern, der alle für die Analyse relevanten
Methoden und Abläufe umfasst,
� spezifischen Plugin-Modulen zur Anbindung verschiedener Programmiersprachen,
� einer Präsentationskomponente zur zielgruppenspezifischen Darstellung der
Ergebnisse und
� einer Benutzeroberfläche, über welche die Benutzereingaben gesteuert und
strukturiert werden können.
Um den Implementierungsaufwand möglichst gering zu halten, verständigten sich die
Partner darauf, soweit sinnvoll und möglich bereits existierende Konzepte und Methoden bei
der Realisierung des Werkzeugs einzusetzen.
Die Bewertung verschiedener Realisierungsalternativen erfolgte im Hinblick auf den Grad
der Erfüllung der gesammelten Anforderungen. Themen waren dabei zum Beispiel die
optimale Repräsentation des analysierten Programms (z. B. mittels Quelltext, Syntaxbaum,
Kontrollflussgraph, Zwischencode), der während der Analyse gewonnenen Informationen
(z. B. relational, objektorientiert, imperativ), der Analyseregeln (z. B. logisch, mengenbasiert,
objektorientiert, programmatisch) sowie die Darstellung der Analyseergebnisse.
In Abstimmung mit allen Pojektpartnern wurde schließlich ein Ansatz auf Basis einer kontextsensitiven
Codeanalyse ausgewählt, welcher sich im Open-Source-Framework Joeq
wiederfand. Eine wichtige Rolle für die Auswahl dieses Frameworks war die in Joeq
verwendete viel versprechende Datalog- und BDD-Technologie. Dabei wird für die
Speicherung und Auswertung der Datenflussinformationen die BDD-basierte Deduktive
Datenbank "BDDBDDB" [Whaley 2004] verwendet. Zur Formulierung der logischen
Analyseregeln zur Ermittlung komplexer Zusammenhänge dient die Abfragesprache
"Datalog" (http://de.wikipedia.org/wiki/Datalog).
Das Joeq-Framework bietet Programmiersprachenunabhängkeit durch eine Intermediate
Representation (IR) basierend auf einem Quad genannten Zwischencode. Dieser stellt eine
traditionelle 2-stufige Zwischensprache mit einem Kontrollflussgraphen und einer Darstellung
der Befehle als Quads (3 Operatoren, 1 Operand) dar. Als prozessornahe registerbasierte
Darstellung vereinfacht Quad die Datenflussanalyse, die in einer stackbasierten Darstellung
durch das Stackhandling wesentlich aufwendiger wäre.
Die sprachunabhängige Darstellung Quad dient für SecFlow zudem als Schnittstelle zur
Anbindung der verschiedenen Programmiersprachen an das SecFlow-Analyseframework.
Diese Anbindung erfolgt im jeweiligen Sprachmodul durch einen – natürlich
sprachabhängigen – Compiler für die Übersetzung vom Quell- bzw. Bytecode der jeweiligen
Programmiersprache nach Quad.
Insgesamt resultierte eine modulare Werkzeugarchitektur gemäß Abbildung 1.
Die Architektur sieht vor, dass Software verschiedener Quellsprachen analysiert werden
kann. Aktuell unterstützt das Werkzeug die Programmiersprachen Java und C#, wobei
jeweils der Bytecode (JBC/Java bzw. CIL/.NET-Assembly) analysiert wird. Dieser erste
Schritt, der nicht zum SecFlow-Werkzeug gehört, sondern von konventionellen Compilern
erledigt wird, wird unter der Bezeichnung ”Preprocessing" zusammengefasst.
Die Sprachkomponente (Language Component) übersetzt den stackbasierten, sprachabhängigen
Bytecode in die registerbasierte, sprachunabhängige Zwischensprache Quad.
Der so entstehende Zwischencode dient als Schnittstelle zu nachfolgenden SecFlow-
Komponenten. Er beinhaltet die Datenbasis für die spätere Analyse.
Die Adapterkomponente (Adapter Component) übersetzt den Zwischencode in relationale
Tupel. Diese Tupel bilden im Quadcode enthaltene Zusammenhänge ab.
Datenfluss-Summaries sind Modelle externer Funktion, die nicht direkt analysiert werden
können. Sie müssen manuell spezifiziert werden. Die Summarykomponente (Summary
Component) übersetzt die Datenfluss-Summaries und macht sie damit für das Werkzeug
verfügbar.
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
11 von 27

Abb. 1: SecFlow: Werkzeugarchitektur
Die Analysekomponente (Analysis Component) führt die eigentliche Datenflussanalyse
durch und berechnet aus den zuvor generierten Tupeln und den von der Summarykomponente
übersetzten Datenfluss-Summaries eine Rohform der kritischen Pfade. Das
Ergebnis der Analysekomponente sind verschiedene Datenbankrelationen, welche tupelweise
ausgelesen werden können.
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
12 von 27

Die Filterkomponente (Filter Component) entwickelt aus den Ergebnisrelationen der
Analysekomponente einen Graphen und extrahiert aus diesem Graphen einen redundanzfreien
Datenflusspfad. Der Pfad wird in XML-Format ausgegeben. In der Präsentationskomponente
(Presentation Component) können diese Pfade visualisiert werden.
Sprachmodule: Compiler nach QUAD
Java-Bytecode JBC nach Quad
Für die Programmiersprache Java war das Sprachmodul, der Compiler vom Java-Bytecode
JBC nach Quad, in Joeq bereits vorhanden (der sogenannte JVM2QUAD-Compiler).
.NET-Bytecode CIL nach Quad
Um auch Programme in anderen Programmiersprachen als Java analysieren zu können,
müssen entsprechende Compiler nach Quad erstellt werden. Ein lohnendes Ziel für
Sicherheitsanalysen sind die auf der .NET-Plattform von Microsoft implementierten
Programmiersprachen (u. a. C#, Visual Basic .NET). Für alle diese Sprachen existieren
bereits Compiler von der Quellsprache in den .NET-Bytecode "Common Intermediate
Language" (genannt CIL), eine erweiterte Bytecodesprache (siehe auch Abbildung 2). CIL-
Bytecode dient als Zwischensprache für viele verschiedene Quellsprachen (neben den oben
genannten .NET-Sprachen auch Java und PHP) und ist Bestandteil der CLR (Common
Language Runtime), einer nach ECMA 335 vorliegenden Spezifikation für eine
Ausführungsumgebung. CLR wurde von Microsoft als Alternative zur Java VM (JVM)
vorangetrieben, es liegen dazu auch Implementierungen als Open Source vor (z. B, Mono,
MS Rotor).
Im Projekt wurde daher beschlossen, die Sicherheitsanalyse basierend auf dem .NET-
Bytecode CIL aufzusetzen, damit konnte SecFlow gleichzeitig für eine Vielzahl von
Sprachen erweitert werden. Aus dieser Tatsache entstand die Notwendigkeit für einen
entsprechenden Compiler von CIL-Bytecode in den Zwischencode Quad, dem sogenannten
CIL2Quad Compiler (vgl. Abbildungen 2 und 3).
C#
using System;
using System.IO;
namespace sample
{
class MainClass
{
public static void Main(string[]
args)
{
int[] iArray = new int[2];
Int32 i32 = new Int32();
iArray[0] = 2;
iArray[1] = i32;
if(!(iArray[1]

QUAD:
BB0 (ENTRY) (in: , out: BB2)
BB2 (in: BB0 (ENTRY), out: BB3, BB8)
1 NEWARRAY T3 Int32[], IConst: 2, LInt32;[]
2 MOVE_I R1 int, IConst: 0
3 NULL_CHECK T-1 , R0 String[]
4 BOUNDS_CHECK R0 String[], IConst: 1, T-1
5 ALOAD_I T4 int, R0 String[], IConst: 1, T-1
6 NULL_CHECK T-1 , R0 String[]
7 BOUNDS_CHECK R0 String[], IConst: 0, T-1
8 ALOAD_I T5 int, R0 String[], IConst: 0, T-1
9 IFCMP_I T4 int, T5 int, LE, BB8
BB3 (in: BB2, out: BB7)
10 MOVE_I R2 int, IConst: 0
11 GOTO BB7
BB7 (in: BB3, BB6, out: BB8, BB4)
:
BB1 (EXIT) (in: BB2, out: )
Abb. 3: Beispiel für eine C#-Datei: Darstellung im Quadcode.
In diesem Zusammenhang wurde von CC eine Anforderungs- und Machbarkeitsanalyse
sowie eine Aufwandsabschätzung zur Herstellung eines solchen Compilers durchgeführt.
Dazu wurde die für die Programmiersprache Java schon vorhandene Lösung, der
JVM2QUAD-Compiler, analysiert und parallel verschiedene Open-Source-Projekte und
verschiedene Spezifikationen untersucht, die sich mit dem Handling von CIL-Bytecode
befassen. Dazu gehören unter anderem ILDump, JaCIL, IKVM, MS Rotor, MBEL und Mono.
Der CIL2QUAD-Compiler wurde schließlich auf Basis des quelloffenen Bytecodeparsers
MBEL (Microsoft Bytecode Engineering Library, [MBEL 2008]) entworfen und entwickelt –
dies schloss Implementierung und Test ein. Die Entscheidung für MBEL ergab sich u. a.
auch aus der Implementierungssprache Java, die eine einfache Integration in das SecFlow-
Framework gewährleistete. Während der Entwicklung zeigte sich, dass MBEL an einigen
Stellen nicht vollständig implementiert ist. Die Bibliothek wurde entsprechend ergänzt.
Zusätzlich unterzog CC die Komponente einem Profiling und optimierte diese – auch im
Hinblick auf die Performance – auf Basis der Ergebnisse weiter. Die Unabhängigkeit des
CIL2QUAD-Compilers und damit auch des SecFlow-Analyse-Backends von einer konkreten
CLR-Implementierung konnte so erreicht werden.
Mit Unterstützung des Projektpartner IESE wurde schließlich der CIL2QUAD-Compiler von
CC in das SecFlow-Framework integriert. Kritische Codebereiche wurden besprochen und
nötige Anpassungen der Schnittstelle vorgenommen.
Anbindung weiterer Programmiersprachen
Neben der Analyse von Java- und .NET-Programmen erscheint auch die Prüfung von
Quelltexten in der Programmiersprache PHP als lohnenswerte Zielsetzung für SecFlow.
Mit der Anbindung der Programmiersprache PHP wird es nicht nur möglich sein,
Anwendungen, die in dieser heute als hochgradig unsicher geltenden Programmiersprache
erstellt wurden bzw. werden, auf sicherheitskritische Datenflüsse zu analysieren. Es wird
zudem aufgrund des hohen Verbreitungsgrades in der Entwickler Community und der zahlreichen
Implementierungen zur Anhebung des allgemeinen Sicherheitsstandards von Web-
Anwendungen beitragen.
Im Rahmen des Projektes wurde von IESE und CC die Möglichkeit der Erweiterung des
SecFlow-Kerns für die Programmiersprache PHP analysiert. Im Rahmen einer Diplomarbeit
bei IESE wurde eine prototypische, wenn auch nicht voll ausgereifte Unterstützung für die
Programmiersprache PHP realisiert [Nicolay 2008]. Dabei konnte nachgewiesen werden,
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
14 von 27

dass eine Anbindung von PHP prinzipiell möglich ist. Es bestehen derzeit jedoch noch große
Beschränkungen insbesondere aufgrund der von SecFlow verfolgten statischen Analyse.
Diese Grenzen zu lösen, stellt eine herausfordernde Aufgabe dar, die evtl. in einem
nachfolgenden Projekt durch die Projektpartner angegangen werden soll.
Benutzerschnittstelle und Präsentationskomponente
Ein weiterer Aufgabenschwerpunkt im Projekt war die Entwicklung der Benutzerschnittstelle
des SecFlow-Werkzeugs inklusive der zugehörigen Validierung. Neben der Gewährleistung
einer einfachen Handhabung des Werkzeugs, vor allem in Hinblick auf mögliche
Einstellungen durch den Anwender, entschieden sich die Projektpartner auch die
Ergebnisdarstellung über die SecFlow-GUI zu realisieren. Ziel war dabei eine übersichtliche
und verständliche Darstellung der Prüfergebnisse zu finden, die es Anwendern auch ohne
spezifisches Wissen über sicherheitskritische Aspekte im Sourcecode nicht nur erlaubt, die
Ergebnisse zu verstehen, sondern auch Unterstützung bei der Einleitung entsprechender
Maßnahmen zur Verbesserung der Sicherheit bietet.
Das Konsortium entschied sich nach einer Analyse und Bewertung möglicher Alternativen,
die GUI-Komponenten in Eclipse als weit verbreitetes und anerkanntes Entwicklungssystem
zu integrieren. Zur Erprobung der Implementierungsvarianten einzelner Teilkomponenten
der GUI wurden von IESE als auch von CC verschiedene Referenzimplementierungen
erarbeitet.
Die letztendlich erstellte SecFlow-GUI bietet
� Funktionen zur Konfiguration und Ausführung des Analysevorhabens,
� Funktionen zur Bearbeitung von Summary Dateien (auch Flow Dateien genannt) zur
Abbildung externer Teile des analysierten Systems,
� die übersichtliche Ausgabe und verständliche Darstellung der Analyseergebnisse
sowie
� eine Rückreferenzierung von den Analyseergebnissen auf den dem Entwickler
vorliegenden Quellcode des analysierten Systems.
Dafür wurden folgende GUI-Komponenten implementiert:
� Konfigurationseditor
� Flow-GUI
� Präsentationskomponente
CC realisierte diese Benutzeroberfläche als Eclipse-Plugin. Sie wird über eine speziell für
SecFlow entwickelte Eclipse Update Site bereitgestellt.
Einen Überblick über die einzelnen Komponenten und ihre Zusammenhänge bietet die
nachfolgende Abbildung 4.
Konfigurationseditor
Der Konfigurationseditor dient zur Konfiguration der Analyse, dem Management der zu
analysierenden Quellen sowie der Organisation der benötigten Ressourcen. Über diese
Komponente wird die Ausführung der Analysen gestartet.
Flow-GUI
Der Flow-Editor der Benutzerschnittstelle bietet Funktionen, um dem Anwender die
Erstellung, die Bearbeitung und Pflege der Flow-Dateien (Summary Dateien) zu erleichtern.
Dem Anwender stehen dabei drei Eclipse Views zur Verfügung:
Die Library View zeigt die in einem Projekt verfügbaren Bibliotheksklassen (externe
Funktionen) an, während die Flow View die für ein Projekt verfügbaren Summary Dateien
wiedergibt. Weiterhin bietet sie Funktionen, um fehlende und unvollständige Summary
Dateien (bezogen auf die Ebene der Methoden) im aktuellen Projekt zu bestimmen. Über
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
15 von 27

eide Views ist es möglich, den Flow-Generator aufzurufen und so die Erzeugung neuer
Summary Dateien zu starten.
Abb. 4: Überblick zur Benutzerschnittstelle
Die Flow Outline View zeigt eine strukturierte Übersicht über eine Flow-Datei. Die View soll
den Entwickler dabei unterstützen korrekte Flow-Dateien zu erstellen. Die Auswahl eines
Elements öffnet im Source-Editor die entsprechende Flow-Datei und positioniert den Cursor
vor dem ausgewählten Element. Änderungen an der Flow-Datei werden beim Speichern
direkt in der Outline View übernommen.
Mit dem Flow-Generator ist es möglich, unter Angabe der Quelldatei automatisch Templates
für Flow-Dateien zu erzeugen. Diese beinhalten ein an die Gegebenheiten der jeweiligen
Bibliotheksfunktion angepasstes Grundgerüst zur Darstellung des entsprechenden
Datenflussmodells. Diese Grundgerüst kann dann vom Anwender mit den entsprechenden
Datenflussinformationen gefüllt werden.
Präsentationskomponente
Das SecFlow-Analyse-Backend liefert Informationen über sicherheitsrelevante Schwachstellen
in sogenannten Pfaden. Ein Pfad beschreibt einen Weg von einer Quelle zu einer
Senke. Über eine Quelle werden potentiell kritische Daten in ein Programm eingespeist.
Wenn diese bis zur Senke gelangen, entsteht möglicherweise ein Schaden.
Die Ergebnisse werden durch das Analyse-Backend in Form einer XML-Struktur
ausgegeben. Die Präsentationskomponente hat zum einen die Aufgabe, diese Analyseergebnisse
für Programmentwickler und -verantwortliche leicht verständlich darzustellen und
zum anderen eine Rückreferenzierung von den Analyseergebnissen auf den dem Entwickler
vorliegenden Quellcode des analysierten Systems anzubieten.
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
16 von 27

Um den in der ersten Projektphase ermittelten Anforderungen gerecht zu werden, wurden
durch den Implementierungspartner CC zwei spezielle Ausgabekomponenten geschaffen –
die Outpath View und die Reporting-Komponente.
Die Out Path View bereitet die Ausgaben des SecFlow-Analyse-Backends auf und stellt sie
dem Entwickler in optisch und logisch aufbereiteter Form dar. Aus ihr kann der Anwender die
ermittelten sicherheitskritischen Pfade und deren Elemente ablesen. Darüber hinaus bildet
die Out Path View die Schnittstelle und Verbindung zwischen der Ausgabe des SecFlow-
Analyseframeworks und dem Quelltext der analysierten Source-Datei: Die angezeigten
Pfadelemente sind mit den Quelltextabschnitten verknüpft und ermöglichen es, in die
betroffene Codezeile in der analysierten Source zu navigieren (siehe Abbildung 5).
Abb. 5: Out Path View
Die im Out Path View angezeigten Informationen beschränken sich auf die für die Anzeige
im Quelltext relevanten Inhalte, wie zum Beispiel Element, Identifier oder Zeilennummer.
Darüber hinaus können auch weitere Statistiken bezüglich der Ausgabe des SecFlow-
Werkzeugs ermittelt werden. Aus der Out Path View heraus ist es möglich, die
Reportausgabe zu starten und Reports in verschiedenen Formaten (HTML, PDF, ODT, XLS)
zu erstellen. Ein Report fasst den analysierten Quelltext, die Ausgabe des SecFlow-
Werkzeugs und die Beziehungen zwischen diesen beiden zu einem Dokument zusammen
und ermittelt Kennzahlen über Quellen, Senken, Pfade, Schwachstellen etc. zu den
analysierten Programmen.
Die Reportgenerierung in SecFlow basiert auf der Reporting Engine JasperReports und
iReport [Jasper 2008]. Das Tool iReport bietet eine GUI-Oberfläche zur Erstellung und
Bearbeitung von JasperReports. Das Subreport-Konzept von iReport gestattet es, einzelne
Komponenten eines Reports und den Report selbst in anderen Reports wiederzuverwenden.
Dadurch ist es möglich, das Aussehen und die Ausgaben des Reportings ohne großen
Aufwand zu ändern und zu erweitern.
Die grundlegenden Informationen zum Aufbau des SecFlow-Werkzeugs und seiner
Bedienung stellte CC im Benutzerhandbuch zusammen. Dieses Handbuch führt in die
Grundzüge von SecFlow ein, geht auf die Funktionen seiner einzelnen Komponenten ein
und leitet den Anwender – sei es ein Entwickler oder ein Betreuer eines ganzen Portfolios
von Programmen – durch sein Analysevorhaben mit dem Werkzeug von der Konfiguration
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
17 von 27

des Werkzeugs bis zu seinen Ausgaben. Neben Informationen, die die Arbeit mit dem
SecFlow-Framework vereinfachen, bietet das Handbuch auch einige Beispiele.
Bewertung von Analysegüte und Performanz
Zur Absicherung der Richtigkeit der Analyseergebnisse und zur Verifizierung der
Werkzeugfunktionalität des erstellten Prototyps wurde die SecuriBench Micro [SecuriBench
2006] benutzt, eine von der Stanford University veröffentlichte Sammlung von kurzen
Programmbeispielen mit charakteristischen Problemfällen für statische Quellcodeanalysen.
Neben der Unterstützung der laufenden Regressionstests während der Weiterentwicklung
des Prototyps gewährleisteten diese Testfälle eine objektive Bewertung der Fähigkeit des
SecFlow-Frameworks, kritische Datenflüsse zu erkennen und dabei möglichst wenige falschpositive
oder falsch-negative Befunde zu ermitteln.
Für die Programmiersprache Java wurden 128 an die [SecuriBench 2006] angelehnte
Testfälle ausgeführt. 110 Testfälle lieferten das korrekte, vollständige Ergebnis; 12 Testfälle
ergaben einen falsch-positiven Befund und 6 Testfälle einen falsch-negativen Befund. Somit
wurden etwa 86 Prozent der kritischen Datenflüsse richtig identifiziert bei einer Quote von
weniger als 9,4 Prozent falsch-positiven Resultaten.
Eine vergleichbare, ebenfalls auf [SecuriBench 2006] basierende Testsuite wurde von den
Kooperationspartnern SHE und CC auch für die Programmiersprache C# konzipiert. Auch
für diese Testfälle wurde eine vergleichbare Testabdeckung und Werkzeuggüte erzielt.
Damit wurde für diese Testfallsammlungen das ursprüngliche Ziel, möglichst viele
Datenflussprobleme zu erkennen und dabei weniger als 50 Prozent falsch-positive Befunde
zu liefern, erreicht. Ob die erzielte Genauigkeit in der Praxis auch bei sehr umfangreichen
Quellprogrammen ähnlich positiv bleibt, muss sich noch erweisen.
Nach derzeitigem Befund bleibt die Performanz des Werkzeugs bisher hinter den im Projekt
gesetzten Erwartungen zurück. Zu einem Teil ist dies der Zeitnot geschuldet, die leider ein
umfangreicheres Feintuning einzelner Komponenten bzw. Konzepte verhinderte. Die
Projektpartner sind zuversichtlich, dass die Analyseregeln noch signifikantes
Optimierungspotential bergen, das in Zukunft noch erschlossen werden soll. Allerdings zeigt
die allgemeine Erfahrung auch, dass statische Datenflussanalyse offenbar ein inhärent
schwieriges Problem darstellt. Ein Indiz dafür liefern zum Beispiel auch Erfahrungsberichte
von Anwendern verschiedener freier oder kommerziell vertriebener Analysewerkzeuge: Alle
bekannten Analyseansätze leiden entweder unter geringer Analyseschärfe, einer hohen
Rate falsch-positiver Befunde oder unter beschränkter Analysegeschwindigkeit — meist
unter allen genannten Defiziten in unterschiedlichem Maße. Daher ist auch im günstigsten
Fall nicht zu erwarten, dass ein Analysewerkzeug ein rundum befriedigendes
Analysevermögen hat. Nach heutigem Kenntnisstand werden Datenflussanalysen immer
erheblichen Beschränkungen unterliegen.
Werkzeugvalidierung
Neben den oben beschriebenen "kleinen" Testfällen war es notwendig, die Funktionalität und
Einsatzfähigkeit des Werkzeugs unter praxisnahen Bedingungen zu erproben. Dazu wurden
insbesondere von den Praxispartnern ICT und SHE verschiedene Testfälle definiert, die
Verwundbarkeiten in der Realität darstellen.
ICT mit seinem Know-how bezüglich J2EE-Plattformen und Internet-Anwendungen stellte
dafür Teile seines Content Management System ICContent zur Verfügung, in dem gezielt
Verwundbarkeiten in verschiedenen Klassen eingebaut wurden. Die eingebauten
Schwachstellen wurden so aufgebaut, dass sie aus verschiedenen Gefahrenbereichen
stammen. So wurden insbesondere Schwachstellen aus den wichtigen Bereichen Command
Injection, Error-Handling und Austausch von Systemparametern in die Testklassen
eingebaut. SHE als Spezialist für Anwendungen in den Programmiersprachen C# und .NET
stellte eine Testanwendung in einer alternativen Sprache (.Net) mit entsprechenden
Eigenschaften zur Verfügung.
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
18 von 27

Weiterhin wurden im Rahmen der Evaluierung von Testanwendungen Datenflüsse
spezifiziert und Junit Tests geschrieben. Dies war notwendig, um die entsprechenden
Klassen über das Datenflussanalyse-Werkzeug auf sicherheitskritische Schwachstellen hin
überprüfen zu können. Damit die Tests durchgeführt werden konnten, mussten für weite
Teile der Testanwendungen Datenflussbeschreibungen – d. h. Summaries – erstellt werden.
Mit ihrer Hilfe kann das Analysewerkzeug die Datenflüsse außerhalb seines Analysebereichs
erkennen und entscheiden, ob sich dabei Schwachstellen ergeben.
Im Zusammenhang mit der Erstellung von Testfällen arbeiteten ICT und SHE eng
zusammen. In mehreren Teilprojekttreffen zum Thema "Test" erörterten sie gemeinsam
relevante Schwachstellen und ein entsprechendes Vorgehen, um entsprechende Codestellen
in den bestehenden Anwendungen definieren zu können.
In der Validierungsphase des Projektes wurde der Werkzeug-Prototyp über einen Zeitraum
von fünf Wochen von den Anwendungspartnern SHE und ICT unter kontrollierten,
realitätsnahen Versuchsbedingungen erprobt. Neben ausführlichen Funktionstests wurde
auch die Usability, d. h. der Komfort bei der Bedienung des Werkzeugs betrachtet.
Die Ergebnisse wurden protokolliert und statistisch ausgewertet. Von den Implementierungspartnern
IESE und CC wurden daraufhin notwendige Fehlerkorrekturen durchgeführt und die
durch die Benutzer eingebrachte Verbesserungen und Erweiterungen im Handling von
SecFlow implementiert.
Wissensbasis
Um dem Anwender von SecFlow später auch eine inhaltliche Hilfe zu den gefundenen
Schwachstellen zu bieten, wurde von ICT eine Wissensbasis angelegt. Diese beinhaltet
Codebeispiele und Entwicklerhinweise, auf die bei Problemen zugegriffen werden kann. Die
Fälle sind hierarchisch aufbereitet und definierten Problembereichen zugeordnet. Die
Wissensbasis wurde bisher mit ca. 50 Fällen aus verschiedenen sicherheitsrelevanten
Bereichen gefüllt. Über das Datenfluss-Werkzeug und über den von ICT entwickelten Source
Code Scanner erhält der Anwender einfachen und direkten Zugriff auf die Fälle der
Wissensbasis. Zur Umsetzung wird die Plattform www.secflow.de genutzt, die mit dem
Content Management System ICContent betrieben wird.
Musterbasierte Codeanalyse
Neben dem datenflussbasierten SecFlow-Werkzeug wurde für die Sprache Java ein
musterbasierter Source Code Scanner als Prototyp für Java in Form eines Eclipse-Plugins
während des Projektes durch ICT erstellt. Das Tool dient der Ermittlung von möglichen
Schwachstellen, die rein musterbasiert, also unabhängig vom Kontroll- und Datenfluss,
erkennbar sind. Hintergrund dieser Entwicklung war der Idee, sicherheitskritische
Codestellen bereits während der Codierung aufzudecken und dem Entwickler ähnlich einer
Rechtschreibprüfung anzuzeigen.
2.2 Darstellung des voraussichtlichen Nutzens
2.2.1 Nutzen für die Allgemeinheit
Das Open Web Application Security Project (OWASP) veröffentlicht jedes Jahr die Rangliste
der wichtigsten Sicherheitsmängel von Web-Anwendungen. Nach wie vor belegen dabei
kritische Sicherheitsmängel, die auf ungeprüften Eingabedaten basieren, die vordersten
Plätze. Das SecFlow-Werkzeug zeigt solche Sicherheitsschwachstellen auf Anwendungsebene
automatisch an.
Das Ergebnis des SecFlow-Projektes ist ein funktionsfähiger Prototyp eines
Analysewerkzeugs für Java- und .Net-Anwendungen. Es kann die Datenflüsse in
Anwendungen auf reale und potentielle Sicherheitslücken überprüfen und zeichnet sich
durch ein hohes Maß an Sprachunabhängigkeit aus. Ein Großteil der Sicherheitslücken
beruht auf Fehlern bei der Programmierung, die auf fehlendes Wissen der Entwickler über
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
19 von 27

Softwaresicherheit zurückzuführen sind. Zudem treten viele Schwachstellen wiederholt auf.
Das SecFlow-Werkzeug, in dem spezielles Wissen über Softwaresicherheit verankert ist,
kann die mühsame und fehleranfällige Arbeit der programminternen Kontrolle und Analyse
übernehmen. Damit ist es möglich, bereits bei der Entwicklung von Software potentielle
sicherheitskritische Schwachstellen des im Entstehen befindlichen Systems vorab zu
identifizieren und durch entsprechende Gegenmaßnahmen zu beseitigen. Der wirtschaftliche
Erfolg liegt deshalb vor allem auch bei den Benutzern von Web-Anwendungen, die höhere
Qualität und Sicherheit erhalten.
Neben den noch bestehenden Analysegrenzen (z. B. bei der Behandlung von Reflection
oder Arrays) ist vorläufig der Einsatz des SecFlow-Frameworks noch durch ein hohes Maß
an manuellen Tätigkeiten, notwendiger spezieller Kenntnis der zu analysierenden
Anwendung selbst sowie der von ihr verwendeten externen Systeme als auch durch die
Analysegeschwindigkeit beschränkt. Ein effektiver Einsatz des Werkzeugs ist derzeit für
kleine bzw. mittelgroße Anwendungen möglich.
Trotzdem wird das Werkzeug einen Beitrag leisten, um die entwickelten wissenschaftlichen
und technischen Konzepte weiter in der IT-Welt zu verbreiten und damit die Herstellung von
sicherer Software zu fördern. Die Verfügbarmachung des Werkzeug-Frameworks als
Open Source sorgt für eine weite Streuung des im Tool enthaltenen Know-hows. Es
gestattet unabhängigen Dritten die Erstellung eigener umgebungsspezifischer
Weiterentwicklungen, was längerfristig zur Hebung des allgemeinen Qualitätsstandards der
deutschen Software-Branche auf dem so wichtigen Feld der IT-Sicherheit beiträgt.
2.2.2 Verwertbarkeit im Sinne des fortgeschriebenen Verwertungsplans
Unabhängig von einer kommerziellen Verwertung der konkret entwickelten SecFlow-
Komponenten ist die im Projekt erworbene Kompetenz im Bereich der fortschrittlichen
Datenflussanalysen bzw. im Bereich der IT-Sicherheit eine wichtige Bereicherung für das
Produkt- und Dienstleistungsportfolio aller beteiligten Technologie-, Anwendungs- und
Forschungspartner. Alle Partner gehen davon aus, die erworbene Kompetenz in
Kundenprojekten weiter erfolgreich einsetzen zu können.
Zudem planen insbesondere die Partner ICT, SHE und CC das entstandene Werkzeug
weiter zu nutzen. So zielt z. B. ICT auf eine Überprüfung der gesamten Software ICContent
durch das SecFlow-Werkzeug, um so einen Sicherheitsvorsprung gegenüber vergleichbaren
Anwendungen zu erlangen. Im Rahmen des Projektes konnten bereits verschiedene Module
von ICContent auf potentielle Schwachstellen hin untersucht werden. Bei diesen Analysen
konnten erfolgreich Schwachstellen lokalisiert, eingegrenzt und behoben werden. Damit
konnte das SecFlow-Werkzeug seinen direkten Nutzen im Rahmen der Software-
Entwicklung bereits beweisen. Diese Arbeiten sollen möglichst im Jahr 2009 abgeschlossen
werden.
Trotz des zusätzlichen Aufwands für die Erweiterung und Verbesserung des Werkzeugs
nach Projektende wird CC die Ergebnisse des Projektes in die Erweiterung der existierenden
CC-Produktpalette einfließen lassen und damit auch den Kompetenzbereich bei Analysewerkzeugen
in Bezug auf das Qualitätsmerkmal Sicherheit und dabei schwerpunktmäßig auf
die Sicherheit von Quellcode ausdehnen. Angestrebt wird dabei auch eine Kopplung des
SecFlow-Werkzeugs bzw. seiner Ausgaben mit bereits existierenden und am Markt
etablierten CC-Produkten wie z. B. mit der Software zur statischen Programmanalyse
CC AUDITOR. Dies bietet nicht nur bestehenden Kunden einen zusätzlichen Nutzwert der
Produkte, sondern stellt gleichzeitig einen zusätzlichen Anreiz für Interessenten zum Einsatz
eines CC-Werkzeuges dar. Insbesondere im Hinblick auf die wachsende Konkurrenz im
Open-Source-Bereich geht CC davon aus, dass die erfolgreiche Anbindung des SecFlow-
Werkzeuges an die CC-Produkte die Erhaltung der Wettbewerbsfähigkeit und die Sicherung
der Marktposition der Produkte bedeuten.
Zudem plant CC, einzelne Komponenten des SecFlow-Frameworks in anderen Zusammenhängen
weiter zu nutzen. So wird z. B. angestrebt unter der Verwendung von Methoden und
Technologien des CIL2QUAD-Compilers, Mechanismen zu entwickeln, die die Konvertierung
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
20 von 27

verschiedener Programmiersprachen unterstützen. Damit könnte CC zukünftig auch
Konvertierungen von Anwendungssystemen von und nach Programmiersprachen, die in der
.NET-Plattform implementiert sind, kostengünstig anbieten und damit seine Marktposition in
diesem Bereich stärken.
Nicht zuletzt eröffnet die geschaffene Schnittstelle zwischen .NET und Java neue
Möglichkeiten: Die Verbindung von .NET mit Java-Code und die damit mögliche Integration
und Auswertung der kommerziellen Microsoft.NET-Welt in die durch Open Source geprägte
Java-Welt ist für eine weitere Verwertung der Ergebnisse von grossem Interesse.
Aufgrund der Erfolge des SecFlow-Projekts erwägen die Konsortialpartner, das SecFlow-
Framework gemeinsam im Rahmen eines Folgeprojekts systematisch zu ergänzen und
weiterzuführen. Dazu fand Anfang Dezember 2008 bereits ein erstes Treffen in Kaiserslautern
statt, in dem die Partner mögliche Ziele für eine Fortführung der Forschungs- und
Entwicklungsarbeiten identifizierten.
2.2.3 Wissenschaftliche Verwertung der Projektergebnisse
Als Forschungsinstitut mit zahlreichen Projektaufträgen unterschiedlichster Themengebiete
beabsichtigt IESE die SecFlow-Projektergebnisse auch in andere Forschungsvorhaben
konstruktiv einzubringen. Entsprechend sollen die Konzepte und Kernkomponenten des
SecFlow-Frameworks im Rahmen des von der Europäischen Gemeinschaft im
7. Rahmenprogramm geförderten Projekts SHIELDS (http://www.shields-project.eu)
weiterverwendet werden. Das SHIELDS-Projekt hat die Zielsetzung, Entwurfs- und
Entwicklungsunterstützung zu liefern, um (grundsätzlich bereits bekannte) Sicherheitsschwachstellen
zu erkennen und aus der Software zu verbannen. Hier soll der SecFlow-
Ansatz dazu beitragen, kritische Datenflüsse im Rahmen von Sicherheitsinspektionen
einfacher und zuverlässiger zu identifizieren.
Modulare, komponierbare Sicherheitsmodelle bieten eine weitere Verwertungsmöglichkeit
der SecFlow-Ergebnisse. Im Projekt VIERforES, einem vom BMBF geförderten Verbundvorhaben,
erforscht Fraunhofer IESE derzeit Möglichkeiten, die Sicherheit komplexer
eingebetteter Systeme zu beurteilen, indem das System in seine Teilkomponenten zerlegt
und diese Teilsystem zunächst unabhängig voneinander analysiert werden. Die so
ermittelten Teilbefunde für jedes Modul werden dann aggregiert, um so schließlich eine
Bewertung des Gesamtsystems abzuleiten. Beim Zusammenfügen der einzelnen
Komponenten-Sicherheitsmodelle spielt die Betrachtung der komponentenübergreifenden
Datenflüsse eine zentrale Rolle. Hier kann auf die in SecFlow entwickelte methodische und
technische Unterstützung zurückgegriffen werden, um Sicherheitsmerkmale entlang der
solcher Datenflüsse zu propagieren.
Eine ähnliche Anwendungsmöglichkeit ergibt sich auch im Bereich der Serviceorientierten
Architekturen (SOAs). Deren Konstruktionsprinzip besteht darin, komplexe Anwendungen
aus einer Menge elementarer Dienste zu komponieren. Bei der Komposition der
Basisdienste ist zu klären, wie sich deren Sicherheitseigenschaften auf das Gesamtsystem
übertragen: Auch hier ist eine genaue Analyse der Datenflüsse unverzichtbar. Da SOA-
Systeme immer größere Verbreitung finden, liefern die SecFlow-Ergebnisse einen wichtigen
Beitrag zum Kompetenz-Portfolio des IESE.
2.3 Fortschritt auf dem Gebiet des Vorhabens bei anderen Stellen
Während der Laufzeit des Vorhabens sind keine bahnbrechend neuen wissenschaftlichen
Erkenntnisse zur statischen Sicherheitsanalyse bekannt geworden, die nicht — zumindest in
ihren Grundzügen — vorher bereits bekannt gewesen wären. Eine übersichtliche Darstellung
zum Stand der Kunst auf dem Gebiet der Programmanalyse bietet zum Beispiel [Binkley
2007].
In Bezug auf die Anwendung spezifischer statischer Analysetechniken sind richtungsweisende
Arbeiten erschienen, die in SecFlow aufgegriffen wurden. So beschreibt Livshits in
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
21 von 27

[Livshits 2006] zum Beispiel sogenannte Derivation Descriptors, mit deren Hilfe die
Datenfluss-Effekte von Methodenzugriffen charakterisiert werden. Eine konsequente
Weiterentwicklung dieser Idee ist die in SecFlow entwickelte Sprache FLOW, die solche
Spezifikationsmöglichkeiten in benutzerfreundlicherem Format ermöglicht.
Die Arbeiten von Lam und Whaley [Whaley&Lam 2004] hatten ebenfalls großen Einfluss auf
das SecFlow-Vorhaben. Die Bedeutung des Einsatzes einer deduktiven Datenbank mit der
Formulierung von Analysestrategien über Datalog-Regeln wird auch durch die Fortführung
der in Joeq verwendeten Ansätze durch Whaley unterstrichen [Whaley 2007].
In Weiterführung dieser Ansätze wird in [Lam et al. 2008] vorgeschlagen, die statische mit
der dynamischen Analyse zu verbinden. Dies stellt einen viel versprechenden Ansatz dar.
Insbesondere für eine Erweiterung des SecFlow-Werkzeugs um die Analyse von
Programmiersprachen, die für die Herstellung dynamischer Webseiten und Webanwendungen
verwendet werden, ist ein Ansatz erforderlich, der die statische Datenflussanalyse
mit anderen dynamischen Analyseverfahren kombiniert. Soll zur Laufzeit generierter
Code auf seine Vertrauenswürdigkeit geprüft werden, muss dieser zuerst mit der bereits
vorhandenen statischen Analyse ausfindig gemacht werden. Anschließend wird der dabei
extrahierte Codeausschnitt für die erforderlichen dynamischen Tests vorbereitet und kann
dann analysiert werden.
Weiterhin wird durch führende Literatur des Compilerbaus [Knuth 2008, Aho et al. 2006]
bestätigt, dass mit BDD auf eine Schlüsseltechnologie der IT gesetzt wurde. Durch die
Einführung leistungsstarker moderner PCs rückt ein Einsatz von BDD auch für komplexe
Aufgaben auf kleinen Systemen immer näher.
Hinsichtlich des Wettbewerbs zu SecFlow auf Produktebene sind seit Projektbeginn einige
Werkzeuge bekannt geworden, die sich mit der Analyse von Quellcode verschiedener
Programmiersprachen beschäftigen. Es sind jedoch keine grundlegenden neuen
Entwicklungen darunter, die bereits Lösungen für die mit SecFlow verbundenen
Zielsetzungen bieten. Der innovative Gehalt des Vorhabens hat sich damit bestätigt.
Die existierenden Werkzeuge sind zumeist sprachabhängig, zielen auf andere, nicht sicherheitsbezogene
Schwachstellen im Quelltext oder verwenden Methoden zur Quelltextanalyse,
die sich von den im SecFlow-Projekt verfolgten Lösungen zur statischen Datenflussanalyse
unterscheiden. Lediglich Fortify [Fortify 2008] bietet mit der Source Code Analysis ein
Werkzeug, das die internen Datenströme überwacht und analysiert. Sollte ein Datenstrom
ungefiltert zu einem sicherheitsrelevanten Objekt gehen, wird eine Warnmeldung
ausgegeben. Hiermit erfüllt Fortify die Anforderungen von SecFlow und ist als einziges der
betrachteten Codeanalyse-Werkzeuge mit der gewünschten Endfunktionalität von SecFlow
vergleichbar. Allerdings sind keine genauen Benchmark-Resultate zu Fortify veröffentlicht.
Die wenigen verfügbaren Informationen deuten jedoch darauf hin, dass die Anwendung
erheblich durch falsch-positive Befunde beeinträchtigt wird. Nach heutigem Stand der
Bewertung ist davon auszugehen, dass sich SecFlow durch eine höhere Analysegenauigkeit
auszeichnen wird. Nicht zuletzt wird sich aber SecFlow gegenüber dem hohen Kaufpreis von
Fortify behaupten können.
2.4 Erfolgte und geplante Veröffentlichungen des Ergebnisses
Die wissenschaftlich-technischen Ergebnisse des Verbundprojektes wurden unter der
Plattform www.sourceforge.net veröffentlicht. Dazu wurde ein entsprechendes Projekt
eingerichtet und das SecFlow-Werkzeug zum Download für Dritte kostenlos bereitgestellt.
Wichtige Informationen zum SecFlow-Projekt als auch SecFlow-Werkzeug sind zusätzlich
auf der projekteigenen Internetseite www.secflow.de zusammengestellt.
Neben den periodischen Zwischenberichten zum Stand des Vorhabens an den Projektträger
sind seitens der Projektpartner während des Vorhabens folgende Publikationen und
Dokumentationen entstanden:
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
22 von 27

[Peine et al. 2006] H. Peine, S. Mandel, D. Richter:
SecFlow: Automatische Ermittlung sicherheitskritischer
Datenflüsse in Quellcode. Statuskonferenz Forschungsoffensive
"Software Engineering 2006", Juni 2006.
[Mandel&Peine 2007] Stefan Mandel, Holger Peine:
The SecFlow Source Code Security Checker: Current Problems
and Solution Alternatives. 23. Annual Computer Security
Application Conference (ACSAC’07), Miami, Florida, Dez. 2007.
[Mandel&Jawurek 2008] Stefan Mandel und Marek Jawurek.
FLOW – Eine Datenfluss-Beschreibungssprache für objektorientierte
Programme. Bericht Nr. 086.08/D, Fraunhofer IESE,
Kaiserslautern 2008.
[Kalenborn et al. 2008] Axel Kalenborn, Gennadi Umansky
SecFlow: Flow Beschreibung, Entwurf 2008
[Richter, Kienast 2008] D. Richter, J. Kienast:
SecFlow: Automatische Ermittlung sicherheitskritischer
Datenflüsse in Quellcode: Benutzerhandbuch, Wiesbaden,
November 2008.
Die wissenschaftlich-technischen Grundlagen des SecFlow-Projekts lieferten die Basis für
zwei Lehrveranstaltungen zum Thema "Entwurf sicherer Software", die Dr. Peine im
Sommersemester 2007 sowie im Wintersemester 2007/08 an den Hochschulen in
Kaiserslautern durchführte. Beide Lehrveranstaltungen wurden von den Studierenden sehr
gut angenommen und erhielten in Vorlesungsumfragen überdurchschnittliche Bewertungen,
wozu sicher auch die aktuellen Bezüge zu den SecFlow-Arbeiten beigetragen haben.
Dank dieser Lehrveranstaltungen konnte Fraunhofer IESE das Interesse der Studenten an
SecFlow wecken und so fähige studentische Mitarbeiter rekrutieren, die mit ihren Projekt-
und Diplomarbeiten zum Erfolg des Projekts beigetragen haben:
[Hildenbrand 2008] Timo Hildenbrand:
Sicherheitsbewertung von Datenflüssen in Java-Programmen.
Diplomarbeit, Fraunhofer IESE / Technische Universität Kaiserslautern,
April 2008.
[Nicolay 2008] Joachim Nicolay:
Entwicklung eines Compilerfrontends für PHP. Diplomarbeit,
Fraunhofer IESE / Technische Universität Kaiserslautern, April
2008.
[Storck 2008] Michael Storck:
Erstellung von Codemodellen aus Bytecode. Projektarbeit, Fraunhofer
IESE / Technische Universität Kaiserslautern, Juni 2008.
[Wagner 2008] Andreas Wagner:
Implementierung einer Werkzeugunterstützung zur Spezifikation
und Visualisierung von Sicherheitsschwachstellen. Praktikumsbericht,
Fraunhofer IESE / Fachhochschule Kaiserslautern, August
2008.
Im Rahmen der Kooperation zwischen ICT und dem Lehrstuhl Wirtschaftsinformatik I der
Universität Trier wurden zwei Studienprojektarbeiten erstellt:
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
23 von 27

[Beinig et al. 2006] V. Beinig, P. Gilberg, M. Hausen,.C. Knaut, A. Westphal:
Studienprojekt SecFlow I: Automatische Erkennung von
Sicherheitsproblemen im Programmquellcode, 2006.
[Heiles et al. 2007] H. Heiles, A. Kiesow, C. Schlimbach, J. Schneider:
Studienprojekt SecFlow II - Automatische Erkennung von
Sicherheitsproblemen im Programmquellcode, 2007.
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
24 von 27

3 Literaturverzeichnis
[Aho et al. 2006] A. V. Aho, M. S. Lam, R. Sethi, J. D. Ullman:
Compilers Principles, Techniques & Tools, 2nd ed., Addison
Wesley, New York, 2006.
[Beinig et al. 2006] V. Beinig, P. Gilberg, M. Hausen,.C. Knaut, A. Westphal:
Studienprojekt SecFlow I: Automatische Erkennung von
Sicherheitsproblemen im Programmquellcode, 2006.
[Binkley 2007] David Binkley:
Source Code Analysis: A Road Map. Proceedings IEEE Future of
Software Engineering (FOSE’07), Washington DC, USA, 2007.
[Engler&Musuvathi 2004] Dawson Engler, Madanlal Musuvathi:
Static Analysis versus Software Model Checking for Bug Finding.
Proceedings 5 th International Conference on Verification, Model
Checking, and Abstract Interpretation (VMCAI 2004) Venedig,
Italien, Januar 2004.
[Eclipse 2008] Eclipse Foundation:
http://www.eclipse.org/
[Fortify 2008] Fortify Software Inc.:
Fortify Source Code Analysis (SCA).
http://www.fortifysoftware.com/products/sca/
[Heiles et al. 2007] H. Heiles, A. Kiesow, C. Schlimbach, J. Schneider:
Studienprojekt SecFlow II - Automatische Erkennung von
Sicherheitsproblemen im Programmquellcode, 2007.
[Hildenbrand 2008] Timo Hildenbrand:
Sicherheitsbewertung von Datenflüssen in Java-Programmen.
Diplomarbeit, Fraunhofer IESE / Technische Universität Kaiserslautern,
April 2008.
[Hind 2001] Michael Hind:
Pointer Analysis: Haven’t We Solved This Problem Yet?
Proceedings of the 2001 ACM SIGPLANSIGSOFT Workshop on
Program Analysis for Software Tools and Engineering
(PASTE’01), Snowbird, Utah, USA, Juni 2001.
[Jasper 2008] Jaspersoft:
Embeddable Open Source Java Reporting Library,
http://jasperforge.org/plugins/project/project_home.php?group_id=
102 und www.jasperforge.org
[Kalenborn et al. 2008] Axel Kalenborn, Gennadi Umansky
SecFlow: Flow Beschreibung, Entwurf 2008
[Knuth 2008] D. E. Knuth:
The Art of Computer Programming, Vol. 4, Pre-Fascicle 1b: A
Draft Of Section 7.1.4 Binary Decision Diagrams, Addison Wesley,
New York, 2008.
[Lam et al. 2008] Monica S. Lam, Benjamin Livshits, John Whaley:
Securing Web Applications with Static and Dynamic Information
Flow Tracking. Proceedings of the 2008 ACM SIGPLAN
Symposium on Partial Evaluation and Semantics-based Program
Manipulation (PEPM'08), San Francisco, Kalifornien, USA, 2008.
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
25 von 27

[Livshits 2006] Benjamin Livshits:
Improving Software Security with Precise Static and Runtime
Analysis. Dissertation, Stanford University, Dezember 2006.
[Mandel&Jawurek 2008] Stefan Mandel, Marek Jawurek.
FLOW — Eine Datenfluss-Beschreibungssprache für objektorientierte
Programme. Bericht Nr. 086.08/D, Fraunhofer IESE,
Kaiserslautern 2008.
[Mandel&Peine 2007] Stefan Mandel, Holger Peine:
The SecFlow Source Code Security Checker: Current Problems
and Solution Alternatives. 23. Annual Computer Security
Application Conference (ACSAC’07), Miami, Florida, Dez. 2007.
[MBEL 2008] University of Arizona:
MBEL: The Microsoft Bytecode Engineering Library
http://www.cs.arizona.edu/projects/mbel/
[Nicolay 2008] Joachim Nicolay:
Entwicklung eines Compilerfrontends für PHP. Diplomarbeit,
Fraunhofer IESE / Technische Universität Kaiserslautern, 2008.
[Peine et al. 2006] H. Peine, S. Mandel, D. Richter:
SecFlow: Automatische Ermittlung sicherheitskritischer
Datenflüsse in Quellcode. Statuskonferenz Forschungsoffensive
"Software Engineering 2006", Juni 2006.
[Richter, Kienast 2008] D. Richter, J. Kienast:
SecFlow: Automatische Ermittlung sicherheitskritischer
Datenflüsse in Quellcode: Benutzerhandbuch, Wiesbaden,
November 2008.
[SecuriBench 2006] Benjamin Livshits:
Stanford SecuriBench Micro. SUIF Group, Stanford University,
2006
http://suif.stanford.edu/~livshits/work/securibenchmicro/pubs.html
[Storck 2008] Michael Storck:
Erstellung von Codemodellen aus Bytecode. Projektarbeit, Fraunhofer
IESE / Technische Universität Kaiserslautern, Juni 2008.
[Wagner 2008] Andreas Wagner:
Implementierung einer Werkzeugunterstützung zur Spezifikation
und Visualisierung von Sicherheitsschwachstellen. Praktikumsbericht,
Fraunhofer IESE / Fachhochschule Kaiserslautern, August
2008.
[Whaley 2004] J. Whaley:
BDD-Based Deductive Database. 2004
http://bddbddb.sourcefourge.net/
[Whaley 2005] J. Whaley:
Joeq: A Virtual Machine and Compiler Infrastructure. In Science of
Computer Programming Journal, 2005.
http://joeq.sourceforge.net/
[Whaley 2007] John Whaley:
Context-sensitive Pointer Analysis Using Binary Decision
Diagrams. Dissertation, Stanford University, März 2007.
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
26 von 27

[Whaley&Lam 2004] J. Whaley, M. Lam:
Cloning-based context-sensitive pointer alias analysis using binary
decision diagrams. Proceedings of the ACM SIGPLAN 2004
Conference on Programming Language Design and
Implementation (PLDI’04), Washington, DC, USA, Juni 2004.
[Whaley et al. 2005] J. Whaley, D. Avots, M. Carbin, M. S. Lam:
Using Datalog with Binary Decision Diagrams for Program
Analysis. In Proceedings of Programming Languages and
Systems: Third Asian Symposium, APLAS 2005, Tsukuba, Japan,
November 2005.
Datei
SecFlow_Gesamtschlussbericht_V10.odt
Version
1.0
Datum
2009-02-02
Bearbeiter/in
Dana Richter
Seite
27 von 27