Cloud APIs - the Next Battleground for Denial-of-Service Attacks

by Mark O'Neill

In recent months, there have been a number of highly publicized cyberattacks on U.S. banks. These attacks took the form of Distributed Denial of Service (DDoS) attacks, involving enormous amounts of traffic being sent to Internet-facing banking services, rendering them unusable. These recent denial-of-service attacks focused mainly on the websites of banks and other financial institutions, bringing down their online banking services, inconveniencing users, losing revenue and damaging the financial institutions’ brand reputation. The attack surface of banks is changing, however. Increasingly banks are rolling out mobile apps to ensure improved customer service and loyalty. These mobile apps consume data via APIs in the Cloud. Given this scenario the next wave of DDoS attacks may very well target cloud these APIs in order to disable these mobile apps. A mobile app is “blind” without access to its APIs. In light of such risks, Chief Security Officers and their IT security team members need to come up to speed on both the threats posed to APIs and the very real impact an API disruption presents. This article examines strategies for protecting Cloud APIs against DDoS attacks. Let’s take a look at how mobile apps use APIs within a banking context. Similar to other mobile apps, mobile banking apps use APIs to perform actions and receive data. A DDoS attack would effectively disable access to the API. As mobile app penetration and usage grows, and bank customers use apps as their main channel to perform banking transactions, the impact an API attack can have on an economy grows exponentially. Customers are unable to pay bills, transfer money, or ensure they have funds to make purchases. In the recent cyber attacks on banks, users could initiate the mobile banking apps from their phone or tablet, but the apps could not “call home” to their banking systems so they could not connect to any account details, or even log into their account. Unlike the Website disruption, this API disruption is not directly visible to the end users. The perception of the attack is different because the app itself can still be launched on their phone or tablet. In fact, when confronted with a mobile banking app which has problems performing certain functions, a user may simply blame their mobile network, or assume they have lost coverage, rather than suspect the API has been compromised.

Protecting APIs

The recent DDoS attacks have highlighted the need to put measures in place to protect APIs. Going forward, we can envisage a scenario where rather than APIs only being taken down as a side effect of attacks on Websites, future attacks could be directed against APIs with a goal of taking out mobile applications. Ensure Distributed Deployment to Avoid Vulnerability

Today, it’s still quite common to have API protection grouped with Website protection. As APIs are still relatively quite new, it sometimes seems they are considered to come under the general rules of an organization’s Web resources. As such, there is a lot of focus on protecting the Website from DDoS or general attacks while neglecting to prepare for an API disruption and its impact on mobile applications. In the case of the recent banking DDoS attacks, the huge volume of data involved, meant there was little the banks could do to protect against the attacks. However, separating the hosting of APIs from the hosting of “traditional” Website resources may be one mitigating factor. This means that a DDoS attack against the Website may not have the side-effect of taking down the APIs used by mobile banking apps. Implement Policies (e.g. Identity and Throttling)

Additionally, the IT security team should be aware that APIs are different in terms of usage patterns, and in the type of traffic they receive. Whereas a website is accessed by a browser, an API is accessed by an app. This means that it makes sense to protect APIs using different policies. For example, the policy could dictate that a specific API could be accessed by particular users with defined throttling and security policies. Similarly, identity-based policy rules can be used to govern and secure APIs. This is the basis of “API Management”. Organizations should also consider implementing policies to control the availability and access to their APIs. Simply opening applications via APIs to the outside world without any security policy in place exposes the enterprise to the potential malicious usage of those APIs. Any organization exposing data via an API needs to ensure its clients can’t easily pull down data; otherwise it runs the risk of becoming a channel for data harvesting. This means implementing throttling policies to detect if a particular client is abusing its right of access or levels of usage of the APIs. APIs and Financial Services

Consider the example of how a Financial Services firm working with companies that have managed funds would benefit from effective API management. In a typical scenario where the firm is managing pensions or 401ks, they would normally have an API to give the current price and other details regarding the fund. In such a context, it is normal for an app to call the API on a regular basis. However, if an API is called by the same app thousands of times a second, or is called in an obviously automated way, the API will be monopolized to the detriment of other users. In this instance, the Financial Services firm would need to identify and block users with risky behavioural patterns – without impacting the experience of legitimate users. What kind of API Management?

There are some API management products that can provide mitigation against attacks. These products have features including the ability to set policies, throttle traffic, and deliver the security clients need via a particular security token such as an API key or OAuth tokens. Of note, API keys should be handled carefully as there is a tendency to embed them in applications, without regard for security. Additionally, API management products can also detect unusual API patterns. For example, if the mobile application generally accesses certain API operations in particular patterns it can detect anomalous traffic activity and provide alerts. Lessons Learned

One of the lessons from recent attacks is the need to put measures in place to protect APIs especially as future attacks could be directed against APIs with a goal of taking out mobile applications. This risk is increasing as a significant amount of users adopts mobile applications. This trend combined with banks’ focus on providing mobile banking applications means that organizations’ require a watertight approach to managing and securing APIs. Mark O’Neill is a frequent speaker and blogger on APIs and security. He is the co-founder and CTO at Vordel, now part of Axway. In his new role as VP Emerging Technology, he manages Axway’s Identity and API Management strategy. Vordel’s API Server enables enterprises to connect to Cloud and Mobile. Mark can be followed on his blog at www.soatothecloud.com and twitter @themarkoneill ####