From 3b69f255ec8360fd0351529b2bfb142d22b14c50 Mon Sep 17 00:00:00 2001 From: "Claude Sonnet 4.6" Date: Fri, 5 Jun 2026 09:54:49 +0000 Subject: [PATCH] feat: Add concrete milestone deliverables at Day 30/90/180 rapid-modernisation-plan.md: New 'Milestone Deliverables' section with 23 numbered, verifiable deliverables across three milestones. Day 30 (7 deliverables): Brownhat Diagnostic, ASTRAL deployed, PULSAR deployed, T0 accounts hardened, attack surface report, quick wins closed, stale account queue opened. Hard gate: if ASTRAL/PULSAR not deployed, the bottleneck is access provisioning not scope. Day 90 (9 more deliverables): MFA for all users enforced (not enrolled), legacy auth blocked, CA baseline, P0/P1 vulns closed, BloodHound before/ after, vendor access hardened, T0 backup verified, ASTRAL restore drill, PULSAR top 5 alert rules with runbooks. Day 180 (7 more deliverables): Alert runbooks, custom detection rules, client IT lead independence (live walkthrough), housekeeping 3 cycles, module completion packages, risk register closure evidence, retained scope. Each milestone includes the verifiable evidence column and a 'what this value stands alone' statement. Section closes with honest timeline modifiers (large AD, high user count, OT environments). business-case-template.md: The Ask updated to quote the three milestones explicitly. Co-Authored-By: Tom Kracmar --- .../playbooks/business-case-template.md | 2 +- .../playbooks/rapid-modernisation-plan.md | 82 ++++++++++++++++++- 2 files changed, 82 insertions(+), 2 deletions(-) diff --git a/antifragile-consulting/playbooks/business-case-template.md b/antifragile-consulting/playbooks/business-case-template.md index 1cd2988..8f7c129 100644 --- a/antifragile-consulting/playbooks/business-case-template.md +++ b/antifragile-consulting/playbooks/business-case-template.md @@ -150,7 +150,7 @@ Present as: *"This program delivers a [X]% return in year one, rising to [Y]% in **The Ask (Full Programme)**: -> *"We recommend approval of a 180-day antifragile enterprise programme, structured in three 60-day phases with hard go/no-go gates. The initial 60-day investment is €[X] with a defined deliverable: the kill chain documented, T0 accounts hardened, and ASTRAL/PULSAR deployed. If the kill chain is not closed by day 60, the programme stops with no further obligation. The 180-day programme produces a hardened foundation and a client team that can operate it independently — not a complete transformation. What comes after that is a retained capability engagement, scoped separately."* +> *"We recommend approval of a 180-day antifragile enterprise programme with three hard milestones. By Day 30: your kill chain is documented, ASTRAL and PULSAR are live, and your most privileged accounts are hardened. By Day 90: MFA covers the entire organisation, your kill chain is closed, and you have detection capability on M365. By Day 180: your team operates the systems independently, housekeeping is running as a permanent stream, and everything we built is in your repository. That is the 180-day programme. What comes after is a retained scope — scoped separately, renewed quarterly."* **The Ask (Modular Alternative)**: diff --git a/antifragile-consulting/playbooks/rapid-modernisation-plan.md b/antifragile-consulting/playbooks/rapid-modernisation-plan.md index 1fb40f3..70fc382 100644 --- a/antifragile-consulting/playbooks/rapid-modernisation-plan.md +++ b/antifragile-consulting/playbooks/rapid-modernisation-plan.md @@ -19,10 +19,90 @@ This is not a three-year digital transformation. It is a **180-day foundation pr **Investment principle**: Configuration first. Procurement only if justified. Most value is extracted from existing tools before any new purchase is discussed. -**Governance**: Weekly check-in with named client lead. Monthly steering committee. Hard go/no-go gates at days 60, 120, and 180. +**Governance**: Weekly check-in with named client lead. Monthly steering committee. Hard go/no-go gates at days 30, 90, and 180. **Modularity**: Every phase can be delivered as an independent, fixed-scope module. See [Modular Engagements](../core/modular-engagements.md) for the standalone engagement menu. +--- + +## Milestone Deliverables: What You Hold in Your Hands + +The three milestone dates — Day 30, Day 90, Day 180 — are not arbitrary progress checkpoints. Each produces a specific, verifiable set of deliverables. A client who stops at Day 30 still holds something of lasting value. A client who reaches Day 180 holds everything below in a form they can operate without us. + +### Day 30: Intelligence and Immunity + +*Precondition: Brownhat Diagnostic complete, access provisioned by kickoff.* + +| # | Deliverable | Verified by | +|---|-------------|-------------| +| 1 | **Brownhat Diagnostic report** — kill chain identified, up to 5 immediate quick wins, prioritised module roadmap | Delivered document | +| 2 | **ASTRAL deployed** — complete M365 tenant configuration snapshot committed to Git; drift detection running; event-driven change probe active | First drift PR visible in ADO | +| 3 | **PULSAR deployed** — all M365 admin audit events ingesting; logs searchable from day 1 forward; 12-month retention accumulating | Oldest log entry confirmed in UI | +| 4 | **T0 accounts hardened** — every Global Admin, Domain Admin, and high-privilege service principal identified; MFA enforced; documented with owner | CA sign-in logs show MFA enforced for T0 accounts | +| 5 | **Public attack surface report** — all internet-facing assets enumerated; P0 findings (internet-exposed + critical CVE) identified and prioritised | Delivered report | +| 6 | **Quick wins closed** — up to 5 immediate improvements from Brownhat findings, using existing tools, zero procurement | Closed items documented in change log | +| 7 | **Stale account queue opened** — full list of candidates generated and prioritised; named owner and monthly cadence confirmed | Queue visible in agreed tracking system | + +**The Day 30 value**: You know your kill chain. Your M365 configuration is under version control and your audit logs are being retained — permanently, from this day. Your most privileged accounts are hardened. This stands on its own regardless of what follows. + +*Day 30 is a hard gate. If ASTRAL and PULSAR are not deployed and T0 accounts are not confirmed as MFA-enforced by day 30, the engagement has a resourcing or access problem that must be resolved before proceeding.* + +--- + +### Day 90: Kill Chain Closed + +*Everything from Day 30, plus:* + +| # | Deliverable | Verified by | +|---|-------------|-------------| +| 8 | **MFA enforced for all users** — not just enrolled; enforced via Conditional Access policy | CA sign-in logs: zero successful authentications without MFA for in-scope users | +| 9 | **Legacy authentication blocked tenant-wide** | CAExporter export + sign-in logs: zero legacy auth sign-ins in past 7 days | +| 10 | **Conditional Access baseline deployed** — device compliance, sign-in risk, location policies active and tested | CA policy set exported by CAExporter; test sign-in matrix documented | +| 11 | **P0 and P1 vulnerabilities closed** — from Day 30 attack surface report | Rescan confirming closure; residual items in risk register | +| 12 | **AD attack paths reduced** — BloodHound before/after comparison showing measurable reduction in paths to Domain Admin | BloodHound report: path count comparison | +| 13 | **Vendor remote access hardened** — time-bounded, MFA-required, session-recorded for all third-party access | Vendor access log showing new controls enforced | +| 14 | **T0 backup integrity verified** — at least one successful restore per T0 system, timed and documented | Backup test report per T0 system | +| 15 | **ASTRAL: first restore drill** — a rejected drift PR has triggered the restore pipeline; restore validated against a real change | ADO restore pipeline run log | +| 16 | **PULSAR: top 5 alert rules operational** — rules written, test-triggered, runbooks drafted for each | Alert rule set visible; test trigger documented | + +**The Day 90 value**: Your kill chain is closed. MFA covers the entire organisation. The highest-risk attack paths are measurably reduced. Any incident from this point has a detection and response capability behind it — and your configuration is auditable back to day 1. + +--- + +### Day 180: Operational Independence + +*Everything from Day 90, plus:* + +| # | Deliverable | Verified by | +|---|-------------|-------------| +| 17 | **Alert runbooks complete** — documented response procedure for every active PULSAR alert rule; escalation paths defined | Runbook set reviewed and signed off by client IT lead | +| 18 | **Custom detection rules** — at least 3 rules written for client-specific TTPs identified in Phase 1 kill chain | Rules deployed; test-triggered and confirmed | +| 19 | **Client IT lead operational independence** — client IT lead demonstrates ability to: review ASTRAL drift PRs, search PULSAR events, trigger and verify an alert rule | Live walkthrough completed without consultant prompting | +| 20 | **Housekeeping stream running** — 3 consecutive monthly cycles completed; accounts resolved per cycle tracked | Queue status report showing 3 cycles; measurable reduction | +| 21 | **Module completion packages delivered** — every runbook, script, configuration file, and detection rule in client's own repository | Repository contents confirmed; client confirms ownership | +| 22 | **Risk register closure evidence** — before/after comparison for every risk addressed during the programme; residual risks documented | Risk register delivered and reviewed with executive sponsor | +| 23 | **Retained capability scope agreed** — written scope for continuation: cadence, activities, named owner | Signed retained scope or explicit decision to defer | + +**The Day 180 value**: You are no longer dependent on us. The systems run, the detections fire, the housekeeping happens on schedule. What continues in the retained scope is enhancement — not maintenance of what we built. + +--- + +### What These Milestones Assume + +These deliverables are based on a typical M365-primary environment with: +- A named client lead with 30–40% availability +- Access provisioned before kickoff (accounts, MFA, Global Admin for ASTRAL/PULSAR bootstrap) +- An IT admin who can execute configuration changes with guidance +- Weekly check-ins not cancelled + +**What shifts the timeline:** +- Large or complex AD environments add 2–4 weeks to Day 90 work +- High user count (500+) adds 2–4 weeks to MFA rollout change management +- Constrained IT team availability is the single most common cause of slippage — budget for it honestly in the scope +- OT environments: see the [Critical Infrastructure Adaptation](move-fast-and-fix-things.md#the-critical-infrastructure-adaptation); Day 90 timelines for network segmentation work are longer + +**What does not shift the Day 30 milestone:** ASTRAL and PULSAR deploy in hours. The Brownhat Diagnostic is 2 half-day workshops. T0 account hardening is 1–2 weeks of focused work. If Day 30 deliverables are not met, the bottleneck is access provisioning or client availability — both of which are addressable before kickoff. + *For the business case and financial justification, see [Business Case Template](business-case-template.md).* *For board conversation guidance, see [C-Suite Conversation Guide](../core/c-suite-conversation-guide.md).*