So why are we talking about this? Because APIs are becoming the de facto service interface – not only for cloud and mobile, but for just about every type of service. The need for security around these APIs is growing, which is why we have seen a rush of acquisitions to fill security product gaps. In what felt like a couple weeks Axway acquired Vordel, CA acquired Layer7, and Intel acquired Mashery. The acquirers all stated these steps were to accommodate security requirements stemming from steady adoption of APIs and associated web services. Our goal for this paper is to help you understand the challenges of securing APIs and to evaluate technology alternatives so you can make informed decisions about current trends in the market. We will start our discussion by mentioning what’s at stake, which should show why certain features are necessary.

API gateways have a grand and audacious goal: enablement. Getting developers the tools, data, and functionality they need to realize the mobile, social, cloud and other use cases the enterprise wants to deliver. There is a tremendous amount of innovation in these spaces today, and the business goal is get to market ASAP. At the same time, security is not a nice-to-have – it’s a hard requirement. After all, the value of mobile, social, and cloud applications is in mixing enterprise functionality inside and outside the enterprise. And riding along is an interesting mix of user personas: customers, employees, and corporate identities, all mingling together in the same pool. API gateways must implement real security policies and protocols to protect enterprise services, brands, and identity. This research paper will examine current requirements and technical trends in API security.

API gateways are not sexy. They do not generate headlines like cloud, mobile, and big data. But the APIs are the convergence point for all these trends, and the crux of IT innovation today. We all know cloud services scale almost too well to be real, at a price that seems to good to be true. But the APIs are part of what makes them so scalable and cheap. Of course open, API-driven, multi-tenant environments bring new risks along with their new potentials. As Netflix security architect Jason Chan says, securing your app on Amazon Cloud is like rock climbing – Amazon gives you a rope and belays you, but you are on the rock face. You are the one at risk. How do you manage that risk? API gateways play a central role in limiting the cloud’s attack surface and centralizing policy enforcement.

Mobile apps pose similar risks in an entirely different technical environment. There is endless amount hype about iOS and Android security. But where are the breaches? On the server side. Why? Because attackers are pragmatic, and that’s where the data is. Mobile apps have vulnerabilities that attackers can go after one by one, but a breach of the server-side APIs exposes the whole enterprise enchilada. Say it with me in your best Taco Bell Chihuahua accent: The whole enchilada! Like cloud applications, API gateways need to reduce the enterprise’s risk by limiting attack surface. And mobile apps use web services differently than other enterprise applications, communications are mostly asynchronous, and the identity tokens are different too – expect to see less SAML or proprietary SSO, and more OAuth and OpenID Connect. API gateways address the challenges raised by these new protocols and interactions.

APIs are an enabling technology, linking new and old applications together into a unified service model. But while cloud, mobile, and other innovations drive radical changes in the data center, one thing remains the same: the speed at which business wants to deploy new services. Fast. Faster! Yesterday, if possible. This makes developer enablement supremely important, and is why we need to weave security into the fabric of development – if it is not integrated at a fundamental level, security gets be removed as an impediment to shipping. The royal road is to things that make it easy for developers to understand how to build and deploy an app, grok the interfaces and data, and quickly provision developers and their app users to login – this is how IT shops are organizing teams, projects, and tech stacks.

The DMZ has gone the way of the dodo. API gateways are about enabling developers to build cloud, mobile, and social apps on enterprise data, layered over existing IT systems. Third-party cloud services, mobile devices, and work-from-anywhere employees have destroyed (or at least completely circumvented) the corporate IT ‘perimeter’ – the ‘edge’ of the network has so many holes it no longer forms a meaningful boundary. And this trend, fueled by the need to connect in-house and third-party services, is driving the new model.

API gateways curate APIs, provision access to users and developers, and facilitate key management. For security this is the place to focus – to centralize policy enforcement, implement enterprise protocols and standards, and manage the attack surface.

This paper will explore the following API gateway concepts in detail. The content will be developed and posted to the Securosis blog for vetting by the developer and security community. As always, we welcome your feedback – both positive and negative. Our preliminary outline is:

1. Access Provisioning: We will discuss developer access provisioning, streamlining access to tools and server support, user and administrator provisioning, policy provisioning and management, and audit trails to figure out who did what.
2. Developer Tools: We will discuss how to maintain and manage exposed services, a way to catalogue services, client integration, build processes, and deployment support.
3. Key Management: This post will discuss creating keys, setting up a key management service, key and certificate verification, and finally the key management lifecycle (creation, revocation, rotation/updating).
4. Implementation: Here we get into the meat of this series. We will discuss exposing APIs and parameters, URL whitelisting, proper parameter parsing, and some deployment options that effect security.
5. Buyers Guide: We will wrap this series with a brief buyers guide to help you understand the differences between implementations, as well as key considerations when establishing your evaluation priorities. We will also cover some implementation areas you want to consider during the proof-of-concept evaluation and offer a checklist to help you through the process.

We have been developing this research over the past six months, talking with the user community about – and in Gunnar’s case deploying – API security. Both Gunnar and I are happy to announce that our friends at Intel intend to license this research when it’s completed, based upon our initial outline. As with all our research projects, we write for end users without corporate influence, using our Totally Transparent Research methodology.