GlobalSign Blog

07 Aug 2018

Umgang mit Cybersicherheit in Finanzinstituten / FinTech-Partnerschaften

Wir stellen Jon Scheele vor, Berater und Trainer, der mit Finanzinstituten an API-basierten Partnerschaften arbeitet. Er beginnt eine Reihe von Blogs, die sich an Finanzinstitute und FinTechs richten. Sie sollen ihnen dabei helfen, mit den aufstrebenden Technologien und der regulierten Landschaft des EU-Marktes gewachsen zu sein. Folgen Sie dem Link am Ende des Artikels zum nächsten Blog der Reihe.

Partnerschaften zwischen Finanzinstituten (FI) und FinTech (Finanztechnologie-basierte Start-ups) müssen über das Wertversprechen an die Kunden hinausgehen. Strenge Vorschriften wie eIDAS für die Sicherung elektronischer Transaktionen, PCI DSS, das festlegt, wie Zahlungsdaten erfasst, gespeichert und organisiert werden können, und DSGVO für den Datenschutz der Kunden, erfordern, dass Cybersicherheit in alle Phasen der Customer Journey eingebettet werden muss.

Um den End-to-End-Schutz von Kundendaten und Vermögenswerten zu leisten, müssen alle Partnersysteme Authentifizierung und Autorisierung, Schutz von Daten, Systemintegrität sowie proaktive Erkennung und Reaktion auf Cybersicherheitsvorfälle umfassen. Da Application Programming Interfaces (APIs) der Schlüssel für die Anbindung von Partnern sind, ist die Implementierung einer erstklassigen API-Sicherheit unerlässlich.

Wer ist für all das verantwortlich? Egal ob Sie dies als FI oder FinTech-Unternehmen lesen, es ist immer ein Spagat. Betrachten wir Folgendes:

Die Chance

Ein gemeinsamer Bericht von PwC UK und dem Open Data Institute prognostiziert eine Einnahmenchance von 7,2 Milliarden £ durch Open Banking bis 2022. Dies schließt zusätzliche Einnahmen aus neuen Produkten und Diensten sowie bestehende gefährdete Einnahmen von alteingesessenen Unternehmen ein, wenn diese sich nicht anpassen.

Die Öffnung von APIs für FinTech-Partner in ihren Zielmarktsegmenten erweitert die Fähigkeit einer Bank, Kunden zu akquirieren, sich auf sie einzulassen und mit ihnen Geschäfte zu tätigen. PwCs Studie von 2017 mit 39 führenden Banken in 17 Ländern ergab, dass "92 Prozent der Banken angeben, dass Partnerschaften mit Nichtbanken in Zukunft sehr wichtig oder wichtig sein werden" und dass "71 Prozent der Banken zustimmen oder voll und ganz zustimmen, dass Partner / Zusammenarbeit erforderlich sein werden, um mit dem Innovationstempo Schritt zu halten". Die Befragten beschrieben die Stärken der FinTechs damit, dass sie neue Technologien und verbesserte Kundenerfahrungen bringen, während die Stärken der FIs ihre sichere Infrastruktur, der vorhandene Kundenstamm, Kundenkenntnis und die Datenverfügbarkeit sind.

Die Risiken

Aber die Risiken verschwinden nicht, genauso wie die Verantwortung der FI gegenüber Aufsichtsbehörden und Kunden, sensible Daten und Gelder der Kunden zu schützen. FIs müssen ihre Wachsamkeit erhöhen, um sich vor Verlust oder Diebstahl von Kundendaten, nicht autorisierten Transaktionen oder dass ihre Systeme oder Konten für Geldwäsche oder die Verletzung von Sanktionen verwendet werden, zu schützen.

Bedrohungen

Bedrohungen durch Viren-, Malware-, Man-in-the-Middle-, Phishing- und Denial-of-Service- (DOS) Angriffe nehmen zu, wenn zum digitalen Ökosystem der FIs Partnersysteme hinzukommen.

Zwei Vorfälle in letzter Zeit weisen auf die höhere Anfälligkeit von Kundendaten durch Partner der FIs hin:

  • Die Datenschutzverletzung bei Ticketmaster UK legte die personenbezogenen und Zahlungskartendaten von 40.000 Kunden offen. Die Sicherheitslücke entstand, als ein Teil des Javascript-Codes, der von Ticketmasters ChatBot-Anbieter Inbenta erstellt wurde, auf die Zahlungsseite von Ticketmaster angewendet wurde. Obwohl sich herausgestellt hat, dass die Hackergruppe Magecart Inbentas Skript infiziert hat, sind es die Banken, die die Karten ausgestellt haben, die sich um die betroffenen Kunden kümmern müssen.

  • Die Datenschutzverletzung der neuen digitalen Immobilienbörse PEXA in Australien wirft ein Schlaglicht auf die Verluste, die Kunden erleiden können, wenn Nichtbank-Partnersysteme kompromittiert werden. Bei diesem Vorfall schöpfte ein Hacker 250.000 $ aus der Eigentumsregelung einer Familie ab, indem er eine E-Mail zur Rücksetzung eines Passworts an einen Notar abfing, ein eigenes Benutzerkonto einrichtete und Gelder auf sein eigenes Bankkonto umleitete. Als Reaktion darauf führte PEXA Multi-Faktor-Authentifizierung, zusätzliche Kontrollen bei Rücksetzungen des Passworts und eine Kundengarantie ein. Der Reputationsschaden durch diese Datenschutzverletzung kommt jedoch zu einem Zeitpunkt, da PEXA, Banken und Behörden versuchten, das Vertrauen der Öffentlichkeit in ein neues digitales System zu stärken, das einen 150 Jahre alten papierbasierten Prozess ersetzen sollte.

Management

Der Schutz vor Bedrohungen erfordert einen ökosystemweiten Ansatz für die Cybersicherheit. Dazu gehören:

  • Überprüfung der Partner, bevor Zugang zum Produktionssystemen des FI gewährt wird;
  • detaillierte Überwachung der API-Nutzung durch Partner;
  • Verifizierung der Identität von Partnersystemen;
  • Tokenization: Ersatz sensibler Kundendaten durch ein Token oder einen Platzhalter. Dadurch kann das FI den Kunden innerhalb seines "Token-Tresors" zuordnen, ohne die Originaldaten offen zu legen.

Die Herausforderung für FIs bei der Unterstützung eines Partner-Ökosystems besteht darin, die Entwickler des Partners darin zu schulen, wie sie ihre APIs nutzen können, ohne Informationen preiszugeben, die zum Hacken des Systems verwendet werden könnten. Um Entwickler zum Testen von APIs zu ermutigen, veröffentlichen viele Institute Entwicklerportale mit Leitfäden, Beispielcode und einer "Sandbox" -Umgebung, die es Entwicklern ermöglicht, simulierte API-Aufrufe durchzuführen. Während Sandboxes es Entwicklern erleichtern, ihre Prototypen zu entwickeln und zu testen, erfordert die Erlaubnis, dass eine Partneranwendung die Produktions-APIs des FI aufrufen darf, strengere Prüfungen. FIs müssen sich davon überzeugen, dass sowohl die Kontrollen des FI als auch der FinTech Kundendaten und Produktionssysteme schützen, bevor Partneranwendungen auf die Live-Produktionssysteme des FI zugreifen.

Das Schöne an APIs ist, dass sie eine Abstraktionsebene über die Systeme des FI legen. Sie müssen keine Informationen über das zugrunde liegende System herausgeben (und die Partner müssen nicht wissen, wie das zugrunde liegende System funktioniert, um mit ihm zu interagieren). Außerdem können Zugang und Nutzung eng überwacht werden, indem nur ein Weg in die Systeme eines FI hinein gewährt wird.

Incident Response

Die Verantwortung für die API-Sicherheit liegt voll und ganz auf den Schultern des API-Anbieters - dem FI selbst. Ungenügendes Verständnis inhärenter Schwachstellen in solchen Geschäftsfunktionen kann zu massiven Verlusten und Risiken führen.

Der FinTech-Partner muss in die Security Incident and Event Management (SIEM) -Funktion des FI integriert werden, die Folgendes umfasst:

  • Prozesse:
    • Nutzung von API-Aufrufen
    • Nach Funktion/Aktivität
    • Menge
    • Fehler
  • Reaktion:
    • Beobachten
    • Isolieren/Quarantäne/ Herunterfahren betroffener Bereiche (API-Zugriff durch das System eines Partners)
  • Benachrichtigung:
    • Partner
    • Kunden
    • Regulierungsbehörden

Authentifizierungsansätze

Der Wechsel von einer herkömmlichen Kunden-FI-Schnittstelle zu einem Drei-Wege Kunden-FinTech-FI-Modell erhöht die "Angriffsfläche" (mehr Punkte für Angriff und Datenschutzverletzung). Dies erfordert ein neues Vertrauensmodell für die Cybersicherheit, bei dem ein Kunde dem FI zustimmen kann, dem FinTech Zugang zu seinen Kontodaten zu gewähren, ohne die Anmeldeinformationen des Kunden offenzulegen. Daher müssen weitere Governance- und Datensicherheitskontrollen eingeführt werden, um einen Kunden bei der Nutzung von zwischengeschalteten FinTech-Diensten zu schützen.

Die Europäische Bankenaufsichtsbehörde (EBA) hat Leitlinien für die Umsetzung der Sicherheit gemäß der Zahlungsdienstrichtlinie (PSD2) festgelegt. Diese erfordern eine "starke Kundenauthentifizierung", wie z. B. die Verwendung von Multi-Faktor-Authentifizierung (z. B. Zwei-Faktor-Authentifizierung) basierend auf dem, was ein Kunde besitzt (Besitz), weiß (Wissen) oder ist (Inhärenz).

Offene Protokolle wie OAuth und OpenID Connect sind derzeit Best Practice, um Dritten Zugang zu Kontodaten zu gewähren und gleichzeitig die Vertraulichkeit der Anmeldedaten des Kunden zu wahren. Abhängig von der Aktivität, die aufgerufen wird, wie z. B. Geldüberweisung oder Zahlung, ist auch eine erneute Authentifizierung erforderlich.

Die Implementierung von EBA-Sicherheitsrichtlinien ist Mindestvoraussetzung. Die Unternehmen müssen weiter gehen, um sicherzustellen, dass die Kontrollen getestet wurden und wie erwartet funktionieren. Sicherheit muss in die Entwicklungspraktiken von Anwendungen integriert werden, um sicherzustellen, dass keine Schwachstellen vorhanden sind, die durch Hacker, Malware und API-Missbrauch ausgenutzt werden können.

Sicherer Ausbau

Der Aufbau von FI/FinTech-Partnerschaften erfordert einen ökosystemweiten Ansatz für die Cybersicherheit. Dies umfasst die Entwicklung eines robusten Partner-Screening- und Onboarding-Prozesses, die Anwendung von OAuth2.0- und OpenID Connect-Sicherheitsprotokollen, Methoden wie digitale zertifikatbasierte Authentifizierung  und Tokenization sowie die Integration in die Security Incident- und Event-Management-Prozesse des FI.

Durch den Einbau dieser Kontrollen in die Bildung und Erweiterung von Partnerschaften wird sichergestellt, dass FIs, FinTechs und ihre Kunden die Vorteile von Partnerschaften (sicher) nutzen können.

Dieser Blog wurde für FinTechs und Finanzinstitute geschrieben. Verpassen Sie nicht den nächsten Teil der Serie im August - PSD2: Cyber-Implikationen für FinTech-APIs.

Über den Autor

Jon Scheele ist ein Berater und Trainer, der Finanzinstituten und FinTechs hilft, durch API-fähige Partnerschaften neue Wertversprechen an die Kunden aufzubauen. Jon schult in seinem Kurs "Building Financial Services Open APIs (Aufbau von Open APIs für Finanzdienste)" Finanzdienstleister in Strategie, Design, Implementierung und Produktmanagement von APIs.

HinweisDieser Blog Artikel wurde von einem Gastautor geschrieben, um unseren Lesern eine breitere Vielfalt an Inhalten anzubieten. Die in diesem Gastautorenartikel ausgedrückten Meinungen sind nur die des Autors und geben nicht unbedingt die von GlobalSign wieder.

Artikel teilen