[WAF] ELI5 updates part 2

src/content/docs/waf/account/index.mdx

@@ -11,9 +11,9 @@ sidebar:
 This feature requires an Enterprise plan.
 :::
 
-The account-level Web Application Firewall (WAF) configuration allows you to define a configuration once and apply it to multiple Enterprise zones in your account.
+The account-level Web Application Firewall (WAF) configuration allows you to define a configuration once and apply it to multiple Enterprise zones in your account. Instead of configuring each zone individually, you create rulesets at the account level and use expressions to control which zones and traffic they apply to.
 
-Configure and deploy custom rulesets, rate limiting rulesets, and managed rulesets to multiple Enterprise zones, affecting all incoming traffic or only a subset (for example, all traffic to `/admin/*` URI paths in both `example.com` and `example.net`).
+For example, you can deploy a single ruleset that applies to `/admin/*` URI paths across both `example.com` and `example.net`. Rulesets can target all incoming traffic or a specific subset.
 
 At the account level, WAF rules are grouped into rulesets. You can perform the following operations:
 

src/content/docs/waf/account/managed-rulesets/index.mdx

@@ -15,13 +15,13 @@ This feature requires an Enterprise plan.
 
 ## Account-level deployment
 
-At the account level, you can deploy each [WAF managed ruleset](/waf/managed-rules/#available-managed-rulesets) more than once. This means that you can apply the same managed ruleset with different configurations to different subsets of incoming traffic for the Enterprise zones in your account.
+At the zone level, each [WAF managed ruleset](/waf/managed-rules/#available-managed-rulesets) can only be deployed once. At the account level, you can deploy each managed ruleset more than once. This allows you to apply the same ruleset with different configurations to different subsets of incoming traffic across the Enterprise zones in your account.
 
-For example, you could deploy the [Cloudflare OWASP Core Ruleset](/waf/managed-rules/reference/owasp-core-ruleset/) multiple times with different paranoia levels and a different action (_Managed Challenge_ action for PL3 and _Log_ action for PL4).
+For example, you could deploy the [Cloudflare OWASP Core Ruleset](/waf/managed-rules/reference/owasp-core-ruleset/) multiple times with different [paranoia levels](/waf/managed-rules/reference/owasp-core-ruleset/concepts/#paranoia-level) and a different action (_Managed Challenge_ action for PL3 and _Log_ action for PL4). Higher paranoia levels enable additional rules that are more likely to produce false positives.
 
 <Details header="Example: Deploy OWASP with two different configurations">
 
-The following example deploys the [Cloudflare OWASP Core Ruleset](/waf/managed-rules/reference/owasp-core-ruleset/) multiple times at the account level through the following execute rules:
+The following example deploys the [Cloudflare OWASP Core Ruleset](/waf/managed-rules/reference/owasp-core-ruleset/) multiple times at the account level through the following [execute rules](/ruleset-engine/managed-rulesets/deploy-managed-ruleset/):
 
 - First execute rule: Enable OWASP rules up to paranoia level 3 (PL3) and set the action to _Managed Challenge_.
 - Second execute rule: Enable OWASP rules up to PL4 and set the action to _Log_.
@@ -48,7 +48,7 @@ Once you finish your configuration, the **Deployed managed rulesets** list will
 
 </TabItem> <TabItem label="API">
 
-The following `POST` request for the [Create an account ruleset](/api/resources/rulesets/methods/create/) operation creates an [entry point ruleset](/ruleset-engine/about/rulesets/#entry-point-ruleset) for the `http_request_firewall_managed` phase at the account level. The ruleset includes two rules deploying the Cloudflare OWASP Core Ruleset twice with different configurations.
+The following `POST` request for the [Create an account ruleset](/api/resources/rulesets/methods/create/) operation creates an [entry point ruleset](/ruleset-engine/about/rulesets/#entry-point-ruleset) for the `http_request_firewall_managed` [phase](/ruleset-engine/about/phases/) at the account level. The ruleset includes two rules deploying the Cloudflare OWASP Core Ruleset twice with different configurations.
 
 <APIRequest
 	path="/accounts/{account_id}/rulesets"

src/content/docs/waf/account/rate-limiting-rulesets/index.mdx

@@ -7,13 +7,18 @@ sidebar:
 
 import { GlossaryTooltip } from "~/components";
 
-A rate limiting rule defines a <GlossaryTooltip term="rate limiting">rate limit</GlossaryTooltip> for requests matching an expression, and the action to perform when that rate limit is reached. At the account level, rate limiting rules are always grouped into rate limiting rulesets, which you then deploy.
+[Rate limiting rules](/waf/rate-limiting-rules/) allow you to define a <GlossaryTooltip term="rate limiting">rate limit</GlossaryTooltip> for requests matching an [expression](/ruleset-engine/rules-language/expressions/), and the action to perform when that rate limit is reached. You can configure rate limiting rules for a single zone or at the account level.
+
+Account-level rate limiting rulesets allow you to define rate limiting rules once and deploy them to multiple Enterprise zones. Instead of configuring the same rules in each zone, you create a ruleset at the account level and control which zones it applies to.
 
 :::note
 This feature requires an Enterprise plan.
 :::
 
-To apply a rate limiting ruleset at the account level, create a custom rate limiting ruleset with one or more [rate limiting rules](/waf/rate-limiting-rules/), and then deploy it to one or more zones on an Enterprise plan.
+To apply a rate limiting ruleset at the account level:
+
+1. Create a rate limiting ruleset with one or more rate limiting rules.
+2. Deploy the ruleset to one or more zones on an Enterprise plan.
 
 For more information on how Cloudflare calculates request rates, refer to [Request rate calculation](/waf/rate-limiting-rules/request-rate/).
 

src/content/docs/waf/analytics/security-analytics.mdx

@@ -14,20 +14,20 @@ import {
 	Render,
 } from "~/components";
 
-Security Analytics displays information about all incoming HTTP requests for your domain, including requests not handled by Cloudflare security products.
+Security Analytics displays information about all incoming HTTP requests for your domain, including requests not handled by Cloudflare security products. This gives you visibility into your full traffic profile, not only the requests that triggered a security rule.
 
-By default, Security Analytics queries filter on `requestSource = 'eyeball'`, which represents requests from end users. Note that requests from Cloudflare Workers (subrequests) are not visible in Security Analytics.
+By default, Security Analytics shows requests from end users (requests to your site directly, as opposed to requests generated by Cloudflare products). Requests generated by [Cloudflare Workers](/workers/) subrequests are not included.
 
 Use the Security Analytics dashboard to:
 
 - View the traffic distribution for your domain.
-- Understand which traffic is being mitigated by Cloudflare security products, and where non-mitigated traffic is being served from (Cloudflare global network or [origin server](https://www.cloudflare.com/learning/cdn/glossary/origin-server/)).
+- Understand which traffic is being <GlossaryTooltip term="mitigated request">mitigated</GlossaryTooltip> by Cloudflare security products, and where non-mitigated traffic is being served from (Cloudflare global network or [origin server](https://www.cloudflare.com/learning/cdn/glossary/origin-server/)).
 - Analyze suspicious traffic and create tailored WAF custom rules based on applied filters.
-- Learn more about Cloudflare's security scores (<GlossaryTooltip term="attack score" link="/waf/detections/attack-score/">attack score</GlossaryTooltip>, [bot score](/bots/concepts/bot-score/), [malicious uploads](/waf/detections/malicious-uploads/), and [leaked credentials](/waf/detections/leaked-credentials/) results) with real data.
+- Review Cloudflare's security scores (<GlossaryTooltip term="attack score" link="/waf/detections/attack-score/">attack score</GlossaryTooltip>, [bot score](/bots/concepts/bot-score/), [malicious uploads](/waf/detections/malicious-uploads/), and [leaked credentials](/waf/detections/leaked-credentials/) results) with real data from your traffic.
 - [Find an appropriate rate limit](/waf/rate-limiting-rules/find-rate-limit/) for incoming traffic.
 - Analyze suspicious traffic ([new security dashboard](/security/) only).
 
-If you need to modify existing security-related rules you already configured, consider also checking [Security Events](/waf/analytics/security-events/). This dashboard displays information about requests affected by Cloudflare security products.
+Security Analytics shows all traffic, whether or not Cloudflare acted on it. If you are looking for requests that Cloudflare security products acted on or flagged, refer to [Security Events](/waf/analytics/security-events/) instead.
 
 ## Availability
 
@@ -113,7 +113,7 @@ Each suspicious activity is classified with a severity score that can vary from
 The main chart displays the following data for the selected time frame, according to the selected tab:
 
 - **Traffic analysis**: Traffic mitigated by the Cloudflare security platform, served by Cloudflare, and served by the origin server, according to the following classification:
-  - **Mitigated by WAF**: Requests blocked or challenged by Cloudflare's application security products such as the WAF and HTTP DDoS protection. It does not include requests that had the following actions applied: _Log_, _Skip_, and _Allow_.
+  - **Mitigated by WAF**: Requests blocked or [challenged](/cloudflare-challenges/challenge-types/challenge-pages/#actions) by Cloudflare's application security products such as the WAF and HTTP DDoS protection. Requests with _Log_, _Skip_, or _Allow_ [actions](/ruleset-engine/rules-language/actions/) are not counted as mitigated.
   - **Served by Cloudflare**: Requests served by the Cloudflare global network such as cached content and redirects.
   - **Served by origin**: Requests served by your origin server.
 
@@ -155,7 +155,12 @@ To apply the filters for an insight to the data displayed in the Security Analyt
 Only available in the previous dashboard navigation structure.
 :::
 
-The **Attack analysis**, **Bot analysis**, **Malicious uploads**, and **Account abuse detection** sections display statistics related to WAF attack scores, bot scores, WAF content scanning scores, and leaked credentials scanning of incoming requests for the selected time frame. All plans include access to the **Leaked credential check** under **Account abuse detection**. This feature detects login attempts using credentials that have been exposed online. For more information on what to do if you have credentials that have been leaked, refer to [Example mitigation rules](/waf/detections/leaked-credentials/examples/).
+The **Attack analysis**, **Bot analysis**, **Malicious uploads**, and **Account abuse detection** sections display statistics related to Cloudflare's security scores for incoming requests in the selected time frame:
+
+- **Attack analysis**: Uses [WAF attack scores](/waf/detections/attack-score/) to classify requests based on the likelihood that the request is malicious.
+- **Bot analysis**: Uses [bot scores](/bots/concepts/bot-score/) to classify requests based on the likelihood they come from automated traffic.
+- **Malicious uploads**: Uses [WAF content scanning](/waf/detections/malicious-uploads/) scores to detect potentially malicious content uploaded in requests.
+- **Account abuse detection**: Uses [leaked credentials detection](/waf/detections/leaked-credentials/) to identify login attempts with credentials that have been exposed in data breaches. All plans include access to the **Leaked credential check** under this section. For more information on what to do if you have leaked credentials, refer to [Example mitigation rules](/waf/detections/leaked-credentials/examples/).
 
 You can examine different traffic segments according to the current metric (attack score, bot score, or content scanning). To apply score filters for different segments, select the buttons below the traffic chart. For example, select **Likely attack** under **Attack analysis** to filter requests that are likely an attack (requests with WAF attack score values between 21 and 50).
 
@@ -165,7 +170,7 @@ Additionally, you can use the slider tool below the chart to filter incoming req
 
 Security Analytics shows request logs for the selected time frame and applied filters, along with detailed information and security analyses of those requests.
 
-By default, Security Analytics uses sampled logs for the logs table. If you are subscribed to [Log Explorer](/log-explorer/), you may also have access to [raw logs](#raw-logs).
+By default, Security Analytics uses sampled logs (a subset of your traffic rather than every individual request). Sampling allows Cloudflare to return results in seconds, even when query volumes are large. If you are subscribed to [Log Explorer](/log-explorer/), you may also have access to [raw logs](#raw-logs).
 
 #### Sampled logs
 
@@ -208,4 +213,4 @@ Currently, changing the time frame or the applied filters while showing raw logs
 
 ## Sampling
 
-The Security Analytics dashboard uses [sampled data](/analytics/graphql-api/sampling/), except when showing raw logs. Most information in the dashboard is obtained from `httpRequestsAdaptiveGroups` and `httpRequestsAdaptive` GraphQL nodes. For more information on working directly with GraphQL datasets, refer to [Datasets (tables)](/analytics/graphql-api/features/data-sets/).
+The Security Analytics dashboard uses [sampled data](/analytics/graphql-api/sampling/), except when showing raw logs. If you query Security Analytics data through the [GraphQL Analytics API](/analytics/graphql-api/), the primary underlying datasets are `httpRequestsAdaptiveGroups` and `httpRequestsAdaptive`. For more information, refer to [Datasets (tables)](/analytics/graphql-api/features/data-sets/).

src/content/docs/waf/analytics/security-events.mdx

@@ -14,7 +14,9 @@ import {
 	DashButton,
 } from "~/components";
 
-Security Events allows you to review <GlossaryTooltip term="mitigated request">mitigated requests</GlossaryTooltip> and helps you tailor your security configurations.
+Security Events allows you to review <GlossaryTooltip term="mitigated request">mitigated requests</GlossaryTooltip> and helps you tailor your security configurations. Use Security Events to investigate requests that Cloudflare security products acted on or flagged, identify false positives, and fine-tune your security rules.
+
+If you want to analyze all incoming traffic, including requests that Cloudflare did not act on, refer to [Security Analytics](/waf/analytics/security-analytics/) instead.
 
 The main elements of the dashboard are the following:
 
@@ -23,7 +25,7 @@ The main elements of the dashboard are the following:
 - [Top events by source](#top-events-by-source): Provides details of the traffic flagged or actioned by a Cloudflare security feature (for example, IP addresses, User Agents, Paths, Countries, Hosts, ASNs).
 - [Sampled logs](#sampled-logs): Summarizes security events by date to show the action taken and the applied Cloudflare security product.
 
-Security Events displays information about requests actioned or flagged by Cloudflare security products, including features such as [Browser Integrity Check](/waf/tools/browser-integrity-check/). Each incoming HTTP request might generate one or more security events. The Security Events dashboard only shows these events, not the HTTP requests themselves.
+Security Events displays information about requests actioned or flagged by Cloudflare security products, including features such as [Browser Integrity Check](/waf/tools/browser-integrity-check/). A single HTTP request can generate one or more security events when it triggers security features. The Security Events dashboard shows these individual events, not the HTTP requests themselves.
 
 ## Availability
 
@@ -68,7 +70,7 @@ To manually add a filter:
 <Steps>
 
 1. Select **Add filter**.
-2. Select a field, an operator, and a value. For example, to filter events by IP address, select _IP_ for **Action**, select _equals_ for the operator, and enter the IP address.
+2. Select a field, an operator, and a value. For example, to filter events by IP address, select _IP_ for the field, select _equals_ for the operator, and enter the IP address.
 3. Select **Apply**.
 
 </Steps>
@@ -118,7 +120,7 @@ A deleted custom rule or rate limiting rule will show as `Rule unavailable` unde
 
 ## Sampled logs
 
-**Sampled logs** summarizes security events by date to show the action taken and the applied Cloudflare security feature.
+**Sampled logs** shows a subset of security events for the selected time period, listed by date with the action taken and the applied Cloudflare security feature. For large volumes of traffic, Cloudflare uses [sampling](/analytics/graphql-api/sampling/) to return results faster. This means that not every individual event may appear in the list.
 
 ![Example list of events in Sampled logs, with one of the events expanded to show its details](~/assets/images/waf/events-sampled-logs.png)
 
@@ -174,8 +176,8 @@ The generated report will reflect all applied filters.
 
 Security Events currently has these limitations:
 
-- Security Events may use sampled data to improve performance. If your search uses sampled data, Security Events might not display all events and filters might not return the expected results. To display more events, select a smaller time frame.
+- Security Events may use sampled data to improve performance. If your search uses sampled data, Security Events might not display all events and filters might not return the expected results. To display more events, select a smaller time frame (a narrower time range reduces the volume of data, which reduces or eliminates sampling).
 
 - The Cloudflare dashboard may show an inaccurate number of events per page. Data queries are highly optimized, but this means that pagination may not always work because the source data may have been sampled. The GraphQL Analytics API does not have this pagination issue.
 
-- Triggered OWASP rules appear in the Security Events page under **Additional logs**, but they are not included in exported JSON files.
+- Triggered [OWASP rules](/waf/managed-rules/reference/owasp-core-ruleset/) appear in the Security Events page under **Additional logs**, but they are not included in exported JSON files.