Designing a Secure Open Banking Environment 

Many of us use innovative products such as Mint, Chime or Venmo without really knowing that they are built on Open Banking APIs. 

Open Banking initiative is primarily driven by European regulation, Payment Services Directive 2 (PSD2), to open closed and proprietary deposit-taking banking customer data to external third-party providers (TPPs) securely through publicly available APIs. The objective is to spur both innovation and to increase competition. Unlike in traditional banking where all customer data is controlled by the parent bank, in Open Banking, the customer data is securely exposed to TPPs via APIs only when the consent is provided by the customer. Gartner predicts that by 2022, application programming interface (API) attacks will become the most-frequent attack vector, causing data breaches for enterprise web applications. The API security challenge requires threat coverage, easy integration and complete visibility for both documented and undocumented APIs.   

According to a 2018 Celent study, the number of U.S. financial institutions (FIs) that have open banking portals to facilitate TPP access to consumer financial and other data is expected to grow from 20 to over 200 by the end of 2021. As of the first quarter of 2020, there were over 300 TPPs registered in the U.K. Other countries, such as India and Australia, have followed the EU’s approach and have a thriving open banking ecosystem. 

Open Banking APIs – What Could Go Wrong? 

Prior to Open Banking, many innovative FinTech providers used screen scraping to gain access to customer data including user credentials without knowledge of the parent bank. Open Banking APIs move to streamline legal implications of sharing customer credentials and information though APIs, consent, and regulatory authority. 

While APIs bring tremendous benefits, they also introduce availability and security concerns such as: 

• Service disruption: API services unavailable due to security, network and application configuration errors, API denial of service attacks or application or authentication infrastructure outages. 
• Trust issues: Many solutions for OB are built on cloud-only or hybrid infrastructure. However, migration to public clouds creates trust issues due to incompatibility of security solutions, configuration challenges across different environments, misconfigurations and issues around application security policies and profiles.  

• Increased attack surface: API attacks of various types are fairly common. A survey by Radware revealed that 55% of organizations experience a DoS attack against their APIs at least monthly, 48% experience some form of injection attack at least monthly and 42% experience an element/attribute manipulation at least monthly. Other attacks include API authentication and authorization attacks, embedded attacks such as SQL injection, cross-site scripting (XSS) and Bot attacks. 
• Bot attacks on APIs: Bot attacks are automated programs scripted to breaking into user accounts, stealing identities, payment fraud, scraping content, pricing, coupons or data, spreading spam or propaganda and impacting business activities. 
• Data theft: Many APIs process sensitive personally identifiable information (PII). The combination of sensitive and confidential information coupled with the lack of visibility into how these APIs and third-party applications operate is a security nightmare in case of a breach. 
• Undocumented but published APIs: Undocumented APIs may accidently expose sensitive information if not tested and may be open to API manipulations and vulnerability exploits. 

[adbutler zone_id="276005"]

Isn’t my API Gateway and WAF sufficient? 

Because threats vary, API security requires a combination of security controls including: 

• API access controls for authentication, authorization and access management 
• Protecting from BOT attacks on APIs 
• Preventing DDoS & availability attacks 
• Protecting from embedded attacks, API vulnerabilities and API manipulations 
• Preventing leakage of PII data, and excessive data exposure 
• Protecting from fraud and phishing scams 

Traditionally, DDoS protection, WAFs and API gateways have been the primary security tools used for API protection. While API gateways offer API management and integration with authentication and authorization capabilities, their API security, bot protection and web application protection capabilities are either limited or absent.  Most WAFs do not understand the differences between APIs and regular web applications. Even if they do understand the difference, they do not inspect or detect the real security risks related to APIs. 

[You may also like: 4 Questions to Ask About Open Banking Compliance]

Bots are not always friendly or visible! 

APIs are also exposed to bot attacks. According to Forrester, more than a quarter of all web requests originate from bad bots. These bots were observed attempting automated attacks targeting APIs, such as account takeover, denial of service, payment data abuse, and denial of inventory. Protecting APIs against automated attacks is different from protecting web and mobile applications, simply because the bot behaviors, navigation flow and indicators are different. 

The lack of dedicated bot management tools in most organizations puts these organizations at greater risk for potential bad actors launching successful attacks through APIs, such as credential stuffing, brute force and scraping attempts.  

What’s required to secure Open Banking APIs? 

Radware solution is designed to secure APIs from hackers and nation-state attacks. The solution protects application APIs from denial of service, application and bot attacks, protect API against vulnerabilities and manipulations, prevent service disruptions while addressing trust and security concerns of customers migrating to a multi-cloud or hybrid deployment. 

Conclusion: 

Although Open Banking is still in its infancy, it is growing very rapidly. Open Banking opens customer data to external third-party providers via APIs to deliver innovative services. However, this also means a broader threat surface that needs to be protected against abuse and malice. Banks and fintech that thrive in this environment will deliver solutions that encourage customer trust through secure solutions. To know more on how Radware can help visit Frictionless Security At The Pace of Innovation | Radware

[Like this post? Subscribe now to get the latest Radware content in your inbox weekly plus exclusive access to Radware’s Premium Content.]