The more business uses apps, the better you have to be able to rely on APIs. APIs offer numerous industries, such as financial services providers, the opportunity to deepen customer dialogue and thus strengthen customer loyalty. So it’s hardly surprising that APIs are almost ubiquitous today. But despite their undeniable benefits, they also provide direct access to valuable enterprise data, making them an increasingly popular and critical attack vector.

The closer lifestyle, financial management and budgeting apps are interwoven by APIs, the more critical it is to ensure the security of this integration and the protection of each API’s back-end resources. However, few security specialists and virtually no Identity and Access Management (IAM) solution provider have really addressed API-based security threats.

Common API security issues

One of the main problems with API security is the lack of transparency. Many organizations find it difficult to clearly identify all their sensitive data, network resources, databases or SaaS applications. They often don’t know how many APIs they have, what versions are in use, what traffic is flowing through them, and who is using them. “API sprawl” is a growing problem. A recent survey by One Poll found that companies manage an average of 363 different APIs and that over two-thirds of these companies make their APIs available to the public.

Another problem with API security is verifying that the data accessed through an API is compliant and that the user behind the API is actually who he claims to be. Bots and DDoS attacks on APIs are also very critical.

API hacks on the rise

So it is not surprising that attacks that directly target APIs are on the rise. McDonald’s, for example, used an app that revealed important user information about its mobile delivery app, including name, email address, phone number, mailing address, and social media links. Panera Bread, [24]7.ai, T-Mobile, Instagram, Salesforce, the IRS*, Facebook, Twitter, Buffer, and Snapchat are all examples of organizations that have fallen victim to data breaches due to unsafe APIs.
*Internal Revenue Service

Protect APIs

So what is to be done to reliably protect APIs?

Traditional methods for API protection include WAF-based approaches that look for common attack types, such as cross-site scripting. API gateways are also widely used. Rate limiting is used primarily to prevent DDoS attacks. However, these approaches are often not very helpful for so-called “low-and-slow” attacks, which remain below the limits of the rate limit.

In addition, attacks that use credential stuffing, stolen cookies or tokens are more difficult to detect, since the corresponding activities seem to originate from normal users. Here, an identity and analysis-based approach to securing APIs can be helpful to define a normal level of API behavior. You can then look for any conspicuous behavior patterns. In this way, attacks can be uncovered that cannot be detected with other methods. AI and machine learning, especially unmonitored machine learning, can be very helpful in tracking API activity, identifying abnormal behavior, and detecting attacks without manually creating policies or signatures.

Identity-based approaches can also help verify the identity of people or systems attempting to access an API. Also, the EU’s new Payment Services Directive, PSD2 , requires stringent user authentication with at least two factors before granting API access.

And that’s a good thing, because according to twofactorauth.org only a surprisingly small number of consumer websites offer two-factor authentication as an option at all.

But not only the identity of accessing users or systems should be verified. An API security solution must also be able to use policies to determine what each individual user can access. In principle, this is a policy-based governance feature.

As mentioned earlier, one of the key issues with API security is a lack of visibility. Therefore, an API security solution should always be able to automatically detect APIs and determine what type of traffic each API is used for.

API deposition technology can also be very useful as it allows attackers to be exposed to the dummy environment without interacting with active APIs.

IBM expands security services further

IBM again invests heavily in IT security. With a “novel” threat protection system and data protection services, Big Blue is fighting the rising number of cyber attacks. The aim is to prevent attacks before they can cause damage.

The “IBM Threat Protection System” on the one hand and the “Critical Data Protection Program” on the other have largely emerged from takeovers in recent years. Q1 Labs, Trusteer, Guardium, Ounce Labs, Watchfire, Fiberlink/MaaS360 – all of them have been purchased by IBM and have since been merged into the security unit they built at the end of 2011. As a result, the Group is now at the forefront of the IT security market, with double-digit growth in each of the last six quarters.

With the Threat Protection System, IBM now introduces a concept that uses analytical and forensic software to detect and respond to cyber attacks – in the best case so early that no damage occurs in the first place. The system consists of several individual measures such as the Trusteer Apex solution to block malware at the endpoint. For example, quarantine measures, but also new sandboxing features, come into play here. In order to detect attacks faster, IBM has further developed its “Radar Security Intelligence” platform, which helps users, for example, to fend off attacks conveniently at the click of a mouse. In the area of active defense, the “Security QRadar Incident Forensics” solution is available when it comes to identifying and tracking attack patterns in order to better defend against similar attacks in the future.