8/9/22, 10:22 AM Business-use scenarios for a Web application firewall deployment

9 SearchSecurity
g
M Buying Decisions

FEATURE

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.

Brad Causey

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

z
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.

https://www.techtarget.com/searchsecurity/feature/Business-use-scenarios-for-a-Web-application-firewall-deployment 1/5
8/9/22, 10:22 AM Business-use scenarios for a Web application firewall deployment
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.

https://www.techtarget.com/searchsecurity/feature/Business-use-scenarios-for-a-Web-application-firewall-deployment 2/5
8/9/22, 10:22 AM Business-use scenarios for a Web application firewall deployment

k 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.

m 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

https://www.techtarget.com/searchsecurity/feature/Business-use-scenarios-for-a-Web-application-firewall-deployment 3/5
8/9/22, 10:22 AM Business-use scenarios for a Web application firewall deployment

m Dig Deeper on Application and platform security

API security strategies must evolve to include API protection

By: Sharon Shea

How to mitigate an HTTP request smuggling vulnerability

By: Mike Chapple

Signal Sciences: Enterprises still overlooking web app security

By: Alexander Culafi

Web application firewall (WAF)

By: Ben Lutkevich

-ADS BY GOOGLE

Cloud Facebook Ads Acc

Pre Warm up Fb ads acc
Fb ads Acc , 100% approved ads Pre warm up account

adslambo.com OPEN

NETWORKING
CIO
ENTERPRISE DESKTOP
CLOUD COMPUTING
COMPUTER WEEKLY

SearchNetworking

Wi-Fi sensing has the potential to be disruptive

With help from AI and machine learning, Wi-Fi sensing detects movement in the Wi-Fi environment. While it sounds promising, the ...

What an AI-driven network looks like

https://www.techtarget.com/searchsecurity/feature/Business-use-scenarios-for-a-Web-application-firewall-deployment 4/5
8/9/22, 10:22 AM Business-use scenarios for a Web application firewall deployment
Log analysis and wireless management are common AI use cases in networking. Future applications could include chatbot alerts, ...

About Us Editorial Ethics Policy Meet The Editors Contact Us Videos Photo Stories

Definitions Guides Advertisers Business Partners Media Kit Corporate Site

Contributors CPE and CISSP Training Reprints Events E-Products

All Rights Reserved,

Copyright 2000 - 2022, TechTarget

Privacy Policy

Do Not Sell My Personal Info

https://www.techtarget.com/searchsecurity/feature/Business-use-scenarios-for-a-Web-application-firewall-deployment 5/5