Skip to content
// BLOG

Was ist Penetration Testing? Ein ehrlicher Überblick

Penetration Testing klingt kompliziert, ist aber im Kern ganz einfach: Jemand versucht, in Ihr System einzubrechen – aber mit Ihrer Erlaubnis. Hier erkläre ich, wie das abläuft und wann es sinnvoll ist.

Was ist Penetration Testing?

Im Grunde bezahlen Sie jemanden, der versucht, in Ihr System einzubrechen. Klingt verrückt, ist aber die effektivste Methode, um herauszufinden, wo Ihre IT-Sicherheit wirklich steht. Nicht auf dem Papier. Nicht in der Theorie. Sondern in der Praxis.

Ein Penetration Test – kurz Pentest – simuliert einen echten Angriff auf Ihre Systeme, Netzwerke oder Anwendungen. Der Unterschied zu einem echten Angriff: Sie haben dem zugestimmt, es gibt klare Regeln, und am Ende bekommen Sie einen Bericht statt eines Erpresserschreibens.

Aus meiner Erfahrung ist das Konzept für viele erstmal schwer zu greifen. Warum sollte man jemanden dafür bezahlen, Schwachstellen auszunutzen? Die Antwort ist simpel: Weil es jemand anderes sonst kostenlos macht – nur ohne Ihr Einverständnis. Und ohne Bericht.

Warum braucht man das überhaupt?

Automatische Scanner finden nicht alles

Ja, es gibt Vulnerability Scanner. Die sind auch nützlich. Aber sie arbeiten nach Checklisten. Sie prüfen bekannte Schwachstellen ab und spucken eine Liste aus. Was sie nicht können: kreativ denken. Ein Scanner findet eine veraltete Software-Version. Ein Pentester findet heraus, dass die Kombination aus drei eigentlich harmlosen Konfigurationen zusammen eine kritische Lücke ergibt.

Was ich oft sehe: Unternehmen lassen einen Vulnerability Scan laufen, beheben die Findings, und denken sie sind sicher. Dann kommt der Pentest und findet Dinge, die kein Scanner jemals gefunden hätte. Logikfehler in der Anwendung. Fehlkonfigurierte Berechtigungen. Social Engineering Vektoren. Dinge, die ein automatisiertes Tool schlicht nicht testen kann.

Compliance-Anforderungen

Manche Unternehmen müssen Pentests durchführen. Nicht weil sie wollen, sondern weil es Vorschriften verlangen. ISO 27001 empfiehlt regelmäßige Sicherheitsüberprüfungen. PCI-DSS schreibt Pentests explizit vor, wenn Sie Kreditkartendaten verarbeiten. Und die DSGVO verlangt, dass Sie die Sicherheit Ihrer Systeme nachweisen können – ein Pentest-Bericht ist da ein ziemlich gutes Argument.

Aber ehrlich gesagt: Compliance als einzigen Grund für einen Pentest zu nehmen, ist zu kurz gedacht. Der eigentliche Wert liegt woanders.

Reale Bedrohungen testen statt theoretische

Sicherheitskonzepte auf Papier sind schön und gut. Aber ob die Firewall-Regeln wirklich halten, ob die Segmentierung funktioniert, ob das Monitoring einen Angriff erkennt – das wissen Sie erst, wenn es jemand ausprobiert. Ein Pentest ist der Praxistest für Ihre Sicherheitsmaßnahmen.

Die verschiedenen Arten von Penetration Tests

Nicht jeder Pentest ist gleich. Je nachdem, wie viel Vorwissen der Tester bekommt, unterscheidet man drei Ansätze.

Black Box Testing

Der Tester bekommt fast nichts. Vielleicht einen Firmennamen oder eine Domain. Das wars. Er muss sich alles selbst erarbeiten – genau wie ein echter Angreifer. Das klingt erstmal nach dem realistischsten Szenario, hat aber einen Nachteil: Der Tester verbringt viel Zeit mit Reconnaissance, die ein echter Angreifer über Wochen oder Monate betreiben würde. Bei einem zeitlich begrenzten Pentest geht diese Zeit von der eigentlichen Testzeit ab.

Wann sinnvoll: Wenn Sie wissen wollen, wie angreifbar Sie von außen sind. Gut für einen ersten Überblick oder wenn Sie Ihr externes Sicherheitsniveau einschätzen wollen.

White Box Testing

Das andere Extrem. Der Tester bekommt alles: Quellcode, Netzwerkdiagramme, Dokumentation, Zugangsdaten. Damit kann er viel gezielter arbeiten und in der gleichen Zeit deutlich mehr Schwachstellen finden. Das fühlt sich für manche unrealistisch an – welcher Angreifer hat schon den Quellcode? Aber genau das ist der Punkt: Es geht nicht darum, einen Angreifer zu simulieren. Es geht darum, möglichst viele Schwachstellen zu finden.

Wann sinnvoll: Bei Anwendungen, die Sie selbst entwickelt haben. Oder wenn Sie das Maximum an Findings aus dem Pentest herausholen wollen.

Grey Box Testing

Der Mittelweg. Der Tester bekommt einige Informationen – zum Beispiel Benutzer-Accounts, API-Dokumentation oder eine Übersicht der Netzwerk-Architektur. Das spart Zeit bei der Vorbereitung und ermöglicht trotzdem ein halbwegs realistisches Angriffsszenario.

Wann sinnvoll: In den meisten Fällen ist Grey Box der beste Kompromiss. Sie bekommen realistische Ergebnisse und verschwenden kein Budget für Dinge, die der Tester auch einfach hätte nachfragen können.

Aus meiner Erfahrung: Die meisten Kunden fahren mit einem Grey Box Ansatz am besten. Black Box klingt cool, aber wenn der Tester drei Tage mit OSINT verbringt statt mit dem eigentlichen Test, ist das verschwendetes Budget.

Wie läuft ein Pentest ab?

Ein Pentest folgt einem klaren Ablauf. Das ist kein wildes Drauflos-Hacken, sondern ein strukturierter Prozess. Hier sind die einzelnen Phasen.

1. Scoping und Planung

Bevor irgendjemand auch nur einen Port scannt, wird erstmal geredet. Was genau soll getestet werden? Welche Systeme sind im Scope? Welche sind es explizit nicht? Gibt es Zeitfenster, in denen nicht getestet werden darf? Was passiert, wenn der Tester eine kritische Schwachstelle findet?

Das wird in den sogenannten Rules of Engagement festgehalten. Die sind wichtig. Ohne klare Absprachen kann ein Pentest schnell Probleme verursachen – zum Beispiel wenn ein Test versehentlich ein Produktivsystem lahmlegt.

Und ja, es gibt auch einen rechtlichen Rahmen. Ohne schriftliche Genehmigung ist ein Pentest schlicht illegal. Egal wie gut die Absicht ist.

2. Reconnaissance – Informationssammlung

Jetzt geht es los. Der Tester sammelt Informationen über das Ziel. Bei einem Black Box Test passiert das von außen: DNS-Einträge, öffentlich erreichbare Dienste, Mitarbeiter auf LinkedIn, Technologien auf der Website. Bei einem White Box Test werden die vorhandenen Unterlagen studiert.

Diese Phase wird oft unterschätzt. Aber ein guter Pentester verbringt hier bewusst Zeit. Je besser die Informationsbasis, desto gezielter die späteren Angriffe.

3. Scanning und Enumeration

Hier wird technischer. Mit Tools wie nmap werden offene Ports und Dienste identifiziert. Webanwendungen werden mit Scannern wie Burp Suite oder Nikto untersucht. Das Ziel: Ein möglichst vollständiges Bild der Angriffsfläche.

Wichtig zu verstehen: Das ist noch kein Angriff. Das ist Aufklärung. Wie ein Einbrecher, der sich erstmal das Haus von außen anschaut, bevor er einsteigt.

4. Exploitation – Das eigentliche Ausnutzen

Jetzt wird es spannend. Der Tester versucht, die gefundenen Schwachstellen tatsächlich auszunutzen. Nicht theoretisch, nicht als Bullet Point in einem Report – sondern real. Kann ich mich ohne gültige Credentials einloggen? Kann ich SQL-Injection nutzen, um an die Datenbank zu kommen? Kann ich über einen veralteten Dienst Code auf dem Server ausführen?

Das ist der entscheidende Unterschied zum Vulnerability Scan. Ein Scanner sagt: "Diese Version hat eine bekannte Schwachstelle." Ein Pentester sagt: "Ich habe diese Schwachstelle ausgenutzt und konnte damit X, Y und Z machen."

5. Post-Exploitation – Wie weit kommt man?

Okay, der Tester ist drin. Und jetzt? Jetzt geht es darum herauszufinden, welchen Schaden ein echter Angreifer anrichten könnte. Kann er sich lateral im Netzwerk bewegen? Kommt er an sensible Daten? Kann er seine Rechte erweitern? Kann er Spuren verwischen?

Diese Phase zeigt den tatsächlichen Geschäftsimpact. Eine SQL-Injection ist abstrakt. "Über die SQL-Injection konnte ich alle Kundendaten exportieren, inklusive Passwörter im Klartext" – das versteht auch das Management.

6. Reporting – Das wichtigste Ergebnis

Der Bericht ist das, wofür Sie eigentlich bezahlen. Nicht für das Hacken selbst. Was bringt es, wenn der Tester 20 Schwachstellen findet, aber niemand versteht, was damit anzufangen ist? Ein guter Bericht macht den Unterschied zwischen einem Pentest, der etwas verändert, und einem, der in der Schublade verschwindet.

Was ein guter Pentest-Bericht beinhaltet

Was ich oft sehe: Berichte, die entweder zu technisch für das Management oder zu oberflächlich für das IT-Team sind. Ein guter Bericht bedient beide Zielgruppen.

Executive Summary

Eine Zusammenfassung auf ein bis zwei Seiten. Keine technischen Details, sondern Geschäftsrisiken. "Ein Angreifer könnte mit mittlerem Aufwand Zugriff auf Kundendaten erlangen" – das versteht ein Geschäftsführer. CVE-2024-12345 eher nicht.

Technische Details

Für jedes Finding: Was wurde gefunden? Wie wurde es ausgenutzt? Welche Beweise gibt es (Screenshots, Logs, Payloads)? Das IT-Team braucht diese Details, um die Schwachstellen nachvollziehen und beheben zu können.

Risikobewertung

Nicht jede Schwachstelle ist gleich kritisch. Ein guter Bericht bewertet jedes Finding nach Schweregrad – zum Beispiel nach dem CVSS-Standard oder einer eigenen Skala. Das hilft bei der Priorisierung: Was muss sofort gefixt werden? Was kann warten?

Konkrete Empfehlungen

"Schwachstelle beheben" ist keine hilfreiche Empfehlung. Gute Berichte liefern konkrete Schritte:

  • Welche Konfiguration muss geändert werden?
  • Welches Update behebt das Problem?
  • Welche Alternative gibt es, falls ein Update nicht möglich ist?
  • Wie kann man verifizieren, dass die Behebung erfolgreich war?

Häufige Missverständnisse

"Ein Pentest macht uns sicher"

Nein. Ein Pentest zeigt Ihnen, wo Sie gerade Probleme haben. Mehr nicht. Er ist eine Momentaufnahme. Ob Sie die Findings dann auch beheben, ist eine andere Frage. Und selbst wenn Sie alles beheben – morgen kann eine neue Schwachstelle auftauchen, die beim Test noch nicht existierte.

Ein Pentest ist kein Gütesiegel. Er ist ein Werkzeug zur Verbesserung. Und genau so sollte man ihn behandeln.

"Wir wurden letztes Jahr getestet, reicht das?"

Kurze Antwort: Nein. Ihre Systeme ändern sich. Neue Features werden deployed. Server werden umkonfiguriert. Mitarbeiter kommen und gehen. Ein Pentest von vor zwölf Monaten sagt Ihnen wenig über Ihre aktuelle Sicherheitslage.

Wie oft man testen sollte, hängt davon ab, wie stark sich die Umgebung verändert. Bei einer Webanwendung, die alle zwei Wochen neue Features bekommt, ist ein jährlicher Pentest zu wenig. Bei einer stabilen Infrastruktur, die sich kaum ändert, kann einmal im Jahr reichen.

"Vulnerability Scan = Pentest"

Das ist definitiv nicht das Gleiche. Und das ist ein Missverständnis, das ich wirklich oft sehe.

Ein Vulnerability Scan ist automatisiert. Ein Tool prüft bekannte Schwachstellen ab und erstellt einen Report. Das dauert Stunden, nicht Tage. Es ist günstig und sollte regelmäßig laufen. Aber es findet nur das, was in der Datenbank steht.

Ein Pentest ist manuell. Ein Mensch denkt kreativ, kombiniert Schwachstellen, findet Logikfehler und testet Angriffsketten, die kein automatisiertes Tool erkennen würde. Das dauert Tage bis Wochen und ist entsprechend teurer.

Beides hat seinen Platz. Vulnerability Scans sind gut für die regelmäßige Basis-Hygiene. Pentests sind für die Tiefe. Eins ersetzt nicht das andere.

Wann ist ein Pentest sinnvoll? Und wann vielleicht nicht?

Ein Pentest ist sinnvoll, wenn:

  • Sie eine neue Anwendung oder ein System vor dem Go-Live testen wollen
  • Sie Compliance-Anforderungen erfüllen müssen
  • Sie wissen wollen, wie Ihre Sicherheitsmaßnahmen einem echten Angriff standhalten
  • Sie größere Änderungen an der Infrastruktur oder Anwendung vorgenommen haben
  • Sie einen Vorfall hatten und sicherstellen wollen, dass die Lücke wirklich geschlossen ist

Ein Pentest ist vielleicht nicht der richtige nächste Schritt, wenn:

  • Sie noch nicht einmal grundlegende Sicherheitsmaßnahmen haben – keine Firewall, kein Patch-Management, keine Zugriffskontrollen. Dann wissen Sie auch ohne Pentest, dass es Probleme gibt. Investieren Sie das Budget lieber erstmal in die Basics.
  • Sie die Findings des letzten Pentests noch nicht behoben haben. Warum nochmal testen, wenn die bekannten Probleme noch offen sind?
  • Sie keinen Plan haben, was Sie mit den Ergebnissen machen sollen. Ein Pentest-Bericht bringt nichts, wenn niemand die Empfehlungen umsetzt.

Und genau das ist der Punkt: Ein Pentest ist kein Selbstzweck. Er bringt nur etwas, wenn Sie bereit sind, mit den Ergebnissen zu arbeiten. Sonst ist es rausgeschmissenes Geld.

Fazit

Penetration Testing ist kein Hexenwerk. Es ist ein strukturierter Prozess, bei dem jemand versucht, Ihre Sicherheitsmaßnahmen zu umgehen – mit Ihrer Erlaubnis und einem klaren Ziel. Die Ergebnisse zeigen Ihnen, wo Sie stehen. Nicht wo Sie gerne stehen würden.

Es ist keine Garantie für Sicherheit. Es ist kein einmaliges Projekt, das man abhakt. Und es ist kein Ersatz für grundlegende Security-Hygiene. Aber es ist eines der effektivsten Mittel, um echte Schwachstellen zu finden, bevor es jemand anderes tut.

Wenn Sie überlegen, ob ein Pentest für Ihr Unternehmen sinnvoll wäre, oder Fragen zum Ablauf haben – melden Sie sich einfach. Ich erkläre Ihnen gern, welcher Ansatz für Ihre Situation am meisten Sinn ergibt.

Weiterführende Artikel