So bauen Sie 2026 ein Threat Intelligence auf

Herkömmliche, auf Perimeter-Sicherheit basierende Abwehrmaßnahmen wurden für eine andere Zeit konzipiert. In der heutigen Sicherheitslandschaft nutzen Angreifer Schwachstellen innerhalb eines kritischen 72-Stunden-Fensters nach Bekanntwerden der Schwachstelle aus. Diese Schnelligkeit bedeutet, dass geschäftskritische Anwendungen Angriffen ausgesetzt bleiben, lange bevor Korrekturen implementiert werden können, wenn man sich ausschließlich auf monatliche Patch-Zyklen verlässt.

Um den digitalen Kern im Jahr 2026 zu sichern, müssen Unternehmen von statischen Compliance-Prüfungen zu einer umfassenden Strategie der SAP Threat Intelligence übergehen. Dieser Ansatz nutzt Schwachstellendaten und Verhaltensanalysen, sodass Sicherheitsteams Angriffe vorhersehen können, anstatt nur auf sie zu reagieren.

Der Kernlebenszyklus: Von der Erfassung bis zur Umsetzung

Ein ausgereiftes SAP-Sicherheitsprogramm ist eher ein kontinuierlicher Prozess als eine lineare Checkliste. Es orientiert sich an modernen Cybersicherheits-Frameworks wie NIST, ist jedoch speziell auf die Komplexität der ERP-Geschäftslogik zugeschnitten.

Der Lebenszyklus besteht aus drei unterschiedlichen Phasen:

1. Assess Ermittlung und Priorisierung): Über einfache CVSS-Werte hinausgehen, um die spezifischen Schwachstellen zu ermitteln, die Ihre individuelle Infrastruktur gefährden.
2. Defend Schützen & Erkennen): Implementierung von „Ausgleichskontrollen“ oder virtuellen Patches sowie Überwachung auf aktive Ausnutzungsversuche, während die Patches validiert werden.
3. Reagieren (Integrieren & Handeln): Überwindung von Silostrukturen durch die Weiterleitung präziser Warnmeldungen an das unternehmensweite SOC über Tools wie Microsoft Sentinel oder Splunk, um sofortige Maßnahmen auszulösen.

Schritt 1: Schwachstellenmanagement und Priorisierung

Sicherheitsteams leiden aufgrund der schieren Menge an Warnmeldungen häufig unter „Patch-Müdigkeit“. Da SAP an jedem Patch-Tag mehr als 20 Sicherheitshinweise veröffentlicht , ist es oft betrieblich nicht machbar, jeden Fix sofort in einer komplexen Landschaft zu implementieren.

Das Ziel besteht nicht nur darin, Patches schneller zu installieren, sondern auch effizienter. Ein robustes Strategie zum Schwachstellenmanagement filtert kritische Bedrohungen auf der Grundlage von drei betrieblichen Gegebenheiten:

1. Verfügbarkeit (Ist der Vermögenswert zugänglich?)

Eine Sicherheitslücke kann zwar den Schweregrad „Kritisch“ aufweisen, doch wenn sie eine Komponente betrifft, die nicht installiert oder über das Netzwerk nicht erreichbar ist, ist das unmittelbare Risiko geringer. threat intelligence effektive threat intelligence die Sicherheitslücke mit Ihrer tatsächlichen Systemkonfiguration threat intelligence , um den Angriffspfad zu überprüfen.

2. Ausnutzbarkeit (Ist die Bedrohung aktiv?)

Nicht alle Sicherheitslücken werden gleichermaßen ausgenutzt. Informationen von Onapsis Research Labs unterscheiden zwischen theoretischen Schwachstellen und solchen, die in der Praxis aktiv ausgenutzt werden. Ein Fehler mit dem Schweregrad „Hoch“, für den es ein aktives Exploit-Kit gibt, sollte Vorrang vor einem Fehler mit dem Schweregrad „Kritisch“ haben, für den keine Angriffsmethode bekannt ist.

3. Auswirkungen auf das Geschäft (Was steht auf dem Spiel?)

Jedes System gleich zu behandeln, ist eine ineffiziente Nutzung von Ressourcen. Ihr Programm sollte die Ressourcen nach ihrer geschäftlichen Bedeutung priorisieren. So wird sichergestellt, dass die begrenzten Wartungsfenster auf die Systeme konzentriert werden, die personenbezogene Daten, Finanzdaten oder Lieferkettenlogik enthalten.

Schritt 2: Einrichtung des Schutzes vor dem Patch

Die gefährlichste Phase für jedes Unternehmen ist der Zeitraum zwischen der Bekanntgabe einer Sicherheitslücke und der Bereitstellung des offiziellen Patches. In komplexen SAP-Umgebungen können Test- und Transportfenster diese Zeitspanne auf Wochen oder Monate verlängern.

Um dieses Fenster zu schließen, muss ein threat intelligence Schutz vor der Installation des Patches. Dies beinhaltet den Einsatz von „Ausgleichskontrollen“, um das System zu sichern, während der Patch validiert wird.

• Verhaltensüberwachung: Anstatt auf die Behebung des Codes zu warten, überwachen Sie das spezifische Verhalten, das ein Angreifer nutzen würde, um die Schwachstelle auszunutzen. Wenn eine Schwachstelle beispielsweise einen bestimmten böswilligen Aufruf einer RFC-Schnittstelle beinhaltet, sollte das System sofort eine Warnung ausgeben, sobald dieses Aufrufmuster erkannt wird.
• Virtuelles Patching: Moderne Plattformen können schlanke Überwachungsregeln implementieren, die Exploit-Versuche auf Netzwerk- oder Anwendungsebene erkennen und blockieren, ohne dass ein Neustart des Systems erforderlich ist. Dadurch gewinnt das Basis-Team die nötige Zeit, um den offiziellen SAP-Sicherheitshinweis zu testen, ohne das Unternehmen einem Risiko auszusetzen.

Schritt 3: SOC-Integration (Abbau von Silos)

In der Vergangenheit waren SAP-Sicherheitsdaten in einem Silo isoliert. Basis-Teams überwachen technische Protokolle auf Leistungsprobleme, während das zentrale Security Operations Center (SOC) Endgeräte und Netzwerke überwacht. Diese Diskrepanz führt dazu, dass das SOC Angriffe, die innerhalb der ERP-Anwendungsschicht stattfinden, oft nicht erkennt.

Eine moderne Lösung schließt diese Lücke, indem sie SAP threat intelligence in die SIEM- oder platform des Unternehmens einspeist.

Die Kraft des Kontexts

Durch die Integration können Analysten unterschiedliche Signale zu einem vollständigen Bild des Angriffs zusammenführen.

• Ohne Zusammenhang: Das SOC sieht, dass sich ein Benutzer über ein VPN anmeldet. Das Basis-Team sieht, dass ein Benutzer Code debuggt. Für sich genommen wirkt beides nicht verdächtig.
• Mit Integration (z. B. Microsoft Sentinel): Das SIEM korreliert diese Ereignisse und stellt fest, dass sich ein Benutzer von einem ungewöhnlichen Standort aus angemeldet und sofort mit dem Debuggen von Produktionscode begonnen hat. Dies löst einen hochpräzisen Alarm wegen „verdächtiger Rechteerweiterung“ aus, sodass der Analyst das Konto sofort sperren kann.

Durch die Zusammenführung dieser Perspektiven machen Unternehmen die SAP-Sicherheit von einer Nischenangelegenheit zu einem zentralen Bestandteil ihrer Unternehmenssicherheitsstrategie.

Schritt 4: Rollendefinition und Governance

Ein erfolgreiches threat intelligence erfordert klare Zuständigkeiten. In vielen Unternehmen befindet sich die SAP-Sicherheit in einer „Grauzone“ zwischen dem Basis-Team (zuständig für den Betrieb) und dem Büro des CISO (zuständig für das Risikomanagement). Diese Unklarheit führt zu Lücken, die Angreifer ausnutzen.

Um ein widerstandsfähiges Programm aufzubauen, müssen Sie konkrete Zuständigkeiten in drei zentralen Bereichen festlegen:

1. Das Basis-Team (Betrieb)

• Schwerpunkt: Systemverfügbarkeit und -leistung.
• Sicherheitsrolle: Installation von Patches, Konfiguration von Parametern und Verwaltung technischer Benutzer. Diese Personen setzen Sicherheitsänderungen um, sollten jedoch nicht allein für die Erkennung komplexer Bedrohungen verantwortlich sein.

2. Das Sicherheitsteam (SOC & InfoSec)

• Schwerpunkt: Erkennung von Bedrohungen und Reaktion auf Vorfälle.
• Sicherheitsrolle: Überwachung von Warnmeldungen, Untersuchung von Anomalien und Festlegung der Sicherheitsstrategie. Sie übernehmen die Aufsicht und benötigen Einblick in die SAP-Ebene, um ihre Aufgaben effektiv erfüllen zu können.

3. Der CISO (Governance)

• Schwerpunkt: Risikomanagement und Compliance.
• Sicherheitsrolle: Festlegung der Richtlinie für „akzeptables Risiko“. Der CISO muss sich bewusst sein, dass SAP nicht nur eine IT-Ressource, sondern eine geschäftskritische Funktion ist. Er genehmigt das Budget für Tools, die die Lücke zwischen Basis und Sicherheit schließen.

Hinweis zu SAP RISE: Wenn Sie auf die cloud umsteigen, entwickeln sich diese Rollen weiter, verschwinden aber nicht. Im Rahmen des Modell der geteilten Verantwortungverwaltet SAP die Infrastruktur, doch Sie bleiben voll verantwortlich für die Sicherung Ihrer Daten, Benutzer und Anwendungslogik.

Fazit: Erfolgsmessung

Der Aufbau eines threat intelligence ist ein Weg, der von reaktiver Brandbekämpfung hin zu proaktivem Management führt. Der ultimative Maßstab für den Erfolg ist nicht die Anzahl der installierten Patches, sondern die Verringerung des Risikos.

Weltklasse-Unternehmen erfassen folgende Kennzahlen:

• Durchschnittliche Behebungszeit (MTTR): Wie schnell können Sie eine kritische Sicherheitslücke nach ihrer Bekanntgabe schließen?
• Erfassungsgrad: Wie viel Prozent Ihrer geschäftskritischen Ressourcen (einschließlich Nicht-Produktionssysteme) werden in Echtzeit überwacht?
• Falsch-Positiv-Rate: Sind Ihre Warnmeldungen präzise genug, um vom SOC als Handlungsgrundlage genutzt werden zu können?

Durch die Umsetzung dieser Schritte verwandeln Sie die SAP-Sicherheit von einer isolierten technischen Aufgabe in einen strategischen Geschäftsfaktor.

Häufig gestellte Fragen (FAQ)

Brauchen wir ein spezielles SAP-Sicherheitsteam, um dieses Programm durchzuführen?

Nicht unbedingt. Zwar verfügen große Unternehmen oft über eigene SAP-Sicherheitsarchitekten, doch eine moderneplatform darauf ausgelegt, dieses Wissen allgemein zugänglich zu machen. Indem sie komplexe SAP-Protokolle in standardisierte Sicherheitswarnungen umwandelt, ermöglicht sie es Ihren bestehenden SOC-Analysten oder Ihrem allgemeinen Sicherheitsteam, SAP zu überwachen, ohne dass dafür fundierte Kenntnisse in ABAP oder Basis erforderlich sind.

Wie schwierig ist es, SAP-Daten in unser SIEM-System (z. B. Splunk oder Sentinel) zu integrieren?

Die Integration ist dank zertifizierter Konnektoren in der Regel unkompliziert. Führende Plattformen wie Onapsis bieten vorgefertigte Integrationen für Microsoft Sentinel, Splunk und ServiceNow an. Diese Konnektoren ordnen SAP-Ereignisfelder automatisch den Standarddatenschemata Ihres SIEM-Systems zu, sodass Sie bereits wenige Stunden nach der Bereitstellung mit der Datenkorrelation beginnen können.

Ersetzt dieses Programm unser jährliches SAP-Audit?

Nein, es ergänzt diese. Ein Audit ist eine punktuelle Überprüfung, um gegenüber den Aufsichtsbehörden die Einhaltung der Vorschriften nachzuweisen. Ein Threat Intelligence bietet eine kontinuierliche Überwachung, um Angreifer abzuwehren. Man braucht beides. Tatsächlich lässt sich durch ein Programm zur kontinuierlichen Überwachung das jährliche Audit oft schneller und kostengünstiger durchführen, da historische Daten sofort verfügbar sind.

Wir nutzen SAP RISE. Kümmert sich SAP darum für uns?

Nein. SAP schützt zwar die cloud (die Server), überwacht jedoch weder Ihre spezifischen Benutzeraktivitäten noch die Konfigurationen Ihrer Geschäftslogik. Wenn ein legitimes Benutzerkonto kompromittiert wird und der Download sensibler Personaldaten beginnt, erkennen die Tools von SAP dies als autorisierten Datenverkehr. Sie sind dafür verantwortlich, diese Anomalie zu erkennen.

Wie gehen wir mit „falschen Alarmen“ im SAP-Alarmsystem um?

Der Schlüssel liegt in der Festlegung von Referenzwerten. Ein generisches Tool würde möglicherweise jedes Mal eine Warnung auslösen, wenn ein Benutzer einen kritischen Transaktionscode (wie SM20) ausführt. Ein ausgereiftes Programm lernt das „normale“ Verhalten Ihrer Administratoren kennen. Es löst nur dann eine Warnung aus, wenn diese Transaktion zu einer ungewöhnlichen Zeit, von einem ungewöhnlichen Standort aus oder von einem Benutzer ausgeführt wird, der diese Aufgabe nur selten ausführt.