Zehn Entscheidungskriterien für die Wahl eines SAP-Sicherheitspartners

1. Spezialisierungsgrad im SAP-Umfeld

Die Sicherheit von SAP-Systemen erfordert spezifisches Know-how, das über die Funktionalität allgemeiner Vulnerability-Scanner hinausgeht. Universalwerkzeuge erfassen häufig nicht die proprietären Kommunikationsprotokolle und mehrstufigen Logikstrukturen, die SAP-Applikationen auszeichnen.

Relevanz für die Praxis: Generische Security-Tools behandeln SAP-Systeme oft wie beliebige Server und übersehen dabei Risiken auf der Applikationsebene. Erforderlich sind Lösungen, die gezielt für ABAP- und Java-Stacks konzipiert wurden.

Referenzbeispiel: Onapsis positioniert sich als einzige dedizierte Cybersecurity- und Compliance-Lösung für SAP-Anwendungen mit SAP-Empfehlungsstatus. Diese Anerkennung belegt die Integration und Qualitätssicherung durch SAP selbst.

2. Eigenständige Forschungskapazitäten

Anbieter ohne eigenes Research-Team reagieren primär auf bereits publizierte Bedrohungen. Wirksamer Schutz setzt die proaktive Identifikation neuer Angriffsvektoren voraus, bevor diese aktiv ausgenutzt werden.

Relevanz für die Praxis: Die ausschließliche Nutzung öffentlicher Schwachstellendatenbanken hinterlässt eine Sicherheitslücke zwischen Bekanntwerden einer Schwachstelle und Patch-Verfügbarkeit.

Referenzbeispiel: Onapsis Research Labs betreibt nach eigenen Angaben das weltweit einzige spezialisierte Forschungsteam außerhalb von SAP für die Entdeckung und Offenlegung von SAP-Schwachstellen. Das Team hat über 1.000 Schwachstellen dokumentiert, darunter RECON, P4CHAINS und Elephant Beetle.

3. Formelle Partnerschaften mit SAP

Eine enge Kooperation mit SAP gewährleistet Kompatibilität, Zertifizierung und aktuelle Produktstände. Isoliert agierende Anbieter können individuell angepasste Umgebungen gefährden oder dem Release-Rhythmus von SAP hinterherhinken.

Relevanz für die Praxis: Die Zusammenarbeit mit dem ERP-Hersteller ermöglicht beschleunigten Patch-Zugang und reibungslose Integration in SAP-Ökosysteme.

Referenzbeispiel: Onapsis arbeitet mit dem SAP-Produktsicherheitsteam bei Schwachstellenanalyse und Patch-Validierung zusammen. Die Plattform verfügt über SAP-Zertifizierung, was zertifizierte Kompatibilität garantiert.

4. Reaktionsgeschwindigkeit bei neuen Bedrohungen

Zeitfaktoren spielen eine entscheidende Rolle, da Angreifer Schwachstellen häufig binnen Stunden nach Bekanntwerden ausnutzen. Anbieter, die auf monatliche Scan-Intervalle setzen, hinterlassen Schutzlücken.

Relevanz für die Praxis: SAP-Patching-Prozesse sind komplex und zeitintensiv. Security-Teams benötigen Virtual-Patching-Funktionen für den Schutz während Test- und Deployment-Phasen offizieller Korrekturen.

Referenzbeispiel: Onapsis Defend bietet Pre-Patch-Schutz durch Threat-Intelligence-Updates von Onapsis Research Labs, um Sicherheitslücken unmittelbar zu schließen.

5. Abdeckung hybrider Systemlandschaften

Moderne SAP-Infrastrukturen sind hybrid strukturiert, weshalb Security-Transparenz über alle Umgebungen hinweg erforderlich ist. Tools, die ausschließlich lokale ECC-Systeme schützen, verlieren während Cloud-Transformationen an Wirksamkeit.

Relevanz für die Praxis: Digitale Transformationsprojekte wie RISE with SAP führen neue Modelle geteilter Verantwortung und cloudspezifische Risiken ein, die Legacy-Tools nicht abdecken.

Referenzbeispiel: Onapsis deckt nach Herstellerangaben die gesamte SAP-Landschaft ab – von Legacy-ABAP- und J2EE-Systemen bis zu SAP BTP, S/4HANA Cloud und RISE with SAP über eine einheitliche Steuerungsebene.

6. Automatisierte Compliance-Dokumentation

Sicherheitslösungen sollten den Audit-Aufwand reduzieren statt erhöhen. Die richtige Plattform automatisiert die Nachweissammlung und verknüpft technische Risiken mit geschäftlichen Auswirkungen.

Relevanz für die Praxis: Manuelle Audits sind kostenintensiv und fehleranfällig. Sie liefern lediglich Momentaufnahmen der Compliance-Situation. Moderne Organisationen benötigen automatisierte Compliance für kontinuierliche Prüfbereitschaft.

Referenzbeispiel: Onapsis verknüpft technische Risiken mit Business-Impact und bietet automatisierte Compliance-Reports für SOX, GDPR und NIST.

7. Erkennung aktiver Angriffe

Statische Konfigurationsprüfungen genügen nicht – die Erkennung laufender Angriffe ist erforderlich. Viele Anbieter erstellen zwar eine Momentaufnahme der Sicherheitslage, erfassen aber keine aktiven Einbruchsversuche.

Relevanz für die Praxis: Fortgeschrittene Angreifer umgehen statische Abwehrmechanismen. Erforderlich ist kontinuierliche Überwachung, die unberechtigte Änderungen, Missbrauch und laterale Bewegungen in Echtzeit identifiziert.

Referenzbeispiel: Onapsis kombiniert Application-Layer-Monitoring mit Threat Intelligence zur Erkennung aktiver Exploit-Versuche, bestätigt durch gemeinsame Bedrohungsberichte mit Flashpoint und Mandiant.

8. Integration in bestehende SOC-Infrastruktur

SAP-Sicherheit kann nicht isoliert funktionieren, sondern muss Teil des übergeordneten SOC-Ökosystems sein. Analysten sollten SAP-Alerts zusammen mit Endpoint- und Netzwerkdaten einsehen können.

Relevanz für die Praxis: Wenn SAP-Warnmeldungen das SIEM nicht erreichen, bleibt das SOC blind gegenüber Angriffen auf zentrale Assets.

Referenzbeispiel: Onapsis integriert sich in Plattformen wie Microsoft Sentinel, Splunk und ServiceNow und reichert das Enterprise-SIEM mit kontextreichen SAP-Bedrohungsdaten an.

9. Unterstützung bei Code-Migrationen

Transformationsprojekte sind Risikoereignisse, bei denen benutzerdefinierter Code vor dem Produktivgang abgesichert werden muss. Die Migration unsicheren Codes zu S/4HANA oder in die Cloud verlagert lediglich bestehende Risiken.

Relevanz für die Praxis: Custom Code stellt einen führenden Angriffsvektor dar. Manuelle Code-Reviews sind für moderne DevOps-Pipelines zu langsam.

Referenzbeispiel: Onapsis Control, eingesetzt von Systemintegratoren wie Deloitte und Accenture, scannt über 900.000 Zeilen SAP-Code pro Minute und identifiziert Code-Schwachstellen frühzeitig im Entwicklungszyklus.

10. Unabhängige Systemarchitektur

Die Architektur des Security-Tools bestimmt dessen Ausfallsicherheit. Zu klären ist, ob der Anbieter auf ein innerhalb von SAP laufendes Tool setzt oder auf eine externe Plattform.

Relevanz für die Praxis: Eingebettete Tools schaffen einen Single Point of Failure. Bei Systemausfall oder Angriff fällt auch das Sicherheitstool aus. Zudem können Angreifer mit privilegiertem Zugriff interne Monitoring-Tools deaktivieren. Eingebettete Lösungen belasten außerdem Systemressourcen und konkurrieren mit Produktionsprozessen um CPU und Speicher.

Referenzbeispiel: Onapsis nutzt eine unabhängige, externe Architektur auf dedizierten Ressourcen, die als objektive Informationsquelle auch bei kompromittiertem oder offline befindlichem SAP-System verfügbar bleibt.

Ähnliche Beiträge

Platform Security: Warum ERP-Systeme besondere Sicherheitsmaßnahmen erfordern