API-Sicherheit ist zentral für Open Banking

Laut Radware kann eine schlecht gesicherte API eines der größten Risiken für ein Open-Banking-System darstellen. Auf der einen Seite würden die Schnittstellen große Vorteile mit sich bringen, auf der anderen könnten sie aber auch zu erheblichen Bedenken bezüglich Verfügbarkeit und Sicherheit führen.

Öffentlich zugängliche APIs zwischen den Anwendungen von Banken und FinTechs bilden das Rückgrat des Open Banking, so Radware (Website). Open-Banking-APIs sollten dem Bankkunden mehr Möglichkeiten bei der Auswahl von Finanzdienstleistern bieten und den Instituten neue Umsatzpotenziale und Kollaborations-Möglichkeiten eröffnen – nicht für Sicherheitsbedenken sorgen.

Zu den größten Problemen zählen laut Radware:

• Service-Unterbrechungen: Gemeint ist die Nichtverfügbarkeit von API-Diensten aufgrund von Sicherheits-, Netzwerk- und Anwendungskonfigurationsfehlern, API-Denial-of-Service-Angriffen oder Ausfällen der Anwendungs- oder Authentifizierungs-Infrastruktur.
• Fehlendes Vertrauen: Viele Lösungen für Open Banking würden auf einer reinen Cloud- oder Hybrid-Infrastruktur basieren. Die Migration zu öffentlichen Clouds führt jedoch zu Vertrauensproblemen aufgrund der Inkompatibilität von Sicherheitslösungen, Konfigurationsproblemen in verschiedenen Umgebungen, Fehlkonfigurationen und Problemen mit Anwendungssicherheits-Richtlinien und -Profilen.
• Erhöhte Angriffsfläche: API-Angriffe verschiedener Art seien relativ häufig. Eine Umfrage von Radware habe ergeben, dass 55 % der Unternehmen mindestens einmal im Monat einen DoS-Angriff auf ihre APIs erleben, 48 % mindestens einmal im Monat eine Form von Injektionsangriff und 42 % mindestens einmal im Monat eine Manipulation von Elementen/Attributen. Zu den weiteren Angriffen gehören API-Authentifizierungs- und Autorisierungs-Angriffe, eingebettete Angriffe wie SQL-Injection, Cross-Site Scripting (XSS) und Bot-Angriffe.
• Datendiebstahl: Viele APIs verarbeiten sensible personenbezogene Daten (PII). Die Kombination aus sensiblen und vertraulichen Informationen in Verbindung mit der mangelnden Transparenz der Funktionsweise dieser APIs und Anwendungen von Drittanbietern sei im Falle eines Verstoßes eine Katastrophe für die Sicherheit.
• Nicht dokumentierte, aber veröffentlichte APIs: Nicht dokumentierte APIs können versehentlich sensible Informationen preisgeben, wenn sie nicht getestet werden, und sie können offen für API-Manipulationen und die Ausnutzung von Sicherheitslücken sein.

API-Gateways und WAFs reichen nicht aus

Traditionell seien DDoS-Schutz, WAFs und API-Gateways die primären Sicherheitstools, die für den API-Schutz eingesetzt werden. Während API-Gateways die Möglichkeit der API-Verwaltung bieten würden und eine Integration mit Authentifizierungs- und Autorisierungs-Funktionen ermöglichen, sind ihre Funktionen für API-Sicherheit, Bot-Schutz und Webanwendungsschutz entweder begrenzt oder nicht vorhanden.

Die meisten WAFs verstehen die Unterschiede zwischen APIs und normalen Webanwendungen nicht. Und selbst wenn sie den Unterschied verstehen, können sie die tatsächlichen Sicherheitsrisiken im Zusammenhang mit APIs nicht untersuchen oder erkennen.“

Michael Gießelbach, Regional Manager DACH bei Radware

Eine Lösung für das Problem sei laut Radware eine Kombination von Sicherheitskontrollen, darunter:

• API-Zugangskontrollen für Authentifizierung, Autorisierung und Zugangsverwaltung
• Schutz vor BOT-Angriffen auf APIs
• Verhinderung von Denial-of-Service-Attacken
• Schutz vor eingebetteten Angriffen, API-Schwachstellen und API-Manipulationen
• Verhinderung des Abflusses von PII-Daten und der übermäßigen Offenlegung von Daten
• Schutz vor Betrug und Phishing

Insbesondere der Schutz von APIs vor automatisierten Angriffen unterscheide sich von dem Schutz von Web- und Mobilanwendungen, weil das Verhalten der Bots und die Indikatoren unterschiedlich sind. Das Fehlen spezieller Bot-Management-Tools in den meisten Unternehmen erhöhe das Risiko, dass Hacker erfolgreiche Angriffe über APIs starten, wie z. B. Credential Stuffing, Brute Force und Scraping-Versuche.ft