Know Your Enemy, Know Yourself: Why WAFs can't protect your APIs

How I learned WAFs couldn't provide API Security

Before I started Impart, my take on API Security was that folks could get API security with a WAF.   After all, API traffic is predominantly HTTP,  just like a web application.  I thought that all we needed to do to provide API security is to block bad API requests. It also didn’t hurt that I worked at a WAF vendor at the time.

However, the more I spoke with customers and CISOs, the more I realized that this approach didn’t work.  Our WAF had no way to answer the questions I was being asked by CISOs:

“Do I have any APIs that are over-exposing sensitive data? Is a vulnerable API under attack right now? Are my crown jewels being properly protected? Did I stop the bad guys?"

WAFs simply do not have the ability to answer these questions.  While WAFs are a great tool to help security teams defend against known risks, they were not designed to inform security teams about what those risks actually are.

This realization is what led me and my co-founders to start Impart Security.

WAFs don't know the enemy, and don't know themselves

“If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself, but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.”  Sun-Tzu, Art of War

Application security today can be likened to a war, and so I thought it might be useful to turn to Chinese military strategist Sun Tzu’s Art of War for better ways to explain some of my day to day realities.  Within are many great nuggets in that can be applied to application security as a whole, but I found the above excerpt to be particularly helpful as a way to summarize the limitations of WAFs in providing API security.

WAFs don't know the enemy, and they don't konw themselves. As a result - they're going to succumb in every battle.

Here are four reasons why.

1. WAFs rely on context they don't have

You could make the case that WAFs don't "know" anything.

The reason for this is that WAFs rely on the practitioner to provide knowledge about the environment and attack landscape to be effective, and that most operators don’t have that knowledge because it is very difficult to gather that context from all around their organization.  

To be successful with WAF, a security person has to know where to put it in order to have effective coverage, what types of attacker behavior to expect in order to configure the right rules, and the critical business vulnerabilities that their company has in order to monitor them for business losses. 

Does a security practitioner have this context, or have the time to gather all of it from the dozens of different development and infrastructure teams in their company ?  The answer is usually no, and the result is WAF policies that are based on guesses that are “succumbing in every battle,” in Sun Tzu’s parlance.

2. WAFs don’t know what the enemy is doing

Because WAFs evaluate single HTTP requests and have strict 8kb memory limits on the business logic they can run to evaluate them, they simply aren’t capable of understanding the over time behavior that is required to truly know the enemy.  

A WAF might know the enemy’s attacks, i.e. the arrows of XSS, swords of SQLI, or the bullets of XFF, but simply do not have the technical or analytical capability to understand the enemy behind them, what their plans are, or their strategic objectives.  

Without knowing these things about the enemy, victory becomes impossible.

3. WAFs don’t know what they are protecting  

Because WAFs operate on runtime context, the best they can do is understand external behavior and threats inbound to an enterprise.  They completely lack any understanding of what API assets exist within an organization, what the risk profile of those assets are, and the changing state of those assets within an active development environment.  

Imagine trying to design defenses of your estate without the blueprints of your home.  Without knowledge of where the entrances, exits, valuables, and weaknesses of your home are, designing an effective defense becomes impossible and the result is a hodgepodge of random guesses about what defenses need to be installed where.

4. WAFs can't explain what they're actually doing

Ever tried to understand what your WAF is doing?  It's a very difficult task. The way most WAFs are configured they are simply matching individual HTTP requests against an open source library of thousands of regex patterns. What this might mean is that a single HTTP request might trigger dozens of WAF rules which means that you can't easily understand which rule is most relevant or applicable to any blocking decision. All the WAF does is run it's rule set, make a decision, and then forget everything.

Want to better understand the decisions your WAF is making?  Your'e out of luck!  WAFs don't keep track of that level of detail, and now you're now going to have a to play a fun game of configuring your WAF logs to show enough data, and to digging around in your SIEM to try to figure out what happened. Doing this at scale on a regular basis, not just to investigate a single threat, is nearly impossible.

How to truly protect your APIs

The open secret of WAFs is that they rarely work in production, and are usually left turned off, in logging mode, or with so few blocking rules turned on that they are effectively “off.”   While blocking bad API requests is a very important piece of the puzzle when it comes to API security, I hope we've help show, through the lens of Sun Tzu, that relying on that approach is not a winning strategy.

Having a deep understanding of your enemy, and yourself, is the key to true API security.

To successfully do this, you should look for solutions that:

• Discover and provide visibility into all of your APIs
• Help you Visualize how your developers built your APIs and what they are intended to accomplish
• Detect anomalies and suspicious behavior over time, from either attackers or from your developers
• Validate potential threats with integrated testing to reduce un-ncessary noise
• Can block threats natively with integrated firewall that can explain what was blocked and why
• Offer an integrated approach that can tie together all these capabilities into a single platform

If you'd like to learn more about Impart's integrated API security solution, get started today with a live demo.

‍

‍