DET-AUTH-002 — session creation velocity

Rule ID: DET-AUTH-002 Title: Session-create rate per IP per minute exceeding 3σ above 7-day baseline Category: auth Last validated: 2026-06-04 (initial catalog, dormant) State: dormant — requires session-create event log to be queryable

Telemetry source

• Session-create event emitted at /api/auth/login/verify (POST) on successful WebAuthn assertion verification → row insert into the customer-session store.
• App log lines from backend_v2/api/routes/auth.py login_verify path; expected destination is the same archived log drain as DET-AUTH-001.
• Eventually: a customer_sessions write event in customer_audit_events should make this query Postgres-direct. Pre-launch, log-drain query is the source.

Statistical method + baseline window

• Method: Poisson tail test on sessions-created-per-IP-per-minute vs. rolling 7-day baseline mean for the same time-of-day bucket.
• Baseline window: 7 days, hourly time-of-day buckets.
• Fire condition: observed sessions per IP per minute > μ + 3σ of the baseline distribution, AND observed count >= 3.

Threshold + expected FP rate

• Pre-launch placeholder: >= 5 sessions per IP per minute. No baseline yet; this is the floor.
• Post-launch: dynamic 3σ on time-of-day-bucketed Poisson baseline.
• Expected FP rate (post-launch): ~2 per week, dominated by users on shared corp/coffee-shop NAT.

Alert route

• HIGH (post-baseline fire): ops@ daily digest unless the same IP fires the rule twice in 24h → escalate to #raxx-ops-alert-sev2-5 (ET hours) / #raxx-ops-alert-sev2 (off-hours).
• MEDIUM (single sub-threshold trend): silent log to docs/detections/_log/.

Escalation owner

• security-agent for repeat fires (stolen session cookie replay, credential-stuffing post-success).
• sre-agent if the fire correlates with a deploy event (likely a session-create loop bug, not adversarial).

Test fixture / synthetic positive

See _fixtures/session_creation_velocity_positive.json for a synthetic 8-session burst from one IP within 47 seconds.

What to do when this fires

1. Pull the IP's session list for the prior 24h. Distinct user-IDs? Same user-ID? Same user-ID + N sessions = likely cookie-replay; distinct user-IDs from one IP = credential-stuffing post-success or NAT.
2. Check customer_audit_events for the user-IDs in question — recent password reset, RBAC change, IP-geo mismatch?
3. If the same user-ID appears across N>5 sessions from the IP within 5 min, force-revoke all sessions for that user-ID and notify the user via email (only after launch; pre-launch this means operator's own account).
4. Hand the IP + session-ID set to security-agent for incident review.

What NOT to do

• Do not invalidate sessions broadly from this detection. The action belongs to security-agent or operator.
• Do not extend baseline window beyond 7 days — long baselines dilute today's regime shift signal.
• Do not include the operator's own dev sessions in the baseline. Exclude operator's user-ID via configuration.