feat: Add findings backlog as pragmatic alternative to risk register
New: assessment-templates/findings-backlog.md Design principles: lives where client works, every finding has an owner, feeds the housekeeping stream, accumulates from all sources. Format: 6-field minimal entry (ID, finding, source, priority, owner, status) with optional target date/effort/notes/closed date. P0/P1/P2 priority using kill chain test. Flat file template for Git-based clients. Population guide: Day 30 (from Brownhat), subsequent modules, continuous tools (ASTRAL drift, PULSAR alerts, Elysium, BloodHound). Monthly housekeeping cycle structure. Relationship to formal risk register explained. Backlog health indicators (warning signs it is not functioning). Wired into existing framework: move-fast-and-fix-things.md: Rule 4 now names the backlog as the queue rapid-modernisation-plan.md: Day 30 item 7 and Phase 1 action updated engagement-model.md: Section 4 deliverables table updated at all stages assessment-templates/README.md: Production-ready templates section added index.md: Findings Backlog added to Assessment and Tools table Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>
This commit is contained in:
@@ -41,7 +41,7 @@ The three milestone dates — Day 30, Day 90, Day 180 — are not arbitrary prog
|
||||
| 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 |
|
||||
| 7 | **Findings backlog opened** — all Brownhat Diagnostic findings entered with P0/P1/P2 priority, owner assigned per item, monthly cadence confirmed; this is the input queue for the housekeeping stream | Backlog visible in agreed system; all findings from items 1–6 above entered |
|
||||
|
||||
**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.
|
||||
|
||||
@@ -178,7 +178,7 @@ Target: privileged accounts only. Not all accounts.
|
||||
| Restrict or close the highest-risk vendor access paths | Security / Procurement | Vendor access changes confirmed |
|
||||
| Implement basic network segmentation between IT and OT (if applicable) | Network / OT | Segmentation policy; validated firewall rules |
|
||||
| Phase 1 review: re-run BloodHound and Elysium against week 1 baseline | Security | Before/after comparison; revised kill chain assessment |
|
||||
| Establish housekeeping queue: stale accounts, orphaned permissions, legacy protocols | IAM / Security | Queue populated; named owner; monthly cadence confirmed |
|
||||
| Establish findings backlog: all Phase 1 findings entered with priority, owner, target date | IAM / Security | [Findings Backlog](../assessment-templates/findings-backlog.md) populated; named owner; monthly housekeeping cadence confirmed |
|
||||
|
||||
### Phase 1 Exit Criteria
|
||||
|
||||
|
||||
Reference in New Issue
Block a user