Aufgeräumte Spielzeugkiste gibt Sicherheit

Sicherheit in all ihren Facetten ist bei der DZ BANK ein großes Thema. Ein Cyber-Security-Operations-Center bildet die Kontrollinstanz zwischen den einzelnen „Verteidigungslinien“. Aber diese Sicherheit hat ihren Preis. Aufräumarbeiten, teilweise weniger Komfort, dafür mehr Aufwand warten auf dem Weg zur umfassenden IT-Security und müssen bewältigt und akzeptiert werden.

Viele Banken kämpfen mit dem Erbe ihrer IT-Architekturen. Prozessorientierung, Skalierbarkeit, Flexibilität, Modularisierung und Service-Fähigkeit sind die Anforderungen an die moderne IT-Architektur. Auch die IT-Sicherheit und regulatorische Compliance werden dabei immer wichtiger. Die zunehmende Vernetzung und Professionalität der Angriffe auf die Infrastrukturen sind durchaus alarmierend. Es ist ein permanenter Wettlauf, von dem die Kunden erwarten, dass eine Bank ihn jeden Tag aufs Neue gewinnt.

Die DZ BANK kommt aus einer Welt, in der alle SAP-Systeme in einer einzigen Netzwerkzone angesiedelt waren. Zu der Zeit war SAP-Security noch kein Thema. Das änderte sich 2018, als sich die IT-Abteilung umorganisierte. „Wir haben ein Cyber-Security-Operations-Center (CSOC) aufgebaut, sozusagen als Kontrollinstanz zwischen der ersten und zweiten Verteidigungslinie“, erläutert Johannes Rumpf, SAP-Security-Spezialist bei der DZ BANK. Die erste Verteidigungslinie bilden die SAP-Cross-Applications (ehemals SAP Basis) und die zweite die Informationssicherheit. Als dritte dient die Konzern- und Außenrevision. Zudem wurden professionelle Penetrationstests eingekauft, um zusätzlich einen anderen Blickwinkel auf das System zu haben, wie ihn z. B. eine Innenrevision bietet.

Wichtige Aufräumaktion

So wurde eine Sicherheitshistorie basierend auf den technischen Netzwerkzonierungsmöglichkeiten, den Berechtigungsthemen und der Systemparametrisierung aufgebaut und unter der Leitung des CSOC in ein Projekt gegossen. Da es keine Richtlinien gab, wurde anhand von allgemein anerkannten Empfehlungen und Vorschriften geprüft. Es war der erste Schritt zu einer dringend notwendigen Aufräumaktion. Denn ein klassisches SAP-System, das im Schnitt zwischen 20 und 30 Jahren betrieben und regelmäßig mit Upgrades und Updates erweitert wird, gleicht einer Spielzeugkiste im Kinderzimmer.

„Irgendwer hat die Kiste rausgeräumt, damit gespielt und sie dann stehen lassen. Wenn es dann ans Aufräumen geht, will es keiner gewesen sein“, erklärt Johannes Rumpf. Dabei sind einige zentrale Fragen zu beantworten: Wie aufgeräumt ist ein System? Wie sind die Zuständigkeiten geklärt? Wem gehören welche Tabellen, wer hat welche Berechtigungen, wo sind die fachlichen und technischen Schnittstellen? „Wenn man da die Antworten kennt, ist das eine gute Sache. Wir sind aktuell noch dabei, hier Klarheit zu schaffen“, berichtet Johannes Rumpf.

Weniger Komfort, mehr Aufwand

Aktuell sind der SAP-Security-Spezialist und seine Kollegen an vielen Stellen aktiv, um die notwendigen Sicherheitsmaßnahmen umzusetzen. Wenn Berechtigungen für Tabellen entzogen werden oder geklärt wird, wer darauf zugreifen darf, sinkt der Arbeitskomfort. Gleichzeitig steigt der Aufwand. Auch müssen in einem neuen Projekt erst mittels eines Funktions-Firewall-Antrags sämtliche benötigten Funktionsbausteine freigeschaltet werden. Das ist z. B. bei SAP UCON (Unified Connectivity) der Fall, einem Tool, das gegen Angriffe über Remote-Function-Call-Schnittstellen (RFC) schützt.

Interne Kommunikation verschlüsseln

Ein weiterer Aspekt ist die verschlüsselte Kommunikation. Wenn nur noch diese erlaubt sein soll, muss früh überlegt werden, wie die Systeme miteinander kommunizieren und ob das auf derselben Verschlüsselungsebene geschieht. Kommen die Beteiligten aus einer Welt, in der verschlüsselte Kommunikation untypisch war, ist der Aufwand für das Security-Grund-Setup erst mal höher. „Viele verstehen nicht, warum sie im Firmen-Netzwerk verschlüsselt miteinander reden sollen. Aber auch firmenintern kann abgehört werden, und daher ist grundsätzlich zu verschlüsseln“, erläutert Johannes Rumpf.

Sicherheit ist auch Mentalitätssache

Vieles im Sinne der Sicherheit ist auch eine Sache der Mentalität. Falls diese nicht stimmt, kann das unaufgeräumte „IT-Kinderzimmer“ sehr schnell zur größten Herausforderung werden. „Security-by-Default bedeutet, sich mit den Prinzipien der Berechtigungen auseinandersetzen und sich an gewisse Prozesse anpassen und seine Arbeitsweise ändern zu müssen. Das führt hier und da schon zu Widerständen“, weiß Johannes Rumpf.

Geschäftsführung entscheidet über Ausstattung

Im Risiko-Management, der „zweiten Abwehrreihe“ in der IT, hat sich in den letzten Jahren einiges getan. „Die Kollegen haben anfangs nur Konzernrichtlinien veröffentlicht. Diese werden mittlerweile auch in SAP-spezifische Richtlinien übersetzt“, erläutert Johannes Rumpf. Zudem bewerten sie das, was nicht umsetzbar ist, und die damit verbundenen Risiken in Euro. Am Ende entscheidet die Geschäftsführung, wie stark sie die Security mit Geldmitteln ausstattet. Denn in den letzten Jahren haben sich die regulatorischen und gesetzlichen Anforderungen im Bankenumfeld deutlich verschärft.

Dafür braucht es Ansätze und Lösungen. Nach einem klassischen Emergency-Konzept im SAP-Umfeld besitzt ein User das Passwort für eine Maximalberechtigung im Systemnetz. Für Johannes Rumpf ein weit verbreiteter, aber veralteter Ansatz. Es braucht eine durchdachte Rechteeskalation um zu klären, was mit all den kritischen Berechtigungen passieren soll. Steht z. B. ein System, und es kommt zu Produktionsproblemen, muss mit maximaler Berechtigung agiert werden können. Zudem gilt es zu regeln, wenn die Unterstützung eines Entwicklers für das Produktivsystem oder externer Support benötigt wird, der im System keinen User-Zugang hat. Für diese Fälle sollte ein System automatisiert beobachtet werden können. „Das sollte nur nach dem Vier-Augen-Prinzip erfolgen. Das wiederum ist aber nur umsetzbar, wenn es auch entsprechend viele Administratoren gibt. Falls nicht, muss das System selbst das zweite Augenpaar sein“, fasst Johannes Rumpf zusammen.

Risikoabwägung beim Support

In Sachen Sicherheit bei der DZ BANK war SAP vor allem mit Consulting-Leistungen bei der Einrichtung von SAP Governance, Risk and Compliance und beim Thema Support aktiv. In diesem weiten Umfeld mussten mit SAP einige zentrale Punkte diskutiert werden. Wie funktioniert der SAP-Support-Fall? Welche Berechtigungen benötigt bzw. erhält SAP, um auf das System zuzugreifen? Für Johannes Rumpf ein wichtiger Punkt. „Wenn wir für SAP eine Verbindung aufmachen, brechen wir quasi ein Loch in unsere Firewall. Und richten wir einen anonymen User ein, ist nie klar, welcher der zigtausend SAP-Support-Mitarbeitenden letztendlich auf das System zugreift.“ In diesem Fall ist das eine Risikoabwägung. Einen User mit echtem Namen anzulegen, wäre zeitlich sehr aufwendig. Daher muss das Risiko durch einen anonymen User akzeptiert werden. Dann bleibt immer noch die Möglichkeit zu kontrollieren, was der Kollege konkret im System gemacht hat.

Nützlich aus Sicht von Johannes Rumpf wäre eine Zentralisierung von Protokolldateien (Logs). „Wenn z. B. das Application-Log, das Table-Change-Log und das Gateway-Log direkt auf einen Sys-Log-Server übertragbar wären und ohne Zwischenspeicherung in einer Datei wieder ausgeben werden könnten, wäre das sehr hilfreich“, richtet der Security-Spezialist einen Appell an SAP. Und schickt einen weiteren Wunsch hinterher. „In Bezug auf Security-by-Default wäre eine wesentlich höhere Grundsicherung wünschenswert. Da könnte noch vieles besser werden.“

Es ist also noch nicht alles sicher, was glänzt. Daher lohnt es sich, das Thema konsequent anzugehen bzw. voranzutreiben. Dementsprechend empfiehlt Johannes Rumpf: „Verschaffen Sie sich einen kompletten Überblick, mit welchen Risiken das eingesetzte System konfrontiert ist, wie gut es aufgestellt ist und welche finanziellen Konsequenzen drohen, wenn eine vorhandene Lücke ausgenutzt wird.“ Dann macht es gleich viel mehr Spaß, mit der Spielzeugkiste zu spielen.

Bildnachweis: iStock, DZ Bank AG