You're designing a detection strategy for Caribbean Medical University in Grenada, where Vice President for IT Camille Baptiste needs a documented strategy with measurable performance targets that an accreditation committee will accept as evidence.
The discipline skills: baselining what current telemetry actually detects; redirecting coverage from "what's easy" to "what the threat model says matters"; choosing a SIEM architecture per data tier with a defensible rationale; committing in writing to detection rate, false positive rate, and detection latency targets; designing exploitation that tests whether the strategy works; writing for both the technical team and the accreditation committee; and producing a handoff packet the next assessor can pick up cold.
The AI-direction lesson: AI optimises for ATT&CK coverage completeness and proposes "comprehensive" infrastructure that deploys every available tool. It does not weigh business risk, does not read the regulatory regime, and does not test the resilience claims it writes. The lesson at this altitude is partly when not to use AI: strategy prioritisation, evasion-resilience assessment, and executive translation are yours. The composition challenge is also new — an offensive validation agent and a defensive strategy agent can each produce valid output while the composition fails, and you'll design verification that spans them.
Your Role
You're the detection strategy architect. You design the baseline assessment, the threat model, the coverage prioritisation, the SIEM architecture, the per-tier targets, the validation regime, the strategy document, and the handoff packet.
Scaffolding is thin. No detection-strategy template, no SIEM architecture template, no targets table to fill in. The brief is a forwarded email — an accreditation finding layered with Camille's working hypothesis. A senior colleague returns for one tightly placed touchpoint: Dani Okafor reviews your quantitative targets in Unit 4 and asks one pointed question about whether the clinical and student tiers should share the same detection latency. She is not present elsewhere. The AI relationship is multi-agent and scoped — an offensive validation agent, a defensive strategy agent, and a multi-audience writer agent, each with context limited to its task, under your orchestration.
What's New
Last time you designed a reconnaissance campaign for a textile manufacturer in Tajikistan — adversary profile, sufficiency judgment, noise as a deliberate variable, an attack-surface map as the deliverable.
Strategy as a written commitment. Earlier projects had you write rules, tune them, map coverage, and remediate gaps. P14 asks you to commit, in a document a regulator will read, to the rate at which the institution detects threats — and to the architecture and validation regime that make the commitment real.
SIEM architecture is yours to design. From P1 through P13 the logging stack arrived pre-built. This time you decide which tiers Wazuh covers, which Loki covers, which use both, and you write the rationale.
Exploitation tests detection. Offensive techniques you've used since P5 are now selected because they will reveal whether the detection strategy works, not because they are the cheapest path to compromise.
Three audiences, structurally. The document is for the technical team (ATT&CK heatmap, rule-by-rule tables, gap analysis), the accreditation committee (detection rate, false positive rate, business risk coverage, cost to close gaps with SLAs), and the Dean of Medicine (the ransomware-coverage answer his board asked for).
The hard part: knowing what NOT to delegate. AI generates rule candidates and coverage suggestions effectively, but strategy-level prioritisation, evasion-resilience assessment, and the executive translation require professional judgment AI cannot supply.
Tools
- Claude Code, Codex CLI — driving the offensive validation, defensive strategy, and multi-audience writer agents. Continuing.
- Wazuh, Loki, Grafana, Promtail, Suricata, osquery — the existing defender stack. Familiar. P14 is the first time you decide which tier each tool serves, with rationale. The lab pins Promtail 2.9.6 (deliberately — Caribbean Medical University's production stack is encoded that way); Grafana Alloy is the documented forward path the team will migrate to when the next platform upgrade lands (Promtail EOL 2026-03-02).
- Sigma, sigma-cli, pySigma backends — detection rule format and conversion tooling. Familiar.
- ATT&CK Navigator — coverage mapping and the technical-audience heatmap. Familiar from P11.
- Threat-modelling artefacts — STRIDE-style threat model for a medical-university threat landscape. Used to prioritise coverage.
- Python, Markdown, YAML, Mermaid — strategy document, baseline assessment, validation configuration, architecture diagrams.
- GitHub — engagement repository. Issues track detection-coverage gaps with closure SLAs.
Materials
- Forwarded first-contact email — the accreditation committee finding layered with Camille's framing and her working hypothesis.
- Existing-tools inventory — what's deployed, without strategy or targets.
- Regulatory-regime brief — FERPA-equivalent student records, HIPAA-adjacent clinical research data, and accreditation expectations.
- Medical-university Docker lab — clinical simulation labs, research database tier, student LMS, student housing Wi-Fi, admin systems, and the existing Wazuh + Loki + Grafana + Suricata + osquery defender stack.
- Agent-spec template — familiar from P13.
CLAUDE.md— engagement governance file with detection-strategy verification targets.
The threat model, coverage prioritisation, SIEM architecture, per-tier targets, validation regime, strategy document, and handoff packet are yours to design.