cqrenet/antifragile
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Add engagement model, consultant field guide, deliverable templates, CQRE tools integration, and Czech localization

Browse Source 
New documents:
- core/engagement-model.md: Full client-facing engagement lifecycle (Sections 1-6) plus consultant delivery discipline (Section 7)
- core/consultant-field-guide.md: Decision models, client qualification, module selection, 10 common mistakes, technical onboarding, proposal writing
- core/about-cqre.md: Company overview template with [PLACEHOLDER] markers for client-facing use
- core/about-cqre-cs.md: Czech version of company overview (O společnosti CQRE)
- core/executive-summary-cs.md: Czech translation of the board executive summary
- assessment-templates/nist-csf-baseline.md: Full Brownhat Diagnostic workshop methodology (NIST CSF 2.0)
- assessment-templates/nist-csf-baseline-cs.md: Czech version of Brownhat Diagnostic (for Czech-language workshops)
- assessment-templates/module-completion-report.md: Module completion package template
- assessment-templates/risk-register-example.md: 8 fully populated risk entries (Meridian Logistics GmbH fictional engagement)
- playbooks/privileged-access-architecture.md: Module 13 - Teleport, Tailscale/Headscale, JIT access, vendor governance
- playbooks/sovereign-communications.md: Module 14 - Delta Chat chatmail relay, Matrix/Element, crisis channels

Updated documents:
- playbooks/sovereign-tool-stack.md: Added Elysium, CAExporter, E8-CAT, macOS_IntuneManagement, IntunePolicyParser, M365-Scripts; updated capability matrix and module pairings
- core/modular-engagements.md: Module 2 now includes CAExporter as first step; Module 6 includes Elysium password audit
- reference/nist-csf-mapping.md: Added back-reference to nist-csf-baseline.md
- assessment-templates/README.md: Changed Q1/Q2/Q3/Q4 to Phase 1/2/3/4, added Status column
- index.md: Registered all new documents; restructured consultant navigation into three labeled groups (1-25)
- README.md: Updated directory tree; updated Quick Start for Consultants

Czech localization pointers:
- executive-summary.md: Added Česká verze pointer
- nist-csf-baseline.md: Added Česká verze pointer
- engagement-model.md: Added note that client-facing Czech translation is planned

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Tomas Kracmar
2026-05-27 21:33:52 +02:00
parent 7bab42398a
commit 64f73371c9
24 changed files with 3325 additions and 66 deletions
Download Patch File Download Diff File Expand all files Collapse all files
antifragile-consulting/assessment-templates/README.md
+8 -6
View File
@@ -55,12 +55,14 @@ Measures the organization's ability to convert incidents into structural improve
## Development Roadmap
| Quarter | Deliverable | Format |
|---------|-------------|--------|
| Q1 | AF-MM v1.0 questionnaire and scoring guide | Markdown + spreadsheet |
| Q2 | AI Sovereignty Readiness Assessment v1.0 | Interactive web form or CLI tool |
| Q3 | T0 Asset Discovery Scanner v0.1 | Python script (cloud APIs + on-premises) |
| Q4 | Dependency Risk Mapper v0.1 | Python + network analysis libraries |
Phases are sequenced by client impact, not calendar quarter. Dates are assigned at the start of each development cycle.
| Phase | Deliverable | Format | Status |
|-------|-------------|--------|--------|
| 1 | AF-MM v1.0 — Antifragile Maturity Model questionnaire and scoring guide | Markdown + spreadsheet | Planned |
| 2 | AI Sovereignty Readiness Assessment v1.0 | Interactive web form or CLI tool | Planned |
| 3 | T0 Asset Discovery Scanner v0.1 — cloud APIs + on-premises enumeration | Python script | Planned |
| 4 | Dependency Risk Mapper v0.1 — vendor coupling depth and failure cascade simulation | Python + network analysis | Planned |
## Contributing
antifragile-consulting/assessment-templates/module-completion-report.md
+238
View File
@@ -0,0 +1,238 @@
# Module Completion Report
> *Copy this template for each completed module. Remove all guidance notes (lines in italics or blockquotes) before sharing with the client. Fill every section — a section left blank signals incomplete delivery.*
---
```
Client: [Organisation name]
Module: Module [N] — [Module name]
Engagement start: [Date]
Completion date: [Date]
Consultant lead: [Name]
Client lead: [Name, role]
Report version: 1.0
```
---
## Executive Summary
> *One page. Written for the executive sponsor, not the IT lead. No technical jargon. Lead with the business outcome, not the technical activity.*
**What was done**: [One sentence describing the module in plain language. E.g., "We audited, cleaned, and hardened your Active Directory environment, eliminating the most direct attack paths to organisational failure."]
**Risk closed**: [One sentence on the primary risk addressed. E.g., "A compromised standard user account can no longer reach Domain Admin in fewer than 12 steps; previously it could in 3."]
**Before/after**: [Key metric comparison. E.g., "BloodHound attack paths to Domain Admin: 4,217 → 23. PingCastle score: 52 → 81. Kerberoastable service accounts: 14 → 2."]
**Outstanding items**: [Any P0 or P1 risks identified during the module that are not yet closed. Be specific. If none, state "None."]
**Recommended next step**: [One sentence on the logical next module and why now. E.g., "Module 2 (Identity Security) should follow within 60 days to extend the clean AD foundation into Entra ID and enforce MFA for all users."]
---
## Scope
### Agreed scope (from kickoff)
> *Copy the completion criteria from the scope agreement signed at kickoff.*
| Deliverable | Completion criterion | Status |
|-------------|---------------------|--------|
| [Deliverable 1] | [Verifiable condition] | ✅ Complete / ⚠️ Partial / ❌ Not completed |
| [Deliverable 2] | [Verifiable condition] | ✅ Complete / ⚠️ Partial / ❌ Not completed |
| [Deliverable 3] | [Verifiable condition] | ✅ Complete / ⚠️ Partial / ❌ Not completed |
> *For any Partial or Not Completed item, explain briefly in the section below.*
### Scope changes
> *Document any scope changes accepted during delivery. For each: what changed, why, and whether a change order was issued.*
| Change | Reason | Change order issued? |
|--------|--------|---------------------|
| [Change description or "None"] | | |
### Out-of-scope items discovered
> *Items found during the engagement that are outside this module's scope but should be tracked. These feed into the risk register update.*
| Finding | Risk tier | Recommended module |
|---------|-----------|--------------------|
| [Finding or "None"] | | |
---
## Change Log
> *Every change made during the engagement, in the order made. Date, what changed, why, and the client approval reference (name of person who approved and date). This log is the permanent audit record.*
| Date | System / Component | Change made | Rationale | Approved by |
|------|--------------------|-------------|-----------|-------------|
| [DD Mon YYYY] | [System] | [Specific change] | [Why this was needed] | [Name, date] |
| | | | | |
| | | | | |
> *If the change log is very long (>20 items), summarise by category here and attach the full log as a separate file in the client repository.*
---
## Deliverables
> *Everything produced during this engagement that the client now owns. All files should already be in the client's repository. This section is a reference map.*
| Deliverable | Location | Format | Notes |
|-------------|----------|--------|-------|
| Configuration baseline (pre-engagement state) | `[repo path]` | Markdown / JSON / CSV | Snapshot taken [date] |
| Configuration baseline (post-engagement state) | `[repo path]` | Markdown / JSON / CSV | Snapshot taken [date] |
| [Script / rule / query name] | `[repo path]` | PowerShell / Python / KQL / Sigma | [Brief description] |
| [Script / rule / query name] | `[repo path]` | | |
| Operating runbook | `[repo path]` | Markdown | See Section 6 |
> *Nothing produced during this engagement should require the client to contact CQRE to access or operate. If any deliverable requires our involvement to use, note it here and explain why — this is an incomplete handover.*
---
## Metrics Baseline
> *Before-and-after measurements that prove the work was effective. Choose metrics appropriate to the module. Avoid vanity metrics — only record what can be re-measured in the same way next quarter.*
| Metric | Before | After | Target | How measured |
|--------|--------|-------|--------|-------------|
| [Metric name] | [Value] | [Value] | [Value] | [Tool / method] |
| [Metric name] | [Value] | [Value] | [Value] | [Tool / method] |
| [Metric name] | [Value] | [Value] | [Value] | [Tool / method] |
> *Module-specific metric suggestions:*
> - *Module 1 (Endpoint)*: Intune enrolment %, E8-CAT maturity level, EDR coverage %
> - *Module 2 (Identity)*: MFA enforcement %, legacy auth sign-ins (target: 0), Global Admin count, Secure Score identity subcategory
> - *Module 3 (M365 Hardening)*: Secure Score overall, ASTRAL drift events (baseline), CA policy count (documented)
> - *Module 6 (AD Hardening)*: PingCastle score, BloodHound paths to DA, KRBTGT age (days), Kerberoastable SPNs, privileged account count
> - *Module 12 (Blue/Purple)*: TTP detection rate (%), MTTR (minutes), custom rules deployed, % of MSSP alerts with custom context
> - *Module 13 (Privileged Access)*: Accounts under PAM management %, session recording coverage %, JIT request volume (baseline)
> - *Module 14 (Communications)*: Enrolled participants in out-of-band channel, independence from corporate infrastructure confirmed (Y/N)
---
## Risk Register Update
### Risks closed this engagement
> *Each closed risk must have evidence — not just "we fixed it." Link to the specific change log entry, configuration export, or tool output that proves closure.*
| Risk ID | Risk name | Evidence of closure | Closed date |
|---------|-----------|--------------------|----------- |
| [AF-YYYY-NNN] | [Name] | [Evidence location] | [Date] |
### Risks remaining open
> *Risks identified before or during this engagement that are not yet closed. Include the priority, the recommended next step, and the suggested owner.*
| Risk ID | Risk name | Priority | Why still open | Recommended action | Owner |
|---------|-----------|----------|----------------|-------------------|-------|
| [AF-YYYY-NNN] | [Name] | P[0/1/2] | [Reason] | [Action] | [Name] |
### New risks identified during this engagement
> *Risks discovered during delivery that were not in the pre-engagement register. Add them to the full risk register and assign initial priority.*
| Risk ID | Risk name | Tier | Priority | Recommended module |
|---------|-----------|------|----------|--------------------|
| [AF-YYYY-NNN] | [Name] | T[0-3] | P[0-2] | Module [N] |
---
## Operating Guide
> *How the client's team operates and maintains what was built. If a full runbook exists in the repository (it should), reference it here and summarise the key maintenance actions.*
**Runbook location**: `[repo path to runbook]`
### Maintenance calendar
| Action | Who | Cadence | What triggers escalation |
|--------|-----|---------|--------------------------|
| [Action, e.g. "Review ASTRAL drift alerts"] | [Role] | [Daily / Weekly / Monthly / Quarterly] | [Condition] |
| [Action] | | | |
### Alert handling
> *For any monitoring or detection deployed in this module, describe what the client's team does when an alert fires.*
| Alert type | Initial response | Escalation threshold | Escalation path |
|-----------|-----------------|---------------------|----------------|
| [Alert, e.g. "LAPS password access outside business hours"] | [Response] | [When to escalate] | [Who to contact] |
### Who to contact
> *Remove the CQRE contact information if this report is being used in a context where it should not appear.*
| Situation | Contact | Channel |
|-----------|---------|---------|
| Operational question about deployed tools | [Client IT lead name] | [Contact method] |
| Alert requiring security decision | [Client security lead name] | Delta Chat out-of-band channel |
| Suspected incident | [CQRE contact name] | Delta Chat out-of-band channel |
---
## Next Steps
### Recommended next module
**Module [N]: [Name]**
**Rationale**: [2–4 sentences explaining why this is the logical next step based on what was found in this engagement. Be specific — reference actual findings from the change log or risk register, not generic language.]
**Suggested timeline**: [When to start, based on the client's capacity and the urgency of the remaining open risks.]
**Prerequisites already met by this engagement**: [What this module produced that the next module depends on. E.g., "The clean AD baseline from this engagement is the required prerequisite for Module 2's PIM deployment."]
---
## Sign-Off
> *Both parties should confirm the module is complete before the final invoice is issued. This section should be signed (physically or via email confirmation). Attach the email confirmation to this document if signing electronically.*
**Completion confirmed by (client)**:
```
Name: ________________________________
Role: ________________________________
Date: ________________________________
Signature: ________________________________
```
**Completion confirmed by (CQRE)**:
```
Consultant: ________________________________
Date: ________________________________
```
**Outstanding items accepted by client** (if any completion criteria are partial):
> *If any items are marked Partial or Not Completed in the Scope table, the client must explicitly accept that the module is considered complete despite these items. Note what was agreed for each outstanding item.*
```
Item: ________________________________
Accepted by: ________________________________
Resolution: ________________________________
Date: ________________________________
```
---
## Integration With Existing Frameworks
| Document | Integration |
|----------|-------------|
| [Engagement Model](../core/engagement-model.md) | The Module Completion Package defined in Section 5; sign-off process in Stage 5 |
| [Antifragile Risk Register](antifragile-risk-register.md) | Risk register update section feeds directly into the client's running register |
| [NIST CSF 2.0 Baseline Assessment](nist-csf-baseline.md) | Metrics baseline maps to the domain scores from the Brownhat Diagnostic |
| [Modular Engagements](../core/modular-engagements.md) | Next-module recommendation references the module menu |
---
*Use [Antifragile Risk Register](antifragile-risk-register.md) for the full risk register format and taxonomy.*
*For worked examples of completed risk register entries, see [Risk Register Example](risk-register-example.md).*
antifragile-consulting/assessment-templates/nist-csf-baseline-cs.md
+265
View File
@@ -0,0 +1,265 @@
# Základní hodnocení NIST CSF 2.0
> *„Většina organizací neví, co neví. Tento workshop zpřístupní neznámé — za dva půldenní bloky, bez jediného technického nástroje."*
> *Anglická verze tohoto dokumentu je k dispozici zde: [NIST CSF 2.0 Baseline Assessment](nist-csf-baseline.md). Metodika, struktura hodnocení a pokyny pro konzultanta jsou totožné — tento dokument slouží jako pracovní nástroj pro workshopy vedené v češtině.*
---
## Účel
Toto hodnocení je **vstupním bodem před výběrem jakéhokoliv modulu**. Odpovídá na otázku, kterou každý klient potřebuje zodpovědět před přijetím závazku k programu: *„Kde skutečně jsme a co je nejdůležitější napravit?"*
Jde o strukturovaný workshop, nikoli technický audit. Žádné nástroje se neinstalují. Z IT systémů se neshromažďují žádná data. Výstupem je jasný obraz bezpečnostní pozice organizace napříč šesti funkcemi NIST CSF 2.0, zpráva o silných stránkách a mezerách a prioritizovaný plán nápravy, který se přímo mapuje na menu antifragilních modulů.
**Délka**: Dva půldenní bloky (4 hodiny každý). Preferovaná forma je osobní přítomnost; vzdálená s kamerou je přijatelná.
**Kdo se účastní**:
- CIO/CISO nebo ekvivalent (povinný účastník)
- IT manažer / vedoucí infrastruktury (povinný účastník)
- Jeden vlastník business procesu (finance, provoz nebo HR — ten, kdo spravuje nejkritičtější data)
- Volitelně: Legal/compliance, provozní manažer pro OT prostředí
**Předpoklady**: Žádné. Toto je výchozí bod.
---
## Jak workshop vést
### Před workshopem
Zašlete klientovi jednostránkovou přípravnou poznámku:
> *„Strávíme dva půldenní bloky společným zodpovídáním upřímných otázek o tom, jak vaše organizace dnes řídí bezpečnost. Neexistují špatné odpovědi. Naším cílem je porozumět skutečnému stavu — ne tomu, co říkají politiky, ne tomu, co byste chtěli dělat, ale tomu, co se skutečně děje. Přiveďte prosím lidi, kteří vědí, jak věci opravdu fungují."*
Žádné domácí úkoly, žádný dotazník k předvyplnění. Předvyplněné dotazníky produkují aspirační odpovědi. Workshop produkuje upřímné.
### Struktura workshopu
**Sezení 1 (1. půlden): Kontext a základy**
- 30 min — Úvod, pravidla, přehled metodiky
- 90 min — Doména GOVERN (organizační kontext a řízení rizik)
- 60 min — Doména IDENTIFY (správa aktiv a hodnocení rizik)
- 20 min — Shrnutí, nedořešené body, náhled na 2. sezení
**Sezení 2 (2. půlden): Kontroly, detekce a obnova**
- 30 min — Rekapitulace a otevřené body ze sezení 1
- 45 min — Doména PROTECT (kontroly a záruky)
- 45 min — Doména DETECT (monitoring a detekce anomálií)
- 30 min — Doména RESPOND (řízení incidentů)
- 30 min — Doména RECOVER (obnova a zlepšování)
- 20 min — Předběžná zjištění, další kroky
---
## Dotazníky k jednotlivým doménám
Pro každou otázku zaznamenejte:
- **Aktuální stav** (co se skutečně děje)
- **Důkazy** (jaká dokumentace nebo artefakty existují)
- **Skóre**: 🔴 Není přítomno / 🟡 Částečné nebo nekonzistentní / 🟢 Funkční a efektivní
Skóre je diskusní nástroj, nikoli auditní zjištění. Jeho účelem je odhalit mezery, nikoli klienta hodnotit na prospěl/neprospěl.
---
### GV — GOVERN (Řízení)
*Identifikuje procesy, role a struktury dohledu, které přijímají bezpečnostní rozhodnutí a určují směr.*
| # | Otázka | Doptejte se, pokud není jasná |
|---|--------|-------------------------------|
| GV-1 | Kdo v organizaci nese konečnou odpovědnost za kybernetickou bezpečnost? Má tato osoba pravomoc nad rozpočtem? | „Kdyby dnes v noci došlo k úniku dat, kdo by přijímal rozhodnutí o oznámení a nápravě?" |
| GV-2 | Má organizace zdokumentovanou politiku kybernetické bezpečnosti? Kdy byla naposledy přezkoumána? | „Četl ji někdo za posledních 12 měsíců? Odráží to, co skutečně děláte?" |
| GV-3 | Je riziko kybernetické bezpečnosti formálně reportováno představenstvu nebo výboru? Jak často? | „Co vedení skutečně vidí? Ohodnocení rizik? Přehledy incidentů? Nic?" |
| GV-4 | Jsou role a odpovědnosti v oblasti bezpečnosti jasně přiděleny a pochopeny těmi, kdo je zastávají? | „Kdybych se vašeho IT manažera zeptal, jaké jsou jeho bezpečnostní odpovědnosti, shodovala by se jeho odpověď s vaším očekáváním?" |
| GV-5 | Má organizace proces pro přezkoumání a schválení nových technologií před jejich nasazením? | „Jak byl váš poslední velký SaaS nástroj vyhodnocen před pořízením?" |
| GV-6 | Jsou dodavatelé a partneři třetích stran hodnoceni z hlediska bezpečnostního rizika? | „Víte, zda u vašich kritických dodavatelů došlo v posledním roce k narušení bezpečnosti?" |
**Klíčový poznatek k odkrytí**: Většina SMB má „odpovědnost za bezpečnost" neformálně přiřazenou tomu, kdo spravuje IT. To není totéž, jako mít odpovědného vedoucího pracovníka. Mezera bývá obvykle nikoli technická — je to mezera v řízení.
---
### ID — IDENTIFY (Identifikace)
*Rozvíjí organizační porozumění aktivům, business kontextu, zdrojům a schopnostem pro řízení kybernetického rizika.*
| # | Otázka | Doptejte se, pokud není jasná |
|---|--------|-------------------------------|
| ID-1 | Udržuje organizace inventář hardwarových aktiv? Je aktuální? | „Kdybych se vás teď zeptal, kolik notebooků vaše společnost vlastní, dokázali byste mi to říct?" |
| ID-2 | Udržuje organizace inventář softwaru a SaaS služeb? | „Víte, které SaaS nástroje vaši zaměstnanci používají s firemními daty? Včetně těch neoficiálních?" |
| ID-3 | Jsou nejkritičtější business procesy organizace a data, na nichž závisejí, zdokumentovány? | „Které tři systémy by, kdyby byly nedostupné týden, nejvíce ohrozily podnikání?" |
| ID-4 | Bylo v posledních 12 měsících provedeno hodnocení rizik? | „Kdo ho provedl? Bylo pouze technické, nebo zahrnovalo i riziko business procesů?" |
| ID-5 | Jsou definovány a uplatňovány úrovně klasifikace dat na citlivá data? | „Vědí zaměstnanci, které dokumenty jsou důvěrné a co to v praxi znamená?" |
| ID-6 | Rozumí organizace svému externímu útočnému povrchu (veřejné služby, domény, IP rozsahy)? | „Naskenovali jste někdy svoji organizaci zvenčí?" |
**Klíčový poznatek k odkrytí**: Propast mezi „máme registr aktiv" a „máme aktuální, přesný registr aktiv, na němž jsou bezpečnostní rozhodnutí založena" je téměř vždy větší, než klient očekává.
---
### PR — PROTECT (Ochrana)
*Rozvíjí a implementuje odpovídající záruky pro zajištění dodávky kritických služeb.*
| # | Otázka | Doptejte se, pokud není jasná |
|---|--------|-------------------------------|
| PR-1 | Je vícefaktorové ověření (MFA) vynuceno pro všechny uživatelské účty, včetně administrátorských? | „Existují výjimky? Přístup přes VPN? Starší aplikace? Sdílené účty?" |
| PR-2 | Jak jsou privilegované (administrátorské) účty spravovány? Jsou odděleny od každodenně používaných účtů? | „Kontroluje váš IT admin e-mail ze stejného účtu, ze kterého spravuje servery?" |
| PR-3 | Jsou aktualizace softwaru a záplaty aplikovány systematicky na všech zařízeních? Jaká je typická prodleva? | „Jak dlouho po vydání kritické záplaty Microsoftem ji vaše endpointy typicky obdrží?" |
| PR-4 | Jsou citlivá data šifrována v klidu i při přenosu? | „Kdyby byl dnes v noci ukraden notebook, mohl by útočník přistupovat k datům na něm?" |
| PR-5 | Je přístup k systémům založen na principu nejnižšího oprávnění? | „Když nastoupí nový zaměstnanec, k čemu má automaticky přístup?" |
| PR-6 | Existuje program bezpečnostního povědomí pro všechny zaměstnance? Kdy proběhlo poslední sezení? | „Kdybych dnes phishoval vaše zaměstnance, přibližně kolik procent by kliklo na odkaz?" |
| PR-7 | Jsou endpointová zařízení chráněna aktuálním anti-malware/EDR? Jaké je pokrytí? | „Existují zařízení — osobní notebooky, BYOD — která přistupují k firemním datům bez endpointové ochrany?" |
**Klíčový poznatek k odkrytí**: Většina organizací má MFA nasazené, ale nevynucené. Rozdíl je zásadní — „nasazené" znamená, že existuje; „vynucené" znamená, že ho nikdo nemůže obejít.
---
### DE — DETECT (Detekce)
*Rozvíjí a implementuje odpovídající aktivity pro identifikaci výskytu kybernetické bezpečnostní události.*
| # | Otázka | Doptejte se, pokud není jasná |
|---|--------|-------------------------------|
| DE-1 | Existuje centralizované logování pro kritické systémy? Kdo logy přezkoumává? | „Kam ukládáte logy ze serverů? Kdy se naposledy někdo díval do logů z jiného důvodu než kvůli incidentu?" |
| DE-2 | Existují automatizované alerty pro bezpečnostně relevantní události? | „Co by spustilo alert dnes v noci, kdyby se někdo pokoušel brutální silou napadnout váš admin účet ze zahraničí?" |
| DE-3 | Existuje monitoring neobvyklého chování uživatelů (přihlášení mimo pracovní dobu, velké exporty dat)? | „Věděli byste, kdyby zaměstnanec dnes v noci stáhl veškeré dokumenty z vašeho SharePointu?" |
| DE-4 | Jak jsou bezpečnostní alerty třídeny a eskalovány? Kdo je přijímá? | „Kdyby váš SIEM dnes v noci vygeneroval 100 alertů, kdo by je viděl? Zítra ráno? Nebo ihned?" |
| DE-5 | Byla testována účinnost detekčních kontrol? | „Kdy jste naposledy ověřili, že váš monitoring by skutečně něco zachytil?" |
**Klíčový poznatek k odkrytí**: Většina klientů má logy. Téměř nikdo je nečte. „Logujeme vše" a „detekujeme hrozby" jsou různé schopnosti.
---
### RS — RESPOND (Reakce)
*Rozvíjí a implementuje odpovídající aktivity pro přijetí opatření při zjištěné kybernetické bezpečnostní události.*
| # | Otázka | Doptejte se, pokud není jasná |
|---|--------|-------------------------------|
| RS-1 | Má organizace zdokumentovaný plán reakce na incidenty? | „Byl testován? Obsahuje kontaktní seznamy, rozhodovací stromy a komunikační šablony?" |
| RS-2 | Kdo odpovídá za vyhlášení incidentu a koordinaci reakce? | „Ve 2 hodiny ráno v sobotu, kdy se ransomware šíří sítí, kdo rozhodne o izolaci systémů?" |
| RS-3 | Má organizace záložní komunikační kanál pro reakci na incidenty? | „Když budou při incidentu nedostupné e-mail a Teams, jak budete komunikovat?" |
| RS-4 | Jsou předem identifikovány a nasmlouvány externí strany (právní poradenství, IR firma, pojišťovna, regulátor)? | „Máte vztah s cyber pojišťovnou? Retainer na incident response? Právního poradce obeznámeného s oznamováním narušení dat?" |
| RS-5 | Jak jsou zachycena a aplikována ponaučení z incidentů nebo téměř-miss situací? | „Dokážete uvést příklad procesu, který se změnil kvůli bezpečnostnímu incidentu za posledních dva roky?" |
**Klíčový poznatek k odkrytí**: Většina organizací má plán reakce na incidenty, který nebyl nikdy testován. Netestovaný plán není plán. Je to dokument. Otázka, kterou je třeba položit: „Kdy jste naposledy simulovali ransomwarový incident?"
---
### RC — RECOVER (Obnova)
*Rozvíjí a implementuje odpovídající aktivity pro udržení plánů odolnosti a obnovu schopností narušených kybernetickým bezpečnostním incidentem.*
| # | Otázka | Doptejte se, pokud není jasná |
|---|--------|-------------------------------|
| RC-1 | Zálohuje organizace své kritické systémy? Jak často? Jsou zálohy testovány? | „Kdy jste naposledy obnovili data ze zálohy? Ne zkopírovali — skutečně obnovili a ověřili, že to fungovalo?" |
| RC-2 | Jsou zálohy uloženy odděleně od primárních systémů (offline nebo neměnné)? | „Kdyby ransomware dnes v noci zašifroval vaše servery, mohl by se dostat také k zálohám?" |
| RC-3 | Jsou pro kritické systémy definovány cíle doby obnovy (RTO) a cíle bodu obnovy (RPO)? | „Jak dlouho by mohlo podnikání fungovat bez základního systému? Hodinu? Den? Týden?" |
| RC-4 | Jsou postupy obnovy zdokumentovány a známy osobám, které by je prováděly? | „Kdyby byl váš primární IT pracovník nedostupný při incidentu, dokázal by někdo jiný provést obnovu?" |
| RC-5 | Bylo provedeno úplné cvičení obnovy alespoň pro jeden kritický systém? | „Rekonstruovali jste někdy skutečně server ze zálohy v testovacím prostředí, abyste ověřili, že proces funguje?" |
**Klíčový poznatek k odkrytí**: Zálohy, které nebyly obnoveny, nejsou zálohy. Jsou to naděje. Nejčastějším zjištěním v této doméně je, že zálohy existují, ale nikdo neověřil, zda jsou konzistentní, úplné nebo obnovitelné ve stanoveném časovém rámci.
---
## Bodování a analýza mezer
Po dokončení všech domén sestavte skóre do souhrnné matice:
| Doména | Skóre | Kritické mezery (🔴) | Výrazné silné stránky (🟢) |
|--------|-------|---------------------|--------------------------|
| GOVERN | | | |
| IDENTIFY | | | |
| PROTECT | | | |
| DETECT | | | |
| RESPOND | | | |
| RECOVER | | | |
**Skóre domény**: počet 🟢 položek ÷ celkový počet položek. Není to přesná metrika — je to diskusní nástroj pro prioritizaci.
**Překryv s útočným řetězcem**: Po bodování položte ještě jednu otázku:
> *„Na základě toho, co jsme probrali, jaká je nejkratší cesta od ‚zatím se nic špatného nestalo' k ‚organizace nemůže fungovat'? Proveďte mě jí."*
Tím vznikne útočný řetězec. Moduly, které tento řetězec uzavírají, jsou prioritním doporučením.
---
## Struktura zprávy
Hodnocení produkuje dvoudílný výstup:
### Část 1: Zpráva o aktuálním stavu (doručena 5 pracovních dní po workshopu)
1. **Výkonné shrnutí** — jedna stránka; celková pozice, tři kritické mezery, tři klíčové silné stránky
2. **Zjištění k doménám** — pro každou doménu: aktuální stav, mezery v důkazech, klíčová rizika
3. **Analýza útočného řetězce** — nejkratší cesta k organizačnímu selhání na základě zjištění z workshopu
4. **Rychlá vítězství** — až 5 položek, které lze zlepšit za < 30 dní stávajícími nástroji a bez rozpočtu
### Část 2: Plán nápravy (součást části 1)
Mapuje zjištění přímo na antifragilní moduly:
| Priorita | Mezera | Modul | Odhadované úsilí |
|----------|--------|-------|-----------------|
| P0 (útočný řetězec) | [Zjištění] | [Modul č.] | [Délka] |
| P1 (kritické) | [Zjištění] | [Modul č.] | [Délka] |
| P2 (důležité) | [Zjištění] | [Modul č.] | [Délka] |
---
## Mapování na výběr modulu
| Typické zjištění hodnocení | Doporučený vstupní modul |
|---------------------------|-------------------------|
| Žádný inventář aktiv; neznámý útočný povrch | Modul 1 (Endpoint) + Modul 3 (M365 Hardening) |
| MFA nasazeno, ale nevynuceno; slabá identity hygiene | Modul 2 (Identity Security) |
| Žádné logování nebo alerty; „slepí" vůči útokům | Modul 3 (M365 Hardening) + Modul 12 (Blue/Purple Team) |
| Zálohy existují, ale netestovány; žádné cvičení obnovy | Modul 7 (Recovery & Resilience) |
| OT/IT síť bez segmentace; žádná kontrola přístupu dodavatelů | Modul 8 (OT Security) + Modul 13 (Privileged Access) |
| AD ve špatném stavu; zastaralé účty; žádná PAW | Modul 6 (On-Premise AD Hardening) |
| Žádný plán reakce na incidenty nebo krizová komunikace | Modul 14 (Sovereign Communications) + Modul 7 |
| Nástroje vlastněny, ale nepoužívány; týmy se necítí pod kontrolou | Modul 11 (Embedded Quality) |
| Dev a bezpečnost v silo; pomalé release cykly | Modul 9 (Organisational Resilience) |
| MSSP podvýkonný; žádná vlastní detekce | Modul 12 (Blue/Purple Team) |
---
## Cena a model angažmá
Toto hodnocení je **samostatné placené angažmá**, nikoli bezplatný scoping call.
**Typický rozsah**:
- Příprava před angažmá: 2 hodiny
- Dvě půldenní workshopová sezení: 8 hodin celkem
- Příprava zprávy: 4–8 hodin
- Prezentace zprávy a Q&A: 2 hodiny
- **Celkový čas konzultanta**: 16–20 hodin
**Co to produkuje**:
- Jasný, upřímný obraz toho, kde organizace stojí
- Doporučení modulů na základě důkazů (nikoli generická výzva „potřebujete více bezpečnosti")
- Prioritizovaný plán, na němž může klient jednat okamžitě — bez ohledu na to, zda pokračuje v angažmá
**Pitch**:
> *„Dříve než cokoliv doporučíme, chceme přesně pochopit, kde se nacházíte. Toto hodnocení trvá dva půldenní bloky a přináší upřímnou zprávu: vaše silné stránky, vaše mezery a tři věci, které je nejdůležitější napravit. Pokud po tomto doporučíme moduly, přesně pochopíte proč. Pokud se rozhodnete nepokračovat, stále máte plán, který můžete realizovat nezávisle. Oba výsledky jsou dobrý výsledek."*
---
## Integrace se stávajícími dokumenty
| Dokument | Integrace |
|----------|-----------|
| [NIST CSF 2.0 Mapping](../reference/nist-csf-mapping.md) | Toto hodnocení operacionalizuje mapování rámce — domény dotazníku se přímo mapují na referenci |
| [Modular Engagements](../core/modular-engagements.md) | Zjištění hodnocení řídí Diagnostic Path a výběr modulů |
| [Antifragile Risk Register](antifragile-risk-register.md) | Zjištění hodnocení naplňují počáteční registr rizik |
| [Rapid Modernisation Plan](../playbooks/rapid-modernisation-plan.md) | Výstupní kritéria fáze 1 (Hygiene) zrcadlí zjištění domén Identify a Protect |
| [Business Case Template](../playbooks/business-case-template.md) | Zjištění hodnocení poskytují vstup pro kvantifikaci rizik v business case |
---
*Pro referenci ke standardům viz [NIST CSF 2.0 Mapping](../reference/nist-csf-mapping.md).*
*Pro proces výběru modulů viz [Modular Engagements](../core/modular-engagements.md).*
*Pro šablonu registru rizik viz [Antifragile Risk Register](antifragile-risk-register.md).*
antifragile-consulting/assessment-templates/nist-csf-baseline.md
+262
View File
@@ -0,0 +1,262 @@
# NIST CSF 2.0 Baseline Assessment
> *"Most organisations do not know what they do not know. This workshop makes the unknown visible — in two half-days, without a single technical tool."*
## Purpose
This assessment is the **entry point before any module selection**. It answers the question every client needs answered before committing to a programme: *"Where are we actually, and what matters most to fix?"*
It is a structured workshop, not a technical audit. No tools are installed. No data is collected from systems. The output is a clear picture of the organisation's security posture across the six NIST CSF 2.0 functions, a strengths/gaps report, and a prioritised remediation roadmap that maps directly to the antifragile module menu.
**Duration**: Two half-days (4 hours each). In-person strongly preferred; remote with camera-on acceptable.
**Who attends**:
- CIO/CISO or equivalent (mandatory)
- IT manager / infrastructure lead (mandatory)
- One business process owner (finance, operations, or HR — whoever owns the most critical data)
- Optional: Legal/compliance, operations manager for OT environments
**Prerequisites**: None. This is the starting point.
---
## How to Run the Workshop
### Before the Workshop
Send the client a one-page prep note:
> *"We will spend two half-days together answering honest questions about how your organisation manages security today. There are no wrong answers. Our goal is to understand the reality of your current state — not what the policies say, not what you would like to be doing, but what actually happens. Please bring the people who know how things actually work."*
No homework, no questionnaire to fill in advance. Pre-filled questionnaires produce aspirational answers. The workshop produces honest ones.
### Session Structure
**Session 1 (Half-Day 1): Context and Foundation**
- 30 min — Introduction, ground rules, methodology overview
- 90 min — GOVERN domain (organisational context and risk management)
- 60 min — IDENTIFY domain (asset management and risk assessment)
- 20 min — Wrap, parking lot, preview of Session 2
**Session 2 (Half-Day 2): Controls, Detection, and Recovery**
- 30 min — Recap and open threads from Session 1
- 45 min — PROTECT domain (controls and safeguards)
- 45 min — DETECT domain (monitoring and anomaly detection)
- 30 min — RESPOND domain (incident management)
- 30 min — RECOVER domain (recovery and improvement)
- 20 min — Preliminary findings, next steps
---
## Domain Questionnaires
For each question, record:
- **Current state** (what actually happens)
- **Evidence** (what documentation or artefacts exist)
- **Score**: 🔴 Not present / 🟡 Partial or inconsistent / 🟢 Operational and effective
The score is a discussion tool, not an audit finding. Its purpose is to surface gaps, not to pass or fail the client.
---
### GV — GOVERN
*Identifies the processes, roles, and oversight structures that make security decisions and set direction.*
| # | Question | Probe If Unclear |
|---|----------|-----------------|
| GV-1 | Who in the organisation is ultimately accountable for cybersecurity? Do they have budget authority? | "If there were a breach tonight, who would make decisions about disclosure and remediation?" |
| GV-2 | Does the organisation have a documented cybersecurity policy? When was it last reviewed? | "Has anyone read it in the past 12 months? Does it reflect what you actually do?" |
| GV-3 | Is cybersecurity risk formally reported to the board or executive committee? How often? | "What does the board actually see? Risk ratings? Incident summaries? Nothing?" |
| GV-4 | Are security roles and responsibilities clearly assigned and understood by the people who hold them? | "If I asked your IT manager what their security responsibilities are, would their answer match your expectation?" |
| GV-5 | Does the organisation have a process for reviewing and approving new technology before deployment? | "How was your last major SaaS tool evaluated before procurement?" |
| GV-6 | Are third-party suppliers and vendors assessed for security risk? | "Do you know whether your critical suppliers have had breaches in the past year?" |
**Key insight to surface**: Most SMBs have "security responsibility" informally assigned to whoever manages IT. This is not the same as having an accountable executive. The gap is usually not technical — it is governance.
---
### ID — IDENTIFY
*Develops organisational understanding of assets, business context, resources, and capabilities to manage cybersecurity risk.*
| # | Question | Probe If Unclear |
|---|----------|-----------------|
| ID-1 | Does the organisation maintain an inventory of its hardware assets? Is it current? | "If I asked you right now how many laptops your company owns, could you tell me?" |
| ID-2 | Does the organisation maintain an inventory of software and SaaS services in use? | "Do you know which SaaS tools your employees are using with company data? Including the unofficial ones?" |
| ID-3 | Are the organisation's most critical business processes and the data they depend on documented? | "Which three systems, if unavailable for a week, would most threaten the business?" |
| ID-4 | Has a risk assessment been conducted in the past 12 months? | "Who conducted it? Was it technical-only, or did it include business process risk?" |
| ID-5 | Are data classification levels defined and applied to sensitive data? | "Do employees know which documents are confidential and what that means in practice?" |
| ID-6 | Does the organisation understand its external attack surface (public-facing services, domains, IP ranges)? | "Have you ever scanned your own organisation from the outside?" |
**Key insight to surface**: The gap between "we have an asset register" and "we have a current, accurate asset register that security decisions are based on" is almost always larger than the client expects.
---
### PR — PROTECT
*Develops and implements appropriate safeguards to ensure delivery of critical services.*
| # | Question | Probe If Unclear |
|---|----------|-----------------|
| PR-1 | Is multi-factor authentication enforced for all user accounts, including administrative accounts? | "Are there any exceptions? VPN access? Legacy applications? Shared accounts?" |
| PR-2 | How are privileged (administrative) accounts managed? Are they separate from daily-use accounts? | "Does your IT admin check email from the same account they use to manage servers?" |
| PR-3 | Are software updates and patches applied systematically across all devices? What is the typical lag? | "How long after Microsoft releases a critical patch do your endpoints typically receive it?" |
| PR-4 | Is sensitive data encrypted at rest and in transit? | "If a laptop were stolen tonight, could an attacker access the data on it?" |
| PR-5 | Is access to systems based on least privilege (minimum necessary access)? | "When a new employee joins, what do they get access to by default?" |
| PR-6 | Is there a security awareness training programme for all employees? When did the last session occur? | "If I phished your employees today, roughly what percentage would click the link?" |
| PR-7 | Are endpoint devices protected with up-to-date anti-malware/EDR? What is the coverage percentage? | "Are there devices — personal laptops, BYOD — that access company data without endpoint protection?" |
**Key insight to surface**: Most organisations have MFA deployed but not enforced. The distinction matters enormously — "deployed" means it exists; "enforced" means no one can bypass it.
---
### DE — DETECT
*Develops and implements appropriate activities to identify the occurrence of a cybersecurity event.*
| # | Question | Probe If Unclear |
|---|----------|-----------------|
| DE-1 | Is there centralised logging for critical systems? Who reviews the logs? | "Where do your server logs go? When was the last time someone looked at them for a non-incident reason?" |
| DE-2 | Are there automated alerts for security-relevant events? | "What would trigger an alert tonight if someone was trying to brute-force your admin account from a foreign country?" |
| DE-3 | Is there monitoring for unusual user behaviour (logins outside business hours, large data exports)? | "Would you know if an employee downloaded every document from your SharePoint tonight?" |
| DE-4 | How are security alerts triaged and escalated? Who receives them? | "If your SIEM generated 100 alerts tonight, who would see them? Tomorrow morning? Or immediately?" |
| DE-5 | Has the effectiveness of detection controls been tested? | "When did you last verify that your monitoring would actually catch something?" |
**Key insight to surface**: Most clients have logs. Almost none have someone reading them. "We log everything" and "we detect threats" are different capabilities.
---
### RS — RESPOND
*Develops and implements appropriate activities to take action regarding a detected cybersecurity incident.*
| # | Question | Probe If Unclear |
|---|----------|-----------------|
| RS-1 | Does the organisation have a documented incident response plan? | "Has it been tested? Does it include contact lists, decision trees, and communication templates?" |
| RS-2 | Who is responsible for declaring an incident and coordinating the response? | "At 2 AM on a Saturday, if ransomware is spreading through the network, who makes the call to isolate systems?" |
| RS-3 | Does the organisation have an out-of-band communication channel for incident response? | "If your email and Teams are down during an incident, how do you communicate?" |
| RS-4 | Are external parties (legal counsel, IR firm, insurer, regulator) pre-identified and contracted? | "Do you have a relationship with a cyber insurer? An incident response retainer? Legal counsel familiar with data breach notification?" |
| RS-5 | How are lessons from incidents or near-misses captured and acted on? | "Can you give an example of a process that changed because of a security incident in the last two years?" |
**Key insight to surface**: Most organisations have an incident response plan that has never been tested. An untested plan is not a plan. It is a document. The question to ask is: "When did you last pretend to have a ransomware incident?"
---
### RC — RECOVER
*Develops and implements appropriate activities to maintain plans for resilience and to restore any capabilities impaired by a cybersecurity incident.*
| # | Question | Probe If Unclear |
|---|----------|-----------------|
| RC-1 | Does the organisation back up its critical systems? How often? Are backups tested? | "When was the last time you restored from backup? Not copied — actually restored and verified it worked?" |
| RC-2 | Are backups stored separately from the primary systems (offline or immutable)? | "If ransomware encrypted your servers tonight, could it also reach your backups?" |
| RC-3 | Are recovery time objectives (RTOs) and recovery point objectives (RPOs) defined for critical systems? | "If your core system went down, how long could the business operate without it? An hour? A day? A week?" |
| RC-4 | Are recovery procedures documented and known to the people who would execute them? | "If your primary IT person were unavailable during an incident, could someone else execute the recovery?" |
| RC-5 | Has a full recovery drill been conducted for at least one critical system? | "Have you ever actually rebuilt a server from backup in a test environment to verify the process works?" |
**Key insight to surface**: Backups that have not been restored are not backups. They are hopes. The most common discovery in this domain is that backups exist, but no one has verified they are consistent, complete, or restorable in the required timeframe.
---
## Scoring and Gap Analysis
After completing all domains, compile the scores into a summary matrix:
| Domain | Score | Critical Gaps (🔴) | Notable Strengths (🟢) |
|--------|-------|-------------------|----------------------|
| GOVERN | | | |
| IDENTIFY | | | |
| PROTECT | | | |
| DETECT | | | |
| RESPOND | | | |
| RECOVER | | | |
**Domain score**: Count of 🟢 items ÷ total items. Not a precise metric — a discussion tool for prioritisation.
**The kill chain overlay**: After scoring, ask one more question:
> *"Based on what we have discussed, what is the shortest path from 'nothing bad has happened yet' to 'the organisation cannot operate'? Walk me through it."*
This produces the kill chain. The modules that close the kill chain are the priority recommendation.
---
## Report Structure
The assessment produces a two-part deliverable:
### Part 1: Current State Report (delivered 5 business days post-workshop)
1. **Executive Summary** — one page; overall posture, three critical gaps, three key strengths
2. **Domain Findings** — per domain: current state, evidence gaps, key risks
3. **Kill Chain Analysis** — the shortest path to organisational failure based on workshop findings
4. **Quick Wins** — up to 5 items that can be improved in < 30 days with existing tools and no budget
### Part 2: Remediation Roadmap (included with Part 1)
Maps findings directly to antifragile modules:
| Priority | Gap | Module | Estimated Effort |
|----------|-----|--------|-----------------|
| P0 (kill chain) | [Finding] | [Module #] | [Duration] |
| P1 (critical) | [Finding] | [Module #] | [Duration] |
| P2 (important) | [Finding] | [Module #] | [Duration] |
---
## Mapping to Module Selection
| Common Assessment Finding | Recommended Entry Module |
|--------------------------|-------------------------|
| No asset inventory; unknown attack surface | Module 1 (Endpoint) + Module 3 (M365 Hardening) |
| MFA deployed but not enforced; weak identity hygiene | Module 2 (Identity Security) |
| No logging or alerting; "blind" to attacks | Module 3 (M365 Hardening) + Module 12 (Blue/Purple Team) |
| Backups exist but untested; no recovery drill | Module 7 (Recovery & Resilience) |
| OT/IT network not segmented; no vendor access control | Module 8 (OT Security) + Module 13 (Privileged Access) |
| AD in poor health; stale accounts; no PAW | Module 6 (On-Premise AD Hardening) |
| No incident response plan or crisis comms | Module 14 (Sovereign Communications) + Module 7 |
| Tools owned but not used; teams feel out of control | Module 11 (Embedded Quality) |
| Dev and security siloed; slow release cycles | Module 9 (Organisational Resilience) |
| MSSP underperforms; no custom detection | Module 12 (Blue/Purple Team) |
---
## Pricing and Engagement Model
This assessment is a **standalone paid engagement**, not a free scoping call.
**Typical scope**:
- Pre-engagement preparation: 2 hours
- Two half-day workshop sessions: 8 hours total
- Report preparation: 4–8 hours
- Report presentation and Q&A: 2 hours
- **Total consultant time**: 16–20 hours
**What it produces**:
- A clear, honest picture of where the organisation stands
- An evidence-based module recommendation (not a generic "you need more security" pitch)
- A prioritised roadmap the client can act on immediately, with or without engaging further
**The pitch**:
> *"Before we recommend anything, we want to understand exactly where you are. This assessment takes two half-days and produces an honest report: your strengths, your gaps, and the three things that matter most to fix. If we recommend modules after this, you will understand exactly why. If you decide not to proceed, you still have a roadmap you can execute independently. Either outcome is a good outcome."*
---
## Integration With Existing Frameworks
| Document | Integration |
|----------|-------------|
| [NIST CSF 2.0 Mapping](../reference/nist-csf-mapping.md) | This assessment operationalises the framework mapping — the questionnaire domains map directly to the reference |
| [Modular Engagements](../core/modular-engagements.md) | Assessment findings drive the Diagnostic Path and module selection |
| [Antifragile Risk Register](antifragile-risk-register.md) | Assessment findings populate the initial risk register |
| [Rapid Modernisation Plan](../playbooks/rapid-modernisation-plan.md) | Phase 1 (Hygiene) exit criteria mirror the Identify and Protect domain findings |
| [Business Case Template](../playbooks/business-case-template.md) | Assessment findings provide the risk quantification input for the business case |
---
*For the standards reference, see [NIST CSF 2.0 Mapping](../reference/nist-csf-mapping.md).*
*For the module selection process, see [Modular Engagements](../core/modular-engagements.md).*
*For the risk register template, see [Antifragile Risk Register](antifragile-risk-register.md).*
*Česká verze (pro workshopy vedené v češtině): [Základní hodnocení NIST CSF 2.0](nist-csf-baseline-cs.md)*
antifragile-consulting/assessment-templates/risk-register-example.md
+246
View File
@@ -0,0 +1,246 @@
# Risk Register — Worked Example
> *This document shows what a fully populated risk register looks like after a Brownhat Diagnostic. It is a teaching example, not a real client record. Use it to calibrate the level of specificity expected in each field and to understand how the antifragile dimensions are applied in practice.*
>
> *Fictional scenario: Meridian Logistics GmbH — 280 employees, hybrid AD + M365 E3, one warehouse with OT/IT overlap, outsourced MSSP with no custom detection. Brownhat Diagnostic completed 14 March 2025.*
---
```
Organisation: Meridian Logistics GmbH [EXAMPLE — NOT A REAL CLIENT]
Assessment date: 14 March 2025
Assessor: T. Kracmar, CQRE
Review cadence: Monthly (tactical) / Quarterly (strategic)
Next review: 14 April 2025
```
---
## Risk Entries
---
### AF-2025-001 · Domain Admin accounts used for daily work
| Field | Value |
|-------|-------|
| **Risk name** | Domain Admin accounts used for daily computing |
| **Description** | All four Domain Admin accounts are also the accounts these admins use for email, browsing, and daily work. A phishing email to any one of them, or a drive-by browser exploit, directly yields Domain Admin credentials. No additional lateral movement required. |
| **Tier** | T0 |
| **Kill chain** | Phishing email → credential harvest → immediate DA access → Golden Ticket or DCSync → all AD-joined systems compromised → ransomware or data exfiltration within 2 hours |
| **Shortest path to failure** | 2 steps |
| **Probability** | 4 — High. Admin accounts are the most-targeted accounts in any environment; phishing success rates on unprotected accounts exceed 20%. |
| **Impact** | 5 — Existential. Full domain compromise. |
| **Traditional risk score** | 20 — P0 |
| **Optionality impact** | Extreme. Once the domain is compromised, the organisation cannot safely use any AD-joined system. Cloud migration becomes impossible until full recovery. |
| **Convexity** | Extreme. Creating separate admin accounts and deploying PAWs costs 2 consultant days. Domain recovery from a Golden Ticket attack takes 2–6 weeks and costs €200K–€800K. |
| **Current control** | Password policy (12 characters minimum). No MFA on admin accounts. No PAWs. No PIM. |
| **Antifragile move** | 1. Create separate, non-mail-enabled admin accounts for all four admins. 2. Disable mail access on admin accounts via Conditional Access or AD attribute. 3. Procure or designate PAWs (locked-down workstations used only for admin tasks). 4. Enforce MFA on all admin accounts via Conditional Access. 5. Begin PIM rollout (Module 2). |
| **Owner** | IT Manager |
| **Target date** | 28 March 2025 (14 days) |
| **Status** | Open |
| **Stress-to-signal mandate** | If this risk materialises: all admin activity permanently migrated to PAWs; quarterly access review for all privileged accounts institutionalised; admin account count reduced to minimum viable and documented. |
| **Verification method** | Conditional Access sign-in logs show zero interactive logins from admin accounts to email or general applications. BloodHound re-run confirms no DA accounts have interactive sessions on non-PAW workstations. |
---
### AF-2025-002 · Compromised password hashes in AD
| Field | Value |
|-------|-------|
| **Risk name** | Domain accounts with known-compromised or dictionary passwords |
| **Description** | Elysium password audit (run 14 March 2025) identified 34 domain accounts whose password hashes match the known-compromised hash database. Of these, 3 are service accounts with elevated permissions, and 1 is a member of the IT Managers group. Password spray tools would crack these accounts in minutes without triggering lockout policies on the first attempt. |
| **Tier** | T0 |
| **Kill chain** | Password spray (external or internal) → service account compromise → lateral movement via permissions → domain escalation |
| **Shortest path to failure** | 3 steps (via the IT Managers account) |
| **Probability** | 5 — Very High. Password spray attacks are fully automated and run continuously against externally-visible authentication endpoints. |
| **Impact** | 5 — Existential via the privileged account paths |
| **Traditional risk score** | 25 — P0 |
| **Optionality impact** | High. Compromised service accounts may have embedded credentials in scripts, pipelines, and third-party integrations — full remediation requires inventory of all places these accounts are referenced. |
| **Convexity** | Extreme. Forcing password resets costs 0 budget. A service account used to pivot to domain takes weeks to eradicate. |
| **Current control** | Password policy (12 chars minimum). No check against known-compromised hashes at set time. No monitoring of service account logins. |
| **Antifragile move** | 1. Immediate: force password reset on all 34 identified accounts. 2. For the 3 privileged service accounts: rotate and vault in PAM (or temporary password manager). 3. Audit all scripts and pipelines referencing these accounts before rotation to prevent service disruption. 4. Deploy Elysium on quarterly cadence as part of retained capability. 5. Implement EntraID Password Protection (ban known-weak passwords at set time). |
| **Owner** | IT Manager |
| **Target date** | 21 March 2025 (7 days — immediate) |
| **Status** | Open |
| **Stress-to-signal mandate** | If any of these accounts are confirmed compromised: mandatory incident response; all service account credentials reviewed and rotated; password hygiene tool (Elysium or equivalent) deployed permanently on quarterly cadence. |
| **Verification method** | Elysium re-run shows 0 accounts matching compromised hash database. Service account credential inventory documented and stored in PAM or password manager. |
---
### AF-2025-003 · Backups never restored — recoverability unknown
| Field | Value |
|-------|-------|
| **Risk name** | Backup existence confirmed; restorability unverified |
| **Description** | Veeam is deployed and running nightly jobs. The last documented restore test was performed during initial deployment 3 years ago. No restore has been attempted since. File server backups are confirmed; AD backup and Exchange/M365 data backup are unverified. RPO and RTO have never been formally defined. |
| **Tier** | T0 |
| **Kill chain** | Ransomware encrypts primary systems → recovery required from backup → backup restore fails or takes 3× expected time → extended downtime → operational failure |
| **Shortest path to failure** | 1 step (backup failure in a ransomware scenario) |
| **Probability** | 3 — Moderate. Backup corruption or misconfiguration is common; ransomware targeting the backup server is increasingly common. |
| **Impact** | 5 — Existential. If backups fail during a ransomware recovery, the organisation faces permanent data loss or payment of ransom with no guarantee of decryption. |
| **Traditional risk score** | 15 — P1 |
| **Optionality impact** | Extreme. Without verified backups, the organisation has no option during a ransomware incident except payment or loss. Verified backups create the option to refuse payment. |
| **Convexity** | Extreme. Scheduling one recovery drill costs 4 hours of IT time. A ransomware incident without working backups costs €500K–€2M+ and may not be survivable. |
| **Current control** | Veeam running nightly backups. No restore tests. No immutable or offline copy confirmed. No defined RPO/RTO. |
| **Antifragile move** | 1. Immediate: schedule a restore test for one critical system (file server or AD) within 7 days. Document the result. 2. Define RPO/RTO for top 3 critical systems. 3. Confirm whether backups are air-gapped or immutable (ransomware-resistant). If not, configure Veeam immutable backup or add an offline copy. 4. Test AD backup specifically — AD restore is distinct from file restore and frequently untested. 5. Schedule quarterly restore drills as a standing calendar item. |
| **Owner** | IT Manager |
| **Target date** | 28 March 2025 (P1 — within 30 days; first restore test within 7 days) |
| **Status** | Open |
| **Stress-to-signal mandate** | If a ransomware incident occurs before this is resolved: mandatory post-incident review of backup architecture; immutable copy deployed before resuming operations; quarterly restore drills mandated as board-visible KPI. |
| **Verification method** | Documented restore test with timestamped results showing successful restore within defined RTO. Immutable backup copy confirmed in Veeam console. RPO/RTO defined and signed off by executive sponsor. |
---
### AF-2025-004 · KRBTGT password not rotated in 843 days
| Field | Value |
|-------|-------|
| **Risk name** | Stale KRBTGT password — Golden Ticket persistence window |
| **Description** | The KRBTGT account password has not been rotated in 843 days. Any attacker who has previously compromised the domain and extracted the KRBTGT hash holds a Golden Ticket valid until the password is rotated — twice, 10 hours apart. This means a past compromise may still be actively exploitable. |
| **Tier** | T1 |
| **Kill chain** | Previous domain compromise (unknown) → persistent Golden Ticket → reactivated domain access → any impact |
| **Shortest path to failure** | 1 step (if previous compromise occurred) |
| **Probability** | 2 — Unknown but non-trivial. Cannot rule out a previous compromise that was not detected. |
| **Impact** | 5 — Existential if previous compromise occurred |
| **Traditional risk score** | 10 — P2 (elevated to P1 due to optionality impact) |
| **Optionality impact** | High. Until rotated, a potential past attacker retains the option to re-enter the domain at will. Rotation removes that option permanently. |
| **Convexity** | High. KRBTGT rotation is a 30-minute procedure. The cost of a persistent Golden Ticket being exploited is existential. |
| **Current control** | None. No rotation policy or cadence. |
| **Antifragile move** | 1. Rotate KRBTGT password twice (10 hours apart) during a scheduled maintenance window. 2. Establish a 180-day rotation cadence, calendar-blocked and IT-manager-owned. 3. After rotation, run a BloodHound collection to confirm no anomalous Kerberos ticket activity. |
| **Owner** | IT Manager |
| **Target date** | 11 April 2025 (P1 — within 30 days; maintenance window to be scheduled) |
| **Status** | Open |
| **Stress-to-signal mandate** | If Golden Ticket evidence is discovered: mandatory full incident response; KRBTGT rotation immediately; assume full domain compromise until proven otherwise. |
| **Verification method** | KRBTGT password last-set date in AD is < 30 days post-engagement. Rotation event in AD audit log. Next rotation date calendar-blocked. |
---
### AF-2025-005 · No out-of-band communication channel
| Field | Value |
|-------|-------|
| **Risk name** | Incident response communication depends on corporate infrastructure |
| **Description** | The organisation's incident response relies on Teams and corporate email. Both depend on Microsoft 365, Active Directory, and internet connectivity. In a ransomware scenario where AD is compromised or M365 is unavailable, the incident response team has no pre-established way to communicate securely. There is no out-of-band channel, no enrolled participants on alternative infrastructure, and no documented alternative. |
| **Tier** | T1 |
| **Kill chain** | Ransomware or credential compromise → Teams/email unavailable → IR team cannot coordinate → recovery time extends → operational damage increases |
| **Shortest path to failure** | 2 steps |
| **Probability** | 3 — Moderate. Ransomware attacks that target AD (the most common variant) will likely impact Teams and email. |
| **Impact** | 3 — Significant. Does not cause failure directly but extends recovery time and increases costs materially. |
| **Traditional risk score** | 9 — P3 (elevated to P1 due to convexity and the active risk from AF-2025-001) |
| **Optionality impact** | Moderate. Without out-of-band comms, the organisation has no options for coordinated response when primary channels fail. |
| **Convexity** | Extreme. Deploying a Delta Chat chatmail relay costs €7/month and 30 minutes of setup. Lack of communication during an active incident is immeasurable in cost. |
| **Current control** | Personal mobile numbers exist for key staff. No structured channel, no encryption, no pre-enrolled participants. |
| **Antifragile move** | 1. Deploy a Delta Chat chatmail relay on an independent VPS (outside corporate network, outside M365). 2. Enrol: IT Manager, CISO/executive sponsor, all admins, CQRE consultant lead. 3. Document the channel in the incident response runbook as the primary IR communication method. 4. Test the channel monthly with a brief message — confirm all participants can receive. |
| **Owner** | IT Manager |
| **Target date** | 21 March 2025 (very low effort — do this in the first week) |
| **Status** | Open |
| **Stress-to-signal mandate** | If an incident occurs without out-of-band comms: the channel is deployed as the first post-incident action before anything else. |
| **Verification method** | Delta Chat relay deployed. All named participants enrolled and confirmed reachable. Channel documented in IR runbook. Monthly test message logged. |
---
### AF-2025-006 · M365 audit log retention at 90 days
| Field | Value |
|-------|-------|
| **Risk name** | Unified Audit Log retention insufficient for investigation and compliance |
| **Description** | The M365 Unified Audit Log is retained for 90 days (E3 default). Security investigations frequently require logs older than 90 days — breach discovery typically occurs 197 days after initial access (IBM Cost of Data Breach average). An incident discovered today may require logs from 6 months ago for attribution and scope assessment. Regulatory requirements (DORA, NIS2) expect logs sufficient to reconstruct incidents. |
| **Tier** | T1 |
| **Kill chain** | Breach occurs → discovered 197 days later → investigation requires logs → logs deleted at 90 days → incident scope and attribution impossible → regulatory non-compliance |
| **Shortest path to failure** | 1 step (breach + 90-day gap = irretrievable evidence) |
| **Probability** | 3 — Moderate. Breaches occurring in the 90-day window where logs would be needed are not unlikely given the average discovery gap. |
| **Impact** | 3 — Significant. Primarily a compliance and investigation impact rather than operational failure. |
| **Traditional risk score** | 9 — P3 (elevated to P2 due to regulatory exposure) |
| **Optionality impact** | Moderate. Once logs are deleted, the option to investigate and prove scope is permanently lost. |
| **Convexity** | High. Extending retention to 180 days requires E3 Compliance Add-on (≈€8/user/month) or ingestion into a long-term log store (AOC + blob storage). Cost vs. cost of regulatory non-compliance is asymmetric. |
| **Current control** | M365 Unified Audit Log at 90-day default. No secondary storage. AOC not yet deployed. |
| **Antifragile move** | 1. Deploy AOC to ingest and persist audit logs beyond the 90-day window into the organisation's own infrastructure (MongoDB + blob storage). 2. Alternatively, evaluate E3 Compliance Add-on for extended Microsoft-native retention. 3. Document retention policy and verify it meets applicable regulatory requirements (NIS2 Article 21 recommends 12+ months). |
| **Owner** | CISO / IT Manager |
| **Target date** | 30 April 2025 (P2 — within 90 days) |
| **Status** | Open |
| **Stress-to-signal mandate** | If an incident reveals log gaps: AOC deployed immediately post-incident; retention policy reviewed and extended to regulatory minimum; board notified of compliance gap. |
| **Verification method** | AOC deployed with log ingestion confirmed. Oldest ingested log age exceeds 180 days within 6 months of deployment. Retention policy documented and signed off. |
---
### AF-2025-007 · MSSP running generic rules — no custom detection
| Field | Value |
|-------|-------|
| **Risk name** | Outsourced SOC with no environment-specific detection |
| **Description** | The organisation pays a managed SOC provider €8,500/month. The MSSP deploys its standard detection ruleset — tuned for its entire client base, not for Meridian's specific environment, architecture, or threat model. No custom rules have been written for Meridian-specific risks: the OT/IT boundary, service account behaviour baselines, or logistics-industry TTPs. An assessment of 5 common TTPs showed the MSSP would detect 2 of 5. |
| **Tier** | T2 |
| **Kill chain** | Targeted attacker uses logistics-industry TTP → MSSP generic rules do not fire → attacker operates undetected for days/weeks → damage occurs |
| **Shortest path to failure** | 3–5 steps (attacker must complete multiple phases undetected) |
| **Probability** | 3 — Moderate. Generic rules are well-documented to miss targeted attacks; logistics is an increasingly targeted sector. |
| **Impact** | 4 — Major. Extended dwell time dramatically increases breach cost and scope. |
| **Traditional risk score** | 12 — P2 |
| **Optionality impact** | Moderate. Without detection, the organisation cannot exercise the option to contain and eject an attacker early. |
| **Convexity** | High. Building a detection engineering cell (1 FTE equivalent) costs ≈€150K/year and makes the €102K/year MSSP investment 3× more effective. |
| **Current control** | MSSP with generic ruleset. AOC not deployed. No custom detection rules. MSSP SLA measures ticket response time, not detection coverage. |
| **Antifragile move** | 1. Conduct a purple team TTP coverage test against the MSSP (5 TTPs, as described in the Retained Capability document). 2. Deploy AOC to add M365-specific detection on top of the MSSP. 3. Write 3–5 custom detection rules for the highest-priority Meridian-specific TTPs (OT/IT boundary crossing, service account anomalies, large SharePoint exports). 4. Add detection coverage rate to the MSSP SLA. 5. Consider a retained capability arrangement to maintain and extend the custom ruleset. |
| **Owner** | IT Manager / outsourced CISO |
| **Target date** | 30 June 2025 (P2 — within 90 days to start; sustained programme) |
| **Status** | Open |
| **Stress-to-signal mandate** | If an attacker achieves extended dwell time undetected: MSSP relationship reviewed and re-contracted with detection coverage metrics; retained detection engineering capability established immediately. |
| **Verification method** | Purple team test result: MSSP detects ≥4 of 5 tested TTPs with custom rules deployed. Detection coverage rate added to monthly MSSP reporting. |
---
### AF-2025-008 · Service account passwords not rotated
| Field | Value |
|-------|-------|
| **Risk name** | Service accounts with non-expiring passwords and no rotation policy |
| **Description** | 18 service accounts have password-never-expires set. 11 of these have not had passwords changed in over 2 years; 3 have not been changed since account creation (the oldest is 6 years old). Service account credentials are stored in a shared Excel spreadsheet accessible to 4 IT staff. Any of the 4 staff members (including 2 who have since left) could have exfiltrated these credentials. |
| **Tier** | T2 |
| **Kill chain** | Former employee with exfiltrated service account credentials → authentication from external location → exploitation of account permissions → persistence |
| **Shortest path to failure** | 2 steps |
| **Probability** | 2 — Low-moderate. No evidence of compromise, but credential exposure via the spreadsheet means the attack surface is wider than known. |
| **Impact** | 3 — Significant. Depends on the permissions of the specific service accounts accessed. |
| **Traditional risk score** | 6 — P3 (elevated to P2 due to optionality and the spreadsheet exposure) |
| **Optionality impact** | Moderate. Exposed credentials that cannot be tracked mean the organisation cannot confidently assert that no compromise has occurred or will occur. |
| **Convexity** | High. Rotating 18 passwords and vaulting them costs 1 day of IT work. A service account used to establish persistence is weeks of incident response. |
| **Current control** | Password-never-expires set. Credentials in Excel spreadsheet. No PAM solution. No audit trail for service account access. |
| **Antifragile move** | 1. Immediate: identify the 3 accounts used by departed staff and rotate passwords. 2. Within 30 days: rotate all 18 service account passwords. Vault new passwords in a password manager (minimum) or PAM solution (preferred). 3. Remove the Excel spreadsheet. 4. Enable service account login auditing in AD. 5. For Module 13 (Privileged Access), migrate service accounts into Teleport or equivalent for session recording. |
| **Owner** | IT Manager |
| **Target date** | Immediate rotation of departed-staff accounts: 17 March 2025. All accounts: 11 April 2025. |
| **Status** | Open |
| **Stress-to-signal mandate** | If a service account is confirmed compromised: all service account credentials rotated immediately; PAM solution deployed before credentials are restored to operation; Excel credential store permanently prohibited. |
| **Verification method** | All service account passwords rotated (AD last-password-set date confirms). Excel file deleted and confirmed removed from all backup copies. Credentials in password manager or PAM. Audit logging enabled and confirmed on all service accounts. |
---
## Summary Dashboard
| Risk ID | Name | Tier | P | I | Score | Priority | Owner | Due | Status |
|---------|------|------|---|---|-------|----------|-------|-----|--------|
| AF-2025-001 | DA accounts used daily | T0 | 4 | 5 | 20 | **P0** | IT Mgr | 28 Mar | Open |
| AF-2025-002 | Compromised password hashes | T0 | 5 | 5 | 25 | **P0** | IT Mgr | 21 Mar | Open |
| AF-2025-003 | Backups unverified | T0 | 3 | 5 | 15 | **P1** | IT Mgr | 28 Mar | Open |
| AF-2025-004 | KRBTGT 843 days stale | T1 | 2 | 5 | 10 | P1* | IT Mgr | 11 Apr | Open |
| AF-2025-005 | No out-of-band channel | T1 | 3 | 3 | 9 | P1* | IT Mgr | 21 Mar | Open |
| AF-2025-006 | Audit log 90-day retention | T1 | 3 | 3 | 9 | P2 | CISO | 30 Apr | Open |
| AF-2025-007 | MSSP generic rules only | T2 | 3 | 4 | 12 | P2 | IT Mgr | 30 Jun | Open |
| AF-2025-008 | Service account passwords | T2 | 2 | 3 | 6 | P2 | IT Mgr | 11 Apr | Open |
*\* Elevated from traditional score based on convexity and optionality impact.*
**Kill chain summary**: The shortest path to organisational failure runs through AF-2025-001 (DA account compromise) and AF-2025-002 (compromised hashes). These two risks, combined, mean an attacker with a phishing kit and a password spray tool can achieve full domain compromise in under an hour. They must be closed before anything else.
---
## Integration With Existing Frameworks
| Document | Integration |
|----------|-------------|
| [Antifragile Risk Register](antifragile-risk-register.md) | The template used to produce these entries — see for field definitions and scoring methodology |
| [Module Completion Report](module-completion-report.md) | The "risk register update" section of each completion report feeds entries into this format |
| [NIST CSF 2.0 Baseline Assessment](nist-csf-baseline.md) | The Brownhat Diagnostic produces the initial risk list that populates this register |
| [Retained Capability](../core/retained-capability.md) | AF-2025-007 (MSSP generic rules) maps directly to the detection engineering gap described there |
---
*For the risk register template and scoring methodology, see [Antifragile Risk Register](antifragile-risk-register.md).*
*For the module completion report that generates risk register updates, see [Module Completion Report](module-completion-report.md).*