Make it fire

A detection is only useful if it fires on the real thing and stays quiet otherwise. In this episode we create the detections the threat model already wrote, keep them detect-only while we tune, then run a bounded attack against our own lab and watch each rule light up.

The safety promise first

Every new rule starts in test mode: it detects and notifies, but takes no action — no blocks, no rate limits. You arm responses only after a rule proves clean on real traffic. Nothing in this episode can lock anyone out.

Step 1 — The report already wrote the SQL

Open the Detection & Mitigation report from Episode 1. Each threat row carries a ready-to-run detection: a SQL query, a suggested name, a schedule, and a severity. You're not inventing queries — you're copying the ones grounded in your telemetry.

Step 2 — Create a rule

securenow alerts rules create \
  --name "Repeated failed sign-ins per IP" \
  --sql @rules/repeated-failed-logins.sql \
  --apps <APP_KEY> \
  --severity high \
  --schedule "*/5 * * * *" \
  --nlp "one IP with 10+ failed password sign-ins in 15 minutes"

create validates the SQL before it ever runs. New rules are created detect-only.

Step 3 — Validate before you trust it

Dry-run the query against your real stored telemetry:

securenow alerts rules test <RULE_ID> --mode dry_run --wait

To exercise a rule end-to-end without waiting for real attackers, send synthetic events on TEST-NET IPs (203.0.113.x, 198.51.100.x, 192.0.2.x):

securenow event send --type auth.login.failure --ip 203.0.113.10 \
  --attr account_ref=acct_demo --attr reason=bad_password

Step 4 — Run a bounded attack

The lab ships a small attack harness that reproduces each modeled threat against your local copy only (it refuses to run against a deployment):

node attack-simulation/attack.mjs list              # see the scenarios
node attack-simulation/attack.mjs password-guessing # run one

It sends attacker IPs in X-Forwarded-For, exactly as a reverse proxy forwards the real client — so the app's limits, its audit events, and SecureNow's traces all see the simulated address.

Step 5 — Read the evidence

In the dashboard, each detection groups its hits by rule and IP, shows the matching traces, and (where you added the bridge) the pseudonymous account it targeted. You can see the exact sequence — five failures, then a success — that defines a takeover.

Step 6 — Arm a response (only when it's clean)

After a few days of real traffic with zero false alarms, promote a high-precision rule to production and attach a scoped response — a rate limit on /api/auth/login, a challenge, or a block:

securenow alerts rules update <RULE_ID> --mode prod

What you just did

You turned the threat model into live, validated detections, proved them against a real attack, and kept everything safe in test mode. In Episode 4 we stop containing the attacker and start closing the holes — in the code.