Is API security a better WAF?

The perceptions of the API security market have really shifted since we started Impart Security three years ago.  When we first started Impart, API security was a new market; there were many different opinions about what API security was, how to approach the problem, and what good API security looked like. I remember back in 2020, although most security teams I spoke with thought of API security as a critical part of their security program, those same teams also had very different views of what specific problems and urgent pain points needed to be addressed.

In this post I’ll unpack the current state of the market, where it’s going, and what security teams should be doing about it. Really, good API security is all about runtime protection.

‍

The API security trough of disillusionment

The biggest difference in what I’m hearing from security teams today about API security versus what I heard back in 2021 is an overall feeling of disillusionment. In 2021, API security was new, the market was ripping, security budgets were growing, and most security teams were getting started on their API security journey by deploying their first API security tool, which promised a silver-bullet solution to the growing challenge of API security.

‍

What I hear today from security teams is that by and large, these tools have failed to deliver on their promise of solving the API security challenge. The root causes seem to be two-fold: firstly, the very real complexity and difficulty of API security itself, secondly, there is a vast gap between expectations and the reality of these earlier solutions.

Most of the conversations I am having now are about how security teams are disillusioned with their tools; API security is proving to be a bigger challenge than expected, with existing tools being unable to adapt to the complexity and scale of the problem. Some specific frustrations I’ve heard in the last few months:

• “Our vendor delivered 90% false positives, which created a rabbit hole of new security issues that needed to be investigated, which couldn’t be reproduced.”
• “Even after telling our vendor about false positives, they kept on showing up as new findings and couldn’t be removed, even after we engaged with their engineering team.”
• “It took us nine months out of our 12-month contract to get deployed.”
• “Our vendor lacked sufficient understanding of the API, which created manual work to write regex rules for every endpoint.”

Unfortunately, the sad reality is that API security challenges are still largely unsolved, despite the fact that security teams have been spending more time and energy trying to solve them, often with worse results. These security teams are frustrated, disillusioned, and skeptical that there is a workable solution due to the poor experience that they have had with early API security vendors.

‍

DAST and WAF techniques can be applied to API security

While APIs do have a fundamentally different attack surface and profile than traditional web applications, that doesn’t mean we can’t learn from historic approaches to application security that have been in place for many years—DAST (Dynamic Application Security Testing) and WAF (Web Application Firewall). These tools, while limited and difficult to use, do have noble security outcomes and goals they try to accomplish, which we can apply to the API attack surface.

Traditionally, the primary goals of a DAST is to help security teams detect potential vulnerabilities, and to prevent those vulnerabilities from making it to production. This is accomplished through the use of test automation and test cases that are triggered at different stages of the SDLC, and provide feedback to development teams for remediation.

Traditionally, the primary goals of a WAF have been to help security teams detect potential threats and to protect critical assets from those threats. Threat detection has historically been accomplished through regex filters, with threat protection accomplished with inline enforcement techniques like blocking, rate limiting, and redirects.

What we are seeing and hearing from customers today is that legacy DAST and WAF solutions are not working when it comes to protecting their APIs, but this doesn’t mean we can’t learn from these legacy approaches and put them together into a list of requirements for a successful API security program:

• Vulnerability detection
• Vulnerability prevention
• Threat detection
• Threat protection

Spoiler alert: In the rest of this post, I will walk through these requirements and make the case that threat protection is the most valuable of these requirements.

‍

The limits of vulnerability detection and prevention

Vulnerability detection requires runtime context

Putting aside the challenge of crossing the remediation gap, the larger challenge with vulnerability-centric approaches is that they simply don’t provide sufficient context to properly understand the APIs they are supposed to be protecting.

Here’s an example: If you are trying to use a DAST to test your API, you might have a DAST tool like BURP or ZAP,  a battery of canned tests ready to run, and some partial documentation about the APIs. However, what you lack is enough understanding about the API attack surface to actually run a useful test, such as a complete list of all the API endpoints that need to be tested or realistic data payloads that can be used to simulate live traffic.

The only way to solve these problems is to pull in a sample of runtime data and analyze it to find enough insights to feed your testing framework. But from a data standpoint, that’s not intuitive; rather than analyzing the huge and rich data source of runtime data for interesting insights and context, this approach actually discards the majority of that data to feed a context-light testing system based on canned tests that were most likely created outside of the scope of your specific application. This would be like the FBI looking for criminals by running a bunch of tests on every update of the phonebook then listening to samples of random phone calls to better improve the accuracy of their tests. See reference image below.

‍

Vulnerability prevention requires developer remediation

One challenge with a vulnerability-centric-based approach to API security is that every test finding provided by a failed test generates a new work activity that needs to be deduplicated, investigated, reproduced, validated, prioritized all before they are sent to engineering to be remediated. That’s a lot of work for the security team, and even if they’re able to accomplish that, they still have to be sent to engineering who already has a full backlog of other non-security related priorities.

The core issue here is that most security teams aren’t allowed to make changes to source code written by development teams. From a systems standpoint, not having a closed-loop system can only create issues as there is no real ability to close issues on their own. Although good collaboration and teamwork can help security teams influence development teams to quickly remediate outstanding issues, or to follow security best practices during the development process, security teams still aren’t able to act as independent agents to reduce their security risk when focusing solely on vulnerabilities.

‍

Threat detection is not the same as threat protection

Threat detection is the analysis of API traffic and behavior. This can be done in many ways: via logs, which is what a legacy WAF can do) or via traffic monitoring, which is what some API security companies do through traffic mirroring, network taps, or eBPF.

Threat protection is actually enforcing policies on API requests, such as blocking, rate limiting, redirecting, or decorating API requests. Threat protection solutions need to be inline, and need to operate in real time to withstand the high-stakes pressure of making blocking decisions on production traffic, which can have serious repercussions if done incorrectly.

There are also a number of API security vendors who claim to have “runtime protection”, which is a misleading claim designed to make you think that they offer both threat detection and threat protection, when the reality is that they only have threat detection. Their threat-protection story is actually just a form of alert—to a SIEM, a SOAR, or a WAF, which now has to be investigated and validated, creating more work for already busy security teams.

At an operational level, relying on an alert-based approach to blocking decisions is that they don’t happen fast enough to block requests in real time, and they don’t allow security teams to explain why a blocking decision was made, can’t be replicated for validation, and ultimately leave security teams in the untenable position of having to justify a blocking decision by combing through logs.

Solutions that can only detect threats and create alerts aren’t helpful to security teams who are already drowning in alerts from all of their other security tools.

Threat protection is what actually reduces API security risk

In a world where every security tool is creating alerts, alarms, and tickets that need to be investigated, reproduced, and remediated, threat protection is the only “closed-loop” process available that helps security teams reduce their security risk. Threat protection allows security teams, when they identify a threat, to immediately do something about it to stop the threat and reduce their security risk, without having to rely on an external party (like a busy developer) to accomplish their job.

‍

The problem that many security teams face is that there is a lack of innovative tools for them to use in the threat-prevention space. While this is a general industry problem, this is particularly true in API security and other newer threat categories because threat prevention and runtime are hard spaces to operate in. There’s a whole new class of stakeholders (SREs, or site reliability engineers, and platform engineers) that need to sign off on security tools, and there is a whole new level of technical excellence (speed, reliability, performance) that is required to excel in this space.

However, for any security tools that do pass this type of technical bar and can successfully engage with this new set of stakeholders, the value that security teams can derive from them is significantly more valuable.

‍

Key Takeaways

The API security landscape has changed a lot in the last few years, and we are now in the mid-game. While many first-generation solutions have failed to deliver value, that doesn’t mean that API security has stopped being a problem for enterprises. As the market continues to evolve, here are what I think the key takeaway for security teams should be:

1. Focus on threat prevention, not just threat detection – Don’t let overloaded marketing terms like “runtime protection” fool you into thinking that alarms and webhooks to existing tools protect your APIs. Be sure to validate claims about threat protection and that you have complete enforcement capabilities and the ability to validate them.
2. Integrate vulnerability and threat findings – A complete API security problem will integrate vulnerabilities and threats into cohesive protection policies. Don’t rely on legacy, siloed tools that can’t organically put these concepts together or you’ll have to do it yourself, manually.
3. Don’t give up! – API security is a hard problem, and just because the first vendor you tried didn’t work doesn’t mean your challenges can’t be solved! The number of APIs is only continuing to grow and isn’t going to slow down any time soon. Rest assured, there are a number of very passionate folks in the industry working hard to solve this problem (like Impart), and we will come together to solve this problem.

If you’ve made it this far, thanks for reading, and I hope you’ll be able to better answer the question “Is API security a better WAF?”  If my opinions and thoughts on API security struck a chord with you, I hope you’ll give Impart Security a try. Contact us at try.imp.art.