Na redakční otázky odpovídá Roman Jukl, konzultant, STORYFLEX a.s.

1) Na co bychom neměli zapomenout při tvorbě bezpečnostní politiky?

Vytvoření bezpečnostní politiky samo o sobě vlastně žádnou vyšší bezpečnost nepřinese, přesto má velkou důležitost. Kromě jasného signálu nejvyššího managementu, že organizace má zájem se o bezpečnost zajímat, vyhradí na ni zdroje, bude ji vyžadovat a také kontrolovat, přináší často již první odhalení a otevřeně pojmenovává chyby, o kterých se sice ví, ale přesto se neřeší.

Při tvorbě se určitě nesmí zapomenout na komplexní přístup k problematice, protože osamocený sofistikovaný firewall, skvělý systém šifrování a dokonalá silná hesla jsou vcelku k ničemu, pokud dostatečně protřelý útočník použije jednoduché lsti sociálního inženýrství nebo jsou běžnou praxí hesla přilepená na monitoru.

Velmi důležité také je, aby se v procesech podniku pamatovalo na to, že například ukončením certifikace na bezpečnost informací práce nekončí, ale začíná. Pokud má systém fungovat, musí se trvale udržovat aktuální a živý, musí se revidovat, ale také například opakovaně školit, kontrolovat, prověřovat a to včetně analýz rizik nového druhu.

2) Jak prosadit bezpečnostní politiku u uživatelů?

Zatímco bezpečnostní školení učí uživatele spíše „jak na to?“, nemělo by se zapomínat na neustálé školení „proč?“. Víra v důležitost bezpečnosti informací, přesvědčení každého uživatele, že pokud on selže, může ohrozit práci a výkon organizace, to vše je jako motivace stejně důležité jako to, aby si pamatoval konkrétní postup.

Jiným podstatným faktorem je také příklad viděný v okolí, protože příklady táhnou. Pokud manažer selhává v dodržování některých bezpečnostních praktik, byť o tom skoro „nikdo neví“, je vcelku jasné, že tato informace se „JPP kanály“ dostane do všech nepovolaných uší a neštěstí je na světě: „Proč bych to dělal, vždyť on to taky nedodržuje“. Doporučovat potom pravidelnou kontrolu jako další způsob prosazení bezpečnostní politiky se může minout kýženým účinkem.

3) Jak se nejlépe připravit na incident a co je naopak při přípravě zcela zbytečné?

Příprava může být hodně detailní a konkrétní a přesto nemusí být v konkrétní situaci použitelná a je tudíž zbytečná. Užitečnou věcí může být úplně globální Incident Management Plán, který bude mít odpověď téměř na každou situaci, byť nebude každá tato situace dále konkrétně řešena. V každé situaci pak máme alespoň základní představu, co dělat. Zde platí ono známé „klišé“  - těžce na cvičišti, lehce na bojišti.

4) Které chyby nejčastěji děláme v oblasti „disaster managementu“?

Například bych uvedl formálnost. K čemu je formálně hezky napsaný plán, který však nikdo nikdy nevyzkoušel, zda půjde realizovat? Který už je dva roky starý? K čemu je celá politika, když konkrétní osoba vlastně netuší ani základní věci, které má v případě nutnosti provádět? Tedy disaster plán je nutno vyzkoušet, simulovat si možné krizové scénáře, teprve reálné simulace ukážou problémy, o kterých nikdo netušil, že vůbec existují. Protože v případě nějaké „disaster“ události hrajeme především o čas. O čas obnovy do funkčního stavu. A jak známo, čas jsou peníze.

5) Jak jsou dnes firmy tolerantní k výpadkům systémů? Jak se proti nim zajišťují?

K výpadkům systémů není moc tolerantní téměř žádný uživatel, ale tento mlhavý pojem je lépe objektivizovat do parametrů jako MTPD a RTO. Ty nám skutečně řeknou, jak to je, nebo přesněji řečeno, jak management strategicky rozhodl, že to má být. Pak je možné to porovnat se skutečným stavem věcí a začít případně napravovat.

U řady firem se lze setkat s celkem drahým (a třeba i kvalitním) technickým zajištěním proti výpadku serveru, na který však nenavazuje řešení v dalších potřebných souvisejících oblastech: procesech, infrastruktuře atd.. Skutečná odolnost firmy a reálná schopnost dodržet třeba nějaké RTO je potom zcela ve hvězdách.

Bezpečnostní management