Co-authored by Erez Azaria, VP, WAF Development at StackPath
Today’s blog post is about our vision of modern web application security here at StackPath and how we have made strategic architectural decisions to build a best-in-class cloud Web Application Firewall (WAF). Let us lay some foundational knowledge down first, then we will discuss how we think about communication between the different segments of our WAF.
It’s common to differentiate between two types of WAFs, traditional first generation WAFs and next-generation WAFs (sometimes called a WAAP—web app and API protection—for the added API protection).
First-gen WAFs are usually on-prem appliances or web server add-ons that provide a signature-based rule engine. Just like your “old” antivirus, they contain a set of rules and patterns designed to scan and detect commonly known attack vectors. This rule set must be updated periodically to protect against new threats as they emerge, typically in a manual process.
In this model, the attacker could easily get the upper hand because a signature-based engine is reactionary by design, and the client remains exposed to novel vulnerabilities (a.k.a. zero days attacks) when the WAF rule set was in-between updates.
Modern antivirus already evolved from that signature-based engine and now can proactively act based on how a certain application behaves on the operation system. In the same way, compared to a traditional first-gen WAF, a next-gen WAF will also have behavioral analysis to enable it to assess the risk a certain client poses.
When it comes to developing a next-gen WAF, it is easier to develop a more sophisticated behavioral component if this part is built over a scalable cloud like environment. Having it on the cloud creates the resource rich environment required for deep analysis, without having memory or processing limitations.
As a service, the solution will probably need to be multi-tenant and designed in such a way that it can share resources on both the technical and informative levels. This way, you can deduce behavioral anomalies from traffic on one domain and immediately be able to act on this information, when applicable, on another domain. Without sharing of the deep analysis, it can be more resource heavy and less effective.
Not all next-gen WAFs have the same capabilities. The ability of a WAF to assess risk is derived from several key factors:
As mentioned, only cloud-based services have the potential of initiating deep analysis processes in an effective and scalable way. Only they may have a centralistic processing power that could potentially scale to sustain continual machine learning, keep multiple entities’ histories, and cross-reference behavior of traffic on multiple domains.
The fact that cloud-based services can potentially have these capabilities doesn’t necessarily mean they all have it. In fact, many of them have only a partial set of the mentioned abilities.
Most of the time, the architecture of cloud-based next-gen WAF service will be composed of two parts:
Many of the cloud WAF services that have the above-mentioned key factors of risk analysis and a centralistic deep analysis, encounter an architectural problem with the implementation of efficient information circulation between the two main parts of the system.
The first part, which is in essence a first-gen WAF, will mitigate all things that do not need deep analysis acting solely on the information found on the request itself against its known rule set. This engine will be responsible for mitigating IP, IP range and location blocklists and whitelists, protocol anomalies, signature-based blocks, and other pre-defined rules (i.e., OWASP Top 10). It will also be able to assimilate and act on the directives that are sent from the second part, the behavioral component.
The second part, the behavioral or deep analysis component, will be responsible for the “long processing”. Anything that takes more than a single request to deduct or any information that takes a longer time to retrieve will be done by the behavioral component. Eventually, this part will formulate a rule or an action, and the latter will be sent to the WAF edge node (the first part) to be enforced.
With the “short analysis” and “long analysis” components, essentially you have two types of brains now working on this cloud WAF. Each one operates almost independently. A rule that was created by the behavioral component is now pushed to the WAF edge node and enforced, along with the other rules the WAF edge node has. Because these rules are formulated on different places they are sometimes competing and at times conflicting in nature, but most importantly they are separated and cannot be easily integrated.
To solve this split-brain situation, we architected our WAF to decouple the information layer completely from the rule/action layer. This gave us the ability to logically unify the information producing components together even though they are located on different places. Through this, we were able to de-silo our rule layer and our analysis layer.
The centralized analysis part of our WAF is called TACT, short for Traffic Analysis Classification and Tagging.
TACT is a proprietary machine learning platform that enables real time data transformation, data processing, data retravel, data storing, imbedding external data sources and AI models-based analysis for each request that flows through the system. The products of this system, as the anacronym suggests, are information tags rather than rules or actions.
These tags can be produced on different entities of a request like the session, IP, range, fingerprint, or domain and once produced they are transferred to the same POP that originally proxied the request.
Our WAF edge node, though still responsible for running the WAF rule set and implementing actions, also contains more traditional components like a regular expression engine for scanning attack vector signatures. With TACT in place, any engine such as this that involves information processing will also generate information tags on the request entity.
The last step of this architecture was to design an efficient information circulation management between the TACT and the WAF edge node. We created a mechanism that knows how to effectively communicate any additions, updates, and expirations of tags between the two components. We also developed another feedback loop for information tags that have been generated on the WAF edge node, so this information could feed back to our heuristics on TACT.
This means that instead of having a split brain where each part is independent and agnostic, the two “hemispheres”, the WAF edge node and TACT, are now highly integrated and comprise a single logical “brain”.
Our WAF now produces industry leading levels of granular insight. Empowered with information from the edge and an intelligent central security cloud, one can form rules that will act on this information, no matter where it originated from. For the user, the engines and entities that carry the tags are completely transparent and easily actionable.
The decoupling of the two layers and introduction of TACT created additional significant advantages.
Analysis happens all the time, regardless of the existence of a rule, providing security practitioners with clarity as to what is the available information for any given requests that flows through the system.
This means that you can easily:
All of this results in a more nimble, self-improving web application firewall that puts the power back in our customers’ hands. It’s easy to see why more enterprises are choosing StackPath for their WAF needs.
