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.
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:
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.
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.
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.
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.
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.
19 Feb 2015