security-logging-alerting-architect

name

security-logging-alerting-architect

description

Design the security-event detection and alerting layer — DETECTION coverage (what must be logged: authn failures/anomalies, access-control denials, privilege/config changes, injection/abuse signals, sensitive-data access), ALERTING rules (alert vs ticket, thresholds justified against baselines, correlation, noise control), and response WIRING (every alert has an owner, severity, escalation, runbook link). Closes OWASP Top 10:2025 A09 (Security Logging and Alerting Failures). Use when designing security monitoring/detection/alerting or asking "would we notice this attack?". Do NOT use for the audit RECORD (audit-log-architect — records, never detects/alerts), system/perf telemetry or alert-config edits (observability-operator), reliability SLOs/paging (slo-reliability-architect), or the playbook AFTER an alert (incident-response-runbook — this designs what fires it).

Security Logging & Alerting Architect

Purpose

Produce the design that makes attacks visible and actionable: a security-event DETECTION coverage map (which events must be logged, with the fields that make them detectable), ALERTING rules per event class (what fires an alert vs a ticket, thresholds justified against observed baselines, correlation and noise control so real attacks are not buried), and response WIRING (every alert routes to a named owner with severity, escalation path, and runbook link). This closes OWASP Top 10:2025 A09 — Security Logging and Alerting Failures: the failure class where a breach succeeds not because nothing was logged, but because nothing DETECTED it, nothing ALERTED, or nobody was wired to respond. Design-only and model-invocable: this skill edits no code and no live alert configuration — implementation is handed to the operating skills.

Use When

• Use when: designing or overhauling security monitoring — "what security events should we log, detect, and alert on?"
• Use when: asking "would we notice this attack?" — auditing existing security logging/alerting coverage against likely attacker behavior.
• Use when: security alerts exist but are ignored noise — redesigning thresholds, correlation, and alert-vs-ticket classification without silently losing detection coverage.
• Use when: an incident review found the attack was visible in logs but no alert fired — or the alert fired and no one owned it.
• Use when: compliance or a customer contract requires demonstrable security MONITORING (detection and alerting), beyond an audit record.
• Do NOT use when: designing the tenant-scoped audit RECORD — taxonomy, schema, integrity, retention — that is audit-log-architect; it records events but does not detect threats or alert. This skill designs detection and alerting ON TOP of those records, and feeds logging gaps back to it.
• Do NOT use when: instrumenting system/performance telemetry or EDITING live alert/dashboard config — observability-operator (manual-only) implements this skill's alerting design in the monitoring stack.
• Do NOT use when: defining reliability SLOs/SLIs, error budgets, or what pages for reliability — slo-reliability-architect; security alerting fires on attacker behavior, not on error-budget burn.
• Do NOT use when: writing what responders DO once paged — incident-response-runbook authors the reactive playbook; this skill designs the detection and alerting that FIRES it, and every alert in the design links to such a runbook.

Inputs to Inspect

1. The threat model (threat-modeler / ai-threat-modeler output): each enumerated threat is a detection requirement — the design must answer "would we see this?" per threat, or record the blind spot.
2. The audit-log design (audit-log-architect output) and current logging reality: which security-relevant events are already recorded, with what fields — detection consumes these records; missing events or fields are logging gaps this skill feeds back as requirements.
3. The authorization matrix and tenant model: access denials, privilege/role changes, and cross-tenant attempts are first-class detection events, and tenant context is a mandatory field on every security event.
4. The current alert inventory and its noise level: what already fires, alerts/day, acknowledgment and action rates — thresholds set without this baseline are guesses and must be labeled as such with a tuning date.
5. The incident-response reality: severity ladder, paging paths, runbook inventory, and who is actually on call — wiring targets must exist; a route to nobody is a gap, not wiring.
6. Regulatory or contractual monitoring obligations that name specific detections, retention, or response times.

Workflow

1. Derive detection requirements from attacker behavior, not from what is convenient to log. Walk the threat model and the application's security surfaces; for each, state the observable event an attack would produce. Start from the standard security-event classes in references/security-event-coverage-sheet.md: authentication (failures, anomalies, credential stuffing patterns), access control (denials, object-level failures, cross-tenant attempts), privilege and security-config changes, input attacks (injection attempts, abuse-signal spikes), and sensitive-data access/export.
2. Map required events against what is actually logged. For each required event: does a record exist, does it carry the fields detection needs (actor, tenant, target, outcome, source, correlation id, timestamp)? Missing events/fields become logging requirements handed to audit-log-architect or the owning service — with the rule that security events must be structured, not prose log lines.
3. Classify each event class into a detection posture: log-only (needed for investigation), ticket (aggregated review), or alert (a human reacts now). The default for a new class is ticket until a justified threshold exists — alerting on everything is how alerting fails.
4. Design the alert rules. Per alerting class: the trigger condition (single event or threshold/correlation over a window), the threshold and its justification against the observed baseline, and the noise controls — deduplication, aggregation by actor/source, and suppression rules that are bounded and owned. State explicitly what each rule will NOT catch.
5. Wire every alert. Owner (a role that exists), severity on the incident ladder, escalation path, and the runbook it links to — missing runbooks become named requirements for incident-response-runbook. An alert without an owner and runbook is not done.
6. Design the coverage tests. For each alert: a safe, synthetic way to prove it fires end-to-end (test event → detection → alert → route), plus a negative check that the noise controls do not silently swallow the real pattern. Alert rules that cannot be exercised are listed as unverifiable.
7. State the blind spots honestly. Threats with no detection, events that cannot be logged today, thresholds set without baselines — each with a reason and a follow-up owner. An honest blind-spot list beats implied full coverage.
8. Hand off implementation. The alert/dashboard configuration is implemented by observability-operator (manual-only); logging changes go to the owning service or ; response procedures to . This skill changes nothing itself.

Output Format

A security detection & alerting design containing:

1. Detection coverage map — event class × required events × source × required fields × current status (logged / partial / missing).
2. Alerting rules table — per rule: trigger condition, threshold + justification (baseline or "unbaselined — tuning date"), correlation/ dedup/suppression, severity, owner, runbook link, and what it will not catch.
3. Response wiring table — alert → owner → escalation → runbook, with gaps named (missing runbook, unowned route).
4. Coverage test plan — per alert, the safe synthetic exercise proving it fires and routes.
5. Blind-spot register — undetected threats and unverifiable rules, each with reason and follow-up owner.
6. Handoff list — logging requirements (to audit-log-architect / service owners), implementation items (to observability-operator), runbook items (to incident-response-runbook).

Validation Checklist

• Every threat-model threat has a detection answer: covered, ticketed, or an explicit blind-spot entry — none silently skipped.
• Every alert rule has: trigger, threshold justification (or an "unbaselined" label with a tuning date), severity, owner, escalation, and a runbook link.
• Noise controls (dedup/aggregation/suppression) are bounded and owned — no unbounded suppression that could hide a real attack.
• Tenant context is a required field on every security event in the coverage map.
• Each alert has a defined safe way to prove it fires end-to-end, or is listed as unverifiable.
• The design changed no code and no live alert config; every change is in the handoff list with an owning skill or human.
• OWASP category claims are scoped to the concrete risks covered; exact category text is flagged for confirmation against the OWASP source, not asserted from memory.

Gotchas

• Recording is not detecting. A complete audit log with no rules watching it fails A09 exactly as hard as no log — the breach is reconstructable but not noticed. The audit trail is an input here, never the deliverable.
• Alert-on-everything is alert-on-nothing. Unjustified thresholds and unaggregated per-event alerts train responders to ignore the channel; the design must show the noise math (expected fires/day) per rule.
• Deleting noisy alerts loses coverage silently. Noise redesign must show what each removed/retuned rule stops catching and where that detection moved (ticket, correlation rule) — otherwise it is coverage loss dressed as hygiene.
• Security alerting ≠ reliability alerting. Error-budget burn pages on user-visible symptoms; security detection fires on attacker behavior that may be invisible to users (slow credential stuffing, low-and-slow export). Reusing reliability thresholds for security events misses both ways.
• Fields decide detectability. "Login failed" without actor, source, and tenant cannot support a credential-stuffing rule; field requirements are part of detection design, not an implementation detail.
• Wiring rot. Routes to a person (not a role), to a channel nobody reads, or to a runbook that was never written — wiring must reference things that verifiably exist at design time.
• OWASP text drift. This skill's A09 mapping uses the category name as recorded in the repo's D8 coverage audit of OWASP Top 10:2025; when quoting category text or scope, confirm against the OWASP source first (verify-don't-assert) — editions revise, and framework-edition-tracker owns detecting that drift.

Stop Conditions

• No threat model and no statable attack concerns exist — detection requirements would be invented; run threat-modeler first or get the human's concern list.
• Asked to EDIT live alert/dashboard/monitoring configuration — that is observability-operator (manual-only); this skill designs and hands off.
• Asked to weaken or delete alerting/suppression in a way that removes detection coverage without a documented, human-approved tradeoff.
• The organization has no incident-response path at all (no owner, no severity ladder): alert wiring would route to nobody — surface this as the blocking gap instead of designing unroutable alerts.
• Monitoring obligations are contractual/regulatory and their exact requirements are unavailable — confirm the obligation text with the human rather than guessing detections into a compliance claim.

Supporting Files

• references/security-event-coverage-sheet.md — starter security-event classes with example events, required fields, default detection posture, and noise-control patterns.
• evals/evals.json — behavior cases: coverage design, noisy-alert redesign, refusal to edit live config, source-honesty on OWASP text, and the audit-record boundary.
• evals/trigger-evals.json — discrimination against audit-log-architect, observability-operator, slo-reliability-architect, and incident-response-runbook.