by Mark O’Neill
Application Programming Interfaces (APIs) are the glue that connects applications (apps), be they consumer- or enterprise-oriented apps. In fact, as mobile computing reaches further into the enterprise, APIs are also being rapidly adopted to expose mobile apps across all industry sectors. As APIs rise in importance, so has the need for better practices in their creation, development and management. While the API economy forges ahead, enterprises need to be aware of some of the potential pitfalls they may encounter along the way and learn how to address them. The following five tips offer best practice approaches for managing APIs with a focus on security.
Tip #1: Implement Policies to Avoid Uncontrolled
Access and Usage of APIs
Enterprises need to implement policies to control 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.
Overages: Additional Revenue Streams. When an organization implements throttling policies to dictate how a client accesses its APIs, it can then start to charge for overages. This approach is similar to a mobile phone plan – where a user pays up to a certain amount as part of a normal plan, but if the user goes over that amount, then there is an overage fee. By implementing a throttling policy to limit the amount of requests a client can make, a firm can choose to charge users who go over that limit, which opens up a new revenue stream.
Tip #2: Govern the Creation and Distribution of
The growth of APIs has resulted in potentially risky practices where different lines of business in an organization and within individual departments are creating their own APIs - with no way to manage them as a whole. In fact, once the APIs are deployed, there is no way to get metrics, or determine how they are being used or not. An API governance framework should be implemented to better manage the creation and distribution of the APIs. Consider the following options:
API Catalog. An API catalog provides visibility into the organization’s APIs and details metrics on API usage and policies. By leveraging an API catalog, an organization gains a layer of governance to control its API usage and stops the unmanaged proliferation of APIs.
Policy. Another element of governance is the application of policies to APIs. For example, the policy could dictate that a specific API should only be accessed by particular clients with defined throttling and security policies. Similarly, identity-based policy rules can be used to govern a BYOD scenario, where employees are accessing company information from their personal devices.
API Analytics. When an organization deploys APIs, it wants to know how they are being used. Typical questions an organization may ask about API usage include: who used the API in the last week, is traffic up or down, what time of day is it accessed, which operating systems are being used, for example, iOS, Android or Windows. In summary, an organization does not want to put out an API and have no information on usage.
Tip #3: Avoid Creating New Silos of Users and Passwords
It is tempting for an organization to create an entire new user store for an API with associated new user names and passwords. However, the problem with this approach is that it creates a new user silo with all of the attendant cost and time overheads for the provisioning, management and de-provisioning of users. Why not simply link the API Management process to existing user stores and profiles?
Provisioning of Appliances. Consider a Financial Services firm with money managers who want the ability to manage funds and get real time metrics from their iPads. The firm is already using an identity management platform such as CA SiteMinder for identity management (IdM) yet, there is no SiteMinder Agent for iPad. By deploying an API Management platform to connect the existing IdM polices to the API traffic, IT avoids costly silo duplication and enables a BYOD policy for the business.
Consider User Context. Another benefit of this approach is to enable the enforcement of user context based policies. These are policies which define whether a user who is accessing APIs via a specific device, at a particular location within a specified time range is permitted access or not. For example a money manager working from a coffee shop in Boston at 2pm mid-week is permitted access to an organization’s API as he is working from an identifiable location, within a specific time range and with a particular device. However, access will be blocked to a user who identifies as the same money manager while accessing the API from St. Petersburg at midnight on a device the money manager does not own – even if it has the right credentials. As such, the context of the user is considered before allowing access to the API.
Tip #4: Avoid Lock-in to Cloud Providers
An organization can avoid vendor lock-in with a cloud provider by deploying APIs to be independent of cloud providers. Rather than customers connecting directly to an organization’s services on cloud providers such as Rackspace, Amazon or Salesforce, a virtualization layer in the middle enables them to connect directly to the organization. The key element here is the virtualization of the APIs. This enables the organization to move easily between different systems and cloud services depending on pricing, reliability and the respective Service Level Agreements.
Tip #5: Avoid Denial of Service Attacks. Ensure
Distributed Deployment to Avoid Vulnerability in Your API Hosted Network
In recent months, there have been a number of highly publicized cyberattacks on U.S. banks. These attacks take the form of Distributed Denial of Service (DDoS) attacks, involving enormous amounts of traffic being sent to Internet-facing banking services, rendering them unusable.
Much of the media coverage focused on the fact that the websites of the banks were taken offline by the sheer volume of traffic. However, a side-effect of the attacks has been to also render the mobile apps of the affected banks useless. Although users could initiate the mobile banking apps from their phone or tablet, the apps could not “call home” to their banking systems, so they could not connect to any account details, or even log the user in. Like other mobile apps, mobile banking apps use APIs to perform actions and receive data. The DDoS attacks effectively disabled API access.
Protecting APIs Against Attack. In the case of these DDoS attacks, there was little the banks could do to protect against the attacks; such was the volume of data. 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.
Some API management platforms can provide mitigation against attacks. These products have features including the ability to throttle traffic, and also ensure security as clients need to use a particular security token such as an API key or OAuth token.
The API Platform is Not an Island or a Cloud
Given today’s environment, it is clear that organizations require a watertight approach to managing and securing APIs. While an API platform is an obvious solution for managing and securing APIs, there are best practices to consider in this area also.
When leveraging an API management platform, an organization should ensure the platform is not operating completely separately from the enterprise. Additionally, an organization should ensure its API platform is on-site as opposed to cloud-based, which gives the organization greater flexibility. Of note, an organization should understand an API platform is not an island – or indeed a cloud in the sky! It needs to be a fully integrated part of the entire enterprise, brought into the fold and part of organizational policies, with architectures and mandates built around it. Otherwise, the platform is operating as an island, where new user and policy stores will continually be required – along with a high risk of security breaches.
Mark O’Neill is a frequent speaker and blogger on APIs and security and
the CTO at Vordel, now part of Axway.