Fallstudie als Bachelorarbeit in Cybersecurity 2026: Penetrationstest oder Sicherheitsvorfall wissenschaftlich auswerten

Ein Penetrationstest oder eine Analyse eines realen Sicherheitsvorfalls sind für eine Cybersecurity-Bachelorarbeit attraktive Ausgangspunkte, weil sie konkret, praxisnah und meist gut dokumentierbar sind. Die Schwierigkeit liegt nicht in der technischen Durchführung – dafür gibt es etablierte Werkzeuge und Vorgehensmodelle –, sondern darin, aus einer technischen Übung eine wissenschaftliche Fallstudie zu machen, die eine Forschungsfrage beantwortet, statt nur ein Testprotokoll abzuliefern.

Dieser Beitrag zeigt, wie eine Fallstudie zu Penetrationstest oder Sicherheitsvorfall methodisch aufgebaut wird, welche ethischen und rechtlichen Grenzen dabei gelten und wie sich die technischen Ergebnisse wissenschaftlich auswerten lassen, statt sie nur zu protokollieren – inklusive der Frage, ob ein Einzelfall oder mehrere vergleichende Fälle die bessere Wahl für eine Bachelorarbeit sind, und wie sich die Ergebnisse am Ende überzeugend gegenüber einer Prüfungskommission verteidigen lassen.

Zwei Wege: Penetrationstest oder Vorfallanalyse

Ein weiterer Überblick über Cybersecurity-Themen für die Bachelorarbeit, etwa Phishing-Erkennung oder IoT-Sicherheitsanalysen, findet sich im Beitrag zu 30 Themen für die Bachelorarbeit in Informatik; dieser Beitrag geht für das Fallstudiendesign spezifisch in die Tiefe. Ein selbst durchgeführter Penetrationstest eignet sich, wenn ein Testsystem oder ein kooperationsbereites Unternehmen mit klarer Autorisierung zur Verfügung steht, und liefert eigene Primärdaten. Eine Analyse eines bereits eingetretenen, dokumentierten Sicherheitsvorfalls – etwa anhand anonymisierter Logs eines Praxispartners oder eines öffentlich dokumentierten Falls aus der Fachliteratur – vermeidet die rechtlichen Hürden eines eigenen Tests, verlangt aber eine sorgfältige Quellenkritik der vorliegenden Dokumentation.

Einzelfall oder vergleichende Fallstudie?

Eine grundsätzliche Designentscheidung betrifft die Anzahl der untersuchten Fälle. Eine tiefgehende Einzelfallstudie – ein Penetrationstest eines einzelnen Testsystems oder die Analyse eines einzelnen Vorfalls – erlaubt maximale Detailtiefe, macht aber Aussagen über Verallgemeinerbarkeit schwieriger. Eine vergleichende Fallstudie mit zwei oder drei Fällen, etwa Penetrationstests mehrerer strukturell ähnlicher Testsysteme, erlaubt es, Muster über Fälle hinweg zu identifizieren, verlangt aber entsprechend mehr Bearbeitungszeit pro Fall. Grundlagen zur Wahl zwischen Einzelfall- und Mehrfallstudien sowie weiteren Forschungsdesigns zeigt der Beitrag zum Forschungsdesign der Bachelorarbeit. Für eine Bachelorarbeit mit begrenzter Bearbeitungszeit ist ein gut dokumentierter Einzelfall meist die realistischere Wahl als zwei oberflächlich behandelte Fälle.

Den Fall auswählen und begründen

Eine Fallstudie lebt von einer expliziten Begründung, warum gerade dieser Fall untersucht wird – nicht als beliebiges Beispiel, sondern als Fall, der für eine bestimmte Klasse von Systemen oder Vorfällen aufschlussreich ist. Ein Kriterienkatalog hilft: Ist der Fall typisch für eine bestimmte Systemklasse (etwa eine Standard-Webanwendung eines KMU) oder gerade wegen seiner Untypik interessant (etwa ein besonders komplexer, mehrstufiger Angriff)? Liegt genug zugängliches Material vor, um den Fall in der Tiefe zu untersuchen? Und lässt sich der Fall ohne Verletzung von Vertraulichkeit oder Recht bearbeiten? Diese drei Fragen gehören explizit in die Falldarstellung der Arbeit, nicht nur implizit in die Themenwahl. Eine gute Praxis ist, diese Begründung als eigenen kurzen Unterabschnitt zu Beginn des Methodikkapitels zu führen, statt sie über die Einleitung verstreut anzudeuten.

Durchführung eines Penetrationstests

Für einen selbst durchgeführten Penetrationstest orientiert sich das methodische Vorgehen an einem anerkannten Framework wie dem Penetration Testing Execution Standard (PTES) oder dem OWASP Testing Guide für Webanwendungen. PTES gliedert den Test in sieben Phasen: Vorbereitung und Scoping (Pre-engagement Interactions), Informationsbeschaffung, Bedrohungsmodellierung, Schwachstellenanalyse, aktive Ausnutzung (Exploitation), Post-Exploitation und Berichterstattung; der OWASP Testing Guide ergänzt für Webanwendungen konkrete Testfälle je Schwachstellenkategorie. Für die Bachelorarbeit ist entscheidend, dass jede Phase dokumentiert wird – welche Werkzeuge eingesetzt wurden, welche Befunde in welcher Phase entstanden sind, und wie von einem Befund zum nächsten geschlossen wurde. Ein reines Auflisten gefundener Schwachstellen ohne diese methodische Rahmung wirkt wie ein technisches Protokoll, nicht wie eine wissenschaftliche Untersuchung.

Durchführung einer Vorfallanalyse

Eine Analyse eines bereits eingetretenen Sicherheitsvorfalls orientiert sich methodisch an digitaler Forensik und Incident-Response-Modellen. Weit verbreitet ist der Lebenszyklus aus NIST SP 800-61 Rev. 2 (Vorbereitung, Erkennung und Analyse, Eindämmung/Beseitigung/Wiederherstellung, Nachbereitung); die im April 2025 veröffentlichte Rev. 3 ersetzt Rev. 2 und ordnet Incident Response entlang der Funktionen des NIST Cybersecurity Framework 2.0 ein – welche Fassung die Arbeit zugrunde legt, sollte im Kapitel ausdrücklich stehen. Für die Bachelorarbeit bedeutet das: Die verfügbaren Rohdaten – Logs, Forensikberichte, Zeitstempel – werden chronologisch rekonstruiert, um eine nachvollziehbare Angriffskette (Kill Chain) darzustellen. Eine bewährte Struktur ist die Zuordnung der beobachteten Schritte zu einem etablierten Referenzmodell wie dem MITRE-ATT&CK-Framework, das Angriffstechniken in standardisierte Taktiken und Techniken einordnet und damit eine vergleichbare, nachvollziehbare Sprache für die Analyse liefert. Wichtig ist, klar zu trennen, welche Schritte der Kill Chain durch harte Beweise (Log-Einträge mit Zeitstempel) belegt sind und welche nur plausibel rekonstruiert, aber nicht direkt belegt sind – diese Unterscheidung gehört explizit in die Darstellung.

Systematische Dokumentation der Befunde

Ob Penetrationstest oder Vorfallanalyse: Jeder einzelne Befund sollte nach einem konsistenten Schema dokumentiert werden – Beschreibung der Schwachstelle oder des Angriffsschritts, Schweregrad nach einem etablierten Bewertungssystem wie CVSS, Nachweis (Screenshot, Log-Auszug oder Beweisführung), und eine Einschätzung der Ausnutzbarkeit und potenziellen Auswirkung. Dieses konsistente Schema erlaubt es später, die Befunde systematisch statt anekdotisch zu vergleichen und zu klassifizieren, was den Übergang vom Testprotokoll zur wissenschaftlichen Auswertung markiert.

Beispiel: eine dokumentierte Befundzeile

Ein solches Schema, konsistent für alle Befunde durchgehalten, macht die Arbeit im Ergebnisteil sofort auswertbar: Wie viele Befunde fallen in welche Schweregradkategorie, welche Schwachstellenklassen (Injection, Authentifizierung, Konfiguration) häufen sich, und was sagt diese Verteilung über die untersuchte Systemklasse aus.

Von der Befundliste zur wissenschaftlichen Auswertung

Der Schritt, der eine technische Übung zu einer Bachelorarbeit macht, ist die Auswertung über die reine Befundliste hinaus. Typische Auswertungsfragen: Welche Kategorien von Schwachstellen häufen sich, und was sagt das über systematische Schwächen im untersuchten System aus? Wie hätte eine bestimmte Sicherheitsmassnahme – etwa eine Web Application Firewall oder eine strengere Eingabevalidierung – welche der gefundenen Schwachstellen verhindert? Bei einer Vorfallanalyse: An welchem Punkt der Angriffskette hätte eine frühere Erkennung den Schaden am wirksamsten begrenzt? Diese Fragen führen von der reinen Beschreibung zur Diskussion, in der die eigenen Befunde mit der Fachliteratur zu ähnlichen Schwachstellenklassen oder Angriffsmustern verglichen werden. Eine zusätzliche, oft aussagekräftige Auswertungsdimension ist die zeitliche: Wie lange hätte es realistisch gedauert, bis ein aufmerksames Monitoring-System die gefundene Schwachstelle oder den beobachteten Angriffsschritt erkannt hätte, verglichen mit der Zeit, die der Test oder Vorfall tatsächlich bis zur Entdeckung benötigte?

Rechtliche und ethische Grenzen

Ein Penetrationstest ohne ausdrückliche, schriftliche Autorisierung ist in der Schweiz strafrechtlich relevant – das unbefugte Eindringen in ein Datenverarbeitungssystem ist nach Art. 143bis StGB strafbar, und gute Absichten wie ein Sicherheitstest ändern daran nichts, solange die Befugnis fehlt. Für die Bachelorarbeit bedeutet das: Vor jedem Test steht eine schriftliche Vereinbarung (Rules of Engagement) mit dem Systemeigentümer, die Scope, erlaubte Techniken, Testzeitraum und Ansprechpersonen bei Zwischenfällen festlegt. Diese Vereinbarung gehört, in anonymisierter oder auszugsweiser Form, in den Anhang der Arbeit. Wie generell mit Datenschutz und Einwilligung bei eigenen Erhebungen umzugehen ist, zeigt der Beitrag zu Datenschutz und Ethikvotum bei eigenen Erhebungen – bei einer Vorfallanalyse mit Praxispartnerdaten gilt zusätzlich, dass alle personenbezogenen Angaben in Logs vor der Analyse konsequent anonymisiert werden müssen, auch wenn der Zugriff selbst rechtmässig war. Bei einem Testsystem, das ausserhalb der eigenen Institution liegt – etwa bei einem Praxispartner-Unternehmen –, sollte zusätzlich schriftlich festgehalten werden, wer im Fall eines unerwarteten Systemausfalls während des Tests informiert wird und welche Eskalationsschritte gelten.

Häufige Fehler

Häufige Fragen

Eine Cybersecurity-Fallstudie überzeugt, wenn sie über das reine Testprotokoll hinausgeht: ein begründeter Fall, ein anerkanntes methodisches Vorgehen, eine konsistente Dokumentation und eine Diskussion, die aus dem Einzelfall verallgemeinerbare Erkenntnisse ableitet, statt nur eine technisch korrekte, aber wissenschaftlich unausgewertete Sammlung von Testresultaten zu präsentieren.