You are here

Lego team

API security: Whose job is it anyway?

public://pictures/John-Mello-Journalist.png
John P. Mello Jr., Freelance writer

Whenever a new way to spin data into gold appears on the scene, companies are quick to jump on the money train. And when they do, security frequently falls by the side of the tracks. That's the case, in many instances, with application programming interfaces (APIs).

APIs are system components that allow applications, platforms, and systems to connect and share data. They're the bedrock of what's being called the API economy, where companies are finding new ways to monetize their software assets through APIs that give developers access to those assets.

How popular are APIs? A recent survey by Ovum and Distil Networks of 100 companies of various sizes and across a variety of industries in North America, Europe, and the Asia-Pacific region found that 20% of them were maintaining, building, or publishing more than 50 APIs, 48% were running between 1 and 50, and 32% were working on between 1 and 10.

That popularity of APIs—especially public APIs that are exposed to developers outside the company that owns the APIs—and their connection to money make them a magnet for cybercriminals. For example, web bandits are using networks of compromised computers called botnets to scrape data and hijack APIs. Other abuses include runaway scripts, integration bugs, and business partners who loosely abide by terms-of-service agreements.

Stephen Singam, managing director of security research at Distil Networks, explains:

“The API economy is about data generating money. Every API call is a kind of digital currency, so the more data that's taken without paying for it loses revenue for the API owner.”

So who should be responsible for security? Experts share some thoughts and suggestions.

How to Get the Most From Your Application Security Testing Budget

IT excluded from API development

Despite the dangers that vulnerable APIs pose to organizations, many of them fail to treat security in the development process in a way that's consistent and unambiguous. Ovum's research found that nearly a third of APIs go through specification without being looked at by the company's IT security team. Nearly 30% go through the entire development process without input from security pros, and more than one in five make it online without any security review.

Jacob Ideskog, a solutions architect with the identity and access management company Twobo Technologies, notes:

“When an API is deployed without sufficient security in place or is deployed before security is in place the correct way, it commonly causes deployment failures or incidents.”

Since API security is a cross-functional part of the organization, IT needs to be part of the process, but it rarely is, Ideskog added. "They're kept at arm's length to deal with machines and networks."

Many technology initiatives originate in IT, but frequently that's not the case with APIs, which is why security teams may come to the party late or not at all.

Merritt Maxim, a senior analyst with Forrester Research, notes:

“API discussions often emerge not from an IT function but from some other business area. That can lead to poor coordination and communication internally about understanding what APIs are, what their designs should be, and what the security implications are.”

Security may not have a seat at the table when the design is discussed, or if it gets a seat at the table it may be late in the game, when internal momentum may prevent security from getting all its requirements into the final design, Maxim added.

Mission friction

It's not uncommon for development and security teams to be at odds when creating applications, so it's no surprise that similar frictions can afflict API development. Stakeholders in the API—marketers, developers, and others—are driven by revenue goals. Security people, on the other hand, are driven by goals such as compliance. "They've got conflicting goals, so for the two to merge creates a lot of pain," Distil's Singam said.

Nevertheless, he estimates that about a third of companies overcome that pain to do a good job securing their APIs.

It's very hard to really convey security issues to business stakeholders, because they look at things like cost and revenue, while the security guys are asking, "Am I going to get breached and am I in compliance?" Singam says, noting: 

“Communications rarely happens across that chasm.”

That kind of communication failure can feed friction between development and security teams when an issue arises after the API is deployed. Developers might be coding in a way that they consider efficient to get the thing done and into production without it being reviewed for security flaws or even skimping on testing time, explained Rik Turner, a senior analyst with Ovum. "That leads to a lot of finger-pointing when a threat actor uses the API to gain some kind of advantage against the company," he added.

When conflicts arise between API stakeholders and security interests, security is often at a disadvantage. That's because it's more difficult to build a business case for something that may or may not happen—such as delaying deployment because this flaw may be discovered and may be exploited—than it is to peg a revenue number to an API.

Forrester's Maxim notes:

“Business holds the winning hand, and they're often able to overrule concerns from the security team because of the value of connecting systems.”

[ Report: The State of Application Security in the Enterprise ]

Potential threat vectors

Even when an organization takes security into account, it will often miss the mark. For instance, it will focus exclusively on access to the API by those developing it. "But there's more to API security than that, so there is a big hole in the security posture in the APIs being done by those folks," Ovum's Turner said.

That tendency to focus security concerns on developers and disregard other risks resonated in the Ovum study, which found that the largest proportion of API management platforms in use offered some degree of protection from developer error but that only a small number were concerned about malicious activity, such as automated data scraping and API hijacking.

Maxim says there's recognition of the problem:

“There's increased awareness that APIs are a vulnerability point, so people are investing more to try and address that.”

"There's an ecosystem of vendors that provide API security, but we still don't have coverage across 100% of the APIs in use today," Maxim adds. "That means APIs can be potential threat vectors that can be compromised by hackers to gain access to systems that they can use to exfiltrate data."

Beef up API security with the right team

What can organizations do to beef up API security? Twobo's Ideskog recommends making sure to create a cross-functional team that owns security, with a focus on identity.

Your team should involve developers, architects, and operations people who can guide and maintain the security solution for the organization, Ideskog says. "It needs to be clear who to ask when help is needed, and also where to find information about what is needed for an API to be approved for deployment."

Lifecycle security techniques used for applications should also be applied to API development. Security vulnerability testing throughout the API lifecycle can be critical to preventing problems before they occur. "You should engage with the security folks from the moment you start thinking about an API and designing what you want it to do," advises Ovum's Turner.

And once you get to the production stage, you should continually monitor for what's trying to access the API and for anomalous behavior, Turner adds.

It's important to keep a close eye on the assets used by your APIs. A single catalog for those assets is useful for that purpose, says Singam, adding: 

“If you don't know where your assets are—in this case, API calls—you cannot protect them.”

Finally, whether buying an API management platform or building one in-house, it's important that it provide protection not only from developer error but also from malicious usage, hijacking, and scraping.

Image credit: Flickr/davidht   

 [ Partner resource: Take Security Journey's first two white belt modules for free ]