Open Banking API vor Cyber‑Angriffen schützen

Bereits in den letzten Jahren war Open Banking ein wichtiges Thema im Finanzsektor. Die API für Drittanbieter (Third Party Providers, TPPs) eröffnet neue Geschäftsmodelle für Banken und FinTechs. Darüber hinaus bietet sie durch neue Services auch viele Vorteile für Bankkunden. Mit Inkrafttreten der PSD2-Richtlinie wird die Schnittstelle obligatorisch. So stehen Banken nicht nur vor der Herausforderung, die Programmierschnittstelle zu installieren, sondern auch, diese gegen Cyber-Angriffe zu schützen.

von Frederik Mennes, VASCO Data Security

Zwei Möglichkeiten von API-Lösungen

Für diese Anforderungen kommen zwei Arten von APIs infrage: eine neue, dezidiert für TPPs vorgesehene API oder die Nutzung einer bereits bestehenden Schnittstelle wie etwa der Online-Banking-Zugang von Usern.”

Eine dezidiert für TPPs eingerichtete API muss so aufgebaut sein, dass sie den ISO 20022 Standard erfüllt, der sich bereits für den Datenaustausch zwischen Finanzinstituten bewährt hat. Zudem sollte die Schnittstelle eine RESTful API sein oder einen ähnlichen Standard erfüllen, auch wenn das nicht explizit vorgeschrieben ist.

Im Gegensatz dazu steht die Möglichkeit, eine bereits vorhandene Schnittstelle, wie etwa den Online-Banking- oder Mobile-Banking-Zugang von Kunden zu verwenden. Hier ist der entscheidende Unterschied, dass sich der TPP – nicht der User – bei der Bank identifizieren muss.

Zwei Möglichkeiten für Schnittstellen: Bankkunden können entweder mit dem TPP oder der Bank kommunizieren. Banken stellen dabei entweder (a) eine extra API zur Verfügung oder die Kundenschnittstelle (b).

Sicherheitsanforderungen für APIs

Die regulatorischen Anforderungen der PSD2-Richtlinie sehen hohe Standards bei der Authentifizierung vor, wenn Kunden auf ihr Konto zugreifen oder eine Überweisung tätigen. Deshalb ist es auch ein wichtiges Thema, wie Authentifizierungsmethoden in die Schnittstelle integriert werden können.

Außerdem muss der Austausch von sicherheitskritischen Daten zwischen Bank und TPP gewährleistet sein, etwa wenn sich der User über eine TPP-App bei der Bank authentifiziert. Hier muss also eine Verifizierung der Daten seitens der Bank erfolgen.

Wenn man davon ausgeht, dass Banken sich eher für die Lösung einer dezidiert für TPPs vorgesehenen Programmierschnittstelle entscheiden, gibt es einige Risiken, die bedacht werden müssen.

Sicherheitsrisiken durch die Authentifizierungsmethode

Unterschiedliche Authentifizierungsmethoden haben unterschiedliche Sicherheitsmerkmale. Diese sollten bei der Entscheidung für die Art der API berücksichtigt werden.

In einem eingebetteten Authentifizierungsmodell gibt der User seine Zugangsdaten in die App oder auf der Website des TPP ein. Dieser leitet die Informationen weiter zur Bank, um sie sich bestätigen zu lassen. Dieses Verfahren könnte anfällig für Phishing- oder Man-in-the-Middle-Attacken sein.

Weiterhin kann in diesem Vorgang die Ende-zu-Ende-Verschlüsselung für die Datenübertragung zwischen User und Bank nicht gewährleistet werden. Da jedoch die Banken für Zahlungsbetrug haften müssen, ist es für sie sicherer, die Authentifizierung des Nutzers selbst zu übernehmen und so sicherzustellen, dass die Authentifizierung nicht manipuliert werden kann.

Im Gegensatz dazu stehen Modelle, die die Authentifizierung durch eine Weiterleitung zur Bank lösen oder einen dritten Dienst zur Identitätsprüfung nutzen. Hier gibt der Bankkunde seine Informationen nur in die App oder auf der Website der Bank ein beziehungsweise wird zum Identitätsprüfer weitergeleitet. So stellt die Bank sicher, direkt an der Authentifizierung beteiligt zu sein.

Autor Frederik Mennes, Vasco

Frederik Mennes leitet das Vasco Security Competence Center, wo er sich mit den Sicherheitsaspekten der Vasco-Produkte und -Infrastruktur beschäftigt. Er nimmt regelmäßig an Industrieveranstaltungen und Konferenzen zu Sicherheitstechnologien als Redner teil und engagiert sich bei der Initiative for Open Authentication (OATH). Neben seiner Tätigkeit bei Vasco hat Mennes die Information Security Group (ISG) an der Royal Holloway, University of London als Lehrbeauftragter unterstützt. Er hat einen MBA von der Vlerick Business School (Belgien), einen M.Sc. in Informationssicherheit vom Royal Holloway, University of London, und einem M.Sc. in Computer Science Engineering von der KU Leuven, (Belgien).

Moderne Software-Lösungen, wie zum Beispiel Vascos IDENTIKEY Risk Manager, prüfen alle Finanz-Transaktionen im Hintergrund. So identifizieren sie unübliche Verhaltensmuster, die auf Betrug hindeuten, und erhöhen, wenn nötig, die Sicherheitsmaßnahmen.

Eine weitere Möglichkeit, einen sicheren Datenaustausch ohne Zertifikatsverwaltung zu implementieren, ist die Nutzung von hochentwickelten Software Development Kits wie DIGIPASS for Apps von Vasco, die einen Ende-zu-Ende verschlüsselten Datenaustausch zwischen Bank und TPP ermöglichen.

Doch auch diese Modelle müssen so aufgebaut sein, dass sie Sicherheitslücken vermeiden. Eine bewährte Methode ist hier das 3-D-Secure-Protokoll, das zum Beispiel für Kartenzahlungen genutzt wird. Allerdings öffnet dieses Verfahren einen iFrame oder ein Pop-Up-Fenster ohne Adresszeile, was es Nutzern schwer macht zu sehen, wer die Zahlungsinformationen von ihnen abfragt. Auch das begünstigt Phishing-Angriffe.

Risiken, die von TPPs ausgehen

Die Einführung von Schnittstellen durch die Banken bedeutet, dass ihre eigene Sicherheit abhängig von der Sicherheit der TPPs wird, die diese APIs nutzen. Damit verbunden sind folgende Risiken:

Da TPPs Finanzinformationen von Bankkunden speichern, können Sicherheitslücken in deren Anwendungen auch die Datenintegrität bei den Banken beeinträchtigen und so der Reputation schaden. Deshalb müssen Banken sicherstellen, dass sie sowohl vom technischen als auch vom organisatorischen Gesichtspunkt aus gerüstet sind, die Daten, die sie mit TPPs teilen, zu schützen.

Wenn Hacker sich Zugriff zu einer Anwendung eines TPP verschafft haben, können sie den Zugang zur Bank nutzen, um Informationen anzufragen oder Transaktionen zu tätigen. Jedoch sind es die Banken, die zuerst für die Durchführung betrügerischer Überweisungen zur Rechenschaft gezogen werden. Und so wirken sich Sicherheitslücken bei TPPs direkt auf die Banken aus.

Ganz ähnlich sieht es aus, wenn der Angriff von der TPP-App selbst kommt – etwa durch einen unzufriedenen Mitarbeiter, der seinen Zugang nutzt, um kritische Informationen abzufragen.

Eine Hacker-Attacke auf TPPs könnte zur Folge haben, dass die Anwendung eine Vielzahl an invaliden Authentifizierungsanfragen an die Bank sendet. Als Folge würde die Bank den Account vorübergehend sperren und der Bankkunde könnte den Service nicht nutzen.

Risiken bei der Implementierung der API

Moderne Banking-Applikationen bestehen meistens aus Rich Clients, die über HTTP mit RESTful APIs im Backend verbunden sind und JSON oder XML verwenden, um Daten zu strukturieren. Wenn diese nicht ordnungsgemäß integriert sind, können APIs zu Sicherheitsrisiken werden. User-Daten können gestohlen, manipuliert oder unwiderruflich gelöscht werden. Aber auch illegale Transaktionen oder sogar die komplette Übernahme der App können die Folge sein.

Diese Art von Angriffen nutzt Sicherheitslücken aus, indem ein schadhafter Code in eine Datenbank, oder in diesem Fall in einen Aufruf der API-Funktion, eingefügt wird und so zum Beispiel kritische Daten abfragen kann. Meistens sind Injection-Attacken die Folge von mangelnder Reinigung (Sanitization) des Inputs.

Anwendungsfunktionen, die mit der Authentifizierung und dem Session-Management zusammenhängen, sind oft nicht richtig implementiert. Das ermöglicht Angreifern, Passwörter, Verschlüsselungen oder Session Tokens zu kompromittieren und einen Account zu hacken oder sogar die Identität eines Users zu stehlen.

Bei Man-in-the-Middle-Attacken geht es vor allem darum, kritische Daten abzugreifen, indem Anfragen und Antworten, die über die API ausgetauscht werden, abgefangen werden. Probleme können auftreten, wenn der Kommunikationskanal nicht genügend gesichert ist oder die Authentifizierungsmethode nicht ausreicht.

DoS-Attacken (Denial of Service) wirken sich auf die Verfügbarkeit der App aus. Schnittstellen können potenziell durch eine Flut von Anfragen überlastet werden und das Backend-System lahmlegen. Infolgedessen ist der Dienst vorübergehend nicht mehr verfügbar.

Wie sich Banken schützen können

Angesichts dieser Risiken ist es für Banken essentiell, dass sie geeignete Sicherheitsmaßnahmen ergreifen und ihre APIs bestmöglich schützen. Dafür stehen ihnen eine Reihe an Möglichkeiten zur Verfügung.

TRA (Transaction Risk Analysis) kann bei mehreren der geschilderten Risiken Abhilfe verschaffen. Zahlungsdienste und somit auch Banken sind laut der regulatorischen Anforderungen der PSD2 dazu verpflichtet, für jede Transaktion eine Risikoanalyse durchzuführen. So kann zum Beispiel verhindert werden, dass Zahlungen mit einer gestohlenen Kreditkarte getätigt werden.

Aber die Technik kann auch genutzt werden, um auffällige Veränderungen bei den Anfragen oder ungewöhnliche Transaktionen oder Aufrufe der Schnittstelle durch die TPPs aufzudecken – und das in Echtzeit.

Zudem ist es möglich, Schwachstellen bei der Implementierung der API zu entdecken. Treten betrügerische Transaktionen oder ungewöhnliches Nutzerverhalten gehäuft auf, deutet dies auf Schwachstellen in der Implementierung hin.

Wie schon erwähnt, haben unterschiedliche Authentifizierungsmodelle unterschiedliche Merkmale und Auswirkungen auf die Sicherheit. Aus der Perspektive der Bank ist ein Modell, das den Prozess der Authentifizierung zur Bank weiterleitet oder an einen Drittanbieter weitergibt am attraktivsten – so können sie während des Vorgangs direkt mit dem Kunden interagieren.

Das bedeutet, sie verfügen über einen Authentifizierungsnachweis, was im Betrugsfall wichtig für die Frage der Haftung ist. Zudem erhalten sie Informationen, wie sicher das Gerät ist, mit dem sich Bankkunden authentifizieren. Diese Angabe kann weiterhin für die Risikoanalyse genutzt werden.

Um Man-in-the-Middle-Attacken, illegale Transaktionen oder Datenverluste vorzubeugen, sollten Banken für einen sicheren Datenaustausch mit TPPs sorgen, etwa durch gegenseitige Authentifizierung. Hierfür können zum Beispiel SSL/TLS-Protokolle genutzt werden. Diese erfordern jedoch besondere Sorgfalt bei der Implementierung. Zum einen ist es leicht, auf Server-Seite falsche Konfigurationen vorzunehmen und zum anderen validieren viele Entwickler Zertifikate nicht richtig.

Banken sollten eine unabhängige Evaluation der Sicherheitsmaßnahmen der TPPs anfordern. In der PSD2 sind bereits ausführliche Richtlinien für die Einrichtung, Implementierung und das Monitoring von Sicherheitsmaßnahmen festgelegt, die TPPs erfüllen sollten. Sie umfassen nicht nur das Framework des Risikomanagements, sondern auch die Risikoanalyse, den Schutz von Daten und einige weitere Punkte.

Gegen Injection-Attacken kann man sich schützen, indem man sicherstellt, dass – egal welches Datenformat die Schnittstelle verwendet – die API-Softwarekomponente für das Daten-Parsing gegen Angriffe geschützt ist. Zudem ist es wichtig, den Prozess der Input-Bereinigung (Sanitization) zu schützen, um Injection-Angriffe aller Art zu verhindern.

Fazit

Durch die in der PSD2 geforderten Programmierschnittstellen werden Innovationen und der Wettbewerb gefördert – doch diese Vorteile verkehren sich schnell ins Negative, wenn die nötigen Sicherheitsvorkehrungen nicht getroffen werden. Deshalb müssen sich Banken und Drittanbieter über die Risiken bewusst sein und für einen ausreichenden Schutz sorgen.aj

 
Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/66731

• teilen 
• teilen 
• teilen 
• teilen 
• teilen 
• RSS-feed 
• E-Mail 
• drucken