Awareness of the need to protect APIs has increased, but the actual situation is not alarming (Photo: Dreamstime)
By Shay Rappaport, Director of Information Security Services at ITway
The Israeli regulator recently adopted the European regulation, which requires banks and financial institutions to allow the development of external solutions on their platforms through the accessibility of APIs. This means that banks, credit companies and other financial entities will be required to make their systems accessible through an API to any third party that the Bank of Israel approves, and in fact make it possible to build applications for financial services that will be based on the information, operations and infrastructure of these financial entities.
For example, companies will be able to build payment, lending and consulting applications without having to enter into a commercial contract, obtain authorization from the bank and perform complex integrations with its systems. The Bank of Israel will approve those companies and it is the consumer who will approve the use of his details.
So where is the problem?
The first part of the regulations, requiring banks to provide API access to current account and credit card data, went into effect in June of this year. In October, a regulation requiring access to loan and savings data will also come into effect. It is likely that in the coming years we will see dozens of applications and online services authorized to access this sensitive information using millions API calls between them and the banks every day. In general, the trend of making operations and information accessible has long since turned most of the HTTPS requests at any given moment on the Internet into API requests. According to Gartner, in 2022 most attacks will also move to this front.
Although the awareness of the need to protect APIs has increased, many entities still use WAF or API Gateway that includes security components for the purpose of protecting APIs, but the use of these tools does not meet all the expected challenges in managing, maintaining and securing API interfaces. A significant number of organizations do not have a comprehensive catalog of their APIs, there is no mapping of the sensitive information that passes through them or an overview that allows you to see if all the interfaces are managed and that their configuration is properly protected.
The protection capabilities of WAF or API Gateway are also limited, because these tools work with the traditional methods of comparing each individual request to a set of rules (Positive/Negative) in order to identify attacks. In this way of operating it is impossible to detect sophisticated attacks, where each individual request looks completely legitimate, but together create an attack at the Business logic level. In addition, these tools do not learn or improve API security and do not provide feedback to developers, so over time the vulnerabilities are effectively left open. The need for a dedicated API tool is becoming more and more important.
This is how you choose the right API protection tool
Due to this growing need, several companies specializing in the security management of API interfaces have sprung up in recent years, most of them founded by Israeli entrepreneurs. Due to the trends of communication switching to APIs in general and open banking in particular, the adoption curve of these tools is on the rise. Startups that identified the problem in time and adapted a comprehensive and effective solution to it became unicorns almost overnight.
With the multitude of new solutions and their addition to older generation solutions in the form of WAF or API Gateway, the question becomes more acute: how to choose the right protection tool for your organization?
1. Cloud or no cloud: Is your organization authorized, able and willing to export communication data to an external cloud of a security service provider? If the answer is no, it is important to choose a solution whose components, including the analysis engine, can be installed on-prem without transferring any data or meta-data to the cloud.
2. Mapping: Organizations tend to think that all their APIs are known and managed, but in the vast majority of cases the organization does not manage or secure between 20% and 30% of all its APIs. Therefore, it is critical that the solution be able to connect to several strategic points in the network, gain visibility on everything that passes through the corporate network and identify and map all API traffic, catalog it, report on unmanaged APIs, configuration problems, authentication, and the like. It is important to remember that a proxy solution located only at a single point cannot do the magic.
3. Identifying attacks at the Business logic level: Identifying “noisy” attacks as well as attacks of deviation from the standard data structure is quite simple. The point is that APIs are vulnerable to more complex attacks, such as BOLA. It is imperative to choose a tool that can effectively understand what is a legitimate flow of requests and responses, and identify anomalies that constitute an attack at the level of business logic and neutralize them immediately, without creating noise of false positives.
4. Hardening: It is not advisable to leave loopholes in the API and rely only on the protection layers. A good product will know how to diagnose the loopholes and create test tools for the development and CI/CD environments, in order to identify and close loopholes at this stage.
The business reality and regulatory dictates force organizations to reveal more and more information and the possibility of performing actions through APIs. The problem is that the old protection and monitoring tools do not allow the organization to see all its APIs and certainly not protect them well. Organizations that transmit sensitive information through APIs must take care not to leave shadow APIs and protect all APIs well even against sophisticated low and slow attacks. Only new generation dedicated API protection tools meet these requirements.