IT-Security: Supereinfach oder superschwer

Spätestens seit der 2007 auf der Blackhat-Konferenz vorgestellten Gateway-Schwachstelle (vgl. VIDEO) hat sich die Wahrnehmung für SAP-Sicherheit nachhaltig geändert. Über diese Schwachstelle kann ein Angreifer ohne Authentifikation sich auf SAP-ERP- und Abap-Systemen einen Administratornutzer mit „SAP_ALL“-Berechtigungen anlegen.

Anschließend hat der Angreifer die volle Kontrolle und kann beliebige Daten einsehen und manipulieren. Trotz dessen, dass diese Schwachstelle so lange bekannt ist, sind viele ERP-Kunden auch 2019 noch gegen sie und viele andere Standardschwachstellen anfällig. Woran liegt das?

SAP-Sicherheitshinweise lassen sich nicht direkt mit Microsoft-Windows-Sicherheitsupdates vergleichen, weil SAP in der Abap-Welt dem Prinzip der Abwärtskompatibilität folgt. In der Folge liefert SAP immer einen Schalter in den Hinweisen mit aus, wenn ein Risiko besteht, dass der Patch die bestehende Funktionalität oder Verfügbarkeit beim Kunden gefährdet.

Das alleinige Einspielen reicht folglich in diesen Fällen nicht aus, sondern der Kunde muss zur Aktivierung erst anschließend die manuellen Schritte durchführen. Häufig benötigen gerade die kritischen Schwachstellen diese manuelle Nacharbeit und führen so unbewusst zu unsicheren Systemen. So ist dies ebenfalls bei der exemplarischen Gateway-Schwachstelle der Fall, gegen die noch immer eine Vielzahl von Kundensystemen verwundbar ist.

SAP hat im Jahr 2009 die Sicherheitsstrategie geändert und seitdem 4256 SAP-Sicherheitshinweise veröffentlicht, davon über 50 Prozent in den Jahren 2010 bis 2012. Aussagen auf einer TechEd zufolge hat SAP damals erstmals den kompletten SAP-Standard mit statischer Code-Analyse untersucht, was mit zur obigen Häufung geführt haben soll.

2010 wurde dann der „SAP Security Patchday“ am zweiten Dienstag eines Monats eingeführt. Hierdurch werden die Hinweise primär nur noch gebündelt veröffentlicht. Ab 2012 wurde eingeführt, dass Security-Hinweise nur noch in Abhängigkeit von Ihrer Priorität mit Support Packages ausgeliefert werden.

Dringend zu beachten ist hierbei die 18-Monate-Regel: Nach dieser wird das Einspielen von Security-Hinweisen nur in Systemen garantiert, die auf einem Support-Package-Level sind, der nicht älter als 18 Monate ist. Jeder Kunde benötigt daher zusätzlich zu einem SAP-Security-Patch-Zyklus einen regelmäßigen Support-Package-Einspielzyklus.

Während in einer einstufigen SAP-Systemlandschaft eine Überwachung der Hinweise, Konfigurationen und Support-Package-Level noch manuell möglich ist, wird dies in großen und heterogenen SAP-Landschaften zunehmend schwerer bis unmöglich. Hier bietet es sich an, diese Aufgaben mit einem Automaten zu überwachen. Sowohl die SAP als auch der freie Markt bieten hier diverse Lösungen an.

Sind diese Herausforderungen 2019 mit S/4 und Hana gelöst? In der Cloud führt SAP die Infrastrukturwartung durch, allerdings hat der Kunde hier keinen SAP-GUI-Zugriff mehr und kann keine Eigenentwicklungen im Kernsystem durchführen.

Auf den Kunden kommen hier neue Herausforderungen in hybriden Architekturen zu. Häufig ist mit der wachsenden Komplexität nicht klar, wo, wie häufig, welche Daten gespeichert werden und wer darauf Zugriff hat.

Das gilt insbesondere dann, wenn die Fachabteilung mit einer Kreditkarte zusätzliche Services freischalten kann, von denen die IT erst einmal nichts mitbekommt. Kunden, die S/4 als on-premise nutzen, müssen weiterhin die oben genannten Themen beachten.

Auch 2019 muss ein aktuelles S/4 1809 nach der Installation gehärtet werden. Beispiele sind das im Standard nicht aktivierte Security Audit Log, der nicht aktivierte Schutz gegen RFC-Call-Back-Angriffe oder die seit 1992 ausgelieferte Passwortmindestlänge von lediglich 6 Zeichen.

Als Fazit für 2019 bleibt, dass der Kunde für die Sicherheit seiner Daten selbst verantwortlich ist und das auch bleiben wird. In den vergangenen Jahren gab es jedes Jahr kritische Schwachstellen im SAP-Standard.

Daher ist es weiterhin erforderlich, seine SAP-Systeme zeitnah zu patchen und das Einspielen zu überwachen. Das gilt für genutzte als auch ungenutzte Komponenten.