4 Environment Support
To be effective the WAF has to work well in your environment. The following section describes aspects of a
WAF required to support your environment. It is split into [two] sections. The first describes the options for
deployment and the requirements your organization might have regarding those options and the impact to
the environment. The second aspect is the support offered for the elements of the target environment. This
further includes 2 aspects, support for protected applications support for environment options and ability to
implement environment options. [MK: The example here is support for various authentication options vs.
implementation of those options.]
Evaluation guidelines: unless described otherwise, for each criteria group below select and evaluate only the
criteria that are relevant to your organization. Keep in mind that requiring unneeded criteria may lead to
higher cost and complexity in the solution selected.
4.1 Deployment Model
4.1.1 Packaging
Packaging is often a matter of corporate culture and usually does not have significant effect on the quality of
the solution. Verify that the WAF supports the packaging method your organization prefers. Note that
method of delivery will limit the deployment architecture options available and vice versa.
Delivery
Method
Description
Deployment Architecture
Options
A.
Appliance
Software bundled with hardware. Appliances are usually
highly optimized and may contain specialized hardware
components to increase performance (e.g. SSL
processors), availability (e.g. “fail-open” network
interfaces) or perform other specialized functions (e.g.
Lights-Out Management, or “LOM”, interfaces.
Reverse Proxy
Transparent Proxy
Transparent Bridge
Non-inline
B.
Virtual
Appliance
WAF is delivered as software packaged as an installable
virtual instance for a specific hypervisor, e.g an .OVF file
for VMWare ESX. Often a specific minimum configuration
of resources (memory, disk, etc.) is required.
Reverse Proxy
Transparent Proxy
Transparent Bridge
Non-inline
C.
Software
WAF is delivered as an application that can be installed
on a generic computer. Often a specific reference
configuration of hardware and operating system is
required.
Reverse Proxy
Transparent Proxy
Transparent Bridge
Non-inline
Embedded
D.
Software
as a
Service
(SaaS)
The WAF is provided to the user as a service. In this
scenario the physical delivery model for the software can
be hidden from the user. This model is typical for
”Cloud” models, but can also be relevant in hosted
environments or even for on-premise deployments
managed by a managed service provider.
Reverse Proxy
Transparent Proxy
4.1.2 Deployment Architecture
Depending on size your organization may need just one deployment option. For large organizations with a
variety of applications and environments, more than one option may be needed. Verify that the WAF
supports the deployment mode or modes you prefer:
A.
D.
Deployment
Architecture
Description
Delivery Model Options
Reverse
Proxy
Application traffic is re-directed through the
WAF, typically using DNS reconfiguration or
networking changes. The WAF terminates the
HTTP session with the browser and opens a
separate session to the application server.
Appliance
Virtual Appliance
Software
SaaS
Transparent
Proxy
"A 'transparent proxy' is a proxy that does
not modify the request or response beyond
what is required for proxy authentication and
identification".i Typically, this means that the
client IP appears to the server to be the same
as the true source IP of the client.
Appliance
Virtual Appliance
Software
SaaS
Transparent
Bridge
Application traffic is intercepted by the WAF
at layer 2. This is typically accomplished by
deploying the device at a network location
through which user sessions normally flow,
but in some cases can be accomplished via
routing or other networking changes. The
WAF does not terminate the user session,
allowing the traffic to pass unaltered from
browser to server.
Appliance
Virtual Appliance
Software
Non-inline
Application traffic is forwarded “off-line” to
the WAF device through a SPAN port or other
network monitoring mechanism. The WAF is
typically looking at only a copy of the traffic,
so no sessions are terminated or otherwise
affected. If desired, blocking must be
accomplished via an indirect mechanism.
Appliance
Virtual Appliance
Software
Deploying WAFs in non-inline mode
significantly reduces the possibility of
blocking and is mostly valuable for proof of
concept, learning mode, or for information
centric deployments. Make sure that the
sniffer supports passive decryption of SSL
traffic.
Embedded
Application traffic is intercepted by
embedding a WAF as a software module on
the web server.
Offers horizontal scalability with the number
of Web Servers used but may affect web
Software
server performance. You will need to verify
that the WAF supports your web server.
4.1.3 High Availability and Clustering
Depending on the availability requirements of your organization you may want to select one of these high
availability strategies. Depending on the characteristics of your WAF and your environment, high availability
may be achieved “natively” meaning that the WAF itself provides the high availability mechanism or
externally, meaning that the infrastructure of the environment provides the mechanism.
A.
Fail Open
Upon failure, traffic is forwarded directly to
the application, bypassing the WAF. In this
scenario, application up time is preserved, but
security functionality is lost during the down
time of the WAF solution.
Does fail open apply both to physical
(e.g., loss of power) and software
(e.g., software hang) failures?
B.
Fail Over
Upon failure, control transfers from a primary
WAF to a backup system. Fail over systems
should ensure minimal disruption of service
during fail over.
What is the latency of switching
nodes?
What is the affect on sessions and
session security when switching
nodes? For many applications
resetting sessions will be acceptable
and can reduce the complexity of
configuration of fail over.
Can nodes be geographically
distributed across data centers? How
does this affect failover and state?
C.
Clustering
An implementation in which multiple systems
work simultaneously to increase performance
and provide fail over between nodes.
Can nodes be geographically
distributed across data centers? How
does this affect failover and state?
For performance related aspects of high availability, refer to the “performance” section [XXX].
4.2 Application Support
It is extremely important that the WAF works seamlessly with your applications. This will ensure the
availability and functionality of your application as well as allow the WAF to protect it effectively. This
section lists a selection of the possible requirements related to application support. It would be impossible to
list all of the possibilities and many smaller organizations will require only a subset of the items listed in this
section. Larger organizations, with a more diverse application portfolio are more likely to require a broader
set of supported technologies.
Evaluation guidelines: The best method to ensure a WAF works with your application is to test it, i.e. to
run an acceptance test with the WAF deployed and configured.
4.2.1 Specific Application Support
For many organizations the applications in scope for WAF protection will be limited to a specific set of
applications. In this case the best option is to list these specific applications and evaluate whether the WAF
works well with them.
4.2.2 Application Protocol Support
For organizations with a broader application base or that anticipate the need to support a broad range of
application technologies, the following is a list of potential application technologies that a WAF may or may
not support. Its importance to your organization depends on whether you use the technology or not.
A.
HTTP
HTTP is the fundamental underlying
protocol for many web applications. Verify
that WAF supports the version(s) in use by
your application portfolio.
Verify support for relevant versions:
1.HTTP/0.9
2. HTTP/1.0
3. HTTP/1.1
Verify support for encoding types in
use. Widely-used encoding types are
below (yours may vary):
1. application/x-www-formurlencoded encoding
2. multipart/form-data encoding
3. v0 cookies
4. v1 cookies
5. chunked encoding in requests and
responses.
6. request compression
7. response compression
B.
JSON
JSON is a protocol often used for modern
and “mobile” web applications. If it is in
use by your application portfolio verify that
the WAF supports this use.
C.
Other
[MK Are there other application protocols
we would want to include as “standard”
ones to look at? In some of the comments
on WAFEC v1, HTML5 was mentioned
which doesn’t quite fit this section on
protocols…does it justify a separate
section?]
[MK: looking for input as to what to
put in here as standard support
items related to JSON]
4.2.3 SSL Support
SSL is often used to encrypt the communications between the browser and the applications. In order to
inspect and protect the application a WAF must be able to get access to the unencrypted stream.
A.
Access
How does the WAF access SSL
Terminates SSL. The network needs to be re-
encrypted communication?
configured to move the SSL operations to the
WAF itself. WAF decrypts the encrypted traffic
to get access to the HTTP data. The
communication between the WAF and the web
server can be in plain-text, or SSL-encrypted.
Passively decrypts SSL. Configured with a copy
of the web server's SSL private key WAF
decrypts the SSL traffic. The original data
stream travels unaffected to the web servers,
where it is separately decrypted and
processed.
Embedded. Working embedded in a web
server, a WAF can be positioned to work after
the SSL data is decrypted on the server.
B.
Cipher Suites
A Cipher suite refers to the
encryption algorithms used to
encrypt and decrypt data.
Does the WAF support the cipher suites that
are in use by the applications?
[MK do we want to list ciphers here? We had a
list in WAFEC v1 and resulted in a lot of
misguided check box evaluations]
Some servers allow negotiation of cipher suites
based on support by the browser. This may
result in an unacceptable cipher suite to be
used either unintentionally or via a crafted
attack. Can the WAF enforce a minimum or
specific cipher suite.
C.
Client
Certificates
Client certificate
D.
Implementation
Security
Some environments require
special certification of the
handling of private encryption
keys and/or certification of the
underlying encryption software.
Can the WAF retrieve SSL keys from an
external key storage facility (e.g. local or
network-based Hardware Security Module)?
Is the SSL implementation FIPS 140-2 certified?
Which FIPS levels are supported (level II and/or
III)?
4.2.4 Authentication Support
Many applications that warrant the protection of a WAF are authenticated applications. As such it is
important that the WAF can support the authentication methods in use for your applications.
For all modes, verify the following for all relevant authentication schemes:
1. Application functionality and authentication continues to operate with WAF in place?
2. WAF can identify users for policies?
[MK In some cases, users will want the WAF to be the point of authentication, I feel this should be in “other
functionality” do others agree?
A.
Authentication
Scheme
Considerations
Client Side
Certificates
Are client certificates supported in all relevant modes for the
deployment?
For termination mode, can the content from client
certificates be sent to the application using some alternative
transport method (e.g. request headers).
B.
Basic
Authentication
C.
Digest
Authentication
D.
NTLM
Authentication
E.
Other
Many applications use an outside software or service for
authentication. For example, higher security environments
might require a two-factor authentication for users. These
solutions might use a combination of the above methods in
combination with proprietary capabilities. Verify the WAF
supports the specific authentication product or service in
use.
Reverse
proxy
Transparent
reverse
proxy
Transparent
bridge
Out of
line
Embedded
Network
architecture
changes
Yes
No
No
No
No
Software
configuration
changes
Yes (1)
No
No
No
Yes requires
installation
on each
web server
that needs
protection
Site/application
changes
In some
cases (1)
In some
cases (1)
No
No
No
Network point
of failure
Yes, but can
be deployed
in HA
configuration
Yes, can be
when fitted
with a failopen card
or
configured
for high
availability
Yes, but can
be fitted
with a failopen card
or
configured
for high
availability
No
No
Change to
traffic dynamics
Yes.
Traffic
redirected to
proxy via
DNS or
routing
changes.
Yes.
Traffic
redirected
to proxy via
DNS or
routing
changes.
No
No
No.
Negative web
server
performance
impact
None
None
None
None
Competes
for server
resources;
can affect
server on
malfunction
Network
separation
Yes
Yes
Yes
No
No
Scaling
TODO
TODO
TODO
TODO
Easy; scales
implicitly
with web
servers
SSL
Termination
Termination
Passive
decryption
Passive
decryption
Not
applicable
Changes client
IP Address
Yes
.
No
No
No
No
Response
Options (see
section 3.2 for
definitions)
Passive
Active
Intrusive
Passive
Active
Intrusive
Passive
Active
Intrusive
Passive
Passive
Active
Intrusive
Content
rewriting
Yes
Yes
Limited
No
Yes
Notes:
1. There are two cases when application changes may be required:
1. If the site requires client IP address to operate correctly and it is not possible to modify the configuration of the
web server "fake" this information, then the only other solution is to modify the application to take the client
IP address information from somewhere else (typically request headers)
2. If the site relies on the SSL private certificates to operate correctly then it will have to modify to retrieve this
information from somewhere else (typically request headers).
i
RFC 2616 (Hypertext Transfer Protocol—HTTP/1.1) http://tools.ietf.org/html/rfc2616