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.
WAFs and SSDLCs
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.
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.
