Exclusive: Cybersecurity in the API economy

As organisations connect an increasing number of devices, the demand for connected experiences across these devices and platforms also increases.

Users expect to be able to start watching a programme on Netflix on our phones on the bus home, and then switch to tablets or smart TVs when they get home, and they expect the experience to be seamlessly connected.

Users live in an 'always on,' 'always connected' world and expect devices to have smart responses.

Application programming interfaces (APIs) are the cornerstone of both connected devices and the connected experience.

They drive integrations, opportunities and revenues across the business landscape.

As a result of this massive potential impact, they've shifted from the domain of just developers to a mainstay of board-level conversations: Expedia, for example, was generating 90% of its revenue from its API starting in 2015.

For Twilio, the cloud communications PaaS company, that figure is 100% of its revenues.

And these businesses are only the tip of the iceberg.

But the more devices users connect, the more integral the role of APIs becomes.

And as more and more data is generated and interwoven across platforms – and potentially the platforms of partners' and customers' – the security of the entire ecosystem come under the microscope.

With great power comes great responsibility: Pillars of API security

According to Gartner, APIs will be the most common attack vector by 2022, but without a deliberate, focused effort to protect these systems, even that timeline seems optimistic.

We can identify three basic pillars of API security, which essentially boil down to what, how much, and with whom:

• What: We expose only the interfaces we intend
• How much: We share and accept only the data we intend
• With whom: We grant access only to the people or systems we intend

Getting businesses to tackle API security seriously and from the beginning of their development is just the first hurdle to overcome.

There are a number of approaches to API security.

Approach 1: Trust your end-users

Trusting your end users is not a serious approach to API security, but is, unfortunately, the most common by far.

Unqualified trust does not equal security in any circumstance, even for internal APIs.

Not treating API security seriously can leave companies open to serious cybersecurity vulnerabilities.

Developers should approach it in the same way they would for web interfaces and applications in order to protect company data and IP.

Approach 2: API keys

Most API access starts with API keys. Fast and easy to implement, API keys are XXXXX – which essentially means they function as a password. That leaves you maintaining passwords and rotating as you go.

With scale, this becomes a giant headache for developers.

Generally speaking, API Keys allow all or nothing access, so if a developer has your API Keys, they can call every single one of the APIs that you expose.

In short, API keys are able to address the 'With Whom' aspect, but rarely the 'What' or 'How Much'.

Approach 3: Use an API gateway

One of the more advanced ways to protect an API's infrastructure is an API Gateway, such as Apigee and Mulesoft.

In general, a gateway provides an access management functionality that can address the first, 'What', aspect of API security.

 But when it comes to the full scope of access management, most API Gateway implementations tend to provide a slightly narrower solution to 'How Much' or 'With Whom.'

With a full access management solution to complement it, API Gateways can be extremely valuable.

When used alone, API Gateways often lack the full context on users: a distinction between just asking who they are, and asking what they are trying to accomplish.

For example, using an HR system's API to download vacation history contains very different risks to using that same API to change direct deposit information.

Approach 4: OAuth 2.0

OAuth is the industry standard that the industry is beginning to see a lot more.

Think about the hotel check-in experience; key cards, but for applications.

Specific access tokens, granted by an Authorisation Server upon proof of identity, allow access for the specified user to a specific set of resources, with an automatic expiration.

The expiration removes the pain of rotating passwords, while the inherent scoping built into OAuth allows clearly defined parameters to answer all three of the basic API security pillars.

OAuth is a more complex approach, functioning not as a single specification, but as a framework. While that is true, it also allows for greater flexibility and less standardisation – a benefit in the world of security.

It's important to remember, however, that OAuth 2.0 is still not a complete solution for securing APIs because while it addresses the original three pillars, it doesn't take into consideration how to protect the API itself.

Two solutions are better than one

In practice, no security option is entirely failsafe, and each will come with an element of risk management.

However, to create the most sophisticated solution for high-security use cases, API Gateways using OAuth are becoming increasingly ubiquitous.

The complementary technologies combine to create a powerful API Access Management solution that can limit particular OAuth scopes to specific devices, a specific network or group membership.

Importantly, a security team can manage policies like this outside the API Gateway, while centrally logging access requests, grants and policy changes.

Better solutions can help bring APIs out of the realm of 'shadow IT', and back to known, trusted systems.

No solution is final, and today's trusted partner may become tomorrow's compromised system.

Organisations need the flexibility to adjust, respond and protect their systems based on the full context of the user and their goals.