Schutz für Finanz-APIs und das Management von Risiken in der Wertschöpfungskette

Derzeit werden mehr Tools für Finanztechnologie (bzw. Fintech) eingeführt wie nie zuvor, und die Verbraucher fordern einen unkomplizierten digitalen Zugang zu ihren Finanzen: Sie wollen Geld überweisen, den Status von Versicherungsansprüchen prüfen und ihre Investitionen online verwalten. Im Rahmen einer Studie über die Auswirkungen der Fintech gaben 93% der Verbraucher an, dass sie im Jahr 2022 echten Nutzen aus ihren Fintech-Apps ziehen konnten – ein Anstieg gegenüber den Zahlen aus den Jahren 2021 (90%) und 2020 (84%) (Plaid). Finanzinstitute haben ein starkes Interesse daran, ihre eigenen Tools anzubieten, aber auch an Verknüpfungen mit den Lösungen von Drittanbietern, um Kunden zu gewinnen und zu binden.

Damit diese Funktionen bereitgestellt werden können, werden die Finanz-Ökosysteme immer komplexer. Leider bergen diese erweiterten Wertschöpfungsketten für die Finanzinstitute das Risiko von Sicherheitsverletzungen und finanziellen Verlusten. Laut den Schätzungen in Verizons Bericht über die Untersuchung von Datenschutzverletzungen waren im Jahr 2022 Datenschutzverletzungen in der Wertschöpfungskette für 62% der Systemeinbrüche verantwortlich (Verizon). Warum ist diese Art von Missbrauch so stark verbreitet, und wie können Finanzinstitute mit diesem massiven Risikovektor angemessen umgehen?

Diese Frage lässt sich nicht ohne Kenntnisse über den Aufbau dieser Ökosysteme beantworten. Die Partner des Ökosystems stehen in der Regel über Finanz-APIs in Verbindung, die eine einfache gemeinsame Nutzung von Daten ermöglichen. Seit dem Aufkommen dieser Finanz-Ökosysteme priorisieren die Finanzinstitute die Entwicklung der APIs: der Anteil der Banken und Kreditgenossenschaften, die in APIs investiert oder diese entwickelt haben, stieg von 35% im Jahr 2019 auf 47% im Jahr 2021. Weitere 25% planen Investitionen für das Jahr 2022 (Pyments). APIs sind allgegenwärtig und bilden das Herzstück der modernen Finanzdienstleistungen. 

Unglücklicherweise ist ihr Schutz nicht so einfach wie es scheint– es braucht zwar nicht viel, um einen API-Endpunkt einzurichten, aber es ist sehr viel schwieriger, seine Sicherheit zu gewährleisten. Die meisten Unternehmen gehen davon aus, dass der Programmierer die API-Sicherheit in den Code integriert hat, den die API verwendet. Die Programmierer allerdings sind viel eher darauf bedacht, den Code schnell fertig zu stellen, und neigen zu der Annahme, der Anbieter der API-Gateway-Software sei für die Sicherheit verantwortlich. Der Anbieter wiederum bietet unter Umständen nur die grundlegenden Sicherheitsmaßnahmen an und geht davon aus, dass das Sicherheitsteam des Endkunden das Problem schon lösen wird.

Die daraus resultierenden Verbindungen können leicht ausgenutzt werden und zu Problemen führen, die durch schnelle Entwicklungsprozesse (wie beispielsweise Agile) noch verschärft werden. Hierbei ist zu beachten, dass die Agilität an sich nicht das Problem darstellt , sondern dass sie ohne einen ausgereiften DevSecOps-Prozess dazu führen kann, dass Weiterentwicklungen überstürzt werden. Im Zuge dessen werden Sicherheitsanforderungen nicht selten vernachlässigt, so dass die Funktions-Updates die Anwendung unter Umständen insgesamt unsicherer machen. Cyberkriminelle sind sich der Unsicherheiten im Umgang mit der API-Sicherheit durchaus bewusst und versuchen diese Schwachstellen auszunutzen. Dies ist einer der Faktoren, die hohe Zahlen für Datenschutzverletzungen nach sich ziehen, welche auch Partner in der Wertschöpfungskette betreffen.

In Wahrheit sind für eine wirkungsvolle Sicherheit von Finanz-APIs mehrere Ebenen erforderlich.

API-Verbindungen werden in zwei Kategorien eingeteilt: exponierte und nicht exponierte. Exponierte APIs sind öffentlich zugänglich und bieten über eine Schnittstelle jedem Dritten problemlosen Zugang zur Geschäftslogik. Natürlich kann das Unternehmen auch bei einer exponierten API kontrollieren, was und wem sie angezeigt wird, andererseits beschleunigt dieser API-Typ die Verbindungen mit den Drittparteien aus der Wertschöpfungskette erheblich.

Eine nicht exponierte API hingegen ist eine Punkt-zu-Punkt-Verbindung zwischen zwei bestimmten Parteien. Dies scheint zwar oberflächlich betrachtet sicherer zu sein, erschwert aber die Erweiterung des Ökosystems, und auch hier können ähnliche Sicherheitsprobleme auftreten. Ein Unternehmen, dass sich durch die Verwendung ausschließlich nicht exponierter APIs geschützt wähnt, sollte sich folgende Fragen stellen: „Haben wir wirklich Vertrauen zu allen Unternehmen, mit denen wir in Kontakt stehen, mit allen ihren Mitarbeitern und ebenso allen ihren Auftragnehmern und Unternehmen, mit denen sie wiederum in Verbindung stehen?“ Wenn die Antwort auf diese Fragen „Nein“ lautet, dann bedeutet das Vermeiden exponierter APIs nicht, dass das Risiko tatsächlich gebannt ist, und zwar aus folgendem Grund: In beiden Fällen verfügt die API über ein Zertifikat, das den Kanal verschlüsselt. Das Unternehmen und die betreffende vertrauenswürdige Drittpartei tauschen untereinander ein Geheimnis (Secret) aus, das jeder kennen muss, um mit dieser API interagieren zu können. Leider kann ein Geheimnis, genauso wie ein Passwort oder eine wissensbasierte Authentifizierungsfrage, enträtselt werden. Diese Basisstufe der API-Sicherheit ist unzureichend, weil Unternehmen in der Regel keine Kontrolle über die Sicherheitsprotokolle der Drittanbieter und aller mit ihnen verbundenen Entitäten haben. Eine einzige Sicherheitslücke bei einer Drittpartei kann einen API-Exploit bei allen verbundenen Unternehmen zur Folge haben.

Nehmen wir das Beispiel einer Bank, die mit einer API-Verbindung zu einer Drittpartei arbeitet, die Zahlungsverkehr anbietet. Es ist vorstellbar, dass dieser Zahlungsdienstleister von einem Cyberkriminellen gehackt wird, der es auf die Daten der Bank abgesehen hat. Dabei spielt es in diesem Fall keine Rolle, ob diese API exponiert ist oder nicht: Wenn der Hacker in eine Drittpartei eingedrungen ist und das gemeinsame Geheimnis kennt, kann er über die API auf die Bankdaten zugreifen, indem er sich als Zahlungsanbieter ausgibt und infolge auf alles zugreifen, was die Bank für den Zahlungsanbieter bestimmt hat. Schlimmer noch: Ein geschickter Hacker kann die Verbindung, sobald er Zugriff hat, auf mehrere Weisen manipulieren, indem er die Objekt-IDs innerhalb der API verändert, um so Zugang zu weiteren Informationen zu erhalten oder sogar bösartige Daten oder Befehle einschleust, die als Parameter oder Datei-Uploads getarnt sind.

Wie oben bereits erwähnt, sind Angriffe dieser Art recht häufig. Aufgrund der Beschaffenheit der Wertschöpfungskette im Finanzbereich ist es leider ausgeschlossen, auf API-Verbindungen zu verzichten. Unternehmen müssen stattdessen den Basisschutz der Kanalverschlüsselung und der gemeinsamen Geheimnisse erweitern, wenn sie sich vor den Gefahren der Wertschöpfungskette schützen wollen.

API-Gateways sind das nächste Schutzlevel für die APIs eines Finanzinstituts und erschweren den Hackern das Schlüpfen durch Lücken – obwohl auch sie keine umfassende Sicherheit bieten. Warum ist das so? Gateways übernehmen einige nützliche Aufgaben, indem sie eine Governance-Funktion bereitstellen, die als Verbindungsbroker für Entitäten und als zentrale Stelle fungiert, die API-Anfragen weiterleitet, API-Antworten zusammenfasst und Service-Level-Agreements durchsetzt. Ein Gateway bietet Authentifizierungs- und Autorisierungsfunktionen, regelt den Datenverkehr, stoppt Denial-of-Service-Angriffe und bietet Telemetrie- und Analysefunktionen, mit denen Unternehmen die Nutzung ihrer APIs besser überblicken können.  

API-Gateways überprüfen jedoch nicht alle Daten, die zwischen den Endpunkten übertragen werden, was allerdings die Voraussetzung für den vollständigen Schutz der API wäre. Nehmen wir als Beispiel die Sicherheitskontrolle am Flughafen. Der Beamte prüft die Bordkarte und den Pass des Fluggastes, bevor er ihn durchwinkt. Diese Vorgänge sind vergleichbar mit der Konfiguration des API-Gateways und der Verwendung eines gemeinsamen Geheimnisses durch den Programmierer beim Herstellen einer Verbindung. Angenommen, der Pass und die Bordkarte sind echt – kann der Passagier dann direkt ins Flugzeug steigen?

Jeder, der schon einmal geflogen ist, weiß, dass dies nicht der Fall ist. Es reicht nicht aus, einen gültigen Ausweis und eine Bordkarte vorzuzeigen. Die Sicherheitskräfte am Flughafen kontrollieren, was der Fluggast am Körper und in seinem Gepäck mitführt. Ohne diese Kontrolle könnte man mit einem gültigen Reisepass und einer Bordkarte trotzdem etwas Gefährliches mit ins Flugzeug bringen. Daher wird das Handgepäck jedes Passagiers gescannt. Der Beauftragte, der die Inhalte prüft, hat schon Millionen von Reisenden passieren sehen. Er ist darin ausgebildet, nach Anomalien zu suchen, und mit geschultem Blick sondert er auffällige Gepäckstücke aus, damit sie genauer untersucht werden.

Aus diesem Grund ist das Prüfen von zwischen Endpunkten übertragenen Daten so außerordentlich wichtig.

Erinnern Sie sich an die hier zuvor erwähnten Sicherheitslücken? Nehmen wir an, unser Hacker hat eine vertrauenswürdige Drittpartei infiltriert und sich Zugang zum gemeinsamen Geheimnis verschafft. Nun ist es dem Cyberkriminellen gelungen, sich als scheinbar autorisierter Benutzer beim API-Gateway der Bank zu authentifizieren. Dies kann zur unerwünschten Offenlegung von Daten, zur Übernahme von Konten oder sogar zur Änderung oder Löschung von Informationen führen, welche die Bank nie weitergeben wollte. Der Hacker könnte auch versuchen, bösartigen Code oder Befehle in die API einzuschleusen, indem er sie in vertrauenswürdigen oder erwarteten Inhalten versteckt. Wir haben hier nur ein paar der häufigsten Angriffsarten aufgezeigt, bei denen eine Schwachstelle in der Wertschöpfungskette für das Eindringen in ein Finanzinstitut genutzt wird.

Wenn zur Kontrolle nur das gemeinsam genutzte Geheimnis und das API-Gateway verwendet werden, können solche Angriffe zunächst unentdeckt bleiben. So ist der Schaden bereits entstanden, wenn die Bank den Angriff durch das Parsen der vom Gateway gelieferten Analysedaten entdeckt. Um auf diese Bedrohungen in Echtzeit reagieren zu können, benötigt das Unternehmen eine Lösung für API-Sicherheit, die den Datenverkehr zwischen den Endpunkten prüft, Anomalien direkt erkennt, das zuständige Sicherheitsteam alarmiert und sofort Maßnahmen ergreift.

Finanzinstitute setzen immer stärker auf APIs beim Aufbau ihrer Finanz-Ökosysteme und können nicht blind darauf vertrauen, dass Programmierer in diese Verbindungen effiziente Sicherheitsmaßnahmen integriert haben. Fakt ist, dass es für die Entwickler selbst bei einer starken Fokussierung auf Sicherheit praktisch unmöglich ist, jedes potenzielle Sicherheitsszenario im ursprünglichen Code zu berücksichtigen. Auch die Annahme, der Schutz der API-Gateways sei ausreichend, ist irreführend.

Wir bei Ping Identity wissen, wie wichtig APIs für den Erfolg Ihrer digitalen Initiativen sind, und wir wissen auch, dass Sie sich mit den Risiken in der Wertschöpfungskette auseinandersetzen müssen. Unsere Lösung für die Sicherheit und Intelligenz von Finanz-APIs funktioniert wie der Gepäckscanner am Flughafen im oben genannten Beispiel. Sie nutzt maschinelles Lernen, um die Daten zu beobachten, um Normalität zu erlernen, Sicherheitsteams bei Anomalien und schlechtem Verhalten zu alarmieren und um im Falle eines Angriffs sofort gezielte Maßnahmen zu ergreifen.

APIs sind die Zukunft der digitalen Dienstleistung, und Cyberkriminelle werden immer neue und kreative Wege finden, um sie zu missbrauchen. Finanzinstitute müssen ihre Schutzschilde verstärken, und Ping Identity kann dabei helfen.

Sie möchten tiefer in dieses Thema einsteigen? In unserem Whitepaper Die Notwendigkeit von API-Sicherheit und Governance finden Sie weitere Informationen.