facebook LinkedIN LinkedIN - follow
ITSM (ITIL) - Řízení IT IT Security IT právo Veřejný sektor a zdravotnictví

Zákon o kybernetické bezpečnosti versus ISO 27001

aneb jak vyhovět oběma normám

Jan Goll


Jan GollO zákonu č. 181 z roku 2014 – zákon o kybernetické bezpečnosti (ZoKB), respektive vyhlášce č.316/2014 Sb. – vyhláška o kybernetické bezpečnosti (VoKB) se tvrdilo, že vychází z normy ISO 27001 – Systémy managementu bezpečnosti informací. Z toho plynul předpoklad, že pro naplnění VoKB postačí, když organizace má implementovaný systém řízení bezpečnosti informací (ISMS) právě dle ISO 27001. Toto tvrzení bylo přinejmenším zavádějící, byť podložené ustanovením § 29 –  Prokázání certifikace. Naštěstí se tento problematický paragraf v nové verzi VoKB z roku 2018 již nevyskytuje, a tak i mizí důvod k tvrzení, že když mám zaveden ISMS, jsem v souladu i se ZoKB


Podstatný rozdíl totiž je a vždycky byl v pojetí technických opatření, což má své logické opodstatnění – ISO 27001 je univerzální a to, jakým způsobem ji organizace implementují, je na nich samotných a jen při certifikačním auditu se dvoustupňově zjišťuje, jak byla příslušná doporučení aplikována. V prvním stupni se zjišťuje soulad dokumentace s normou, ve druhém soulad dokumentace s praktickým výkonem a vlastní implementací interních bezpečnostních předpisů. Oproti tomu ZoKB není obecným doporučením, ale závazným předpisem, který organizacím a firmám zajišťujícím životně důležité služby pro chod státu ukládá, jak mají příslušná aktiva chránit, lépe řečeno jaká má být minimální ochrana, a tím zajistit základní funkce státu jak v oblasti kritické infrastruktury, tak i v případě významných systémů a nově i pro digitální služby. Pokud se organizace musí řídit ZoKB, má tento logicky přednost před ISO 27001, což je nutné vzít v potaz a strukturu dokumentace přizpůsobit zákonnému předpisu, až následně pak naplnit požadavky ISO 27001.

Autoři ZoKB mohli jít cestou, že by nechali patřičnou volnost normy a učinili ISO 27001 závaznou jejím uvedením v zákoně (normy v našem právním systému jsou nezávazné a závaznými se stávají až požadavkem uvedeným v zákonné, případně podzákonné normě), ale to by způsobilo řadu dalších problémů vycházejících z volnosti normy, nejednoznačnosti doporučení a v neposlední řadě i z autorských práv a nutnosti pořízení řady norem. Proto si NÚKIB ponechal možnost rychlejší reakce na změny a metodického vedení při implementaci opatření.

Osobně mi dost vadí ortodoxní rozdělení na organizační a technická opatření uvedená ve VoKB, zejména u položek patřících do skupiny technicko-organizačních, ale přesto mi více vyhovuje struktura VoKB než ISO 27001. V praxi se ovšem velmi často setkávám s nutností vyhovět jak normě ISO 27001, tak i ZoKB, což mě vedlo ke sjednocení obou norem a přeuspořádání jich do logické souslednosti, ke které měla nejblíže původní norma ČSN ISO/IEC 27001 z roku 2006, než tato byla narušena v ČSN ISO/IEC 27001 z roku 2014.
 

ČSN ISO/IEC 27001:2014 - Příloha A ZoKB: Vyhláška č.82/2018 Sb. (VoKB)
  §03 - Systém řízení bezpečnosti informací
A. 5 Politiky bezpečnosti informací §30 - Bezpečnostní politika a bezpečnostní dokumentace
A. 6 Organizace bezpečnosti informací §06 - Organizační bezpečnost
A. 6.1.1 Role a odpovědnosti bezpečnosti informací §07 - Bezpečnostní role
A. 15 Dodavatelské vztahy §08 - Řízení dodavatelů
A. 8 Řízení aktiv §04 - Řízení aktiv
  §05 - Řízení rizik
A. 7 Bezpečnost lidských zdrojů §09 - Bezpečnost lidských zdrojů
A. 9 Řízení přístupu §12 - Řízení přístupu
  §19 - Správa a ověřování identit
  §20 - Řízení přístupových oprávnění
A. 11 Fyzická bezpečnost a bezpečnost prostředí §17 - Fyzická bezpečnost
A. 12 Bezpečnost provozu §10 - Řízení provozu a komunikací
A. 13 Bezpečnost komunikací §18 - Bezpečnost komunikačních sítí
A. 12.2 Ochrana proti malwaru §21 - Ochrana před škodlivým kódem
A. 10 Kryptografie §26 - Kryptografické prostředky
A. 14 Akvizice, vývoj a údržba systémů §13 - Akvizice, vývoj a údržba
A. 14.1 Bezpečnostní požadavky informačních systémů §25 - Aplikační bezpečnost
A. 14.2 Bezpečnost v procesech vývoje a podpory §11 - Řízení změn
A. 12.4 Zaznamenávání formou logů a monitorování §22 - Zaznamenávání událostí Inf.Sys. a Kom.Sys., jeho uživatelů a administrátorů
A. 16 Řízení incidentů bezpečnosti informací §14 - Zvládání kybernetických bezpečnostních událostí a incidentů
  §23 - Detekce kybernetických bezpečnostních událostí
  §24 - Sběr a vyhodnocování kybernetických bezpečnostních událostí
A. 17 Aspekty řízení kontinuity činností organizace z hlediska bezpečnosti informací §15 - Řízení kontinuity činností
A. 17.2.1 Dostupnost vybavení pro zpracování informací §27 - Zajišťování úrovně dostupnosti informací
A. 12.7 Hlediska auditu informačních systémů §16 - Audit kybernetické bezpečnosti
A. 18 Soulad s požadavky  
  §28 - Průmyslové, řídicí a obdobné specifické systémy
  §29 - Digitální služby

 A jaký vývoj v požadavcích zaznamenala VoKB? Pokud pomineme nový § 29 – Digitální služby, který se týká specifických subjektů, tak se počet paragrafů zvýšil o jeden a počet požadavků pro kritickou informační infrastrukturu (KII) o 11, což není nikterak dramatické. U významných informačních systémů (VIS) je ovšem situace rozdílná, zde došlo k nárůstu o 91 požadavků, a to zejména v oblasti organizačních opatření. Převážně je to způsobeno zmenšením rozdílu mezi požadavky kladenými na kritickou infrastrukturu a významné informační systémy. V této souvislosti se setkávám s názorem, že je již jedno, zda eviduji zvlášť VIS a KII, a že když bude vše KII, je to pro řízení jednodušší. Což je do jisté míry pravda, ale najdou se i praktické výhody rozdělení – jednou z nich je zajištění kontinuity činností, kdy mám danou prioritu pro KII a následně se řeší VIS. Pokud však budu mít vše v KII, tak obnovuji všechny primární aktiva najednou, což může působit organizační a logistické komplikace.

Co se týká kontrol, ať ve formě interních, či externích auditů nebo auditů certifikačních, je výhodou mít jasnou strukturu požadované dokumentace a vyhnout se zbytečným komplikacím s vyhledáváním popisu jednotlivých opatření. A co si budeme nalhávat… i auditoři jsou jen lidé a také jim jistě bude více vyhovovat jednoduché dohledání opatření, kdy se mohou soustředit na to, zda jsou splněny všechny požadavky. Ostatně pořádek a logická stavba dokumentace svědčí o správném pochopení problematiky a jisté systematičnosti při řízení nejenom dokumentace, ale celého systému bezpečnosti informací.

Další výhodou logické stavby interních bezpečnostních předpisů je snadnější údržba a zajištění konzistence dokumentace při změnách norem, zákonných a podzákonných předpisů, změně externích a interních požadavků, výsledků kontrol, auditů atd.

Bývalý hacker Kevin Mitnick kdysi řekl: „Bezpečnost není technologický problém, ale je to problém lidí a řízení.“ K tomuto výroku bych už jen rád dodal, že skutečně účinné řešení bezpečnosti se nakonec bez technologických opatření neobejde.

Jan Goll
Autor článku je Senior Information Security Consultant ve společnosti Anect.
 

Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.