Get started Bring yourself up to speed with our introductory content.

Business-use scenarios for a Web application firewall deployment

Web application firewalls can be a critical security layer for many companies. Expert Brad Causey explains when and how to deploy a WAF in the enterprise.

Web application firewalls (WAFs) have been around long enough that the Web security industry is now quite mature. After all, the first WAFs appeared in the late 1990s to address growing threats attacking applications directly. Today, WAF offerings range in cost from free to hundreds of thousands, and vary widely in their implementation models.

While WAFs have grown in maturity and popularity over the years, so too have Web-based threat actors that they defend against. These actors can be anyone from a teenager testing out newly learned SQL injection skills on an organization's website, to a nation-state sponsored attacker looking to steal its proprietary information.

What makes Web security so challenging is that WAF design has to be both "open" and secure. It has to maintain wide availability while maintaining proper user authorization and data security. For example, HTML pages of old were never designed to protect entire databases full of credit card information or enterprise systems from determined hackers. Web-based VPN portals are especially challenging in that they are designed to be a secure access channel into a company, and yet they exist on the open Internet -- meaning anyone can make a call to the webpage and access its unrestricted content.

These are just a few of the reasons why many companies today are turning to WAFs, in their many forms, to meet the need for a "bolt on security" approach that protects company networks and resources -- as well as partner and customer data -- from malfeasance over Internet. While Web applications are fantastic for convenience and compatibility, they also create additional attack surfaces on any data they have access to.

These factors must be taken into consideration to help organizations better understand when or why (even if) they are in need of a Web application firewall deployment.

WAF scenario #1: Online vendors

While Web applications are fantastic for convenience and compatibility, they also create additional attack surfaces on any data they have access to.

The first and most compelling reason to deploy a WAF is to protect business data and services. Thousands of businesses, from the small town bank to the largest enterprise, rely on their Web presence to bring in revenue and keep the company afloat. If this revenue stream becomes compromised, the business would be negatively impacted in a number of ways, including:

  • Loss of direct revenue -- By a Web resource becoming unavailable, a company may lose a significant amount of money from purchases not occurring or leads not being generated.
  • Loss of customer confidence -- Many consumers and customers pay attention to news stories about particular businesses that have been hacked, and they make a mental note not to do business with that vendor. Reputation is important.
  • Loss of sensitive data -- In many cases, websites being compromised have led to hackers accessing sensitive information such as credit card details, names, addresses, Social Security numbers and medical information. Other forms of protected data can include proprietary information, trade secrets and even classified government data. While this in and of itself is bad, the fines and cost of disaster recovery/forensics can exceed every other financial impact to the organization.

While employing a WAF won't guarantee these incidents won't happen, it is a key part of a comprehensive, layered approach to IT security that can help greatly lower the odds that they will. And, if an incident does happen, a WAF can help reduce its impact on an organization, its customers and partners, as well as the bottom-line.


There are a number of reasons an organization may not be able to rely solely on a secure software development lifecycle (SSDLC) -- SSDLCs are effectively versions of the standard software development lifecycle where security is applied at all stages. The primary problem with implementing a SSDLC is that it takes time, money and technology to implement and support, which is not an easy proposition. Since the ultimate goal is to produce a secure product, a WAF can be introduced in front of the network-facing components (even if they aren't browser-based) to increase security.

Organizations can "bolt on" the WAF to services and applications, and without much effort, tune it to properly defend Web applications from attacks. This will effectively buy organizations enough time to complete whatever security analysis is required and close any problems discovered. In some cases, newly purchased online services can be protected while businesses work out a way to ensure security testing where it didn't exist before.

It's important to understand that a WAF is not a replacement or substitute for proper Web application security and testing. It is a security tool that exists at one layer in an overall approach.

WAF scenario #2: Consumers of Web services

Nearly every organization does business with online vendors nowadays, and, in many cases, even hosts Web services owned and provided by others. This presents a unique problem because enterprises aren't directly able to control the security of Web services belonging to outside organizations. As a result, these services may still introduce risk that requires mitigation.

Most large companies, as an example, may purchase human resources (HR) software to host internally or, perhaps, buy as a cloud-based service. Even if the HR application is hosted internally, the user license agreement may prevent the organization from performing detailed security testing. If the product is cloud-based, then things become even more complicated, because the Web host, software owner and service provider would all have to provide written permission for detailed security testing.

Another example of this is when a company purchases a third-party service for branded use by their customers. In the banking industry, many small financial organizations will purchase an online-banking product, and have it branded as their product but hosted elsewhere. That's a tough position to be in, because the financial institution doesn't directly control the hardware/software of the online banking product.

Fortunately, since the bank does control the DNS information, all traffic can be routed through a WAF, thereby offering an additional layer of security with minimal performance impact on the site itself.

Thankfully, WAFs aren't picky about who they are protecting. Organizations can place them between themselves and the service, or between the service and others. Even if a company buys an application for use internally, they can place a WAF in front of it in order to reduce risk to the site and its data.

The vast majority of computer security incidents within organizations start at the endpoint, the user's PC or mobile device. From there, as has been seen in recent large retail compromises, the infection can spread to Web resources. And, from there, the sky is the limit as to how much trouble the breach can cause. With a WAF properly deployed between the endpoints and a Web application, organizations can help to prevent these incidents from happening in the first place.

Web application firewall placements
As you can see here, regardless of who is accessing a resource (internal users or public Internet users) or where that resource is located, a WAF product exists to protect it.

Either WAF placement (see image above) can be ideal when an organization is providing Web services. It can also give them time to get the security lifecycle of the code-base up to par.

The great thing about modern WAF deployments is that they support the decentralization of Web resources organizations are wishing to protect today; the placement of the WAF itself is flexible. The flexibility in placement of WAFs means organizations can (likely) avoid having to redesign existing architectures or relocate servers to support the deployment of more comprehensive web application security.

WAF preparation: Questions and obstacles

Any time an organization considers deploying a new technology, it should look at it from a number of angles. These include closely examining the company's goals, budget, etc. Analyzing the validity of a WAF purchase is no different.

  • What is the true risk? This is an important question that will determine how an organization applies budgetary constraints. For example, if the Web resource it wishes to protect doesn't house customer data, but only generic marketing data -- which isn't at risk of exposing the company -- the monetary risk to the organization could be more related to general availability and malware risks (and not so much to Web application risks). If those are relatively small, then a simple cloud-based WAF could be a quick and easy product.
  • What functional requirements exist? Many WAFs vary widely on the volume and quality of features they offer. In some cases, a turnkey system with limited I/O is acceptable or desired, and can make implementation simple. For example, a simple blog or forum website could do fine with a basic WAF. Where more configuration options, centralized logging options and frequent changes will be required, a more robust (and costly) product is in order. A good example of this would be a website like Amazon or WebEx where the business logic can be quite complex.
  • How technical is the implementation team? In many cases, large and complex Web applications will require large and complex implementations. This can mean complex rule-sets that don't break the application, or extensive failover and redundancy configurations. It's important to consider the organization's internal IT skill base or the cost of bringing in contract resources for the implementation. Include that cost along with the initial estimate when determining the total cost of a WAF deployment. WAF vendors should be able to offer some close estimates for the total deployment cost based on previous experience.
  • What is the current and future planned architecture of the Web resource? Web applications, by design, can be located anywhere on or off the company network and run with any combination of technologies. Make sure a proposed WAF product is compatible with any future plans the organization may have for the application. As an example, a change from Java to .Net and from Oracle to MSSQL could mean that it needs to pick a different WAF product if the one they've selected or currently have deployed doesn't support protecting the change in platform.

Making a business case for the purchase and implementation of a WAF product doesn't have to be complicated, but it should be well planned and thought through. Most importantly, make sure the security and development teams are involved, as they will both be significantly impacted and will be responsible for integrating the new technology with existing Web resources.

Next Steps

In part 1 of this series, learn about the basics of Web application firewalls in the enterprise

Part 3 of this series looks at the four questions to ask before buying a Web application firewall

Part 4 compares the best Web application firewall products on the market.

Learn more about Web application firewall deployment in this technical guide

Read how WAFs may not fix all Web application security issues

This was last published in February 2015

Dig Deeper on Application firewall security

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Are Web application firewalls an effective way to reduce Web-based threats?
The point of a Web application firewall is to protect users from Web-based threats that infect through the Web application. These are an effective security measurement, but are only useful for novice computer users and children. At some point, you will have to access something that these firewalls will attempt to block. The firewall may also miss something.

Web application firewalls do help protect users from Web-based threats, but they only help to an extent.
I think that’s a good point, and needs to be kept in mind. WAFs do help protect, and are a good place to start, but good security is, by necessity, multi-layered, so they should not be considered as the only security measure taken. One thing that struck me in reading the article was that WAFs could be used as a first line of defense in scenarios in which organizations are rapidly deploying small changes to, and testing in them in, the production environment. These scenarios typically involve making the updated functionality available to a small number of users. In this situation, it could make sense to “bolt on”  a WAF, giving the security team some extra time to implement a stronger, more sophisticated and layered security solution before the change is made accessible to the population at large.
As Steph points out, it can easily be defeated by the user. And as I've said multiple times, the human element is the one element that causes most issues when it comes to data or facility security. People are the weak link, so we need more than just Web app firewalls if we expect our apps to be secure.
Firewalls will only tackle one part of the problem. You still likely need on staff Information Security personnel to monitor systems, routinely apply security patches, and looking for the next attack vector to prevent it before it is exploited.
A firewall is only marginally comforting. As other have noted here and elsewhere, users who like to keep all the doors open for easy access are the real problem. There's only so much safety that can be programmed into an app; what we need is better education & better training. Smarter, more careful users wouldn't hurt either, but that may be asking for too much.
Security, and threats to it, are volatile. A WAF, especially if your app is externally hosted, is an essential layer to a proactive, preventative approach.
I believe a web application firewall can provide additional security to applications, especially as the number of vectors to attack applications continue to grow. It allows you to be a little more proactive in cutting off many potential attack vectors for vulnerabilities.
Has anyone done a business case on why to use WAF?