PSD2's API Wave Will Pump up the Security Risk

January 4, 2018 Stephen Singam

Note: This is a post was originally found on PaymentsSource, the leading news and Resource for payments and financial-service professionals.

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 Get Transcript API used by the IRS’s browser-based remote access app was breached by systematic bot attacks.

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.

About the Author

Stephen Singam

Stephen Singam is Managing Director of Security Research at Distil Networks. He's a veteran Information Security & Technology Management professional with extensive experience in the Financial Services, Healthcare, Media & Entertainment and Cybersecurity Consulting industries, having held senior cybersecurity positions at Hewlett Packard (Asia Pacific & Japan), Commonwealth Bank of Australia (Sydney), 20th Century Fox/News Corporation (Los Angeles), Salesforce.com (San Francisco), IBM Corp (New York City & Singapore) and Nokia (Helsinki, Finland).

More Content by Stephen Singam
Previous Article
2017 WFiT Scholarship Recipient: Jenny Ramirez
2017 WFiT Scholarship Recipient: Jenny Ramirez

Meet 2017 recipient Jenny Calderon. Beginning as a child her passion for discovering “how things work” enco...

Next Article
Ecommerce Websites are a Major Target for Bad Bots
Ecommerce Websites are a Major Target for Bad Bots

Bad bots makeup 21.4% of traffic on ecommerce sites. When you consider the goals of any bot operator it is ...