Penetrationstest
Ein Penetrationstest ist ein geplanter, autorisierter Angriff auf ein IT-System, um dessen Schwachstellen aufzudecken, bevor echte Angreifer sie ausnutzen. Fachleute prüfen dabei kontrolliert, ob und wie weit sie in Netzwerk, Anwendung oder – etwa beim ERP-System – in geschäftskritische Daten eindringen können.
Ein Penetrationstest (kurz Pentest) ist ein simulierter, ausdrücklich beauftragter Angriff auf ein IT-System, mit dem Sicherheitsexperten dessen Verwundbarkeit unter realen Angriffsbedingungen prüfen. Ziel ist es, Schwachstellen in Netzwerken, Servern, Webanwendungen oder Konfigurationen zu finden und – soweit vertraglich erlaubt – aktiv auszunutzen, um zu zeigen, welchen Schaden ein echter Angreifer anrichten könnte. Anders als ein reiner Sicherheitsbericht liefert ein Pentest damit keinen theoretischen Risikohinweis, sondern einen praktischen Nachweis: Diese Lücke ist real, so lässt sie sich ausnutzen, und das sind die Folgen.
Der Test ist streng abgegrenzt und kontrolliert. Auftraggeber und Tester vereinbaren vorab Umfang (Scope), Zielsysteme, Zeitfenster und erlaubte Methoden in einer schriftlichen Freigabe – ohne diese Autorisierung wäre dieselbe Handlung strafbar. Am Ende steht ein Bericht, der die gefundenen Schwachstellen nach Schweregrad einordnet, den Angriffsweg nachvollziehbar dokumentiert und konkrete Maßnahmen zur Behebung empfiehlt. Ein Penetrationstest ist damit ein zentrales Werkzeug, um das Sicherheitsniveau eines Systems belastbar zu bewerten, statt sich auf Annahmen zu verlassen.
Auf einen Blick
- Penetrationstest = autorisierter, simulierter Angriff zum Aufdecken realer Schwachstellen
- Immer mit schriftlicher Freigabe und klar abgegrenztem Scope – sonst strafbar
- Arten: Black-, Grey- und White-Box je nach Vorwissen des Testers
- Liefert einen priorisierten Bericht mit Nachweis, Angriffsweg und Gegenmaßnahmen
- Für ERP-Systeme relevant, weil sie zentrale Finanz-, Kunden- und Bestandsdaten bündeln
Wie ein Penetrationstest abläuft
Ein Penetrationstest folgt einem strukturierten Ablauf, der sich an etablierten Vorgehensmodellen wie dem BSI-Leitfaden oder dem OWASP Web Security Testing Guide orientiert. Am Anfang steht nicht das Hacken, sondern die Abstimmung: Was darf getestet werden, welche Systeme sind tabu, wie aggressiv darf vorgegangen werden und wer ist im Notfall erreichbar. Erst wenn dieser Rahmen schriftlich fixiert ist, beginnt die eigentliche technische Arbeit.
Typischerweise durchläuft ein Pentest mehrere Phasen. In der Aufklärung (Reconnaissance) sammeln die Tester Informationen über das Ziel – offene Ports, eingesetzte Software, Versionsstände. Es folgt das Auffinden potenzieller Schwachstellen, deren aktive Ausnutzung (Exploitation) und – wo relevant – der Versuch, die erlangten Rechte auszuweiten (Privilege Escalation) und die Kontrolle zu behalten. Abschließend werden alle Spuren dokumentiert und das System wieder in den Ausgangszustand versetzt.
Die Phasen im Überblick
Als Merkhilfe gliedert man den Ablauf oft in fünf Schritte: Vorbereitung und Scoping, Informationsbeschaffung, Schwachstellenanalyse, aktive Ausnutzung und Berichterstattung. Der letzte Schritt ist der wertvollste – ein Pentest ohne verständlichen Abschlussbericht mit priorisierten Empfehlungen bleibt Selbstzweck. Ein guter Bericht richtet sich zugleich an Technik (konkrete Fixes) und an die Leitung (Risikobewertung fürs Geschäft).
Arten von Penetrationstests
Penetrationstests unterscheiden sich vor allem darin, wie viel Vorwissen die Tester erhalten und aus welcher Position sie angreifen. Beim Black-Box-Test bekommen sie kaum Informationen und agieren wie ein außenstehender Angreifer – das ist realistisch, aber zeitaufwendig. Beim White-Box-Test liegen Quellcode, Architektur und Zugangsdaten offen, was eine tiefe, effiziente Prüfung erlaubt. Der Grey-Box-Test liegt dazwischen und ist in der Praxis am verbreitetsten, weil er Aufwand und Aussagekraft ausbalanciert.
Ergänzend unterscheidet man nach Angriffsposition: Ein externer Test prüft, was von außen über das Internet erreichbar ist – Webshop, VPN-Zugang, Mailserver. Ein interner Test simuliert einen Angreifer, der bereits im Netzwerk ist, etwa durch einen kompromittierten Mitarbeiter-Account oder Schadsoftware. Weitere Spielarten sind Tests von Webanwendungen und APIs, von Cloud-Umgebungen, von WLAN sowie Social-Engineering-Tests, die den Faktor Mensch (Phishing, Zutritt) auf die Probe stellen.
Abgrenzung: Penetrationstest vs. Schwachstellenscan vs. Audit
Der Begriff wird oft mit verwandten Prüfungen verwechselt. Ein Schwachstellenscan (Vulnerability Scan) ist ein weitgehend automatisierter Abgleich der Systeme gegen bekannte Sicherheitslücken. Er ist schnell und günstig, liefert aber viele Fehlalarme und beweist nicht, ob eine Lücke tatsächlich ausnutzbar ist. Ein Penetrationstest baut oft auf einem solchen Scan auf, geht aber entscheidend weiter: Menschen prüfen manuell, verketten mehrere Schwachstellen und weisen den realen Schaden nach.
Ein Security-Audit wiederum bewertet primär Prozesse, Richtlinien und Konformität – etwa gegen ISO 27001 – und arbeitet dokumenten- und stichprobenbasiert, ohne aktiv anzugreifen. Ein noch umfassenderes Format ist das Red Teaming, bei dem ein Team über längere Zeit und mit voller Bandbreite an Methoden (Technik, Physisches, Social Engineering) ein Unternehmen angreift, um die gesamte Verteidigungsfähigkeit zu testen. Der Pentest ist der fokussierte, technisch-praktische Kern in diesem Spektrum.
Penetrationstest im ERP-System
Ein ERP-System ist ein besonders lohnendes Angriffsziel, weil es die wertvollsten Daten eines Unternehmens an einem Ort bündelt: Kundenstamm und Lieferantenstamm, Preise und Konditionen, offene Aufträge, Bestände sowie Finanz- und Buchungsdaten. Gelingt einem Angreifer der Zugriff, drohen Datendiebstahl, manipulierte Bestellungen, umgeleitete Zahlungen oder ein kompletter Betriebsstillstand. Ein Penetrationstest prüft deshalb gezielt, ob sich diese zentrale Datenbasis von außen oder über kompromittierte Konten erreichen lässt.
Im ERP-Kontext richtet sich der Test typischerweise auf mehrere Ebenen: die Weboberfläche und Anmeldung, die angebundenen Schnittstellen und APIs (etwa zu Shop, Marktplatz oder Versanddienstleister), das Berechtigungskonzept sowie die zugrunde liegende Server- und Datenbankschicht. Häufige Befunde sind zu weit gefasste Rollen, schwache oder fehlende Mehr-Faktor-Authentifizierung, ungepatchte Komponenten und ungesicherte API-Endpunkte. Wie der Test organisiert wird, hängt vom Betriebsmodell ab.
Cloud-ERP vs. On-Premise: Wer darf was testen?
Bei einem Cloud-ERP im SaaS-Modell betreibt der Anbieter die Infrastruktur – ein eigenmächtiger Pentest gegen dessen Systeme ist in der Regel vertraglich untersagt und muss vorab abgestimmt werden. Der Kunde kann und sollte aber die eigenen Zugänge, Rollen, Schnittstellen und individuellen Anpassungen prüfen lassen. Bei einem On-Premise-ERP oder eigenem Hosting liegt die Verantwortung vollständig beim Unternehmen, das den Test entsprechend breiter beauftragen darf – von der Anwendung bis zum darunterliegenden Server.
Warum Penetrationstests im DACH-Raum zählen
Regelmäßige Sicherheitsüberprüfungen sind nicht nur gute Praxis, sondern zunehmend Pflicht. Die DSGVO verlangt für personenbezogene Daten angemessene technische Schutzmaßnahmen und deren fortlaufende Überprüfung – ein Penetrationstest ist ein anerkanntes Mittel, diese Sorgfalt nachzuweisen. Sicherheitsstandards wie ISO 27001 fordern ebenfalls ein systematisches Schwachstellenmanagement, das Pentests einschließt. Für Betreiber kritischer Infrastrukturen (KRITIS) sowie im Rahmen der NIS-2-Umsetzung verschärfen sich diese Anforderungen zusätzlich.
Praktisch zahlt sich ein Pentest doppelt aus: Er senkt das reale Risiko eines teuren Vorfalls, und er liefert gegenüber Kunden, Auditoren, Versicherern und Aufsichtsbehörden einen dokumentierten Beleg für Sorgfalt. Wichtig ist die Wiederholung – ein Test ist eine Momentaufnahme. Nach größeren Änderungen an ERP, Schnittstellen oder Infrastruktur sowie in festen Abständen (oft jährlich) sollte er erneut durchgeführt werden, ergänzt um kontinuierliches Patch-Management, damit einmal geschlossene Lücken nicht wieder aufreißen.
Praxisbeispiel
Beispiel: Pentest deckt eine offene API beim Onlinehändler auf
Ein mittelständischer Onlinehändler betreibt sein ERP im eigenen Hosting und hat es über eine API an Shop und Marktplätze angebunden. Vor der Anbindung eines weiteren Vertriebskanals beauftragt die Geschäftsführung einen Grey-Box-Penetrationstest der ERP-Schnittstellen. Die Tester erhalten einen normalen Benutzerzugang und die API-Dokumentation, aber keine Administratorrechte.
Innerhalb weniger Tage finden sie einen API-Endpunkt, der Bestell- und Kundendaten ohne saubere Berechtigungsprüfung ausliefert: Mit einem einfach hochgezählten Parameter lassen sich fremde Aufträge inklusive Adressen und Beträgen abrufen. Der Bericht stuft den Befund als kritisch ein, dokumentiert den genauen Angriffsweg und empfiehlt eine serverseitige Berechtigungsprüfung je Datensatz. Das Unternehmen schließt die Lücke vor dem Rollout – ein potenzieller Datenschutzvorfall mit Meldepflicht wird so verhindert.
Häufige Fragen
Passende Leistungen
Fragen zu Penetrationstest in deinem ERP-Projekt?
Wir beraten herstellerunabhängig – und setzen es auf Wunsch selbst um.