The “existing state of affairs” is changing in the web application firewall market.
Innovation isn’t about a follower mentality. By this, I mean the many vendors ticking the box for security by creating “me too” WAF products released around some version of ModSecurity. These products are typically set to identify regular expressions and then cobble them together for alerting and logging of malicious requests. This approach perpetuates the cycle of massive complexity for users through dumping an exorbitant amount of in-actionable false positives across their security engineering and DevOps teams, effectively slowing down their speed of delivery. These vendors typically try to mask value in a couple of UI or performance boosts in an effort to capture market share when they should be focused more on solving problems and creating real business value.
What most web security vendors are doing today is not innovation. However, it is this approach that consumers of Legacy WAF products have been forced to accept as the status quo.
[My background: I spent years prior to joining Signal Sciences helping a company that built a network based WAF product roll that product from Beta to GA acquiring Fortune 500 & Internet Retailer 500 clients from our biggest competitors along the way. ]
I’ve been thinking quite a bit lately about what I frequently heard from organizations in evaluations while working at a Legacy WAF provider. In these conversations, the majority of user complaints were very real pain points. I got the sense, and that sense was confirmed in getting to know clients personally over time, that they somewhat begrudgingly expected they’d have to swallow many of the same issues from their previous WAF provider simply because it was status quo among all WAF products they’d examined. Unfortunately, for Legacy WAF clients the answers to those complaints haven’t moved the needle over time.
With that, I want to take the time to share some of the specific objections that came up most by customers and compare them to what I now know and hear from prospects and clients as a member of the Signal Sciences team.
Legacy WAF Problems Expressed By Users
“It’s going to be very difficult to install, configure, and test the product.”
In order for a client to even see data from a CDN’s WAF product, they must have traffic running on that CDN. Thus, the prospective client must either already have their content with the desired CDN provider to test their WAF product, or they must be willing to migrate their web properties to another CDN provider without ever having run production traffic on that CDN (or through that WAF) just to test the WAF product.
In this example, clients looking for security are left with two options: A.) using their existing CDN provider, likely driven out of convenience and not product value or B.) taking a very large risk by moving their content over to a truly untested CDN & WAF provider.
For any golfers out there, scenario “A” is like buying a driver because it’s the same brand as the set of irons you like regardless of how you actually hit the driver, and scenario “B” is like walking into a golf club warehouse and picking the driver brand you think looks the coolest without ever having swung any of that brands clubs on an actual golf course!
Neither of these scenarios leads to a customer making the most informed decision to purchase the best product for their application security practice.
The New Status Quo: Installation of a WAF product should not be a resource-heavy task for customers in order to get a proof of value, not a proof of concept, up and running. Any vendor that puts prospects or clients in a position where they cannot prove out the value of the product without side tracking a large contingent of their internal team for an extended period of time should be removed from consideration ahead of testing.
“We’d like to be able to block more, but we are convinced, based on past experience, that if we run in blocking mode we will end up blocking legitimate traffic or breaking our app.”
The consistent theme of Legacy WAF products from clients was nearly always one of product fear as much as it was of product confidence. We’d be told that they only wanted to run in logging or alerting mode for the foreseeable future until they were absolutely sure they could write a custom blocking rule. Prospective clients seemed to always be searching for a product that could actually impose cost on attackers, only to end up realizing the general approach to blocking hadn’t changed from a decade ago.
The New Status Quo: Customers being asked to invest resources into any product should expect it to provide value out of the box. Additionally, an exorbitant amount of false positives or the potential breaking of your sites as part of the testing expectation is one you should instantly reject. Any vendor that cannot explain how their product will solve these problems is one you should consider removing from the conversation entirely.
“We are going to need resources, internally or externally, to manage our WAF instances on an ongoing basis.”
With the shift of applications to the cloud and agile DevOps practices being the new normal for nearly every company doing anything online, it has become imperative to only implement vendor products that marry well with these practices. Security teams need to be more integrated with the agile DevOps culture of today, but in a manner and with tools that help them speed the business up—not slow it down.
Legacy WAF’s match regular expressions to flag “malicious” requests which starts the onslaught of false positive data that only the security team typically sees. Because of this, prospective clients need specialized team members on staff to manage their Legacy WAF instances. In some cases they even require that the vendor has a professional services team who can manage their instance for them, significantly increasing the total cost of the solution.
The New Status Quo: Consumers of WAF products should be able to leverage a product that accomplishes what it sets out to do without the need for significant resource allocation post deployment. These products should protect the apps they are installed on and enable online operations teams to move quicker and more strategically, not blur the view of their world, or stall their development cycles. Any WAF vendor that cannot show a prospective client, in proof of value, that their product will not require a team of people to manage it should make the buyer question how valuable and technologically advanced that product really is.
In my experience, these are some of the key reasons Legacy WAFs fail to deliver business value. The good news is the WAF market is not completely devoid of innovation. At Signal Sciences, we’ve taken a fundamentally different approach to building the industry’s first Next Generation WAF. It addresses all of these issues through a DevOps-friendly architecture, an emphasis on democratizing security data, the ability to be agnostic to your chosen cloud & CDN providers, and a unique blocking approach that’s not solely based on regular expressions or signatures.
If you think this type of approach might be a fit for you—we’d love to talk!
At Signal Sciences we are building the industry’s first Next Generation Web Application Firewall (NGWAF). Our NGWAF was built in response to our own frustrations of trying to use legacy WAFs while enabling business initiatives like DevOps, cloud adoption and continuous delivery. The Signal Sciences NGWAF works seamlessly across cloud, physical, and containerized infrastructure, providing security without breaking production traffic.