DET-AUTH-003 — RBAC denied burst

Rule ID: DET-AUTH-003 Title: Cluster of RBAC permission-denied events from one operator account in a short window Category: auth Last validated: 2026-06-04 (initial catalog) State: live — RBAC denial events log today via console/app/blueprints/rbac_reader.py:255 (category="rbac.permission_denied") and console/app/middleware/rbac.py:436

Telemetry source

• console/app/middleware/rbac.py — emits JSON log line including error="permission_denied", admin identity, requested permission, route.
• console/app/blueprints/rbac_reader.py — emits structured event category="rbac.permission_denied" with admin/permission/reason.
• Eventually: console_audit_events should mirror these events with operator-id + permission-key + route fields (gap; see prerequisites).
• Current source: console app logs via Heroku Logplex; same Logplex-drain prerequisite as DET-AUTH-001 for archival queries. Real-time tail viable today.

Statistical method + baseline window

• Method: event-cluster detection — N denials from one operator account within window W where N exceeds historical operator baseline.
• Baseline window: rolling 30 days per operator (RBAC denials are sparse → longer baseline).
• Fire condition: >= 5 distinct-permission denials from one operator account within 10 minutes, OR >= 3 denials targeting "elevated" permissions (any *:admin or *:write scope) within 10 minutes.

Threshold + expected FP rate

• Threshold: 5 denials / 10 min (any permission); 3 denials / 10 min (elevated permissions).
• Expected FP rate: ~1 per quarter pre-launch. Operator-driven RBAC exploration produces small bursts; tune-up if more than 1 FP per month post-launch.

Alert route

• HIGH (elevated-permission burst, 3+ in 10 min): #raxx-ops-alert-sev2-5 (ET hours) / #raxx-ops-alert-sev2 (off-hours). Per-event because compromised-operator-account is one of the worst-case pre-launch incidents (operator is sole admin).
• MEDIUM (any-permission burst, 5+ in 10 min): ops@ daily digest.

Escalation owner

• security-agent — possible compromised operator session, possible mid-attack lateral probe.
• operator if the operator recognizes the session as their own (recent role-narrowing accident).

Test fixture / synthetic positive

See _fixtures/rbac_denied_burst_positive.json for a synthetic 6-denial burst from one operator across 6 distinct admin permissions within 8 minutes.

What to do when this fires

1. Identify the operator account in the cluster. If it's the sole operator's account, immediately verify with operator out-of-band (do they recognize the session?).
2. Check the source IP + user-agent for the denied requests against the operator's known login pattern.
3. If unrecognized: force-revoke all operator sessions, rotate operator's hardware key (per the FIDO2 enrollment posture from feedback_signup_never_blocks), and treat as SEV1.
4. If recognized (operator was exploring): close as confirmed-FP, tag the fire in docs/detections/_log/ for baseline tuning, and leave the rule live.

What NOT to do

• Do not auto-revoke sessions from this rule alone. Confirm out-of-band first.
• Do not silence the rule because the sole operator triggered it during exploration. Tune the baseline; do not gut the rule.
• Do not exclude any operator from this rule. Even the operator account is monitored (especially the operator account — they're the sole admin).