dsauer

4 08, 2021

Common Vulnerability Scoring System (CVSS) – ein (subjektiv) einheitliches Bewertungsschema für Sicherheitslücken?

von |4. August 2021|Pentest|0 Kommentare|

Es kann sehr fesselnd sein, in der Rolle eines Angreifers in fremde IT-Systeme einzudringen. Als Penetrationstester sollte dabei jedoch nie das eigentliche Ziel aus den Augen verloren werden: die Identifikation aller Einstiegspunkte bzw. Sicherheitslücken in einem Zielsystem. Die Liste von Schwachstellen kann sehr lang und unübersichtlich werden. Um einem Auftraggeber aber mitzuteilen, welche Schwachstellen zuerst adressiert bzw. behoben werden sollten, müssen die ermittelten Schwachstellen nach ihrem Risiko geordnet werden.

Grundsätzlich kann das Risiko einer Schwachstelle über zwei verschiedene Arten dargestellt werden. So kann entweder ein konkreter Zahlenwert ermittelt (bspw. 1.034,99 Euro) werden oder eine Aussage über die Schwere des Risikos getroffen (wie gering, mittel, hoch) werden. Der konkrete Zahlenwert ist das Ergebnis einer quantitativen Risikoanalyse. Diese eignet sich beispielsweise zur Bestimmung des Risikos eines Festplattenausfalls, da Festplatten einen konkreten Preis und eine durch­schnitt­liche Lebensdauer haben. Im Gegensatz dazu liegen einem Pentester bei Schwachstellen von IT-Systemen normalerweise nicht genug Informationen dieser Art vor, sodass diese Form der Risikoanalyse nicht empfehlenswert ist. Stattdessen kann aber eine qualitative Risikoanalyse vorgenommen werden, da immer Aussagen über die Eintrittswahrscheinlichkeit und das mögliche Schadensausmaß einer Schwachstelle getroffen und somit die Schwere des Risikos abgeschätzt werden kann. Wie bei einer Schätzung üblich, werden verschiedene Pentester zu unterschiedlichen Risikobewertungen gelangen, da ihre Wahrnehmung und Erfahrungen uneinheitlich sind – selbst, wenn sie sich auf dasselbe Bewertungsschema beziehen.

Jedoch benötigen gerade regulatorische Stellen wie das Regierungspräsidium Darmstadt ein einheitliches System, da sie konkrete Anforderungen und Maßnahmen definieren müssen. Infolgedessen fordern sie von Pentestern eine Risikobewertung nach dem Common Vulnerability Scoring System (CVSS) durchzuführen. Bei diesem handelt es sich um ein metrisches Bewertungsschema, welches einer Schwachstelle eine Punktzahl bzw. einen Score zwischen 0 und 10 zuweist – je höher der Score desto gravierender ist das Risiko einer Schwachstelle. Auch wenn das Risiko einer Schwachstelle beim CVSS anhand einer Vielzahl von Parametern berechnet wird (s. https://www.first.org/cvss/calculator/3.1), liegen Kenngrößen wie die Auswirkung einer erfolgreich ausgenutzten Schwachstelle auf die Integrität im Ermessen der Pentester. Somit können Risikoangaben wie der CVSS Score einem Auftraggeber zwar als Richtwert dienen, jedoch sollte intern immer eine eigene Schwachstellenbewertung vorgenommen werden.

6 02, 2020

„Digitale Forensik“-Vorlesung im Wirtschaftsinformatik-Studiengang

von |6. Februar 2020|IT-Forensik|0 Kommentare|

Der vor Kurzem durchgeführte Hackerangriff auf die Uni Gießen hat vielen Menschen vor Augen geführt, dass die Bedrohung durch Angreifer aus dem Internet stetig zunimmt. Um aus solchen Sicherheitsvorfällen lernen zu können, benötigt es IT-Forensiker, die den 7 W-Fragen der Kriminalistik nachgehen: Wer (Täter), was (Straftat), wann (Tatzeitpunkt), wo (Tatort), wie (Tathergang) womit (Werkzeuge) und warum (Motiv). So versuchen sie über die vom Angreifer hinterlassenen digitalen Spuren den Sicherheitsvorfall zu rekonstruieren und den Täter – im Idealfall – zu überführen.

Über Hochschulkontakte bot sich mir im Wintersemester 19/20 die Gelegenheit das Modul „Digitale Forensik“ im Masterstudiengang der Wirtschaftsinformatik an der Technischen Hochschule Mittelhessen (THM) anzubieten. Mit der Sichtweise eines Angreifers auf IT-Systeme, beschäftigte es mich als Pentester ohnehin, welche Spuren bei einem Angriff hinterlassen werden und wie diese verschleiert werden können. Dahingehend standen für mich folgende Themen auf der Agenda:

  1. Hacking
  2. Antiforensik
  3. Gutachtenerstellung
  4. Live Forensik
  5. Datenträgeranalyse
  6. Anwendungsforensik
  7. Erstellung von Schadsoftware
  8. Malwareanaylse
  9. Reverse Engineering

Getreu dem Zitat von Sunzi – „Du musst deinen Feind kennen, um ihn besiegen zu können“ -, wechselte ich je nach Vorlesungseinheit die Perspektive zwischen den beiden Kontrahenten und ließ die besprochenen Inhalte im nachstehenden Szenario von den Studierenden anwenden:

Die Dubius Payment Ltd. ist ein vor Kurzem gegründeter Zahlungsdienstleister, welches Kreditkarteninformationen in seinen Systemen speichert, verarbeitet und weiterleitet. Seit dem 14. November 2019 gegen 16:45 Uhr (Donnerstag) verzeichnet das Produktionssystem Ausfälle und ihr Intrusion Detection System meldet in regelmäßigen Abständen einen ungewöhnlich hohen Netzwerkverkehr über ihr Payment Gateway. Aus Angst vor einem Hackerangriff haben sie den Studierenden als IT-Forensiker beauftragt, den Fall zu analysieren.

In ihrer praktischen Arbeit stellten die Studierenden über das Sammeln und der Analyse von digitalen Spuren auf dem Livesystem fest, dass ein Mitarbeiter des Unternehmens in regelmäßigen Zeitabständen Kreditkartendaten aus der Datenbank abzieht. Wie in der Realität üblich, blieb es nicht bei dieser Schlussfolgerung, sondern die Studierenden mussten nun über eine anschließende Datenträgeranalyse des Arbeitscomputers vom Tatverdächtigen die Zweifelsfrage klären, ob der Nutzer das Opfer eines Hackerangriffs geworden ist oder tatsächlich die Schuld am Datendiebstahl trägt. Ihre Ergebnisse hielten sie in Form eines Gutachtens fest.

Natürlich lief im ersten Durchlauf nicht alles reibungslos. So hatte ich beispielsweise mit dem Aufbau meines geplanten Labors zu kämpfen: Damit die Studierenden lernen ihr eigenes Toolkit auf einem kompromittierten System zu verwenden, sollte das Linuxprogramm „/usr/bin/ls“ mit folgendem „Schadcode“ auf dem Livesystem ersetzt werden:

#include <iostream>

#include <cstdlib>

using namespace std;

int main() {

cout << "I've got ya! ;)" << endl;

system("sleep 1");

system("sudo reboot");

return 0;

}

Da “ls” jedoch auch von Init-Skripten aufgerufen wird, führte die Schadsoftware im Falle eines Neustarts zu einer Endlosschleife. Die Verwendung eines Aliases in Linux lieferte hier Abhilfe. Umso erfreulicher ist die positive Resonanz der Studierenden, welche sich in den Anmerkungen der Lehrveranstaltungsevaluation abzeichnet (s. Evaluationsergebnis).

“Es ist das spannendste Modul im gesamten Wirtschaftinformatik Studium, es fesselt und macht viel Spaß anzuwenden/zu lernen“

Student/in

So hat beispielsweise der vorige Kommentar mit dazu beigetragen, dass ich mir als Ziel genommen habe, einen neuen Online-Kurs für die binsec academy zu entwerfen: Das “Digital Forensics Training”, welches zukünftig Teilnehmer als Binsec Academy Certified Digital Forensic Professional (BACDFP) zertifizieren soll.

2 07, 2019

Die Aussagekraft von Vulnerability-Scanner vs. Penetrationstests

von |2. Juli 2019|Pentest|1 Kommentar|

It is worth mentioning that automated methods are much faster in performing the security analysis.

Alavi, Bessler und Massoth 2018

Die vorherige Anmerkung von Alavi, Bessler und Massoth schildert den ausschlaggebenden Beweggrund hinter den Einsatz von Vulnerability-Scanner bei der Durchführung von Penetrationstests: Zwar haben beide als Hauptaufgabe die Identifikation von Schwachstellen in IT-Systemen, jedoch geschieht dies bei Vulnerability-Scannern rein automatisiert, welche lediglich von einem Anwender konfiguriert und gestartet werden müssen. Wegen den geringeren personellen Ressourcen sollten Kunden beim Einkauf eines Pentests Acht geben, nicht mit einem aufbereiteten Vulnerability-Scan-Report „abgespeist“ zu werden.

Inwieweit die Ergebnisse eines Vulnerability-Scanners mit einem Penetrationstest verglichen werden können, haben zwei BACPPler – Saed Alavi und Niklas Bessler – in ihrem Paper „A Comparative Evaluation of Automated Vulnerability Scans Versus Manual Penetration Tests on False-negative Errors“ gezeigt. Für ihre Analyse haben sie sich die Frage gestellt, wie viele Schwachstellen von einem Vulnerability-Scanner und einem Penetrationstester nicht als solche identifiziert werden, obwohl die Lücken vorhanden sind? Im Wissenschaftsjargon ist hier die Rede von der False-Negative-Rate (FNR). Dazu haben sie eine mit Schwachstellen übersäte IT-Infrastruktur aufgebaut und diese sowohl einem Penetrationstest als auch einem Vulnscan unterzogen. Wie – zugegebenermaßen – zu erwarten war, kamen sie zu dem Schluss, dass Penetrationstests zwar Vulnerablity-Scans beinhalten können, aber mit ihren manuellen Prüfphasen weit darüber hinaus gehen:

„Most importantly, we have seen a remarkable higher false-negative rate in the vulnerability scan, which suggests that automated methods cannot replace manual penetration testing. However, the combination of both methods is a conceivable approach.“

Alavi, Bessler und Massoth 2018

Dennoch ist der Einsatz von Vulnerability-Scannern nicht obsolet: Auch wenn die Fülle an Informationen eines Vulnerability-Scanners erst überblickt, sortiert und ausgewertet werden muss – je nach Scanner kann dies leider selbst einen Fachmann benötigen -, sind sie ein Werkzeug um die eigene IT zu härten.

21 02, 2019

BACSCP: Die Entstehung des Secure Coding Trainings

von |21. Februar 2019|binsec|0 Kommentare|

Jedes Semester schließen Tausende Informatikstudenten erfolgreich ihr Studium ab – leider meist ohne oder mit nur geringen Kenntnissen in sicherer Softwareentwicklung. Wen wunderts, dass dann altbekannte Schwachstellen wie Cross-Site-Scripting (XSS) noch immer nicht der Vergangenheit angehören. Als Folge stehen Unternehmen selbst in der Verantwortung, ihre Entwickler zu schulen und für Sicherheitsmaßnahmen in deren Softwareprodukten zu sorgen.

Die Geschichte unserer neuartigen Online-Schulung begann vor ein paar Jahren mit einer Kundenanfrage bezüglich einer OWASP-Entwicklerschulung zu sicherer Softwareentwicklung. Als PCI-DSS-zertifiziertes Unternehmen musste unser Kunde jährlich nachweisen, dass sich seine Softwareentwickler im Rahmen der aktuellen Techniken zur sicheren Programmierung fortbilden. Natürlich hätte als Nachweis auch eine Bescheinigung darüber genügt, ein Buch gelesen oder an einem Vortrag (passiv) teilgenommen zu haben… So etwas kann aber weder im Sinne des PCI DSS noch im Sinne der Softwareentwickler sein.

So kam es dazu, dass wir als binsec einen 2-Tages-Workshop konzipierten, zu gleichen Teilen aus Theorie- und aus Praxiselementen aufgebaut. Während wir am ersten Tag auf die Anforderungen des PCI-DSS an Softwareentwickler und auf die OWASP Top 10 eingingen, musste jeder Schulungsteilnehmer am zweiten Tag eine verwundbare Webanwendung härten und anschließend versuchen, die in den Anwendungen seiner Kollegen verbliebenen Schwachstellen auszunutzen. Mit jedem erfolgreichen Angriff sammelten die Teilnehmer Punkte und kamen damit dem Gewinn der Siegesprämie – eines Amazon Gutscheins – Schritt für Schritt näher. Unterm Strich verlief der erste Teil des Trainings durchaus erfolgreich, doch stach das positive Feedback zum zweiten Abschnitt deutlich hervor. Die Teilnehmer waren fokussiert und engagiert sich gegenseitig „auszuspielen“, weshalb ihre Rückmeldung für uns nicht überraschend kam: „Weniger Theorie, mehr Praxis, bitte.“

Wir begannen parallel zu dieser Entwicklerschulung, diverse Lehrveranstaltungen an Hochschulen zu halten, in denen wir sukzessive den Praxisanteil in den Vordergrund rückten. Wie schon bei unserer Vorlesung zu Penetration-Testing, aus der unser Zertifizierungslehrgang „Binsec Academy Certified Pentest Professional (BACPP)“ hervorgegangen ist, entschieden wir als binsec uns auch bei unserer Entwicklerschulung „Secure Software Development Training“ dazu, sie zur Basis von etwas Neuem zu machen: Es schlug die Geburtsstunde des „Secure Coding Trainings“ der binsec academy:

In dieser Online-Schulung zu Secure Coding schlüpft der Teilnehmer in die Rolle eines Teamleiters, dem die Aufgabe zuteilwird, in einer verwundbaren REST-API die am meisten verbreiteten Schwachstellen (OWASP TOP 10) zu identifizieren und diese im Programmcode zu beheben. Der Clou dabei ist: Der Teilnehmer kann als Programmiersprache PHP, Java, Python, Perl, Go, Ruby oder Node.js wählen und wird mit unserem BACSCP-Zertifikat (Binsec Academy Certified Secure Coding Professional) belohnt, wenn mindestens acht von insgesamt zehn Sicherheitslücken erfolgreich entfernt wurden. Zertifizierte BACSCPler können

  • die am meisten verbreiteten Schwachstellen in Webanwendungen identifizieren und Sicherheitslösungen entwerfen,
  • eine Webanwendung gemäß OWASP und PCI DSS sicher entwickeln, sowie
  • einen Secure-Code-Review strukturiert durchführen.

Nach den ersten Betatests erweiterten wir die Kooperation mit Hochschulen, um Studierenden der Informatik die Inhalte sicherer Softwareentwicklung zu vermitteln. Wir hoffen hiermit einen wesentlichen Beitrag zur anwendungsorientierten IT-Sicherheit leisten zu können.

19 10, 2018

Tipps zum Anfertigen wissenschaftlicher Arbeiten

von |19. Oktober 2018|Unkategorisiert|0 Kommentare|

Als Dozent begegne ich vielen Studierenden, die während der Anfertigung ihrer Abschlussarbeit unter Ratlosigkeit und Zeitproblemen leiden. Die Wurzel allen Übels ist meist eine oberflächliche Vorbereitung, die zu einer unwissenschaftlichen Vorgehensweise geführt hat. Wie würden Sie beispielsweise vorgehen, wenn Sie acht Stunden Zeit hätten, einen Baum zu fällen? Die Mehrheit würde wahrscheinlich sofort die Axt ergreifen und gegen den Baum schwingen, statt die ersten sechs Stunden mit dem Schärfen ihrer Axt zuzubringen. Diese Analogie von Abraham Lincoln zeigt auf sehr einfache Art und Weise, wie bedeutsam eine intensive Einarbeitung in das Wunschthema beim wissenschaftlichen Arbeiten ist.

Den Kern einer Abschlussarbeit stellt eine wissenschaftliche Fragestellung dar. Diese leitet sich üblicherweise aus einem komplexen Problem ab, welches zu bewältigen war oder ist. In anderen Worten: Eine Thesis spiegelt lediglich einen reproduzierbaren Lösungsweg wider – nicht mehr, aber auch nicht weniger.

Die erste Hürde beim wissenschaftlichen Arbeiten ist es, die Fragestellung auf das Wesentliche einzugrenzen. Wenn beispielsweise der Raum zu weit aufgespannt wird, entstehen Formulierungen wie „[…] wurde im Rahmen dieser Arbeit nicht untersucht“. Solche Ausdrücke implizieren, dass der Autor einer solchen Abschlussarbeit entweder zu wenig Zeit in die Arbeit investiert hat oder nicht im Besitz der notwendigen Kompetenzen war. Beide Fälle werfen unnötigerweise ein schlechtes Bild auf das Werk. Zudem unterstützt eine zentrale Fragestellung die Herleitung einer stringenten Argumentation.

Worin unterscheidet sich aber eine wissenschaftliche Arbeit von einem Referat bzw. was verbirgt sich hinter dem Begriff der Wissenschaftlichkeit? Grundsätzlich ist das Fundament einer wissenschaftlichen Ausarbeitung ein breiter Literaturüberblick. Durch den Bezug auf diverse Autoren (und/oder auch Abgrenzungen) werden die eigenen Ausführungen zu einer abschließenden Erkenntnis übergeleitet. Diese sollte – in irgendeiner Form – mit den Ergebnissen anderer Forschender in Verbindung gesetzt werden, welche sich mit einer ähnlichen Thematik befasst haben. Einen Mehrwert liefert eine wissenschaftliche Arbeit jedoch nur, wenn die Ergebnisse von anderen Personen reproduziert werden können.

Um wissenschaftliche „Schwächen“ bereits in der Anfangsphase erkennen zu können, sollte vorab immer ein Exposé zu einer anvisierten Fragestellung angefertigt werden. Dieses beinhaltet neben der Problemstellung und der damit verbundenen Zielsetzung auch eine Darlegung der wissenschaftlichen Herangehensweise (inkl. der Ergebnisse einer vorab durchgeführten Literaturrecherche). Auch wenn die Erstellung eines solchen Schriftstücks einen hohen Aufwand mit sich bringt, ist dieser doch nicht verloren: Das Exposé kann eins zu eins als das erste Kapitel der Thesis wiederverwendet werden. Darüber hinaus ist mit ihm ein Leitfaden entstanden, welcher alle weiteren Bearbeitungsschritte vorgibt.

Informatiker werden feststellen, dass sich eine wissenschaftliche Vorgehensweise nicht allzu sehr von den Phasen des Software Development Life Cycle (SDLC) unterscheidet. Zumindest lassen sich die meisten Thesen – analog zum SDLC – zur folgenden Struktur abstrahieren:

  1. Einführung („Planning“)
  2. Related Work („Analysis“)
  3. Konzeption („Design“)
  4. Umsetzung („Implementierung“)
  5. Evaluation („Test“)
  6. Fazit und Ausblick („Maintenance“)

Selbstverständlich können für die eigene Thesis andere Kapitelüberschriften gewählt werden. Im Folgenden werden (persönliche) Tipps und Tricks zum wissenschaftlichen Schreiben aufgezeigt:

  • Grundsätzlich muss jede Aussage bzw. jede These belegt werden, da sie sonst eine Behauptung darstellt. Wörter wie „beispielsweise“ stellen Auswege dar, um eine Entscheidung aus mehreren Möglichkeiten unkommentiert zu lassen. Hierbei sollte aber beachtet werden, dass die Verwendung solcher Wörter die Qualität einer wissenschaftlichen Arbeit nicht fördert.
  • Die Auswahl von Kriterien sowie deren Gewichtung erfordern ebenfalls eine Begründung – außer die Kriterien wurden vorgegeben, z. B. von einer Partnerfirma. (Dieses „Schlupfloch“ sollte vermieden werden.)
  • Es sollten erst alle Stichpunkte zu jedem Kapitel niedergeschrieben werden, bevor man anfängt, Texte auszuformulieren. Mit hoher Wahrscheinlichkeit wird man in dieser Phase die Gliederung der Arbeit mehrmals anpassen müssen, um den nötigen „roten Faden“ zu gewinnen und zu bewahren. Generell wird die initiale Gliederung einer Thesis nicht in Stein gemeißelt sein.
  • Jedes Kapitel sollte eigenständig gelesen werden können, weshalb immer ein Einführungstext vorangestellt werden sollte.

Abschließend sollte die finale Version einer wissenschaftlichen Ausarbeitung einmal wie folgt begutachtet werden: Zuerst sollte die Einführung gelesen werden, danach das Fazit und zuletzt eine zufällige Seite. Falls sich zwischen den genannten Kapiteln kein Zusammenhang erkennen lässt, sollte dieser nachträglich eingearbeitet werden. Zudem sollte der Kern einer wissenschaftlichen Thematik auch von fachfremden Lesern nachvollzogen werden können, weshalb es empfehlenswert ist, die Arbeit von unterschiedlichen Personen Korrektur lesen zu lassen.

26 09, 2018

Hacking vs. Penetration Testing – die Geburtsstunde des BACPP

von |26. September 2018|binsec|0 Kommentare|

Als Dozent für „Penetration Testing“ kenne ich den ausschlaggebenden Beweggrund meiner Studentinnen und Studenten für ihre Teilnahme am Wahlpflichtfach nur zu gut. Die Rede ist von „Hacking“. Bereits in jungen Jahren für viele ein spannendes Thema – brennt sich das Hacken von IT-Systemen doch durch seine Darstellung in Film und Fernsehen schon früh als aufregend in die Köpfe der Zuschauer ein. Es ist somit kein Wunder, dass ein beruflicher Weg hin zum Penetrationstester mehr als verlockend klingt. Was viele dabei nicht wissen: Hacking stellt „nur“ den technischen Part eines Pentests dar, weshalb sich auch die Suche nach einer geeigneten Personenzertifizierung als schwierig gestaltet(e).

Im Allgemeinen versuchen Hacker Sicherungsmechanismen zu umgehen oder zu brechen, um einen unbefugten Datenzugriff zu erhalten. Das Aufgabengebiet Penetration-Testing entstand deshalb mehr oder weniger als eine Art Gegenmaßnahme seitens der IT-Sicherheit im Wettrüsten mit den Angreifern: Potenzielle Auftraggeber bitten bzw. beauftragen Pentester mit der Identifizierung der Schwachstellen ihrer IT-Systeme, um diese am Ende härten bzw. schließen zu können.

Hierbei wendet ein Pentester konsequenterweise dieselben technischen Verfahren an wie ein böswilliger Angreifer. Aber nicht nur das. Zusätzlich wird eine strukturierte Vorgehensweise benötigt, um reproduzierbare Ergebnisse zu erzielen. Ohne eine solche Vorgehensweise können (offensichtliche) Schwachstellen unentdeckt bleiben. Im Gegensatz zu einem Hacker genügt dem Pentester nicht ein einziger Einstiegspunkt in das IT-System, sondern er will alle aufdecken. Ebenso müssen die identifizierten Schwachstellen dem Auftraggeber mitgeteilt werden. Dies geschieht üblicherweise in einem abschließenden Bericht oder in einer Präsentation, wobei die Schwachstellen nicht nur aufzulisten, sondern auch nach ihrem Risiko zu priorisieren sind. Folglich stellt Hacking „nur“ den technischen Part in einem Pentest dar.

Bis dato existiert weder eine staatlich anerkannte Ausbildung noch ein solcher Studiengang zum Penetration-Testing, weshalb es im Informationssicherheitssektor üblich ist, solche speziellen Fähigkeiten und Fertigkeiten über Zertifizierungsprogramme zu erlangen und/oder nachzuweisen. Im Hinblick auf Penetration Testing sind insbesondere die Zertifikate CEH von EC-Council und OSCP von Offensive Security weit verbreitet – unterscheiden sich in der Prüfung der Teilnehmenden jedoch wie Schwarz und Weiß. Während die Zertifizierung als CEH mittels einer theoretischen Prüfung – konkret Multiple-Choice-Aufgaben – erlangt werden kann, muss der zukünftige OSCPler eine 24-stündige praktische Prüfung, in welcher 5 IT-Systeme vollständig kompromittiert werden sollen, absolvieren. Unabhängig davon sehe ich bei beiden Zertifizierungen den Fokus auf dem technischen Verständnis, welches zwar das Fundament eines Penetrationstests darstellt, aber noch zu keinem befähigt; für mich ein Kritikpunkt, ohne den Schwierigkeitsgrad beider Prüfungen infrage stellen zu wollen.

Zumindest mir fiel der Übergang von der OSCP-Prüfungsumgebung in die Realität schwer. Am spürbarsten war dies in Bezug auf die Anfälligkeit von IT-Systemen für Sicherheitslücken. Im Vergleich zum Übungslabor von Offensive Security sind in der Praxis oftmals (härtere) Sicherheitsmaßnahmen anzutreffen, wodurch die vollständige Kompromittierung eines IT-Systems nicht immer gewährleistet werden kann. Zudem wünscht sich der Auftraggeber eines Pentests im Regelfall die Identifikation sämtlicher Schwachstellen in seinen IT-Systemen, weshalb die Prüfung nicht mit dem Aufdecken des erstbesten Einfallstors endet. Auch die Berichterstellung steht in einem ganz anderen Licht, da dies das einzige Dokument ist, welches der Auftraggeber in seinen Händen halten wird. Kurzum: Das Spielparadies des OSCP nahm ein Ende und die Realität brach ein. Leider kam dies unerwartet, da keine der zahlreichen zurate gezogenen Rezensionen im Internet die Unterschiede zum realen Tätigkeitsfeld eines Penetrationstesters erwähnt hatte.

Nachdem ich mit meinem B.Sc. in Informatik an der Hochschule Darmstadt (h_da) und mit meiner als Pentester der binsec GmbH gesammelten Berufserfahrung die formelle Eignung erworben hatte, eine Lehrveranstaltung zu halten, wollte ich mein Wissen rund um Penetration Testing weitergeben. Personen mit einem Hang zur IT-Sicherheit sollten künftig einen „leichteren“ Einstieg in die Materie erhalten als ich zu meiner Zeit. Unter Zustimmung der Fachgruppe „IT-Sicherheit“ an der h_da konzipierte ich das Wahlpflichtmodul „Penetration Testing“, in welchem die Studierenden das „Pentest-Einmaleins“ – von der Klassifikation eines Pentests, über das eigentliche Hacking, bis hin zur Berichterstellung – am Beispiel eines fiktiven Firmennetzwerks erlernen und anwenden können. Dies geschah anfänglich noch mithilfe von Amazon AWS; doch aufgrund der großen Nachfrage und positiven Resonanz meiner Studierenden entschlossen wir als binsec uns dazu, ein globales Online-Zertifizierungsprogramm zu entwerfen: die Qualifizierung zum BACPP (Binsec Academy Certified Pentest Professional), die sich aus einer Online-Prüfung, dem „Pentest Exam“, und einer optionalen Online-Schulung, dem „Pentest Training“, zusammensetzt.

Während sich die Online-Schulung historisch aus meiner Hochschullehrveranstaltung heraus entwickelt hat, können IT-Spezialisten im „Pentest Exam“ ihre Expertise unter neu konzipierten, realen Bedingungen unter Beweis stellen. So können zertifizierte BACPPler

  • IT-Systeme kompromittieren und Zero-Day-Exploits entwickeln,
  • Netzwerke und Anwendungen nach einer reproduzierbaren Vorgehensweise auf Schwachstellen hin untersuchen,
  • all ihre Findings in einem strukturierten Bericht für den Auftraggeber niederlegen und sie nach ihrem Risiko priorisieren,
  • einen mehrtägigen Penetrationstest professionell durchführen.

Rückblickend scheint sich meine (zeitintensive) interdisziplinäre Arbeit gelohnt zu haben: Das situierte Lernen in der Informationssicherheit einzusetzen hat nicht nur die Begeisterung vieler Studierender geweckt, sondern auch die ersten BACPP-Zertifizierten angesprochen. Die Theorie des situierten Lernens setzt in der Wissensvermittlung auf realistische Anwendungssituationen, welche das primäre Kennzeichen meiner Lehrveranstaltungen und meiner Trainings sind. Analog wurde der BACPP konzipiert und setzt auf den Nachweis praktischer und realer Erfahrung.