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

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>
2026-05-27 21:33:52 +02:00
parent 7bab42398a
commit 64f73371c9
24 changed files with 3325 additions and 66 deletions
@@ -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).*