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). Addresses the detection and alerting portion of 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), checking audit logging is on in an account (cloud-security-baseline-reviewer), 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 addresses the detection and alerting portion of OWASP Top 10:2025 A09 —
Security Logging and Alerting Failures. Log integrity, safe content handling,
retention and backup require their own audit-log design and operating controls.
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: the ask is whether audit logging is actually switched on
  in every account and region — that is `cloud-security-baseline-reviewer`,
  which checks configured settings; this skill designs what the logs must
  detect and alert on.
- 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
   include tenant context when known or derivable; pre-tenant and global
   events record an explicit unknown or not-applicable tenant state.
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](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 when known or its explicit unresolved state, 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). Choose immediate alerts for high-severity single events when the
   threat and response need them. For rate-based classes without a measured
   baseline, begin with a ticket or a labeled provisional threshold and
   tuning date; 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 `audit-log-architect`; response procedures to
   `incident-response-runbook`. 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.
- [ ] Every security event has tenant context when known or an explicit
      unknown/not-applicable state 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](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](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](evals/trigger-evals.json) — discrimination
  against `audit-log-architect`, `observability-operator`,
  `slo-reliability-architect`, and `incident-response-runbook`.