WAFEC 2
T h e We b A p p l i c a t i on F i re wa l l Eva l u a t i o n C ri te ri a Ve rsi on 2
Outline
Contents
1
2
Introduction
1.1
WAFEC Mission Statement
1.2
Using WAFEC
1.2.1
Structure
1.2.2
Evaluation Process
1.3
What’s New
1.4
License
What is a WAF
2.1
Definition
2.2
Use Cases
2.2.1
Logging and Troubleshooting
2.2.2
Attack Detection
2.2.3
Attack Mitigation
2.2.4
Virtual Patching
2.3
3
Minimum Requirements
Security
3.1
Threat landscape coverage
3.2
Mitigation
3.2.1
Blocking
3.2.2
Response
3.2.3
Throttling
3.3
Protection techniques
3.3.1
Positive Security
3.3.2
Virtual Patching
3.3.3
Signatures
3.3.4
Protocol Validation
3.3.5
4
Deployment Options
4.1
Method of Delivery
4.2
Network Integration
4.2.1
Deployment Architecture
4.2.2
Inline Modes
4.2.3
High Availability and Clustering
4.3
5
6
Session Tracking
Application Support
4.3.1
HTTP and HTTPS Support
4.3.2
Authentication Support
Supporting Features
5.1
Management
5.2
Reporting and Analytics
5.3
System Security
5.4
Performance
5.5
Reliability
5.6
Extensibility and Integration
5.7
Physical Characteristics
Appendices
6.1
Integrated Related Features
6.2
None Technical Criteria
6.3
Alternative and Complementary Solutions
6.4
Testing Framework
6.5
Suggested Weighting Schemes
6.6
Unaddressed Threats
6.7
V1 to V2 translation table
6.8
Response Table
1 Introduction
1.1 WAFEC Mission Statement
WAFEC provides interested partied, including users, vendors and 3rd party evaluators with a tool to learn
about WAFs and evaluate the suitability of different WAFs for specific use cases and environments.
1.2 Using WAFEC
1.2.1 Structure
WAFEC has two inherent goals: education and evaluation. Section ### “What is a WAF?” focuses on the
educational goal and set the framework for the following discussion.
When evaluating a WAF, one has to address several high level functional and technical criteria groups which
affect selection in different ways. A chapter of the document is dedicated to each one of them:

Provide sufficient security - WAFEC security criteria focus on results rather than methods used for
protection as those may vary between WAFs while still providing the same benefit. To that end the
key criteria is what threats, based on the Web Application Security Consortium Threat Classification
(WASC-TC) a WAF protects from. Not all the WASC-TC threats can be protected from by a WAF, and
those which cannot are omitted from the chapter and listed in appendix ###.
Protection methods and their implementation do affect the quality of the protection provided. To
that end, when evaluating based on WAFEC one needs to determine which methods supported by
the WAF are used for protecting from each threat. In addition a section of the security criteria
chapter is dedicated to Evaluating the quality of implementation of the protection methods. A WAF
does not have to implement all protection methods, however those implemented should be of
quality and address the listed threats

Suit the environment it is used at - To protect web applications a WAF has to be implemented in the
organization’s IT environment and be compatible with it. Compatibility focuses on two areas:
o
Deployment compatibility -
o
Protected applications compatibility – ensuring both that they continue to run and that they
are well protected.
When weighting those criteria, one must decide whether to require all or just the options required
for the specific use case at hand. While the former ensures more future flexibility it may lead to a
higher cost and complexity. One way around it would be to give a higher weight to the currently
needed requirements while giving lower weights to potential future requirements.

Include supporting features - Lastly, once deployed and protecting applications, a WAF needs a large
number of supporting features in order to be efficient and provide value. Those include
management, reporting, integration with other systems as well as self-security and performance.
While no WAF can exist without addressing many of those criteria, the list is long and a solution
never can or should implement them all. One should focus on the criteria which are relevant to the
environment in which the WAF operates.
While this document focuses on the intrinsic functional and technical criteria of WAFs, selecting a solution
may involve other criteria such as price, vendor reputation, quality of support and related features integrated
into the WAF. When analyzing the results a user must add such criteria. A list of criteria to consider in this
respect is included in Appendix ### but should not be taken as comprehensive.
1.2.2 Evaluation Process
The table at appendix ### provides a convenient tool for actually performing an evaluation. Note that it is not
enough to evaluate a criterion for yes or no. In addition an explanation of the implementation methods is
required.
Lastly, WAFEC does not provide weights for specific criteria as this would be too organization specific. This
does not imply that all criteria are equal in importance. As a guideline we suggest applying weights
hierarchically, first weighting chapters and then sections within chapters and so on to avoid weighting by
numbers or criteria rather than by importance. Appendix ### provides suggested weighting schemes.
1.3 What’s New
WAFEC v1 was release in 2006. Naturally the long time since justifies a new version of the document to
address the changing threat landscape as well as newer protection and deployment technologies.
Changes in the new version include:

To the extent possible, WAFEC now focus on feature and benefits rather than implementation
details. Implementation details are at times important to assess the quality of a solution and are
included in those cases.

WAFEC now clearly identifies what is a requirement and how to use it to evaluate WAFs.

Descriptive text is added to all sections and to individual requirements to help explain their context
and importance.

Add on features that do not directly support WAF core functionality (as defined by WAFEC) are
excluded from body of the document and listed in appendix ###.
Refer to appendix ### for a translation table between WAFEC v1 and WAFEC v2
1.4 License
This work is licensed under the Creative Commons Attribution License. To view a copy of this license, visit
http://creativecommons.org/licenses/by/2.5/ or send a letter to: Creative Commons, 559 Nathan Abbott
Way, Stanford, California 94305, USA.
2 What is a WAF
Note: the information in this section is descriptive in nature and should help the user to identify the
specific use cases that are required from a WAF in her organization. This selection affects the relevance
of criteria in subsequence sections.
2.1 Definition
2.2 Use Cases
2.2.1 Logging and Troubleshooting
<To be completed>
2.2.2 Attack Detection
<To be completed>
2.2.3 Attack Mitigation
<To be completed>
2.2.4 Virtual Patching
<To be completed>
<Any other use cases to be added here>
2.3 Minimum Requirements
<List of requirements (from other sections) that a WAF must have>
3 Security
3.1 Threat landscape coverage
Evaluation guidelines: For each one of the threats listed below evaluate the WAF detection and
mitigation capabilities using the following methods:
 Test the WAF for detection and mitigation of each threat.
 Establish whether a trusted 3rd party evaluator has tested the WAF detection and mitigation
capabilities for the threat.
 List the detection and mitigation techniques (from those listed in section ### or others) used by the
WAF to detect and mitigate each theat.
Since many of the threats below address a broad array of Note that the WAFs coverage for a specific
threat may be partial, for example limited to specific types of applications.
A WAF main function is to protect web applications from attacks. To do so, it has to detect and potentially
mitigate attacks. Therefore a key criterion for WAFs is their ability to detect and mitigate attacks.
WAFEC uses the Web Application Security Consortium Threat Classification1 (WASC-TC) as the base list of
threats that a WAF should detect and mitigate. Some threats cannot be effectively detected or mitigated by a
WAF and therefore are omitted (see appendix ### for a list of those). Note that WAFEC does not provide
descriptive text of threats and the reader is encourages using the original WASC TC description.
You may find the WASC TC Taxonomy cross reference2 useful if you would like to establish a WAF threat
coverage with regard to other taxonomies such as CW, the OWASP top 10 and SANS top 25.
1
WASC Threat Classification: http://projects.webappsec.org/w/page/13246978/Threat%20Classification
WASC Threat Classification Taxonomy Cross Reference:
http://projects.webappsec.org/w/page/13246975/Threat%20Classification%20Taxonomy%20Cross%20Reference
%20View
2
The threats against which the WAF should be evaluated are:
WASC ID
Name
WASC-03
Integer Overflows
WASC-04
Insufficient Transport Layer Protection
….
….
Notes
3.2 Mitigation
3.2.1 Blocking
Your security policy may require specific responses once an attack is detected. Those responses depend on
the deployment mode used and attack detected as described in the table.
<For an example of writing criteria refer to the “deployment option” section>
Examples include:

TCP Reset

Blocking source IP

Connection dropping

Session dropping

User blocking
3.2.2 Response
When denying a web request due to any of the blocking method above, a WAF should be able to provide one
of the following responses:
<For an example of writing criteria refer to the “deployment option” section>
3.2.3 Throttling
3.3 Protection techniques
Evaluation guidelines:
 Specify for each threat in section ### what protection methods are used to protect from it.
 In this section specify the attributes of the specific protection technique.
While the key to the effectiveness of WAF is the end result: which threats it protects from, protection
techniques and their implementation do affect the quality of the protection provided. Use this section to
evaluate the quality of the implementation of the different protection methods.
3.3.1 Positive Security
<Please add description>
<Please add criteria. For an example of writing criteria refer to the “deployment option” section>
Example Criteria:

Granularity of policy

Learning supported

Anti-Evasion techniques

URL rewrite and REST interface support
3.3.2 Virtual Patching
<Please add description>
<Please add criteria. For an example of writing criteria refer to the “deployment option” section>
Example Criteria:

URL rewrite and REST interface support
3.3.3 Signatures
<Please add description>
<Please add criteria. For an example of writing criteria refer to the “deployment option” section>
Example Criteria:

Used defined signatures

Granularity of signatures

Frequency of vendor update

Are updates automated?

Complexity supported by signatures

Exceptions supported

Learning supported

Anti-Evasion techniques

URL rewrite and REST interface support
3.3.4 Protocol Validation
<Please add description>
<Please add criteria. For an example of writing criteria refer to the “deployment option” section>
<Refer to section 2.3-2.5 of WAFEC v1 for examples>
3.3.5 Session Tracking
<Please add description>
<Please add criteria. For an example of writing criteria refer to the “deployment option” section>
Example Criteria:

Automated session identification

User defined session identification
4 Deployment Options
<This serves as an example section >
The WAF has to work well in your own environment. The following sections describe aspects of a WAF
required to support your environment.
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 Method of Delivery
Packaging is often a matter of choice and corporate culture and do not have significant effect on the quality
of the solution. Verify that the WAF supports the packaging method you prefer. Note that method of delivery
will limit the network connectivity options (see ###) available as described below.
A.
Appliance
Software bundled with hardware. Appliances are usually
highly optimized and may contain specialized hardware
components to increase performance. Are there other
optional hardware components that may further
increase performance (except for SSL, which was already
covered in 1.2)?
Relevant for Inline &
Sniffer deployment.
B.
Virtual
Appliance
Transfer control from a faulty system to a backup system
in case of a failure. Fail over systems should ensure
minimal disruption of service during fail over. Relevant
areas include latency of switch and granularity of
maintained state when switching.
For performance related aspects of high availability, refer
to the “performance” section below.
Relevant for Inline, Sniffer
and Cloud deployments.
C.
Software
Relevant for Inline, Sniffer,
Cloud and Embedded
deployments.
D.
SaaS
Relevant for Cloud
Deployment.
4.2 Network Integration
4.2.1 Deployment Architecture
Your organization will usually need just one deployment option. Verify that the WAF supports the
deployment mode or modes you prefer:
A.
Inline
Inline is the currently the most common option for WAF deployment.
B.
Embedded
Embedding a WAF in the web server offers easy scalability with the number of Web
Servers used but may affect web server performance. You will need to verify that the
WAF supports your web server.
C.
Cloud
Cloud deployment is similar to inline (in reverse proxy configuration) however traffic
is routed through a cloud based service. Cloud based WAFs are usually simpler to set
up but add latency to client requests.
D.
Sniffer
Deploying WAFs in sniffer mode significantly reduce 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.
4.2.2 Inline Modes
Inline mode may be provided in one of several networking configurations. Verify that the ones relevant to
your organization are supported:
A.
Transparent Bridge (two
legged connection)
Does not require network reconfiguration but must support fail
open network interface cards.
B.
Router (one legged
connection)
Requires network reconfiguration to direct traffic through the WAF
C.
Reverse Proxy
Traffic is re-directed through the WAF using DNS reconfiguration.
Note that Cloud based offerings would usually work this way.
4.2.3 High Availability and Clustering
Depending on your level of confidence in the WAF you may want to select one of these high availability
strategies:
A.
Fail Open
Upon failure, traffic is forwarded directly to the application bypassing the WAF
B.
Fail Over
Transfer control from a faulty system to a backup system in case of a failure. Fail
over systems should ensure minimal disruption of service during fail over. Relevant
areas include latency of switch, granularity of maintained state when switching and
physical separation permitted between systems.
For performance related aspects of high availability, refer to the “performance”
section below.
C.
Clustering
A fail over implementation in which both systems work in tandem to increase
performance. When one of the systems fail, the other one takes over service for
the communication serviced by the other system.
4.3 Application Support
It is extremely important that the WAF works seamlessly with your application. This will ensure the
availability and functionality of your application as well as allow the WAF to protect it effectively.
Evaluation guidelines: The best method to ensure a WAF works with you application is to test it, i.e. to
run the application acceptance test with the WAF deployed and configured. The criteria below will help
you to determine compatibility with ### .
4.3.1 HTTP and HTTPS Support
The following is a least of potential application delivery 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 Compressions
Upon failure, traffic is forwarded directly to the application bypassing
the WAF
B.
Chunked Encoding
Transfer control from a faulty system to a backup system in case of a
failure. Fail over systems should ensure minimal disruption of service
during fail over. Relevant areas include latency of switch and granularity
of maintained state when switching.
For performance related aspects of high availability, refer to the
“performance” section below.
D.
SSL Encryption
4.3.2 Authentication Support
A.
Client Side Certificates
B.
Basic Authentication
C.
Digest Authentication
D.
NTLM Authentication
5 Supporting Features
Like any other information technology system, a WAF needs to include a large number of features in addition
to the core security functionality to make it useful.
5.1 Management
<Please add description>
<Please add criteria. For an example of writing criteria refer to the “deployment option” section>
Examples:



Access:

Thin vs. thick client

Command Line interface

Central management of multiple sensors
Functionality:
o
Configuration roll-back
o
Manually accept false positives
o
Support for trusted hosts
Log Management:
o
Log Retention
o
Event Signing
o
Scrubbing
o
Indication of detected attack
o
De-duplication
5.2 Reporting and Analytics
A WAF is expected to provide reporting and analytics capabilities over data entities it manages focusing on
detected events.
<Please add description>
<Please add criteria. For an example of writing criteria refer to the “deployment option” section>
Example Criteria:

Full Transaction Store

The quality and amount of out of the box reports

Level of customizability of reports

Options for report output formats

Options for report scheduling and distribution.
5.3 System Security
Evaluation guideline: Many of the criteria below may be mandated by your organization’s security policy.
Otherwise, the more criteria listed the WAF satisfies, the better secure it can be considered.
The WAF itself must be secure from external attacks as well as insider abuse. While assessing the security of
an information system is a complex task, the following criteria provide strong indication as to the level of the
security of the WAF.
<Please add description>
<Please add criteria. For an example of writing criteria refer to the “deployment option” section>
Example Criteria:


Management:
o
Management Role based access control
o
Management Audit Log
o
Separate management network interface
o
Encrypted management access
o
Two factor authentication
Encryption:
o
FIPS 140-2 certification
o
Hardware based key storage

Automated patching to the underlying operating system

3rd party security assessment
5.4 Performance
5.5 Reliability
5.6 Extensibility and Integration
<Please add description>
<Please add criteria. For an example of writing criteria refer to the “deployment option” section>
Example Criteria:

Management API

Event export using: Syslog, SNMP Traps, Log file, Accessible log DB tables, Web Services
5.7 Physical Characteristics
<Please add description>
<Please add criteria. For an example of writing criteria refer to the “deployment option” section>
Example Criteria:

Size

Power consumption

CE certification
Evaluation guideline: these criteria apply only to an appliance based solution.
6 Appendices
6.1 Integrated Related Features
6.2 None Technical Criteria
Examples:

Price

Vendor characteristics

Integrated functionality
6.3 Alternative and Complementary Solutions
Examples:

Secure software design

Manual and automated source code analysis

Manual and automated pen testing
6.4 Testing Framework
6.5 Suggested Weighting Schemes
6.6 Unaddressed Threats
6.7 V1 to V2 translation table
6.8 Response Table
<Preferably as an attached Excel>