Jeden zweiten Dienstag im Monat veröffentlicht SAP neue Sicherheitshinweise. Für viele Teams beginnt damit dieselbe Diskussion: Welche Notes müssen sofort eingespielt werden, welche können warten und wer entscheidet das eigentlich?

Warum der Patch Day so viele Teams überfordert

In den meisten SAP Landschaften scheitert Patch Management nicht an der Technik, sondern an drei strukturellen Punkten:

• Die Zuständigkeit ist unklar. SAP Basis kennt die Systeme, Security kennt die Bedrohungslage, der Fachbereich kennt die Prozesse. Solange niemand formal entscheidet, entscheidet der Kalender.
• Die Menge ist zu groß für Einzelfallprüfung. Bei 20 bis 35 Hinweisen pro Monat über mehrere Systemlinien hinweg ist eine vollständige manuelle Bewertung nicht leistbar. Ohne Filterlogik bleiben Hinweise liegen.
• Wartungsfenster sind knapp. Produktive ERP Systeme lassen sich nicht beliebig oft neu starten. Wenn jeder Patch auf das nächste reguläre Fenster wartet, entsteht ein Rückstand, der über Monate wächst.

Das Ergebnis kennen wir aus vielen Erstgesprächen: Die Systeme sind gepatcht, aber niemand kann belegen, welche kritischen Hinweise offen sind und warum.

Was der CVSS Score aussagt und was nicht

Der CVSS Score ist ein guter Ausgangspunkt und eine schlechte Entscheidungsgrundlage.

Er beschreibt die technische Schwere einer Schwachstelle unter Standardbedingungen. Er weiß nichts über Ihre Landschaft. Eine Lücke mit CVSS 9,8 in einer Komponente, die Sie gar nicht einsetzen, ist irrelevant. Eine Lücke mit CVSS 6,5 in einem System, das über das Internet erreichbar ist und Zahlungsdaten verarbeitet, kann Ihr dringendstes Problem sein.

Belastbar wird die Priorisierung erst, wenn Sie vier Faktoren zusammenführen:

1. Technische Schwere: CVSS Score und SAP Einstufung, also HotNews, High, Medium oder Low.
2. Exponierung: Ist das System aus dem Internet erreichbar? Hängt es an einem Partnernetz? Läuft es rein intern?
3. Geschäftskritikalität: Welche Prozesse stehen still, wenn das System kompromittiert oder ausgefallen ist?
4. Ausnutzbarkeit im Ist Zustand: Ist die betroffene Komponente überhaupt aktiviert? Existieren kompensierende Kontrollen wie Netzsegmentierung, restriktive Berechtigungen oder ein aktives Monitoring?

Erst diese Kombination ergibt eine Risikoeinschätzung, die Sie im Change Advisory Board und im Audit vertreten können.

Eine Priorisierungsmatrix, die im Alltag funktioniert

Die folgende Einteilung hat sich in Kundenprojekten bewährt. Sie ist bewusst einfach gehalten, weil komplexe Modelle im Tagesgeschäft nicht angewendet werden.

Der entscheidende Punkt ist die letzte Zeile. Ein dokumentierter und begründeter Ausschluss ist kein Versäumnis, sondern eine Entscheidung. Ein undokumentierter offener Hinweis ist ein Befund.

Der Patch Day Prozess in fünf Schritten

Schritt 1: Systeminventar aktuell halten

Sie können nur bewerten, was Sie kennen. Notwendig sind eine gepflegte Übersicht über alle Systeme, Releases, Support Package Stände, aktivierte Komponenten und Schnittstellen. Ohne dieses Inventar ist jede Priorisierung Schätzung.

Schritt 2: Vorfilterung am Veröffentlichungstag

Gleichen Sie die neuen Hinweise gegen Ihr Inventar ab. In der Praxis fallen dabei häufig mehr als die Hälfte der Notes weg, weil die betroffene Komponente nicht im Einsatz ist. Halten Sie diesen Abgleich schriftlich fest.

Schritt 3: Bewertung der verbleibenden Hinweise

Wenden Sie die Matrix an. Für P1 und P2 Fälle gehört eine kurze fachliche Einschätzung dazu: Was kann ein Angreifer konkret tun und welche Kontrollen greifen bereits?

Schritt 4: Umsetzung mit Testnachweis

Einspielen im Entwicklungssystem, funktionaler Test, Transport über die Qualitätssicherung, danach Produktion. Bei P1 Fällen mit verkürztem, aber nicht ausgelassenem Testpfad. Ein Hinweis, der die Produktion stört, kostet mehr als die Schwachstelle, die er schließt.

Schritt 5: Nachweis und Rückblick

Dokumentieren Sie pro Monat, welche Hinweise eingespielt, verschoben oder ausgeschlossen wurden. Diese Liste ist Ihr Nachweis gegenüber Wirtschaftsprüfung, interner Revision und im Rahmen von NIS2 oder ISO 27001.

Wer diesen Zyklus einmal etabliert hat, braucht dafür monatlich in der Regel einen halben bis einen Personentag statt der oft befürchteten Wochen.

Fünf Fehler, die wir regelmäßig sehen

1. Nur HotNews werden bearbeitet. Angreifer verketten Schwachstellen. Eine Information Disclosure mit CVSS 6,5 liefert die Zugangsdaten, mit denen die nächste Lücke ausnutzbar wird. Mittlere Einstufungen dauerhaft zu ignorieren, erzeugt genau diese Ketten.
2. Patches ohne Konfiguration. Viele SAP Hinweise wirken erst, wenn zusätzlich ein Profilparameter gesetzt, ein Dienst deaktiviert oder eine Berechtigung angepasst wird. Der Hinweistext beschreibt das, wird aber häufig nur überflogen. Der Patch ist dann eingespielt und die Lücke trotzdem offen.
3. Entwicklungs und Testsysteme bleiben außen vor. Sie enthalten oft produktive Datenkopien, sind schwächer abgesichert und dienen als Sprungbrett in die produktive Landschaft.
4. SAP eigene Prüfwerkzeuge werden nicht genutzt. Der Konfigurationsvalidierung im SAP Solution Manager, der System Recommendations Funktion und dem EarlyWatch Alert entnehmen Sie einen großen Teil der Ausgangsdaten, ohne zusätzliche Lizenzkosten.
5. Keine Verbindung zum Monitoring. Solange ein Hinweis offen ist, sollte das betroffene System engmaschiger beobachtet werden. Wer Patch Management und SAP Security Monitoring getrennt betreibt, verliert genau in der Übergangszeit die Sicht.

Wo Automatisierung wirklich hilft

Manuelle Priorisierung stößt schnell an ihre Grenzen. Sobald mehrere Systemlinien, unterschiedliche Releasestände und ein wachsender Bestand offener Hinweise zusammenkommen, kostet allein der Abgleich mit dem tatsächlichen Systemstand mehr Zeit als die eigentliche Umsetzung. Mit passend eingerichteten Werkzeugen sparen Sie hier erheblichen Aufwand, und zwar an einer bestimmten Stelle: nicht beim Einspielen, sondern bei Inventar, Abgleich und Nachweis.

Ein zentrales SAP Schwachstellenmanagement gleicht neue Hinweise automatisch gegen den tatsächlichen Systemstand ab, bewertet sie anhand Ihrer eigenen Kritikalitätsvorgaben und erzeugt den Nachweis, den Sie im Audit ohnehin brauchen. Der Zeitgewinn entsteht durch die entfallende Vorfilterung, nicht durch automatisches Patchen. Automatisches Patchen in produktiven ERP Systemen empfehlen wir bewusst nicht.

Wenn Sie den gesamten Zyklus nicht selbst betreiben möchten, übernehmen wir Bewertung, Umsetzung und Dokumentation als Managed Service für SAP Sicherheit. Wie die Werkzeugseite aussieht, zeigen wir auf unserer Seite zum SAP Schwachstellenmanagement sowie im Praxisratgeber zum SAP Vulnerability Management.

Häufige Fragen zu SAP Security Notes

Fazit

SAP Security Notes sind kein Wartungsthema, sondern ein Steuerungsthema. Die technische Umsetzung ist selten das Problem. Das Problem entsteht dort, wo Zuständigkeit, Bewertungslogik und Nachweisführung fehlen.

Drei Dinge machen den Unterschied: ein gepflegtes Systeminventar, eine einfache und verbindliche Priorisierungsmatrix und eine monatliche Dokumentation der getroffenen Entscheidungen. Mit dieser Grundlage wird aus dem Patch Day ein planbarer Prozess statt einer wiederkehrenden Ausnahmesituation.