Best Practices

Best practices on setting up WAF vary by organization due to a variety of factors, such as those listed below.

Factor	Description
Web Applications	The type of web applications running on the origin server may affect the level of protection that may be applied via WAF.
Traffic Delivery Profile	The level of security that should be applied to site traffic may vary for a variety of reasons, such as: Public vs. private content that requires authentication Type of application (e.g., CMS vs. non-CMS traffic) Additionally, there may be multiple traffic delivery profiles that are specific to an application, role, or the action being performed. View sample scenario. Both country and referrer access controls may potentially be applied to a site that requires authentication and only caters to customers in the United States. However, this configuration would be too restrictive for a site that has worldwide users from various traffic sources.
Acceptable Risk	WAF allows the flexibility to determine the degree to which a site will be protected. A balance must be found between security and allowing the flow of legitimate traffic. A major factor in this balancing act is the degree to which an organization is able to cope with risk.

As a result of the above factors, it may make sense to tailor WAF by request type. This may require a Security Application Manager configuration and rules for each custom set of security requirements.

Setup

The recommended approach for setting up WAF is described below.

1. Create an access rule with a minimal set of whitelisted access controls.
2. Create a managed rule according to these recommendations.
3. Create a Security Application Manager configuration that only screens traffic for your application. Add the above managed rule and access rule. Set their production action to Alert only.
4. Repeat steps 1 - 3 as needed.

5. After an acceptable period of time has passed (e.g., 24 to 48 hours), review the alerts logged in the dashboard. Assess whether the defined policies are too permissive, result in too many false positives, or strike a balance between the two.
   

   Use the following tips to adjust your configuration:

   • Too Permissive: Close any security loopholes by defining additional restrictions within your access rule(s) and managed rule(s).

   • False Positives: If the dashboard indicates that legitimate traffic is being flagged, then filter for the alert in question, switch to Event Log, expand the alert, and then take a look at the Rule Tags field to determine whether a rule, access control, or a setting was violated. Take the following action:

     • Rules: The recommended approach is to avoid disabling policies and rules whenever possible. Assess the rule that was violated and consider whether the web application should be updated to conform to that rule. If careful analysis indicates that the security profile must be changed, then disable the rule in question.
       

       A rule may be identified through the Rule Tags and Rule ID fields. The Rule Tags field identifies a policy, while the Rule ID field provides the identification number for the rule that triggered the alert.

       Each policy contains a search feature that finds all rules within that policy whose name contains the specified term or that are an exact match for the specified ID.

     • Delivery Profile: Consider modifying the delivery profile defined within your access rule to account for the set of traffic being blocked.
       
   • Balanced: Update the Security Application Manager configuration's production action for the access rule and managed rule to Block request. This will cause WAF to deny requests that are identified as threats.

Threat Detection/Rule Set

The recommended approach to setting up a profile's rule set is to:

• Set the detection threshold to a level that balances security with risk tolerance. The appropriate value for this threshold will vary according to the set of enabled policies/rules and your traffic profile.

  The detection threshold fine tunes threat detection to balance security requirements with risk tolerance. For example, this detection threshold may need to be increased if a significant number of false positives are detected upon activating an instance associated with this profile.

• Enable as many relevant policies and rules as possible.
• Disable all policies and rules that are inapplicable. This step is crucial for performance.

One way to deal with false positive alerts is to check to see whether the corresponding web application or the site’s source code may be modified to bring it into compliance with the offending rule.

Access Controls

Traffic may be whitelisted by URL, country, IP address, etc. Use this type of setup sparingly to always allow traffic from a legitimate source.

Whitelisting traffic should only be performed after careful consideration and with extreme caution. Whitelisted traffic will not be screened and therefore creates a launching point for a potential attack on your applications and web servers.

Edgecast CDN