George Lawton
Various types of internet firewalls have evolved to help mitigate security vulnerabilities at different levels of network connectivity. Web Application Firewalls (WAFs) emerged to protect a certain class of threats that affected the way web applications were built and deployed. WAFs have played an important part in the commercialization of the internet by making it safe to allow companies to connect more critical services, data, and applications.
In theory, companies would not need WAFs if applications were built using secure coding principles from the get-go. But in practice, web vulnerabilities continue to escape into production for various reasons including the use of legacy apps and libraries, convenience, difficulties in patching apps, and newly discovered weaknesses.
Next Generation Web Application Firewalls (NGWAFs) include advanced features to improve detection and classification of threats, policy enforcement, deployment of updates, and overall management. In practice, NGWAFs are a moving target representing the state of the art in improving the underlying technology for securing web applications. Over the last five years, NGWAF security features have been added as a standard part of most WAFs today and include the use of machine learning to reduce decision fatigue caused by false positives, and the ability to deploy and update with increased ease and facility.
Let’s take a quick look back at how WAFs have evolved to meet ever more sophisticated security threats and the current state of protection they provide, especially as attackers focus on API vulnerabilities.
How Firewalls Evolved Over 30 Years
Both WAF and NGWAF are part of the long evolution of basic firewalls. Internet firewalls were modeled after physical firewalls that mitigated the spread of fires in large buildings. Routers were introduced to separate networks and protect against problems such as misconfigurations and a flood of traffic from chatty protocols.
The first firewalls added explicit rules, called a firewall policy, to restrict traffic between networks after widespread security problems like the Morris Worm spread across the internet. The first generation were packet filter firewalls introduced by Digital Equipment Corporation in 1987. These were only able to enforce relatively straightforward rules related to the characteristics of the networking traffic such as IP addresses of source and destination, the type of protocol, and specific ports.
The next generation of stateful firewalls was introduced in 1989 by researchers at AT&T that operated at the level of connections or circuits. These allowed security teams to enforce more sophisticated rules related to properties of the connections. This made it possible to examine longer-running traffic patterns between specific sources and destinations. They were effective in mitigating attacks with known signatures that affected known protocol vulnerabilities.
They were less effective against attacks using allowed protocols that focused on weakness in applications. These could be broken by denial-of-service attacks that sent fake connection packets to overwhelm the system’s ability to keep track of connections.
Researchers introduced the first application firewall in the early 1990s. These made it easier to identify and block attacks caused by fake connection packets. They could also see when packets appeared to be operating outside the bounds of how applications were supposed to work and adapt to how these applications were supposed to communicate. Application firewalls take into consideration characteristics of the session, presentation, and application-level characteristics in their security rules.
The Rise of WAFs
Next Generation Application Firewalls evolved into the first WAFs in the late 1990s. These could provide greater security by taking into accounts the characteristics of HTTP traffic used for web services. These were able to address a host of emerging security threats such as SQL injection and cross-site scripting attacks.
In 2003, the OASIS Web Application Security Technical Committee developed the first Open Web Application Security Project Top 10 list that characterized the most common types of web attacks. This helped inform the development of standard WAF security features.
WAFs are often a key component for ensuring compliance with the Payment Card Industry Data Security Standard (PCI-DSS) mandated for secure credit card processing. A WAF can be a standalone appliance or run as a virtual service on other types of networking hardware such as routers or switches.
As new vulnerabilities are discovered they can be coded into new polices. These allow companies to beef up security of existing applications by making changes at the appliance layer with a policy rather than within the application itself, which might be harder.
WAFs improved thanks to better tools for implementing and tuning rules that block the most malicious traffic with the lowest rates of false positives. Older WAFs use static rules sets that make it difficult to increase detection while keeping false positives to a minimum.
In addition, attackers continue to bypass the latest policy enforcement mechanisms by finding ways to make changes to their attack signatures which the rules are designed to detect. In response, security teams must invest considerable resources in updating their rules.
NGWAF Improvements
Traditional WAFs faced several challenges related to false positives, the types of threats they prevented, deployment models, and management. Some vendors have begun using the term Next Generation Web Application Firewalls to describe tools used to address these limitations.
One of the challenges with all firewalls lies in striking a balance between detecting and preventing threats without blocking legitimate traffic. False positives will lead to either blocking legitimate traffic or unnecessarily alerting security teams. Alert fatigue results when teams must process too many false positives. False negatives, meanwhile, can allow attacks to continue undetected. NGWAFs support improved engines that promise to identify threats with greater precision.
WAFs traditionally addressed OWASP Top-10 threats. NGWAFs include more sophisticated policy engines that can detect and prevent other kinds of attacks such as malicious bots, credential stuffing, and distributed denial of service (DDoS) attacks.
Vendors are also making it easier to deploy NGWAF engines in conjunction with applications that may span various combinations of application-hosting models including servers, containers, cloud services, and serverless infrastructure. One example might be deploying an NGWAF on containers that can be dynamically deployed in conjunction with a microservice architecture running on Kubernetes. This makes it easier to scale the perimeter in conjunction with the applications.
NGWAF vendors have also improved the management tools that make it easier to automatically spin up new protection engines from a central console. These consoles also improve the ability to update the policies across various NGWAFs running on various types of infrastructure in response to newly discovered threats.
Stepping beyond Web applications
As has been the case with next generation application firewalls becoming WAF, NGWAF is really just WAF with evolved features. And there are just a few vendors characterizing their products as NGWAF. Its only a matter of time before the industry transitions to the next term everyone settles on describing the future of protecting APIs and the applications built on them.
WAF was conceived at a time when enterprises built their front door to the Internet as a web application. But more and more, enterprises are starting to provide services and data to customers and partners via APIs. These API services make it easier to provide a good user experience across web applications, mobile interfaces and conversational interfaces from a single back end.
However, WAF and NGWAF were designed to focus on the web application layer. APIs are generally built using web protocols but follow a different kind of logic and architecture than traditional web applications.
Enterprises will need to consider other types of tools beyond WAFs and NGWAFs to protect against attacks that target vulnerabilities in how APIs are implemented and connected. Many NGWAF vendors are beginning to add some support for API security on top of their traditional role in protecting web applications. In addition, a number of startups have emerged to focus front and center on the security challenges of protecting APIs built on traditional web services.
About the Author
George Lawton is a technology writer and regular contributor to The Inside Trace.
