Open Banking PTBR

Many banks have standard HTTPS encryption, tokens, OAuth2 and 2-factor authentication already in place for their API security management. However, the majority of banks do not feel that this is yet enough to ensure ongoing protection of customer data. 76% of survey respondents are experimenting and testing additional security measures, with OAuth 2, 2-factor or multifactor authentication, HTTPS encryption, OpenID Connect and biometrics being considered by at least a third of respondents. "The recent API-based breaches at Google and Facebook were a wake up call for many enterprises," says Bernard Harguindeguy, CTO at Ping Identity. "If these organizations, which are considered to have top technical talent, were breached via attacks that exploited APIs then it could happen to all of us. It took 14 months for one to discover the breach, so it begs the question and makes me wonder that others are already under attack and just don't know about it yet." Harguindeguy believes this uncertainty is one of the drivers for testing new API security methods. "I believe most are realizing that access control is not enough to secure an API and that more is needed. That has raised the interest in securing APIs and, I venture to say, that every bank will fund projects to explore, identify and deploy solutions that address the cybersecurity needs of their API infrastructure — especially in the context of PSD2 and Open Banking projects." Harguindeguy believes API security introduces particular new threats to open banking systems, but that many banks are aware of these risks and are now pursuing new technological solutions to counter these security challenges. "It starts with the recognition that API based attacks are a new breed of sophisticated attacks — sometimes using AI and automation extensively. This is no longer about a SQL injection or XSS attack. It's about reverse engineering APIs to identify how to best get to data and applications. It's about attacking the credential system to log in with a stolen identity, stolen token or stolen cookie. It's about the theft of data and private information via APIs, and about disabling APIs with finely tuned, low volume, targeted DDoS attacks. I believe that most banks are tackling this right now and assembling teams to identify and deploy solutions. This has become a board-level discussion for many. Leadership is about recognizing the issues upfront and assembling teams that can provide guidance on proper API design security techniques, and recommend solutions to deploy that can track every activity on an API and identify and block threats and abuses." One banking executive explained their current security approach: "In terms of opening up our customer transactions via API, that for us was much more about customer security. In the past, we have been able to detect screen scrapers that were going through customer information, and that was a huge concern for us. We realized that was dangerous for our customers, so it became necessary to provide relevant APIs so that those who provide a great 360 view product to our customers, like some finance management software providers, that they can get the customer consented information through OAuth. Everyone at the bank saw the security problem so APIs helped solve that." Another banking executive spoke of how security is managed as part of the governance process: "When we create new APIs, the line of business department owner must fill in a risk return decision matrix and make a security statement on it. We ask about measures for security against penetration, and for risk management. If sufficient security measures are in place and everyone agrees, we can release the API." 23 The BanKIng SecuRITy STacK

• Cover