Repeating the past experimental and empirical methods in system and software security

Abstract

I propose a new method of analyzing intrusions: instead of analyzing evidence and deducing what must have happened, I find the intrusion-causing circumstances by a series of automatic experiments. I first capture process';s system calls, and when an intrusion has been detected, I use these system calls to replay some of the captured processes in order to find the intrusion-causing processes—the cause-effect chain that led to the intrusion. I extend this approach to find also the inputs to those processes that cause the intrusion—the attack signature. Intrusion analysis is a minimization problem—how to find a minimal set of circumstances that makes the intrusion happen. I develop several efficient minimization algorithms and show their theoretical properties, such as worst-case running times, as well as empirical evidence for a comparison of average running times. Our evaluations show that the approach is correct and practical; it finds the 3 processes out of 32 that are responsible for a proof-of-concept attack in about 5 minutes, and it finds the 72 out of 168 processes in a large, complicated, and difficult to detect multi-stage attack involving Apache and suidperl in about 2.5 hours. I also extract attack signatures in proof-of-concept attacks in reasonable time. I have also considered the problem of predicting before deployment which components in a software system are most likely to contain vulnerabilities. I present empirical evidence that vulnerabilities are connected to a component';s imports. In a case study on Mozilla, I correctly predicted one half of all vulnerable components, while more than two thirds of our predictions were correct.

Ich stelle eine neue Methode der Einbruchsanalyse vor: Anstatt Spuren zu analysieren und daraus den Ereignisverlauf zu erschließen, finde ich die einbruchsverursachenden Umstände durch automatische Experimente. Zunächst zeichne ich die Systemaufrufe von Prozessen auf. Nachdem ein Einbruch entdeckt wird, benutze ich diese Systemaufrufe, um Prozesse teilweise wieder einzuspielen, so dass ich herausfinden kann, welche Prozesse den Einbruch verursacht haben —die Ursache-Wirkungs-Kette. Ich erweitere diesen Ansatz, um auch die einbruchsverursachenden Eingaben dieser Prozesse zu finden — die Angriffs-Signatur. Einbruchsanalyse ist ein Minimierungsproblem — wie findet man eine minimale Menge von Umständen, die den Einbruch passieren lassen? Ich entwickle einige effiziente Algorithmen und gebe sowohl theroretische Eigenschaften an, wie z.B. die Laufzeit im ungünstigsten Fall, als auch empirische Ergebnisse, die das mittlere Laufzeitverhalen beleuchten. Meine Evaluierung zeigt, dass unser Ansatz korrekt und praktikabel ist; er findet die 3 aus 32 Prozessen, die für einen konstruierten Angriff verantwortlich sind, in etwa 5 Minuten, und er findet die 72 von 168 Prozessen, die für einen echten, komplizierten, mehrstufigen und schwer zu analysierenden Angriff auf Apache und suidperl verantwortlich sind, in 2,5 Stunden. Ich kann ebenfalls Angriffs-Signaturen eines konstruierten Angriffs in vernünftiger Zeit erstellen. Ich habe mich auch mit dem Problem beschäftigt, vor der Auslieferung von Software diejenigen Komponenten vorherzusagen, die besonders anfällig für Schwachstellen sind. Ich bringe empirische Anhaltspunkte, dass Schwachstellen mit Importen korrelieren. In einer Fallstudie über Mozilla konnte ich die Hälfte aller fehlerhaften Komponenten korrekt vorhersagen, wobei etwa zwei Drittel aller Vorhersagen richtig war.