Suchen

Administration von SAP-Umgebungen, Teil 2 Patch-Prozess als Risikofaktor für SAP

| Autor / Redakteur: Gerhard Unger* / Stephan Augsten

SAP-Systeme sind unsicher, obwohl SAP, Entwickler und Berater aktiv gegensteuern. Patches gibt es zuhauf, doch selbst bei bekannten Sicherheitslücken kann es dauern, bis ein Patch wirklich implementiert wird. Die Gründe dafür sind vielfältig.

Zeitbombe: Viel Administratoren warten zu lange, bis sie einen SAP-Patch einspielen.
Zeitbombe: Viel Administratoren warten zu lange, bis sie einen SAP-Patch einspielen.
(Bild: Archiv)

Etliche Faktoren haben Einfluss auf die Verwundbarkeit von SAP-Systemen: Die Komplexität der Implementierung, das historische Wachsen von Landschaften oder auch die relativ unkomplizierte, aber oft folgenreiche Konfiguration von Parametern durch Setzen von Tabellenwerten. Das Ergebnis ist bedenklich.

Fast alle Systeme halten einer strengen Sicherheitsprüfung nicht stand, obwohl in vielen Fällen Patches für Schwachstellen schon lange verfügbar sind. Der prominente Fall von Nvidia Anfang 2014 hat das Problem vor Augen geführt. Hier hatte ein Hacker eine Schritt-für-Schritt-Anleitung zur Ausnutzung einer bereits bekannten SAP-Sicherheitslücke ins Netz gestellt.

Nvidia reagierte schnell und schloss die Lücke. Die auf SAP Netweaver basierende Nvidia-Care-Webseite https://nvcare.nvidia.com musste aber vorübergehend vom Netz genommen werden. Nach Umfragen von IDC wären Angriffe bei korrektem Patching in 75 Prozent aller Fälle abzuwenden gewesen.

Die meisten Administratoren patchen selten

Das Problem sind dabei nicht die nicht vorhandenen Patches. Es gibt genug davon, ja, fast schon zu viele. Seit 2009 wurden 3.242 Security Notes veröffentlich. Ihren derzeitigen Höhepunkt erreichte diese Welle dabei in den Jahren 2011 mit 731 und im Folgejahr mit 835 Patches. Seitdem sinkt zwar die Zahl, aber auch 2014 wurden 391 Notes veröffentlicht, davon 46 Prozent High-Priority-Risiken.

Viele dieser Lücken betrafen auch Drittanbieter-Lösungen. Zudem ist jeder Patch für sich genommen bei der Implementierung keine kurze Security Note, sondern ein komplexes, zeit- und kostenintensives Problem. Denn Patches betreffen das Setzen von Parametern (rund 1.500 pro Server können betroffen sein), die Sicherung der Transportschicht, manchmal sogar Änderung des Codes.

Auf einer komplexen, historisch gewachsenen und individuell implementierten oder auch auf Kundenwünsche angepassten Plattform bedeutet das viel Arbeit und Zeit. Bei Fehlern entstehen vielleicht sogar neue Probleme. Der Rhythmus der Einspielung von Security Patches ist entsprechend darauf ausgerichtet. So dauert es im Schritt ein halbes Jahr, bis ein neuer Patch implementiert wird.

Uns liegen Aussagen von Verantwortlichen vor, die aus Zeitmangel gar nicht mehr patchen – oder mitunter nur einmal im Jahr. Vorbildliche Administratoren werden viermal im Jahr aktiv, also einmal pro Quartal. Selbst hier zeigt sich aber bereits ein gewisser Mut zur Lücke.

(ID:43182058)