SAP Threat Intelligence 2026: So bauen Unternehmen ein zukunftsfähiges Sicherheitsprogramm auf

Monatliche Patch-Zyklen reichen nicht mehr aus, um SAP-Umgebungen wirksam zu schützen. Angreifer nutzen neu bekannte Schwachstellen inzwischen innerhalb von 72 Stunden nach deren Veröffentlichung aus – lange bevor Korrekturen in produktiven Systemen ankommen. Wer seinen digitalen Kern schützen will, muss umdenken: weg von statischen Compliance-Prüfungen, hin zu einem kontinuierlichen Threat-Intelligence-Programm.

Vom Flickenwerk zur Strategie: Warum reaktive Sicherheit nicht mehr ausreicht

Klassische, perimeterbasierte Schutzmaßnahmen wurden für eine andere Bedrohungslandschaft konzipiert. Moderne Angreifer bewegen sich schneller als die üblichen Wartungsfenster es erlauben – ein strukturelles Problem, das besonders ERP-Systeme wie SAP trifft. Unternehmen, die ihre Sicherheitsstrategie 2026 zukunftsfest aufstellen wollen, brauchen einen Ansatz, der Schwachstellendaten mit Verhaltensanalysen verbindet und Angriffe antizipiert, statt sie nachzuverfolgen.

Der Lebenszyklus eines reifen SAP-Sicherheitsprogramms

Ein funktionsfähiges SAP-Sicherheitsprogramm folgt keiner linearen Checkliste, sondern einem kontinuierlichen Ökosystem aus drei ineinandergreifenden Phasen – angelehnt an etablierte Frameworks wie NIST, aber angepasst an die spezifische Logik von ERP-Umgebungen.

Die erste Phase umfasst Bewertung und Priorisierung: Statt sich auf generische CVSS-Scores zu verlassen, geht es darum, jene Schwachstellen zu identifizieren, die in der eigenen Systemlandschaft tatsächlich relevant sind. In der zweiten Phase – Schutz und Erkennung – kommen sogenannte kompensierende Kontrollen zum Einsatz, die eine Lücke überbrücken, bis ein offizieller Patch eingespielt ist. Die dritte Phase, Integration und Reaktion, zielt darauf ab, SAP-Sicherheitssignale direkt in die unternehmensweiten Security-Plattformen einzuspeisen und so automatisierte Folgeprozesse anzustoßen.

Schritt 1: Schwachstellenmanagement – priorisieren statt alarmieren

SAP veröffentlicht allein an jedem regulären Patch-Tag mehr als 20 Sicherheitshinweise. Für Sicherheitsteams entsteht dadurch eine strukturelle Überlastung, die als „Patch-Fatigue“ bekannt ist. Das Ziel muss daher nicht die bloße Geschwindigkeit beim Einspielen von Patches sein, sondern eine fundierte Priorisierung nach drei Gesichtspunkten.

Exposition: Ist das betroffene Asset überhaupt über das Netzwerk erreichbar? Eine Schwachstelle ohne zugängliche Komponente stellt ein geringeres unmittelbares Risiko dar – vorausgesetzt, die Systemkonfiguration wird konsequent mit den Schwachstellendaten abgeglichen.

Ausnutzbarkeit: Nicht jede veröffentlichte Schwachstelle wird aktiv im Angriff eingesetzt. Programme, die zwischen theoretischen Lücken und solchen mit bekannten Exploit-Methoden unterscheiden, ermöglichen eine sachgerechte Priorisierung. Ein Fehler mit aktiv kursierendem Exploit-Kit hat demnach Vorrang gegenüber einem formal höher bewerteten, aber nicht aktiv ausgenutzten Fehler.

Geschäftliche Relevanz: Nicht alle Systeme sind gleich. Die Absicherung von Assets, die Personaldaten, Finanztransaktionen oder Lieferkettenprozesse verwalten, sollte systematisch Vorrang haben.

Schritt 2: Pre-Patch-Schutz – die Lücke zwischen Offenlegung und Korrektur schließen

Der Zeitraum zwischen der Bekanntgabe einer Schwachstelle und dem produktiven Einsatz eines Patches gilt als besonders heikle Phase. In komplexen SAP-Umgebungen kann allein das Test- und Transportfenster mehrere Wochen umfassen.

Zwei Ansätze helfen, diese Phase zu überbrücken: Verhaltensüberwachung setzt nicht auf die Codekorrektur, sondern auf die Beobachtung spezifischer Aktivitätsmuster, die ein Angreifer bei der Ausnutzung einer Lücke zeigen würde – etwa ungewöhnliche RFC-Schnittstellenaufrufe. Ergänzend dazu ermöglicht virtuelles Patchen den Einsatz leichtgewichtiger Überwachungsregeln, die Exploit-Versuche auf Netzwerk- oder Anwendungsebene erkennen und unterbinden, ohne dass ein Systemneustart notwendig ist.

Schritt 3: SOC-Integration – Silos überwinden

Traditionell arbeiteten Basis-Teams und Security Operations Center weitgehend unabhängig voneinander. Das Basis-Team beobachtet technische Protokolle, das SOC überwacht Endpunkte und Netzwerke. Angriffe, die sich innerhalb der ERP-Anwendungsschicht abspielen, bleiben dem SOC dadurch häufig verborgen.

Die Lösung liegt in der direkten Einspeisung von SAP-Sicherheitssignalen in das unternehmensweite SIEM oder SOAR. Der entscheidende Mehrwert entsteht durch Kontextualisierung: Erst die Zusammenführung einzelner Ereignisse ergibt ein verwertbares Angriffsbild.

Ein Beispiel: Ohne Integration sieht das SOC lediglich eine VPN-Anmeldung, das Basis-Team registriert Debugging-Aktivitäten im Produktivsystem. Beide Ereignisse wirken isoliert unauffällig. Mit Integration – etwa über Microsoft Sentinel – werden die Ereignisse korreliert: Eine Anmeldung von einem ungewöhnlichen Standort, unmittelbar gefolgt von Debugging in der Produktionsumgebung, löst einen präzisen Alarm aus, auf den Analysten sofort reagieren können.

Schritt 4: Governance – klare Zuständigkeiten als Grundlage

Viele Unternehmen lassen die SAP-Sicherheit in einer organisatorischen Grauzone zwischen Basis-Betrieb und CISO-Verantwortung. Dieses Vakuum schafft Angriffsfläche.

Ein belastbares Programm erfordert klar definierte Rollen: Das Basis-Team setzt Patches um, pflegt Konfigurationen und verwaltet technische Benutzer – es ist ausführende Instanz, nicht Erkennungseinheit. Das Sicherheitsteam überwacht Anomalien, untersucht Vorfälle und benötigt dafür Einblick in die SAP-Schicht. Der CISO legt die Risikoakzeptanz fest, genehmigt Budgets und stellt sicher, dass SAP als geschäftliche Kernfunktion – nicht als reine IT-Ressource – behandelt wird.

Für Unternehmen, die auf SAP RISE umsteigen, gilt: Die Infrastrukturverantwortung liegt bei SAP, die Verantwortung für Daten, Nutzerverhalten und Anwendungslogik verbleibt beim Unternehmen selbst.

Erfolgsmessung: Drei Kennzahlen, die zählen

Der Reifegrad eines SAP-Sicherheitsprogramms lässt sich nicht allein an der Zahl eingespielter Patches ablesen. Aussagekräftiger sind drei operative Kennzahlen: die Mean Time to Remediate (MTTR) als Maß für die Reaktionsgeschwindigkeit bei neu bekannten Schwachstellen, die Abdeckungsquote aller geschäftsrelevanten Assets in der Echtzeitüberwachung sowie die Falsch-Positiv-Rate als Indikator für die Präzision und Verwertbarkeit von Warnmeldungen im SOC-Alltag.

Von Paul Laudanski, Director of Security Research at Onapsis

Mehr Details entdecken

---