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. Deployment Model 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
[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? Authentication Scheme Considerations A. 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 card or for high availability Yes, but can be fitted with a 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).