SAP-Penetrationstests: Blinde Flecken im Kern der IT

Die aktuelle Bedrohungslandschaft lässt keinen Zweifel: Cyberangriffe sind eine allgegenwärtige Gefahr für Unternehmen jeder Größe. Laut dem BSI-Lagebericht zur IT-Sicherheit in Deutschland 2025 ist die Lage angespannt und -bietet Angreifern durch immer noch zu schlecht geschützte Angriffsflächen die Möglichkeit, vor allem kleine und mittlere Unternehmen anzugreifen. Dieser Trend spiegelt sich auch im SAP-Umfeld wider: Eine Analyse der monatlich veröffent-lichten Sicherheitshinweise zeigt 2025 eine deutliche Zunahme an Schwachstellen, was die wachsende Angriffsfläche von SAP-Anwendungen unterstreicht. In Reaktion auf diese angespannte Cyberlage haben die meisten Organisationen ihre Verteidigungsmaßnahmen verstärkt: Multi-Faktor-Authentifizierung, Endpoint-Detection-Systeme und Infomationssicherheits-Management als Beispiele für moderne Sicherheitsmaßnahmen sind bekannt und gehören mittlerweile zum Standardrepertoire. Doch inmitten dieser Bemühungen existiert ein gefährlicher blinder Fleck: die SAP-Systemlandschaft. Während das Netzwerk und die klassische IT-Infrastruktur akribisch geprüft werden, bleibt das System, das Finanz- und Personaldaten, Produktionspläne und Kundeninformationen verwaltet, oft eine Blackbox. 

Vernachlässigte SAP-Sicherheit

Die Gründe dafür sind meist organisatorischer Natur. SAP-Sicherheit fällt oft in eine Zuständigkeitslücke: Dem IT-Sicherheitsteam fehlt das Spezialwissen zur proprietären Architektur, während sich das SAP-Team auf Stabilität statt auf Angriffssimulationen fokussiert. Hinzu kommt ein trügerisches Sicherheitsgefühl, das SAP-Systeme als interne, abgeschottete Monolithen betrachtet. Diese Annahme ignoriert die -Realität moderner, über Webservices und Cloud-Anbindungen vernetzter Landschaften. Ein klassischer Netzwerk-Pentest reicht nicht aus: Standard-Scanner prüfen nur die Host-Maschine, verstehen aber nicht die komplexe SAP-Anwendungsschicht mit ihren proprietären Protokollen wie Remote Function Call (RFC) oder Dynamic Information and Action Gateway (DIAG). Werden zudem angebundene Entwicklungs-, Test- oder technische Systeme wie Solution Manager, Focused Run, Governance, Risk and Compliance usw. vom Test-Scope ausgenommen, bleibt ein entscheidender Angriffsvektor unberücksichtigt.

Typische Angriffsvektoren

Angriffstypen auf SAP-Systeme lassen sich einerseits in Serververschlüsselung mit dem Ziel der Lösegelderpressung, andererseits in Insider-Angriffe einteilen. Gefährlich sind beide Vorgehensweisen vor allem durch ihre Schnelligkeit: Ein Bericht von Onapsis und SAP zeigt, dass Angriffe auf kritische SAP-Anwendungen zunehmen und oft schon innerhalb von 72 Stunden nach Veröffentlichung eines Sicherheitspatches erfolgen. Angreifer nutzen dabei immer wieder typische Schwachstellen. Ein besonders häufiger Angriffsvektor sind ungepatchte SAP-Systeme. Obwohl SAP an jedem zweiten Dienstag im Monat im Rahmen des Patch Day sicherheitsrelevante Hinweise veröffentlicht, werden Updates in vielen Unternehmen nicht zeitnah eingespielt. Systeme bleiben dadurch über Wochen oder Monate für bekannte Exploits offen. Ebenfalls kritisch sind unzureichend abgesicherte RFC-Schnittstellen. Wird zunächst ein weniger geschütztes Entwicklungs- oder Testsystem kompromittiert, können Angreifer über diese Verbindungen lateral auf produktive Systeme zugreifen und dort Funktionen ausführen. 

Hinzu kommen mangelhafte Berechtigungskonzepte: Noch immer existieren Standardbenutzer wie SAP* oder DDIC mit schwachen oder unveränderten Passwörtern sowie überprivilegierte Dialog- oder Systembenutzer. Solche Konten werden gezielt genutzt, um Rechte schrittweise bis zur vollständigen Systemkontrolle auszuweiten. Auch unsicherer Custom Code stellt ein Einfallstor dar, etwa durch fehlende Berechtigungsprüfungen oder Anfälligkeit für Code-Injections. Passwörter bleiben ebenfalls ein Dauerproblem, da lange Gültigkeitszeiträume, schwache Hash-Verfahren und Wiederverwendungen die Übernahme von Benutzerkonten erleichtern.

Um die Risiken proaktiv zu adressieren, reicht ein herkömmlicher Penetrationstest nicht. Die SAP Secure Operations Map bietet ein anschauliches Modell, um die verschiedenen Sicherheitsebenen zu verstehen. 

SAP-Penetrationstests

Klassische Pentests decken in der Regel nur die unterste IT-Infrastrukturebene ab. Die entscheidenden Schwachstellen und Angriffspunkte liegen jedoch meist in den darüber liegenden system- und applikationsspezifischen Ebenen, die für Außenstehende oft eine Blackbox darstellen. Ein SAP-Penetrationstest setzt daher gezielt dort an, wo klassische Prüfungen enden, und analysiert SAP-spezifische Dienste und Protokolle wie Gateway, Message Server oder das Internet Communication Framework ebenso wie die Sicherheit der DIAG- und RFC-Kommunikation. Darüber hinaus wird die Anwendungssicherheit geprüft, indem Standardtransaktionen, Fiori-Apps und Webservices auf Manipulationsmöglichkeiten und unberechtigte Zugriffe untersucht werden. Ein weiterer Schwerpunkt liegt auf dem Berechtigungskonzept, das systematisch auf kritische Berechtigungen und potenzielle Pfade zur Rechteausweitung hin analysiert wird. Auch kundenindividueller Abap-Code wird sowohl manuell als auch mit spezialisierten Werkzeugen auf Schwachstellen wie Code-Injection oder fehlende Authority-Checks untersucht. Ergänzend erfolgt eine Überprüfung der Systemkonfiguration, insbesondere sicherheitsrelevanter Profilparameter, auf ihre Konformität mit den Best Practices von SAP und DSAG-Empfehlungen. Ein weiterer Vorteil liegt im tiefen Verständnis der Tester für die SAP-Welt. Sie wissen, wo versteckte Konfigurationen liegen, wie -Geschäftsprozesse manipuliert werden können und welche Standardeinstellungen ein Risiko darstellen. Dieser fachliche Fokus ermöglicht es, Schwachstellen aufzudecken, die für allgemeine Sicherheitsscanner und -experten unsichtbar bleiben. Regulatorische Vorgaben wie Nis2 oder Kritis-Vorgaben fordern einen nachweisbaren, ganzheitlichen Sicherheitsansatz, den der isolierte Penetrationstest allein nicht erfüllt.

Eine ganzheitliche SAP-Sicherheitsstrategie geht darüber hinaus und umfasst eine sichere Softwareentwicklung im Rahmen eines Secure Software Development Lifecycles. Auch die Absicherung der Supply Chain gewinnt an Bedeutung, insbesondere in kritischen Branchen, in denen Abhängigkeiten von externen Partnern erheb-liche Risiken bergen. Ergänzt wird dieser Ansatz durch ein kontinuierliches Monitoring, das mithilfe eines zentralen SIEM-Systems sicherheitsrelevante Ereignisse systemübergreifend erfasst und auswertet. Und schlussendlich erfordert der zunehmende Einsatz von Cloud-Lösungen eine gesonderte Betrachtung, da deren -Sicherheitsanforderungen und Bedrohungsszenarien sich in vielen Punkten von klassischen On-Premises-Systemen unterscheiden.

Weiter zum Partnereintrag: