In this post: Learn the advantages and disadvantages of two common firewall solutions: cloud WAF vs on-premise traditional firewall. 

The threat landscape is constantly changing—that’s nothing new. And as an IT leader, your title is often synonymous with “decision-maker.” In order to stay ahead of the next data breach or DDoS attack, you must remain vigilant and make real-time decisions about the technology that you are putting in place for your network and application defenses.

One such decision you might be facing is how best to defend your network perimeter and your applications. The experts at ADAPTURE weigh in on the pros and cons of the common firewall solutions.

Defining the Terms

Let’s establish some common vernacular before we move on:

  • A next-generation firewall (NGFW) is a deep-packet inspection firewall that goes beyond enforcing a set of predetermined rules about what traffic (data packets) can enter or exit a network—NGFW adds some application-level inspection, intrusion prevention, and security intelligence in addition to the layer 2-3 firewall.
  • A web application firewall (WAF) is a firewall that monitors, filters, and/or blocks web-based traffic as it travels in and outside of a web-based application. WAF devices can contain signature sets for negative based security policies and behavioral inspectors for a positive security model. WAFs can also have a way to customize security protections as well as allow third party integrations for automation of the protection criteria.

On-Premise WAF vs. Cloud WAF

In short, WAF in the cloud and WAF on-premise serve a very similar purpose. It’s the same service, you are given the same options, and you have almost all of the same abilities. Where the two firewalls begin to differ is in their architectural complexity.

On-Premise WAF

A WAF intrinsically looks at everything that comes through it from the web application, regardless of direction. Inbound and outbound are seen as different paths, and both are inspected with the same level of scrutiny.

So, because on-premise WAFs are often positioned as close to the application as possible, they deal with a considerable workload because they are fielding all traffic from external users as well as your internal organization’s traffic to the application. When you put a WAF in front of a web server, it looks at everything, regardless of whether it is malicious or not. Even if the traffic is generated by internal IP addresses—by employees doing honest, every-day work—that traffic still has to be inspected as if it were potentially harmful. Also, because of the additional internal IP addresses that must be monitored, the architecture and configuration for on-premise WAF devices can be much more complex.

Cloud WAF

Much like a traditional on-premise WAF, a cloud WAF is placed directly in front of the application.

With a cloud WAF, it becomes solely about the individuals trying to access that particular application from the outside—there is relatively no internal traffic to deal with. While the default operational use is for bidirectional inspection, a cloud architecture has little to no traffic that originates from the internal network.  This one-way street enables you to simplify and focus your detection criteria at a more granular level because the volume and variance of traffic is considerably reduced. This is a more succinct policy, and, as a result, it gives you more control over your blocking and filtering parameters.

Filtering Differences

For instance, with an on-premise traditional WAF in contrast to cloud WAF, if a certain stream of traffic is blocked, it could affect several other applications externally or workloads internal to the organization. You must then either roll that back or deal with the effects on your internal users. With a cloud WAF, however, you manage permissions directly and can just block that single stream of traffic to that one application with no real impact to internal users. In this way, you only chance affecting one subset of people. Even then, because cloud is more flexible, you can mitigate the problem by simply adjusting the policy for that instance.

WAF vs. Next-Generation Firewall (NGFW)

NGFWs—even though they claim to grant application visibility—are limited in their ability to detect differences in traffic input (e.g. IIS vs. Apache) because while they can detect the type of protocol, they lack the depth of insight available in more dedicated application firewalls.

This ability to discern between traffic inputs is important because of how NGFW directs traffic and mitigate threats. For example, IIS has specific web functions and locations where developers can put code and images, etc. With Apache, it’s an entirely different architecture. Therefore, when you apply security to a web server based on Apache, it will be entirely different than with IIS. Understanding the differences between web server architecture and how it works helps you better protect that webserver from potential threats.

Detection Differences

NGFWs are powerful but lack that laser precision of a WAF when it comes to security. They quite literally don’t know better. Conversely, WAF holds signatures for the entire threat base and can make smart decisions based on that data. For example, NGFWs can detect that content has been placed in a user field, but not what that content or characters is. If an input is obfuscated by encryption or escape encoding, the firewall could, in essence, be blind to that input.  WAFs, on the other hand, are contextually aware and can detect a specific character or decode character inputs and simultaneously prevent it making them not susceptible to SQL injections (like NGFWs can be).

Designed for Different Locations

Architecturally, NGFWs sits at the border of the environment and provides perimeter protection; while NGFWs are capable of processing lots of traffic quickly, they have a limited ability to protect, and they are more porous by design. WAFs sit directly in front of the application itself, so it has a more restrictive entry point with better protection criteria for a specific resource than a border device does. Because of their deeper understanding of the application design and traffic, you can more capably restrict the traffic to “learned” values and vectors that are known to be safe for that specific application.

Choosing the Right Devices

Even though the field seems to be stacked towards cloud WAFs, you still have a decision to make. You will always need the detection and mitigation at both the network and application levels, so your decision is no longer a matter of which one, but how you should deploy each one.

NGFWs are broad, WAFs are surgical—but you can (and should) optimize them to work together to create a more robust security and monitoring mechanism for your networks and applications. Where one is limited, the other can step into the gap. According to ADAPTURE experts, you will have a healthy mixture of both WAFs and more traditional NGFWs in an ideal environment, where each one communicates with the other for cohesion while they continue to complete their unique tasks independently.

Categories: SecurityTags: