Opravdu potřebujete SIEM, abyste splnili požadavky nového kyberzákona? Nebo to jde i jinak?

Tyto otázky si dnes pokládá mnoho organizací ve vyšším režimu povinností. Zejména těch, které dosud pod regulaci nespadaly a kyberbezpečnosti se zatím příliš nevěnovaly.

S novou legislativou totiž přichází i povinnost zavést technická opatření pro logování, vyhodnocování událostí a reakci na incidenty (§ 22 a § 23 vyhlášky). Tedy funkce, které typicky spadají do domény nástrojů typu SIEM.

Pojďme se na toto téma podívat blíže.

Zákon zajímá jen výsledek

Po analýze rizik, které jsem věnoval předchozí článek (zde), čeká povinné organizace výběr nástrojů, díky kterým paragrafy zákona naplní.

Zákon přitom neříká: „Nasaďte X, abyste splnili požadavek Y.“ Tak to nefunguje (oč by to bylo jednodušší, kdyby ano).

Nepreferuje konkrétní technologie, mluví pouze o výsledku.

Dává tím povinným subjektům větší či menší prostor pro kreativitu. Zároveň to ale může vyvolat nejistotu, zda je zvolená cesta 100% správná.

To se týká i paragrafů 22 a 23 vyhlášky, které na první pohled svádí k jedinému řešení, pořídit SIEM. Tedy poměrně složitý, nákladný nástroj po všech představitelných stránkách.

Jenže to, že zákon zmiňuje detekci, zaznamenávání a vyhodnocování kybernetických událostí nemusí nutně znamenat, že každá povinná organizace jej rázem implementuje.

Vždy záleží na velikosti organizace, kapacitách týmu a jejích cílech.

Než se ale pustíme do porovnávání možností, podívejme se na to, co vlastně zákon po regulovaných subjektech v režimu vyšších povinností požaduje.

Co zákon požaduje

Ve vztahu k otázce, zda pořídit či nepořídit SIEM, jsou klíčové především § 22 a § 23 prováděcí vyhlášky k novému ZoKB. Ty definují požadavky na zaznamenávání a vyhodnocování kybernetických událostí.

Paragraf 22 v podstatě říká: logovat musíte, a to smysluplně.

Organizace si podle něj musí určit, na kterých technických aktivech (například servery, síťové prvky, bezpečnostní systémy) bude události zaznamenávat (což by v této fázi již měla vědět na základě vlastního ohodnocení významnosti aktiv a rizik).

Logování se pak musí vztahovat na běžné provozní události (například zahájení a ukončení činnosti aktiva) i na události přímo se vztahující k bezpečnosti poskytované služby. Jde například o přihlašování a odhlašování k účtům, změny a neúspěšné pokusy o nastavení nástrojů, neúspěšné pokusy o provedení privilegované činnosti, atd.

Vyhláška (konkrétně odst. 3 a 4 § 22) stanovuje i minimální rozsah informací, které musí záznam obsahovat – datum a čas, typ činnosti, identifikaci zařízení, uživatele a informaci o úspěšnosti akce.

Nestačí tedy mít „nějaké logy“.

Je potřeba mít centralizovaný nástroj pro sběr a uchovávání záznamů událostí a ukládat je minimálně po dobu 18 měsíců v zabezpečeném úložišti.

V § 23 pak přichází to, co lze na první pohled spojit se SIEMem.

Ve zkratce tento paragraf říká: musíte nejen logovat, ale také události aktivně vyhodnocovat. Vyhláška mluví o „nástroji pro nepřetržité vyhodnocování kybernetických bezpečnostních událostí“.

V praxi to znamená, že data z logů se musí shromažďovat, třídit, seskupovat a korelovat, aby bylo možné detekovat anomálie a potenciální hrozby.

Zákon navíc výslovně uvádí, že tento nástroj má navíc upozorňovat příslušné role nebo osoby na zjištěné události (§ 23 odst. 1 písm. b).

Důležité je také to, že vyhláška mluví o minimalizaci chybných detekcí a o pravidelné aktualizaci pravidel a konfigurace. Takže nestačí nástroj jednou nastavit, musí se udržovat aktuální, reagovat na nové typy hrozeb a přizpůsobovat se změnám v infrastruktuře (§ 23 odst. 2).

§ 22 a 23 prakticky

Když se na oba paragrafy vyhlášky podíváme prakticky, popisují dvě různé úrovně práce s logy.

První z nich vyžaduje, aby organizace logy ze svých systémů (technických aktiv) sbírala, uchovávala a měla je pod kontrolou. Důležité přitom je, že má jít o centralizovanou práci s logy.

Jak to udělat efektivně a bezpečně?

Buď pomocí log management nástroje, nebo rovnou pomocí SIEM systému.

Log management systémy řeší to, co zákon vyžaduje v § 22, tedy centrální sběr, uchovávání a dohledatelnost záznamů. Umožňují vyhledávání, filtrování, retenci a auditní dohled nad tím, kdo má k logům přístup.

§ 23 jde o krok dál. Mluví o vyhodnocování kybernetických bezpečnostních událostí, tedy o schopnosti data z logů analyzovat, korelovat a vyvozovat z nich závěry. A právě zde začíná být situace zajímavější.

Zatímco základní log management nástroj vám ukáže, co se stalo, SIEM dokáže najít souvislosti, vyhodnotit, zda jde o kyberbezpečnostní incident, a včas na něj upozornit.

SIEM totiž umí:

  • agregovat a korelovat události z různých zdrojů (např. Firewall, EDR, Active Directory),
  • rozpoznávat anomálie a vzorce chování, které ukazují na útok nebo nežádoucí chování,
  • a automaticky upozornit bezpečnostní tým, pokud se děje něco podezřelého (na základě definovaných pravidel, takzvaný alerting).

Lze dostát požadavkům § 23 i bez SIEMu?

Alternativy SIEMu

V praxi existují i jiné přístupy, které dokážou zajistit sběr, vyhodnocování a reakci na události. Jak to už ale bývá, vše je ale otázkou kompromisů, nákladů a technické složitosti.

Security Operations Center (SOC) jako služba

Pokud firma nechce budovat vlastní kyberbezpečnostní kapacity, může je outsourcovat formou služby SOC.

Security Operations Center (SOC) je vlastně tým odborníků, kteří disponující patřičnými nástroji (včetně SIEM), sledují dění v síti zákazníka, vyhodnocují bezpečnostní události a v případě incidentu dokážou upozornit na riziko nebo aktivně zasáhnout.

SOC s sebou nese několik výhod:

  • dlouhodobý provozní náklad (nikoliv jednorázový + maintenance, jako při pořízení SIEM)
  • odborníci 24/7 rozumějící hrozbám i technologiím,
  • relativně rychlé nasazení bez nutnosti investovat do vlastní infrastruktury,
  • sdílené know-how, ověřené procesy, aktuální detekční pravidla.

Na druhou stranu je to ale vykoupeno:

  • menší kontrolou nad daty (řeší se samozřejmě smluvně, ale v praxi to bývá citlivá otázka),
  • závislostí na poskytovateli služby SOC,

SOC může skutečně být alternativou pořízení vlastního SIEMU. Zákon o kybernetické bezpečnosti (vyhláška č. 409/2025 Sb., § 23) totiž v podstatě popisuje právě to, co SOC běžně zajišťuje: nepřetržité vyhodnocování, včasné varování a schopnost reagovat.

Pro mnoho povinných organizací s menším IT týmem tak může právě SOC představovat nejrychlejší a nejrealističtější cestu, jak naplnit požadavky § 22 a 23 vyhlášky, aniž by musely implementovat a provozovat vlastní SIEM.

Extended Detection and Response (XDR)

XDR je novější přístup v oblasti kybernetické bezpečnosti, který vznikl jako reakce na limity starších nástrojů, především EDR a částečně i SIEM.

Tyto nástroje kombinují data z více zdrojů (endpointů, cloudových služeb, síťového provozu), analyzují je a v případě detekce hrozby umí spustit automatickou reakci.

Jistým omezením XDR systémů je v současnosti hloubka propojení se zbytkem IT prostředí. Tyto nástroje jsou schopny přijímat a zpracovávat logy z firewallů, antivirů, a dalších sond, ale mají omezení co se týká napojení například na SCADA nebo IoT systémy. Není také výjimkou, že fungují jen v rámci ekosystému jednoho vendora (např. Palo Alto nebo CrowdStrike).

XDR nástroje také nevěnují pozornost dlouhodobé retenci logů – jejich hlavním účelem je real-time ochrana na úrovni sítě a koncových zařízení. Uchování logů u nich sice možné je, ale za cenu vysokých nákladů.

Oproti tomu je SIEM mnohem univerzálnější platforma.

Vyspělé organizace tedy XDR využívají spíše v kombinaci se SIEMem pro posílení svých detekčních a reakčních schopností v rámci bezpečnostní architektury,

Na druhou stranu si lze představit speciální případy, kdy je možné XDR pro naplnění požadavků zákona použít. Například pokud organizace provozuje víceméně ucelenou infrastrukturu od jednoho výrobce, může být XDR – v kombinaci s log management nástrojem a systémem pro Managed Detection and Response (MDR) – volbou, která navíc umožní i automatizovanou reakci na incidenty.

Takové nastavení je však už složitější a ve výsledku i nákladnější, protože mimo jiné přináší nutnost spravovat více dodavatelů a různá SLA.

Pokročilé log management řešení

V kyberbezpečnosti je běžné, že vendoři přidávají do svých nástrojů funkce tradičně vyhrazené jiné skupině nástrojů. To se děje i v případě log managementu, který byl historicky používaný výhradně pro centralizovaný sběr, prohledávání a dlouhodobé uchování logů pro účely IT compliance.

Řada výrobců dnes své log management nástroje rozšiřuje o pokročilé analytické, korelační a alertovací funkce. Nabízejí je pak jako odlehčenou alternativu k SIEMu, která zvládne centrální sběr, vyhledávání, základní analýzu, korelace i upozornění na události.

Takové řešení by z hlediska nákladů, administrace a údržby mohlo představovat vhodný kompromis především pro menší a střední organizace podléhající požadavkům vyššího režimu zákona.

Je však třeba vždy oddělit marketing od skutečných schopností systému a dané řešení dobře otestovat. Pokud nabízí integrace s běžně používanými technologiemi a umožňuje definici pravidel pro detekci anomálií (na základě thresholdů, pravidel, případně integrací threat intelligence feedů), může pokrýt i požadavky paragrafu 23.

Bez SIEMu to (nejspíš) nepůjde

Z pohledu požadavků nového zákona o kybernetické bezpečnosti je zřejmé, že organizace musí zavést nejen logování klíčových událostí, ale také jejich vyhodnocování, eskalaci a reakci.

Nestačí logy jen sbírat, je potřeba s nimi aktivně pracovat.

SIEM v tomto kontextu představuje nejpřímější a nejucelenější cestu, jak požadavky § 22 a § 23 vyhlášky technicky naplnit.

Existují samozřejmě i alternativy, které mohou být zajímavé pro organizace s menším IT týmem, omezeným rozpočtem nebo nedostatkem odborné kapacity. Kompromisům se ale nevyhnete.

Outsourcování prostřednictvím služby SOC může internímu týmu výrazně ulevit a umožní vyhnout se složité implementaci SIEMu, zároveň však přinfáší závislost na dodavateli a nutnost dobře vyřešit kontrolu nad daty.

XDR sice dokáže pokrýt část funkcí SIEMu, zejména v oblasti detekce incidentů, ale obvykle mu chybí hlubší integrace s infrastrukturou a možnosti dlouhodobé archivace logů pro auditní účely.

Pokročilý log management zase typicky zvládne sběr a retenci událostí, ale jen omezeně podporuje korelaci a detekci v širším kontextu. Pro jednodušší prostředí, kde je potenciálně možné události vyhodnocovat manuálně, to může stačit. Ale jakmile se IT infrastruktura větví a hrozby jsou sofistikovanější, je potřeba jisté automatizace. Možnosti i pokročilého log management nástroje pak mohou narážet na své limity.

Pro většinu povinných subjektů tak bude SIEM nejspíše nutností. A to nejen kvůli požadavkům zákona, ale i s ohledem na dlouhodobou udržitelnost a efektivitu bezpečnostního dohledu, který nová legislativa vyžaduje.

Vzhledem k nákladům pak v praxi bude nejběžnějším řešením služba SOC, kdy dodavatel nasadí své SIEM řešení, které v sobě už bude mít zabudovaný i log management.

Co si o tom myslíte vy? Lze naplnit požadavky zákona i bez SIEMu? A pokud ano, za jakou cenu a s jakými kompromisy?