Configuration

Set up WAF by defining rules and then creating a Security Application Manager configuration that enforces them. After which, perform near-real-time threat monitoring through the dashboard.

Additional information on each of the above steps is provided below.

#	Task	Description
1	Create Rules	Create modular rules (i.e., Access Rules, Rate Rules, Bot Rules, Custom Rules, and Managed Rules) through which you may define security policies for inbound HTTP/HTTPS traffic. These rules identify legitimate traffic or threats via: Access controls (e.g., IP address, country, URL, etc.). Rate limits. Browser challenges. Custom threat detection rules. The Custom rules capability requires WAF Premier or WAF Standard. If you currently have WAF Essentials or WAF Insights and would like to use custom rules, please contact your CDN account manager to upgrade to the full version. Threat detection policies.
2	Create a Security Application Manager Configuration	Create a Security Application Manager configuration that identifies the type of traffic to which your rules will be applied and how threats will be handled. You may also use it to test new rules via an audit mode that generates alerts on flagged traffic.
3	Monitor Threats	Use the dashboard to: Visualize threat frequency and timing. Analyze threats and ensure that legitimate traffic is not impacted.

Different applications and types of requests may require varying levels of protection. Create rules and Security Application Manager configurations for each use case that requires a unique level of protection.

Threat Detection

A Security Application Manager configuration contains rules that define the criteria that determine whether traffic is legitimate or a threat. WAF leverages this security configuration and performs a sequential check for each criterion. An overview of this security check is provided below.

1. Does the request meet a whitelist criterionA whitelist identifies traffic that should always be considered safe. Traffic may be whitelisted by ASN, country, IP address, referrer, URL, user agent, HTTP method, media type, and/or file extension.? If so, it is considered legitimate and no further checks will be performed.

2. Proceed to the next step if the access rule does not contain at least one acceslist.

   Does the request satisfy at least one criterion in each defined accesslistAn accesslist identifies traffic that may access your content upon passing a threat assessment. Traffic may be accesslisted by ASN, country, IP address, referrer, URL, user agent, HTTP method, media type, and/or file extension.? If not, then the request is identified as a threat and no further checks will be performed.

3. Does the request meet a blacklist criterionA blacklist identifies traffic that should always be considered malicious. Traffic may be blacklisted by ASN, country, IP address, referrer, URL, user agent, HTTP method, media type, and/or file extension.? If so, it is identified as a threat and no further checks will be performed.
4. Has the rate limit been exceeded? If so, then the request is identified as a threat and no further checks will be performed.
5. Was the client able to solve a browser challenge? If not, then the request is identified as a threat and no further checks will be performed.
6. The request will undergo threat detection analysis according to the Security Application Manager configuration's custom rule. Was a rule in the custom rule set satisfied? If so, then the request is identified as a threat and no further checks will be performed.
7. Will the request be served from cache instead of being forwarded to an origin server? If so, it is considered legitimate and no further checks will be performed.
8. The request will undergo threat detection analysis according to the Security Application Manager configuration's managed rule. A request will be classified as a threat when the severity and frequency of rule violations exceeds the configured threshold.

The above threat detection workflow is illustrated below.

Managed Rule Violations

If an access rule, rate rule, or custom rule cannot identify whether a request is legitimate or a threat, then it is up to the Security Application Manager configuration's managed rule to make that determination. The request will be evaluated according to a managed rule's enabled rules and its definition of a valid HTTP request. A request will not be considered a threat until a threshold of violations is met. The score assigned to a request is determined according to the severity and frequency of the violations.

• Severity: Each rule is assigned a severity. Each severity is assigned an anomaly score from 2 to 5.

  Severity	Anomaly Score	Description
  Critical	5	This severity level is triggered by web attack violations.
  Error	4	This severity level is reserved for future use.
  Warning	3	This severity level is triggered by malicious client violations.
  Notice	2	This severity level is generally used to indicate protocol policy violations.

• Frequency: A threat is identified when the aggregate score for all violations meets or exceeds the configured threshold value. This allows WAF to account for minor violations without forcing it to take action for a single offense.

A managed rule may be assigned a threshold value from 2 to 20. However, the recommended value is 5. A threshold value of 5 triggers threat identification after a single severe violation or multiple minor violations. This balanced approach identifies questionable requests without impacting legitimate traffic.

More Information

• Access Rules
• Rate Rules
• Bot Rules
• Custom Rules
• Managed Rules
• Security Application Manager
• Best Practices