Spojte se s námi

Buďte s námi v kontaktu

Technická opatření k ZoKB – zápisky ze CyberEdu Konzultační hodiny

Tentokrát jsme se v CyberEdu Konzultační hodině zaměřili na Technická opatření, které se vztahují k zákonu o kybernetické bezpečnosti. Expertním hostem byl Viktor Tyúkos z EY. Níže si můžete shlédnout záznam vysílání, nebo přečíst poznámky.

Technická bezpečnostní opatření – Režim vyšších povinností

Zákon definuje 11 oblastí pro technická opatření:

1. Fyzická bezpečnost

    ◦ Cílem je předcházet poškození, odcizení nebo zneužití cenných aktiv.

    ◦ Je nutné vymezit fyzický bezpečnostní perimetr a rozdělit jej do ochranných zón podle důležitosti aktiv. (Např. recepce vs. serverovna).

    ◦ Opatření zahrnují: zámky, turnikety, čipové karty, biometrii (otisky prstů, skeny zornice).

    ◦ Dále: protipožární ochrana, automatizované hasicí systémy, záložní zdroje pro případ výpadku elektřiny.

    ◦ Kamerové systémy a logování vstupů (kdo, kdy, kam vstoupil).

    ◦ Důležité je i používat selský rozum: např. zabezpečené dveře do serverovny jsou k ničemu, když jsou stěny ze sádrokartonu nebo nevedou až ke stropu (umožňující přelézt).

2. Bezpečnost komunikačních sítí

    ◦ Segmentace sítě je klíčová (oddělit vývojová, testovací, administrativní a zálohová prostředí).

    ◦ Důležitá je dokumentace datových toků a komunikace mezi segmenty, nejen dokumentace samotných segmentů. Nedostatečná dokumentace vede k volně nastaveným firewallům a pravidlu „allow any“, což ruší efektivitu firewallu.

    ◦ Zabezpečené vzdálené přístupy (např. VPN) s rozumnými timeouty a vynuceným opětovným přihlášením.

3. Správa identit

    ◦ V době remote work je identita uživatele nejdůležitější věcí k ochraně.

    ◦ Implementace centrálního nástroje pro správu a ověřování identit (Identity Access Management – IAM).

    ◦ Multifaktorová autentizace (MFA) by měla být téměř všude.

    ◦ Zero trust přístup: ověřovat identitu uživatele před přístupem ke každému systému.

    ◦ Kde nelze použít MFA, použít kryptografické klíče, certifikáty nebo dostatečně silná hesla.

    ◦ Požadavky na hesla: velká/malá písmena, speciální znaky, čísla. Pozor na snadno uhodnutelné vzorce (první písmeno velké, pak čísla, speciální znak). NIST již nevyžaduje expiraci hesel a preferuje passwordless autentizaci (Face ID, otisky prstů).

    ◦ Osobní tip pro hesla: Diceware – generuje hesla z kombinace čtyř slov, která jsou snáze zapamatovatelná a stejně silná jako náhodně generovaná dlouhá hesla.

    ◦ „Break Glass“ účty (nouzové/záložní účty pro obnovu systému nebo bezpečnostní incident) musí být stejně komplikované, s 22 znaky. Hesla by měla být odrotována/změněna při podezření na kompromitaci. Přístup k nim by měl být pouze v případě potřeby (např. v obálce v trezoru).

4. Řízení přístupových práv a oprávnění

    ◦ Často integrováno s IAM systémy.

    ◦ Dodržování principů nejnižšího oprávnění a řízení na základě rolí (čtení/zápis, přístup k aktivům).

    ◦ Žádné konflikty zájmů v definici rolí.

    ◦ Pro administrátorské účty se používá „Just in Time access“ (krátkodobý přístup pro konkrétní úkon), často s nástrojem Privileged Access Management (PAM).

    ◦ Nepoužívat sdílené administrátorské účty; každý administrátor by měl mít svůj vlastní účet pro lepší dohledatelnost.

5. Detekce bezpečnostních událostí a incidentů

    ◦ Vyhláška vyžaduje kontrolovat a blokovat komunikaci nejen na perimetru sítě (internet), ale i mezi jednotlivými segmenty a uvnitř segmentů.

    ◦ Řídit a sledovat dění na koncových stanicích (spouštění programů, kódu, připojování externích zařízení).

    ◦ Používat nástroje, které dokáží vyhodnocovat události na základě chování (programů, uživatelů, síťové komunikace), nejen na základě známých virů.

6. Zaznamenávání událostí (Logování)

    ◦ Důležité je stanovit rozsah a detail logování na základě hodnoty aktiv a bezpečnostních potřeb.

    ◦ Zajistit synchronizaci času napříč všemi systémy pro korelaci událostí.

    ◦ Pro nové systémy a servery by měly být připraveny automatické integrace s log managementem (např. přes image), aby se předešlo manuálním chybám.

    ◦ Minimální rozsah logování dle vyhlášky:

  • všechny detekované události a incidenty,
  • síťová komunikace,
  • přihlášení/odhlášení (úspěšné i neúspěšné),
  • pokusy o privilegované činnosti,
  • činnosti uživatelů (datum, čas, časové pásmo, typ činnosti, uživatel, účet, identita).

    ◦ Zajistit důvěryhodnost a integritu logů, aby útočník nemohl změnit.

    ◦ Mít centralizovaný nástroj pro sběr a uchovávání logů, oddělený od zbytku sítě (ochrana před ransomwarem).

    ◦ Uchovávat záznamy minimálně 18 měsíců.

7. Vyhodnocování bezpečnostních událostí

    ◦ Množství logů a dat vyžaduje automatizované systémy jako SIEM (Security Information and Event Management). Microsoft v Azure zavádí AI agenty pro korelaci dat.

    ◦ SIEM není „magická krabička“; vyžaduje neustálou optimalizaci, ladění a testování pravidel.

    ◦ Minimalizovat false positives (hlášení událostí, které se nestaly).

    ◦ Preferovat menší množství dobře vyladěných pravidel před tisícovkou špatně spravovaných.

8. Aplikační bezpečnost

    ◦ Doporučuje se používat pouze podporovaná technická aktiva; systémy po „end of life“ minimalizovat, izolovat nebo nahradit.

    ◦ Klasický vulnerability management: skenování zranitelností, aplikování patchů, pravidelné updatování systémů.

    ◦ Penetrační testování: během vývoje, po větších updatech a pravidelně alespoň jednou za dva roky. Penetrační testy nenajdou všechny zranitelnosti a mají časové omezení. Důležité je výsledky řešit a provádět retesty.

9. Šifrování

    ◦ Požadavek na šifrování veškeré komunikace (e-mailová, telefonní, hlasová – např. přes Teams).

    ◦ Pro implementaci šifer používat doporučení od NÚKIB (Národní úřad pro kybernetickou a informační bezpečnost).

    ◦ Správa kryptografických klíčů a certifikátů pomocí nástroje, který automatizuje jejich generování, distribuci, ukládání a případnou revokaci.

    ◦ Pravidelně kontrolovat a auditovat klíče a certifikáty.

    ◦ Udržovat šifrovací algoritmy aktuální (např. používat TLS 1.3 namísto starších verzí jako 1.0 nebo 1.1, které jsou prolomitelné).

10. Zajištění dostupnosti regulované služby

    ◦ Stanovení BCM (Business Continuity Management) a BCP (Business Continuity Plan) plánů.

    ◦ Technická podpora: zálohování, zajištění integrity záloh, testování obnovy systémů ze záloh, znalost rychlosti a času obnovy.

    ◦ Ideálně pravidlo 3-2-1: tři lokální zálohy, dvě off-site zálohy, jedna offline záloha (např. na páskách).

    ◦ Příklad ze Slovenska: měsíční nedostupnost katastru nemovitostí kvůli nedostatečnému zálohování/obnově.

11. Zabezpečení průmyslových a řídicích systémů

    ◦ Platí pro ně všechna výše uvedená opatření, ale s řadou specifických požadavků.

    ◦ Často se jedná o proprietární systémy s omezeným přístupem a fyzickou bezpečností.

    ◦ Mají pomalejší upgrade cyklus (životnost 15, 20, 30+ let), což znamená zastaralé systémy s menším výpočetním výkonem.

    ◦ Někdy samotné šifrování může být natolik náročné, že ovlivní primární funkcionalitu výrobní linky.

Technická bezpečnostní opatření – Nižší režim povinností

• Většina základních požadavků z vyššího režimu platí i pro nižší režim, ale v omezenějším rozsahu.

• Týká se šesti oblastí (oproti 11 pro vyšší režim).

• Odpadají některé „přesahující“ požadavky: např. nepotřebujete nástroj pro automatickou správu certifikátů (lze manuálně), nepotřebujete XDR/EDR pro kontrolu chování uživatelů na koncových stanicích.

• Základ jako správa identit, MFA, šifrování komunikace, segmentace zůstává.

Organizací opatření jsme probírali v tomto článku.