Qualys WAF is architected for easy and flexible deployment and management. You can completely manage the WAF security configuration and monitor security events through our cloud-based Qualys Suite portal. Your website traffic never leaves your environment, because the traffic inspection and attack mitigation is managed by our virtual appliances that can be deployed alongside your web applications. These virtual appliances are horizontally scalable, require no special hardware and can be deployed using VMware vCenter, Microsoft Hyper-V or AWS AMI. VMWare and Hyper-V images of the virtual appliances are available for download in the Qualys Suite portal and the AWS AMI is available in the AWS Marketplace. Our Getting Started Guide will walk you through the various technicals aspects of the WAF deployment and configuration.
Proper planning, as with anything, is the key to simple deployment of the Qualys WAF service. To that end, below is a rough outlined plan that will help highlight the important portions of a deployment, and hopefully will allow you to better understand the complexity and customer requirements.
As with any security project, proper upfront information gathering is crucial. For WAF, that means not only gathering technical details, but also making some general architectural and policy decisions that will help guide this and future deployments with each customer.
First, we'll need to decide which applications to deploy WAF to. Once we've identified the applications, we'll need to gather some technical detail about the applications, to ensure that we have everything we need up front - mise en place, if you will.
- URL of the application we'd like to protect
- load balancer details for this application (which LBs, how they share load, and configuration if it's readily available)
- SSL/TLS certificates if the website serves HTTPS traffic
- IP addresses or FQDNs of the backend web servers that serve traffic for your website
- logical flow diagram for the application
- business purpose for the site (this will help drive creation of policy and assist us in determining how to treat SSL)
- understanding of the application, and which components are dynamic versus static
These details should be understood up front, in a consulting-style kickoff meeting if necessary. From there, for each application we need to make some architectural and policy decisions:
- does the application *require* end-to-end encryption? If it does not, it is much more efficient to offload SSL services to the load balancer and to pass to the WAF in the clear.
- are there Source IP ranges or source countries we would like to treat differently? (Not only black/white list, but threat influence can also be modified based on these criteria)
- will we be blocking traffic for this application?
Now, based on the purpose of the application and the policy decisions above, we should be able to come up with general criteria for creation of a security posture for the application, which will drive policy creation in the Qualys Portal.
WAF Deployment Design
Based on the architecture, we'll need to determine how many appliances need be deployed. This will depend on the number of applications being protected and the need for fault tolerance within each application deployed.
After we've determined that number, we'll need to come up with a structure for WAF Clusters (by data center or location, by application, etc.) which will help us when we configure the Portal and deploy. We also need to determine if the appliances have direct access to Qualys (rns.qualys.com or rns.qualys.eu) via HTTPs, or if they need to be proxied.
Initial Implementation (no impact to Production)
In this phase we'll allocate virtual machine resources for our appliances, deploy the appliances, and connect them to the Qualys Portal. We'll also create WAF clusters, applications, and build security policies. Once complete, we will be able to determine that connectivity to all components is configured and working properly without yet touching the Production application.
Test Implementation (no impact to Production)
Now that our WAF footprint is deployed, we'll start running some test traffic through it. The easiest way to do this is by creating a DNS name for testing (www-test, for example, to test www.) We'll then add this new DNS name to the application configuration in the Portal, and create an appropriate load balancer configuration for the new DNS name, as if it were a production application. We can then begin sending live traffic on this "dummy" DNS name through WAF to the production application. In this way, we can test the production application without actually having any impact on the app itself (as only traffic destined to our dummy DNS name will be proxied by WAF).
Here, we'll take what we've learned from the test deployment phase and use that knowledge in production. We'll need to simply modify the production load balancer configuration to start routing traffic to WAF, and then test thoroughly.
Tuning (no additional production impact)
Once WAF is deployed, we'll need to work on tuning. We need to evaluate security events, understand their impact and threat on the environment, and make appropriate and necessary changes to the WAF security policies.
When we're comfortable that WAF is operating properly, we should clean up after our testing - remove the load balancer and DNS configurations for the test URL.
Configure Blocking, if required
At this point we're comfortable that we've got solid security policies in place, and we can simply enable Blocking mode on the application. Again, as always, we'll want to test thoroughly to ensure we're seeing expected behaviour.
This document was generated from the following discussion: WAF Deployment Overview