Banks are digitizing at a rapid pace to catch up with upstart fintech providers. Such rapid evolution can run the risk of introducing vulnerabilities, and the financial services industry is no different.
PSD2, the second iteration of the European Union’s Payment Service Directive, is scheduled to go into effect in January.
The directive is designed to create a level playing field for banks and nonbank financial services providers (fintechs) in the European Union by enabling third-party payment service providers to access customers’ account information. This in turn will enable those payment service providers to initiate payments through accounts at another payment service provider.
All of this requires the widespread use of open APIs to facilitate cross-access to account information. It’s great news for end users, but a potential nightmare for information security.
The banking industry is already heavily involved in API development to facilitate mobile banking, but opening up internal customer data directly to third parties introduces a whole other layer of potential vulnerabilities.
Fintechs like Amazon, PayPal and Zillow have a significant head start over banks in open API use, but they also have the breach history to prove it:
In November 2010, PayPal suffered critical API errors that prevented any transactions from being completed.
In June 2012, Amazon Web Services was hit by a huge increase in API errors after a power outage.
In August 2015, a security flaw in a Facebook API allowed hackers to decrypt and scan IDs, putting 1.44 billion users at risk of identity theft.
In February 2016, the
Ironically, being late to the game could turn out to be a benefit for traditional banks, as they have the opportunity to learn from early adopters’ mistakes. There are five broad lessons that can be drawn from these and other fintech breaches:
Lack of TLS/SSL: Even if an API key used for app authentication is disabled, a standard browser request will bring another key. By the same token, blacklisting IP addresses will not prevent bot attacks.
Encryption does not equal trust: HTTPS plus multiple robust access control methods (especially risk-based authentication) are needed, including OAuth, Mutual SSL authentication or certificate-based mutual authentication, or SAML tokens, to more effectively preserve API data integrity and confidentiality.
Life cycle key management: Pay particular attention to properly planned SSL certificate validation if you want to prevent fraudulent certificates from being used to gain read/write access to user data.
Business logic flaws: Attackers look for vulnerabilities in API design (this is how Facebook was exploited in 2015), so take care to manually audit APIs and always expose the least possible amount of data.
Insecure API endpoints: Banks tend to be heavy users of legacy systems, and tech staff may be reluctant to use the APIs those systems rely on for fear of breaking them. Harden endpoints early in the API development process to avoid this trap.
Taking a 360-degree view of API security is essential. This approach can be broken down into three parts:
Detection: One cannot protect an asset that one does not know. Know and track your API assets. Know your consumers and solidify their authentication. Know what access patterns for your APIs should look like, especially the versioning methodologies.
Prevention: Authentication is the essence of API management. Adopt OAuth 2.0, perhaps build OpenID Connect on top of OAuth, and choose the implementation that is most appropriate for the architecture and risk profile of your application. Enforce strong authentication at initial login, especially if you’re using SSO.
Mitigation: This is why you need to be familiar with typical API access patterns. Pattern anomalies can be fed into self-learning detection systems that use machine learning algorithms to improve protection for everyone.
