Ein Pentest ist eine Momentaufnahme — was er in diesem Moment wirklich zeigt

/01Begriff und Abgrenzung: Was ein Penetrationstest ist — und was er nicht ist

Der BSI-Leitfaden für IS-Penetrationstests definiert die Sache nüchtern: ein erprobtes Vorgehen, um das Angriffspotenzial auf ein IT-Netz, ein einzelnes System oder eine Webanwendung festzustellen — die Erfolgsaussichten eines vorsätzlichen Angriffs werden eingeschätzt, und daraus werden notwendige Maßnahmen abgeleitet oder die Wirksamkeit bestehender Maßnahmen überprüft. Typische Ansatzpunkte sind Netzkoppelelemente, Sicherheitsgateways, Server, Webanwendungen, Clients und drahtlose Netze. Ein Penetrationstest ist damit etwas anderes als ein automatisierter Schwachstellenscan, der nur Versionen und Patchstände abfragt, und etwas anderes als eine IS-Revision, die prüft, ob vereinbarte Maßnahmen wie vereinbart umgesetzt sind. Ein Pentest geht einen Schritt weiter: Er sucht aktiv nach Wegen, die Maßnahmen zu umgehen.

Genauso wichtig ist, was ein Pentest nicht ersetzt. Der BSI-Leitfaden stellt klar, dass ein IS-Penetrationstest keine Qualitätssicherung von neuen oder geänderten IT-Anwendungen ersetzt — die gehört in den Lebenszyklus der Software selbst, nicht in einen einmaligen externen Test. Und die Prüfer müssen unabhängig bleiben: Ein Pentest, der von den hauseigenen IT-Fachkräften durchgeführt wird, verliert genau die unbeteiligte Perspektive, die einen Angreifer von einem Administrator unterscheidet. Für diesen Artikel wurde der BSI-Leitfaden im Volltext geprüft, ebenso die Produktseite der HostSpezial-Pentest-Plattform — alle Zahlen sind entsprechend gekennzeichnet. Wer einen Pentest im Rahmen von Managed Services einkauft, sollte dieselbe Abgrenzung von seinem Dienstleister verlangen: ein Pentest ist ein Baustein der Sicherheitsarbeit, kein Ersatz für den laufenden Betrieb.

/02Blackbox, Whitebox, Greybox: drei Informationsstände, drei Ergebnisse

Der BSI-Leitfaden unterscheidet grundsätzlich zwei Varianten. Bei einem Blackbox-Test stehen den Prüfern lediglich die Adressinformationen des Zieles zur Verfügung — simuliert wird der Angriff eines typischen Außentäters mit unvollständigen Kenntnissen. Bei einem Whitebox-Test verfügen die Prüfer vorab über umfangreiche Informationen: IP-Adressen des internen Netzes, eingesetzte Soft- und Hardware, Netzpläne. Das BSI empfiehlt grundsätzlich die Whitebox-Variante — nicht, weil sie realistischer wäre, sondern weil bei einem Blackbox-Test aufgrund fehlender Informationen Schwachstellen übersehen werden können, weil das Szenario eines informierten Innentäters unberücksichtigt bleibt und weil der Aufwand wesentlich größer ist als bei einem Whitebox-Test.

In der kommerziellen Praxis hat sich dazwischen eine dritte Stufe etabliert, die der BSI-Leitfaden selbst nicht kennt: Greybox. Die OWASP Mobile Application Security Testing Guide beschreibt sie als Testform, bei der dem Prüfer ein Teil der Informationen vorab gegeben wird — meist ein einfaches Nutzerkonto — während der Rest entdeckt werden muss; nach eigener Einordnung ist das „die in der Sicherheitsbranche verbreitetste Testform", weil sie einen Kompromiss zwischen Testfällen, Kosten, Geschwindigkeit und Prüfumfang darstellt. Für eine Webanwendung heißt Greybox praktisch: Der Tester bekommt einen normalen Benutzerzugang und prüft von dort aus, wie weit er über die eigentlich vorgesehenen Rechte hinauskommt — ein Szenario, das dem häufigsten realen Angriffsweg näherkommt als ein reiner Blackbox-Test ohne jeden Zugang.

Welche Variante die richtige ist, hängt von der Frage ab, die beantwortet werden soll. Wer wissen will, ob ein Angreifer von außen überhaupt eine Angriffsfläche findet, braucht Blackbox. Wer wissen will, ob die vorhandenen Maßnahmen tatsächlich wirken, bekommt mit Whitebox in derselben Zeit mehr geprüfte Tiefe. Für die meisten Mittelständler, die zum ersten Mal einen Pentest beauftragen, ist Greybox der pragmatische Mittelweg: realistisch genug, um den häufigsten Angriffsweg — ein kompromittiertes Konto — abzubilden, und zielgerichtet genug, um das Budget nicht in der Suche nach dem Eingangstor zu verbrauchen.

/03Scope: Was vor dem ersten Befehl feststehen muss

Der BSI-Leitfaden widmet der Festlegung des Prüfumfangs einen eigenen Abschnitt, aus gutem Grund: Ein Pentest ohne klaren Scope ist entweder gefährlich oder wertlos. Üblicherweise wird nach einer Erstinbetriebnahme eines Systems oder nach wesentlichen Änderungen ein Pentest angestrebt — dann lässt sich das Prüfobjekt leicht eingrenzen. Schwieriger wird es bei einem präventiven Test: Eine Institution möchte jede Angriffsmöglichkeit identifizieren, aber das ist zeitaufwendig und teuer, und selten steht ein Prüfer so lange zur Verfügung. Der BSI-Leitfaden empfiehlt deshalb, zunächst dort zu testen, wo ein Angriff am wahrscheinlichsten ist, und weitere Schnittstellen in Folgeprüfungen abzudecken.

Für einen typischen Mittelstandsbetrieb bedeutet das: VPN-Zugänge und die Firewall zuerst, dann die extern erreichbaren Webanwendungen, dann interne Systeme wie der Verzeichnisdienst. Ob der Fernzugang überhaupt eine zweite Faktor-Prüfung verlangt — MFA ist einer der häufigsten Befunde, wenn sie fehlt —, gehört in jeden Scope, der Fernzugänge einschließt. Zum Scope gehört auch, was ausdrücklich außen vor bleibt — Produktivsysteme, auf denen ein Ausfall den Betrieb stoppen würde, landen oft in einem gesonderten, enger abgesteckten Fenster oder werden nur in einer Staging-Kopie geprüft. Das BSI empfiehlt dazu grundsätzlich eine moderate Angriffsstärke: Schwachstellen sollen nachgewiesen, aber nur aktiv ausgenutzt werden, wenn es nicht vermeidbar ist und die Exploits vorher ausreichend getestet wurden. Ein destruktiver Test, der ein Produktivsystem zum Absturz bringt, ist kein Erfolg, sondern ein Planungsfehler.

Ein Beispiel verdeutlicht den Unterschied: Ein Betrieb mit rund 60 Mitarbeitern, zwei kundenseitigen Webanwendungen und einem VPN-Zugang für den Außendienst legt den Scope für einen ersten Greybox-Test typischerweise so fest — ein Testkonto für jede Webanwendung, Lesezugriff auf die Netzwerkdokumentation, aber kein Zugriff auf das Produktivsystem der Finanzbuchhaltung, das in einem separaten Fenster mit eigener Freigabe geprüft wird. Das Prüffenster wird meist außerhalb der Kernarbeitszeit gelegt, damit ein unerwarteter Lastanstieg durch aktive Scans kein Tagesgeschäft stört. Diese Festlegung — wer testet was, mit welchem Zugang, in welchem Zeitfenster, mit wem als Eskalationskontakt bei einem unerwarteten Systemausfall — steht schriftlich fest, bevor der erste Befehl läuft.

/04Der Ablauf: von der Einarbeitung zum Abschlussgespräch

Nach BSI-Empfehlung gliedert sich ein Pentest in feste Arbeitspakete. Zuerst die Einarbeitung der Prüfer: Je ausgefallener die eingesetzten Systeme, desto mehr Zeit braucht dieser Schritt, und die Institution muss dafür eine ausführliche Dokumentation bereitstellen. Danach folgt der eigentliche Test des Prüfobjekts, aufgeteilt in Anfangsgespräch, Einrichten der Arbeitsumgebung, praktische Prüfung und Abschlussgespräch. Bei mehrtägigen Tests empfiehlt der Leitfaden ein kurzes Morgengespräch zwischen Prüfern und dem technischen Personal des Auftraggebers, in dem geklärt wird, was für den Tag geplant ist — eine einfache Routine, die verhindert, dass ein Test unkoordiniert an Systemen vorbeiläuft, die der Kunde gerade selbst ändert.

Am Ende steht der Bericht, dem ein eigener Abschnitt gewidmet ist, weil er in der Praxis über den Wert des gesamten Tests entscheidet. Während des gesamten Ablaufs gilt eine Vorgabe, die selten explizit gemacht wird: Die Prüfer müssen zu jedem Zeitpunkt unabhängig vom Prüfobjekt bleiben. Ein Prüfer, der zyklisch kontrolliert, ob die beim letzten Mal gefundenen Lücken geschlossen wurden, verliert diese Unabhängigkeit — solche Nachkontrollen gehören laut BSI-Leitfaden in die interne Qualitätssicherung, nicht in einen erneuten externen Pentest mit denselben Prüfern.

/05Die vier Prüfmodule — von konzeptionellen Schwächen bis Exploits

Der praktische Teil eines Pentests nach BSI-Methodik gliedert sich in vier Module, die aufeinander aufbauen, aber nicht zwingend in dieser Reihenfolge laufen müssen.

• Modul 1 — konzeptionelle Schwächen. Schon beim Sichten der Unterlagen fallen den Prüfern oft strukturelle Probleme auf: unabhängige Fachanwendungen, die auf demselben System gehostet laufen, ohne dass jemand den gemeinsamen Schutzbedarf bewertet hat.
• Modul 2 — Umsetzung von Härtungsmaßnahmen. Offene Ports, unerwartete Schnittstellen, veraltete Patchstände, Zugangsvoraussetzungen und Authentisierung, Absicherung der Dienste und Regelwerke — hier wird geprüft, ob Grundschutzmaßnahmen und Härtungsstandards tatsächlich greifen, nicht nur auf dem Papier stehen.
• Modul 3 — bekannte Schwachstellen. Mit Schwachstellenscannern werden Versionen und Patchstände abgefragt; nicht-invasive Scanner lesen dafür nur Banner aus, was ein versierter Administrator fälschen kann, invasive Scanner probieren zusätzlich aus, ob eine bekannte Schwachstelle tatsächlich ausnutzbar ist.
• Modul 4 — Exploits, optional. Der exakte Nachweis einer Schwachstelle gelingt nur, wenn sie ausgenutzt wird — mit dem Risiko, dass ein unsicher programmierter Exploit selbst Schaden anrichtet. Der BSI-Leitfaden verlangt deshalb, Exploits nur einzusetzen, wenn es nicht vermeidbar ist.

Was in diesem Ablauf bewusst fehlt: Social Engineering. Der BSI-Leitfaden stellt ausdrücklich klar, dass der eigene IS-Penetrationstest keinerlei Elemente des Social Engineering enthält, obwohl reale Angriffe höchstwahrscheinlich genau darüber laufen oder solche Elemente enthalten würden. Begründet wird das mit dem Risiko, einzelne Mitarbeiter bloßzustellen, wenn eine nachgestellte Phishing-Aktion bei ihnen erfolgreich war — solche Tests sollten laut Leitfaden nur unter genau definierten Bedingungen mit Personalvertretung und trainierten Spezialisten laufen. Wer einen Pentest bestellt und erwartet, dass damit auch die Klickrate der eigenen Belegschaft getestet wird, bestellt das falsche Produkt — dafür gibt es eigene Formate.

/06Der Bericht: Managementzusammenfassung, Kritikalität, Empfehlung

Der Bericht ist das letzte Arbeitspaket und zugleich das, an dem sich entscheidet, ob ein Pentest etwas bewirkt oder nur eine Akte im Ordner füllt. Der BSI-Leitfaden empfiehlt einen festen Aufbau: zuerst die Beschreibung des Prüfobjekts und der Prüfbedingungen, danach eine Managementzusammenfassung mit den Kernaussagen, die ohne technisches Vorwissen lesbar ist, und erst danach die technischen Einzelbefunde mit genauen Beschreibungen und Empfehlungen — wobei ein neutraler Prüfer Produktempfehlungen vermeiden und sich auf Produktklassen beschränken sollte.

Für die Bewertung der gefundenen Schwachstellen nennt der Leitfaden verbreitete Industriestandards wie CVSSv2 oder DREAD. Das BSI selbst stuft Befunde nach Schadenspotenzial und notwendiger Reaktion ein: Bei hohem Schadenspotenzial — etwa wenn Fremdsteuerung des Prüfobjekts oder Verlust sensibler Daten möglich ist — ist sofortige Reaktion gefordert, bei mittlerem Schadenspotenzial eine kurzfristige. Diese Einstufung ist der eigentliche Wert des Berichts: Sie erlaubt es, die gefundenen Lücken in eine Reihenfolge zu bringen, statt alles gleichzeitig und damit nichts richtig anzugehen. Ein Patch-Management-Prozess, der die Kritikalitätsstufen des Berichts direkt übernimmt, schließt die wichtigsten Lücken zuerst — ohne diese Priorisierung bleibt ein Pentest-Bericht eine lange Liste, keine Entscheidungsgrundlage. Ein einzelner Befund folgt in der Praxis einem festen Muster, das sich direkt aus der BSI-Einstufung ableitet:

# Struktur eines Einzelbefunds im Pentest-Bericht (Format, keine echte Kundenumgebung)
Befund:          Veraltete TLS-Konfiguration auf externem Mailrelay
Schadenspotenzial: mittel  (BSI-Kategorie: kurzfristige Reaktion erforderlich)
Nachweis:        Protokoll-Handshake, Screenshot, Zeitstempel
Betroffenes System: mail01.beispiel.tld, Port 25/587
Empfehlung:      Produktklasse "aktueller TLS-Stack", keine Herstellernennung
Frist:           kurzfristig, vor dem nächsten Wartungsfenster

Für Betriebe mit ISO-27001-Zertifizierung oder vertraglichen Nachweispflichten gegenüber Kunden ist dieser Bericht zugleich das Dokument, das im Audit vorgelegt wird — eine Managementzusammenfassung ohne abgearbeitete Technikkapitel überzeugt dort niemanden.

/07Der Unterschied zum laufenden automatisierten Prüfstand

Ein klassischer Pentest nach BSI-Methodik ist eine Momentaufnahme, und genau das beschreibt die Produktseite der HostSpezial-Pentest-Plattform in einem Satz, der die eigene Kategorie einordnet: „Der klassische Pentest ist eine Momentaufnahme. Zwischen zwei Tests vergehen zwölf Monate" — nach eigener Rechnung bleiben damit rund 51 Wochen, in denen niemand erneut von außen hinsieht, während Deployments, neue Schwachstellen und Konfigurationsänderungen weiterlaufen. Genau diese Lücke soll ein kontinuierlicher, automatisierter Prüfstand schließen: Die Plattform orchestriert die Open-Source-Werkzeuge OpenVAS, OWASP ZAP, SQLMap und Metasploit über ein KI-Dirigat, das in drei Stufen verfügbar ist — ab 1.500 Euro im Monat für bis zu 50 Systeme mit monatlichem Scan, ab 5.000 Euro für bis zu 500 Systeme mit wöchentlicher Prüfung plus Attack-Chain-Replay, ab 15.000 Euro für unbegrenzte Systeme mit kontinuierlicher Prüfung und SOC-Integration.

Wichtig ist, was die Plattform selbst nicht beansprucht zu sein: ein Ersatz für den menschlichen Pentest. Die eigene FAQ beantwortet die Frage direkt: „Ersetzt das einen externen Pentest? Nein, und wir behaupten es auch nicht. Kreative Angriffswege und Social Engineering bleiben Sache eines menschlichen Pentesters." Ein automatisierter Prüfstand arbeitet Signaturen, bekannte Angriffsketten und Konfigurationsfehler ab — zuverlässig, häufig und zu einem Bruchteil der Kosten eines externen Tages-Honorars, aber ohne die Kreativität, mit der ein erfahrener Mensch eine Lücke findet, die kein Werkzeug vorgesehen hat. Beide Formen schließen sich nicht aus, sie decken unterschiedliche Zeiträume ab: der Pentest die Tiefe an einem Stichtag, der Prüfstand die Breite in der Zeit dazwischen.

/08Sinnvolle Frequenz: Wie oft ist genug?

Der BSI-Leitfaden gibt dazu eine klare, wenn auch mit Vorsicht zu lesende Empfehlung: Wiederholungsprüfungen sollten alle zwei bis drei Jahre erfolgen, weil regelmäßig neue Schwachstellen und Angriffsmethoden bekannt werden. Das ist eine Untergrenze für die formale, tiefe Prüfung — kein Freibrief, zwei Jahre lang nichts zu tun. Dieselbe Quelle nennt zwei Anlässe, zu denen ein Pentest unabhängig vom Turnus angestrebt werden sollte: nach der Erstinbetriebnahme eines Systems oder nach wesentlichen Änderungen, und nachdem ein Angriff bereits stattgefunden hat.

Für einen Mittelstandsbetrieb mit mehreren Webanwendungen, regelmäßigen Softwareänderungen und einem wachsenden Netz bedeutet die Zwei-bis-drei-Jahres-Regel in der Praxis: ohne Ergänzung zu selten. Jede neue Anwendung, jedes neue VPN-Gateway, jedes Deployment zwischen zwei Prüfterminen bleibt bis zum nächsten Test ungeprüft. Betriebe mit NIS2-Pflicht oder vergleichbaren Vorgaben erwarten regelmäßige Nachweise ohnehin in kürzeren Abständen als die BSI-Untergrenze. Genau deshalb kombinieren Unternehmen mit höherem Schutzbedarf die formale, tiefe Prüfung im empfohlenen Turnus mit einer kontinuierlichen automatisierten Prüfung dazwischen — die formale Prüfung liefert die Tiefe und die Kritikalitätsbewertung nach BSI-Methodik, der laufende Prüfstand liefert die Abdeckung der Zwischenzeit.

/09Wo es hakt — und wann sich ein Pentest (nicht) lohnt

Drei Trugschlüsse begleiten Pentests im Mittelstand regelmäßig, und sie führen zu Enttäuschung, nicht weil der Test schlecht war, sondern weil die Erwartung falsch war.

„Bestanden" heißt nicht „sicher"

Ein Pentest ohne gefundene kritische Lücken bedeutet, dass die Prüfer in der vereinbarten Zeit und im vereinbarten Scope nichts Kritisches gefunden haben — nicht, dass es nichts zu finden gibt. Zeitlich und vom Umfang her sind die meisten Pentests begrenzt und beziehen sich nur auf die zu erwartenden Hauptangriffsziele; weitere Schwachstellen können trotzdem vorhanden sein.

Ein Bericht, der nicht abgearbeitet wird, ist Geldverbrennung

Der größte Wertverlust entsteht nicht beim Test selbst, sondern danach: ein Bericht mit priorisierten Befunden, der im Ordner verschwindet, weil niemand die Kritikalitätsstufen in einen Maßnahmenplan übersetzt hat.

Ein einzelner Pentest ersetzt kein laufendes Programm

Wer einmal im Jahr oder seltener testet und dazwischen nichts tut, prüft eine Momentaufnahme, die am Tag nach dem Test schon wieder veraltet — jedes neue Deployment, jede neue Schwachstelle in eingesetzter Software zählt ab dem Folgetag nicht mehr zum geprüften Stand.

Dafür spricht ein Pentest: eine unabhängige, kreative Prüfung, die über reine Signaturen hinausgeht, der Nachweis, dass ein Zero-Trust-Versprechen auch unter echtem Druck hält, Pflichtnachweis gegenüber Kunden oder Aufsicht, und der Startpunkt nach einer Erstinbetriebnahme oder einem Vorfall. Dagegen spricht ein isolierter Pentest ohne Ergänzung: wenn die Umgebung sich häufiger ändert als der Prüfzyklus, wenn ein Bericht ohnehin nicht konsequent abgearbeitet wird, oder wenn das eigentliche Problem — etwa ein fehlendes Incident-Response-Verfahren — nicht im Prüfumfang liegt. In der Praxis ist die tragfähigste Kombination für einen Mittelstandsbetrieb: ein externer, unabhängiger Pentest im vom BSI empfohlenen Turnus, dazu ein kontinuierlicher automatisierter Prüfstand für die Zeit dazwischen, und ein Maßnahmenplan, der die Kritikalitätsstufen des letzten Berichts tatsächlich abarbeitet, bevor der nächste Bericht neue liefert.

Für den Beispielbetrieb aus Abschnitt 3 hieße das konkret: der erste Greybox-Test deckt die beiden Webanwendungen und den VPN-Zugang ab, das Finanzsystem folgt in einem zweiten, enger abgesteckten Fenster. Zwischen diesem und dem nächsten formalen Termin in zwei bis drei Jahren läuft ein automatisierter Prüfstand monatlich über dieselben Systeme — nicht, um den Pentest zu wiederholen, sondern um neu bekannt gewordene Schwachstellen in bereits geprüfter Software zu erfassen, bevor sie zwei Jahre lang unbemerkt bleiben.

/10Häufige Fragen