Unbezahlbar: Neue Swift-Regeln für Finanzdienstleister

Um ein Haar wäre es Hackern im vergangenen Jahr gelungen, einen der grössten Betrugsfälle aller Zeiten durchzuziehen un eine knappe Milliarde US-Dollar zu erbeuten. Der SWIFT-Verbund macht nun Druck, die IT-Security in dem Bankennetzwer flächendeckend zu stärken.

Es war eine Aktion, die das Zeug zum Krimi hatte. Im Februar 2016 schafften es bis heute unbekannte Hacker, da Zahlungsnetzwerk von SWIFT für ihre kriminellen Zwecke auszunutzen. Sie missbrauchten Zugriffsrechte und Systeme de Bangladesh Bank, um 35 Zahlungsaufträge mit einem Gesamtwert von über 950 Millionen US-Dollar vom Konto der Bank bei de Federal Reserve Bank of New York (New York FED) direkt ins SWIFT-Netzwerk einzuspeisen. Beinahe wäre den Hackern ei unglaublicher Coup gelungen, hätten nicht weiterführende manuelle Kontrollen den grössten Schaden verhindert.

Nichtsdestotrotz gelang es den Hackern, fünf der 35 Zahlungsaufträge abzuwickeln. Der Schaden war damit immer noc erheblich, da rund 81 Mio. US-Dollar auf vier private Bankkonten der Hacker auf den Philippinen gelangten (weiter Informationen dazu sind über www.ix.de/ix1712104 zu finden). Eine Rückverfolgung dieser Zahlunge sowie des weiteren Transaktionsverlaufs war in der Folge nicht mehr möglich.

Schwierige Suche nach der Schwachstelle

Die Suche nach potenziellen Schwachstellen erwies sich als überaus schwierig. Zwar zeigte sich schnell, dass di SWIFT-seitigen Komponenten (Software, Hardware, Schutzsysteme, SWIFT-Netzwerk et cetera) nicht betroffen waren Ausgenutzt wurden stattdessen kundenseitig unzureichend geschützte Umgebungen, Endsysteme und Accounts. Zusätzlic wurden Softwarekomponenten, beispielsweise ein PDF-Reader, so verändert, dass man manipulierte Zahlungen nicht meh erkennen konnte. Gelingt es Hackern, an Administratorrechte eines SWIFT-Nutzers zu gelangen, kann das Bollwerk der SWIF einen möglichen Schaden nur noch beschränken. Basierend auf den Erkenntnissen der Schwachstellensuche veröffentlicht SWIFT im Mai 2016 eine Erklärung, wonach jeder SWIFT-Nutzer – also Inhaber eines Business Identifier Code (BIC 8) – sic weiterhin um die interne Sicherheit selbst kümmern muss. Zudem sei künftig eine Selbstdeklaration zum Status de internen IT-Sicherheit einzureichen.

Die Nachrichtenagentur Reuters berichtete in der Folge, dass das Eindringen in die Systeme der geschädigten Bank vo allem einer unzureichenden Sicherheitsinfrastruktur geschuldet sei (siehe „Alle Links“). So sei ungeeignete un unzureichende Hardware eingesetzt worden, zudem habe man an wichtigen Stellen auf wirksame Schutzsysteme wie Firewal und Vulnerability Scanner verzichtet – fatale Fehler, die es Hackern letztendlich leicht gemacht hatten, das Unternehme zu infiltrieren.

Es zeigte sich, dass das IT-Sicherheitskonzept der betroffenen Bank erhebliche Mängel aufwies. Zudem waren die Angreife nicht nur über die eingesetzte Software und IT-Infrastruktur genauestens informiert, sondern wussten auch exakt, wo di Schwachstellen lagen und zu welchem Zeitpunkt ihr Angriff erfolgen musste.

Um herauszufinden, worin die Sicherheitslücken bestanden, die den Betrugsfall ermöglichten, trafen sich Vertreter vo Bangladesh Bank, Federal Reserve Bank of New York und SWIFT. Ihr Ziel war es, nicht nur die Kriminellen aufzuspüren sondern auch alle Details zum Fall aufzuklären, damit das globale Finanzsystem zukünftig gegen solche Attacken besse geschützt werden kann.

Die Befürchtung, dass weitere Attacken im ähnlichen Stil folgen könnten, bestätigte sich: Im Verlauf des Jahre informierte SWIFT über Angriffe mit Schadsoftware, bei denen durchweg wieder bankseitige Komponenten betroffen waren Auch bei diesen Attacken blieben das eigene Messaging-System und die Software der SWIFT unversehrt.

Das Vorgehen der Hacker war jedes Mal dasselbe und unterschied sich kaum von anderen Angriffen. Zuerst verschafften si sich einen Zugriff auf die kundenseitig genutzten Systeme eines Finanzinstituts. Im zweiten Schritt gelangten sie an di Benutzerdaten von Mitarbeitern, die SWIFT-Nachrichten erstellen, bestätigen oder versenden können. Danach wurden mit de gestohlenen Benutzerdaten gefälschte Nachrichten eingeschleust und mögliche Spuren sowie Beweismaterial beseitigt ode verfälscht.

Für das Verfälschen von Nachweisen manipulierten die Täter einen PDF-Reader, den die betroffenen Mitarbeiter de Finanzinstituts für das Lesen der SWIFT-Nachrichten nutzten. Dieser war bereits vorher als Schadsoftware auf de Arbeitsrechnern installiert worden und unterschied sich äusserlich kaum vom Original. Wurde der Reader jedoch zum Lese der Zahlungsbestätigungen verwendet, wurden die entsprechenden Dokumente verfälscht dargestellt oder sogar gan gelöscht.

In allen bekannten Betrugsfällen nutzten die Cyberkriminellen ausschliesslich Schwachstellen der kundenseiti eingesetzten IT-Systeme aus, um manipulierte SWIFT-Nachrichten über das SWIFT-Netzwerk zu versenden. Die entsprechende Kontrollen und Schutzmechanismen der Finanzinstitute wurden umgangen. Was aber noch viel schwerer wog: Durch das Lösche oder Verfälschen der Auszüge und Bestätigungen waren die Opfer erst mit Verzögerung in der Lage, den Betrug zu erkennen.

Ein so perfide geplanter Angriff hätte theoretisch jeden treffen können, da es sich bei den Angreifern u hochprofessionelle kriminelle Organisationen handelt. Diese loten alle erdenklichen Schwachstellen aus und setzen dor an, wo sie den schlechtesten Schutz vorfinden.

IT-Systeme auf dem Prüfstand

Um das Einschleusen gefälschter Zahlungsaufträge in Zukunft zu verhindern, sah der SWIFT-Verband keinen anderen Weg, al bestimmte Vorgaben zur Verwendung seiner Infrastruktur an alle SWIFT-Nutzer (Finanzinstitute, Pensionskassen Industriekonzerne et cetera) zur Bedingung zu machen. Die Sicherheit der kundenseitigen Umgebungen und insbesondere de Kanäle für Datenübertragungen sowie den Zahlungsverkehr sollte dabei im Mittelpunkt stehen. Denn eines stand fest: Di Täter mussten sich vor ihrem grossen Coup über längere Zeit sehr tief in die IT-Systeme der betroffenen Organisatione gehackt haben.

Mit den Vorgaben zur Nutzung der SWIFT-Infrastruktur sind alle Teilnehmer aufgefordert, detailliert darüber z informieren, wie sie sich gegen Cyberangriffe schützen. Umgekehrt ersuchten die Nutzer selbst SWIFT um Hilfestellung au diesem Gebiet. Die Vorgaben alleine sind aber nach Ansicht von SWIFT noch nicht ausreichend, einem möglichen Schade vorzubeugen. Deshalb sind die Nutzer auch ausdrücklich zum zeitnahen Informationsaustausch bei Verdacht auf eine Betrugsfall aufgefordert.

Unter den Stichworten „Secure and Protect“, „Prevent and Detect“ sowie „Share and Prepare“ hat der SWIFT-Verbund sein Customer-Security-Programme (SWIFT CSP) ins Leben gerufen. Ein erster Entwurf wurde Ende Oktober 2016 allen Nutzern zu Prüfung zugestellt. Er war vor allem auf kleinere SWIFT-Nutzer mit rudimentärer IT-Sicherheitsinfrastruktur ausgelegt.

Das SWIFT CSP bezieht für Sicherheit und Schutz nun auch die Aspekte Vorbeugen und Erkennen sowie de Informationsaustausch und das Vorbereiten bei möglichen Betrugsfällen ein. Früher wurde kundenseitig lediglich de Schutz der eigenen Umgebung gefordert (Abb. 1).

Stolpersteine für grosse Organisationen

Grossen Organisationen erschienen die im Entwurf enthaltenen Massnahmen als zu wenig praktikabel und es kam daher vo ihrer Seite starker Widerstand: Ihre bereits vorhandenen, professionellen Sicherheitssysteme wären durch diese neue Massnahmen quasi ausgehebelt worden und kontrollierte automatisierte Prozesse hätten zumindest teilweise durch manuell Abläufe ersetzt werden müssen.

Es folgte eine Stellungnahme des SWIFT-Verbunds, in der auch die Schweizer Teilnehmer mit Bezug auf diese negative Folgen zu Wort kamen. Daraufhin wurden die Vorgaben überarbeitet. Zwar blieben die detaillierten Empfehlungen weiterhi gültig, sie wurden jedoch durch grosszügigere Freiräume für alternative Umsetzungen ergänzt.

Die nun geltenden Sicherheitsvorgaben, die im SWIFT Customer Security Controls Framework festgehalten sind, verlange den kundenseitigen Schutz der Komponenten, die direkt an das SWIFT-Netzwerk angeschlossen sind. Pflicht wird auch da wirksame Schützen und Einschränken der Anmeldeinformationen (Credentials), die dem Zugriff auf SWIFT-Systeme dienen sowie das Reagieren auf mögliche Angriffe.

Die SWIFT-Vorgaben entsprechen im Grundsatz den Massnahmen, die in grösseren Organisationen mit hohe Sicherheitsbewusstsein bereits umgesetzt oder zumindest zur Umsetzung geplant sind. Es ist trotzdem davon auszugehen dass ein grosser Teil der SWIFT-Nutzer notwendige Verbesserungen am Sicherheitskonzept umsetzen muss.

Mit dem geforderten Geltungsbereich geht SWIFT deutlich weiter als beispielsweise die Finanzmarktaufsicht in Deutsc land, Österreich und der Schweiz. Die Vorgaben richten sich nicht nur an Banken und Finanzinstitute, sondern an all Inhaber einer achtstelligen BIC. Dies bedeutet, dass die Vorgaben künftig weltweit auch für Versicherer, Pensionskasse und Industriekonzerne gelten. Selbst wenn ein BIC-Inhaber die SWIFT-Dienstleistungen über ein Servicebüro bezieht bleibt er umsetzungspflichtig und muss eine Selbstdeklaration über die je nach Infrastrukturtyp 16 oder 11 zwingende Sicherheitskontrollen („Security Controls“) einreichen (Abbildung 2).

Da es sich bei SWIFT nicht um einen Regulator handelt, beziehen sich die neuen Vorgaben nur auf SWIFT-Komponenten. E ist jedoch dringend zu empfehlen, die geforderten Massnahmen konzernweit umzusetzen und alle IT-Komponente miteinzubeziehen. Auf diese Weise kann die Sicherheit eines Unternehmens als Ganzes erhöht werden. Ein zentrales Elemen ist eine starke Authentifizierung der Mitarbeiter gegenüber den IT-Systemen, was letztlich zu einem wirksamen Schutz vo dem Diebstahl von Credentials führt.

Mit einer firmenweiten Umsetzung der für die SWIFT-Komponenten geforderten Sicherheitsmassnahmen hätten auch viele de spektakulären und medienwirksamen Hackerangriffe aus den letzten Monaten verhindert oder zumindest in ihrer Wirkun begrenzt werden können. Dazu gehören die WannaCry- und NotPetyaAttacken, die weltweit verheerende Schäden i Unternehmen, Krankenhäusern und Behörden anrichteten.

In weiteren Fällen, beispielsweise dem Heartbleed-Programmfehler, der neben prominenten Websites auch VoIP-Telefone Router und Netzwerkdrucker für Angriffe anfällig machte, wäre mit einem effizienten Incident- und Change-Management ei schnelleres Patchen der betroffenen Systeme möglich gewesen.

Die vorgegebenen Massnahmen hängen unter anderem vom Typ der Infrastruktur ab. Neben weiteren drei Architekturtype wird bei diesem Typ eine Softwareanwendung (im Beispiel Alliance Lite2 AutoClient zum Dateienaustausch) innerhalb de Kundenumgebung verwendet, um die Kommunikation zwischen Anwendungen mit einer Schnittstelle zu einem Dienstleiste auszustatten (Abb.2).

Angelehnt an andere Standards

Mit den aktuell definierten Massnahmen und Kontrollen hat die SWIFT das Rad nicht neu erfunden. Vielmehr lehnen sich di Sicherheitskontrollen eng an internationale Standards wie das Cybersecurity Framework des National Institute o Standards and Technology (NIST), ISO / IEC 27002 oder den Sicherheitsstandard der Kreditkartenwirtschaft PCI DS (Payment Card Industry Data Security Standard) an (siehe „Alle Links“). Sie lassen sich sogar auf diese Standard übertragen (sogenanntes Mapping), um bestehende Sicherheitsinfrastrukturen auf SWIFT-Komponenten anzuwenden.

Obwohl die SWIFT-Nutzer nur 11 beziehungsweise 16 der insgesamt 27 Schutzziele zwingend erfüllen müssen – die andere sind nur „empfohlen“ –, ist als effektiver Schutz vor Angriffen auch hier eine vollständige Umsetzung der Massnahme ratsam.

Unter anderem sollten dabei folgende Punkte in den Mittelpunkt rücken:

• Schutz der lokalen (SWIFT-)Umgebung;
• Kontrolle privilegierter Konten auf dem Betriebssystem;
• Sicherheit der internen Datenströme;
• Sicherheitsupdates regelmässig einspielen;
• Systemhärtung: Analyse der Systeme und anschliessende Härtung, um die Verwundbarkeiten zu reduzieren;
• starke (Multi-Faktor-)Authentifizierung und logische Zugriffskontrolle (Access Control);
• Schutz gegen Malware optimieren;
• Softwareintegrität überprüfen;
• Logging und Monitoring von Aktivitäten;
• Planung der Abwehrmechanismen bei Cyberattacken.

Insbesondere den letzten Punkt sollte man nicht vernachlässigen: Wer keinen Plan zur Abwehr von Angriffen ausgearbeite hat, geht ein hohes Risiko ein – es drohen finanzielle Einbussen sowie Imageschäden. Die meisten grössere Organisationen besitzen zwar einen solchen Plan, bei vielen mittleren und kleinen Unternehmen hapert es damit aber noch Kein Wunder, dass sich sogar die amerikanische Homeland Security mit dem Thema beschäftigt und amerikanische Unternehme zum Handeln auffordert („Alle Links“).

SWIFT macht Druck

Für die SWIFT-Nutzer wird die Zeit langsam knapp, denn bereits bis Ende Dezember 2017 müssen alle Inhaber eine sogenannten BIC 8 eine Selbstdeklaration einreichen, die den Erfüllungsgrad der vorgeschriebenen Sicherheitskontrolle angibt. Das einmalige Einreichen reicht jedoch nicht aus: Die Selbstdeklaration muss mindestens alle zwölf Monat erneuert werden, Gleiches gilt bei einer Änderung der lokalen IT-Systemumgebung.

Im Januar 2018 führt SWIFT zudem ein Monitoringsystem ein und erhöht den Kooperationsdruck auf die Teilnehmer. Ab dan kann den Regulatoren – etwa der Eidgenössischen Finanzmarktaufsicht (FINMA) für die Schweiz, in Deutschland de Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) und in Österreich der Finanzmarktaufsicht (FMA) – übermittel werden, welche Organisationen die Selbstdeklaration bis dato nicht eingereicht haben. Bis Dezember 2018 schliesslic muss die volle Regelkonformität (Compliance) zu den SWIFT-Vorgaben erreicht sein. Auch hier sieht die SWIFT vor, di Konformität zu überwachen und den Regulatoren diejenigen Institute zu melden, die die Regeln nicht erfüllen.

Für diejenigen, die bei der Analyse und Umsetzung der SWIFT-Vorgaben externe Unterstützung benötigen, hat SWIFT eigen ein Verzeichnis von registrierten Cybersecurity-Providern erstellt („Alle Links“).

Mit der Umsetzung der SWIFT-Vorgaben und den Empfehlungen seitens NIST, BSI oder ISO / IEC wird es für Cyberkriminell wesentlich schwerer, ihre Ziele zu erreichen. Dazu wird es aber notwendig sein, die aktuellen Massnahmen und Vorgabe regelmässig auf den Prüfstand zu stellen – insbesondere mit Blick auf die hochprofessionellen, bestens organisierten un stark motivierten Angreifer, die unermüdlich auf der Suche nach neuen Zielen sind. Und trotz aller Bemühungen wird e kriminellen Organisationen auch in Zukunft immer wieder gelingen, das schwächste Glied einer Kette auszumachen un auszunutzen.

Alle Links: https://www.heise.de/select/ix/2017/12/softlinks/104

Hinweis: Dieser Artikel wurde in der Zeitschrift iX 12/2017 publiziert.

Compliance Information Security Management System (ISMS)

Über den Autor

Über den Autor

André Clerc ist ein anerkannter PKI-Experte mit über 20 Jahren Erfahrung in der Beratung und Schulung von Unternehmen. Er unterstützt Kunden aus allen Branchen umfassend in den Bereichen PKI, IoT, Identifikations-, Authentifizierungs- und Autorisierungslösungen, Sicherheitsarchitekturen und Systemhärtung.

André Clerc, Managing Security Consultant