Blog
They wrote blocked. The rule was still Count.
At 03:14 Priya saves rule block-reset-flood on web ACL edge-prod with action Count. At 03:18 POST /reset on pay-login-01 returns 200. The scribe writes that the path was blocked.
At 03:14 on 29 October 2026, Priya S (on-call, platform) saves a rule on regional web ACL edge-prod in us-east-1, account 771903662845. The web ACL is attached to ALB pay-login-01. The rule is named block-reset-flood, priority 8. It matches POST /reset from 203.0.113.50. She sets the action to Count. The flood in the inject started at 03:02: repeated POST /reset from that address against pay-login-01. Marcus T (incident commander) reads the plan. It says: on a confirmed flood of POST /reset against pay-login-01, the matching rule on edge-prod is Block before anyone writes that the path is contained. Count is non-terminating. It records the match and the request continues. Do not write blocked while that rule's action is Count, or while the log's top-level action is Allow. Priya says she wants one sample, then she will switch the action to Block. She does not switch it. She does not open the WAF log. She reads the rule name. Lena V (edge), who owns edge-prod, is not on the call. At 03:18 the WAF log for that web ACL shows block-reset-flood under nonTerminatingMatchingRules with action COUNT. The top-level action is ALLOW. terminatingRuleId is Default_Action. The default action on edge-prod is Allow. The access log for ALB pay-login-01 shows POST /reset from 203.0.113.50 at 03:18 with status 200. At 03:26 the scribe writes that the WAF blocked the reset path and that rule block-reset-flood is deployed.
A weak record of those twelve minutes reads:
WAF blocked the reset path. Rule block-reset-flood is deployed.
A strong one reads:
29 October 2026, 03:14 to 03:26. Incident-response tabletop. Seats: Marcus T (incident commander), Priya S (on-call, platform). Lena V (edge, owns web ACL edge-prod) was not on the call. Inject at 03:14: from 03:02, repeated POST /reset from 203.0.113.50 against ALB pay-login-01. Plan: on a confirmed flood of POST /reset against pay-login-01, the matching rule on regional web ACL edge-prod (us-east-1, account 771903662845) is Block before anyone writes that the path is contained. Count is non-terminating. It records the match and the request continues. Do not write blocked while that rule's action is Count, or while the log's top-level action is Allow. At 03:14 Priya saves rule block-reset-flood, priority 8, matching POST /reset from 203.0.113.50, action Count. She says she wants one sample, then she will switch it to Block. She does not switch it. She does not open the WAF log. At 03:18 the log shows block-reset-flood under nonTerminatingMatchingRules with action COUNT, top-level action ALLOW, terminatingRuleId Default_Action. The default action on edge-prod is Allow. ALB pay-login-01 returns 200 for that POST /reset. At 03:26 the scribe writes that the WAF blocked the reset path. Facilitator stops the sitting before anyone sets the action to Block, before anyone tells support the flood has stopped, and before anyone writes to a customer. Nothing was switched to Block. The 03:18 row is the inject's log. Follow-up: Lena sets block-reset-flood to Block, or writes why Count is the contain step for POST /reset, by 13 November 2026.
Both notes say the path was blocked. Only the second shows that at 03:18 the rule action was Count, the request action was Allow, and pay-login-01 returned 200. The first costs you the reset form. On the night this is real, POST /reset keeps answering 200 after the rule is saved, and a reader in March thinks the flood stopped at 03:14.
Count records the match and lets the request through
Priya is looking at the rule name. block-reset-flood is a label she typed. The action on the rule is Count. In AWS WAF, Count is non-terminating: the match is written under nonTerminatingMatchingRules and evaluation continues. No later rule on edge-prod terminated this request. The default action is Allow, so the log's top-level action is ALLOW and terminatingRuleId is Default_Action. The request reaches pay-login-01. A reader who only sees the rule id in the match list can honestly say the rule matched, and still miss that the action was Count.
A password reset and a session revoke that leave an application permission in place are a different object, in the Mail.Read post. That grant authenticates as the app. This sitting is an edge rule that matched and did not terminate. A second security group that still had the batch host connected is a different miss again, in the isolate post. This rule is the one they named. It did not block.
A 200 you rewrite is not a 200 you leave out
The scribe did not skip the request. She turned it into a block. The rule name did that work. Deployed is true of the Count action, and it is the wrong verb for what the plan asked. The plan already said Block, and it already said not to write blocked while the action is Count.
An S3 GetObject 200 that a scribe leaves out of a sentence saying there was no evidence is a different file, in the object-read post. That 200 is a read the packet omitted. This 200 is an origin response the packet rewrote. Copy the action field. Do not copy the rule name over it.
If the plan's contain step says block at the edge and does not name Count versus Block, run the free plan self-check before the next sitting. It asks whether the last test produced findings with owners, and whether they were closed. Lena's follow-up is that finding. A line that says the path was blocked is a record you can produce, and it is the wrong one.
What the packet records
Write the action in the free evidence template: the plan sentence, the flood from 03:02, rule block-reset-flood saved at 03:14 with action Count, the 03:18 log (nonTerminatingMatchingRules action COUNT, top-level action ALLOW, terminatingRuleId Default_Action), the ALB 200, that nobody changed the action, and that Lena was absent, with the follow-up date. The scenario library has six families: ransomware with exfiltration, business email compromise, cloud credential compromise, data subject rights, an AI incident, and a regional outage. None of them has a minute where a rule named block is saved as Count and the scribe writes that the path was blocked. Add this minute. Do not fold it into a line that says blocked. Put the file in the evidence index on the row for that exercise, with the date and the owner, so the next questionnaire finds the action you did not change. The evidence template sits with the other record formats in the template library.
The record shows that these named people left block-reset-flood on Count and wrote that the path was blocked. It does not show that setting the action to Block would have stopped the next POST /reset, and it does not show that the 03:18 response changed a password. A 200 on that path is not a password change. Those are a request after the action is Block, and the application log for that reset. This file is the action they did not change.
Bottom line: write the rule action and the request action. Blocked is the smoothed version. The packet has to show Count.