How to Manage API Security

"There is a crack in everything / That's how the light gets in" — Anthem, Leonard Cohen

When it comes to enterprise applications, the cracks are certainly there, but it's not light finding its way through the gaps — it's criminals and their malware assistants. Some of the enterprise cracks appear through vulnerabilities in application code or firmware, but hundreds, if not thousands, of potential cracks exist in the places where apps and functions come together in an overall application — namely, APIs.

Application programming interfaces (APIs) are the formal, regularly stated ways that pieces of applications talk to one another. This means there is at least one API for every component in an application.

More than half of the APIs used in enterprise applications are developed internally, according to the "2019 Postman State of the API Report," for which more than 10,000 developers were surveyed.  Another 28% of the APIs come from partner organizations, while roughly 19% are publicly available.

"If you think of any infrastructure today in enterprise applications and the components that support it, there is usually a mobile component, a website component, and a myriad of databases and services that support them, and all of this happens with APIs," says Mehul Revankar, director of product management at SaltStack. "And so the API is in some way the invisible glue which keeps all of these things working together seamlessly."

Critical Interface
Because APIs are so critical to the modern application framework, they are tempting targets for criminals. And the criminals' jobs are made easier due to the lack of understanding many IT leaders have about just how many APIs are at work in their infrastructure.

Part of the issue, experts say, is the nature of modern applications. What once were monolithic applications that might make calls to a database and presentation layer are now nested layers of microservices and serverless components.

"What does it mean from an API perspective? What used to be a function call within the app in the past is now an API call," says Shreyans Mehta, Cequence co-founder and CTO. The security challenge is making sure the APIs allow only authorized apps and users to pass data from one piece of an application to another.

The move to the modern application model is driven by the sheer velocity of modern business, with partners, customers, and internal business needs all driving the requirement for speed, says Kin Lane, chief evangelist at Postman. As a result, "People just don't prioritize the cataloging and defining of what these [API] capabilities are," he says.

Taking time to catalog APIs and understand how many APIs are actually in the organization's inventory, then, is step one in securing APIs. But once you know what must be defended, how can you best go about that defense?

The good news, according to Lane, is that many of the APIs in use by enterprises will share a common basis. "The majority of APIs are more of a common-class REST or a Web API," he says. "Those have a lot of common characteristics — it's pretty straightforward to understand how to secure them."

Protect the REST
With APIs discovered and catalogued, and protection for the RESTful sort well-understood, how then should organizations proceed to protecting the remainder of the APIs in the architecture? Some make the case for starting with the basics.

Laurence Pitt, global security strategy director at Juniper Networks, says encryption is a good starting point.

"There are many different methods when considering how to lock down an API, but it does not have to be overcomplicated," he explains. "In most cases, it would suffice to make sure that the API is using HTTPS for communication to ensure that the traffic cannot easily be sniffed from the network, and then to use some form of authentication to allow access."

While it isn't perfect, that method will keep hackers using Internet crawling tools from finding open APIs and tiffing the traffic, Pitt adds.

The next security step could involve following a security framework for protecting APIs. Fortunately, a couple of frameworks are available that multiple experts recommend as part of a drive toward best practices.

Mehta points to the Open Web Application Security Project (OWASP) and its API Security project as a resource, though he does offer one caveat: "I don't think it's in that mature a state right now; there is more work to be done," he says. "It could be a good start, but it's missing a lot of pieces right now."

A release candidate for the OWASP API Security Top 10 was published at the end of September. In other words, the API Security project is quite literally a work in progress. Even so, it presents 10 areas for security teams to be concerned about when it comes to APIs. Those areas range from broken object-level authorization and excessive data exposure to insufficient logging and monitoring.

Beyond OWASP
While the OWASP framework is still in the publication and finalization process, the National Institute for Science and Technology (NIST) has been working on Web application security frameworks for some time. NIST Special Publication 800-95 was published in 2007 and is still considered one of the foundational Web security documents by many professionals. And NIST has not stopped the framework development process

A draft version of NIST Special Publication 800-204, which covers security strategies for microservices-based applications, was published in March with a comment period that went through April. The final version of SP 800-204 was published in August. While important, Kiersten Todt, managing director of the Cyber Readiness Institute, says how the NIST framework — or any other — is used is more critical than what it contains.

"You can't adopt the framework," she begins. "The framework itself has 98 controls. Some companies are going to be able to use all 98. Many of them are not. So my point being that these are all tools that should be used as guidelines, but never destinations."

Thoughtful Application
When considered as guidelines, the OWASP and NIST frameworks may be subject to constant revision. "You as a company have to constantly be assessing and reassessing your mission, your threat environment, your priorities, etc.," Todt explains. "And so again, these are places to start, but they should be customized and they should be constantly assessed."

As for the frameworks and technology organizations use to implement their controls, Postman's Lane says perspective is critical. "Be wary of what's next — that next shiny object to distract you from the hard work," he says. "Don't let it distract you from from the hard work of identifying what your APIs are and following the loss guidance consistently across your teams."

In the end, "Just just be pragmatic and be thoughtful," Lane adds.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "Disarming Disinformation"