Interview mit René Eck: Was beim Pentest alles schieflaufen kann

Was ein Pentest leistet

IT-Dock Redaktion: René, zur kurzen Einordnung: Was ist ein Penetrationstest, kurz Pentest, und worin unterscheidet er sich von einem automatisierten Schwachstellenscan?

René Eck: Ein Pentest ist ein beauftragter und kontrollierter Angriff auf die eigene IT. Ein Mensch geht mit den Methoden eines Angreifers vor, versucht so weit wie möglich zu kommen und hält fest, wie er das geschafft hat.

Ein Schwachstellenscan läuft automatisch. Er gleicht Versionen und Konfigurationen mit bekannten Schwachstellen ab und liefert eine Liste. Das ist sinnvoll und sollte regelmäßig laufen. Aber der Scanner denkt nicht weiter:

• Er erkennt nicht, dass drei für sich harmlose Befunde zusammen den Weg ins Netz öffnen.
• Er prüft keine Logik. Ein Beispiel: Sehe ich in einem Kundenportal die Daten eines anderen Kunden, wenn ich eine Nummer in der URL ändere?

Das kann ein Unternehmen erwarten: eine ehrliche Aussage, wie weit ein Angreifer in einem festgelegten Rahmen und Zeitraum kommt, und konkrete Ansätze zur Behebung.

Das kann ein Pentest nicht: Er beweist nicht, dass man sicher ist. Er ist eine Momentaufnahme mit begrenztem Umfang und begrenzter Zeit. Er sagt auch nichts darüber, ob die Backups funktionieren oder ob das Unternehmen im Ernstfall richtig reagiert. Dafür gibt es andere Werkzeuge.

Erfahrungen aus der Praxis: Wenn der Pentest anders läuft als geplant

IT-Dock Redaktion: Wenn du an das Thema „Was beim Pentest alles schieflaufen kann“ denkst: Welche Situation fällt dir als Erstes ein?

René Eck: Mir fällt als Erstes etwas ganz Unspektakuläres ein: die IP-Liste.

Ich war auf Kundenseite als externer Informationssicherheitsbeauftragter (ISB) für die Abstimmung mit dem Pentest-Dienstleister zuständig. Die Liste der Zielsysteme kam aus der Firewall-Dokumentation und war schon einige Jahre alt. Nach einem Wechsel des Hosters gehörten zwei Adressen gar nicht mehr dem Kunden. Aufgefallen ist das erst, als die ersten Ergebnisse nicht zum Unternehmen passten. Wir haben den Test angehalten, die Liste bereinigt und dann weitergemacht. Passiert ist nichts. Trotzdem wurden für kurze Zeit Systeme getestet, für die niemand eine Freigabe hatte.

Was man daraus lernen kann: Prüfen Sie vor dem Start, ob jedes Zielsystem wirklich Ihnen gehört und ob Sie es testen lassen dürfen. Das gilt besonders für gehostete Systeme und Cloud-Dienste. Das klingt banal, wird aber oft übersprungen, weil alle schnell anfangen wollen.

IT-Dock Redaktion: Ein Pentest kann technisch sauber ablaufen und dem Unternehmen trotzdem wenig bringen. Wann ist das aus deiner Sicht der Fall?

René Eck: Immer dann, wenn die Aufgabe nicht zum eigentlichen Risiko passt. Oder wenn der Test nur stattfindet, weil eine Versicherung oder ein Kunde ihn verlangt, und danach niemand etwas mit dem Ergebnis macht.

Ein typisches Beispiel ist ein Produktionsbetrieb, der seine Website gründlich testen lässt, weil sie das ist, was man von außen sieht. Auf der Seite lagen aber nur Imagetexte und ein Kontaktformular. Das eigentliche Risiko war der Fernwartungszugang für die Maschinenhersteller: dauerhaft offen, ein gemeinsames Konto, keine Multi-Faktor-Authentifizierung (MFA).

Deshalb frage ich vor jedem Test: Was wäre für Ihr Unternehmen der schlimmste realistische Fall, und über welchen Weg käme ein Angreifer dorthin? Daraus ergibt sich der Testumfang, nicht aus der Liste der Systeme.

Pentest planen: Anbieter, Kosten und Testumfang

IT-Dock Redaktion: Was muss eine IT-Leitung intern klären, bevor sie einen Pentest-Anbieter anfragt?

René Eck: Zuerst den Anlass: eine Kundenanforderung, die Versicherung, NIS2, ein neues System oder ein Vorfall. Davon hängt ab, welcher Test sinnvoll ist.

Danach sollte intern klar sein:

• Welche Systeme und Daten sind wirklich kritisch? Was würde wehtun, wenn es ausfällt oder abfließt?
• Wer entscheidet, und wer ist während des Tests der Ansprechpartner?
• Welche Dienstleister, Hoster oder Cloud-Anbieter sind beteiligt und müssen zustimmen?
• Gibt es Zeiten, in denen nicht getestet werden darf, etwa Monatsabschluss oder Produktionsspitzen?
• Stehen nach dem Test Zeit und Budget für die Behebung bereit?

Als Dienstleister brauche ich neben dem Ziel einige grobe Angaben:

• Anzahl der Systeme bzw. IP-Adressen
• Art der Anwendungen und wie viele Benutzerrollen es gibt
• On-Premises, Cloud oder beides
• ob es frühere Testberichte gibt
• welche Sicht gewünscht ist: von außen, von innen oder als bereits angemeldeter Mitarbeiter

Damit kann ich ein Vorgehen vorschlagen, das zum Risiko passt, statt nur einen Preis pro IP zu nennen.

IT-Dock Redaktion: Welche Fehler passieren bei der Festlegung des Testumfangs besonders häufig?

René Eck: Der häufigste Fehler: Der Umfang wird nach Systemen festgelegt, nicht nach Angriffswegen. Dann wird der Webserver geprüft, die API dahinter aber nicht. Oder das Netzwerk wird getestet, aber Microsoft 365 und die Zugänge des IT-Dienstleisters bleiben außen vor.

Ebenfalls häufig:

• Systeme werden ausgeschlossen, weil sie „gerade umgebaut werden“.
• Alte Testumgebungen und vergessene Subdomains tauchen in keiner Liste auf.

Was hilft:

• Vom Szenario aus denken. Was passiert, wenn ein Angreifer das Passwort eines Mitarbeiters hat? Und was, wenn der IT-Dienstleister selbst kompromittiert ist?
• Vorher die Angriffsfläche von außen ansehen, damit man weiß, was überhaupt sichtbar ist. Das machen wir in der Regel vorab.

IT-Dock Redaktion: Woran erkennen Unternehmen einen guten Pentest-Anbieter?

René Eck: Ein guter Anbieter fragt zuerst nach dem Ziel und erst danach nach der Anzahl der IPs. Er rät auch einmal zu einem kleineren Umfang, wenn der genügt.

Im Auswahlgespräch würde ich fragen:

• Wer testet konkret, und welche Erfahrung haben diese Personen?
• Wie viel davon ist Handarbeit, und wie viel macht ein Werkzeug?
• Kann ich einen anonymisierten Beispielbericht sehen?
• Was passiert, wenn Sie während des Tests etwas Kritisches finden?
• Ist ein Nachtest enthalten?
• Wo werden unsere Daten verarbeitet und gespeichert, und wann werden sie gelöscht?

Skeptisch werde ich bei:

• einem Festpreis ohne jede Rückfrage
• Aussagen wie „wir finden garantiert etwas“
• Berichten, die nach einem Scanner-Export aussehen
• fehlender Auskunft darüber, wer testet oder ob Subunternehmer beteiligt sind

Zertifikate der Tester sind ein gutes Zeichen, ersetzen aber nicht den Blick in einen echten Bericht.

IT-Dock Redaktion: Wie viel kostet ein sinnvoller Pentest?

René Eck: Ehrlich gesagt: Es kommt auf den Umfang an. Als grobe Orientierung im Mittelstand:

• Externer Test einer überschaubaren Infrastruktur oder einer kleineren Webanwendung: etwa 4.000 bis 8.000 Euro
• Kombination aus externem und internem Test: schnell 10.000 bis 25.000 Euro
• Komplexe Anwendungen mit vielen Rollen: entsprechend mehr

Den Aufwand bestimmen vor allem:

• Anzahl und Komplexität der Systeme
• Zahl der Benutzerrollen und Funktionen einer Anwendung
• Wissensstand der Tester: ohne Vorwissen oder mit Zugangsdaten und Dokumentation
• interner oder externer Test
• Tests außerhalb der Geschäftszeiten
• Berichtsumfang und Nachtest

Ob ein günstiges Angebot effizient kalkuliert ist, sehen Sie an den Personentagen. Fragen Sie, wie viele Tage für welchen Teil geplant sind. Eine Webanwendung mit fünf Rollen lässt sich nicht in einem Tag manuell testen. Dann ist es im Kern ein Scan. Ein kleines Angebot ist trotzdem in Ordnung, wenn der Umfang klein und klar abgegrenzt ist.

IT-Dock Redaktion: Wie lange dauert ein Pentest, und welcher Aufwand entsteht zusätzlich beim Auftraggeber?

René Eck: Die eigentliche Testphase dauert je nach Umfang einige Tage bis zwei, drei Wochen. Der Bericht kommt meist ein bis zwei Wochen danach. Mit Angebot, Vertrag und Freigaben sollte man vom ersten Gespräch bis zum fertigen Bericht realistisch vier bis acht Wochen einplanen.

Beim Auftraggeber wird vor allem die Vorbereitung unterschätzt:

• Testkonten, VPN-Zugänge und Freigaben müssen am ersten Tag bereitstehen. Sonst ist der erste Testtag verloren, und das kommt öfter vor, als man denkt.
• Hoster und IT-Dienstleister müssen informiert sein und zugestimmt haben.
• Während des Tests muss jemand erreichbar sein, der Entscheidungen treffen kann.

Bei der Nachbereitung wird die Behebung unterschätzt. Wer zehn Befunde bekommt, braucht dafür Zeit im Team und manchmal Budget. Das sollte man einplanen, bevor der Test beginnt, nicht erst danach.

Während des Pentests: Betriebsrisiken und klare Spielregeln

IT-Dock Redaktion: Kann ein Pentest Systeme lahmlegen oder Geschäftsprozesse stören?

René Eck: Ja, das kann passieren. Ein seriöser Test hält das Risiko klein, aber ganz ausschließen lässt es sich nicht. Die Fälle, die ich kenne, waren selten spektakulär, aber ärgerlich:

• Passworttests gegen das Active Directory haben am Montagmorgen mehrere Benutzerkonten gesperrt, und der Helpdesk hatte zu tun.
• Ein älteres Gerät im Netz, etwa ein Drucker oder eine Steuerung, hat sich beim Scan aufgehängt.
• Ein Test von Webformularen hat einige hundert Anfragen im CRM erzeugt, die jemand wieder aufräumen musste.

Fast alles davon wäre mit Vorbereitung vermeidbar gewesen:

• Die Sperrrichtlinie für Konten vorher kennen und berücksichtigen.
• Empfindliche Systeme benennen und schonend testen oder ausschließen.
• Ein passendes Zeitfenster wählen.
• Vor dem Test eine Datensicherung machen.
• Wo möglich in einer Testumgebung arbeiten.
• Einen Notfallkontakt festlegen, der direkt erreichbar ist.

IT-Dock Redaktion: Welche Spielregeln müssen vor dem ersten Test verbindlich vereinbart sein?

René Eck: Alles schriftlich, nichts per Zuruf. Mindestens:

IT-Dock Redaktion: Wie viel sollte die eigene IT vom Pentest wissen?

René Eck: Im Normalfall wissen die IT-Leitung und ein kleiner Kreis von Leuten Bescheid, die im Zweifel eingreifen müssen. Das ist für die meisten Unternehmen der richtige Weg.

Ein unangekündigter Test ist sinnvoll, wenn man gezielt prüfen will, ob Angriffe erkannt werden und ob der IT-Dienstleister oder das Security Operations Center (SOC) richtig reagiert. Aber auch dann muss mindestens eine Person eingeweiht sein, die eine Eskalation stoppen kann.

Ohne diese Abstimmung entsteht vor allem Reibung:

• Der Admin sperrt die IP-Adresse der Tester, und der Test bleibt unvollständig.
• Der Dienstleister startet einen Notfalleinsatz, der Geld kostet.
• Im Haus herrscht Aufregung, die niemandem etwas bringt.

Meine Empfehlung im Mittelstand: erst angekündigt testen und die Lücken schließen. Die Erkennung kann man in einem zweiten Schritt prüfen.

IT-Dock Redaktion: Was passiert, wenn ihr während des Tests eine akut kritische Schwachstelle oder Hinweise auf einen tatsächlichen Angriff entdeckt?

René Eck: Bei einer akut kritischen Schwachstelle wartet man nicht auf den Bericht. Sie wird sofort telefonisch an den vereinbarten Kontakt gemeldet und kurz schriftlich bestätigt. Dann entscheiden IT-Leitung und Testteam gemeinsam: sofort schließen, das System vom Netz nehmen oder bewusst weiterlaufen lassen. Wenn das Abschalten das Geschäft trifft, gehört die Geschäftsführung mit an den Tisch.

Bei Hinweisen auf einen echten Angriff, etwa unbekannte Konten, fremde Skripte oder Spuren im System, stoppt der Test an dieser Stelle. Es wird nichts verändert, damit Spuren erhalten bleiben. Dann greift der Notfallprozess:

• IT-Leitung und Geschäftsführung informieren
• bei Bedarf einen Forensik-Dienstleister und die Versicherung einbinden
• Meldepflichten nach DSGVO oder NIS2 prüfen

Wichtig ist, vorher zu klären: Der Pentester ist nicht automatisch der Incident Responder. Wer in diesem Fall welche Rolle übernimmt, sollte vor dem Test feststehen. Solche Funde sind selten, aber sie kommen vor.

Nach dem Pentest: Vom Bericht zur besseren Sicherheit

IT-Dock Redaktion: Woran erkennt eine IT-Leitung einen guten Pentest-Bericht, ohne jedes technische Detail selbst bewerten zu können?

René Eck: Ein guter Bericht hat eine Zusammenfassung, die auch die Geschäftsführung versteht: Was wurde getestet, wie ist die Lage in Geschäftssprache, und was ist als Erstes zu tun?

Jeder Befund ist nachvollziehbar beschrieben:

• wo er gefunden wurde und wie
• ein Nachweis
• eine Bewertung, die den Kontext des Unternehmens berücksichtigt
• eine konkrete Maßnahme, nicht nur „System härten“

Der Bericht sagt außerdem ehrlich, was nicht getestet wurde, in welchem Zeitraum getestet wurde und was den Test eingeschränkt hat. Wenn er aussieht wie eine Scanner-Liste mit Logo davor, ist das ein Warnsignal.

Wenn kaum Schwachstellen gefunden wurden, kann das gut sein. Dann sollte der Bericht aber zeigen, was alles versucht wurde. Es kann auch heißen, dass der Umfang zu eng war, die Zeit zu knapp oder ein Zugang nicht funktioniert hat.

IT-Dock Redaktion: Welche Fehler machen Unternehmen nach dem Pentest am häufigsten?

René Eck: Der häufigste: Der Bericht landet in der Ablage. Ebenfalls häufig: Nur die kritischen Punkte werden behoben, der Rest bleibt liegen. Oder man behebt das Symptom statt der Ursache. Ein Server wird gepatcht, aber am Patchmanagement ändert sich nichts. Beim nächsten Pentest stehen dann dieselben Befunde wieder im Bericht.

Bei begrenzten Ressourcen priorisiere ich nach drei Fragen:

• Wie schwer wiegt der Befund?
• Ist er von außen erreichbar?
• Wie groß ist der Aufwand?

Einfache Maßnahmen mit großer Wirkung kommen zuerst. Außerdem lohnt es sich, nach Mustern zu schauen. Wenn fünf Befunde auf fehlende MFA zurückgehen, ist das eine Maßnahme, nicht fünf. Jede Maßnahme braucht eine verantwortliche Person und einen Termin.

Ob die Maßnahmen wirken, zeigt ein Nachtest der Befunde. Zwischen zwei Pentests helfen regelmäßige Scans und die Nachverfolgung im Informationssicherheits-Managementsystem (ISMS).

Persönliches Fazit und Podcast

IT-Dock Redaktion: Welche drei Dinge würdest du einem IT-Entscheider vor seinem nächsten Pentest mitgeben?

René Eck:

René Eck: Zur Vertiefung empfehle ich die Folgen „Was passiert eigentlich bei einem Penetrationstest?“ und „Schwachstellen im Griff“ aus unserem Podcast „Kopf gehackt“. Die Folgen werden in den nächsten beiden Wochen veröffentlicht.