Beware the WAF in WAAP Clothing

It’s been a little over two months since I joined ThreatX as CEO, and it’s already shaping up to be a fantastic ride. As a leader, these are always some of the most exciting and illuminating days as we start to get our hands dirty and chart the path forward. As always, the most important insights have come from getting to hear directly from a lot of AppSec leaders and practitioners about the real-world challenges they face on a daily basis.  

And while adapting to COVID-19 has certainly been a hot topic of conversation, it has also been clear that the crisis has simply further exposed and exacerbated some of the core problems that have been festering in WAFs for years. If I had to boil it down to a single statement it is this – organizations are choking on AppSec complexity.  

Sponsorships Available

Sponsorships Available

Sponsorships Available

Most organizations are struggling to get even a small percentage of their apps protected, and the accelerated movement to the cloud brought on by COVID-19 is only making things worse. The apps that do get covered have wildly different levels of protection depending on whether they are local, hosted in the cloud, or accessed via API. Security staff are swamped configuring and maintaining policies across multiple blades or modules and then chasing the alerts they generate.  

Now, of course, none of these problems are particularly new. You might easily have heard a similar set of complaints regarding WAFs if you asked the question five or even 10 years ago. The issue is how to change things going forward so that this time next year organizations aren’t still facing the same old problems. 

WAF vs WAAP: What’s the Difference? 

This brings me to the subject of Web Application and API Protection (WAAP). WAAP is a relatively new term coined by Gartner to define the evolution of application security based on modern challenges such as cloud migration, the rise of APIs, and new threats such as bots. And unsurprisingly, many WAF vendors have cobbled together features here-and-there, mostly through acquisitions, so that they can claim that they are a WAAP solution. We’ve opted to use the term WAAP++ to describe the ThreatX platform, amplifying the Bot management (+) and DDoS mitigation (+) aspects included, but not obvious in the definition’s acronym. 

But here’s the issue: bolting on more functionality to an already bloated architecture doesn’t solve the problem. It makes it even worse. If you treat WAAP as just a WAF with more stuff on it, you get more complexity not less. It’s still a pain to protect everything; you still have wildly differing quality of protection depending on deployment. And, operational management gets even more complex. 

This is why I am so excited about ThreatX and why our native, purpose-built approach to WAAP++ can truly change things for the better. Our cloud-native approach makes it easy to quickly protect 100% of applications, regardless of environment location: local, cloud, or hybrid. As an API-native solution, we provide the same level of coverage for APIs as for application front ends, plus a variety of protections uniquely suited to the needs of APIs. And while we have a myriad of detection and prevention techniques, we bring it all together into a single unified risk score so that policies, alerting, and investigations are boiled down to simple, actionable answers. And, the best part is that there is no need to write tons of rules or baseline activity to leverage the ThreatX WAAP++.   

So instead of a Frankenstein’s monster of features that were never meant to work together, ThreatX is built from the ground up to help solve the complexity problem. So, while vendors are touting their new WAAP features and latest machine learning algorithm, remember to ask yourself: ”Does this make my life simpler and make me more secure?”  

I firmly believe ThreatX can legitimately answer a resounding “YES” to that question. And we’d love the chance to prove it to you.