From 1f7bae3f359125c61a7e3c55a4c0bd54054c1939 Mon Sep 17 00:00:00 2001 From: Anikke Date: Sat, 19 Sep 2026 21:22:43 +0200 Subject: [PATCH] feat: publish About CQRE pages (EN+CS), add MkDocs site config, fix broken cross-links - about-cqre.md / about-cqre-cs.md: placeholders filled; unverified facts kept as invisible CONFIRM(Tom) comments pending Tom's review (2026-09-20 deadline) - mkdocs.yml: Material theme, docs_dir=antifragile-consulting, repo_url to Gitea - Fix broken relative links in index, assessment-team-guide, engagement-checklist, engagement-model, rapid-modernisation-plan, assessment-templates/README - Include previously untracked core/interdiction-model.md (Tom's WIP, appears complete) - .gitignore: exclude site/ build output --- .gitignore | 3 + .../assessment-templates/README.md | 2 +- .../assessment-team-guide.md | 2 +- .../engagement-checklist.md | 2 +- antifragile-consulting/core/about-cqre-cs.md | 131 +++---- antifragile-consulting/core/about-cqre.md | 127 +++---- .../core/engagement-model.md | 2 +- .../core/interdiction-model.md | 336 ++++++++++++++++++ antifragile-consulting/index.md | 4 +- .../playbooks/rapid-modernisation-plan.md | 4 +- mkdocs.yml | 51 +++ 11 files changed, 489 insertions(+), 175 deletions(-) create mode 100644 antifragile-consulting/core/interdiction-model.md create mode 100644 mkdocs.yml diff --git a/.gitignore b/.gitignore index 1d04bd4..9ebf378 100644 --- a/.gitignore +++ b/.gitignore @@ -15,3 +15,6 @@ *.swp *.swo *~ + +# MkDocs build output +site/ diff --git a/antifragile-consulting/assessment-templates/README.md b/antifragile-consulting/assessment-templates/README.md index b156e55..345d5c3 100644 --- a/antifragile-consulting/assessment-templates/README.md +++ b/antifragile-consulting/assessment-templates/README.md @@ -91,4 +91,4 @@ When adding new assessments: --- -*Return to [Repository Index](../README.md)* +*Return to [Repository Index](../index.md)* diff --git a/antifragile-consulting/assessment-templates/assessment-team-guide.md b/antifragile-consulting/assessment-templates/assessment-team-guide.md index 610aa22..06756d4 100644 --- a/antifragile-consulting/assessment-templates/assessment-team-guide.md +++ b/antifragile-consulting/assessment-templates/assessment-team-guide.md @@ -356,7 +356,7 @@ Build the kill chain step by step: 6. What does domain admin give you? (everything on-prem, including ERP, backup servers) 7. What is the impact? (data exfiltration, ransomware, operational disruption) -Write this as a chain, not a list. The [sample engagement kill chain](sample-engagement-mid-market.md#kill-chain-assessment) shows the format. +Write this as a chain, not a list. The [sample engagement kill chain](../playbooks/sample-engagement-mid-market.md#kill-chain-assessment) shows the format. --- diff --git a/antifragile-consulting/assessment-templates/engagement-checklist.md b/antifragile-consulting/assessment-templates/engagement-checklist.md index dbca20c..4f6f9df 100644 --- a/antifragile-consulting/assessment-templates/engagement-checklist.md +++ b/antifragile-consulting/assessment-templates/engagement-checklist.md @@ -3,7 +3,7 @@ > *Not a benchmark. Not scored. A structured inspection list for consultants on active engagements.* **Last updated:** June 2026 -**Companion to:** [Field Guide 2026](../books/field-guide-2026.md) · [Books I–VI](../books/) +**Companion to:** [Field Guide 2026](../books/field-guide-2026.md) · [Books I–VI](../books/README.md) **Next review:** January 2027 --- diff --git a/antifragile-consulting/core/about-cqre-cs.md b/antifragile-consulting/core/about-cqre-cs.md index 9fda792..7a212f8 100644 --- a/antifragile-consulting/core/about-cqre-cs.md +++ b/antifragile-consulting/core/about-cqre-cs.md @@ -1,18 +1,18 @@ # 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).* +*Tato stránka představuje CQRE a metodiku Brownhat novým klientům a novým členům týmu.* + +*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ě]. +**CQRE.NET Ltd** je specializovaná konzultační společnost v oblasti kybernetické bezpečnosti. Působíme primárně z **Prahy** a pracujeme s klienty ve **střední Evropě a Velké Británii**. Naši klienti přerostli generické rady — středně velké společnosti, telekomunikační operátoři, energetika a finanční instituce se skutečnými prostředími, stávajícími investicemi a konkrétními hrozbami, na které zaškrtávací rámce nestačí. -> **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. @@ -27,7 +27,7 @@ Pomáháme organizacím překlenout propast mezi jejich investicemi do bezpečno - 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í. +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).* @@ -51,19 +51,17 @@ Pět principů formuje každé naše doporučení: ## Čí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". +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í. +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. Vaši vlastní dokumentaci neschováváme za retenčním poplatkem. Po ukončení angažmá jste provozně nezávislí. **4. Zveřejňujeme naše obchodní vztahy.** @@ -71,43 +69,41 @@ Máme obchodní partnerství s Huntress, Tailscale, Thinkst Canary a Tenable. Po **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. +Jsme malá, specializovaná praxe. Neprovozujeme 24/7 operační centrum. Nepodepisujeme compliance audity. Nenahrazujeme 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]** +**6. Provozujeme, co prodáváme.** -> **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, PULSAR, Elysium); jazykové schopnosti; specifické certifikace; metodologický přístup. +Naše vlastní nástroje — ASTRAL pro drift konfigurace, PULSAR pro práci s auditními logy, a playbooky v tomto repozitáři — běží nejdřív u nás. Metody, které nasazujeme u klientů, jsou metody, které sami používáme, včetně agentního operačního modelu, který drží pořádek v naší vlastní infrastruktuře. Nedoporučujeme nic, s čím jsme sami nežili. -[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. +Jsme specializovaná praxe **sedmi až devíti lidí** — architektů, projektových manažerů a specializovaných kontraktorů — vedená naším CEO a firemním architektem. Zůstáváme záměrně malí: každé angažmá vede někdo, kdo sám dělá technickou práci, ne někdo, kdo řídí ty, co ji dělají. -### [PLACEHOLDER: Jméno, role] + --- ## 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] +- **Telekomunikačními operátory** — operátoři a ISP se signalingovým, fraudovým a 5G rizikem; obvykle k nám přicházejí kvůli NIS2 nebo po překvapivém incidentu +- **Energetikou a kritickou infrastrukturou** — výroba a přenos elektřiny, vodohospodářství; organizace řešící konvergenci OT/IT a působnost NIS2/CER +- **Finančními službami** — instituce propracovávající se DORA, PSD2 a SWIFT CSP, které potřebují prokazatelné kontroly, ne dokumentační cvičení +- **Středním trhem s hybridními prostředími** — 200–2000 zaměstnanců, AD plus M365, roky nahromaděného technického dluhu a IT tým, který přesně ví, kde jsou mezery, ale nikdy neměl prostor je uzavřít **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ě. @@ -115,68 +111,44 @@ Pracujeme primárně s: ## 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. +Angažmá uvádíme anonymně; podrobné případové studie — s měřitelnými výsledky — poskytneme na vyžádání. Tři archetypy nedávné práce: -### [PLACEHOLDER: Odvětví a velikost, např. „Středně velká logistická společnost, 300 zaměstnanců"] +- **Náprava identit v kritické infrastruktuře**: počet útočných cest k dominanci nad doménou snížen o dva řády; privilegovaný přístup přestavěn na just-in-time, phishing-resistant autentizaci +- **Záchrana tenanta M365**: tenant E3 překonfigurován tak, aby uzavřel mezery, které jeho vlastník platil SOC k pouhému sledování; výdaje na licence přeměněny na schopnosti +- **NIS2 sprint**: 180 dní od „myslíme, že spadáme pod působnost" k balíčkům důkazů, které auditor přijme — postaveno téměř výhradně z nástrojů, které klient již vlastnil -**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] | | | +| Huntress | Managed EDR, 24/7 threat hunting | Klienti bez Defender P2, kteří potřebují nepřetržité pokrytí endpointů | +| Thinkst Canary | Detekce narušení pomocí deception | Prostředí, která potřebují vysoce signální pasti bez SOC | +| Tailscale | Overlay síť s nulovou konfigurací | Distribuované týmy a scénáře přístupu dodavatelů | +| Tenable | Vulnerability management | Organizace potřebující komerční skenování a reporting | -**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. +**Nenahrazujeme 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."] +**Nebereme angažmá, jejichž cílem je papír bez nápravy.** Pokud je cílem certifikát a ne bezpečnostní pozice, jsme špatná praxe. + + --- @@ -190,25 +162,18 @@ Pracujeme primárně s: | | | |-|-| -| **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] | +| **E-mail** | info@cqre.net | +| **Web** | [cqre.net](https://cqre.net) | +| **Jazyky** | čeština, angličtina, slovenština | +| **Geografie** | Česká republika a Slovensko osobně; vzdálená angažmá po celé EU a ve Velké Británii | +| **Doba odezvy** | Počáteční odpověď do jednoho 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).* +- Platba: 50 % při zahájení, 50 % při dokončení +- Měna: CZK nebo EUR +- Smlouvy se řídí českým právem --- diff --git a/antifragile-consulting/core/about-cqre.md b/antifragile-consulting/core/about-cqre.md index 47f92e2..d191053 100644 --- a/antifragile-consulting/core/about-cqre.md +++ b/antifragile-consulting/core/about-cqre.md @@ -1,24 +1,18 @@ # About CQRE · Brownhat -> ⚠️ **TEMPLATE — NOT READY TO SHARE** ⚠️ -> -> This document contains unfilled `[PLACEHOLDER]` sections. **Do not share this file with clients or external contacts until every placeholder has been replaced with real content and all INTERNAL NOTE sections have been removed.** -> -> To check: `grep -r "\[PLACEHOLDER\]" about-cqre.md` should return no results before this file leaves the repository. -> -> *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).* +*This document introduces CQRE and the Brownhat methodology to new clients and new team members.* + +*A Czech-language version of this document is maintained at [O společnosti CQRE](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]. +**CQRE.NET Ltd** is a specialist cybersecurity consultancy operating primarily from **Prague, Czech Republic**, working with clients across **Central Europe and the UK**. We work with organisations that have outgrown generic advice — mid-market companies, telcos, utilities, and financial institutions with real environments, existing investments, and specific threats that checkbox frameworks do not address. -> **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. @@ -57,8 +51,6 @@ Five principles shape every recommendation we make: ## 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. @@ -79,41 +71,39 @@ We have commercial partnerships with Huntress, Tailscale, Thinkst Canary, and Te 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]** +**6. We operate what we sell.** -> **INTERNAL NOTE** — Add a differentiator specific to your practice. Examples: deep expertise in a specific vertical (OT/utilities, Czech regulatory environment); proprietary tools (ASTRAL, PULSAR, Elysium); language capability; specific certifications; methodology approach. +Our own tooling — ASTRAL for configuration drift, PULSAR for audit-log intelligence, and the playbooks in this repository — runs in our own infrastructure first. The methods we deploy at clients are the methods we run at home, including the agent-assisted operational model we use to keep our own estate honest. We do not recommend anything we have not lived with. -[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. +We are a specialist practice of **seven to nine people** — architects, project managers, and specialist contractors — led by our CEO and Firm Architect. We stay deliberately small: every engagement is led by someone who does the technical work, not someone who manages those who do. -### [PLACEHOLDER: Name, role] + --- ## 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] +- **Telecommunications operators** — carriers and ISPs with signaling, fraud, and 5G-era exposure, usually driven to us by NIS2 obligations or a scare +- **Utilities and critical infrastructure** — power generation, transmission, and water organisations with OT/IT convergence problems and NIS2/CER scope +- **Financial services** — institutions working through DORA, PSD2, and SWIFT CSP alignment who need demonstrable controls, not documentation exercises +- **Mid-market hybrid estates** — 200–2000 employees, AD plus M365, years of accumulated technical debt, and an IT team that knows exactly where the gaps are but has never had the runway to close them **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. @@ -121,59 +111,33 @@ We work primarily with: ## 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. +We reference engagements anonymously and share detailed case studies — with measurable outcomes — on request. Three archetypes of recent work: -### [PLACEHOLDER: Industry and size, e.g., "Mid-market logistics company, 300 employees"] +- **Critical-infrastructure identity remediation**: attack paths to domain dominance reduced by two orders of magnitude; privileged access re-architected around just-in-time, phishing-resistant authentication +- **M365 tenant rescue**: an E3 tenant reconfigured to close the gaps its owner was paying a SOC to watch; licence spend redirected into capability +- **NIS2 readiness sprint**: 180 days from "we think we're in scope" to evidence packages an auditor accepts — built almost entirely from tools the client already owned -**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] | | | +| Huntress | Managed EDR, 24/7 threat hunting | Clients without Defender P2 who need round-the-clock endpoint coverage | +| Thinkst Canary | Deception-based intrusion detection | Estates that need high-signal tripwires without a SOC | +| Tailscale | Zero-config overlay networking | Distributed teams and vendor-access scenarios | +| Tenable | Vulnerability management | Organisations that need commercial-grade scanning and reporting | -**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. @@ -182,7 +146,9 @@ We work primarily with: **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.] +**We do not take engagements where the goal is paperwork without remediation.** If the objective is a certificate rather than a posture, we are the wrong practice. + + --- @@ -196,25 +162,18 @@ We work primarily with: | | | |-|-| -| **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] | +| **Email** | info@cqre.net | +| **Web** | [cqre.net](https://cqre.net) | +| **Languages** | Czech, English, Slovak | +| **Geography** | Czech Republic and Slovakia on-site; remote engagements across the EU and UK | +| **Response time** | Initial response within one 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).* +- Payment: 50% at kickoff, 50% at completion +- Currency: CZK or EUR +- Contracts governed by Czech law --- diff --git a/antifragile-consulting/core/engagement-model.md b/antifragile-consulting/core/engagement-model.md index 6e8849a..09ad649 100644 --- a/antifragile-consulting/core/engagement-model.md +++ b/antifragile-consulting/core/engagement-model.md @@ -295,7 +295,7 @@ Our explicit commitment to maximising existing investments before recommending p 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).* +*For the ROI and risk quantification framework, see [Business Case Template](../playbooks/business-case-template.md).* --- diff --git a/antifragile-consulting/core/interdiction-model.md b/antifragile-consulting/core/interdiction-model.md new file mode 100644 index 0000000..f5fd395 --- /dev/null +++ b/antifragile-consulting/core/interdiction-model.md @@ -0,0 +1,336 @@ +# The Interdiction Model + +> *"A kill chain is not broken by patching the worst thing on it. It is broken by cutting it. Those are different sets, they are usually different sizes, and only one of them is computable. Interdiction is the discipline of finding the cut, pricing it, and declining the work that is not in it."* + +This supersedes the operating model in [Quantum Vulnerability Management](quantum-vulnerability-management.md). The philosophy in [Book VII](../books/06-vulnerability-management.md) is unchanged and the four time budgets survive; what changes is the object being budgeted, the way it is selected, and the metric that says whether any of it is working. It is consumed by the [Kill Chain Assessment app](../playbooks/kill-chain-assessment-app.md) and by ORION. + +--- + +## Why "quantum" retires + +The word was doing two jobs at once — naming the *time budget* (hours / days / sprint) and naming the *unit of work* (atomic, all-or-nothing, closes a path). Those are orthogonal. It also collides with quantum computing, which is not a hypothetical problem: the collision costs a reader a wrong turn through QAOA literature before they arrive at a framework that has nothing to do with it. + +| Was | Is | Why | +|---|---|---| +| quantum | **cut** | The unit is a *cut* in the graph-theoretic sense — the object that actually severs a path. Mathematically exact, one syllable, verbs. | +| critical / severe / standard quantum | **hour-cut / day-cut / sprint-cut** | Time budget becomes an adjective on the unit rather than a competing name for it. | +| dark quantum | **dark** | Unchanged in meaning: cannot be placed inside or outside the cut. | +| — | **declined** | New. Not in any cut, and the intervention is net-negative. | +| "did the kill chain get shorter?" | **cut depth (κ)** | A number, not a question. | +| the framework | **interdiction** | Names an existing body of operations research this is an instance of, rather than inventing a private vocabulary. | + +--- + +## The problem in one paragraph + +Prioritisation by severity fails because severity is a property of the vulnerability and the thing that kills you is a property of the *estate*. Prioritisation by kill-chain position — the previous model — is a large improvement and still wrong in one specific way: it ranks by membership on the cheapest adversary path, and removing a link from the cheapest path does not sever anything, it promotes the second-cheapest path. The set that actually severs is a **cut**, it is not the same set as "everything on the chain", it is usually *smaller*, and unlike the chain it is a thing you can compute, price, and argue about with a client. + +--- + +## 1. The estate graph + +Let **G = (V, E)** be a directed graph over one estate. + +| Object | Definition | Where it comes from | +|---|---|---| +| **V** | States. A state is an (asset, privilege) or (identity, scope) pair — "local admin on the jump host", "the Entra Connect sync account" | Capability templates, asset inventory, BloodHound | +| **E** | Adversary moves. `e = (u,v)` asserts *from u an adversary can reach v* | Consultant judgement, BloodHound paths, the coupling library | +| **S ⊆ V** | Entry set: internet-reachable services, phishable identities, supplier connections, physical access | External scan, perimeter capability | +| **J ⊆ V** | Jewel set: existential states — the estate cannot operate, or cannot recover, past this point | "What stops the business operating?" | + +Add a super-source **σ** with infinite-capacity edges into every member of S, and a super-sink **τ** with infinite-capacity edges out of every member of J. Everything below is then a single-source, single-sink problem regardless of how many entries and jewels exist. + +### Two weights, not one + +This is the structural addition. The previous model carried one weight and it was the wrong side of the problem. + +| Weight | Meaning | Range | Used for | +|---|---|---|---| +| **a(e)** | **Adversary effort** — how hard is this single hop for the attacker | 1 (trivial) … 5 (very hard) | Path finding: where the chain runs | +| **d(e)** | **Defender cost** — what it costs *us* to remove this edge | currency, or ordinal | Cut finding: what we should do about it | + +`a(e)` already exists. `d(e)` does not, and without it no cut can be selected, only enumerated. + +`d(e)` is not a single number but the minimum over the interventions available on that edge: + +``` +d(e) = min cost(i) over i ∈ I(e) +I(e) = { patch, compensating control, architectural change, decommission } +``` + +and each intervention carries three attributes that the cost alone does not capture: + +``` +time_class hours | days | sprint → which budget it fits +reversibility reversible | costly | irreversible +iatrogenic P(this change breaks something) × outage cost +``` + +An edge removable by a firewall rule and an edge removable only by a vendor patch with a reboot are both "one edge" to the graph and nothing alike to the business. `d(e)` is where that difference lives. + +--- + +## 2. A path is not a cut + +The previous model's definition of P0 — *"on the shortest chain; break any one link and the existential path is severed"* — holds only when exactly one path exists. + +``` + ┌──── a=2 ──── x ──── a=3 ────┐ + σ ───┤ ├─── τ shortest chain = 5, via x + └──── a=3 ──── y ──── a=4 ────┘ second chain = 7, via y + + Break the x-chain: the estate is not severed. It is now a 7 instead of a 5. + You have bought the adversary two effort units and spent a change window. +``` + +### Definitions + +A set **C ⊆ E** is an **(S,J)-cut** if every directed path from S to J uses at least one edge of C — equivalently, G − C contains no S→J path. + +- **Minimum cut**: a cut minimising |C|. +- **Minimum-cost cut**: a cut minimising Σ d(e) over e ∈ C. + +Both are computable in **polynomial time** by max-flow / min-cut with edge capacities set to `d(e)`. There is no NP-hardness here and no reason to reach for anything exotic. + +**Node removal** — remediating a *host* or an *identity* rather than a single hop — is handled by the standard node-splitting transformation: replace each `v` with `v_in → v_out` carrying capacity equal to the cost of remediating `v`, leave original edges at infinite capacity, run the same algorithm. Most real remediation is node removal, so this is the common case, not the exception. + +### Menger's theorem, and why it matters commercially + +The maximum number of edge-disjoint S→J paths equals the cardinality of the minimum S→J edge cut. So the minimum cut is not merely *a set of things to do* — its size is **the number of independent successes the adversary needs**. + +That is a number you can put in front of a board: + +> *Your estate has a cut depth of 1. One compromised service account ends it. The programme takes you to 4.* + +Compare with a CVSS distribution, which says nothing and cannot be moved. + +### Worked example + +Eight edges, three routes to the domain controller. Adversary effort in the first number, +defender cost in the second. + +``` + ┌── web ──────── app ───────┐ + (a2,d9)│ (a3,d6) (a2,d8)│ + │ ▼ + entry ────────────┼── vpn ──── jump ────────► dc + (a3,d7) │ (a1,d5) (a2,d4) ▲ + └── phish ────────┘ │ + (a1,d9) (a4,d6) │ +``` + +- **Shortest chain**: `entry → vpn → jump → dc`, adversary effort 6. +- **Old P0 rule** — break the weakest link on that chain, `vpn → jump`: + the estate is **still connected**, now via `entry → phish → jump → dc`. + A change window spent, nothing severed. +- **Minimum-cost cut**: `{ web → app , jump → dc }`, defender cost 10. The estate is + disconnected. +- Note that `web → app` **is not on the shortest chain at all.** The cut routinely + contains edges the chain-position model never surfaces, and omits edges it flags as + critical. +- **κ̂ = 2**, matching the two edge-disjoint routes — Menger, as expected. + +The general lesson: *the set you must act on is not a subset of the chain you can see.* + +--- + +## 3. The cut — the unit of work + +A **cut** (the unit) is one atomic remediation that: + +1. **Removes at least one edge of the selected cut set** — not a finding in the abstract, an edge on a mapped path. +2. **Fits a declared time budget** — hours, days, or a sprint. +3. **Ends in a verifiable signal** — a test proving the edge is gone. An unverified removal is a *ghost cut*: fully traversable and now invisible. + +The properties that made "quantum" a good word survive intact. A cut is **atomic** — a control applied to 80% of the fleet has not removed the edge, it has removed it from the part of the graph you were looking at. A cut is **discrete** — work is packetised into units that fit the time available rather than smeared across a backlog with no front. + +### The five classes + +| Class | Budget | Condition | Response | +|---|---|---|---| +| **hour-cut** | Hours | In the selected cut set; reachable; exploit live; uncompensated | Sever reachability by the cheapest reversible control available. **Not the patch** — the patch may not exist and cannot meet the budget. | +| **day-cut** | Days | In the selected cut set; material but not racing | One change window, batched, verified before closure | +| **sprint-cut** | Sprint | In the selected cut set; no urgency | Engineering rhythm; this is where patch velocity is the correct tool | +| **dark** | Unsized | Cannot be placed inside *or* outside the cut — reachability or exploitability unknown | Route to discovery. Not remediation work. | +| **declined** | — | In no S→J path; intervention is net-negative (§5) | Documented risk acceptance with an owner and a review trigger | + +### The membership rule — and why the old rule over-included + +> **Membership is a property of the selected cut, not of the vulnerability.** + +Two criticals on the same path need one intervention between them, not two. Under the old rule ("on the kill chain → do it now") both were hour-quanta. Under the cut rule the cheaper one is selected and the other is deferred or declined. At client scale this is the difference between a remediation plan that gets executed and one that gets filed. + +--- + +## 4. Labelled cuts — where the leverage actually is + +One remediation usually removes several edges at once. Patching a CVE removes every hop that CVE enabled; disabling NTLM removes a class of relay edges across the estate; deploying one CA policy removes every edge that depended on an unmanaged device. + +Formally, let **ℓ : E → L** map each edge to the remediation that removes it. The problem becomes: find the minimum-cost set of *labels* whose removal disconnects S from J. This is **Minimum Label Cut** (also studied as hedge connectivity), and unlike the unlabelled case it is **NP-hard and hard to approximate in general**. + +That is less of a problem than it sounds and more of an opportunity than it looks: + +- **At estate scale it does not bite.** Hundreds to a few thousand nodes yields an ILP that solves in seconds. +- **A greedy heuristic is serviceable** — repeatedly take the label with the best *edges-severed-per-unit-cost*, recompute, stop when disconnected. Treat this as a heuristic with no approximation guarantee, and verify the result by recomputing the cut on the reduced graph rather than trusting the greedy trace. +- **Label multiplicity is convexity.** A label sitting on six cut edges is a small, bounded cost against a large, structural payoff — [Pillar 5](antifragile-manifest.md) made arithmetic. Ranking candidate labels by multiplicity is the single cheapest piece of analysis in the model. + +> No quantum computer is required, or useful, anywhere in this. Min-cut is polynomial; label cut yields to an ILP at the sizes that occur. The word "quantum" in the previous model never referred to quantum computing, which is part of why it had to go. + +--- + +## 5. Pricing the cut — and the iatrogenic rule + +Patching is a change, and changes break things. A model that treats remediation as costless is not a security model, it is a wish. For an intervention `i` removing edge `e`: + +``` +EV(i) = P(adversary traverses e) × Impact(e) − P(i breaks something) × OutageCost(i) +``` + +Two consequences follow immediately. + +**The ~90% subtraction gets a stronger argument.** The previous model said most criticals are not exploitable, therefore deprioritise. The correct statement is harder: for an edge lying on **no** S→J path, `Impact(e) ≈ 0` existentially, while the iatrogenic term stays strictly positive. **EV is negative. The patch is net-harmful.** That is not "low priority" — it is *do not do this*, and it is via negativa with an arithmetic behind it instead of a slogan. + +**This creates the declined class.** A declined cut is a deliberate, owned, documented refusal — not a backlog item that quietly ages. It carries an owner, the reasoning, and a review trigger, exactly like any other decision. + +> ⚠️ **The declined class is technically defensible and politically expensive.** Under NIS2, ISO 27001, or a regulated utility's own standard, "we computed that patching this is net-negative" may simply not be an available answer regardless of the arithmetic — and an obligation edge (coupling type 6) can force the work anyway. Establish per-client, in writing, whether the declined class exists at all *before* it appears in a deliverable. Where it does not, those items return to the sprint-cut backlog and the honest framing is that compliance is buying insurance at a price the model says is above fair value. That is a legitimate thing for a client to choose. It is not a legitimate thing for a consultant to hide. + +--- + +## 6. Cut depth (κ) — the metric + +Define **κ̂ = |C\*|**, the cardinality of the minimum cut computed on the *mapped* graph. The hat is not decoration; §9 explains why it can never come off. + +| κ̂ | Reading | +|---|---| +| 1 | A single point of existential failure. One success ends it. | +| 2–3 | The adversary needs independent successes, but a competent operator chains them in one campaign. | +| ≥4 | Compromise requires a sustained campaign with multiple independent footholds. | + +### Depth and width are different numbers + +Kill-chain length ℓ measures **depth** — how many hops to the jewel. κ̂ measures **width** — how many independent routes exist. The previous model tracked only ℓ, and ℓ alone is misleading: + +``` + ℓ = 7, κ̂ = 1 long and brittle — one link carries everything. + Looks healthy on a chain-length report. Is not. + + ℓ = 3, κ̂ = 5 short and wide — nasty, but survives single failures + and gives detection five chances instead of one. +``` + +**Report the pair (ℓ, κ̂), never either alone.** Lengthening a chain by a hop while twelve parallel paths remain is cosmetic work that reports beautifully. + +--- + +## 7. Antifragility, formally + +The previous model asserted antifragility and measured it with a question. With κ as a state variable it becomes a condition that can be false. + +Let **Λ** be adversary pressure — the arrival rate of events that test the estate: exploited-or-near findings, incidents, red-team results, disclosed vulnerabilities landing on mapped nodes. + +| Regime | Condition | What it looks like | +|---|---|---| +| **Fragile** | `E[Δκ \| event] < 0` | Each event is absorbed by patching the specific edge. Structure unchanged; the next CVE on the same node reopens it. κ drifts down under pressure. | +| **Robust** | `E[Δκ \| event] = 0` | Events are survived. Nothing is learned. | +| **Antifragile** | `E[Δκ \| event] > 0` | Each event yields a structural cut removing more paths than the event exploited. Pressure makes the estate harder. | + +> **A remediation programme is antifragile if and only if the expected gain in cut depth per unit of adversary pressure is positive.** + +That is gain from disorder stated so it can be falsified, and it is the same claim [Pillar 3](antifragile-manifest.md) makes in prose. + +### Measuring it without fooling yourself + +κ̂ can rise for two entirely different reasons, and conflating them makes the metric worthless: + +- **The estate improved** — a path was severed. This is the signal. +- **The map improved** — discovery found an edge, or resolved a dark one. This is *not* progress in security, though it is progress in knowledge, and it can move κ̂ in either direction. + +So every edge mutation carries a **cause**: `discovery | remediation | drift | disclosure`. The antifragility coefficient is the slope of κ̂ against cumulative events computed **over remediation-caused changes only**. Discovery-caused change is reported separately, as map completeness. + +This also satisfies the process-liveness rule: the κ̂ slope goes bad the moment the feedback loop stops running, and there is no way to improve it by relabelling. + +--- + +## 8. The barbell, derived rather than asserted + +The [barbell](quantum-vulnerability-management.md) was previously a doctrine. It is in fact the shape a cost-minimising cut takes, which is a much stronger position to argue from. + +``` + CHEAP / FAST / REVERSIBLE SLOW / STRUCTURAL / DURABLE + low d(e), reversible high d(e), but ℓ(e) covers many edges + → selected by min-cost cut directly → lowest amortised cost per edge cut + ◄──────────── NEVER SELECTED WHILE ALTERNATIVES EXIST ────────────► + mid-to-high d(e), label multiplicity 1, alternatives + available on the same path. The fragile middle is not + forbidden by doctrine — it simply never wins the argmin. +``` + +Both ends are convex. The middle is concave. The algorithm reaches this on its own, which means the barbell survives a client who does not accept Taleb as an authority. + +--- + +## 9. The completeness problem — a cut claims more than a path + +This is the model's most serious weakness and it must be stated wherever κ̂ is reported. + +**A shortest path is an existential claim: "here is a route."** One counterexample proves it. An incomplete map understates the danger but never invents one. + +**A cut is a universal claim: "there is no route."** It is falsified by a single unmapped edge. On an incompletely mapped graph, a min-cut produces *confident, specific, wrong* assurance — which is worse than the vague discomfort the path model left you with. + +Four constraints follow, and none are optional: + +1. **Conservative closure.** Unknown edges are **present until disproved**. A node pair with unknown reachability contributes an edge. Dark is not absent. +2. **κ̂ is an upper bound.** Report it with the dark-edge count beside it, always. A κ̂ of 4 over a graph with 30 unresolved edges is an assertion, not a measurement. +3. **Language discipline.** Never "the path is severed". Always "every *mapped* path is severed, over a map of stated completeness". The qualifier is the honest part of the sentence. +4. **Edges need falsifiers.** An edge asserted *absent* is a claim, and a claim without a falsifier and a test is an opinion. This is the same discipline the claim ledger already imposes on everything else; edges get no exemption. + +The uncomfortable implication is worth stating plainly: **the model is only as good as the graph, and the graph is always incomplete.** What it buys is not certainty but a specific, checkable place to put the uncertainty — the dark-edge count — instead of spreading it invisibly across a backlog. + +--- + +## 10. Running it + +1. **Map.** Nodes, edges, entries, jewels. Unknown reachability becomes an edge, not a blank. +2. **Weight twice.** `a(e)` for the adversary, `d(e)` for us, with time class, reversibility and iatrogenic risk on each intervention. +3. **Label.** Which remediation removes which edges. Rank candidate labels by multiplicity before anything else — this is the cheapest analysis in the engagement and it usually reorders the plan. +4. **Cut.** Min-cost cut over `d`. Node-split where remediation removes a host or identity. +5. **Classify.** Every edge in the cut set into hour / day / sprint. Everything in no S→J path into declined — subject to the obligation check. Everything unresolvable into dark. +6. **Decline explicitly.** Owner, reasoning, review trigger. A declined cut that is not written down is not a decision, it is an omission. +7. **Execute and verify.** Each cut closes with a signal. No signal, no closure — a ghost cut is worse than an open one. +8. **Recompute.** New κ̂. Tag each edge change with its cause. +9. **Close the loop.** After every exploited-or-near event, ask what structural cut it bought. Chart κ̂ against cumulative events over remediation-caused changes. That slope is the programme. + +--- + +## 11. What would falsify this + +Stated as tests, because a model whose failure conditions are unspecified is a belief. + +**Does the computed cut match what actually worked?** Run it backwards over two completed engagements. If the min-cost cut names five interventions, the engagement did five different ones, and the estate demonstrably improved — the cost model is wrong, or the graph was. + +**Is `d(e)` estimable?** Have two consultants independently price the same estate. If they disagree by more than a factor of two, the min-*cost* cut is noise and only the unweighted κ̂ survives. This is the most likely failure and it should be tested before any of this reaches a client. + +**Does κ̂ move when it should?** A completed segmentation project that does not move κ̂ means either the graph does not represent segmentation or the metric does not capture it. Either way, something is broken. + +**Does the declined class survive contact with a regulator?** Needs a legal read, per client, before it appears in a deliverable. If it never survives, the class is theoretical and the model should say so rather than carrying it as decoration. + +**Is a single (S,J) cut the right object?** An estate with several jewel classes of differing impact may need a weighted multi-terminal formulation; a single cut may over-invest on a cheap jewel or under-invest on an expensive one. Resolve empirically on one real estate before generalising. + +--- + +## Honest uncertainty + +The mathematics is settled and not in doubt — max-flow/min-cut, Menger, node-splitting and the hardness of label cut are textbook. **What is unvalidated is every part where this model meets an estate**: whether consultants can price `d(e)` consistently, whether the coupling library projects into a graph that reproduces real attack paths, whether κ̂ behaves as a programme metric over a multi-year engagement rather than a quarter, and whether the declined class is usable in a regulated entity. Treat the formalism as sound and the application as a hypothesis under test. + +One thing not in doubt: **the previous model's P0 definition was wrong**, and every remediation plan built on "break any one link on the shortest chain" promoted a second path instead of severing anything. That correction stands independently of whether the rest of this survives. + +--- + +## References + +- Wood, R.K. (1993). *Deterministic network interdiction.* Mathematical and Computer Modelling 17(2), 1–18. [doi:10.1016/0895-7177(93)90236-R](https://doi.org/10.1016/0895-7177(93)90236-R) — the canonical formulation: minimise an adversary's network performance subject to a defender budget. +- Israeli, E. & Wood, R.K. (2002). *Shortest-path network interdiction.* Networks 40(2), 97–111. [doi:10.1002/net.10039](https://doi.org/10.1002/net.10039) — the shortest-path variant, closest to the kill-chain framing. +- Menger, K. (1927). Max-flow/min-cut duality; see any graph theory text for the modern statement. +- Zhang, P. et al. *Minimum Label Cut / hedge connectivity* — hardness and approximation landscape, [arXiv:1908.06541](https://arxiv.org/abs/1908.06541). + +*Companion documents: [Book VII — Vulnerability Management](../books/06-vulnerability-management.md) for the philosophy; [Kill Chain Assessment app](../playbooks/kill-chain-assessment-app.md) for the instrument; [AI-Assisted TVM](../playbooks/ai-assisted-tvm.md) for hour-cut automation; [Antifragile Manifest](antifragile-manifest.md) for the pillars this derives from.* diff --git a/antifragile-consulting/index.md b/antifragile-consulting/index.md index 9d1da13..bdfb1f7 100644 --- a/antifragile-consulting/index.md +++ b/antifragile-consulting/index.md @@ -21,7 +21,7 @@ Operational and persuasion documents used in engagements. **Start every new clie | Document | Purpose | Audience | |----------|---------|----------| -| [README](README.md) | Repository overview and quick start | Everyone | +| [Repository README](https://git.cqre.net/cqrenet/antifragile) | Repository overview and quick start | Everyone | | [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 | @@ -119,7 +119,7 @@ Operational and persuasion documents used in engagements. **Start every new clie **Start here (read in order before your first engagement):** -1. [README](README.md) — repository orientation +1. [Repository README](https://git.cqre.net/cqrenet/antifragile) — repository orientation 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 diff --git a/antifragile-consulting/playbooks/rapid-modernisation-plan.md b/antifragile-consulting/playbooks/rapid-modernisation-plan.md index 0206607..25634f5 100644 --- a/antifragile-consulting/playbooks/rapid-modernisation-plan.md +++ b/antifragile-consulting/playbooks/rapid-modernisation-plan.md @@ -99,7 +99,7 @@ These deliverables are based on a typical M365-primary environment with: - Large or complex AD environments add 2–4 weeks to Day 90 work - High user count (500+) adds 2–4 weeks to MFA rollout change management - Constrained IT team availability is the single most common cause of slippage — budget for it honestly in the scope -- OT environments: see the [Critical Infrastructure Adaptation](move-fast-and-fix-things.md#the-critical-infrastructure-adaptation); Day 90 timelines for network segmentation work are longer +- OT environments: see the [Critical Infrastructure Adaptation](../core/move-fast-and-fix-things.md#the-critical-infrastructure-adaptation); Day 90 timelines for network segmentation work are longer **What does not shift the Day 30 milestone:** ASTRAL and PULSAR deploy in hours. The Brownhat Diagnostic is 2 half-day workshops. T0 account hardening is 1–2 weeks of focused work. If Day 30 deliverables are not met, the bottleneck is access provisioning or client availability — both of which are addressable before kickoff. @@ -393,7 +393,7 @@ Hard go/no-go decisions. Not formalities. If phase exit criteria are not met, th - Phase 1 must include OT asset inventory and IT/OT connection map. - Phase 2 segmentation work (IT/OT boundary) is the primary kill chain closure, not identity hardening. -- See [Vertical: Power and Utilities](../reference/vertical-power-utilities.md) and the Critical Infrastructure Adaptation in [Move Fast and Fix Things](move-fast-and-fix-things.md#the-critical-infrastructure-adaptation). +- See [Vertical: Power and Utilities](../reference/vertical-power-utilities.md) and the Critical Infrastructure Adaptation in [Move Fast and Fix Things](../core/move-fast-and-fix-things.md#the-critical-infrastructure-adaptation). --- diff --git a/mkdocs.yml b/mkdocs.yml new file mode 100644 index 0000000..b2092e8 --- /dev/null +++ b/mkdocs.yml @@ -0,0 +1,51 @@ +site_name: Antifragile Enterprise — CQRE Brownhat +site_description: Frameworks, playbooks and assessments for antifragile organizations. CQRE Brownhat consulting. +site_url: https://antifragile.cqre.net/ +repo_url: https://git.cqre.net/cqrenet/antifragile +docs_dir: antifragile-consulting + +# Root README.md duplicates index.md as a landing page; keep it out of the nav. +exclude_docs: | + /README.md + +theme: + name: material + language: en + palette: + - scheme: default + primary: blue grey + accent: amber + toggle: + icon: material/brightness-7 + name: Switch to dark mode + - scheme: slate + primary: blue grey + accent: amber + toggle: + icon: material/brightness-4 + name: Switch to light mode + features: + - navigation.indexes + - navigation.sections + - navigation.top + - navigation.footer + - search.highlight + - content.action.view + +plugins: + - search + +markdown_extensions: + - admonition + - attr_list + - md_in_html + - tables + - toc: + permalink: true + - pymdownx.details + - pymdownx.superfences + - pymdownx.highlight: + anchor_linenums: true + +extra: + generator: false