[Datenschleuder] [64]    Deutsche Banken

Deutsche Banken ...im Internet-Zeitalter Vertrauen ist der Anfang von Allem. Diesen Slogan benutzt die Deutsche Bank schon seit langem nicht mehr. Mit dem Jahr 2000 vor der Tür und dem Euro-Problem vor der Nase will sich auch innerhalb der Deutschen Bank nicht so recht Vertrauen einstellen. Sollte sich das Bewußtsein, daß Ihr Geld nur Bytes auf schlecht konfigurierten, nur von Software der Modernitätsklasse "COBOL '68 in wurmzerfressenen Lochkartenstapeln" zusammengehaltenen Datenbanken auf jahrzehntealten Bitfräsen sind, zu den Kunden durchschleichen, könnten die Geschäftssausichten der Geldhäuser deutlich sinken. Daß sein schwer errungenes Vermögen eigentlich nur noch existiert, weil die Backupstrategien bisher nicht in größerem Umfang versagt haben, ist dem normalsterblichen Häuslebauer schwer beizubringen. Die Banken haben schließlich gelernt. Nachdem die ersten wirklichen Probleme aufgetreten waren, haben Schnelldrucker in den Kellerräumen Einzug gehalten, auf denen alle Transaktionen auf Papier gebackupt werden. In IBMs Terminologie sind das dann Quaternär-Speicher. Wie die dazugehörigen einhundert studentischen Datenerfassungsexperten zum Wiedereintippen in IBM-Terminologie heißen, war bisher nicht zu ermitteln. Die armen Banken sind ja auch gebeutelt. Nachdem sie die Jahr-2000-Problematik einige Jahre lang einfach ignoriert haben ("wir haben ja noch genügend Zeit"), und jetzt plötzlich und unerwartet die Euro-Problematik auf die Banken zukam, gibt es jetzt auch noch unerwünschte Presseberichte zum Thema "Sicherheit des Onlinebankings". Mit häßlichen Worten wie "Virus" und "Trojanisches Pferd" wird doch nur wieder Verunsicherung in die Kunden hineingeredet, so der Branchentenor. Erstaunlich einig ist sich die Branche darin, daß man jetzt Personal einstellen muß, weil die veranschlagte Personaldecke nicht ausreichend dimensioniert ist. Der Markt für qualfiziertes EDV-Personal ist aber leergefegt. Wenn eine Bank heute Bank-Software kaufen möchte, bekommt sie von allen Anbietern ein müdes Lächeln und die Aussage, daß in diesem Jahr da sicher nichts mehr zu machen sei. Man wäre schon froh, wenn man bei den größeren Stammkunden die Euro-Problematik fristgemäß gelöst bekäme. Zusätzlich werden die Banken gerade auch an einer anderen Front beschossen: ein Gerichtsurteil hat die Beweislast bei EC-Karten-Problemen umgekehrt (siehe Artikel in dieser Ausgabe). Der Hoffnungsträger der Branche, das Onlinebanking, sieht auch nicht viel stressfreier aus. HBCI ist die Antwort des ZKA zum Thema "Sicherheit vom Online-Banking". Das ZKA ist der "Zentrale Kreditausschuß", sozusagen das Politbüro der Branche. Hier werden Inter-Banken-Angelegenheiten geklärt. HBCI ist der Versuch des ZKA, einen bankenunabhängigen Standard für sichere Online-Transaktionen zu schaffen. Von allen technisch mit der Umsetzung von HBCI befassten Leuten hört man dazu nichts als unterdrückte Seufzer und Stoßgebete, die im wesentlichen das baldige Ende des ZKA herbeisehnen. Kennzeichnend für den technischen Weitblick hinter der Spezifikation sind Zitate wie: "wegen der zunehmenden Bedeutung des Internet [wird] neben T-Online auch TCP/IP [berücksichtigt]". Wer etwa versucht, über HBCI Börsen-Transaktionen durchzuführen, wird in den etliche hundert Seiten starken Dokumenten vergeblich nach einem Messaging-Standard für derartiges suchen. Der Standard enthält keinerlei Features, die es wahrscheinlich erscheinen lassen, daß er außerhalb Deutschlands überhaupt wahrgenommen werden wird. Viele der deutschen Banken betrachten mittlerweile das ZKA und die von diesem Komitee entworfenen Projekte (wie z.B. auch die Geldkarte) als geschäftsschädigend. Über eine Integration von HBCI mit international verbreiteten Systemen wie OFX/Gold wird offenbar nur bei Firmen diskutiert, die mit der konkreten Umsetzung der technischen Infrastruktur befaßt sind. Immerhin basiert die Sicherheit von HBCI auf so "zukunftsträchtigen" Algorithmen wie 56-bit DES. Wieviel das ZKA vom Internet versteht und welchen Stellenwert dem zugemessen wird, läßt sich leicht auf deren Web Server unter http://www.zka.de/ betrachten (da läuft übrigens auch ein minderfrisches sendmail). Ein weiterer Hinweis auf die Internet-Kompetenz der HBCI-Macher ist, daß HBCI den Port 3000 benutzt, d.h. Standard-Firewalls, die nur Web-Traffic (Port 80 und 443) herauslassen, und auch nur über den Proxy-Server, werden HBCI-Banking nicht durchführen können. Andere Banken lösen dieses Problem, indem sie Port 443 auf einem Server benutzen, auf dem dort eben kein https- sondern ein Banking-Server läuft. Weiterhin sieht HBCI als Authentisierungsmethode einen Chipkartenleser und/oder eine Diskette mit Geheimdaten vor, auf die Java natürlich nicht betriebssystemübergreifend zugreifen kann. D.h. Online-Banking wird mit HBCI und Chipkarte vorerst nur unter Windows verfügbar sein. Übrigens sei an dieser Stelle betont, daß HBCI noch sehr modern ist! Von allen deutschen Banken machen genau zwei ihr Internet-Banking nicht über einen BTX-Tunnel! So erklären sich auch die "Bitte warten, Verbindung wird aufgebaut" Meldungen in der Statuszeile. Das liegt gar nicht mal daran, daß die Banken so uninteressiert sind, sondern an der generellen Schwerfälligkeit der Geldinstitute. Das zeigt sich unter anderem, wenn man mit Herstellern von Geldautomaten redet, wie z.B. NCR oder IBM. Diese Hersteller zeigen auf den einschlägigen Messen jährlich revolutionäre Neuerungen; Automaten, an denen man auch Kontotransaktionen machen kann, Automaten mit Internet-Zugang, mit Briefmarkenverkauf, mit Biometrik, mit Stimmerkennung. Die Banken-Abgesandten freuen sich immer wieder darüber, machen große Augen, aber gekauft werden solche Automaten frühestens 5-10 Jahre später. Die Banken ersticken einfach in ihrer selbstverursachten Lähmung, verursacht durch Management, Ausschußgründung und Bürokratie, und so ist auch die Euro- und Y2K-Panik jetzt kurz vor Torschluß zu erklären. Und wenn man so marktunfähig, so gelähmt, viel zu hohe Kosten verursacht und im internationalen Vergleich nicht konkurrenzfähig ist, stellt sich die Frage, warum es in Deutschland keine anständigen Banken aus dem Ausland gibt. Die Antwort ist, daß das deutsche Bankengesetz das bisher auf Drängen der Banken hin einfach verboten hat. Wenn man eine neue Bank anmelden möchte, dann macht die zuständige Behörde die Zulassung von der Meinung des ZKA abhängig, wo ja, wie wir schon gesagt haben, die ganzen anderen Banken sitzen. D.h. am Ende bestimmen die anderen Banken, ob sie gerne Konkurrenz haben möchten oder nicht. Allerdings wird sich das im Rahmen der EU ändern. Die Banken werden sich dann auf andere Weise als Monopol versuchen, so wie sie jetzt schon die europäische Niederlassung der NASDAQ, die EASDAQ, boykottieren. Langfristig ist die Lage allerdings vollständig aussichtslos, die deutsche Bank macht auch nicht durch ihre Kunden, sondern durch ihre Immobiliengeschäfte Gewinne. Wer an der Börse spekuliert, sollte sich dringend noch vor dem Jahre 2000 von seinen Bank-Aktien trennen oder deutsche Bank-Aktien sogar shorten oder putten. Um unsere Kritik zu verstehen, muß man einen Einblick in die grausigen Protokolle und Software-Datenhaufen bekommen, mit denen es der durchschnittliche Banker zu tun hat. Leider haben wir es an dieser Stelle mit einer Art Selbstverteidigungsstrategie der Banken zu tun, denn sie legen von ihren Protokollen und Programmen gar nichts offen., "denn Sicherheit ist Vertrauenssache..." (Werbung der TeleSec für ihr Trust-Center, das sie mit dem TÜV zusammen betreiben). Ein gutes Beispiel ist allerdings das SWIFT-Protokoll, mit dem Banken international ihre Überweisungen abwickeln. Für SWIFT kam vor kurzem ein Jahr-2000-fix heraus. Das Protokoll wird normalerweise mit 56-Bit DES verschlüsselt. Ja, genau das 56-Bit DES, das vor kurzem in drei Tagen geknackt wurde und das die US-Regierung jetzt für hinreichend knackbar hält, daß es international für den Export freigegeben wurde. Somit ist die Verbindung des Internet-Kunden, der sich per 128bit-SSL bei seiner Bank einwählt, um die Gasrechnung zu begleichen, rein kryptographisch um den Faktor 2^72 besser geschützt als die internationalen Millionentransfers. Die Deutsche Bank hat beispielsweise in Ihren Kontonummern nicht die kontoführende Filiale kodiert, obwohl das ja wohl eine offensichtliche Funktion wäre. Tatsächlich ist es einem Mitarbeiter nicht möglich, anhand einer Kontonummer zu erkennen, wo er denn genau anrufen soll, wenn ihm die Filiale nicht zufällig bekannt ist. Außerdem war die Software nicht flexibel genug, die Filialen im Osten und Westen Deutschlands zusammenzuführen, also haben bei den deutschen Großbanken Osten und Westen verschiedene Bankleitzahlen. Überhaupt zieht sich das Konzept der Datenbankschlüssel immer wieder durch die Bankensoftware. Banken identifiziert man nicht mit Namen, sondern mit Bankleitzahl. Aktien identifiziert man nicht mit dem Namen, sondern mit der Wertpapierkennnummer. Konten identifiziert man nicht mit dem Namen und dem Geburtstag oder sonstwas, sondern per Kontonummer. Wir bestreiten nicht, daß man Datenbankschlüssel braucht. Aber wieso belästigt man die Kunden damit, solche Schlüssel auswendig zu lernen? Auch zeichnet sich Steinzeitsoftware dadurch aus, daß Felder in der Länge begrenzt werden. So reservierte die Software eben 4 Zeichen Platz für die Postleitzahl (ein weiteres Beispiel für Datenbankschlüssel). Als sich das dann geändert hat, haben die Banken alle ein gewaltiges Problem gehabt, weil sie ihre COBOL-Software fixen mußten und sich das Datenbankschema geändert hat. Und die Konvertierung von Datenbanken von einem Format in ein anderes führt immer eine Downtime mit sich, d.h. Zeit, in der keine Transaktionen durchgeführt werden können. Zwei bayerische Banken zum Beispiel haben sich gerade zwei Tage Downtime ausbedungen, um eine Datenbank zu mergen. Weltführer für Software-Bloat und feste Datenschlüssel-Längen ist aber SAP. Man hatte das konkrete Problem, für jeden Druckjob eine eindeutige Nummer vergeben zu wollen, und diese hatte man auf 4 Stellen begrenzt, weil soviel ja sicher nicht vorkommt. Nun kam bei einem Großkunden eben doch soviel vor, weil an einem Tag eben sehr viele Belegdaten mitprotokolliert wurden. Also hat man bei SAP lieber nicht das Datenbank-Layout geändert, sondern lieber die Basis für die Nummern von numerisch auf alphanumerisch geändert. Weiterhin mußte die kanadische Börse für ein paar Tage schließen, um ein Speicherleck zu beheben, als in der Liste der ausstehenden Orders für ein Papier zuviele Einträge storniert wurden, ohne dabei den Speicher wieder freizugeben. Die Sparkasse hat in Berlin Briefe an Kunden verschickt, wo "Prüfen Sie doch bitte mal ihre letzten Kontoauszüge, ob da was komisch aussieht" drinstand. Tatsächlich ist denen die Datenbank gecrasht, als sie ihren Kundenstamm mit dem einer anderen berliner Bank vereint haben. Außerdem gibt es natürlich auch weite Felder, die von der EDV überhaupt noch nicht erfaßt sind, d.h. die manuell abgehandelt werden. Traditionell tritt das vermehrt als Interface zwischen verschiedenen EDV-Systemen auf, insbesondere als Order-Routing Verfahren innerhalb von Großbanken. Dort tippen Fachkräfte die Orders rechts in ein 3270-Terminal ein, die links aus einem Drucker kommen (das ist nicht historisch und auch nicht als Scherz gemeint!). An dieser Stelle wundert man sich dann auch nicht mehr über verlorengegangene Überweisungen und Orders und die mehrwöchigen Ausführungszeiten innerhalb einer Wertpapierorder, oder wenn mal eine Null verloren geht (wir haben Zeugen!). In einem anderen uns bekannten Fall werden Überweisungen, die man bei der falschen Filiale (d.h. nicht der kontoführenden) abgibt, hinten in eine Kiste geschmissen und dann ungeprüft von einem Boten zur kontoführenden Filiale gekarrt. Die Postbank verzichtet an dieser Stelle sogar auf einen Boten zugunsten des eigenen Zustellsystems, das ja schon anderweitig durch seine Zuverlässigkeit begeistern konnte. Jetzt stelle man sich den durchschnittlichen Consultant vor, der mal bei einer Bank gearbeitet hat, und einen Einblick in die fürchterlichen Altlasten der Banken hatte. Die Personalfluktuation auf dem EDV-Markt ist außerordentlich hoch, und betroffen sind natürlich auch die Banken, die gerade jetzt sehr gerne auf externe Consultants zurückgreifen, weil sich auf dem EDV-Markt niemand findet, der dumm genug ist, für die Hälfte des Gehaltes die Müllsoftware einer Bank warten zu müssen. Es ist nur eine Frage der Zeit, bis diese massive Ansammlung von angeekelten Programmierern die kritische Masse erreicht und den Banken ihre Systeme um die Ohren fliegen. Hinzu kommt die Masse an zur Zeit entlassenen Arbeitskräften, denn die Banken sind gerade in großem Stil dabei, sich von Mitarbeitern zu trennen, und auf automatisiertes Banking ohne Beratung umzusteigen. Nachdem wir einen Einblick in den Qualitätsstandard der Banksoftware haben, liegt die Vermutung nahe, daß schon ein verärgerter Ex-Mitarbeiter eine Bank in den Ruin treiben könnte, wenn man ihn nur kurzfristig genug entläßt. Nick Leeson, der die Barings-Bank mit seinen etwas unkonventionellen Transaktionen heruntergefahren hat, ist da nur ein Beispiel. Die Innentäterquote bei Banken liegt nach diversen Statistiken im Bereich zwischen 70 und 80 Prozent. Praktisch kein Fall wird bekannt, da die Beteiligten nichts so sehr fürchten wie eine öffentliche Behandlung. Der Imageverlust für die Banken überwiegt in praktisch allen Fällen den materiellen Schaden deutlich. Bei den Außentätern sieht es nicht viel besser aus. Der Fall von Markus Söhnke Ungerbühler, der auch schon in der Datenschleuder behandelt wurde, zeigt dies exemplarisch. Ungerbühler gab sich als Mitglied des Chaos Computer Club aus und versuchte Banken, Rüstungsunternehmen und ähnliche mit der Behauptung zu erpressen, durch Hacking an interne Daten des betroffenen Unternehmens gelangt zu sein. Besonders die Drohung mit einer Veröffentlichung von Belegen für Steuerhinterziehungen zeigte schnelle Wirkung. Vorstände von deutschen Großunternehmen jetteten in Learjets durch die Welt, um einem aus einer psychatrischen Heilanstalt entfleuchten Hochstapler für einige tausend Mark eine Packung Leerdisketten abzukaufen. Nach langwieriger Suche gelang es tatsächlich, eines von mehreren dutzend erpressten Unternehmen zu finden, das sich sicher war, korrekt Steuern gezahlt zu haben. Auf dieser Grundlage war es dem Unternehmen möglich, eine Anzeige zu erstatten, die zusammen mit anderen Maßnahmen letztendlich zu einer Rückführung des Herrn Ungerbühler in seine Klinik führte. Vor dem Hintergrund der drohenden Krisen Euro und Jahr-2000 ist der einzige gangbare Weg eine Open Source Bank. Nur durch eine vollständige Offenlegung aller Sourcen können die Banken den verunsicherten Kunden einen Grund für ihr Vertrauen liefern. Nur so ließe sich das Vertrauen in die eigene EDV dem Kunden gegenüber rechtfertigen. Vertrauen ist gut, Kontrolle ist besser. felix@ccc.de & frank@ccc.de

[Datenschleuder] [64]    Deutsche Banken