11436 SSO

Security in Digital Transformation: an API-Centric Approach

Dec 16, 2013

Recently I came across a mind-boggling statistic from Gartner that should make enterprises stop and rethink how they approach security and privacy in the new connected world of mobile and cloud enabled by APIs. According to Gartner, 85% of enterprises will adopt APIs by 2016 and 90% of enterprises will use a cloud-based deployment by 2015. Furthermore, rapid mobile adoption by consumers and enterprise users is forcing businesses to think “mobile first” (by designing for the mobile form factor from the outset) and “API first” (by developing apps that are platform agnostic but API-centric).

How do companies plan to get there? By investing in DevOps, of course. Gartner found that more than 50% of enterprises are investing in DevOps to enable business agility and deliver apps in a continuous integration and delivery model. In a nutshell, we can say that multiple technology vectors are aligning to accelerate enterprises’ digital transformations.

So what does this all mean to information security organizations? How can they enable a business strategy while protecting information exposed to internal and third-party developers by way of APIs?

To understand the implications for information security and risk organizations, it is important to first set the context on security architecture and the threat vectors relevant in the “API-centric” world. Let’s also discuss a framework to mitigate threats, protect sensitive data (the enterprise’s crown jewels), and manage risk and compliance.

Let’s start with the architecture. A typical API-centric architecture is comprised of two tiers:

The API infrastructure service, or “service exposure,” tier - Composed of API service providers (internal backend services and external partner services); services that securely transform existing backend capabilities into APIs; and new data services that power apps (mobile, social, web, and partner) and are aided by self-service API and management portals.

The API developer service, or “API consumption,” tier - Includes services that enable developers to build and deploy apps in a secure way; engage with a developer community; and help manage application life cycles via self-service API and developer portals. 


Two sides of the equation in an API-centric security architecture


Why is this view important? One of the key tenets that enable "defense in depth" security practices within an enterprise is “separation of concerns.” This design principle will make it easier to design security into the architecture and facilitate strong security management such as “separation of duties” between the service providers (the IT architect, IT security, and business) and service consumers (developers and end users).  

API-centric security architecture demands enterprise-grade security capabilities including: role-based access control (RBAC); fine granular policy management for authorization; authentication for users, developers, and administrators, as well as for APIs (via OAuth, SAML and LDAP); and threat protection against XML, JSON, and DoS attacks.

The key benefit of following a separation of concerns principle is that developers can continue to innovate and iterate with an app-centric security model while IT security architects and operations teams can safely expose the APIs without compromising on the enterprise security standards (authentication, authorization, message security, threat mitigation, logging, and auditing).

Let’s take it further and talk about the expectations on security from each of the stakeholders in the API-centric architecture:

  • The API architect should be able to securely expose the backend services with necessary authentication, authorization, message security, and traffic management
  • The business owner should manage availability, risk, and compliance when delivering a digital service to end users, who will be accessing from any device at any time
  • The security architect should protect the crown jewels (the intellectual property and sensitive data) stored and processed in the cloud and mobile devices while meeting enterprise security standards for authentication, authorization, and auditing (AAA)
  • The developer should create and deploy apps and configure security (not code) with fine-grained authorization via API and self-service management portals

Of course, it’s essential to create a threat model for both the API exposure and consumption tier to help the API and security architects factor in security controls during the design phase. The following threats need to be considered when designing the threat model in an API-centric architecture:

  • Spoofing of identity by applications (mobile, web, client apps, proxies) and users
  • Denial of service by bad actors, inadvertent errors, and botnets
  • Network eavesdropping in the communication chain between app and enterprise backend services
  • Replay attacks
  • Elevation of privilege by applications and developers
  • Data tampering and injection attacks that lead to information disclosure
  • Disclosure of confidential data stored and processed in mobile, API, and backend services
  • Unauthorized access to management system and configuration data
  • Man-in-the-middle attacks
  • Theft of credentials, API keys, tokens, or encryption keys

So how can an enterprise deliver API-centric security to meet all of their stakeholder needs? The following best practices represent a great start:

  • Create an API security architecture with both “API consumption” and “service exposure” perspectives and a threat model to support security controls on both tiers. Keep in mind that any API-centric architecture should support separation of concerns from the stakeholder responsibility point of view.
  • Employ RBAC at every layer to implement “separation of duties” and protect sensitive information, including API keys, SSL certificates, OAuth tokens, and audit logs.
  • Roll out a developer-centric security service aided by self-service and an API management layer. These services should be capable of configuring an API authentication scheme (OAuth, API key, OpenID, and two-way SSL), token management, policy enforcement, and logging. Note, however, that any coding of security into the application will create new vulnerabilities and long-term risk management challenges for IT security.
  • Employ fine granular authorization using OAuth, API keys, and RBAC policies to provision the least privileges required by applications to manage the respective concerns.
  • Protect both the communication and payload using SSL/TLS and threat protection features built into the API management products.
  • Log relevant data that support security analytics and forensics analysis.

Apigee Edge, our complete API platform, enables you to create an API security architecture from both the “API consumption” and “service exposure” perspectives and is grounded in the solid best practices listed above.


Finally, any API-centric architecture should be capable of evolving with new business and developer requirements and be flexible to meet these without adding new attack surfaces. In other words, it should offer continuous API-centric security. 

In the coming weeks I’ll discuss various best practices, security patterns, and anti-patterns in an API-centric security architecture that will safely enable digital transformation within your enterprise.

Scaling Microservices