Show search and navigation.
Best practices on setting up WAF vary by organization due to a variety of factors, such as those listed below.
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:
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.
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.
The recommended approach for setting up WAF is described below.
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:
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:
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.
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.
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.
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.