learntodriveai.dev/Cybersecurity/Designing a Security Engagement From the Brief
Cybersecurity·Project 21·6 units

Designing a Security Engagement From the Brief

**Track:** Cybersecurity

§ Brief

You're designing and conducting a security assessment of the One Government Portal for Tuiatua Sefulu, Director of Digital Transformation at Samoa's Ministry of Communications and Information Technology. The engagement produces a report for the Prime Minister's office and a repeatable methodology so the ministry can run this review annually.

The discipline skills: authoring an engagement methodology from scratch; threat-modelling a national service; setting scope; designing the AI architecture; running reconnaissance and exploitation under your own stop-criteria; writing a detection strategy with quantitative targets; designing a selective zero-trust model; building a purple-team-informed remediation programme; reporting in executive voice; and handing off the engagement memory for the next assessor.

The AI-direction lesson: nothing tells you what to apply. The platform has supplied structure across the track — a scope at one project, a methodology at another, a template later — and now that structure transfers from the platform to you. AI executes each phase but does not hold the engagement together. It does not know when reconnaissance is sufficient, when exploitation has proven the point, or that detection rules need quantitative commitments unless you specify them. Which patterns from the track are load-bearing for this engagement is your call.

Your Role

You're the consultant the ministry called. The methodology, threat model, TTP plan, verification architecture, AI decomposition, trust model, remediation programme, report, and repeatable methodology for the next annual assessor — all yours.

No methodology template, no scope worksheet, no threat-model starter, no detection-strategy framework, no remediation-priority rubric, no engagement-specific report template, no staged colleague review. You receive a forwarded email and a portal to assess. A senior colleague is still on-demand for a second opinion on the methodology, but they won't volunteer — the engagement is yours to design.

What's New

Last time, you evaluated AI security platforms for a Cape Verde telco — a pattern-based evaluation and a board-ready recommendation.

You design the engagement shape. Previous projects gave you a methodology to apply. This one gives you a problem. The shape of the work — what units exist, what gets verified when, what AI does and what you do — is your design.

Reasoning is the deliverable. Inline checks shift from "did you produce the artifact" to "what did you choose, what did you reject, why." A design-decisions record runs alongside the engagement. The next annual assessor will read your methodology and your decisions — they are the durable institutional asset, not the report.

Forwarded email, Pacific government register. Tuiatua writes in formal Pacific courtesy — measured, careful, decisive once committed. He responds within the Apia working day. He gives you room to lead because the ministry does not have deep security expertise internally; that means you also lead him into questions he has not asked yet.

The hard part: authoring a methodology with no reference frame is harder than executing one that is given to you. AI will fill any structural gap with plausible-looking output — a methodology that reads well but does not constrain the engagement, a threat model of generic risks, detection rules without targets, a report that catalogues findings instead of driving a decision. The discipline is naming the commitments, stop-criteria, verification gates, and trust boundaries before the work begins.

Tools

  • Claude Code — familiar. Driving every phase, with five engagement-scoped agents you specify for this engagement.
  • Codex CLI — familiar. Optional for parallel offensive-and-defensive observation during exploitation.
  • One Government Portal fixture — a Docker stand-up of the portal, four connected ministry databases, the citizen identity-verification database, and a representative log corpus. Fixture-only; no real government infrastructure is touched.
  • Nmap, ZAP, Nuclei, Burp, sqlmap, Metasploit — offensive toolkit, familiar. You select which the methodology specifies for which questions.
  • Wazuh, Loki, Grafana, Suricata, osquery, Sigma — defender stack, familiar. The detection strategy specifies which paradigm covers which TTPs.
  • Engagement-memory infrastructure — the working tree inherited from the previous project: pattern-vocabulary skill, CLAUDE.md, AGENTS.md, three-layer durability model. Adapt rather than rebuild.
  • Markdown, YAML, Python, Mermaid, GitHub — for the methodology, attack-tree diagrams, Sigma rules, verification scripts, report, and engagement repository.

Materials

  • The forwarded email (first-contact.md) — the Prime Minister's office to Tuiatua to you, with Tuiatua's framing memo. About 250 words. This is the entire brief.
  • Samoa operational context (samoa-context.md) — small-island governance, currency, working languages, Apia business hours, formal Pacific courtesy register, the recent regional incident that triggered the directive.
  • One Government Portal fixture (one-government-portal-fixture/) — portal application, four ministry-database stand-ins, the citizen identity-verification database, a sample log corpus, and Docker compose.
  • Inherited engagement-memory baseline (engagement-memory/) — CLAUDE.md and AGENTS.md baselines, the pattern-vocabulary skill, the three-layer durability model documentation, and two blank-form templates (one agent spec, one report). No methodology, scope, threat-model, detection-strategy, or remediation template — those are yours.
  • Project governance (CLAUDE.md) — project context, hard constraints, verification targets, commit convention.

Every other artifact of the engagement is yours to author.