Seven Takeaways from Gartner® 2022 Innovation Insight for API Protection

1) Analysts are getting questions about API security

From the report:

“Security leaders are looking for additional security capabilities to protect their APIs. They are expanding beyond their existing API gateways (GWs) and web application and API protection (WAAP) solutions — especially in industry verticals with high security requirements.”

It’s no surprise that API security is at the forefront of security leaders’ minds. CISOs are well aware of their ever-expanding API ecosystem and their organization’s increasing reliance upon them. APIs drive growth and profitability and enable these businesses to deliver their digital goods and services. In fact, university researchers from MIT and Boston University found that businesses that utilize APIs have been more profitable over the past decade, experiencing 12.7% higher growth in market capitalization growth than those that did not use APIs.

During the recent Salt API Security Summit, Dr. Anton Chuvakin, security advisor at the Office of the CISO of Google Cloud, talked about why API security is a ‘now problem’ for security leaders. “People have been building APIs and attacking them for more than 10 years. But right now, we’re living in an era of it being really hot.” He went on to say that “API security is a very tough problem because it's multi-dimensional. You need to be an app sec expert. You need to be a network security expert. You need to understand the business and the application. So you need to know the business, IT, and information security.”

2) Highly-regulated industries are paying special attention to the security of their APIs

From the report:

“Security leaders in high-security and regulated industry verticals express their desire during inquiries for an advanced solution that can immediately provide the required functionality.”

Security teams in highly regulated industries such as financial services, insurance, healthcare, and pharma are quickly realizing that their APIs could be leaving their customers’ sensitive data at risk, which in turn puts their business in jeopardy. APIs represent the access point to PII and other important data assets that attackers target for their own gain and to the detriment of the business. With high-profile API-related breaches frequently making the news (Experian, Optus, Peloton, and the list goes on and on), regulators, boards of directors, and cyber insurers are taking note.

At Salt, we hear from leaders in almost every industry. Our customer base has grown exponentially over the past few years, and that growth has been largely fueled by customers in these highly regulated industries. Just the other day, Joe Martinez, Chief Security Officer at the risk consulting giant Aon, joined us for a fireside chat. We invite you to check out the replay of this conversation – one fascinating observation that Joe had vividly illustrates the need for API security: “I have APIs all over the place, and now APIs are themselves a technology resource that we have to manage, akin to managing a server or managing a workload. So if you consider APIs that way, you quickly realize that you need to focus competency around API management and API security, like we do with database management and data security.”

Berkshire Bank shared a similar perspective. The bank’s CISO, Ryan Melle, told us “We’re seeing an increase in the number of API transactions, but we’re also seeing an increase in API attacks. We have to keep our data secure and our regulators happy, and we can’t get in the way of digital transformation – Salt fits right into that.” During the bank’s evaluation process, the team defined the primary capabilities the bank saw as core to developing its API security strategy: API inventory, API design security, and runtime protection.

We heard a parallel story from another Salt customer, also in a highly regulated space. Jason Weitzman, a senior security engineer from Xolv, a healthcare solution suite that provides home and community-based care, described how his organization transformed with a complete API security solution. Weitzman told us that “we were sure we didn’t know about all our APIs… now that we have Salt, we’ve got a solid idea of what’s out there, and we’re protected in runtime.”

3) Traditional security tools leave API security gaps

From the report:

“Many organizations protect API traffic the same way they protect their legacy applications. Generic application security controls might perform poorly due to the different structure of the traffic (for example, a JSON payload), or due to the characteristics of the API transactions (for example, due to high frequency). Especially in industry verticals that have high security requirements, security leaders are looking for additional security capabilities to protect their APIs.”

The authors of this report are almost certainly getting questions about what API security threats traditional toolsets like API Gateways and WAFs/WAAPs might be missing. We hear these types of questions quite often as well.

Traditional tools including WAFs and gateways cannot detect today’s API attacks, often built on business logic abuse and authorization exploits, because they rely on signatures and well-known attack patterns for detection. The most glaring example of this limitation is the fact that neither WAFs nor API gateways can detect today’s most common API attacks, which target broken object level authorization (BOLA).

WAFs, using technology developed 20 years ago, apply rules to protect web apps from yesterday’s attacks, like SQL injections and cross-site scripting. WAFs see the world one transaction at a time – they have no notion of user context, and no notion of changes over time. They cannot stitch together activity over time, so they can’t see today’s API attacks. That’s why, despite the prevalence of WAFs, we see headlines every month of a new company suffering an API breach.

API Gateways are great at publishing and updating APIs, monitoring their usage, facilitating reuse, and enforcing schema consistency. But gateways have no ability to monitor API traffic and cannot see the indicators of API manipulation in runtime. That’s why all the gateway vendors partner with Salt for runtime protection.

Daniel van Slochteren, the Chief Innovation Officer at Open Line, put it perfectly when he explained, “All of our customers use solutions that are API-driven, with enormous volumes of sensitive data being shared across their services. To reduce digital risks, protection of their APIs is critical, and we found WAFs and API gateways insufficient to address the full scope of this growing problem.” We couldn’t have said it better ourselves, Daniel!

4) Organizations need to have all three to protect their APIs: discovery, posture management, and runtime protection

From the report:

“Security leaders in high-security and regulated industry verticals express their desire during inquiries for an advanced solution that can immediately provide the required functionality… three main functions of API protection products — namely, discovery, posture management and runtime protection.”

The Salt API Protection Platform is based on these pillars, so we couldn’t agree with Gartner more! We believe that APIs require a new approach to security that goes beyond traditional tools that are limited to looking at individual transactions in isolation. We also contend that providing all three of these functions successfully depends on delivering rich context about APIs – otherwise, the solutions may do more than a WAF or gateway but will still fail to catalog APIs effectively, find API attacks in the wild, or provide useful remediation insights based on runtime learnings.

To protect APIs, organizations need a platform that delivers deep API context in all three key pillars:

• Visibility: API sprawl continues unabated, making it nearly impossible to stay up to date on new and changed APIs. Along with dynamic discovery, organizations also need deep details on parameters and other API attributes as well as a sensible catalog that resolves multiple instances of the same API, perhaps isolated by username for example, into a single instance that makes business sense. Companies also need deep insights into where their APIs expose sensitive data.
• Attack prevention during runtime: Every API is unique, so attacks are unique, and organizations need the ability to detect the low-and-slow behavior of bad actors probing APIs in search of business logic flaws. Having the ability to detect an attack over a few minutes or an hour is better than a WAF but it’ll miss today’s sophisticated attacks, which can be drawn out over days or weeks. Catching those attacks requires cloud-scale big data.
• Proactive security (what Gartner calls posture management): Remediation insights, learned in pre-production testing as well as gleaned from attackers’ minor successes at runtime, help developers harden their APIs. However, shift-left tactics will get you only so far. It won’t uncover business logic flaws, for example, and developers should not be expected to build perfectly secure APIs every time – you’ll slow down the business and STILL won’t have the runtime protection you need to really protect valuable data.

5) Runtime protection is critical for all APIs

From the report:

“Through 2025, at least 70% of organizations will deploy specialized runtime protection only for the public-facing APIs they produce, leaving other APIs unmonitored and lacking API protection.”

This stat is both good news and bad news. The good news is, 70% of organizations are expected to deploy runtime protection for their APIs. The bad news is that they’re only considering public-facing APIs as they deploy this necessary security function. While it makes sense to prioritize external APIs, your runtime protection shouldn’t end there.

Internal APIs are usually deployed and operated within a restricted network environment such as a data center or private cloud segment. They’re designed to be consumed by other applications or users in that restricted network. Authentication and authorization may be in place but are often relaxed because exposure is limited.

Unfortunately, internal APIs are also vulnerable. Complex attack chains can traverse external APIs and connect with supposedly internal APIs. And direct internal API calls, inner API to inner API communication, and internal systems are not immune from attack. In addition, it’s not unusual for internal APIs to become external as business needs change - often without the security teams' knowledge. Other times, those supposedly “internal only” environments can accidentally get exposed – this scenario is how the Optus API breach occurred, for example.

6) Companies that build their own APIs need to be extra vigilant

From the report:

“APIs built by organizations are often the cause of high visibility breaches.⁴”

This finding really resonates with what we see and hear every day. API attacks have been all over the news lately. Just a few months ago, Optus, a major telecommunications company in Australia, experienced an API security incident, exposing around 10 million customer records. In March, a HubSpot API breach exposed the sensitive data of 1.6 million users. And who can forget the 2021 barrage of API security breaches that included Peloton, Parler, John Deere, LinkedIn, and Experian? What do all of these companies have in common – besides infamous breaches, of course? They build and maintain their own APIs to solve critical business problems. (It’s worth noting they also have all the traditional protections of WAFs and gateways, and sophisticated AppSec teams, and STILL suffered an API breach – these attacks are not easy to find and stop!)

Every organization that develops software of any kind is an API-driven company. These companies should always assume that their APIs are attractive target – bad actors have figured out that APIs are a great way in.  Attackers find and abuse API endpoints by analyzing application traffic and reverse engineering front-end code. For API-driven companies, protecting those APIs is no longer a question – it’s simply the cost of doing business in a digitally transformed landscape. Without dedicated API security to protect these crucial connectivity tools, companies put everything at risk – speed to market, competitive advantage, and the brand itself.

7) The market needs standalone, best-of-breed API security vendors

From the report:

“Security is undergoing a period of consolidation. We expect the API security space to produce a limited number of best-of-breed vendors that will remain stand-alone and expand their portfolio of offerings.”

We couldn’t agree more, and that’s why we here at Salt are honored to have had the opportunity to help our customers prevent the most complex API security threats and accelerate their digital innovation since 2016!

For more information

If you haven’t already, be sure to download the 2022 Gartner Innovation Insight on API Security. To learn more about how the Salt Security API Protection Platform can help you achieve your own API security milestones, our API experts are here to help. Whether you’re considering adding API security to your architecture soon or in the future, now’s the time to learn about how Salt can help you build a complete and accurate API inventory, find and stop API attacks in runtime, and gain insights to remediate vulnerabilities and harden your APIs.

‍

‍

Gartner, Innovation Insight for API Protection, Dionisio Zumerle, Jeremy D’Hoinne, Mark O’Neill, 10 October 2022.

GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.

Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.^[M1]