antifragile/antifragile-consulting/assessment-templates/nist-csf-baseline-cs.md

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. 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	Toto hodnocení operacionalizuje mapování rámce — domény dotazníku se přímo mapují na referenci
Modular Engagements	Zjištění hodnocení řídí Diagnostic Path a výběr modulů
Antifragile Risk Register	Zjištění hodnocení naplňují počáteční registr rizik
Rapid Modernisation Plan	Výstupní kritéria fáze 1 (Hygiene) zrcadlí zjištění domén Identify a Protect
Business Case Template	Zjištění hodnocení poskytují vstup pro kvantifikaci rizik v business case

---

Pro referenci ke standardům viz NIST CSF 2.0 Mapping. Pro proces výběru modulů viz Modular Engagements. Pro šablonu registru rizik viz Antifragile Risk Register.