Schwachstellen finden, bevor es jemand anderes tut

Ein Penetrationstest ist ein kontrollierter Angriff auf fremde Systeme – und damit nur dann zulässig, wenn der Verfügungsberechtigte ihn schriftlich beauftragt hat. Wir beginnen deshalb ausnahmslos mit einer Freigabeerklärung, in der Auftraggeber, Prüfumfang, Zeitraum, Testtiefe und die Ansprechpartner beider Seiten benannt sind.

Der Prüfumfang wird als Positivliste festgelegt: konkrete IP-Bereiche, Domains, Anwendungen oder Netzsegmente. Alles, was nicht auf dieser Liste steht, wird nicht getestet – auch dann nicht, wenn es während des Tests auffällt. Wir melden solche Beobachtungen, aber wir handeln nicht darauf.

Besondere Sorgfalt gilt bei fremdgehosteten Systemen. Liegt Ihre Anwendung bei einem Cloud-Anbieter oder einem Rechenzentrumsdienstleister, benötigen wir zusätzlich dessen Einverständnis, weil dort auch Infrastruktur anderer Kunden betroffen sein kann. Ohne diese Zustimmung findet der Test an den betreffenden Systemen nicht statt.

Tests an Systemen Dritter ohne deren Auftrag führen wir grundsätzlich nicht durch – unabhängig davon, wer danach fragt und mit welcher Begründung.

Der externe Test nimmt die Perspektive eines Angreifers ein, der nichts über Sie weiß außer Ihrem Namen und Ihrer Domain. Wir erfassen zunächst, was von außen überhaupt sichtbar ist: erreichbare Dienste, offene Ports, veröffentlichte Anwendungen, Mailserver, VPN-Endpunkte, Fernwartungszugänge, vergessene Testsysteme auf Subdomains.

Erfahrungsgemäß ist allein diese Bestandsaufnahme für viele Unternehmen aufschlussreich. Es tauchen regelmäßig Systeme auf, von denen intern niemand mehr wusste – ein altes Kundenportal, eine Testinstanz aus einem abgeschlossenen Projekt, eine Verwaltungsoberfläche, die bei einer Umkonfiguration versehentlich freigegeben wurde.

Anschließend prüfen wir die gefundenen Dienste gezielt: Patchstände, bekannte Schwachstellen, Konfigurationsfehler, schwache Verschlüsselungseinstellungen, fehlende Sperrmechanismen bei Anmeldeversuchen und die Wirksamkeit vorhandener Schutzkomponenten.

Die meisten erfolgreichen Angriffe scheitern nicht am Perimeter – sie beginnen mit einem kompromittierten Arbeitsplatz oder gestohlenen Zugangsdaten. Der interne Test setzt genau dort an: Wir arbeiten mit einem regulären Netzzugang und der Berechtigung eines gewöhnlichen Mitarbeitenden und prüfen, wie weit sich daraus kommen lässt.

Im Fokus stehen dabei die Themen, die in gewachsenen Umgebungen fast immer Befunde liefern: Berechtigungen im Verzeichnisdienst, Dienstkonten mit überhöhten Rechten, im Netz auffindbare Zugangsdaten in Skripten und Freigaben, fehlende Segmentierung zwischen Arbeitsplätzen und Servern, veraltete Protokolle sowie Systeme ohne aktuelle Patchstände.

Ziel ist die Frage, wie schnell aus einem einfachen Benutzerkonto administrative Kontrolle über die Domäne wird. In Umgebungen, die nie geprüft wurden, ist dieser Weg oft überraschend kurz – und ebenso oft mit wenigen gezielten Änderungen deutlich zu verlängern.

Bei Webanwendungen, Kundenportalen und Onlineshops orientieren wir uns am Prüfrahmen der OWASP-Kategorien. Geprüft werden unter anderem Zugriffskontrolle, Authentifizierung und Sitzungsverwaltung, Einschleusungsangriffe, unsichere Konfiguration, kryptografische Umsetzung und der Umgang mit eingebundenen Fremdkomponenten.

Die interessantesten Befunde entstehen dabei selten durch automatisierte Werkzeuge, sondern in der manuellen Prüfung der Anwendungslogik: Lässt sich durch Ändern einer Kennung im Aufruf ein fremder Datensatz aufrufen? Wird eine Berechtigung nur in der Oberfläche geprüft, nicht aber serverseitig? Lassen sich Schritte eines Prozesses überspringen?

Solche Lücken sind für Angreifer besonders attraktiv, weil sie keinerlei Spezialwerkzeug erfordern. Für Anwendungen mit personenbezogenen Daten sind sie zugleich die Befunde mit den weitreichendsten Folgen.

Vor dem Test klären wir den Informationsstand. Beim Blackbox-Ansatz erhalten wir keine Vorabinformationen und arbeiten wie ein Außenstehender – realitätsnah, aber zeitaufwendig. Beim Whitebox-Ansatz stellen Sie Dokumentation, Zugänge und teils Quellcode bereit, wodurch die verfügbare Zeit vollständig in die Tiefe geht statt in die Aufklärung. Der Greybox-Ansatz dazwischen ist für die meisten mittelständischen Projekte der wirtschaftlichste.

Ebenso vereinbaren wir die Eingriffstiefe. Rein verifizierende Tests weisen eine Schwachstelle nach, ohne sie auszunutzen. Ausnutzende Tests belegen die tatsächliche Auswirkung, bergen aber ein Restrisiko für den Betrieb. Für Produktivsysteme legen wir vorab fest, welche Klassen von Prüfungen zulässig sind und welche ausgeschlossen bleiben.

Denial-of-Service-Tests führen wir auf Produktivsystemen grundsätzlich nicht durch. Während des gesamten Tests ist ein Ansprechpartner beider Seiten erreichbar, und es gilt ein vereinbartes Abbruchkriterium: Zeigt sich eine Betriebsbeeinträchtigung, wird sofort gestoppt und informiert.

Der Bericht besteht aus zwei Teilen. Die Zusammenfassung richtet sich an die Geschäftsführung: Wo steht das Unternehmen, welche Risiken bestehen und was sollte zuerst geschehen – ohne Fachjargon. Der technische Teil beschreibt jeden Befund reproduzierbar, mit Nachweis, Risikoeinstufung und einer konkreten Handlungsempfehlung.

Wichtig ist uns die Priorisierung nach Wirkung und Aufwand. Eine lange Liste theoretischer Befunde hilft niemandem; entscheidend sind die drei bis fünf Punkte, deren Behebung die Angriffsfläche am stärksten verkleinert. Diese besprechen wir in einem gemeinsamen Termin, auf Wunsch auch mit Ihrem bisherigen IT-Dienstleister.

Nach Behebung der Befunde führen wir einen Nachtest durch und prüfen gezielt, ob die Korrekturen wirksam sind. Erst dieser Nachtest schließt den Vorgang sauber ab – erfahrungsgemäß bleiben sonst einzelne Maßnahmen unvollständig umgesetzt.

Ein Penetrationstest ist eine Momentaufnahme. Er beschreibt den Sicherheitszustand der geprüften Systeme zum Testzeitpunkt, im festgelegten Umfang, mit der vereinbarten Testtiefe. Er ist damit ausdrücklich kein Nachweis dauerhafter Sicherheit und kein Zertifikat.

Schon wenige Wochen später kann sich das Bild ändern: durch eine neu veröffentlichte Schwachstelle, eine geänderte Firewall-Regel, eine neu ausgerollte Anwendung oder ein zusätzliches Dienstkonto. Auch bedeutet ein Test ohne kritische Befunde nicht, dass keine existieren – er bedeutet, dass im gegebenen Zeitrahmen und Umfang keine gefunden wurden.

Sinnvoll ist ein Pentest deshalb als wiederkehrender Baustein, nicht als einmalige Maßnahme. Für die meisten mittelständischen Unternehmen ist ein jährlicher Rhythmus angemessen, ergänzt um zusätzliche Tests nach wesentlichen Änderungen an der Infrastruktur oder an veröffentlichten Anwendungen.

Zwischen den Tests trägt der laufende Betrieb die Sicherheit: Patch-Management, Monitoring, Berechtigungsreviews und geprüfte Backups. Ein Test ersetzt keinen dieser Bausteine, er zeigt nur, wie gut sie zusammenwirken.