Best Practices

This article explains the legacy version of WAF that will undergo end-of-life on June 30, 2021. Our new version of WAF expands upon all of the capabilities offered by WAF and Rate Limiting with a simplified and centralized setup. Please upgrade to the latest version of WAF at your earliest convenience.

Best practices on setting up Web Application Firewall 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 CMS vs. non-CMS traffic Additionally, there may be multiple traffic delivery profiles that are specific to a site, 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 security by request type. This may require the following configuration:

• A profileWeb Application Firewall: Refers to a configuration that defines the set of security restrictions that may be used to screen inbound HTTP/HTTPS traffic. for each custom set of security requirements.
• An instanceWeb Application Firewall: Identifies profiles that may be used to screen production traffic against illegitimate requests. for each profile that should be activated on production traffic.
• A ruleRules Engine: Refers to a set of statements that identify a set of requests and the manner in which those requests will be handled. or a rule statementRules Engine: Refers to the set of conditional expressions & conditions that identify a single type of request. The last conditional expression in a statement should contain a set of actions that will be applied to that request type. for each traffic profile with custom security requirements.

Setup

The recommended approach for setting up WAF is described below.

1. Create a profileWeb Application Firewall: Refers to a configuration that defines the set of security restrictions that may be used to screen inbound HTTP/HTTPS traffic. that is specific to the desired traffic profile.

   1. Set the Anomaly Score Threshold option to a level that balances security with risk tolerance.

      Learn more.

   2. Update the rule set configuration according to these recommendations.
   3. Keep the set of whitelisted access controls to a minimum.
   4. Establish a strict delivery profile.
2. Create an instanceWeb Application Firewall: Identifies profiles that may be used to screen production traffic against illegitimate requests..
   • Set the Production Action option to "alert."
3. Add or modify a ruleRules Engine: Refers to a set of statements that identify a set of requests and the manner in which those requests will be handled..
   1. Define matchRules Engine: Defines a prerequisite that must be met before one or more actions (i.e., features) may be applied to a request. conditions that identify the type of request that will be screened by WAF.
   2. Add a Web Application Firewall action and set it to the instanceWeb Application Firewall: Identifies profiles that may be used to screen production traffic against illegitimate requests. associated with a profile that is best suited for screening the traffic profile defined in step 3.i.
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.
   Perform one of the following:
   • Too Permissive: Close any security loopholes by defining additional restrictions on the corresponding profile’s threat detection policies/rules, access controls, and/or settings.

   • 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 settings defined in the profile's Settings and Access Controls tabs to account for the set of traffic being blocked.
       
   • Balanced: Set the corresponding instance's Production Action option to "block." This will cause WAF to deny requests that violate the profile’s security configuration.

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, user agent, or referrer. 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 customer origin server.