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
.gitignore
+17
View File
@@ -0,0 +1,17 @@
# Office documents — presentations and working files that aren't part of the repo
*.pptx
*.ppt
*.docx
*.doc
*.xlsx
*.xls
# macOS metadata
.DS_Store
**/.DS_Store
# Editor artifacts
.vscode/
*.swp
*.swo
*~
antifragile-consulting/README.md
+34 -12
View File
@@ -17,7 +17,11 @@ Most security and resilience frameworks optimize for **robustness**—the abilit
```
├── core/ # Foundational frameworks and principles
│ ├── move-fast-and-fix-things.md # Company philosophy: speed, repair, existing tools
│ ├── about-cqre.md # Company overview template — fill before sharing with clients
│ ├── about-cqre-cs.md # Czech version of company overview (O společnosti CQRE)
│ ├── move-fast-and-fix-things.md # Company philosophy: speed, repair, existing tools (Brownhat brand)
│ ├── engagement-model.md # How engagements work: lifecycle, deliverables, pricing, consultant discipline
│ ├── consultant-field-guide.md # Internal playbook: decision models, qualification, mistakes, technical onboarding
│ ├── antifragile-manifest.md # The five pillars of antifragile enterprise
│ ├── modular-engagements.md # Menu of independent, self-contained modules
│ ├── ai-sovereignty-framework.md # AI sovereignty as a strategic mandate
@@ -28,6 +32,7 @@ Most security and resilience frameworks optimize for **robustness**—the abilit
│ ├── blue-purple-team-foundation.md # Building defensive capability from existing tools
│ ├── retained-capability.md # What to keep in-house when outsourcing security (MSSP, pentest, compliance)
│ ├── executive-summary.md # One-page board brief
│ ├── executive-summary-cs.md # Czech version of board brief (Výkonné shrnutí)
│ ├── c-suite-conversation-guide.md # Persuasion scripts for top management
│ └── t0-asset-framework.md # Tier 0 asset classification and protection
├── playbooks/ # Executable modernisation and response plans
@@ -42,10 +47,16 @@ Most security and resilience frameworks optimize for **robustness**—the abilit
│ ├── ad-endpoint-hardening.md # On-prem AD, Windows endpoint, hybrid identity
│ ├── zero-budget-hardening.md # Maximize existing tool investment
│ ├── implementation-playbook.md # Step-by-step operational guide
│ └── business-case-template.md # Financial justification and ROI framework
│ ├── sovereign-tool-stack.md # Open-source arsenal and capability map
│ ├── sovereign-tool-stack.md # Open-source arsenal and capability map
│ ├── privileged-access-architecture.md # PAM: Teleport, Tailscale/Headscale, JIT access (Module 13)
│ ├── sovereign-communications.md # Delta Chat chatmail, Matrix/Element, crisis channels (Module 14)
│ └── business-case-template.md # Financial justification and ROI framework
├── assessment-templates/ # Diagnostic tools and maturity models
│ ├── README.md # Assessment roadmap and development plan
│ ├── nist-csf-baseline.md # The Brownhat Diagnostic: 2-half-day NIST CSF workshop (entry engagement)
│ ├── nist-csf-baseline-cs.md # Czech version of Brownhat Diagnostic workshop questionnaire
│ ├── module-completion-report.md # Template for the module completion package (every module)
│ ├── risk-register-example.md # 8 fully populated risk entries from a realistic engagement
│ ├── antifragile-risk-register.md # Antifragile risk taxonomy and register template
│ └── m365-project-risk-register.md # M365 project-specific risk register
├── reference/ # External standards, mappings, and citations
@@ -88,17 +99,28 @@ Our approach is not an alternative to established frameworks. It is the fastest
2. **Review** [Business Case Template](playbooks/business-case-template.md) — financial justification, ROI, and risk quantification
3. **Browse** [C-Suite Conversation Guide](core/c-suite-conversation-guide.md) — how your advisors should frame the conversation
## Platform Independence
This framework is **platform-agnostic at the strategic level**. The Antifragile Manifest, assessment methodology, and Sovereign Tool Stack operate independently of any vendor ecosystem.
Many playbooks use Microsoft 365 as the reference environment because it is the most common client footprint (E3/Business Premium). Consultants working with Google Workspace, AWS-native, or mixed environments should read the **Platform Adaptation** appendix in [Modular Engagements](core/modular-engagements.md#platform-adaptation-non-microsoft-environments), which maps every M365-specific module to equivalent non-Microsoft tooling.
## Quick Start for Consultants
1. **Open** `core/move-fast-and-fix-things.md` — understand the engagement posture
2. **Read** `core/antifragile-manifest.md` — understand the philosophy
3. **Study** `playbooks/m365-e3-hardening.md` — master the primary client environment (most clients are E3)
4. **Study** `playbooks/ad-endpoint-hardening.md` — cover on-premises AD and endpoint gaps
5. **Study** `playbooks/zero-budget-hardening.md` — extract value from existing tools in 30 days
6. **Deploy** `playbooks/rapid-modernisation-plan.md` — run the 30-60-90-180 day roadmap
7. **Reference** `core/t0-asset-framework.md` and `core/ai-sovereignty-framework.md` — classify assets and own intelligence
8. **Map** `reference/cis-controls-mapping.md` and `reference/nist-csf-mapping.md` — align to standards
9. **Adapt** `reference/vertical-power-utilities.md`, `reference/vertical-telco.md`, or `reference/vertical-banking.md` — tailor for regulated critical infrastructure clients
1. **Open** `core/move-fast-and-fix-things.md` — understand the engagement posture and the Brownhat brand
2. **Read** `core/engagement-model.md` — understand how engagements are structured, scoped, priced, and delivered
3. **Read** `core/consultant-field-guide.md` — internalize the decision models, learn to qualify clients, understand the common mistakes
4. **Read** `core/antifragile-manifest.md` — understand the philosophy
4. **Study** `core/modular-engagements.md` — the full module menu (Modules 1–14) and platform adaptation guide
5. **Run** `assessment-templates/nist-csf-baseline.md` — the Brownhat Diagnostic: mandatory entry engagement for every new client
6. **Study** `playbooks/sovereign-tool-stack.md` — the full tool arsenal, commercial partnerships, and when to use each
7. **Study** `playbooks/m365-e3-hardening.md` — primary client environment for MS clients (most are E3)
8. **Study** `playbooks/ad-endpoint-hardening.md` — on-premises AD and endpoint gaps
9. **Study** `playbooks/zero-budget-hardening.md` — extract value from existing tools in 30 days
10. **Deploy** `playbooks/rapid-modernisation-plan.md` — run the 30-60-90-180 day roadmap
11. **Reference** `core/t0-asset-framework.md` and `core/ai-sovereignty-framework.md` — classify assets and own intelligence
12. **Map** `reference/cis-controls-mapping.md` and `reference/nist-csf-mapping.md` — align to standards
13. **Adapt** `reference/vertical-power-utilities.md`, `reference/vertical-telco.md`, or `reference/vertical-banking.md` — tailor for regulated critical infrastructure clients
## Usage and Licensing
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).*
antifragile-consulting/assets/README.md
+30
View File
@@ -0,0 +1,30 @@
# Assets
This directory holds diagrams, visual frameworks, and presentation materials used in client engagements and internal documentation.
## Planned Assets
| Asset | Purpose | Status |
|-------|---------|--------|
| Antifragile Manifest — one-page visual | Board-ready illustration of the five pillars | Planned |
| Module Stacking Paths — flowchart | Visual representation of Paths A–F | Planned |
| Sovereign Tool Stack — architecture diagram | Layered view of the tool stack and data flows | Planned |
| 180-Day Roadmap — Gantt-style overview | Phase gates and milestone summary for client kickoff decks | Planned |
| Kill Chain → Module Mapping | Decision tree for module selection from kill chain analysis | Planned |
## Naming Convention
Files in this directory should follow:
```
[type]-[subject]-[version].[ext]
```
Examples:
- `diagram-sovereign-stack-v1.png`
- `slide-five-pillars-v2.pdf`
- `template-module-sow-v1.docx`
---
*Return to [Repository Index](../index.md)*
antifragile-consulting/core/about-cqre-cs.md
+228
View File
@@ -0,0 +1,228 @@
# O společnosti CQRE · Brownhat
> *Tato stránka představuje CQRE a metodiku Brownhat novým klientům a novým členům týmu. Vyplňte každou sekci označenou `[PLACEHOLDER]` konkrétními, pravdivými informacemi. Vyhýbejte se obecnému konzultantskému jazyku — klienti to poznají. Sekce označené **INTERNÍ POZNÁMKA** obsahují pokyny pro doplnění šablony; před sdílením navenek je odstraňte.*
>
> *Anglická verze tohoto dokumentu je k dispozici zde: [About CQRE](about-cqre.md).*
---
## Kdo jsme
**CQRE.NET Ltd** je specializovaná konzultační společnost v oblasti kybernetické bezpečnosti registrovaná v [PLACEHOLDER: Velká Británie / Edinburgh]. Primárně působíme z [PLACEHOLDER: Praha, Česká republika] a pracujeme s klienty po celé [PLACEHOLDER: střední Evropě, Velké Británii a západní Evropě].
> **INTERNÍ POZNÁMKA** — Doporučené zpracování: omezte tento odstavec na 3–5 vět. Uveďte rok založení, geografické zaměření a rozsah klientů (odvětví, velikosti). Neslibujte schopnosti, které momentálně nemůžete poskytnout. Příklad: *„CQRE.NET Ltd byla založena v [roce] [jménem] s cílem poskytovat poctivé, metodologicky řízené poradenství v oblasti bezpečnosti organizacím, které přerostly generické rady. Pracujeme primárně se středně velkými společnostmi, telekomunikačními operátory a energetickými podniky ve střední Evropě — organizacemi se skutečnými prostředími, stávajícími investicemi a konkrétními hrozbami, na které generické rámce nestačí."*
[PLACEHOLDER: popis společnosti v 3–5 větách]
Vůči klientům vystupujeme pod značkou **Brownhat** — název odráží naši základní filozofii: pracujeme v brownfield prostředích (zavedených, obydlených, nesoucích tíhu minulých rozhodnutí) a naším úkolem je kultivovat to, co existuje, dříve než cokoliv doporučíme koupit.
---
## Co děláme
Pomáháme organizacím překlenout propast mezi jejich investicemi do bezpečnosti a jejich skutečnou bezpečnostní pozicí. V praxi to znamená:
- Auditovat to, co existuje, upřímně — nikoli to, co říkají politiky
- Maximalizovat hodnotu nástrojů a licencí, za které již bylo zaplaceno
- Uzavřít útočný řetězec — konkrétní sled selhání, který by mohl ukončit podnikání — dříve než cokoliv jiného
- Budovat interní kompetence u klienta, nikoli závislost na nás
Každý angažmá začíná **Brownhat Diagnostikou** — strukturovaným dvoudenním hodnocením, které přinese upřímný obraz situace organizace a toho, co je nejdůležitější napravit. Neposkytujeme doporučení, dokud nerozumíme prostředí.
*Celý přehled služeb naleznete v [Modular Engagements](modular-engagements.md).*
---
## Jak přemýšlíme
Pět principů formuje každé naše doporučení:
| Princip | Co to znamená v praxi |
|---------|----------------------|
| **Strukturální oddělení** | Identifikujeme a odstraňujeme skryté závislosti dříve, než se stanou fatálními. Nepřidáváme složitost, která by vytvářela nové závislosti. |
| **Zachování opcí** | Investujeme váš rozpočet do věcí, které zachovávají vaši schopnost změnit směr. Každý zbytečný nákup nástroje snižuje vaši strategickou flexibilitu. |
| **Přeměna stresu na signál** | Každý incident, selhání a téměř-miss jsou zpravodajství. Budujeme systémy, které se z narušení učí, místo aby ho jen přežily. |
| **Svrchované zpravodajství** | Vaše proprietární data by měla zlepšovat vaše vlastní schopnosti, nikoli modely dodavatele. Budujeme nástroje a systémy, které vlastníte a umíte provozovat. |
| **Design asymetrického výnosu** | Malé, cílené investice do existenčních rizik přinášejí nepřiměřenou ochranu. Nikdy nerozptylujeme úsilí rovnoměrně — soustřeďujeme ho tam, kde by selhání bylo fatální. |
*Plný filozofický základ naleznete v [The Antifragile Manifest](antifragile-manifest.md).*
---
## Čím se lišíme
> **INTERNÍ POZNÁMKA** — Tato sekce popisuje upřímnou konkurenční diferenciaci. Buďte konkrétní. Vyhýbejte se obecným konzultantským tvrzením („jsme zaměřeni na klienta", „přinášíme hodnotu"). Pojmenujte, co skutečně děláte jinak, a buďte připraveni to dokázat. Šest bodů níže jsou doporučené výchozí body — upravte je tak, aby odrážely vaši skutečnou diferenciaci.
**1. Začínáme tím, co vlastníte.**
Většina konzultantů přichází se seznamem produktů. My přicházíme s diagnostikou. Dříve než se mluví o jakémkoliv nákupu, vyčerpáme schopnosti stávajících nástrojů. Pokud váš tenant Microsoft E3 dokáže mezeru uzavřít, nakonfigurujeme ho. Naše honoráře jsou odměnou za odbornost, nikoli za marže na licencích.
**2. Cenu stanovujeme za výstup, nikoli za hodinu.**
Každý angažmá má definovaný rozsah a definovaný výstup před zahájením práce. Víte přesně, za co platíte. Víte přesně, co budete držet v rukách na konci. Neexistují otevřené smlouvy maskované jako „průběžná podpora".
**3. Vše, co vybudujeme, vám patří.**
Každý skript, pravidlo detekce, konfigurace a runbook vzniklý během angažmá je předán do vašeho vlastního repozitáře. Nenecháváme ve vašem prostředí běžet proprietární nástroje. Za retenčním poplatkem neschovávejme vaši vlastní dokumentaci. Po ukončení angažmá jste provozně nezávislí.
**4. Zveřejňujeme naše obchodní vztahy.**
Máme obchodní partnerství s Huntress, Tailscale, Thinkst Canary a Tenable. Pokud doporučujeme jeden z těchto nástrojů, řekneme to a vysvětlíme, proč open-source alternativa neodpovídá vašim konkrétním potřebám. Nedoporučujeme nástroje kvůli maržím.
**5. Říkáme vám, co neumíme.**
Jsme malá, specializovaná praxe. Neprovozujeme 24/7 operační centrum. Nepodepisujeme compliance audity. Nenahradzujeme váš IT tým. Pracujeme po boku vašich lidí, budujeme kompetence uvnitř vaší organizace a odcházíme. Pokud potřeba přesahuje naši praxi, řekneme to a ukážeme na správného poskytovatele.
**6. [PLACEHOLDER: Vaše šestá diferenciace]**
> **INTERNÍ POZNÁMKA** — Přidejte diferenciaci specifickou pro vaši praxi. Příklady: hluboká odbornost v konkrétním odvětví (OT/energie, české regulatorní prostředí); proprietární nástroje (ASTRAL, AOC, Elysium); jazykové schopnosti; specifické certifikace; metodologický přístup.
[PLACEHOLDER: konkrétní diferenciace s jedním konkrétním příkladem nebo důkazem]
---
## Tým
> **INTERNÍ POZNÁMKA** — Buďte upřímní a konkrétní. Neuvádějte certifikace, které jste si neudrželi, ani odbornost, kterou nemůžete prokázat v praxi. Jeden odstavec na osobu je dostačující. Pokud je tým malý, vlastněte to — „Jsme specializovaná praxe [N] konzultantů" je silnější výrok než snaha naznačit rozsah, který nemáte.
### [PLACEHOLDER: Jméno, role]
[PLACEHOLDER: bio v 2–3 větách. Zahrňte relevantní zkušenosti, certifikace a konkrétní odbornost, kterou tato osoba přináší do angažmá. Např.: „15 let v podnikové bezpečnosti ve finančních službách a kritické infrastruktuře. OSCP, CISSP. Hluboká odbornost v architektuře Active Directory a bezpečnosti Microsoft 365. Hlavní konzultant pro všechna hardening a blue/purple team angažmá."]
### [PLACEHOLDER: Jméno, role — opakujte dle potřeby]
[PLACEHOLDER: bio]
**Certifikace, které tým drží** (k [PLACEHOLDER: datum]):
[PLACEHOLDER: seznam relevantních certifikací — např. OSCP, CISSP, CEH, AZ-500, SC-200 atd.]
---
## Naši klienti
> **INTERNÍ POZNÁMKA** — Buďte konkrétní, aniž byste jmenovali klienty, kteří nedali souhlas. Odvětvové archetypy jsou v pořádku; konkrétní názvy organizací vyžadují souhlas. Formulace „jak vypadají naši typičtí klienti" je upřímná a nevyžaduje zveřejnění.
Pracujeme primárně s:
- **[PLACEHOLDER: odvětví/archetyp]** — [jedna věta popisující, jak tito klienti vypadají a co je k nám přivádí]
- **[PLACEHOLDER: odvětví/archetyp]** — [popis]
- **[PLACEHOLDER: odvětví/archetyp]** — [popis]
**Co naši klienti mají společného**: Léta budují a provozují IT infrastrukturu. Nahromadili technický dluh, částečně nasazené nástroje a bezpečnostní mezery, o nichž vědí, ale na systematické řešení nikdy neměli prostředky. Nepotřebují novou platformu — potřebují, aby to, co mají, fungovalo správně.
---
## Vybrané práce
> **INTERNÍ POZNÁMKA** — Anonymizované případové studie jsou věrohodnější než loga klientů. Používejte konzistentní strukturu: odvětví/velikost + problém + co jsme udělali + konkrétní výsledek. Tři příklady stačí. Nevymýšlejte výsledky ani nepřeceňujte rozsah.
### [PLACEHOLDER: Odvětví a velikost, např. „Středně velká logistická společnost, 300 zaměstnanců"]
**Situace**: [PLACEHOLDER: 1–2 věty popisující situaci klienta a podnět k angažmá]
**Co jsme udělali**: [PLACEHOLDER: 1–2 věty o konkrétních modulech nebo provedené práci]
**Výsledek**: [PLACEHOLDER: konkrétní, měřitelný výsledek. Např.: „Počet útočných cest BloodHound k Domain Admin snížen z 4 217 na 23. Skóre PingCastle zlepšeno z 52 na 81. KRBTGT rotováno poprvé za 843 dní."]
---
### [PLACEHOLDER: Odvětví a velikost]
**Situace**: [PLACEHOLDER]
**Co jsme udělali**: [PLACEHOLDER]
**Výsledek**: [PLACEHOLDER]
---
### [PLACEHOLDER: Odvětví a velikost]
**Situace**: [PLACEHOLDER]
**Co jsme udělali**: [PLACEHOLDER]
**Výsledek**: [PLACEHOLDER]
---
## Partnerství a akreditace
> **INTERNÍ POZNÁMKA** — Uvádějte pouze aktivní partnerství a aktuální akreditace. Zaniklé certifikace nebo partnerství, kde nemáte formální dohodu, by se zde neměly objevit.
**Obchodní partnerství** (nástroje, které lze zakoupit a spravovat jménem klientů):
| Partner | Co poskytují | Kdy je doporučujeme |
|---------|-------------|---------------------|
| [PLACEHOLDER: např. Huntress] | [PLACEHOLDER: např. Managed EDR, 24/7 threat hunting] | [PLACEHOLDER: např. Klienti bez Defender P2, kteří potřebují 24/7 pokrytí endpointů] |
| [PLACEHOLDER] | | |
**Akreditace a registrace**:
[PLACEHOLDER: registrační čísla společnosti, relevantní akreditace, členství v profesních organizacích, pojištění kybernetické bezpečnosti atd.]
---
## Co neděláme
> **INTERNÍ POZNÁMKA** — Tato sekce nastavuje upřímná očekávání. Klient, který zjistí „to neděláme" v průběhu angažmá, je nespokojený klient. Je lepší to říct zde.
**Neprovozujeme 24/7 operační centrum.** Nasazujeme, konfigurujeme a zprovozňujeme monitorovací nástroje. Pro nepřetržitou řízenou odezvu spolupracujeme s obchodními partnery (Huntress, Thinkst Canary) nebo pomáháme klientům budovat interní schopnost.
**Nepodepisujeme compliance audity.** Připravujeme klienty na audity — mapujeme kontroly, budujeme balíčky důkazů a uzavíráme mezery. Auditní stanovisko náleží kvalifikovanému auditorovi, kterého vyžaduje váš regulátor.
**Nenahradzujeme váš IT tým.** Pracujeme po boku vašich lidí. Předávání znalostí je součástí každého angažmá. Když odcházíme, váš tým musí být schopen provozovat to, co jsme vybudovali.
**Neprodáváme nástroje, které bychom sami nepoužili.** Každé obchodní doporučení je zveřejněno a vysvětleno. Pokud open-source alternativa splňuje vaše potřeby, nasadíme ji místo komerčního řešení.
**[PLACEHOLDER: páté omezení — co neberete]** [PLACEHOLDER: pokud existují konkrétní oblasti, které odmítáte — konkrétní odvětví, regulatorní režimy, geografie — uveďte je zde. Příklad: „Momentálně nepřebíráme klienty vyžadující certifikaci SOC 2 Type II."]
---
## Jak začít spolupráci
**Výchozím bodem** pro každého nového klienta je Brownhat Diagnostika — dvoudenní strukturované hodnocení, které přinese prioritizovaný obraz vaší bezpečnostní pozice a doporučené pořadí modulů. Jde o placené, ohraničené angažmá, které přináší hodnotu bez ohledu na to, zda bude následovat další práce.
*Plnou metodiku diagnostiky naleznete v [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md).*
**Pro zahájení rozhovoru**:
| | |
|-|-|
| **E-mail** | [PLACEHOLDER: primární kontaktní e-mail] |
| **Web** | [PLACEHOLDER: adresa webu] |
| **Jazyky** | [PLACEHOLDER: např. čeština, angličtina, slovenština] |
| **Geografie** | [PLACEHOLDER: např. Česká republika, Slovensko, Velká Británie; vzdálená angažmá po celé EU] |
| **Doba odezvy** | [PLACEHOLDER: např. Počáteční odpověď do 1 pracovního dne] |
**Shrnutí obchodních podmínek**:
- Angažmá jsou s pevně daným rozsahem a pevnou cenou; výstupy jsou dohodnuty písemně před zahájením práce
- Platba: [PLACEHOLDER: např. 50 % při zahájení, 50 % při dokončení]
- Měna: [PLACEHOLDER: CZK / EUR / GBP]
- Smlouvy se řídí: [PLACEHOLDER: český zákon / anglické právo]
- [PLACEHOLDER: další standardní obchodní podmínky, které stojí za to uvést předem]
---
## In English
> *This page is also available in English: [About CQRE](about-cqre.md).*
---
## Integrace se stávajícími dokumenty
| Dokument | Integrace |
|----------|-----------|
| [Engagement Model](engagement-model.md) | Plný životní cyklus angažmá, cenový model a požadavky na klienty zmíněné v tomto dokumentu |
| [Modular Engagements](modular-engagements.md) | Kompletní přehled služeb |
| [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md) | Brownhat Diagnostika popsaná v sekci „Jak začít spolupráci" |
| [C-Suite Conversation Guide](c-suite-conversation-guide.md) | Přesvědčovací skripty pro executive konverzace |
| [Sovereign Tool Stack](../playbooks/sovereign-tool-stack.md) | Nástroje a partnerství zmíněná v tomto dokumentu |
---
*Pro popis angažmá viz [Engagement Model](engagement-model.md).*
*Pro přehled služeb viz [Modular Engagements](modular-engagements.md).*
antifragile-consulting/core/about-cqre.md
+228
View File
@@ -0,0 +1,228 @@
# About CQRE · Brownhat
> *This document introduces CQRE and the Brownhat methodology to new clients and new team members. Fill every `[PLACEHOLDER]` section with specific, honest information. Avoid generic consulting language — clients can tell. The sections marked **INTERNAL NOTE** contain guidance for completing the template; remove them before sharing externally.*
>
> *A Czech-language version of this document is maintained at [about-cqre-cs.md](about-cqre-cs.md).*
---
## Who We Are
**CQRE.NET Ltd** is a specialist cybersecurity consultancy registered in [PLACEHOLDER: United Kingdom / Edinburgh]. We operate primarily from [PLACEHOLDER: Prague, Czech Republic] and work with clients across [PLACEHOLDER: Central Europe, the UK, and Western Europe].
> **INTERNAL NOTE** — Suggested framing: keep this paragraph to 3–5 sentences. Include founding year, geographic base, and the range of clients you work with (industries, sizes). Do not claim capabilities you cannot currently deliver. Example: *"CQRE.NET Ltd was founded in [year] by [name] to provide honest, methodology-driven security consulting to organisations that have outgrown generic advice. We work primarily with mid-market companies, telcos, and utilities across Central Europe — organisations with real environments, existing investments, and specific threats that generic frameworks do not address."*
[PLACEHOLDER: 3–5 sentence company description]
We operate under the **Brownhat** brand when engaging clients — a name that reflects our core philosophy: we work in brownfield environments (built up, lived in, carrying the weight of past decisions) and our job is to recultivate what exists before recommending anything new.
---
## What We Do
We help organisations close the gaps between their security investments and their actual security posture. In practice, this means:
- Auditing what exists, honestly — not what the policies say should exist
- Maximising the value of tools and licences already paid for
- Closing the kill chain — the specific sequence of failures that would end the business — before anything else
- Building retained capability inside client organisations, not dependencies on us
Every engagement begins with the **Brownhat Diagnostic** — a structured two-day assessment that produces an honest picture of where the organisation stands and what matters most to fix. We do not make recommendations before we understand the environment.
*For the full service menu, see [Modular Engagements](modular-engagements.md).*
---
## How We Think
Five principles shape every recommendation we make:
| Principle | What it means in practice |
|-----------|--------------------------|
| **Structural Decoupling** | We identify and remove hidden dependencies before they become fatal. We do not add complexity that creates new ones. |
| **Optionality Preservation** | We spend your budget on things that preserve your ability to change direction. Every unnecessary tool purchase reduces your strategic flexibility. |
| **Stress-to-Signal Conversion** | Every incident, failure, and near-miss is intelligence. We build systems that learn from disruption rather than merely surviving it. |
| **Sovereign Intelligence** | Your proprietary data should improve your own capability, not a vendor's model. We build tools and systems you own and can operate. |
| **Asymmetric Payoff Design** | Small, targeted investments on existential risks yield disproportionate protection. We never distribute effort evenly — we concentrate it where failure is fatal. |
*For the full philosophical foundation, see [The Antifragile Manifest](antifragile-manifest.md).*
---
## What Makes Us Different
> **INTERNAL NOTE** — This section is the honest competitive differentiation. Be specific. Avoid generic consulting claims ("we are client-focused," "we deliver value"). Name what you actually do differently and be prepared to prove it. The six points below are suggested starting points — edit to reflect your actual differentiation.
**1. We start with what you own.**
Most consultants arrive with a shortlist of products. We arrive with a diagnostic. Before any purchase is discussed, we exhaust the capabilities of existing tools. If your Microsoft E3 tenant can close the gap, we configure it. We earn our fees from expertise, not licence margins.
**2. We price by deliverable, not by the hour.**
Every engagement has a defined scope and a defined deliverable before work begins. You know exactly what you are paying for. You know exactly what you will hold at the end. There are no open-ended retainers disguised as "ongoing support."
**3. Everything we build belongs to you.**
Every script, detection rule, configuration, and runbook produced during an engagement is delivered to your own repository. We do not leave proprietary tools running in your environment. We do not hold your own documentation behind a retainer. When an engagement closes, you are operationally independent.
**4. We disclose our commercial relationships.**
We have commercial partnerships with Huntress, Tailscale, Thinkst Canary, and Tenable. When we recommend one of these tools, we say so and explain why the open-source alternative does not meet your specific need. We do not recommend tools because of margin.
**5. We tell you what we cannot do.**
We are a small, specialist practice. We do not run a 24/7 SOC. We do not sign off on compliance audits. We do not replace your IT team. We work alongside your people, build capability inside your organisation, and leave. If a need falls outside our practice, we say so and point you to the right provider.
**6. [PLACEHOLDER: Your sixth differentiator]**
> **INTERNAL NOTE** — Add a differentiator specific to your practice. Examples: deep expertise in a specific vertical (OT/utilities, Czech regulatory environment); proprietary tools (ASTRAL, AOC, Elysium); language capability; specific certifications; methodology approach.
[PLACEHOLDER: specific differentiator with one concrete example or proof point]
---
## The Team
> **INTERNAL NOTE** — Keep this honest and specific. Do not list certifications you have not maintained or expertise you cannot demonstrate in an engagement. A one-paragraph bio per person is sufficient. If the team is small, own it — "We are a specialist practice of [N] consultants" is a stronger statement than trying to imply scale you do not have.
### [PLACEHOLDER: Name, role]
[PLACEHOLDER: 2–3 sentence bio. Include relevant background, certifications, and the specific expertise this person brings to engagements. E.g., "15 years in enterprise security across financial services and critical infrastructure. OSCP, CISSP. Deep expertise in Active Directory architecture and Microsoft 365 security. Lead consultant for all AD hardening and blue/purple team engagements."]
### [PLACEHOLDER: Name, role — repeat as needed]
[PLACEHOLDER: Bio]
**Certifications held by the team** (as of [PLACEHOLDER: date]):
[PLACEHOLDER: list relevant certifications — e.g., OSCP, CISSP, CEH, AZ-500, SC-200, etc.]
---
## Our Clients
> **INTERNAL NOTE** — Be specific without naming clients who have not given permission. Industry archetypes are fine; specific organisation names require consent. The "what our clients typically look like" framing is honest and does not require disclosure.
We work primarily with:
- **[PLACEHOLDER: industry/archetype]** — [one sentence description of what these clients typically look like and what brings them to us]
- **[PLACEHOLDER: industry/archetype]** — [description]
- **[PLACEHOLDER: industry/archetype]** — [description]
**What our clients typically have in common**: They have been building and running IT infrastructure for years. They have accumulated technical debt, partially deployed tools, and security gaps they know exist but have not had the resources to address systematically. They do not need a new platform — they need someone to make what they have work properly.
---
## Selected Work
> **INTERNAL NOTE** — Anonymised case studies are more credible than logo walls. Use a consistent structure: industry/size + problem + what we did + specific outcome. Three examples are enough. Do not fabricate outcomes or exaggerate scope.
### [PLACEHOLDER: Industry and size, e.g., "Mid-market logistics company, 300 employees"]
**Situation**: [PLACEHOLDER: 1–2 sentences describing the client situation and the trigger for engagement]
**What we did**: [PLACEHOLDER: 1–2 sentences on the specific modules or work performed]
**Outcome**: [PLACEHOLDER: specific, measurable result. E.g., "BloodHound attack paths to Domain Admin reduced from 4,217 to 23. PingCastle score improved from 52 to 81. KRBTGT rotated for the first time in 843 days."]
---
### [PLACEHOLDER: Industry and size]
**Situation**: [PLACEHOLDER]
**What we did**: [PLACEHOLDER]
**Outcome**: [PLACEHOLDER]
---
### [PLACEHOLDER: Industry and size]
**Situation**: [PLACEHOLDER]
**What we did**: [PLACEHOLDER]
**Outcome**: [PLACEHOLDER]
---
## Partnerships and Accreditations
> **INTERNAL NOTE** — Only list active partnerships and current accreditations. Lapsed certifications or partnerships where you have no formal agreement should not appear here.
**Commercial partnerships** (tools we can procure and manage on behalf of clients):
| Partner | What they provide | When we recommend them |
|---------|------------------|----------------------|
| [PLACEHOLDER: e.g., Huntress] | [PLACEHOLDER: e.g., Managed EDR, 24/7 threat hunting] | [PLACEHOLDER: e.g., Clients without Defender P2 who need 24/7 endpoint coverage] |
| [PLACEHOLDER] | | |
**Accreditations and registrations**:
[PLACEHOLDER: company registration numbers, relevant accreditations, professional memberships, cyber insurance, etc.]
---
## What We Do Not Do
> **INTERNAL NOTE** — This section sets honest expectations. A client who discovers a "we don't do that" during an engagement is a dissatisfied client. Better to say it here.
**We do not run a 24/7 operations centre.** We deploy, configure, and enable monitoring tools. For round-the-clock managed response, we work with commercial partners (Huntress, Thinkst Canary) or help clients build internal capability.
**We do not sign off on compliance audits.** We prepare clients for audits — mapping controls, building evidence packages, and closing gaps. The audit opinion belongs to the qualified auditor your regulator requires.
**We do not replace your IT team.** We work alongside your people. Knowledge transfer is part of every engagement. When we leave, your team must be able to operate what we built.
**We do not resell tools we would not use ourselves.** Every commercial recommendation is disclosed and explained. If an open-source alternative meets your need, we deploy that instead.
**We do not take engagements outside our competence.** [PLACEHOLDER: if there are specific areas you decline — e.g., specific industries, specific regulatory regimes, specific geographies — state them here. "We do not currently take on clients requiring SOC 2 Type II certification" or similar.]
---
## How to Engage
**The starting point** for every new client is the Brownhat Diagnostic — a two-day structured assessment that produces a prioritised picture of your security posture and a recommended module sequence. It is a paid, bounded engagement that delivers value regardless of whether any further work follows.
*For the full diagnostic methodology, see [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md).*
**To start a conversation**:
| | |
|-|-|
| **Email** | [PLACEHOLDER: primary contact email] |
| **Web** | [PLACEHOLDER: website URL] |
| **Languages** | [PLACEHOLDER: e.g., Czech, English, Slovak] |
| **Geography** | [PLACEHOLDER: e.g., Czech Republic, Slovakia, UK; remote engagements across EU] |
| **Response time** | [PLACEHOLDER: e.g., Initial response within 1 business day] |
**Commercial terms summary**:
- Engagements are fixed-scope, fixed-price, with deliverables agreed in writing before work begins
- Payment: [PLACEHOLDER: e.g., 50% at kickoff, 50% at completion]
- Currency: [PLACEHOLDER: CZK / EUR / GBP]
- Contracts governed by: [PLACEHOLDER: Czech law / English law]
- [PLACEHOLDER: any other standard commercial terms worth stating upfront]
---
## In Czech
> *Tato stránka je k dispozici také v češtině: [O společnosti CQRE](about-cqre-cs.md).*
---
## Integration With Existing Frameworks
| Document | Integration |
|----------|-------------|
| [Engagement Model](engagement-model.md) | The full engagement lifecycle, pricing model, and client requirements referenced in this document |
| [Modular Engagements](modular-engagements.md) | The complete service menu |
| [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md) | The Brownhat Diagnostic described in the "How to Engage" section |
| [C-Suite Conversation Guide](c-suite-conversation-guide.md) | Client-facing persuasion scripts for executive conversations |
| [Sovereign Tool Stack](../playbooks/sovereign-tool-stack.md) | The tools and partnerships referenced in this document |
---
*For the engagement process, see [Engagement Model](engagement-model.md).*
*For the full service menu, see [Modular Engagements](modular-engagements.md).*
antifragile-consulting/core/antifragile-manifest.md
+3 -1
View File
@@ -21,7 +21,9 @@ This is not a security framework. It is a **strategic operating philosophy** for
## For the Practitioner
This manifest defines the five foundational pillars of an antifragile enterprise. It is not a security framework. It is a **strategic operating philosophy** for organizations that intend to outlast their competitors, their regulators, and their own assumptions.
This manifest defines the five foundational pillars of an antifragile enterprise. Each pillar describes both a principle and a set of concrete moves. The philosophy is platform-agnostic—these pillars apply whether your client runs Microsoft 365, Google Workspace, AWS, on-premise Linux, or a hybrid OT environment.
Your job as a consultant is to translate each pillar into the specific context of the client. The language should shift (a CISO hears "Stress-to-Signal Conversion" differently than a CFO does), but the underlying logic does not.
For the reasoning *why* these pillars work—drawn from natural systems, distributed networks, and emergent order—see [Spontaneous Order Principles](spontaneous-order-principles.md).
antifragile-consulting/core/consultant-field-guide.md
+372
View File
@@ -0,0 +1,372 @@
# Consultant Field Guide
> *"The philosophy tells you what to value. This document tells you how to make the call when two things you value are in conflict."*
This document is the internal complement to the [Engagement Model](engagement-model.md). The engagement model covers the mechanics of delivery: how engagements are structured, scoped, priced, and handed over. This document covers the thinking behind the work — the mental models, the qualification filters, the prioritisation logic, the failure patterns, and the technical onboarding path.
Read the [Engagement Model](engagement-model.md) first. Then read this.
---
## Part 1: How We Make Decisions
Five types of decisions arise in every engagement. The philosophy documents describe what to value. This section describes how to make the call in practice.
---
### Decision Type 1: Prioritisation
**The question**: Which of the client's ten problems do we fix first?
**The mental model**: The kill chain test.
Ask: *"If this is not fixed and an adversary exploits it, does the organisation fail to operate?"*
- **Yes** → P0. Fix before anything else. Do not leave until it is closed or mitigated.
- **No, but material damage results** → P1. Close within the engagement.
- **No** → P2. Document it, put it in the risk register, schedule it for a later module.
P0 examples: Domain admins logging in from email/browsing workstations. Backups that have never been restored. Internet-facing systems with unpatched critical CVEs. MFA not enforced on any account.
The most common prioritisation failure: treating forty findings as equally important because they all appeared in the same scan output. A client who fixes a P2 before their P0 has been made less safe, not more. Rank everything. Communicate the ranking loudly.
---
### Decision Type 2: Tool Selection
**The question**: Do we use what the client owns, an open-source tool, or a commercial product?
**The mental model**: The sovereign test — applied in order.
1. Can we close this gap with what the client already owns or has already paid for? If yes, configure and operationalise it. Do not recommend anything else.
2. If not, can we close it with an open-source tool in the sovereign tool stack? If yes, deploy it.
3. If not — because the gap requires 24/7 managed response we cannot staff, compliance genuinely requires a vendor attestation, or the scale exceeds what open-source handles efficiently — then recommend the appropriate commercial partner.
The test for step 3: *"Would I make this recommendation if I earned no more from it than from deploying the open-source alternative?"* If the answer is no, the recommendation is compromised.
When you do recommend a commercial tool, disclose the partnership relationship at the moment of recommendation. Not in the footnotes.
---
### Decision Type 3: Scope
**The question**: Is this request within scope? If the scope needs to change, how?
**The mental model**: The completion-criteria test.
A scope is defined only when you can write a sentence of the form: *"The work is complete when [verifiable condition]."* If you cannot write that sentence, the scope is not defined. Undefined scope is undeliverable.
For scope changes during delivery:
- Is the request something the agreed completion criteria would reasonably require? → Absorb it.
- Is it genuinely new work? → Change order, written, before execution.
- Is it something you should have scoped initially but missed? → Absorb it and note it as a scoping lesson.
Never retroactively charge for out-of-scope work you did without a change order. Never silently absorb work that should be a change order. Both erode trust, in different directions.
---
### Decision Type 4: Communication
**The question**: How do I communicate a difficult finding, a risk, a scope problem, or a project delay?
**The mental model**: The "would I want to know?" test — applied to timing and framing.
- Say it early. The client's distress from a critical finding is proportional to how long they were not told about it.
- Say it plainly. No hedging, no softening, no burying in a paragraph of context.
- Say what it means in business terms, not technical ones. "Your KRBTGT password is 847 days old" is a technical finding. "An attacker who compromises any domain account can forge authentication tokens valid for up to 847 days, which means we cannot trust any AD authentication even after we reset passwords" is a business finding.
- Then say what we do about it.
The sequence: *finding → business impact → recommended action → timeline*. Always in that order.
---
### Decision Type 5: Recommendation
**The question**: What should the client do next?
**The mental model**: The independence test.
Before making any recommendation, ask: *"If I had no commercial relationship with any vendor and no financial stake in the client's decision, would I still make this recommendation?"* If yes, make it. If no, find the recommendation you would make under those conditions, and make that one instead.
A recommendation that enriches you at the client's expense is not a recommendation. It is a conflict of interest wearing a consultant's jacket. The long-term value of independence — referrals, retained relationships, reputation — always exceeds the short-term value of a compromised recommendation.
---
## Part 2: The Discovery Call
The discovery call happens before the Brownhat Diagnostic. Its purpose is not to sell anything. It is to determine whether this client is a fit for our work and whether we are a fit for their situation.
### What to ask
**The trigger question**: *"What happened recently that made you call us?"*
Listen for: a specific incident, an audit finding, a regulatory deadline, a new hire who saw problems, a breach at a peer organisation. The trigger shapes everything — it tells you which domain is most sensitive, who the executive sponsor is, and how much urgency is real versus performed.
**The accountability question**: *"Who in your organisation is ultimately accountable for security outcomes?"*
Listen for: a specific person with budget authority. "Everyone is responsible" means no one is. Without a named executive sponsor who can make decisions and approve changes, the engagement will die in committee.
**The tools question**: *"What tools do you have? M365 licensing level? Any existing EDR, SIEM, or PAM?"*
This tells you how much existing tooling can be leveraged before any purchase is needed. An E5 client with underused Defender has a different engagement structure than an E3 client with no EDR at all.
**The history question**: *"Have you had any incidents or near-misses in the past two years?"*
Incidents reveal the actual threat landscape, the real response capability, and what the organisation already knows about its weaknesses. Post-incident clients have more internal urgency — and often more political complexity.
**The success question**: *"What does success look like at the end of this engagement?"*
Listen for specificity. "We want to be more secure" is not a success definition. "We want to pass our NIS2 audit in Q2 without findings" is. Clients who cannot articulate success criteria cannot be satisfied — they will always want more, differently, and retroactively.
---
### What disqualifies a client
Some client situations are not a fit. Recognising them before starting an engagement is a service to the client and to yourself.
| Signal | What it means | Response |
|--------|--------------|---------|
| No executive sponsor with decision authority | The engagement will require every decision to go through a committee that never meets | Ask who can approve changes in 24 hours. If the answer is unclear, do not start. |
| "We just need a compliance certificate" | They want a stamp, not resilience | Redirect to a compliance auditor who will produce the stamp. We produce evidence; the stamp is a side effect. If they only want the side effect, we are the wrong provider. |
| "We already know what we need, skip the diagnostic" — and no documentation to support this | High risk of undiscovered scope and mid-engagement surprises | See the [Engagement Model](engagement-model.md), Section 7. Never skip without equivalent documentation. |
| The named project contact has no visibility into IT operations | You will spend half your time waiting for access and information | Escalate to the executive sponsor; require a named IT lead with operational access as a kickoff prerequisite. |
| Budget so constrained that the Brownhat Diagnostic consumes most of it | There is no room to act on the findings; the diagnostic becomes a dead-end exercise | Have an honest conversation: the diagnostic is valuable standalone, but acting on it requires further investment. Confirm the client understands and accepts that constraint. |
---
### When to say no
Decline engagements where:
- The client wants findings presented to a regulator as "third-party validation" of work the client designed themselves, without independent assessment
- The client has been vague or inconsistent about material facts during discovery — this will worsen during delivery
- The scope involves active offensive operations against third parties without written authorisation from the targets
- The client's goal is to reduce a finding's severity in an existing audit rather than to close the actual gap
Saying no is not a failure. It is judgment. A reputation for honesty about fit is worth more than any single engagement.
---
## Part 3: Module Selection — When the Client Can Only Afford One
The Brownhat Diagnostic produces a prioritised module roadmap. When the client has budget for one module and multiple problems, the selection logic is:
**Step 1: What is the kill chain?**
From the diagnostic findings, identify the shortest path from "nothing bad has happened yet" to "the organisation fails." The module that closes the highest-priority node on that path is the right recommendation.
**Step 2: If two modules address the same node, choose the faster time-to-value.**
Module 6 (AD Hardening) closes more attack paths faster than Module 12 (Blue/Purple Team) for a client with a degraded AD. But Module 12 produces detection capability that persists. If both are equal by kill-chain analysis, choose the module that produces durable, operational output over the module that produces a point-in-time fix.
**Step 3: Never recommend a later-stage module when an earlier-stage gap is unaddressed.**
Detection engineering (Module 12) is waste if identity is uncontrolled (Module 2). A red team engagement (Module 10) will find what the kill chain already shows if the basic hygiene isn't done. The right answer is almost always the module that fixes the foundation — not the module that tests it.
---
### Common single-module scenarios
| Client situation | First module | Rationale |
|-----------------|-------------|-----------|
| "Our AD is a mess — stale accounts, no tiering, legacy configs" | **Module 6** | Closes the most attack paths fastest; produces durable structural improvement |
| "We had a phishing incident; accounts were compromised" | **Module 2** | The exploit path was identity; fix the foundation before adding detection on top of it |
| "We have no visibility — we would not know if we were breached" | **Module 1** then **Module 12** | Endpoint management establishes the asset baseline; blue/purple team builds detection on top |
| "DORA audit in 5 months" | **Brownhat Diagnostic** first | The diagnostic maps the gaps to specific controls; module selection follows from the audit findings |
| "Our MSSP generates 300 alerts a day and nothing gets fixed" | **Module 12** | The MSSP problem is a detection engineering problem; retained capability closes it |
| "We are moving to M365 and want to do it right" | **Module 1** → **Module 2** → **Module 3** | In sequence: endpoint baseline, identity security, then hardening |
| "We have OT and IT on the same flat network" | **Module 8** | The segmentation gap is existential; close it before any other work |
---
## Part 4: The Ten Most Common Mistakes
These are the failure patterns that appear most often in first engagements. They are not failures of competence. They are failures of discipline — usually under client pressure, time pressure, or social discomfort.
---
**1. Starting with recommendations before understanding**
Recommending modules, tools, or configurations before the Brownhat Diagnostic is complete. The savings in week 1 cost three times as much in week 5 when the undiscovered scope surfaces.
---
**2. Scope without completion criteria**
Agreeing to "improve AD security" or "harden the M365 tenant" without writing down what "improved" and "hardened" mean in verifiable terms. The work never ends; the client never feels satisfied; the invoice is always a surprise.
---
**3. Absorbing scope creep silently**
Doing out-of-scope work to avoid the discomfort of raising a change order. This trains the client that scope is negotiable and invoices are estimates. It feels worse at billing time than the conversation would have felt mid-engagement.
---
**4. Leaving without runbooks**
Completing technically excellent work without documenting how to operate it. Three months later, something changes or breaks, and nobody on the client side knows how the system works. The client calls back — but not with gratitude.
---
**5. Recommending a purchase before demonstrating existing-tools value**
Proposing a new commercial tool in week 2 before showing the client what their existing investments can do. This looks like reselling, not consulting. It destroys the credibility of the "existing tools first" principle in the same engagement where you invoked it.
---
**6. Hiding bad news**
Discovering a critical finding and softening it to manage the client's reaction. The client's distress from a critical finding is proportional to how long they were not told about it. Say it plainly, frame the remediation, and let the client's reaction be what it is.
---
**7. Over-promising timelines**
Committing to module durations based on the nominal calendar, knowing that the client's access provisioning, decision-making cadence, and existing workload will add weeks. Scope to the realistic case; under-promise and over-deliver.
---
**8. Treating all findings as equally urgent**
Producing a finding list with thirty items where a P0 and a P2 look identical. The client picks items by recognition or by urgency they invent, and the kill chain remains open. Make the priority structure impossible to miss — it should be the first thing a client sees, not something they have to infer.
---
**9. Making changes without explicit client approval**
Even obviously correct changes. The technical work is not the only product of the engagement — trust is also a product. Trust is built on consent, not just competence. Every production change has explicit written approval before execution.
---
**10. Confusing baseline for delivery**
Week 1 produces the baseline. It does not produce improvements. Clients sometimes interpret a week of scanning and documentation as slow progress and apply pressure to start making changes. The week 1 discipline is non-negotiable. Explain why: *"Everything we change in week 2 will be benchmarked against what we documented in week 1. Without the baseline, we cannot measure the improvement. And we cannot improve safely what we do not yet understand."*
---
## Part 5: Technical Onboarding
### CQRE tool repositories
Before leading a module, you need to be able to deploy and use the tools that module depends on. All CQRE tools are hosted at git.cqre.net:
| Tool | Repository | Used in |
|------|-----------|---------|
| **ASTRAL** | `cqrenet/astral` (public) · `cqrenet/Intune` (internal, full version) | Modules 1, 2, 3 |
| **AOC** | `cqrenet/aoc` | Modules 2, 3, 12; retained capability |
| **macOS_IntuneManagement** | `cqrenet/macOS_IntuneManagement` | Module 1; tenant migrations |
| **Elysium** | `cqrenet/elysium` | Module 6, 10 |
| **CAExporter** | `vibecoding/CAExporter` | Modules 2, 3 |
| **E8-CAT** | `vibecoding/E8-CAT` | Modules 1, 3 |
| **IntunePolicyParser** | `vibecoding/IntunePolicyParser` | Module 1; alongside ASTRAL |
| **M365-Scripts** | `cqrenet/M365-Scripts` | Module 1 (MDE device lifecycle) |
Each repository contains its own README with deployment instructions. Read the README and deploy the tool in a lab environment before using it with a client. Do not learn a tool at a client's expense.
### Required competencies before leading each module
This is the minimum bar for leading (not shadowing) a module. If you are not there yet, shadow the module first.
| Module | Minimum competency |
|--------|-------------------|
| **Module 1** (Endpoint) | PowerShell 7+; Intune policy structure; ASTRAL deployment and configuration; E8-CAT scoring |
| **Module 2** (Identity) | Entra ID architecture; Conditional Access design; PIM/PAM concepts; AOC deployment; CAExporter export and analysis |
| **Module 3** (M365 Hardening) | Modules 1 and 2 competency; Prowler Azure audit; ASTRAL drift detection; ASR rules |
| **Module 6** (AD Hardening) | Active Directory architecture; BloodHound collection and analysis; DSInternals and Elysium operation; LAPS deployment; GPO design; Sysmon configuration |
| **Module 8** (OT Security) | OT/IT network segmentation concepts; NIS2 Article 21 and 23 requirements; SCADA/ICS risk framing; Zeek or Suricata basics |
| **Module 12** (Blue/Purple Team) | MITRE ATT&CK framework; KQL or Sigma rule authoring; Wazuh deployment; TheHive and Shuffle basics; detection engineering fundamentals |
| **Module 13** (Privileged Access) | WireGuard protocol; Tailscale and Headscale deployment; Teleport architecture and session recording; SSH certificate authority concepts |
| **Module 14** (Sovereign Communications) | Delta Chat and chatmail relay deployment; Matrix/Synapse basics (for enterprise deployments); out-of-band communication design |
### Building your lab environment
Before your first client engagement, build a personal lab that lets you safely test deployments:
- **M365 developer tenant** — Microsoft's free developer programme provides an E5 tenant. Use it for ASTRAL, AOC, CAExporter, and M365 module testing. Register via the Microsoft 365 Developer Programme.
- **A small Linux VM (any cloud)** — For chatmail relay, Wazuh, TheHive, and Shuffle deployments. A €5–10/month VPS is sufficient for personal lab use.
- **A Windows Server VM** — For AD module testing: BloodHound, Elysium, LAPS, Sysmon. Can be local (Hyper-V, VMware) or cloud.
- **A CQRE internal environment** — Ask for access to the shared lab environment used for tool testing and client demos.
The rule: you must have deployed and operated every tool you plan to use with a client, in a controlled environment, before the client engagement begins.
---
## Part 6: Writing a Proposal
A Brownhat engagement proposal has four parts, in this order:
---
### Part 1: What we found
Two to five specific findings from the Brownhat Diagnostic or discovery call. Not generic risk language. Specific observations:
> *"Your Active Directory contains 847 user accounts, of which 312 have not been accessed in over 12 months. Eleven domain administrator accounts exist; six are used for daily workstation tasks including email and web browsing. The KRBTGT password has not been rotated in 1,247 days."*
The client should recognise their environment in this section. If they do not, the discovery was not thorough enough.
---
### Part 2: What we recommend
One specific module — the one that closes the highest-priority gap from the diagnostic. With an explicit scope: the deliverables, the completion criteria, and what is out of scope.
> *"We recommend Module 6: On-Premise AD Hardening. Scope: BloodHound attack path analysis and remediation report; Elysium password audit with prioritised remediation list; LAPS deployment to all domain-joined workstations (confirmed 100% coverage); KRBTGT rotation; reduction of Global Administrator accounts to a documented minimum; operating runbook for ongoing AD hygiene.*
> *Out of scope: Azure AD Connect hardening (Module 2), endpoint EDR deployment (Module 1), and any changes to OT network infrastructure.*
> *Complete when: LAPS coverage is verified at 100%, KRBTGT rotation is confirmed, and the privileged account count and BloodHound attack path count are documented against the post-engagement baseline."*
---
### Part 3: What you will receive
The Module Completion Package for this specific module. Restate the standard package (from the [Engagement Model](engagement-model.md)) with module-specific additions:
> *"At completion of this engagement, you will receive: a configuration baseline document; the BloodHound and Elysium output files delivered to your own repository; operating runbooks for LAPS management, KRBTGT rotation cadence, and privileged account review; an updated risk register entry for each finding; a before-and-after AD security score (PingCastle); and a recommended next module with rationale."*
---
### Part 4: Investment
| Item | Detail |
|------|--------|
| **Consultant effort** | [N] days |
| **Calendar timeline** | [Start date] → [Completion date] |
| **Infrastructure** | [Any costs, e.g., chatmail relay €5–10/month] |
| **External licensing** | [None / or specify] |
| **Total** | [Fixed fee in €] |
Include a note on payment terms (e.g., 50% at kickoff, 50% at completion).
---
### What never goes in a proposal
| Never include | Why |
|---------------|-----|
| Vague risk language ("your organisation faces significant cybersecurity risks") | Every client already believes this. It adds no information and signals you do not know their specific situation. |
| Tool shopping lists before the diagnostic | Recommending specific products before understanding the environment is reselling, not consulting. |
| Pricing ranges | A range signals that you do not know the scope. Scope it properly and give a fixed price. |
| Multi-year commitments in a first proposal | The client has not yet seen you work. Earn the next engagement. |
| Best-case timelines presented as the estimate | The client will hold you to them. Scope to the realistic case. |
| A list of everything you found rather than a prioritised narrative | Volume is not insight. A proposal is not a scan report. |
---
## Integration With Existing Frameworks
| Document | Relationship |
|----------|-------------|
| [Engagement Model](engagement-model.md) | The operational complement: delivery mechanics, client requirements, pricing structure, communication cadence. Read first. |
| [Move Fast and Fix Things](move-fast-and-fix-things.md) | The source of the "existing tools first" and "fix the kill chain first" principles operationalised in Part 1 |
| [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md) | The Brownhat Diagnostic: the entry point for every new client, referenced throughout Parts 2 and 3 |
| [Modular Engagements](modular-engagements.md) | The full module menu: descriptions, durations, investment levels, and per-module deliverables referenced in Parts 3 and 6 |
| [Sovereign Tool Stack](../playbooks/sovereign-tool-stack.md) | The tool selection doctrine (sovereign test), the per-module tool pairings, and the commercial partnership framework |
| [C-Suite Conversation Guide](c-suite-conversation-guide.md) | The client-facing persuasion scripts and objection handling that complement the internal decision models in this document |
| [Antifragile Risk Register](../assessment-templates/antifragile-risk-register.md) | The risk register format used in the module completion package and referenced in prioritisation |
---
*For delivery mechanics and pricing, see [Engagement Model](engagement-model.md).*
*For module descriptions and selection, see [Modular Engagements](modular-engagements.md).*
*For client-facing scripts, see [C-Suite Conversation Guide](c-suite-conversation-guide.md).*
antifragile-consulting/core/engagement-model.md
+510
View File
@@ -0,0 +1,510 @@
# Engagement Model: Working with Brownhat / CQRE
> *"A consultant who cannot tell you exactly what you will receive and when is not a consultant. They are a process."*
This document explains how engagements with CQRE work in practice — the sequence from first contact to completed work, what we ask of you, and what you will hold in your hands at the end.
**Sections 1–6 are written for clients.** They describe the client experience: the lifecycle, the requirements, the deliverables, the pricing structure, and the communication rhythm.
**Section 7 is written for consultants.** It covers scoping, pricing conversations, delivery discipline, and how to handle difficult situations. It is not typically shared with clients.
---
## Why This Document Exists
Most consulting engagements fail not because the work is wrong but because expectations were misaligned. The client expected a report; the consultant delivered a roadmap. The client expected thirty days; it took ninety. The consultant believed the scope was fixed; the client believed it was a starting point.
This document eliminates that by making the engagement model explicit before work begins. Both sides should be able to answer:
- What happens first, and what comes after that?
- What does the client need to provide, and when?
- What will the client hold in their hands at the end of each stage?
- How is the work priced, and what is never billable?
- What does success look like, and how is it measured?
---
## Section 1: The Entry Point — The Brownhat Diagnostic
**We do not begin with recommendations. We begin with understanding.**
The Brownhat Diagnostic — a structured NIST CSF 2.0 baseline assessment — is the mandatory entry point for every new client. It is not a free scoping call. It is a paid, bounded engagement that produces a deliverable of value regardless of whether any further work follows.
**Why we insist on this**: Every consulting failure we have witnessed started with a recommendation made before the environment was understood. Clients are told they need a SOC before anyone has mapped their assets. They buy an EDR platform before anyone has verified that Defender already covers the gap. They engage a penetration tester before knowing what their actual attack surface looks like. The Brownhat Diagnostic prevents this. We earn the right to recommend anything only after we understand your specific reality.
**What the client receives from the Brownhat Diagnostic**:
- A current-state assessment across all six NIST CSF 2.0 domains (GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER)
- An identified kill chain: the shortest path from "nothing bad has happened yet" to "the organisation cannot operate"
- Up to five quick wins — things improvable within 30 days using existing tools and no budget
- A prioritised remediation roadmap mapped directly to the antifragile module menu
- Auditable evidence of due diligence that can be presented to a regulator, board, or auditor
**The one exception**: Clients experiencing an active incident or a hard deadline (ransomware recovery in progress, regulatory submission in 30 days) may engage directly with the relevant module. In this case, the Brownhat Diagnostic is scheduled for after the immediate work, not instead of it.
*For the full Brownhat Diagnostic methodology, see [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md).*
---
## Section 2: The Engagement Lifecycle
A standard engagement moves through five stages. Not every engagement completes all five — some clients take a single module and stop. That is a valid outcome. The structure is designed to be modular, not mandatory end-to-end.
```
Stage 1: Brownhat Diagnostic
↓
Stage 2: Module Selection and Proposal
↓
Stage 3: Engagement Kickoff
↓
Stage 4: Delivery
↓
Stage 5: Completion and Handover
↓ (optional)
Stage 6: Retained Relationship
```
---
### Stage 1: Brownhat Diagnostic
*Duration: Two half-day workshops + five business days for report delivery.*
A structured workshop with the client's executive sponsor, IT lead, and one business process owner. No tools are installed. No systems are accessed. No changes are made. The output is a clear, honest picture of where the organisation stands and what matters most to fix.
*See [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md) for the full workshop methodology, questionnaires, and report structure.*
---
### Stage 2: Module Selection and Proposal
*Duration: 1–5 business days after diagnostic delivery.*
Based on the Brownhat Diagnostic findings, we present a recommended module sequence:
- Which modules address the identified kill chain (P0 — existential risk)
- Which modules address critical but non-existential gaps (P1)
- Which modules can wait until P0 and P1 work is complete (P2)
- An estimated timeline and investment level for each recommended module
- A recommended starting point: one module, bounded scope, defined deliverable
We do not propose a comprehensive multi-year programme and request a blanket signature. We propose the next logical module, explain exactly why, and let the client decide whether to proceed. Each module stands alone. Committing to one does not commit to any other.
---
### Stage 3: Engagement Kickoff
*Duration: 1–3 days.*
Before delivery begins, we establish:
| Item | Detail |
|------|--------|
| **Named client lead** | One person with authority to approve changes, answer questions, and make decisions within 24 hours. This person is not optional. Without a named lead, the engagement does not start. |
| **Access and credentials** | All required access provisioned before day 1, not on day 1. Accounts, MFA, and permissions confirmed in writing. |
| **Communication channels** | A shared channel (Teams or Slack) for day-to-day communication + a Delta Chat channel on an independent chatmail relay for sensitive material and out-of-band escalation |
| **Scope agreement** | A written document listing exactly what is in scope, what is explicitly out of scope, and what the completion criteria are. Signed before work begins. |
| **Weekly check-in slot** | A standing 30-minute slot with the named client lead. Calendar-blocked before kickoff. |
---
### Stage 4: Delivery
*Duration: Module-specific. See [Modular Engagements](modular-engagements.md) for per-module timelines.*
Delivery follows a consistent rhythm regardless of which module is active.
**Week 1 — Documentation and baseline. No changes.**
Every module begins with reading before writing. We export current configuration state, run baseline assessments, collect existing documentation, and confirm that the agreed scope matches the discovered reality. We make no changes in week 1. This discipline exists because changes made without understanding the environment create new problems; because the client needs to see our process before they trust our execution; and because a clean baseline is required to measure progress.
**Weeks 2–N — Iterative delivery with daily change log.**
Every change is documented the day it is made. The client's named lead sees what changed and why. Nothing is deployed to production without their explicit approval. The pace is set by what can be done safely, not by a calendar.
**Weekly check-in — 30 minutes, every week.**
Structure:
1. What was completed since last week (change log review)
2. What is being worked on this week
3. Decisions the client needs to make
4. Risks and open issues
Meeting notes shared within 24 hours. Action items have owners and dates. If the check-in is consistently cancelled by the client, the engagement is paused until it resumes.
**Escalation before execution.**
If a change carries production risk, requires budget beyond the agreed scope, or touches a system requiring executive sign-off, we escalate before we execute. We do not ask forgiveness.
---
### Stage 5: Completion and Handover
*Duration: 3–5 business days for documentation + 1 final presentation.*
Every completed module produces a **Module Completion Package**:
| Deliverable | Description |
|-------------|-------------|
| **Configuration baseline document** | A record of the state before the engagement, every change made, and the rationale for each change |
| **Scripts, rules, and automation** | Delivered into the client's own repository. The client owns everything we write. |
| **Operating runbooks** | Step-by-step instructions for the client's team to operate and maintain what was built — with cadences, alert handling procedures, and escalation paths |
| **Risk register update** | What the module closed (with evidence), what remains open, and what the next recommended work would address |
| **Metrics baseline** | A measurable before-and-after snapshot: the score against which the next engagement can be benchmarked |
| **Next-module recommendation** | One or two sentences on the logical next step. No obligation — a signpost. |
**The handover principle**: At the end of every engagement, the client's team must be able to operate everything we built without calling us. If they cannot, the handover is not complete. Knowledge transfer is a deliverable, not a bonus.
---
### Stage 6: Retained Relationship
*Optional. Available after at least one project module is complete.*
Some clients want ongoing support rather than discrete projects. Three models:
| Type | Description | Typical cadence |
|------|-------------|----------------|
| **Retained advisory** | A fixed number of hours per month for questions, threat model reviews, architecture reviews, and strategic guidance. No new module delivery — advisory only. | Monthly retainer, 8–16 hours/month |
| **Retained capability support** | Active support operating tools we deployed: reviewing ASTRAL alerts, tuning AOC detection rules, running quarterly AD scans with Elysium and PingCastle, reviewing Huntress findings. | Monthly or quarterly, scoped per tool set |
| **Module continuation** | Ongoing delivery of a multi-module programme at a structured cadence. Each module planned and scoped before it begins. | Quarterly module delivery |
Retained relationships are renewed quarterly. Either side can exit with 30 days' notice.
---
## Section 3: What We Ask of the Client
The most common cause of engagement delay is access that should have been provisioned before day 1 but was not. These are the standing requirements:
### Mandatory for every engagement
| Requirement | Why it matters |
|-------------|---------------|
| **Named client lead with decision authority** | One person who can approve changes, unblock access, and respond within 24 hours. Without this, every decision becomes a committee meeting. |
| **Administrative access — provisioned before day 1** | Read access for the baseline week; write access confirmed before changes begin. Accounts, MFA enrollment, and permissions confirmed in writing before kickoff. |
| **Existing documentation** | Whatever exists: network diagrams, asset lists, previous audit reports, incident post-mortems. Imperfect documentation is far better than none. |
| **Weekly 30-minute check-in** | Standing, calendar-blocked before kickoff. The engagement rhythm depends on it. |
| **Tolerance for uncomfortable findings** | The Brownhat Diagnostic and the first week of any module will surface things nobody wanted to surface. That is the point. The client's job is to receive findings honestly. |
### Module-specific requirements
Each module documents its prerequisites in detail in [Modular Engagements](modular-engagements.md). Common examples:
| Scenario | Access requirement |
|----------|-------------------|
| M365 modules (1–5) | Global Admin access or appropriately scoped Graph API permissions; pipeline access for ASTRAL deployment |
| AD Hardening (Module 6) | Domain Admin access; access to all domain controllers; a maintenance window for KRBTGT rotation |
| OT Security (Module 8) | OT network diagram; OT engineer participation (not just IT); vendor contact list for OT systems |
| Blue/Purple Team (Module 12) | Written authorisation for red team activities; defined out-of-scope systems list; incident response lead identified |
| Privileged Access (Module 13) | Network topology; full list of privileged accounts and service accounts; existing PAM tool inventory |
### What we do not require
- **A clean environment.** We work in brownfield by design. If your environment were clean, you would not need us.
- **Pre-approved budgets for new tools.** Every engagement starts with what you own. Purchases are recommended only after we demonstrate the gap cannot be closed with existing investments.
- **A dedicated project team.** Most modules require one named lead and part-time IT admin access. We bring the methodology; you provide the context.
---
## Section 4: What the Client Receives
| Stage | Deliverable |
|-------|-------------|
| Brownhat Diagnostic | Current-state assessment report (6-domain, kill chain, quick wins) + prioritised module roadmap |
| Module kickoff | Written scope agreement; access checklist confirmation; communication channel setup |
| Weekly (during delivery) | Change log update; check-in summary (decisions made, items pending, risks) |
| Module completion | Configuration baseline document; scripts/rules in client repository; operating runbooks; risk register update; metrics baseline; next-step recommendation |
| Retained relationship | Monthly advisory summary or capability review report |
**Ownership**: Every script, detection rule, query, configuration file, and document produced during an engagement belongs to the client permanently. We do not retain privileged access to client environments after an engagement closes. We do not license anything we build — it is yours.
**Format**: Deliverables are produced in Markdown, delivered to the client's own repository (our preference). Word or PDF formats are available on request. We do not lock clients into proprietary tools for accessing their own documentation.
---
## Section 5: Pricing and Commercial Model
### The Brownhat Diagnostic
The Brownhat Diagnostic is priced as a fixed-scope engagement:
| Component | Hours |
|-----------|-------|
| Pre-engagement preparation | 2 |
| Workshop Session 1 (half-day) | 4 |
| Workshop Session 2 (half-day) | 4 |
| Report preparation | 4–8 |
| Report presentation and Q&A | 2 |
| **Total consultant time** | **16–20 hours** |
Travel and accommodation billed at cost for in-person delivery. Remote delivery (camera-on, strongly preferred for the diagnostic) carries no additional charge.
### Module Pricing
Modules are priced on a **fixed-scope, fixed-deliverable basis** — not time and materials. Before an engagement starts, the client knows exactly what they are paying for and exactly what they will receive. The price is agreed in writing before work begins. There are no end-of-engagement surprises.
Module investment levels correspond to estimated consultant effort:
| Level | Estimated consultant effort |
|-------|-----------------------------|
| **Very low** | Under 3 consultant days |
| **Low** | 3–8 consultant days |
| **Low to medium** | 8–15 consultant days |
| **Medium** | 15–30 consultant days |
| **Medium to high** | 30–50 consultant days |
| **High** | 50+ consultant days; typically multi-phase programmes |
Per-module investment levels are documented in [Modular Engagements](modular-engagements.md). The specific day rate applied to these estimates is stated in each engagement proposal and agreed before kickoff.
### Infrastructure and licensing costs
Some modules carry small infrastructure costs that are invoiced separately at cost:
| Item | Typical cost | Module |
|------|-------------|--------|
| Delta Chat chatmail relay (VPS) | €5–10/month | All engagements — out-of-band channel |
| Matrix/Element hosting | Varies by deployment model | Module 14 (Sovereign Communications) |
| Teleport Enterprise licensing | Per-user, varies | Module 13 for non-qualifying clients |
| Tailscale | Per-user, varies | Module 13 where Headscale is not preferred |
Open-source tools (BloodHound, Wazuh, Elysium, CAExporter, E8-CAT, and the rest of the sovereign tool stack) carry no licensing cost.
### Multi-module programmes
Clients committing to a multi-module programme (typically 3+ modules, scoped in advance) receive:
- A single programme scoping session replacing individual module kickoffs
- A programme-level risk register maintained continuously across all modules
- Priority scheduling with module slots reserved in advance
- A reduced overall rate versus individual module pricing (agreed at programme scope)
### Retained relationship pricing
Retained advisory and capability support is billed monthly at a fixed rate for a minimum quarterly commitment. The rate reflects reserved hours per month and the agreed response-time commitment.
### What is never billable
- Repeat work caused by our own errors
- Re-delivery of documentation that was deficient at handover
- Out-of-scope additions we accepted without a written change order
- Tools and scripts we produce — these are included in the module, not licensed separately
### The "existing tools first" principle and its commercial implication
Our explicit commitment to maximising existing investments before recommending purchases means our engagements are priced primarily on labour, not licence margins. We earn the same whether we deploy Wazuh (free) or recommend Huntress (commercial partnership). We do not earn more from an engagement if the client buys new tools.
When we recommend a commercial tool, the recommendation is because the gap genuinely requires it. When we have a commercial partnership (Huntress, Tailscale, Thinkst Canary, Tenable), that relationship is disclosed at the time of recommendation.
*For the ROI and risk quantification framework, see [Business Case Template](business-case-template.md).*
---
## Section 6: Communication and Governance
### The standing check-in
Every active module has a 30-minute weekly check-in with the named client lead. This is the primary governance mechanism for the engagement. It is not optional and not reschedulable without 24 hours' notice.
**Agenda**:
1. Change log review (5 minutes): what was completed since last week
2. Active work (10 minutes): what is being delivered this week
3. Client decisions required (10 minutes): approvals, access requests, scope questions
4. Risks and open issues (5 minutes)
Meeting notes are shared within 24 hours. All action items have a named owner and a due date.
### The steering committee (for multi-module programmes)
For programmes spanning multiple modules or involving significant organisational change, a monthly 60-minute steering committee is recommended:
- **Attendees**: Executive sponsor, named client lead, CQRE consultant lead
- **Agenda**: Module progress summary, risk register review, next module decision, budget review
- **Output**: Written decision record, updated programme plan
### Escalation
| Situation | Action |
|-----------|--------|
| Change carries significant production risk | Written approval from named client lead before execution |
| Change requires budget beyond agreed scope | Escalated to executive sponsor; work paused until approved |
| Security incident discovered during engagement | Client notified immediately; scope adjusted by written agreement; incident response activated if required |
| Named client lead unavailable for more than 5 business days | Engagement paused; billing suspended |
| Scope extension requested by client | Written change order agreed and signed before additional work begins |
### The out-of-band channel
Before any module begins, all named participants — client lead, executive sponsor, key technical contacts, and the CQRE consultant lead — are enrolled in a Delta Chat channel on an independent chatmail relay. This setup takes under 10 minutes and costs nothing.
This channel is used for:
- Sensitive findings that should not travel through corporate email or Teams
- Incident coordination when corporate channels are unavailable or compromised
- Out-of-hours escalation for urgent decisions
**This channel is not optional.** The rationale is simple: if the engagement is active when corporate infrastructure is experiencing an incident, we need a communication path that does not depend on the infrastructure under attack.
*For setup instructions, see [Sovereign Communications](../playbooks/sovereign-communications.md).*
---
## Section 7: For the Consultant — Scoping, Pricing, and Delivery
*This section is for internal use. It is not typically shared with clients.*
---
### The rules you cannot break
**1. The Brownhat Diagnostic is always the entry point.**
A client who wants to skip the diagnostic and go straight to a module is a client whose scope will be undefined, whose success criteria will be undefined, and whose hidden problems will surface mid-engagement. The diagnostic is not a formality — it is how we prevent the most common failure mode in consulting. The one exception (active incident) is documented in Section 1.
**2. Fixed scope, fixed deliverable, written before work starts.**
Never begin delivery without a signed scope agreement that lists exactly what will be produced and what the completion criteria are. "We will improve the client's AD security" is not a scope. "We will deliver: a BloodHound attack path analysis; an Elysium password audit with remediation list; LAPS deployed to 100% of domain-joined workstations; KRBTGT rotation; a Tier 0 admin account audit; and a runbook reviewed and signed off by the client lead" — that is a scope.
**3. The client owns everything we produce.**
Scripts go into the client's repository. Detection rules are documented in the client's SIEM. Runbooks live in the client's wiki. Nothing should require our return. If at the end of an engagement the client cannot operate what we built without calling us, the handover is not complete.
**4. Knowledge transfer is a deliverable.**
Build time for knowledge transfer into every scope estimate. A runbook is not a knowledge transfer. A runbook plus a walkthrough with the client's team is a knowledge transfer. The test: can the client's named IT lead explain to a new colleague how to use what we built, without asking us?
**5. Week 1 is always documentation and baseline — no changes.**
This is non-negotiable. The temptation to start fixing things immediately is understandable. Resist it. The discipline of a baseline week protects both the client and the consultant. It makes the before-and-after visible. It surfaces scope surprises before they become billing disputes.
---
### Scoping discipline
When estimating a module, use this framework:
**Step 1: Root the estimate in the Brownhat Diagnostic findings.**
What specific gaps does this module close? How severe and how complex are they? A Module 6 engagement for a 200-seat organisation with 15 years of AD debt takes materially longer than the same module for a recently built 50-seat environment. The diagnostic findings should drive the estimate, not the module's nominal duration.
**Step 2: Assess client capacity.**
How available is the named client lead? Does the client have an IT admin who can own parts of the rollout, or must we do everything? A capable internal sysadmin who can execute the LAPS deployment while we focus on the AD architecture review is a different scope than a client where we are the only technical resource.
**Step 3: Identify prerequisites and risks.**
Missing prerequisites mean delay. Scope estimates that assume prerequisites are already met are optimistic estimates. For any prerequisite that is "in progress" rather than "confirmed," add buffer.
**Step 4: Define completion criteria explicitly.**
Not "when we've improved the client's identity security." But: "when MFA is enforced for 100% of users (verified via Conditional Access sign-in logs), legacy authentication is blocked tenant-wide (verified via CAExporter export and sign-in log review), all Global Admin accounts have been converted to JIT access via PIM or manual process, and the runbook is reviewed and signed off by the client lead." Completion criteria that cannot be verified are not completion criteria.
**Step 5: Write the scope agreement before kickoff — not during, not after.**
---
### Pricing conversations
**The Brownhat Diagnostic pitch**:
> *"Before we recommend anything, we need to understand exactly where you are. This assessment takes two half-days and produces a report you can use independently of us — your strengths, your gaps, and the three things that matter most to fix first. It is a paid engagement because our time has value and your assessment has value. If you decide not to proceed with any module, you still have a prioritised roadmap. That is a good outcome for you."*
**The fixed-scope pitch**:
> *"We price by deliverable, not by the hour. You know exactly what you are paying for before we start, and you know exactly what you will receive. There are no 'the scope was larger than we expected' surprises at invoice time. If scope changes, we write a change order before we do the work."*
**The "existing tools first" pitch**:
> *"We do not earn more if you buy new tools. Our first obligation is to extract the value you have already paid for. The recommendation to buy something comes only when we can demonstrate that your existing tools cannot close the specific gap."*
**When the client asks for a discount**:
Do not discount the Brownhat Diagnostic. It is already priced below its value — the roadmap alone is worth more than the workshop cost for most clients. For module pricing, a multi-module commitment justifies a programme rate. A single module discount signals that the price was not honest to begin with.
---
### Handling scope creep
Scope creep is expected — the client discovers adjacent problems as we work. The correct response is not to absorb unlimited scope silently and then present a large invoice, and it is not to refuse everything that was not in the original document.
1. Note the new request in writing in the same session it is raised
2. Assess: is it within the agreed completion criteria?
- **Within scope**: absorb it; document it in the change log; no charge
- **Outside scope**: write a change order before doing the work
3. The change order states the additional effort, the revised completion criteria, and the additional cost — agreed and signed before execution
4. Never retroactively charge for out-of-scope work that you did without a change order
The most common form: *"While you're in here, can you also look at X?"* The correct answer: *"Yes, we can include that. Let me scope it — probably [N] additional days. I'll send a change order this afternoon. Do you want to confirm before we start on it, or shall I include it in the current sprint?"*
---
### When the client pushes back on open-source
Three underlying objections, each with a different correct response:
**"Our auditor requires a vendor-backed tool."**
Establish whether this is a real requirement or an assumed one. Many "needs a vendor tool" requirements are actually "needs documented evidence" — which open-source produces equally well. Ask: "What specifically does the auditor require?" If it genuinely requires a vendor logo and attestation, route to the appropriate commercial partnership. If it requires evidence and documentation, show them that BloodHound + CISO Assistant produces audit-ready evidence that any commercial tool would produce.
**"We tried open-source before and it was too complex."**
This is a deployment and maintenance problem, not a capability problem. Address the real concern directly: *"Who will maintain it after we leave?"* If the answer is "nobody reliable," the sovereign stack requires a retained capability support arrangement, or the commercial partnership tier is the right recommendation.
**"We want vendor support."**
Respect this as a legitimate position. Not every client wants to own their tools. For these clients, the commercial partnership tier (Huntress, Tenable, Tailscale) is the right answer, supplemented by our managed deployment and ongoing advisory retainer. Document the trade-off (cost, sovereignty) so the client makes an informed decision.
---
### When the client wants to skip the diagnostic
*"We know what we need. Just do Module 6."*
A client with recent, credible environment documentation — a post-incident forensic report, a recent third-party assessment, or a previous Brownhat Diagnostic — can proceed to module scoping with a condensed discovery session rather than the full diagnostic. If they have that documentation, use it.
If they do not have it, the honest response is:
> *"The diagnostic costs less than the overtime we will spend fixing scope surprises mid-module. I will never recommend skipping it unless you have equivalent documentation. What do you have?"*
If they insist without adequate documentation, document the risk in writing, scope conservatively, and add buffer for the discoveries week 1 will produce.
---
### When the client's IT team is resistant
Internal IT teams sometimes perceive external consultants as a threat to their position or a criticism of their work. Signs: slow access provisioning, minimal engagement in check-ins, information provided grudgingly.
The correct posture:
- Make the IT lead a co-deliverer, not a subject. Their knowledge of the environment is essential; frame the engagement as structured support, not inspection.
- Credit their existing work publicly in the kickoff and in every report
- Never phrase findings as failures of the IT team — phrase them as consequences of resource constraints, technical debt, or changing threat landscape
- If resistance is blocking delivery, escalate to the named client lead privately, not in a group setting
---
### The first week checklist
Regardless of module, week 1 produces:
- [ ] Configuration export (ASTRAL snapshot for M365; BloodHound + Purple Knight run for AD; CAExporter export for identity; or equivalent)
- [ ] Baseline security score (E8-CAT, PingCastle, or module-appropriate tool)
- [ ] Gap analysis against module completion criteria: is the agreed scope still the right scope?
- [ ] Updated scope confirmation signed by client lead: proceed as scoped / amend scope / escalate
- [ ] Week 2 plan with explicit client approval of any changes to be made
---
## Integration With Existing Frameworks
| Document | Integration |
|----------|-------------|
| [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md) | The Brownhat Diagnostic methodology, questionnaires, and report structure |
| [Modular Engagements](modular-engagements.md) | Module descriptions, durations, investment levels, and completion deliverables |
| [Move Fast and Fix Things](move-fast-and-fix-things.md) | The Brownhat methodology and engagement posture that underlie Section 7 |
| [Sovereign Communications](../playbooks/sovereign-communications.md) | Delta Chat out-of-band channel setup referenced in Section 6 |
| [Retained Capability](retained-capability.md) | The retained relationship model described in Section 2 |
| [Business Case Template](../playbooks/business-case-template.md) | ROI and risk quantification framework for the pricing conversations in Section 5 and 7 |
| [C-Suite Conversation Guide](c-suite-conversation-guide.md) | Executive communication scripts that complement the engagement framing in this document |
| [Sovereign Tool Stack](../playbooks/sovereign-tool-stack.md) | The commercial partnership doctrine and the "existing tools first" principle referenced in Section 5 |
---
*For the entry assessment, see [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md).*
*For the module menu, see [Modular Engagements](modular-engagements.md).*
*For financial justification, see [Business Case Template](../playbooks/business-case-template.md).*
> *Sections 1–6 of this document are client-facing. A Czech translation for use with Czech-speaking clients is planned as `engagement-model-cs.md`.*
antifragile-consulting/core/executive-summary-cs.md
+76
View File
@@ -0,0 +1,76 @@
# Antifragilní podnik — Výkonné shrnutí
> *Pro představenstvo, generálního ředitele a vedení společnosti. Jedna strana. Pět minut. Rozhodnutí, které určí, zda organizace přežije svůj příští otřes.*
---
## Problém v jedné větě
Vaše organizace se v tuto chvíli podílí na **rozsáhlém neplacené výzkumu pro konkurenci** — odesílá vlastnická data, strategické uvažování a provozní informace do cloudových platforem, které mají zájem na znehodnocení vašeho odvětví.
## Co je v sázce
| Kategorie aktiv | Současné riziko | V případě kompromitace nebo zcizení |
|----------------|----------------|--------------------------------------|
| Strategické zpravodajství | Pronajato od poskytovatelů cloudové AI | Konkurenti kopírují vaši výhodu; vaše strategie se stává veřejnými trénovacími daty |
| Důvěra zákazníků | Chráněna formálními procesy | Regulatorní pokuty, odpovědnost za škody, nevratné poškození reputace |
| Provozní kontinuita | Závislá na stabilitě dodavatele | Jediná změna API nebo geopolitická událost zastaví procesy kritické pro příjmy |
| Technické talenty | Plýtvají se na údržbu fragilních systémů | Vyhoření, odchody, neschopnost přilákat bezpečnostně orientované inženýry |
| Regulatorní licence | Předpokládaná, ne prokázaná | DORA, NIS2, PSD2 a národní regulátoři nyní vyžadují prokazatelnou odolnost — ne papíry |
## Antifragilní alternativa
Antifragilní organizace nezahyne při otřesu. **Každý incident produkuje strukturální zlepšení. Každý neúspěch konkurence vytváří tržní příležitost. Každý regulatorní požadavek je splněn důkazy, ne sliby.**
### Pět pilířů (v jazyce vedení)
| Pilíř | Co vedení slyší |
|-------|----------------|
| **Strukturální oddělení** | „Nikdy nebudeme znovu rukojmím jednoho dodavatele, jeho ceníku, podmínek nebo existence." |
| **Zachování opcí** | „Zachováváme si právo změnit směr za 90 dní, ne za 9 měsíců." |
| **Přeměna stresu na signál** | „Každý neúspěch nás učiní chytřejšími a strukturálně silnějšími." |
| **Svrchované zpravodajství** | „Naše proprietární data zlepšují naše vlastní modely, ne modely konkurentů." |
| **Design asymetrického výnosu** | „Malé, cílené investice nás chrání před existenčními riziky." |
## Strategický mandát: AI suverenita
Současné paradigma AI je **extraktivní**. Každý dotaz odeslaný do cloudové AI učí tento systém, jak vás nahradit. Provozováním umělé inteligence na infrastruktuře, kterou kontrolujete, dosáhnete:
- **Ochrany duševního vlastnictví** — nebude součástí veřejných trénovacích dat
- **Provozní kontinuity** — bez závislosti na rozhodnutích dodavatele, geopolitice nebo změnách API
- **Snížení dlouhodobých nákladů** — nepředvídatelné ceny za dotaz se změní na fixní infrastrukturní výdaje
- **Prokázání regulatorní zralosti** — auditorům, kteří stále více prověřují umístění dat a rizika třetích stran
> *„Kdyby podnikové zpravodajství vaší společnosti bylo hromadou fyzické hotovosti, uložili byste ji ve veřejné bance, která si účtuje 'tréninkový poplatek' z každé koruny a vyhrazuje si právo přes noc změnit měnu? Nebo byste ji uchovávali ve vlastním trezoru?"*
Lokální AI je trezor.
## Závazek na 180 dní
Nenavrhuji tříletou transformaci. Navrhuji **čtyři fáze, 180 dní, měřitelné výsledky**:
| Fáze | Časový horizont | Výsledek pro podnik |
|------|----------------|---------------------|
| **Hygiena** | Dny 0–30 | Viditelnost. Vidíme každou identitu, každé aktivum, každou mezeru, která by mohla společnost zničit. |
| **Kontrola** | Dny 30–60 | Omezení. Zavíráme nejrizikovější expozici stávajícími nástroji — bez nových nákupů. |
| **Suverenita** | Dny 60–90 | Vlastnictví. Přebíráme kontrolu nad proprietárními informacemi a ověřujeme schopnost zotavit se z incidentu. |
| **Antifragilita** | Dny 90–180 | Výhoda. Přeměňujeme narušení na ponaučení a ponaučení na tržní pozici. |
## Rámec investic
Toto není nákladové středisko. Je to **pojistka zachování opcí**.
- **Náklady programu**: Primárně konfigurace a procesy — nejprve se využívají stávající nástroje.
- **Náklady nečinnosti**: Průměrná záchrana po útoku ransomwarem stojí 4,5 mil. EUR. Jedna pokuta dle DORA může dosáhnout 2 % celosvětového obratu. Jeden konkurent natrénovaný na vašich datech znehodnotí vaši proprietární výhodu.
- **Návratnost investic**: Snížení rizika je viditelné do 30 dní. Regulatorní důkazy jsou prokazatelné do 90 dní. Konkurenční výhoda ze svrchovaného zpravodajství se kumuluje po dobu 12–24 měsíců.
## Požadované rozhodnutí
Potřebujeme **jednoho výkonného sponzora s pravomocemi**, **jedno setkání řídícího výboru týdně** a **toleranci k dočasným narušením** v prvních 30 dnech. Alternativou je pokračovat v provozu se skrytými závislostmi, nemapovanými riziky a strategií zpravodajství, která obohacuje konkurenci.
---
*Pro podrobný strategický argument viz [The Antifragile Manifest](antifragile-manifest.md).*
*Pro průvodce konverzací s vedením viz [Průvodce rozhovorem s vedením](c-suite-conversation-guide.md).*
*Pro finanční zdůvodnění viz [Šablona obchodního případu](../playbooks/business-case-template.md).*
*Anglická verze: [Executive Summary](executive-summary.md)*
antifragile-consulting/core/executive-summary.md
+1
View File
@@ -73,3 +73,4 @@ We need **one executive sponsor with authority**, **one steering committee meeti
*For the detailed strategic argument, see [The Antifragile Manifest](antifragile-manifest.md).*
*For the board conversation guide, see [C-Suite Conversation Guide](c-suite-conversation-guide.md).*
*For financial justification, see [Business Case Template](../playbooks/business-case-template.md).*
*Česká verze: [Výkonné shrnutí](executive-summary-cs.md)*
antifragile-consulting/core/modular-engagements.md
+187 -16
View File
@@ -68,6 +68,7 @@ We do not sell monolithic transformation projects. We sell **building blocks** t
**What is delivered**:
- Full identity census: human accounts, service accounts, guests, enterprise apps
- **CA policy register** (CAExporter export): readable documentation of every Conditional Access policy before any changes are made
- MFA enforcement for 100% of users (conditional access with MFA for E3; risk-based conditional access and PIM for E5)
- Legacy authentication blocked tenant-wide
- Privileged access workstation (PAW) architecture for admins
@@ -189,6 +190,7 @@ We do not sell monolithic transformation projects. We sell **building blocks** t
**What is delivered**:
- Full AD identity census with orphan and privilege analysis
- **Elysium password audit**: weak and compromised credential check across all domain accounts; P0 remediation list for accounts on high-value attack paths
- KRBTGT password rotation (if > 180 days stale)
- LAPS deployment to all domain-joined workstations
- Sysmon deployment with SwiftOnSecurity configuration
@@ -362,7 +364,7 @@ We do not sell monolithic transformation projects. We sell **building blocks** t
|-----------|--------|
| **Typical duration** | 60-90 days |
| **Typical investment** | Medium (labor; leverages existing Microsoft security stack) |
| **Prerequisites** | Microsoft Defender (E5) or equivalent EDR; at least one security analyst; willingness to learn |
| **Prerequisites** | An operational EDR — Microsoft Defender E5, CrowdStrike, SentinelOne, or open-source Wazuh+Sysmon (see [Sovereign Tool Stack](../playbooks/sovereign-tool-stack.md) for the zero-cost path); at least one security analyst; willingness to learn |
| **Standalone value** | Operating rhythm for SOC; first guided threat hunt; purple team charter; 12-month capability roadmap |
| **Typical client** | Organizations that own E5/Defender/Sentinel but underutilize them; SOC drowning in noise; no hunt discipline; red and blue teams do not collaborate |
@@ -385,6 +387,72 @@ We do not sell monolithic transformation projects. We sell **building blocks** t
---
### Module 13: Privileged Access Architecture
**The Access Control Module. Replace VPN Sprawl With a Two-Layer Architecture.**
| Attribute | Detail |
|-----------|--------|
| **Typical duration** | 30-60 days |
| **Typical investment** | Low to medium (labor; Teleport CE is free for qualifying clients; Tailscale is per-user commercial) |
| **Prerequisites** | Administrative access to network infrastructure; identity provider (Entra ID, Okta, Google, or any OIDC provider) |
| **Standalone value** | Legacy VPN replaced or supplemented; privileged access recorded; vendor access time-bounded and auditable |
| **Typical client** | Any organisation with legacy VPN sprawl; OT clients with uncontrolled vendor remote access; post-breach clients needing access hardening |
**What is delivered**:
- Access architecture design: which layer handles network access, which handles protocol-aware PAM
- Teleport CE or Enterprise deployment (SSH, RDP, Kubernetes, database proxying; session recording; JIT access)
- Tailscale or Headscale + WireGuard deployment (network-level mesh access)
- Access policy design: who reaches what, when, recorded how
- Vendor access governance: time-bounded, request-approve-record workflow for all third-party access
- Admin training and operational handover
**Executive pitch**:
> *"Your VPN gives everyone on it access to everything behind it. Your vendor credentials have not been rotated in two years. Your admins log into production servers from laptops they also use for email. In 30 days, we replace that with a system where every access request is approved, every session is recorded, and every credential expires the moment it is no longer needed. Your auditor will be able to watch a video of every administrative action ever taken on every critical server."*
**Natural next modules**: Module 2 (Identity Security), Module 6 (On-Premise AD), Module 8 (OT Security)
**See**: [Privileged Access Architecture](../playbooks/privileged-access-architecture.md)
---
### Module 14: Sovereign Communications
**The Resilience Module. Communication That Survives an Incident.**
| Attribute | Detail |
|-----------|--------|
| **Typical duration** | 1-5 days (Delta Chat chatmail); 2-10 days (Matrix/Element) |
| **Typical investment** | Very low (€5-10/month infrastructure for Delta Chat chatmail relay; labor minimal) |
| **Prerequisites** | None — this module has no technical prerequisites |
| **Standalone value** | An operational out-of-band communication channel independent from corporate IT; tested and documented in the incident response plan |
| **Typical client** | Any organisation whose incident response plan assumes Teams or email will be available; OT/utilities/telco operators; organisations with recent breaches or near-misses |
**What is delivered**:
*Tier 1 — Delta Chat (always delivered):*
- Chatmail relay deployed on independent cloud infrastructure (10 minutes; €5-10/month)
- Key personnel enrolled: incident response team, executives, OT operators (as applicable)
- Out-of-band channel documented in incident response runbooks
- Crisis channel tested with a simulated incident
*Tier 2 — Matrix/Element (if full platform warranted):*
- Synapse server deployed (CQRE-managed or client on-premises)
- SSO integration (Entra ID, Okta, Google Workspace)
- Persistent rooms configured for operational teams, incident response, management
- Migration guide for users moving from Teams/Slack
**Executive pitch**:
> *"Your incident response plan says to use Teams. Teams runs on Microsoft's infrastructure, authenticated by your Active Directory, connected through your network. If any of those three things are the incident, your response channel is gone too. We deploy a €7/month server today — it takes ten minutes — that gives your entire response team an encrypted channel on their personal phones, completely independent from everything else you run. This is the cheapest, fastest risk reduction in this entire engagement."*
**Natural next modules**: Module 7 (Recovery & Resilience), Module 8 (OT Security), Module 2 (Identity Security)
**See**: [Sovereign Communications](../playbooks/sovereign-communications.md)
---
## Module Selection Guide
### For the Client Who Knows Their Pain
@@ -404,22 +472,32 @@ We do not sell monolithic transformation projects. We sell **building blocks** t
| "We don't feel in control" | Module 11: Embedded Quality Assurance | 60-90 days |
| "We own tools but can't use them" | Module 12: Blue/Purple Team Foundation | 60-90 days |
| "Our outsourced SOC underperforms" | Module 12 (+ Retained Capability Audit) | 60-90 days |
| "Mythos/AI will find all our vulnerabilities" | AI-assisted TVM Sprint | 30-90 days |
| "AI-powered attackers will outpace our response" | AI-Assisted TVM Sprint | 30-90 days |
| "Our VPN is a mess / vendors have too much access" | Module 13 (Privileged Access Architecture) | 30-60 days |
| "We need a crisis communication channel" | Module 14 (Sovereign Communications) | 1-5 days |
| "We don't know where to start" | Brownhat Diagnostic (NIST CSF Baseline) | 5-10 days |
### For the Client Who Does Not Know Where to Start
**The Diagnostic Path**:
**The Brownhat Diagnostic** — a paid, structured [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md):
1. **Week 1: Kill Chain Assessment** (included in scoping; no charge)
- Interview stakeholders
- Identify the shortest path to organizational failure
- Recommend the module that closes the most critical gap
1. **Two half-day workshops** with key stakeholders (CIO/CISO, IT lead, one business owner)
- No tools installed; no data collected from systems
- Structured questionnaire across all six NIST CSF 2.0 domains
- Produces an honest picture of current state, not a desired-state checklist
2. **Module selection based on kill chain**:
2. **Deliverables** (5 business days after workshop):
- Current state report: strengths, gaps, and kill chain analysis
- Prioritised module roadmap aligned to findings
- Up to 5 quick wins executable immediately with existing tools
3. **Module selection based on kill chain**:
- Kill chain starts with compromised endpoint → Module 1
- Kill chain starts with stolen credentials → Module 2
- Kill chain starts with unrecoverable systems → Module 7
- Kill chain starts with OT bridge → Module 8
- Kill chain starts with uncontrolled vendor/privileged access → Module 13
- No out-of-band crisis comms capability → Module 14 (deploy immediately, 1 day)
---
@@ -429,14 +507,15 @@ We do not sell monolithic transformation projects. We sell **building blocks** t
```
Month 1-2: Module 1 (Endpoint Management)
↓ Discovers identity and AI gaps
Month 2-3: Module 2 (Identity Security)
↓ Discovers identity and security configuration gaps
Month 2-4: Module 2 (Identity Security) + Module 3 (M365 Security Hardening)
[run in parallel — identity and configuration are different workstreams]
↓ Discovers compliance and data gaps
Month 4-5: Module 4 (Data Governance)
Month 5-6: Module 4 (Data Governance)
↓ Discovers AI shadow usage
Month 5-6: Module 5 (AI Sovereignty Bridge)
Month 6-7: Module 5 (AI Sovereignty Bridge)
↓ Discovers architectural fragility
Month 7-12: Module 10 (Red Team) + selected hardening
Month 8-12: Module 10 (Red Team) + selected hardening
```
### Path B: The Hybrid Infrastructure Organization
@@ -476,11 +555,13 @@ Month 5-7: Module 2 (Identity Security) + Module 3 (M365 Hardening)
Month 8-12: Module 10 (Red Team) + continuous improvement retainer
```
### Path E: The "Mythos / AI Vulnerability Panic" Organization
### Path E: The "AI-Adversary" Organization
*For clients whose leadership has recognized that AI-powered scanners, exploit generators, and vulnerability-discovery tools have permanently shortened the attacker's window.*
```
Week 1-2: AI-assisted TVM Baseline Sprint
↓ Discovers actual exploitable attack surface; beats adversary AI to first move
Week 1-2: AI-Assisted TVM Baseline Sprint
↓ Maps actual exploitable attack surface before adversary tooling does
Month 1-2: Module 1 (Endpoint Management) + Module 2 (Identity Security)
↓ Closes the highest-risk doors while AI TVM operationalizes
Month 2-3: Module 3 (M365 Security Hardening) + AI TVM operationalization
@@ -568,5 +649,95 @@ For clients ready to commit to a multi-module journey, offer **discounted bundle
---
## Platform Adaptation: Non-Microsoft Environments
The strategic framework, assessment methodology, and tool stack (Modules 6–12) are fully platform-agnostic. Modules 1–5 use Microsoft 365 as the primary reference environment because it is the dominant client footprint—but every module has direct equivalents on other platforms.
**The principle never changes. The tool that implements it does.**
### Module 1: Endpoint Management Foundation
| Environment | Equivalent Tooling |
|-------------|-------------------|
| Microsoft (default) | Intune + Entra ID |
| Apple-heavy | Jamf Pro or Kandji + Entra ID (BYOD) |
| Mixed SMB | JumpCloud MDM or NinjaRMM |
| Linux-heavy | Ansible + osquery (see [Sovereign Tool Stack](../playbooks/sovereign-tool-stack.md)) |
| Multi-platform enterprise | VMware Workspace ONE or Ivanti |
### Module 2: Identity Security
| Environment | Equivalent Platform |
|-------------|-------------------|
| Microsoft 365 | Entra ID — Conditional Access, PIM, SSPR |
| Google Workspace | Cloud Identity + BeyondCorp Enterprise |
| Independent IdP | Okta (MFA, lifecycle), JumpCloud, or self-hosted Authentik |
| AWS-native | IAM Identity Center + SCPs + CloudTrail |
| Legacy/hybrid | Okta or Ping Identity as federation layer over AD |
**The non-negotiables remain identical across all platforms**: MFA on every account, no shared admin credentials, least-privilege access, full audit logging, and PAW architecture for administrators.
### Module 3: Security Hardening
| Environment | Equivalent Approach |
|-------------|-------------------|
| Microsoft 365 | Secure Score + EOP + ASR rules + LAPS |
| Google Workspace | Admin Security Health Advisory + Workspace Security Advisor + Alert Center |
| AWS | Security Hub + Config Rules + GuardDuty + CloudTrail validation |
| Multi-cloud | Prowler (covers AWS, Azure, GCP — see [Sovereign Tool Stack](../playbooks/sovereign-tool-stack.md)) |
### Module 4: Data Governance and Compliance
| Environment | Equivalent Tooling |
|-------------|-------------------|
| Microsoft 365 | Microsoft Purview (sensitivity labels, DLP, retention) |
| Google Workspace | Google Vault + DLP + Drive labels |
| Cloud-native | AWS Macie (data discovery) + S3 Object Lock (retention) |
| Platform-agnostic | CISO Assistant (open-source GRC) for evidence tracking regardless of platform |
### Module 5: AI Sovereignty Bridge
| Environment | Approach |
|-------------|---------|
| Azure (default) | Azure OpenAI Service + Private Endpoints + Foundry |
| AWS | Amazon Bedrock + VPC endpoints + AWS PrivateLink |
| Self-hosted / sovereign | Ollama or vLLM + quantized open models (Llama 3, Mistral, Phi) |
| Hybrid regulated | On-premise inference + Azure or AWS for burst capacity with data boundary controls |
**The sovereignty test is the same regardless of platform**: Does your proprietary data leave your environment? Can you audit what the model sees? Can you operate if the provider goes down?
### Path F: The Non-Microsoft Organization
```
Month 1-2: Module 6 (On-Premise AD Hardening) if AD is present
— OR —
Module 2 equivalent (Okta / JumpCloud / Google Identity hardening)
↓ Establishes identity foundation
Month 2-3: Module 1 equivalent (Jamf / JumpCloud MDM / Ansible endpoint management)
↓ Establishes device visibility and compliance baseline
Month 3-4: Module 3 equivalent (Prowler cloud scan / Google Workspace hardening)
↓ Closes misconfiguration and hardening gaps
Month 5-6: Module 8 (OT Security) if critical infrastructure
— OR —
Module 9 (Organizational Resilience) if development-heavy
Month 7-12: Module 10 (Red Team) + Module 12 (Blue/Purple Team Foundation)
```
**The Sovereign Tool Stack remains unchanged**: BloodHound, osquery, Prowler, CISO Assistant, Wazuh, TheHive, and the rest of the arsenal operate independently of Microsoft licensing.
---
## Integration With Existing Frameworks
| Document | Integration |
|----------|-------------|
| [Rapid Modernisation Plan](../playbooks/rapid-modernisation-plan.md) | Each module maps to one or more rapid modernisation phases |
| [Business Case Template](../playbooks/business-case-template.md) | Modular pricing structure; per-module ROI |
| [C-Suite Conversation Guide](c-suite-conversation-guide.md) | Modular pitching scripts and objection handling |
| [M365 Antifragile Project](../playbooks/m365-antifragile-project.md) | Modules 1-5 map directly to M365 project workstreams |
| [Antifragile Risk Register](../assessment-templates/antifragile-risk-register.md) | Each module closes a defined risk category |
---
*For the full 180-day rapid modernisation plan, see [Rapid Modernisation Plan](../playbooks/rapid-modernisation-plan.md).*
*For module-specific tactical guidance, see the linked playbooks in each module description.*
antifragile-consulting/core/move-fast-and-fix-things.md
+21
View File
@@ -6,6 +6,27 @@ This document anchors the antifragile consulting practice in a single, actionabl
---
## The Brownhat Methodology
This practice operates under the **Brownhat** brand when engaging clients. The name is deliberate:
- **Brownfield** — industrial land that has been used, built on, and left with the legacy of past decisions. Every mature organisation's security environment is a brownfield: layers of partially implemented tools, forgotten configurations, and "temporary" solutions that became permanent.
- **Blackhat / Whitehat** — the security domain's language for attackers and defenders. Brownhat sits between them: we understand how attackers think, but we are here to recultivate the environment, not exploit it.
> *"Brownhat is not a methodology for greenfield deployments. It is for organisations that have been building, acquiring, and running for years — and need someone to recultivate what they have before adding anything new."*
**What Brownhat signals to clients**:
- We are not going to sell you a new platform to replace the one you already own.
- We are going to understand your environment as it actually is, not as it was designed to be.
- We are going to extract maximum value from existing investments before recommending anything new.
- We are going to be honest about what you have, what it costs, and what it would take to fix it.
The Brownhat Diagnostic — a structured [NIST CSF 2.0 baseline assessment](../assessment-templates/nist-csf-baseline.md) — is the named entry engagement for new clients. It is how we earn the right to recommend anything.
---
---
## The Philosophy
### Speed Is a Security Control
antifragile-consulting/core/retained-capability.md
+30
View File
@@ -248,6 +248,35 @@ As an antifragile consultant, you do not replace the MSSP. You make the MSSP eff
---
## AD Security: The Continuous Monitoring Tier
A one-time Active Directory security audit (Module 6) produces a point-in-time snapshot. AD environments drift — new accounts are created, service account passwords stop rotating, privileged groups accumulate members. Retained clients should have a **continuous monitoring tier** for AD security posture.
### The AD Continuous Monitoring Service
| Attribute | Detail |
|-----------|--------|
| **Tool** | PingCastle (quarterly scoring) — suited for tracking progress over time in complex AD environments |
| **Cadence** | Quarterly automated scan; score compared to previous quarter; trend report |
| **What it catches** | New privileged account additions, stale configurations that creep back, KRBTGT age drift, new Kerberoastable SPNs, legacy protocol re-enablement |
| **Deliverable** | Quarterly AD security score with delta from prior period; new findings prioritised by risk; confirmation of previously remediated items |
| **Format** | Included in retained capability contract or as a standalone quarterly retainer |
**The conversation**:
> *"Your AD is clean now. We know — we just fixed it. But AD doesn't stay clean by itself. Admins create service accounts, Group Policy gets modified, privileged groups get members. In six months, without monitoring, it will drift back. We run PingCastle every quarter, trend the score, and tell you what changed before it becomes a problem again. This is the difference between a one-time fix and a lasting security posture."*
### Recommended Retained Capability Stack (Post-Module 6)
| Capability | Tool | Cadence |
|-----------|------|---------|
| AD security scoring | PingCastle | Quarterly |
| AD attack path review | BloodHound (re-run) | Bi-annual or post-significant-change |
| EntraID hybrid health | Forest Druid | Quarterly |
| Privileged group membership | PowerShell/Entra audit | Monthly alert |
---
## Integration With Existing Frameworks
| Document | Integration |
@@ -256,6 +285,7 @@ As an antifragile consultant, you do not replace the MSSP. You make the MSSP eff
| [Modular Engagements](modular-engagements.md) | Retained capability audit can be delivered as a standalone 30-day module; detection engineering cell build is a 60-90 day module |
| [Antifragile Risk Register](../assessment-templates/antifragile-risk-register.md) | "Outsourced SOC with no retained detection engineering" is a T1 risk with extreme optionality impact |
| [Business Case Template](../playbooks/business-case-template.md) | Retained capability ROI calculation |
| [AD and Endpoint Hardening](../playbooks/ad-endpoint-hardening.md) | Module 6 produces the clean baseline; this document defines the retained service that keeps it clean |
---
antifragile-consulting/core/spontaneous-order-principles.md
+7 -7
View File
@@ -138,13 +138,13 @@ The antifragile organization does not merely hope to survive the collapse of rig
These five principles are not abstract philosophy. They are the reasoning behind every pillar of the antifragile manifest:
| Principle | Manifest Pillar |
|-----------|-----------------|
| Order Without Control | [Stress-to-Signal Conversion](antifragile-manifest.md#pillar-3-stress-to-signal-conversion) |
| Minimum Effective Control | [Asymmetric Payoff Design](antifragile-manifest.md#pillar-5-asymmetric-payoff-design) |
| Flow Around Obstacles | [Structural Decoupling](antifragile-manifest.md#pillar-1-structural-decoupling) |
| The Power to Opt Out | [Optionality Preservation](antifragile-manifest.md#pillar-2-optionality-preservation) |
| Collapse Creates Advantage | [Sovereign Intelligence](antifragile-manifest.md#pillar-4-sovereign-intelligence) |
| Principle | Manifest Pillar | The Connection |
|-----------|-----------------|----------------|
| Order Without Control | [Stress-to-Signal Conversion](antifragile-manifest.md#pillar-3-stress-to-signal-conversion) | Decentralized systems produce richer, more honest signals than controlled ones — an emergent failure is better information than a failure that was centrally prevented and therefore never studied |
| Minimum Effective Control | [Asymmetric Payoff Design](antifragile-manifest.md#pillar-5-asymmetric-payoff-design) | Control costs should never exceed the risk they prevent; the asymmetric approach concentrates protection exactly where the payoff is disproportionate and removes it everywhere it only consumes speed |
| Flow Around Obstacles | [Structural Decoupling](antifragile-manifest.md#pillar-1-structural-decoupling) | The decoupled organization has alternative paths already built; when one route is blocked by a vendor, regulation, or failure, it routes around — the tightly coupled one stops |
| The Power to Opt Out | [Optionality Preservation](antifragile-manifest.md#pillar-2-optionality-preservation) | The ability to walk away from any relationship is the mechanism that keeps every option open; without it, every "option" is theoretical |
| Collapse Creates Advantage | [Sovereign Intelligence](antifragile-manifest.md#pillar-4-sovereign-intelligence) | When rigid competitors collapse — because they depended on opaque vendors, rented their intelligence, or had no exit architecture — the organization with sovereign intelligence is positioned to absorb their customers, talent, and market share; you cannot benefit from a competitor's collapse if your own infrastructure depended on the same vendor that failed them |
Together, they describe an organization that does not fight entropy. It surfs it.
antifragile-consulting/index.md
+53 -23
View File
@@ -2,22 +2,29 @@
## For Executives and Board Members
Start here. These documents require no technical background.
| Document | Purpose | Audience |
|----------|---------|----------|
| [Executive Summary](core/executive-summary.md) | One-page strategic overview | CEOs, Boards, Executive Committees |
| [Modular Engagements](core/modular-engagements.md) | Menu of independent modules; choose your starting point | CEOs, CFOs, Procurement |
| [About CQRE](core/about-cqre.md) | Who we are, what we do, how we're different — fill this before sharing with clients | CEOs, New Clients, New Hires |
| [O společnosti CQRE](core/about-cqre-cs.md) | Česká verze firemního profilu — pro české klienty a nové členy týmu | Czech Clients, New Hires |
| [Executive Summary](core/executive-summary.md) | One-page strategic overview — read this first | CEOs, Boards, Executive Committees |
| [C-Suite Conversation Guide](core/c-suite-conversation-guide.md) | Scripts, objection handling, and psychological framing | Executives, Advisors |
| [Business Case Template](playbooks/business-case-template.md) | Financial justification, ROI, and risk quantification | CFOs, Boards, Risk Committees |
| [Antifragile Manifest](core/antifragile-manifest.md) | Core philosophy and five pillars (business translation) | Executives, Architects, Consultants |
| [Spontaneous Order Principles](core/spontaneous-order-principles.md) | Philosophical foundation: why antifragile systems work | Executives, Architects, Strategists |
| [Modular Engagements](core/modular-engagements.md) | Menu of independent modules; choose your starting point | CEOs, CFOs, Procurement |
*For the strategic philosophy, see [Core Frameworks](#core-frameworks) below.*
## For Practitioners and Consultants
Operational and persuasion documents used in engagements. **Start every new client with the [NIST CSF 2.0 Baseline Assessment](assessment-templates/nist-csf-baseline.md)** (the Brownhat Diagnostic) to earn the right to recommend anything.
| Document | Purpose | Audience |
|----------|---------|----------|
| [README](README.md) | Repository overview and quick start | Everyone |
| [Move Fast and Fix Things](core/move-fast-and-fix-things.md) | Company motto and engagement posture | Consultants, Executives |
| [Antifragile Manifest](core/antifragile-manifest.md) | Core philosophy and five pillars | Executives, Architects, Consultants |
| [Engagement Model](core/engagement-model.md) | How engagements work: lifecycle, client requirements, deliverables, pricing, and consultant delivery discipline | Clients, New Consultants |
| [Consultant Field Guide](core/consultant-field-guide.md) | Internal playbook: decision models, client qualification, module selection, common mistakes, technical onboarding, proposal writing | New Consultants |
| [NIST CSF 2.0 Baseline Assessment](assessment-templates/nist-csf-baseline.md) | The Brownhat Diagnostic: entry workshop for every new engagement | Consultants, CISOs, IT Managers |
| [AI Operations Inevitability](core/ai-operations-inevitability.md) | Defensive AI is inevitable; business AI is optional | CISOs, CTOs, Consultants |
| [Azure OpenAI Sovereignty Bridge](core/azure-openai-sovereignty-bridge.md) | Azure OpenAI/Foundry as pragmatic sovereignty step | CTOs, Architects, Consultants |
| [Organizational Resilience](core/organizational-resilience.md) | Shift left and Dev/Sec/Ops merger talking points | CTOs, CISOs, Consultants |
@@ -25,6 +32,8 @@
| [Blue/Purple Team Foundation](core/blue-purple-team-foundation.md) | Building defensive capability from existing tool investments | CISOs, SOC Managers, Security Architects |
| [Retained Capability](core/retained-capability.md) | What to keep in-house when outsourcing SOC, pentest, compliance | CISOs, CFOs, Procurement |
*For the engagement posture and philosophy, see [Core Frameworks](#core-frameworks) below.*
## Core Frameworks
| Document | Purpose | Audience |
@@ -51,6 +60,8 @@
| [Zero-Budget Hardening](playbooks/zero-budget-hardening.md) | Maximize existing tools, minimize new purchases | Consultants, CISOs, IT Managers |
| [Implementation Playbook](playbooks/implementation-playbook.md) | Tactical step-by-step delivery guide | Technical Leads, Security Engineers |
| [Sovereign Tool Stack](playbooks/sovereign-tool-stack.md) | Open-source arsenal: Prowler, BloodHound, CISO Assistant, ASTRAL, AOC, Wazuh, Shuffle | Consultants, CTOs, CISOs |
| [Privileged Access Architecture](playbooks/privileged-access-architecture.md) | PAM design: Teleport, Tailscale/Headscale, JIT access, vendor access governance | Security Architects, Infrastructure Consultants, OT Leads |
| [Sovereign Communications](playbooks/sovereign-communications.md) | Delta Chat chatmail relay, Matrix/Element, crisis out-of-band channels | CISOs, Operations Leads, Incident Response |
| [Business Case Template](playbooks/business-case-template.md) | Financial justification, ROI, risk quantification | CFOs, Boards, Consultants |
## Standards Reference
@@ -72,6 +83,10 @@
| Document | Purpose | Audience |
|----------|---------|----------|
| [NIST CSF 2.0 Baseline Assessment](assessment-templates/nist-csf-baseline.md) | The Brownhat Diagnostic: structured 2-half-day workshop, gap analysis, prioritised module roadmap | Consultants, CISOs, IT Managers |
| [NIST CSF 2.0 — česká verze](assessment-templates/nist-csf-baseline-cs.md) | Brownhat Diagnostika: dotazníky a průvodce workshopem v češtině | Consultants running Czech-language workshops |
| [Module Completion Report](assessment-templates/module-completion-report.md) | Template for the deliverable package at the end of every module | Consultants |
| [Risk Register Example](assessment-templates/risk-register-example.md) | 8 fully populated risk entries from a realistic engagement — calibration reference for consultants | Consultants |
| [Antifragile Risk Register](assessment-templates/antifragile-risk-register.md) | Kill chain-aware risk taxonomy and register template | Risk Managers, Consultants |
| [M365 Project Risk Register](assessment-templates/m365-project-risk-register.md) | M365-specific risk register with phase gates | Project Managers, M365 Consultants |
| [Assessment Templates](assessment-templates/README.md) | Future diagnostic tools and maturity models | Consultants, Auditors |
@@ -96,24 +111,39 @@
### For the Consultant
**Start here (read in order before your first engagement):**
1. [README](README.md) — repository orientation
2. [Move Fast and Fix Things](core/move-fast-and-fix-things.md) — your opening stance and engagement principles
3. [Modular Engagements](core/modular-engagements.md) — the engagement menu: sell any module standalone
4. [Spontaneous Order Principles](core/spontaneous-order-principles.md) — philosophical foundation for why antifragile design works
5. [Antifragile Manifest](core/antifragile-manifest.md) — five pillars and strategic translation for client conversations
6. [M365 E3 Hardening](playbooks/m365-e3-hardening.md) — your bread-and-butter: hardening for E3 clients
7. [AD and Endpoint Hardening](playbooks/ad-endpoint-hardening.md) — on-premises identity and endpoint depth
8. [AI Sovereignty Framework](core/ai-sovereignty-framework.md) — persuasive arguments and objection handling
9. [AI Operations Inevitability](core/ai-operations-inevitability.md) — why defensive AI is not optional
10. [Organizational Resilience](core/organizational-resilience.md) — shift left and Dev/Sec/Ops merger talking points
11. [Zero-Budget Hardening](playbooks/zero-budget-hardening.md) — prove value fast without selling
12. [Zero-Budget Vulnerability Discovery](playbooks/zero-budget-vulnerability-discovery.md) — script-based and osquery-based discovery before scanner procurement
13. [Osquery: The Sovereign Discovery Platform](playbooks/osquery-custom-platform.md) — build owned vulnerability and asset inventory capability
14. [Rapid Modernisation Plan](playbooks/rapid-modernisation-plan.md) — structured engagement roadmap
15. [Implementation Playbook](playbooks/implementation-playbook.md) — tactical delivery guidance
16. [Sovereign Tool Stack](playbooks/sovereign-tool-stack.md) — the open-source arsenal: Prowler, BloodHound, CISO Assistant, ASTRAL, AOC, and recommended additions
17. [Vertical: Power and Utilities](reference/vertical-power-utilities.md), [Vertical: Telco](reference/vertical-telco.md), or [Vertical: Banking](reference/vertical-banking.md) — sector-specific adaptations
18. [CIS Controls Mapping](reference/cis-controls-mapping.md) and [NIST CSF Mapping](reference/nist-csf-mapping.md) — standards alignment for auditors and regulators
2. [Move Fast and Fix Things](core/move-fast-and-fix-things.md) — the Brownhat methodology and engagement posture
3. [Engagement Model](core/engagement-model.md) — lifecycle, scoping, pricing, delivery discipline, and how to handle difficult situations
4. [Consultant Field Guide](core/consultant-field-guide.md) — decision models, client qualification, module selection, the ten common mistakes, technical onboarding, and proposal writing
5. [Antifragile Manifest](core/antifragile-manifest.md) — the five pillars and their client-facing translation
6. [Spontaneous Order Principles](core/spontaneous-order-principles.md) — the philosophical foundation for why antifragile design works
7. [C-Suite Conversation Guide](core/c-suite-conversation-guide.md) — scripts, objection handling, and psychological framing for every executive archetype
**Then study the module delivery toolkit:**
8. [NIST CSF 2.0 Baseline Assessment](assessment-templates/nist-csf-baseline.md) — run this first with every new client (the Brownhat Diagnostic)
9. [Modular Engagements](core/modular-engagements.md) — the full module menu (Modules 1–14) and platform adaptation guide
10. [Sovereign Tool Stack](playbooks/sovereign-tool-stack.md) — the full arsenal: CQRE tools, open-source stack, commercial partnerships, and when to use each
11. [M365 E3 Hardening](playbooks/m365-e3-hardening.md) — primary client environment for MS clients (most are E3)
12. [AD and Endpoint Hardening](playbooks/ad-endpoint-hardening.md) — on-premises identity and endpoint depth
13. [Privileged Access Architecture](playbooks/privileged-access-architecture.md) — Module 13: Teleport, Tailscale/Headscale, JIT access, vendor remote access governance
14. [Sovereign Communications](playbooks/sovereign-communications.md) — Module 14: Delta Chat chatmail relay, Matrix/Element, crisis out-of-band channels
**Reference when needed:**
15. [AI Sovereignty Framework](core/ai-sovereignty-framework.md) — persuasive arguments and objection handling
16. [AI Operations Inevitability](core/ai-operations-inevitability.md) — why defensive AI is not optional
17. [Organizational Resilience](core/organizational-resilience.md) — shift left and Dev/Sec/Ops merger talking points
18. [Retained Capability](core/retained-capability.md) — what to keep in-house when outsourcing SOC, pentest, compliance
19. [Zero-Budget Hardening](playbooks/zero-budget-hardening.md) — extract value from existing tools in 30 days
20. [Zero-Budget Vulnerability Discovery](playbooks/zero-budget-vulnerability-discovery.md) — script-based and osquery-based discovery before scanner procurement
21. [Osquery: The Sovereign Discovery Platform](playbooks/osquery-custom-platform.md) — build owned vulnerability and asset inventory capability
22. [Rapid Modernisation Plan](playbooks/rapid-modernisation-plan.md) — structured engagement roadmap
23. [Implementation Playbook](playbooks/implementation-playbook.md) — tactical delivery guidance
24. [Vertical: Power and Utilities](reference/vertical-power-utilities.md), [Vertical: Telco](reference/vertical-telco.md), or [Vertical: Banking](reference/vertical-banking.md) — sector-specific adaptations
25. [CIS Controls Mapping](reference/cis-controls-mapping.md) and [NIST CSF Mapping](reference/nist-csf-mapping.md) — standards alignment for auditors and regulators
---
antifragile-consulting/playbooks/privileged-access-architecture.md
+223
View File
@@ -0,0 +1,223 @@
# Privileged Access Architecture
> *"Your VPN authenticates people to your network. Your PAM authenticates people to specific resources inside it. Most organisations deploy neither correctly. The result is a flat network where a compromised laptop reaches every server, and a stolen VPN credential reaches everything else."*
## For the Executive Reader
Every organisation has two access control problems hiding behind the label "VPN":
1. **Who can reach the network?** The VPN problem — getting authorised people onto the network at all.
2. **Who can touch which specific systems?** The PAM problem — ensuring that once inside the network, users can only reach what they need, nothing more, and every action is recorded.
Most organisations solve the first problem badly (legacy VPN, IP whitelisting, overlapping access methods nobody remembers creating) and ignore the second entirely. An attacker who compromises a VPN credential in this configuration has access to everything.
The antifragile answer is a two-layer architecture: **network access** (Tailscale or Headscale) sitting in front of **protocol-aware privileged access** (Teleport). Each layer can be deployed independently. Together they close the most common kill chain in the playbook.
*For module selection, see [Modular Engagements](../core/modular-engagements.md). For the asset classification that determines which systems require PAM, see [T0 Asset Framework](../core/t0-asset-framework.md).*
---
## The Two Layers
### Layer 1: Network Access — Tailscale / Headscale + WireGuard
**What it solves**: Replace the legacy VPN sprawl. Admins and remote workers get secure, identity-aware access to internal networks without exposing services to the internet.
**How it works**: WireGuard mesh VPN managed by a control plane (Tailscale as a service, or Headscale self-hosted). Every device gets a node identity. Access is controlled by ACL policies, not IP rules. No open firewall ports required on servers.
**Why it matters for security**:
- Eliminates the "VPN = everything" flat-network problem via ACL policies
- Every connection is mutually authenticated (device certificate + identity)
- Audit log of who connected to what, when
- Access can be revoked instantly by removing a node from the control plane
### Layer 2: Protocol-Aware PAM — Teleport
**What it solves**: Once someone is on the network, enforce *which specific servers, databases, and Kubernetes clusters* they can access — and record every session in a tamper-evident audit trail.
**How it works**: Teleport proxies connections to SSH servers, Windows hosts (RDP), Kubernetes clusters, and databases. Users authenticate once (SSO/MFA); Teleport issues short-lived certificates. Sessions are recorded and searchable. No static credentials stored on servers.
**Why it matters for security**:
- Eliminates shared/static credentials on servers (`root`, `administrator`)
- Just-in-time access: permissions expire, removing standing access
- Session recording: every `sudo`, every SQL query, every RDP session
- Auditor-ready evidence: access logs that regulators actually accept
---
## Tool Details
### Teleport
| Attribute | Detail |
|-----------|--------|
| **What it does** | Protocol-aware privileged access proxy for SSH, RDP, Kubernetes, databases, and internal web applications. Short-lived certificates. Full session recording. |
| **Antifragile pillar** | Sovereign Intelligence, Structural Decoupling |
| **Open-source status** | Community Edition (CE) is open-source and self-hosted |
#### CE Eligibility — Be Honest With Clients
Teleport CE is an excellent, capable product. The licensing constraint is important to communicate clearly:
> **Teleport CE is free for organisations with fewer than 100 employees AND less than $10M annual revenue.** Both conditions must be met.
This catches more clients than it appears. A manufacturing company with 800 employees and 6 administrators who would touch Teleport **cannot** legally deploy CE, even though it would work perfectly for their use case. When in doubt, check with the client's legal team before deploying CE at scale.
| Scenario | Recommendation |
|----------|---------------|
| < 100 employees, < $10M revenue | **Teleport CE** — free, self-hosted, full feature set for this scale |
| > 100 employees OR > $10M revenue | **Teleport Enterprise** (commercial) or see Alternatives below |
| Client needs vendor support | **Teleport Enterprise** regardless of size |
| Client has sovereign data mandate | **Teleport CE or Enterprise self-hosted** (both are self-hosted) |
| OT/SCADA vendor remote access at scale | **Teleport Enterprise** — session recording and just-in-time access are critical |
#### Teleport CE vs Enterprise Feature Comparison
| Feature | CE | Enterprise |
|---------|-----|-----------|
| SSH, RDP, K8s, DB access proxying | ✅ | ✅ |
| Session recording | ✅ | ✅ |
| Short-lived certificates | ✅ | ✅ |
| SSO integration | ✅ | ✅ |
| Just-in-time (JIT) access | ✅ | ✅ |
| Access request workflows | ✅ | ✅ |
| Device trust (trusted devices only) | Limited | ✅ |
| Access monitoring & alerts | Limited | ✅ |
| FedRAMP / compliance reports | ❌ | ✅ |
| Commercial support SLA | ❌ | ✅ |
| High availability clustering | Limited | ✅ |
| **License restriction** | **< 100 employees AND < $10M revenue** | None |
**The conversation for non-qualifying clients**:
> *"Teleport CE would work technically — your admins would love it. The license terms prohibit it for organisations your size. We can deploy Teleport Enterprise (priced per protected resource, not per user), or we can architect the network access layer with Tailscale and use certificate-based SSH access for the protocol layer. Both are valid paths. The right choice depends on whether session recording and JIT workflows are on your auditor's checklist."*
---
### Tailscale — Commercial Partnership
| Attribute | Detail |
|-----------|--------|
| **What it does** | Managed WireGuard mesh VPN. Every device gets a node identity. Access controlled by ACL policies. Works on any device, any OS, any cloud. |
| **Why we partner** | Tailscale provides the managed control plane, commercial support, and SSO integrations that make enterprise deployment painless. Per-user pricing is predictable. |
| **Sovereign alternative** | Headscale (open-source self-hosted control plane for WireGuard) — see below |
| **Antifragile pillar** | Structural Decoupling, Optionality Preservation |
| **Engagement modules** | Module 2 (Identity Security), Module 6 (AD Hardening), Module 8 (OT Security), Module 13 (this module) |
**When to recommend Tailscale (commercial)**:
- Client wants commercial support and SLA
- Client needs Tailscale's SSO integrations (Okta, Azure AD, Google)
- Client has a mixed-device estate that benefits from Tailscale's client apps
- Client's procurement requires a vendor contract
**The conversation**:
> *"You currently have a legacy VPN that requires a specific client, routes all traffic through your data centre, and gives everyone access to the same network. Tailscale replaces it with a mesh that puts every authorised device directly in contact with every authorised resource — no central bottleneck, no broad network exposure. An admin in Prague connects to the server in Vienna as if they are on the same LAN. A supplier accesses only the one application they need, nothing else. When you revoke access, it is immediate and complete."*
---
### Headscale + WireGuard — Sovereign Alternative
| Attribute | Detail |
|-----------|--------|
| **What it does** | Self-hosted control plane (Headscale) for WireGuard mesh networks. Functionally equivalent to Tailscale without the external control plane. Data never leaves client infrastructure. |
| **Why we use it** | For clients with sovereign-data mandates, air-gapped environments, or regulated industries where data about network topology and device identities cannot reside with a third party. |
| **Trade-off vs Tailscale** | More engineering overhead; no managed apps; SSO integration requires custom OIDC configuration; no commercial support |
| **Antifragile pillar** | Sovereign Intelligence, Structural Decoupling |
| **When to deploy** | Clients with NIS2/DORA requirements on data residency; utilities/OT environments; clients who have explicitly declined SaaS control planes |
**Deployment model**: Headscale server on client infrastructure or CQRE-managed VM; WireGuard clients on all devices. Managed by us as a retained service or handed over to the client's infrastructure team.
---
### Smallstep — Certificate-Based SSH Access
| Attribute | Detail |
|-----------|--------|
| **What it does** | SSH certificate authority. Issues short-lived SSH certificates tied to identity (SSO/OIDC). Eliminates static SSH keys. No agent required on target servers. |
| **Why we use it** | For clients who need certificate-based SSH access control but cannot justify Teleport. Covers the most common privileged access vector (SSH) at low cost and complexity. |
| **Limitation vs Teleport** | No session recording; no RDP/Kubernetes/DB proxying; no GUI |
| **Antifragile pillar** | Sovereign Intelligence, Structural Decoupling |
| **When to deploy** | Linux-heavy clients; DevOps teams; as a stepping stone before Teleport |
---
## The Decision Framework
```
Does the client have legacy VPN sprawl or flat-network vendor access?
├── YES → Deploy Layer 1 (network access) first
│ ├── Wants managed service + commercial support → Tailscale (partnership)
│ └── Wants full sovereignty / data residency → Headscale + WireGuard
│
Does the client need protocol-aware session recording / JIT / DB access?
├── YES → Add Layer 2 (PAM)
│ ├── < 100 employees AND < $10M revenue → Teleport CE (free, self-hosted)
│ ├── Larger org / needs support → Teleport Enterprise (commercial)
│ └── SSH-only, budget-constrained → Smallstep (certificates only)
│
Does the client need both layers?
├── MOST CLIENTS → Tailscale (network) + Teleport CE/Enterprise (PAM)
└── OT/CRITICAL INFRA → Headscale (sovereign network) + Teleport (recorded vendor access)
```
---
## OT and Critical Infrastructure Considerations
This module is especially valuable for Module 8 (OT Security Assessment) clients. The most common and dangerous finding in OT environments is **uncontrolled vendor remote access**: SCADA vendors, maintenance contractors, and automation engineers with persistent VPN credentials and no session recording.
**The OT-specific requirements**:
| Requirement | Solution |
|-------------|---------|
| Vendor access without standing credentials | Teleport JIT access: vendor requests access, engineer approves, session recorded, credential expires |
| No persistent VPN for OT networks | Tailscale/Headscale ACL policy: vendor node can reach only the specific OT asset, nothing else |
| Auditability for regulators (NIS2, CER) | Teleport session recordings: complete record of every vendor action on every OT system |
| Air-gapped or restricted networks | Headscale on-premise: no outbound control plane dependency |
| Separation of IT and OT access | Separate Tailscale/Headscale networks with explicit, audited bridge points |
**The executive pitch for utilities and telco**:
> *"Your SCADA vendor has a VPN credential that gives them access to your control network. It has not been rotated in three years. You do not know when they last used it or what they did. If that credential is compromised, an attacker has access to your control systems without ever touching your IT network. We replace that with a session that the vendor requests on the day they need it, that an engineer approves, that is recorded start to finish, and that expires the moment the maintenance window closes. This is not extra bureaucracy. This is the audit evidence your regulator will ask for under NIS2."*
---
## CQRE Deployment Tiers
| Tier | Description | Best for |
|------|-------------|---------|
| **Assessment & Design** | Architecture review, tool selection, design document, implementation roadmap | Clients with existing VPN/PAM debt; pre-deployment planning |
| **Managed Deployment** | CQRE installs and configures the chosen stack; hands over to client team | Clients without internal infrastructure expertise |
| **Fully Managed Service** | CQRE operates the network access and PAM layer as a managed service | Clients who want the capability without the operational burden |
| **Retained Advisory** | Quarterly reviews, policy updates, incident support | Clients who have deployed and want ongoing assurance |
---
## Per-Module Tool Pairing
| Module | Access Architecture Role |
|--------|------------------------|
| **Module 2: M365 Identity Security** | Tailscale/Headscale for admin access to cloud management plane; Teleport for server access |
| **Module 6: On-Premise AD Hardening** | Teleport CE as PAW replacement for domain controller access; recorded sessions for all Tier 0 admin activity |
| **Module 8: OT Security Assessment** | Headscale for sovereign OT network access; Teleport for vendor access with full session recording |
| **Module 10: Red Team & Validation** | Verify that Tailscale ACLs actually enforce segmentation; test Teleport JIT bypass scenarios |
| **Module 13: This module** | Full deployment of chosen network + PAM stack |
---
## Integration With Existing Frameworks
| Document | Integration |
|----------|-------------|
| [T0 Asset Framework](../core/t0-asset-framework.md) | T0 assets (domain controllers, key servers, OT controllers) require Teleport session recording; Tailscale ACLs isolate T0 network segments |
| [AD and Endpoint Hardening](ad-endpoint-hardening.md) | PAW architecture is enhanced by Teleport; privileged accounts should authenticate through PAM, not direct RDP |
| [Sovereign Tool Stack](sovereign-tool-stack.md) | Tailscale/Headscale extends the network access layer; Teleport extends the identity and session intelligence layer |
| [Vertical: Power and Utilities](../reference/vertical-power-utilities.md) | Vendor remote access to OT is addressed directly by this module |
| [Vertical: Telco](../reference/vertical-telco.md) | Network operations centre access, vendor access to network elements |
---
*For the OT security context, see [Vertical: Power and Utilities](../reference/vertical-power-utilities.md).*
*For identity and T0 asset protection, see [T0 Asset Framework](../core/t0-asset-framework.md).*
*For the full module menu, see [Modular Engagements](../core/modular-engagements.md).*
antifragile-consulting/playbooks/sovereign-communications.md
+206
View File
@@ -0,0 +1,206 @@
# Sovereign Communications
> *"Your incident response plan assumes your communication platform is available. Your incident response plan is wrong."*
## For the Executive Reader
Every organisation has a single communication platform — Teams, Slack, or similar — that depends on the same corporate identity, the same internet connection, and often the same Microsoft or Google account as everything else. When an incident takes down corporate IT, the communication platform goes down too. When Active Directory is compromised, the attacker can monitor your incident response in real time.
Sovereign communications solves this with a two-tier architecture:
- **Tier 1 — Delta Chat**: A 10-minute deployment on independent infrastructure. Encrypted, works on mobile, requires no corporate account to log in. Used as an out-of-band channel and crisis fallback.
- **Tier 2 — Matrix/Element**: A full sovereign messaging platform for organisations that want to own their primary communications entirely — no vendor dependency, federated, self-hosted.
These are not competing products. They serve different needs and often both are deployed.
*For the module overview, see [Modular Engagements](../core/modular-engagements.md#module-14-sovereign-communications).*
---
## Why Communications Infrastructure Is a Security Control
Most organisations treat their communication platform as a productivity tool and their security tools as a separate category. This is the mistake. Communication infrastructure is:
| Risk Category | Exposure |
|--------------|---------|
| **Incident response dependency** | If Teams is down during a ransomware attack, how do you coordinate response? |
| **Identity dependency** | M365 Teams requires Entra ID. If identity is compromised, the communication platform is too. |
| **Insider threat surface** | A compromised admin account can read every Teams channel in your tenant silently. |
| **Vendor continuity** | A Teams or Slack outage is outside your control. Your response capability should not be. |
| **OT/Crisis operations** | Control room operators cannot rely on a communication tool that depends on corporate IT — especially when the incident is in the corporate IT. |
**The antifragile principle**: Your crisis communication channel must be independent from the infrastructure that might fail during the crisis.
---
## Tier 1: Delta Chat
### What It Is
Delta Chat is an open-source messaging application that uses **email as its transport layer** — specifically IMAP/SMTP with Autocrypt end-to-end encryption (OpenPGP). It looks and works like a modern instant messenger. It is, technically, encrypted email.
### Why This Is Antifragile
| Property | Why It Matters |
|----------|---------------|
| **Runs on email infrastructure** | SMTP/IMAP is the most resilient, federated, widely deployed protocol in existence |
| **Works with any email account** | No new accounts, no new server required if existing email is used |
| **E2E encrypted by default** | Messages are encrypted before leaving the device; the server never sees plaintext |
| **No accounts to compromise** | Delta Chat uses email addresses — there is no separate "Delta Chat account" to take over |
| **Federated** | Anyone with an email address can participate; no walled garden |
| **Works on mobile without corporate MDM** | Personal devices can be enrolled in crisis channels without corporate management |
| **Open-source and auditable** | No opaque server-side processing; the encryption implementation is public |
### The Two Deployment Options
#### Option A: Use Existing Email Infrastructure
Delta Chat can be pointed at any existing IMAP/SMTP server. If the client already has a stable email platform, Delta Chat adds encrypted messaging on top of it with no new infrastructure.
**Best for**: Adding encryption and a better UX to existing internal communication; M365/Exchange clients who want an encrypted channel without new servers.
**Limitation**: If the email server goes down, Delta Chat goes down. The communication channel and the email infrastructure are the same.
#### Option B: Deploy a Chatmail Relay (Recommended for Crisis/OT)
**Chatmail** is a purpose-built, minimal email relay optimised for Delta Chat. It is not a full mail server — it is designed specifically to be fast, lightweight, and easy to deploy as a Delta Chat backend.
| Chatmail Property | Detail |
|------------------|--------|
| **Deployment time** | ~10 minutes on any small VPS |
| **Infrastructure cost** | €5–10/month on a small cloud instance |
| **Independence** | Completely separate from the client's corporate email/IT infrastructure |
| **No domain dependency** | Does not require integration with the client's existing email domain |
| **Optimised for push** | Purpose-built for Delta Chat's push notification model — messages arrive instantly on mobile |
| **Minimal attack surface** | Not a full mail server; purpose-built, smaller footprint than Postfix + Dovecot |
**Deployment**: One VPS, one domain (e.g., `chat.clientname.cqre.net`), 10 minutes. Users create accounts by scanning a QR code in Delta Chat. No IT involvement required on the user side.
**This is the recommended approach for OT/critical infrastructure clients** and any client where the crisis channel must be independent from corporate infrastructure.
**The conversation**:
> *"We are going to spin up a €7/month server that runs a dedicated chat relay. It has nothing to do with your Active Directory, your Exchange, your Azure, or your corporate network. When your primary infrastructure has a bad day, this server does not care. Your operations team scans a QR code and they are on a channel that is encrypted end-to-end, works on personal phones, and requires no corporate account. We do this today, in this meeting. It takes 10 minutes."*
### Typical Deployment Scope
| Use Case | Delta Chat Configuration |
|----------|------------------------|
| **Crisis/incident response** | Chatmail relay on independent cloud; separate from corporate infra; key responders enrolled |
| **OT operations channel** | Chatmail relay; separate from IT network; control room operators + management enrolled |
| **Board/executive channel** | Chatmail relay; executives enrolled on personal devices; no corporate MDM dependency |
| **Supplier/vendor coordination** | Existing email (Option A); suppliers use their own email addresses; no account setup required |
| **Primary encrypted comms for small teams** | Existing email (Option A); team uses Delta Chat daily for all sensitive communication |
---
## Tier 2: Matrix / Element
### What It Is
Matrix is an open standard for decentralised, federated real-time communication. Element is the primary client application. Synapse and Dendrite are the main server implementations. The combination provides a full-featured, sovereign alternative to Teams or Slack: text, voice, video, file sharing, bridges to other platforms, and automation.
### When Tier 2 Is Warranted
| Client Situation | Matrix/Element Appropriate? |
|-----------------|---------------------------|
| Needs a full Teams/Slack replacement with sovereignty | ✅ Yes |
| Regulated industry requiring data residency for all communications | ✅ Yes |
| OT operator who wants persistent rooms for shift handovers + crisis channel | ✅ Yes |
| Needs bridges to existing platforms (Slack, Teams, Signal, WhatsApp) | ✅ Yes |
| Just needs a crisis fallback channel | ❌ Delta Chat is simpler and faster |
| Just needs encrypted messaging on existing email | ❌ Delta Chat is simpler and faster |
### Matrix/Element Feature Comparison vs Teams/Slack
| Feature | Matrix/Element | Teams / Slack |
|---------|---------------|---------------|
| Persistent rooms | ✅ | ✅ |
| Voice/video calls | ✅ | ✅ |
| File sharing | ✅ | ✅ |
| E2E encryption | ✅ (per room) | Limited/none |
| Self-hosted | ✅ (required for sovereignty) | ❌ |
| Federation with other instances | ✅ | ❌ |
| Bridges (Slack, Teams, Signal) | ✅ (via bridges) | Limited |
| Bot/automation support | ✅ | ✅ |
| Third-party data exposure | None (self-hosted) | Vendor has access |
| Per-user licensing cost | None (self-hosted) | €5–30/user/month |
| Data residency guarantee | Full control | Vendor-dependent |
### CQRE Implementation Options
| Option | Description | Best For |
|--------|-------------|---------|
| **Fully Managed** | CQRE hosts and operates Synapse in our infrastructure; client datacenter region selectable | Clients who want the capability without operating it |
| **On-Premises** | CQRE installs and configures Synapse on client infrastructure; client operates it | Clients with strict data residency requirements |
| **Managed On-Premises** | CQRE installs and manages Synapse on client infrastructure on a support contract | Best of both: sovereign data, no operational burden on client |
**The conversation**:
> *"You are paying €20 per user per month for Slack. That is €240K per year for 1,000 users. Every message your executives send about acquisition targets, regulatory responses, and incident response sits on Slack's infrastructure. We replace that with a self-hosted Matrix instance. Same features. Better encryption. Zero per-user cost after infrastructure. Your messages never leave your building."*
---
## The Dual-Stack Architecture
For most clients, the recommended posture is:
```
PRIMARY CHANNEL: Teams / Slack / email (existing corporate platform)
↓ Fails during incident
OUT-OF-BAND CHANNEL: Delta Chat on chatmail relay
(independent infrastructure, works on personal devices)
For organisations wanting full sovereignty:
PRIMARY CHANNEL: Matrix/Element (self-hosted)
↓ Fails during infrastructure incident
OUT-OF-BAND CHANNEL: Delta Chat on chatmail relay
(different infrastructure, different failure mode)
```
**The key insight**: The out-of-band channel must have a **different failure mode** from the primary channel. If both run on the same VPS or depend on the same corporate identity, they will fail together.
---
## OT and Critical Infrastructure
For utilities, telco, and manufacturing clients, sovereign communications is not a convenience — it is an operational requirement.
| Scenario | Recommendation |
|----------|---------------|
| **Ransomware hits corporate IT** | Delta Chat on chatmail relay — independent from corporate domain; operations can continue coordinating |
| **Power outage affects datacenter** | Delta Chat on cloud-hosted chatmail relay — works on mobile over 4G/5G while datacenter is dark |
| **OT incident requires IT/OT team coordination** | Delta Chat channel pre-enrolled with OT engineers, IT responders, management, and external incident response team |
| **Regulator requires documented crisis comms capability** | Matrix/Element with full audit log + Delta Chat as the fallback — both documented in IR runbooks |
| **Vendor coordination during OT maintenance** | Delta Chat on chatmail relay — vendor uses their own email address; no corporate account provisioning required |
**NIS2 relevance**: NIS2 Article 21 requires operators of essential services to have documented crisis communication procedures. A deployed, tested out-of-band channel is evidence; a policy that says "we will use Teams" is not.
---
## Deployment Complexity
| Tool | Time to First Value | Infrastructure | Expertise Required |
|------|--------------------|-----------|--------------------|
| Delta Chat (existing email) | 5 minutes (per user) | None | Very low |
| Delta Chat + chatmail relay | 10–30 minutes total | One small VPS | Low |
| Matrix/Element (managed by CQRE) | 1–2 days | CQRE infrastructure | Low (client side) |
| Matrix/Element (on-premises) | 2–5 days | Client VPS or VM | Medium |
---
## Integration With Existing Frameworks
| Document | Integration |
|----------|-------------|
| [Modular Engagements](../core/modular-engagements.md) | Module 14; natural follow-on to Module 7 (Recovery & Resilience) and Module 8 (OT Security) |
| [Vertical: Power and Utilities](../reference/vertical-power-utilities.md) | OT crisis communications; NIS2 Article 21 crisis procedure evidence |
| [Vertical: Telco](../reference/vertical-telco.md) | Network operations out-of-band channel; incident bridge coordination |
| [Rapid Modernisation Plan](rapid-modernisation-plan.md) | Delta Chat chatmail relay is a Phase 3 (Sovereignty) quick win — 10 minutes of deployment, immediately demonstrable |
| [T0 Asset Framework](../core/t0-asset-framework.md) | Crisis communication channel is a T1 operational asset; Delta Chat relay should have the same protection as other critical services |
---
*For the OT security context, see [Vertical: Power and Utilities](../reference/vertical-power-utilities.md).*
*For recovery and resilience planning, see [Implementation Playbook](implementation-playbook.md).*
*For the full module menu, see [Modular Engagements](../core/modular-engagements.md).*
antifragile-consulting/playbooks/sovereign-tool-stack.md
+79 -1
View File
@@ -85,6 +85,25 @@ This document provides the complete capability map for our consulting practice:
---
### Active Directory Password Audit
#### Elysium (Our Platform)
| Attribute | Detail |
|-----------|--------|
| **What it does** | Automated detection of weak and compromised passwords in Active Directory. Downloads a known-hash database (KHDB) of breached credentials, compares it against domain password hashes using the DSInternals suite, and identifies accounts with dictionary passwords, known-breached credentials, default passwords, or missing encryption keys — all without transmitting usernames or plaintext passwords outside the secure host. |
| **Why we built it** | Password spray attacks succeed because users choose weak passwords regardless of policy. No open-source tool audits AD passwords in a privacy-preserving way without expensive PAM integrations. Elysium finds the accounts an attacker would crack first — before they do — while keeping individual identity data confined to a dedicated secure host. Only compressed, encrypted hash data moves between systems; usernames are never part of the transfer. |
| **Antifragile pillar** | Stress-to-Signal Conversion, Sovereign Intelligence |
| **Engagement modules** | Module 6 (On-Premise AD Hardening); Module 10 (Red Team & Validation); any environment where credential-based attacks (password spray, stuffing) are in the threat model |
| **Typical output** | "47 domain accounts match known-compromised hashes. 12 match common dictionary patterns. 3 are privileged accounts. Here is the remediation priority list: force-reset these 3 immediately, notify these 44 via IT policy enforcement." |
| **Integration** | Findings cross-referenced with BloodHound attack path analysis — accounts with weak passwords that also have short paths to Domain Admin become P0 remediations; results tracked in CISO Assistant for credential policy evidence |
**The conversation**:
> *"Your password policy says minimum 12 characters. That tells you the length. It tells you nothing about whether your employees chose 'Summer2024!' or an actual strong password. Elysium tests every account's hash against a database of 800 million known-compromised credentials. We run it on a dedicated host inside your network. No username ever leaves your building. What we find is a list of accounts a standard password spray tool would crack in under an hour. Last time we ran this, three privileged accounts were on the list."*
---
### Governance, Risk, and Compliance
#### CISO Assistant
@@ -121,6 +140,14 @@ This document provides the complete capability map for our consulting practice:
> *"Your M365 tenant has 400 configuration objects and no version control. When an admin accidentally deletes a conditional access policy at 2 AM, you discover it 6 hours later because users are complaining. ASTRAL detects the deletion in 60 seconds, attributes it to the specific admin session, and offers one-click rollback. This is not backup. This is configuration immunity."*
**ASTRAL companion utilities (CQRE)**:
| Tool | What it does | When to use |
|------|-------------|------------|
| **macOS_IntuneManagement** | Cross-platform headless PowerShell toolkit for Intune policy export/import and baseline deployment across tenants. Supports baseline manifests, bulk device operations, and cross-tenant dependency mapping. | Brownfield tenant migrations; deploying a clean Intune baseline into a new acquisition; cross-platform (macOS, Linux, Windows) policy management |
| **IntunePolicyParser** | Converts Intune documentation exports to flat CSV/Excel for policy analysis, deduplication, and Power BI dashboards. | Auditing existing policy sets before rationalisation; generating a readable flat register from an ASTRAL snapshot; compliance evidence |
| **M365-Scripts** | Operational PowerShell scripts for MDE device lifecycle management. Current focus: bulk offboarding of devices by tag via the Defender for Endpoint API with dry-run mode and retry logic. | Module 1 device lifecycle cleanup; decommissioning campaigns; offboarding projects |
---
### M365 Audit Log Intelligence
@@ -134,7 +161,7 @@ This document provides the complete capability map for our consulting practice:
| **Antifragile pillar** | Sovereign Intelligence, Stress-to-Signal Conversion |
| **Engagement modules** | Module 12 (Blue/Purple Team Foundation); retained capability (Detection Engineering); all M365 hardening engagements |
| **Typical output** | Daily brief: "3 anomalous events flagged: Global Admin [X] added external user at 03:14; Exchange Admin [Y] exported 12,000 mailboxes; Service Principal [Z] granted Mail.Read to unverified publisher. All require validation within 4 hours." |
| **Integration** | Receives alerts from osquery/FleetDM, Wazuh, and Prowler; pushes cases to CISO Assistant for risk register tracking; enriches AI-assisted TVM with insider-threat context |
| **Integration** | Receives alerts from osquery/FleetDM, Wazuh, and Prowler; pushes cases to CISO Assistant for risk register tracking; enriches AI-assisted TVM with insider-threat context; **MCP server** enables Claude and other AI clients to query audit logs in natural language directly from the analyst's desktop |
**The conversation**:
@@ -142,6 +169,25 @@ This document provides the complete capability map for our consulting practice:
---
### Conditional Access Policy Documentation
#### CAExporter (Our Platform)
| Attribute | Detail |
|-----------|--------|
| **What it does** | Documents Entra ID Conditional Access policies and translates cryptic directory object IDs into human-readable names for targeted users, groups, and applications. Exports a complete, structured CA policy register to CSV and formatted Excel workbooks. |
| **Why we built it** | Organisations with 30–200 CA policies have no readable documentation of what those policies actually cover. Object IDs in the Entra admin centre are opaque — group names are invisible, app names are GUIDs. Before you can harden, rationalise, or audit CA policies, you need to know what each one actually does. CAExporter produces that picture in under 10 minutes. |
| **Antifragile pillar** | Structural Decoupling, Stress-to-Signal Conversion |
| **Engagement modules** | Module 2 (M365 Identity Security); Module 3 (M365 Security Hardening); compliance audits requiring CA policy evidence (NIS2, ISO 27001, DORA) |
| **Typical output** | Excel workbook with one row per policy: policy name, conditions, controls, named groups and apps (not object IDs), assignment scope, current state (enabled/disabled/report-only), and export timestamp. Audit-ready without a single screenshot. |
| **Integration** | Export feeds into ASTRAL as the human-readable CA policy baseline (state at engagement start); CISO Assistant links the workbook as evidence for Entra ID hardening controls; AOC change alerts are cross-referenced against the export to identify which named policy changed |
**The conversation**:
> *"Your Entra tenant has 67 Conditional Access policies. Nobody in this room can tell me, right now, what all 67 of them do. Three of them reference groups that no longer exist. Two claim to block legacy authentication — but only for a subset of users. CAExporter generates a readable register in 10 minutes. We use it to find the gaps, document the baseline, and give your auditor evidence that your CA policies are intentional — not the accumulated result of six admins making changes over four years."*
---
## The Stack Architecture
```
@@ -300,6 +346,10 @@ Our current stack covers cloud posture, AD security, GRC, M365 configuration, an
| GRC and compliance | **CISO Assistant** | OpenGRC, SimpleRisk | ServiceNow GRC, RSA Archer | DORA, NIS2, SOC 2 clients |
| M365 backup/change mgmt | **ASTRAL** | — (no open-source equivalent) | Veeam, AvePoint, SkyKick | All M365 clients; retained capability |
| M365 audit intelligence | **AOC** | — (no open-source equivalent) | Microsoft Sentinel, ManageEngine | All M365 clients; SOC co-management |
| CA policy documentation | **CAExporter** | — (no equivalent) | — | Every Module 2 engagement; CA audits |
| AD password audit | **Elysium** | — (DSInternals manual use) | Netwrix Password Policy, Specops | Every AD engagement; Module 6 |
| Intune baseline deployment | **macOS_IntuneManagement** | — (no cross-platform equivalent) | — | Tenant migrations; brownfield baseline |
| Endpoint hardening baseline | **E8-CAT** | CIS-CAT Lite (Windows only) | CIS-CAT Pro | Module 1/3 pre/post hardening scoring |
| Endpoint inventory | **osquery + FleetDM** | Wazuh (limited), Zentral | Tenable, Qualys | 50-5,000 endpoints; sovereign preference |
| Endpoint detection (EDR) | **Wazuh + Sysmon** | — | CrowdStrike, SentinelOne, Defender P2 | E3 clients without Defender P2; air-gapped environments |
| SIEM / log aggregation | **Wazuh** | Graylog, Grafana Loki, ELK | Splunk, Sentinel, QRadar | All environments needing centralised alerting |
@@ -329,18 +379,22 @@ Our current stack covers cloud posture, AD security, GRC, M365 configuration, an
### Module 1: Endpoint Management Foundation
**Primary**: ASTRAL (Intune configuration backup and drift detection) + osquery/FleetDM (endpoint inventory)
**Augmentation**: Wazuh + Sysmon (for E3 clients without Defender P2)
**CQRE utilities**: macOS_IntuneManagement (baseline deployment, cross-tenant migration); IntunePolicyParser (policy audit register); M365-Scripts (MDE device lifecycle); E8-CAT (pre/post hardening Essential Eight score)
### Module 2: M365 Identity Security
**Primary**: AOC (audit log intelligence) + BloodHound (hybrid identity attack paths)
**Augmentation**: Purple Knight (AD security baseline)
**CQRE utilities**: CAExporter (CA policy documentation baseline — run first, before any CA hardening)
### Module 3: M365 Security Hardening
**Primary**: ASTRAL (configuration state) + Prowler (Azure posture)
**Augmentation**: AOC (continuous monitoring of security control changes)
**CQRE utilities**: CAExporter (CA policy register as audit evidence); E8-CAT (macro restriction and application hardening verification)
### Module 6: On-Premise AD Hardening
**Primary**: BloodHound + Purple Knight / Forest Druid
**Augmentation**: osquery (endpoint state of domain controllers)
**CQRE utilities**: Elysium (weak/compromised password audit — run alongside BloodHound; weak-password accounts on high-value attack paths become P0)
### Module 9: Organisational Resilience and DevSecOps
**Primary**: Falco (container runtime security) + Semgrep (static code analysis) + GitLeaks (secrets detection)
@@ -370,6 +424,10 @@ Our current stack covers cloud posture, AD security, GRC, M365 configuration, an
| CISO Assistant | 1 day | Docker host or VM | Low | Low-Medium (compliance data) |
| ASTRAL | 2 hours | SaaS or client-hosted | Low | High (M365 configuration) |
| AOC | 4 hours | SaaS or client-hosted | Medium | High (audit logs, identity data) |
| CAExporter | 30 minutes | None (runs from PowerShell) | Low | Low (read-only CA policy export) |
| Elysium | 1–2 hours | Dedicated secure host (on-premises) | Medium | High (domain password hashes — stays on-prem) |
| macOS_IntuneManagement | 1 hour | None (PowerShell 7+) | Low | Medium (Intune policy data) |
| E8-CAT | 30 minutes | None (runs on target endpoint) | Low | Low (compliance scan results) |
| osquery + FleetDM | 4 hours | FleetDM server + agents | Medium | High (endpoint data) |
| Wazuh + Sysmon | 1 day | Wazuh server + agents | Medium | High (endpoint + network data) |
| Shuffle | 4 hours | Docker host | Medium | High (SOAR playbooks) |
@@ -538,6 +596,25 @@ Beyond the core stack, these tools address specific niches that arise in sophist
---
### Endpoint Hardening Baseline Verification
#### E8-CAT (Our Platform)
| Attribute | Detail |
|-----------|--------|
| **What it does** | Lightweight PowerShell-based compliance scanner for Windows workstations and servers. Evaluates four Essential Eight strategies — restricting macros, hardening applications, enforcing application control, and limiting administrator privileges — across maturity levels 1–3. Produces JSON, CSV, and HTML compliance reports with pass/fail evidence for each check. |
| **Why we built it** | CIS-CAT Pro costs money and requires a licence; CIS-CAT Lite is Windows-only and limited. The Essential Eight (ACSC) overlaps heavily with what Modules 1 and 3 deliver. Running E8-CAT before and after a hardening engagement produces a concrete, evidence-backed maturity level improvement score that clients and auditors can read. It is lightweight, free, and runs from the target system without an agent. |
| **Antifragile pillar** | Stress-to-Signal Conversion, Asymmetric Payoff Design |
| **Engagement modules** | Module 1 (Endpoint Management) and Module 3 (M365 Security Hardening) as pre/post hardening verification; any engagement that requires documented baseline improvement evidence |
| **Typical output** | "Pre-hardening: Maturity Level 1 across 3 of 4 strategies, Maturity Level 0 on application control. Post-hardening: Maturity Level 2 across all 4 strategies. Evidence: 47 individual check results with registry keys, feature states, and policy values." |
| **Integration** | Results stored in CISO Assistant as control evidence; trends tracked over time for continuous improvement reporting |
**The conversation**:
> *"Before we change anything, E8-CAT scores your endpoints against the Essential Eight hardening framework. You are at Maturity Level 1 on two strategies and Level 0 on two others. When we are done with Module 1 and Module 3, we run it again. That before-and-after score is your evidence: not our word, not screenshots, but a reproducible scan result you can show your auditor and your board."*
---
### Certificate and Subdomain Monitoring
#### CertStream + Crt.sh
@@ -567,6 +644,7 @@ Beyond the core stack, these tools address specific niches that arise in sophist
| Static code analysis | **Semgrep** | Vulnerability detection without cloud dependency | CI/CD security gates |
| Phishing simulation | **GoPhish** | User susceptibility measurement and training | Awareness programmes |
| Certificate monitoring | **CertStream + crt.sh** | Subdomain discovery and unauthorised certs | Continuous perimeter monitoring |
| Endpoint hardening baseline | **E8-CAT** | Free Essential Eight scanner; pre/post hardening maturity score | Module 1/3 hardening evidence |
---
antifragile-consulting/reference/nist-csf-mapping.md
+1
View File
@@ -161,3 +161,4 @@ When auditors ask how the antifragile approach maps to "accepted frameworks":
---
*Previous: [CIS Controls Mapping](cis-controls-mapping.md)*
*To apply this framework in a client workshop, see [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md) — the Brownhat Diagnostic.*