| Open Banking hat glänzende Zukunftsaussichten in Verbindung mit dem richtigen Sicherheitskonzept für APIs. | With the right security concept, open banking has a bright future. |
| Open Banking steht für den Zugang zu personenbezogenen Daten und auch Produktdaten über Unternehmensgrenzen hinweg, mit Zustimmung des Kunden. Die BaFin definiert Open Banking wie folgt: „Konkret sind unter dem Begriff Open Banking meist die durch die Vorgaben der Zweiten Zahlungsdiensterichtlinie (Payment Services Directive 2 – PSD 2) in das Gesetz über die Beaufsichtigung von Zahlungsdiensten (ZAG) eingeführten Erlaubnis- beziehungsweise Registrierungstatbestände der Zahlungsauslöse- und Kontoinformationsdienste gemeint. Verkürzt ermöglichen diese Dienste die Nutzung technischer Schnittstellen zum Abruf von Zahlungsverkehrsdaten und zur Auslösung von Zahlungsaufträgen bei kontoführenden Instituten über Dritte, sofern die Kundin oder der Kunde dies veranlasst.“ Open Banking stellt ein transformatives Potenzial für die Finanzbranche dar. Der beträchtliche Anstieg der Open-Banking-Transaktionen auf 11,4 Millionen Zahlungen im Juli 2023 mit einem beeindruckenden Wachstum von 102 % gegenüber dem Vorjahr ist ein Beleg für die rasche Akzeptanz des Systems im United Kingdom. Politische Entscheidungsträger und Führungskräfte in Finanzdienstleistungs- und Fintech-Unternehmen kommen nicht umhin, sich hierbei auch mit allen wichtigen Sicherheitsmaßnahmen auseinanderzusetzen. Schwachstelle offene API beseitigen „Die Zukunft des Open Bankings (offenes Bankwesen) wird in den nächsten Jahren einen bedeutenden Aufschwung erleben. Viele Unternehmen beeilen sich Open Banking-APIs zu implementieren. Wenn Finanzinstitute jedoch keinen Eklat erleben wollen, sollten sie eine API-Sicherheitsstrategie entwickeln, bevor sie mit der Skalierung beginnen. Wir bieten jetzt sogar eine kostenlose Plattform, um die Sicherheitsüberwachung der APIs zu starten. Mit der Einführung von Graylog API Security V3.6 haben Unternehmen volle Funktionsparität, um die Vorteile der Überwachbarkeit ihrer APIs zu nutzen,“ geht Andy Grolnick, CEO vom Security-Anbieter Graylog, ins Detail. Viele Unternehmen haben keinen vollständigen Einblick in ihre bestehenden APIs. Offene Bank-APIs verbreiten sich in einem Tempo, das schneller ist als die Fähigkeit der DevOps-Teams, Patches zu veröffentlichen oder mit ihrem API-Bestand Schritt zu halten. Da der Sektor zu einem API-First-Ansatz übergeht, wird der Versuch, in einem späteren Entwicklungsstadium Einblick in APIs zu erhalten, zu einer großen Herausforderung. „Mit der zunehmenden Anzahl von APIs im Open Banking steigt auch die Komplexität der Beziehungen zwischen allen APIs in einem Netzwerk. Die meisten APIs sind voneinander abhängig und nutzen sich gegenseitig, um Funktionen auszuführen. Eine verwundbare API zu finden, ist wie die Suche nach einer Nadel im Heuhaufen,“ so Grolnick weiter. „Nehmen Sie zum Beispiel den Angriff auf Optus, bei dem ein ungeschützter API-Endpunkt dazu führte, dass die persönlichen Daten von 10 Millionen Kunden offengelegt wurden. Wenn Finanzinstitute diese Lücken in der Transparenz jetzt schließen, können sie das Problem in den Griff bekommen, bevor es außer Kontrolle gerät.“ Proaktive API-Sicherheit und -Governance sind für den Erfolg von Open Banking entscheidend „Die Institute müssen eine Bestandsaufnahme der bestehenden APIs vornehmen und robuste Kontrollen für neue APIs einführen. Überwachung, Zugriffsmanagement und Testmethoden, die auf APIs zugeschnitten sind, sind erforderlich. Werden API-Schwachstellen nicht frühzeitig behoben, kann das sensible Kundendaten, das Vertrauen in die Technologie und die Zukunft des Open Banking gefährden. Es ist daher wichtig, dass Finanzinstitute heute Maßnahmen ergreifen, um Transparenz und Kontrolle über ihre API-Landschaft zu erlangen,“ rät Grolnick. Eine gute API-Sicherheitsstrategie basiert auf drei grundlegenden Bausteinen, die einen TDIR-Ansatz (Threat Detection and Incident Response) zur Beseitigung von Cyberbedrohungen ermöglichen.
Effektives API-TDIR und API-Governance gehen Hand in Hand. Eine gute Governance bedeutet, dass DevOps-Teams Wege finden, um bestehende APIs zu entdecken, und dass sie Richtlinien und Standards für die Funktionsweise von API-Eigenschaften festlegen, die bei jeder weiteren API-Entwicklung angewendet werden. Sobald Richtlinien für API-Designstandards, Sicherheitsmaßnahmen, Dokumentationsanforderungen und Nutzungsrichtlinien festgelegt sind, müssen Prozesse für die Verwaltung des API-Lebenszyklus eingeführt werden. Damit wird sichergestellt, dass APIs kontinuierlich aktualisiert werden, die richtigen Nutzer Zugang zu ihnen haben und APIs verschiedene gesetzliche Rahmenbedingungen und Datenschutzstandards einhalten. Eine ausgereifte API-Verwaltung verwandelt Erkenntnisse in umsetzbare KPIs und Analysen zur Bewertung der Sicherheitslage. Von dort aus können Unternehmen die Ergebnisse nutzen, um die API-Sicherheit durch messbare Fortschrittsverfolgung kontinuierlich zu verbessern.
API-Sicherheit erfordert eine enge Zusammenarbeit zwischen Entwicklungs- und Sicherheitsteams, doch viele Unternehmen kämpfen mit isolierten Teams und unklaren Zuständigkeiten. DevOps konzentrieren sich auf schnelle Innovation und verlassen sich darauf, dass die Sicherheitsteams Schwachstellen identifizieren, während die Sicherheitsteams erwarten, dass die Entwickler Abhilfemaßnahmen implementieren. Der Mangel an Klarheit führt dazu, dass API-Sicherheit oftmals noch unzureichend Beachtung findet und es an der Umsetzung mangelt. „Da APIs das Bindegewebe zwischen Anwendungen, Systemen und Benutzern bilden, stellt eine fehlende teamübergreifende Abstimmung zur API-Sicherheit ein erhebliches Risiko dar. Dies verlangsamt die Erkennung und Behebung von Schwachstellen, die Angreifer ausnutzen können, um in wertvolle Daten einzudringen und Dienste zu unterbrechen,“ erläutert Grolnick. „Um hier Abhilfe zu schaffen, müssen Unternehmen ein gemeinsames Verantwortungsgefühl für die API-Sicherheit zwischen Entwicklungs- und Sicherheitsteams fördern. Prozesse wie regelmäßige gemeinsame Überprüfungen von APIs und Bedrohungsmodellen können dabei helfen, die Teams auf ein gemeinsames Ziel auszurichten.“ Das Sicherheitsteam sollte entwicklerfreundliche Anleitungen für die Gestaltung sicherer APIs bereitstellen, während die Entwickler die empfohlenen Kontrollen und Praktiken umsetzen. Durch die Verbesserung der Zusammenarbeit können Finanzunternehmen operative Lücken schließen, die es ermöglichen, dass API-Schwachstellen die Integrität ihrer Dienste gefährden. Gemeinsame Verantwortung über den gesamten Software-Lebenszyklus hinweg ist für einen soliden API-Schutz unerlässlich.
Da APIs allgegenwärtig sind, ist ein reiner Perimeter-Ansatz unzureichend. Angreifer sind sehr geschickt darin, sich durch Social Engineering und den Kauf von Zugangsrechten authentifizierten Zugang zu verschaffen. Auch Insider-Bedrohungen stellen ein großes Risiko dar, da autorisierte Benutzer ihre Privilegien absichtlich missbrauchen. Infolgedessen können herkömmliche Web Application Firewalls (WAFs) bösartige Aktionen von authentifizierten Benutzern nicht erkennen, da ihre Anfragen gültig erscheinen. Die Sicherung von APIs erfordert eine mehrschichtige Strategie, die Bedrohungen jenseits des Perimeters identifiziert. So helfen beispielsweise Multi-Faktor-Authentifizierung, erweiterte Überwachung und Privilegienverwaltung dabei, den Zugriff von Insidern zu beschränken. Kontrollen auf Anwendungsebene bieten einen Einblick in die vollständigen Nutzdaten von Anfragen und Antworten, um Anomalien zu erkennen. Dies unterstützt die Erkennung unbekannter Bedrohungen, die den Perimeter-Schutz umgehen, indem sie innerhalb der erwarteten Parameter operieren. „Im Wesentlichen müssen Finanzinstitute einen mehrschichtigen API-Schutz implementieren, der die Perimeter-, Netzwerk-, Anwendungs- und Datenebenen umfasst, da das alleinige Verlassen auf Netzwerkkontrollen ein falsches Gefühl von Sicherheit vermittelt. Ein ganzheitlicher API-Sicherheitsansatz schützt sowohl vor externen als auch vor internen Bedrohungen,“ betont Grolnick abschließend. Der Blick in die Glaskugel Die Zukunft des Open Banking ist vielversprechend, da die Akzeptanz zunimmt und die Behörden Wachstumsinitiativen unterstützen. Die Kunden könnten von mehr Transparenz, Kontrolle und innovativen Dienstleistungen profitieren. Der Fortschritt hängt jedoch von der Bewältigung einer Reihe von Herausforderungen ab, wobei die Sicherheit ganz oben auf der Liste steht. Wenn der Finanzdienstleistungssektor in der Lage ist, die API-Sicherheit durchgängig zu gewährleisten, kann Open Banking ein offeneres, kooperativeres und kundenorientierteres Finanzökosystem ermöglichen. | Open Banking stands for access to personal and product data across company boundaries, with the customer’s consent. BaFin defines Open Banking as follows: „In concrete terms, the term Open Banking usually refers to the authorization or registration facts of payment initiation and account information services, which were introduced into the German Payment Services Act (ZAG) by the requirements of the Second Payment Services Directive (Payment Services Directive 2 – PSD 2). In short, these services enable the use of technical interfaces to retrieve payment transaction data and to initiate payment orders at account-holding institutions via third parties, provided that the customer initiates this“. Open Banking has the potential to transform the financial sector. The significant increase in open banking transactions to 11.4 million payments in July 2023, with an impressive 102% year-on-year growth, is testament to the rapid adoption of the system in the UK. Policymakers and executives in financial services and fintech companies cannot avoid addressing all the key security measures. Addressing the vulnerability of the open API „The future of open banking is set to take off in the next few years. Many companies are rushing to implement open banking APIs. However, if financial institutions don’t want to experience a scandal, they should develop an API security strategy before they start scaling. We now even offer a free platform to get started with API security monitoring. With the launch of Graylog API Security V3.6, organizations have full feature parity to take advantage of the monitorability of their APIs,“ said Andy Grolnick, CEO of security vendor Graylog. Many organizations lack complete visibility into their existing APIs. Open banking APIs are proliferating faster than the ability of DevOps teams to release patches or keep up with their API inventory. As the industry moves to an API-first approach, trying to gain visibility into APIs at a later stage of development becomes a significant challenge. „As the number of APIs in open banking increases, so does the complexity of the relationships between all the APIs in a network. Most APIs are interdependent and use each other to perform functions. Finding a vulnerable API is like looking for a needle in a haystack,“ Grolnick continued. „Take the attack on Optus, for example, where an unprotected API endpoint resulted in the exposure of 10 million customers‘ personal information. By closing these visibility gaps now, financial institutions can get a handle on the problem before it gets out of hand.“ Proactive API Security and Governance is Critical to the Success of Open Banking. „Institutions need to take stock of existing APIs and implement robust controls for new APIs. API-specific monitoring, access management and testing methodologies are required. Failure to address API vulnerabilities early can put sensitive customer data, trust in technology and the future of open banking at risk. It is critical that financial institutions take action today to gain visibility and control over their API landscape,“ said Grolnick. A good API security strategy is based on three fundamental building blocks that enable a Threat Detection and Incident Response (TDIR) approach to eliminating cyber threats.
Effective API TDIR and API governance go hand-in-hand. Good governance means that DevOps teams find ways to discover existing APIs and establish policies and standards for how API properties work, which are applied to all further API development. Once policies are established for API design standards, security measures, documentation requirements, and usage guidelines, processes must be put in place to manage the API lifecycle. This ensures that APIs are continually updated, that the right users have access to them, and that APIs comply with various regulatory and privacy standards. Advanced API management turns insights into actionable KPIs and analytics to assess security posture. From there, organizations can use the results to continuously improve API security by tracking measurable progress.
API security requires close collaboration between development and security teams, but many organizations struggle with siloed teams and unclear responsibilities. DevOps focuses on rapid innovation and relies on security teams to identify vulnerabilities, while security teams expect developers to implement mitigations. The lack of clarity means that API security is often still not given enough attention, and implementation is lacking. „Because APIs are the connective tissue between applications, systems, and users, a lack of cross-team alignment on API security is a significant risk. It slows down the detection and remediation of vulnerabilities that attackers can exploit to penetrate valuable data and disrupt services,“ said Grolnick. „To remedy this, organizations need to foster a shared sense of responsibility for API security between development and security teams. Processes such as regular joint reviews of APIs and threat models can help align the teams around a common goal.“ The security team should provide developer-friendly guidance on how to design secure APIs, while developers implement the recommended controls and practices. By improving collaboration, financial organizations can close operational gaps that allow API vulnerabilities to compromise the integrity of their services. Shared responsibility throughout the software lifecycle is essential for strong API protection.
Because APIs are ubiquitous, a perimeter-only approach is insufficient. Attackers are very adept at gaining authenticated access through social engineering and buying credentials. Insider threats also pose a significant risk as authorized users deliberately abuse their privileges. As a result, traditional Web application firewalls (WAFs) cannot detect malicious actions by authenticated users because their requests appear valid. Securing APIs requires a layered strategy that identifies threats beyond the perimeter. For example, multi-factor authentication, advanced monitoring, and privilege management help limit insider access. Application-level controls provide visibility into the full payload of requests and responses to detect anomalies. This helps detect unknown threats that evade perimeter protection by operating within expected parameters. „Essentially, financial institutions need to implement layered API protection that includes the perimeter, network, application and data layers, as relying solely on network controls provides a false sense of security. A holistic approach to API security protects against both external and internal threats,“ concludes Grolnick. Looking into the crystal ball The future of open banking is promising as adoption grows and regulators support growth initiatives. Customers could benefit from greater transparency, control and innovative services. However, progress depends on overcoming a number of challenges, with security at the top of the list. If the financial services sector can ensure API security across the board, open banking can enable a more open, collaborative and customer-centric financial ecosystem. |
| Arne Lehfeldt, Systems Engineer und CTO Ambassador bei Dell Technologies, erklärt im Podcast Security, Storage und Channel Germany mit Carolina Heyder, warum Unternehmen keine Angst vor KI haben sollten. | Arne Lehfeldt, Systems Engineer and CTO Ambassador at Dell Technologies, explains why companies shouldn’t be afraid of AI in the Security, Storage and Channel Germany podcast with Carolina Heyder. |
Dr. Jakob Jung ist Chefredakteur Security Storage und Channel Germany. Er ist seit mehr als 20 Jahren im IT-Journalismus tätig. Zu seinen beruflichen Stationen gehören Computer Reseller News, Heise Resale, Informationweek, Techtarget (Storage und Datacenter) sowie ChannelBiz. Darüber hinaus ist er für zahlreiche IT-Publikationen freiberuflich tätig, darunter Computerwoche, Channelpartner, IT-Business, Storage-Insider und ZDnet. Seine Themenschwerpunkte sind Channel, Storage, Security, Datacenter, ERP und CRM.
Dr. Jakob Jung is Editor-in-Chief of Security Storage and Channel Germany. He has been working in IT journalism for more than 20 years. His career includes Computer Reseller News, Heise Resale, Informationweek, Techtarget (storage and data center) and ChannelBiz. He also freelances for numerous IT publications, including Computerwoche, Channelpartner, IT-Business, Storage-Insider and ZDnet. His main topics are channel, storage, security, data center, ERP and CRM.
Kontakt – Contact via Mail: jakob.jung@security-storage-und-channel-germany.de