Auditing and Repairing an Inherited Security Setup

You're inheriting a half-finished security setup at Baghdad Technical University, where Dr. Zahra Al-Bayati runs IT Services and needs someone to make sense of what the previous consultant left behind. You'll diagnose what works, repair or replace what's broken, and produce maintenance documentation her three-person team can run without a consultant.

The discipline skills: designing your own audit approach with no template; inventorying an inherited Wazuh, Loki, and Grafana stack; diagnosing why detection rules that pass validation stopped firing; reconstructing the purpose of an undocumented decoder; correcting stale engagement memory; triaging a remediation tracker whose status labels can't be trusted; deciding fix versus replace and verifying the repair held; and writing the handoff documentation that was never written.

The AI-direction lesson: every other project asked how to build something. This one asks what someone else built, and whether it's still right. AI executes the audit work, but it trusts the inherited engagement memory and reproduces its stale assumptions — it will look for log patterns that no longer exist. AI retries a failed detection with parameter tweaks instead of diagnosing the root cause. It proposes a fix or omits a finding rather than reconstructing why a finding was deferred. The inherited artifacts are claims, not facts, and AI will believe them unless you catch the drift first.

Your Role

You're the consultant Zahra called in to recover an engagement that stopped. You deliver a verified diagnosis of the inherited setup, the repairs, a corrected engagement memory, properly closed tracker items, and a maintenance plan written for a stretched internal team — not for an executive, not for another consultant.

Last time the platform handed you a problem and you authored every artifact forward. This time the structure already exists. It's partly wrong and almost entirely undocumented, and there's no key telling you which parts to trust. You work with a new stance: every inherited artifact is untrusted until you've verified it against evidence you gathered yourself. AI is a hazard here as much as a tool, because it inherits the same lies you do.

What's New

Last time, you designed an entire security engagement from a forwarded email for a Samoan government ministry — you were the structure, and the platform supplied only the problem.

This time you inherit structure instead of building it. The previous consultant deployed everything and walked away without explaining why any of it was done. Reading someone else's incomplete work backward — recovering the reasoning that was never written down — is a different job than authoring it forward.

The hard part: there is no answer key, and the artifacts actively mislead. A rule can pass every syntax check and still catch nothing. A tracker can say "complete" about something still exploitable. The engagement memory can describe a system that no longer exists. The discipline is knowing when an inherited thing is fine and should be left alone versus when it's silently broken and looks fine — and proving which by verification, not by what the labels claim.

Tools

• Claude Code — familiar. Driving the audit, but actively misled by the inherited engagement memory until you correct it.
• Wazuh, Loki, Grafana — familiar defender stack, but inherited: a manager, with promtail shipping logs, a ruleset, dashboards, and log collection you didn't configure. The stack is deliberately pinned to six-month-old versions (Wazuh 4.7.3, Promtail 2.9.6, Loki 2.9.6, Grafana 10.4.2) — current versions are Wazuh 4.14.x and Grafana Alloy supersedes Promtail (EOL 2026-03-02). The version drift is part of the inherited technical debt the audit catalogues; do not bump versions during the engagement (re-verifying the seeded alert-volume figures and the decoder load path would be a separate scoped task).
• Sigma — familiar. Forty-seven inherited rules and the sigma CLI for validation; syntax-valid is not the same as still-firing.
• Inherited engagement-memory infrastructure — a previous consultant's CLAUDE.md, custom skills, and validation hooks. Under audit, not adopted on trust.
• Docker — the inherited environment is a Docker stack you stand up with docker compose up and audit in place.
• Markdown, CSV, git/GitHub — for the audit records, findings, corrected engagement memory, and maintenance deliverables.

The unit that introduces the inherited stack walks through standing it up.

Materials

• The handover document — the previous engagement's status summary, delivered in chat. This is your starting point and it is sparse.
• The inherited environment (inherited-environment/) — the Docker stack: Wazuh manager, with promtail shipping logs, Loki, Grafana, 47 deployed Sigma rules, an undocumented custom decoder, and log corpora from the student information system, e-learning, Wi-Fi, and library systems in both pre- and post-migration formats.
• The inherited engagement memory (inherited-engagement-memory/) — the previous consultant's stale CLAUDE.md, custom skills, and a validation hook. Deliberately under-documented; the artifact under audit.
• The remediation tracker (remediation-tracker.csv) — 23 findings in their stale states, with no column explaining the reasoning behind any of them.
• University context (btu-context.md) — scale, the autonomous-department structure, the research computing cluster, and the SIS migration timeline.
• Project governance (CLAUDE.md) — your project context, the untrusted-until-verified stance, and verification targets.

There is no audit template, no corrected engagement memory, no key for which rules are good or which findings are truly closed, and no maintenance plan. Those are yours to produce.