Open banking: Managing operational risk

For regular readers of my blog, it should be no surprise that I believe that strategic use of APIs are fundamental building blocks for digital transformation. However, opening up comes at a price. Unprotected APIs could provide a back door to data and critical systems open for criminals and individuals with malicious intent.

Without proper security, API weak points can expose customer data, backend system access, and even monetary systems to unauthorized access, opening up for several operational risks to both systems and businesses as a whole.

To put perspective on how difficult API security is, pretty much every major Internet company has had API security problems according to ProgrammableWeb. We may all remember such internet scandals as the Ashley Madison breach, where numerous adulterers where exposed, or when a bug in the Instagram APIs gave hackers access to the personal information of high-profile Instagram-users.

These are just two examples of born-digital companies stumbling in the API security department. When McDonalds rolled out its home delivery app, McDelivery (because, what else should they have called it), an API breach resulted in the exposure of personal information for 2,2 million users, including names, email addresses, phone numbers, home addresses and sometimes the coordinates of those homes, as well as links to social media profiles.

With PSD2 on the horizon, banks are told to open up their APIs to third parties, while at the same time the EU’s new data protection regulation, GDPR is setting strict requirements for consumer data protection, including some stiff consequences for those failing to comply with the regulation.

With this in mind, API security is an increasing concern for companies deploying public-facing APIs, as they provide multiple access points to the underlying infrastructure. A study from cyber security company Imperva reveals that 69 percent of companies have public-facing APIs which offer a route to the sensitive data behind applications.

One of the key challenges with APIs is that well-documented APIs often provide a roadmap describing the underlying implementation of an application. Logic and data structures that otherwise would be buried deep in a company’s architecture. According to a CA white paper on API security, this can give hackers valuable clues that could lead to attack vectors they might otherwise overlook. APIs tend to be extremely clear and self-documenting at their best, providing insight into internal objects and even internal database structure – all valuable intelligence for hackers.

While there are many attack vectors, a majority of analysts and data security experts point out a couple of top concerns. For casual readers, things might get a bit techy from here.

DDoS attacks are one of the primary concerns for IT leaders. A typical DDos attack floods a web application with an overwhelming amount of junk requests, forcing the application to eventually crash by overloading the underlying infrastructure. A poorly written API could use up a lot of computing resources if it starts receiving invalid inputs, and Netflix proved this by executing a sophisticated DDoS attack against themselves, resulting in an exploit that turned Netflix own API against itself, proving that security countermeasures should be constantly evolving.

Man in the middle attacks intercept legitimate transactions and exploit unsigned and/or unencrypted data being sent between the client and the server. The average end-users are the number one largest security risk an API can ever have. Thus, you must assume every user is a vulnerability. Implement password strength requirements, session length, and concurrent connection limitations, and even require periodic re-authentication and authorization for continued use. Track usage and account metrics, and respond to any deviation. Assume that even your best user is subject to hijacking and malicious redirection, and plan accordingly.

Parameter attacks exploit the data sent into an API, including URL, query parameters, HTTP headers, and/or post content. This could be performed in numerous ways. Providing an API with unexpected content, repeated requests or knowingly invalid input are all strategies to provoke a system response, providing useful information, which combined with already public API documentation and available metadata provides a blueprint for the underlying architecture. With enough information, hackers can inject the system with everything from executable files, SQL queries or method calls. In order to mitigate this, code quality should be a top priority. Feedback from exception handling and error messages must be written for API usage to prevent access to valuable system information. Validating input parameter and monitoring known parameter attack patterns should be prioritized.

Even if the technical risks are mitigated, API goverance must be designed with a risk perspective in mind. Appointing dedicated resources with backgrounds from both security and business development in charge of API usage is integral to maintain a balance between risk mitigation and innovation. This relates to both carefully selecting of who is given access to your APIs as well as continous monitoring of potential suspicious or unexpected behavior.

In summary, API security is hard, and even the best have failed at some point. This should act as a cautionary tale for banks eager to dive into open banking territory. Banks are dependent on trust, and safeguarding customer data is integral to maintain that trust.