Security Monitoring Strategy

---
name: security-monitoring-strategy
description: Design security monitoring — which events to watch, alert severities and thresholds, on-call rotation and escalation, the monitoring stack, runbooks per alert, and detection and response SLOs. Use when the user asks what security events to alert on, who gets paged, or how fast they should detect and respond. Not for rolling out a SIEM; see /security-siem-setup.
metadata:
  argument-hint: "[project] [--skip-checks]"
  workflow: security
  phase: 3
  artifact: 03-detect.md
---

# Monitoring Strategy

Design security monitoring, alerting, and observability for "$ARGUMENTS". Define what to monitor, set alert thresholds and severity levels, and establish on-call procedures and response runbooks.

**Arguments.** `$ARGUMENTS` may contain the project name and optional flags. Take the first token as `<project>` and treat `--skip-checks` as a flag; never include flags in file paths. All paths below use `<project>`. If `--skip-checks` is present, skip the prerequisite check and, **before writing any artifact**, append one line to `.singularskills/log.jsonl`: `{"ts":"<ISO timestamp>","skill":"security-monitoring-strategy","workflow":"security","phase":3,"project":"<project>","event":"skipped","artifact":"03-detect.md","note":"<reason or \"none given\">"}`.

## Prerequisites

**Part of a workflow.** This skill is phase 3 (Detect) of the NIST CSF workflow (`security`); cross-domain workflows run it too. First check `.singularskills/log.jsonl` for an open run for this project: a `run-started` line with `"project":"<project>"` and no later `run-finished` line for the same `workflow` and `project`. If one exists, the conductor is running you: continue here. Otherwise, if the user asked to start, run, continue or resume a process or workflow rather than this one step, do not continue here: invoke the `workflow` skill with the workflow the user asked for, or `security` when they named none, followed by `<project>`; it runs this phase in order, asks before it writes and records the run. Otherwise continue here: a later phase runs on its own, behind its gate.

Run this skill's gate before writing: `sh <this skill's folder>/scripts/gate.sh <project> <project root>`, where `<project root>` is the folder that contains `.singularskills/` (use `.` when you are already there). If it exits non-zero, stop and tell the user what it printed, unless `--skip-checks` was given (see Arguments). On a refusal, before you stop, append this line to `.singularskills/log.jsonl` (create the folder and file if missing): `{"ts":"<ISO timestamp>","skill":"security-monitoring-strategy","workflow":"security","phase":3,"project":"<project>","event":"refused","artifact":"03-detect.md","note":"<what the gate printed>"}`. Once the gate has passed, or under `--skip-checks` once you have appended the `skipped` line, append this line before you start work: `{"ts":"<ISO timestamp>","skill":"security-monitoring-strategy","workflow":"security","phase":3,"project":"<project>","event":"started","artifact":"03-detect.md","note":""}`.

Read `.singularskills/security/<project>/00-govern.md`. If this file does not exist, tell the user:

> Phase 0 (Govern) has not been completed for "<project>". Run a Govern skill first (e.g., `/security-security-policy <project>`), or use `--skip-checks` to bypass.

## Process

1. **Define what to monitor:**
   - **Authentication events** — login successes and failures, MFA challenges, password resets, account lockouts
   - **Authorization failures** — access denied events, privilege escalation attempts, unauthorized API calls
   - **Data access** — sensitive data reads, bulk data exports, data modification patterns
   - **Configuration changes** — infrastructure changes, security group modifications, IAM policy updates
   - **Network traffic anomalies** — unusual outbound traffic, connections to known malicious IPs, DNS anomalies
   - **Application-level events** — error rate spikes, request pattern changes, resource exhaustion

2. **Set alert thresholds and severity levels:**
   - **Critical (P1)** — active breach indicators, data exfiltration detected, privilege escalation confirmed (response: immediate, 24/7)
   - **High (P2)** — multiple failed login attempts from single source, unauthorized configuration change, known malware signature (response: within 1 hour)
   - **Medium (P3)** — unusual access pattern, new admin account created, certificate expiring soon (response: within 4 hours)
   - **Low (P4)** — informational security events, policy compliance drift, minor configuration anomaly (response: next business day)
   - Define alert deduplication and correlation to reduce noise

3. **Define on-call rotation and escalation:**
   - Design on-call rotation schedule (primary and secondary responders)
   - Define escalation paths by severity (P1 escalates to security lead and CISO)
   - Set escalation timeouts (auto-escalate if not acknowledged within defined window)
   - Ensure coverage across time zones and holidays
   - Define communication channels per severity (PagerDuty, Slack, phone)

4. **Choose monitoring stack:**
   - Evaluate monitoring platforms (Datadog, Splunk, Elastic, CloudWatch, Grafana + Prometheus)
   - Define integration requirements with existing infrastructure
   - Plan metric collection, log aggregation, and trace correlation
   - Design dashboard hierarchy (executive overview, team-specific, service-specific)
   - If the chosen platform is a SIEM, hand off its rollout (ingestion, correlation rules, SIEM dashboards) to `/security-siem-setup`

5. **Create runbooks for common alerts:**
   - Write step-by-step response procedures for each alert type
   - Include investigation steps, containment actions, and escalation criteria
   - Define automated response actions for high-confidence detections
   - Link runbooks to alert configurations for quick access during incidents

6. **Define SLOs for detection and response:**
   - Mean time to detect (MTTD) targets by threat category
   - Mean time to respond (MTTR) targets by severity level
   - Alert accuracy targets (minimize false positive rate)
   - Coverage targets (percentage of critical systems monitored)
   - Define measurement and reporting cadence

7. **Write the artifact** — append to `.singularskills/security/<project>/03-detect.md` under a `## Monitoring Strategy` section. Create the file with a `# Detect — <project>` heading if it does not exist; if a `## Monitoring Strategy` section already exists, replace only that section. The section contains:

   - **Monitoring Scope** — events and systems to monitor with rationale
   - **Alert Thresholds** — severity levels, thresholds, and response timeframes
   - **On-Call and Escalation** — rotation schedule and escalation paths
   - **Monitoring Stack** — selected tools and integration architecture
   - **Runbooks** — response procedures per alert type
   - **Detection SLOs** — MTTD, MTTR, accuracy, and coverage targets

## Output

The monitoring strategy appended to `.singularskills/security/<project>/03-detect.md`. Present a summary to the user highlighting:
- Key events and systems to be monitored
- Alert severity levels and response timeframes
- On-call structure and escalation paths
- Detection SLO targets

**Record the run.** After you have written your section, append this line to `.singularskills/log.jsonl` (the `started` line of Prerequisites, with `"event":"finished"`): `{"ts":"<ISO timestamp>","skill":"security-monitoring-strategy","workflow":"security","phase":3,"project":"<project>","event":"finished","artifact":"03-detect.md","note":""}`.

This artifact is shared by every skill of phase 3 (Detect). The frontmatter is written once, by whoever creates the file: if you create it, open it with the block below (`skill` is the phase title, `started` the time of that first write; `gate` is `passed` when the gate ran clean and `skipped` under `--skip-checks`); if it already exists, leave the block alone except to update `finished` and to set `gate` to the worst value among the sections (`skipped` over `passed`).

```yaml
---
skill: Detect
workflow: security
phase: 3
project: <project>
started: <ISO timestamp>
finished: <ISO timestamp>
agent: <the agent you run in, or "unknown">
gate: <passed|skipped>
---
```

Open your `## Monitoring Strategy` section with one italic line, `*<skill name> · <ISO timestamp> · gate: <passed|skipped>*` (your skill name is `security-monitoring-strategy`).

End your section with `### Decisions` and `### Open questions` (one level under your `## Monitoring Strategy` heading, so the section stays one block), in this shape:

```markdown
### Decisions
- <what was chosen> — <why> — <what was rejected>

### Open questions
- <what the next phase or a reviewer must settle>
```

End the artifact with this paragraph, verbatim:

> **Not a penetration test or audit.** This artifact is generated analysis; validate findings against the live system and have material controls reviewed by a qualified security professional.