DORA, aneb jak by mohla podle stávajícího znění vypadat digitální a provozní bezpečnost

ORA dopadá na široký okruh institucí: Banky, pojišťovny, obchodníky s cennými papíry, některé zprostředkovatele, platební instituce, obchodníky s kryptem regulované dle nové regulace MiCA. A také, spíše nepřímo, na jejich dodavatele ICT služeb a produktů. Z toho důvodu je DORA psána relativně obecně, resp. řada ustanovení a povinností ještě bude upřesněna prováděcími předpisy (RTS, ITS).

První návrhy byly představeny

Návrhy prvních čtyř prováděcích předpisů byly zveřejněny v červnu tohoto roku. Jedná se o návrh RTS k řízení ICT rizik, pro hodnocení provozních a bezpečnostních incidentů, k požadavkům na smlouvy s významnými dodavateli v oblasti ICT a ke struktuře evidence všech ICT dodavatelů. Pozitivně lze hodnotit, že se evropské dohledové orgány drží harmonogramu a návrhy prvních prováděcích předpisů již předložily do veřejné konzultace. Na druhou stranu tyto čtyři dokumenty dohromady čítají téměř 300 stran textu. Jejich důkladná analýza a zavedení do praxe v každé dotčené finanční instituci tak budou poměrně náročné. U dalších prováděcích předpisů, které mají být zveřejněny letos a příští rok, na to bude ještě méně času.

I proto je důležité, a v rámci projektu Partners Banky se o to také snažíme, zavádět bezpečnostní opatření pro zajištění digitální a provozní odolnosti chytře, efektivně, využívat synergie s dalšími procesy i benefity z členství ve skupině Partnere.

Například v požadavcích na kontrolu dodavatelů a obsah smluv podle různých regulací lze najít řadu podobných bodů. Ať už jde o GDPR, outsourcing na finančním trhu, NIS2, či nařízení DORA, všechny povinným subjektům ukládají, aby si vybíraly jen důvěryhodné dodavatele, hodnotily a řídily rizika s nimi spojená a nastavily si odpovídající smlouvy. Byť se požadavky uvedených předpisů zcela nepřekrývají, určitě je možné proces výběru, hodnocení a kontroly dodavatelů nastavit tak, aby pokrýval všechny relevantní požadavky. A tím ho urychlit a zefektivnit.

Obdobně různé předpisy a regulace ukládají bance řídit bezpečnostní a provozní incidenty. I v tomto případě je na místě snažit se proces pro identifikace, řešení a reporting incidentů nastavit pokud možno jednotně, aby plnil v nejlepším případě veškeré funkce, které jsou nezbytné pro zajištění vnitřních požadavků na dostupnost a fungování nabízených služeb, a stejně tak pro zajištění souladu s požadavky současných i budoucích právních předpisů.

Důležité je také si uvědomit, že digitální odolnost, resp. obecně informační bezpečnost, je proces, nikoliv stav, kterého lze jednorázově dosáhnout. Proto je nutné k nastavení systému informační bezpečnosti, včetně požadavků nařízení DORA, přistoupit jako k soustavě postupů a kroků, které musí zahrnovat i pravidelnou aktualizaci a hodnocení rizik, jimž organizace čelí, hodnocení účinnosti a přiměřenosti bezpečnostních opatření, pravidelné kontroly ICT dodavatelů a schopnosti reagovat na incidenty a nedostatky, které při provozu nastanou.

4 hlavní požadavky

Hlavní požadavky nařízení DORA je z technického a provozního pohledu možné shrnout do čtyř základních bodů. Jsou jimi: Řídit a pravidelně vyhodnocovat ICT rizika s cílem identifikovat hrozby a zranitelnosti při využívání informačních technologií pro poskytování finančních služeb. Plánovat a řídit implementaci mitigantů rizik, nápravných opatření. Sestavit plán kontinuity podnikání, zajištění dostupnosti prostředků klientů a poskytovaných služeb i v případě provozní chyby nebo bezpečnostního nedostatku, včetně útoku zvenčí. Posuzovat rizika dodavatelských řetězců, tedy včetně subdodavatelů, a řešit i riziko koncentrace, kdy jeden dodavatel dodává více dílčích (nekritických) ICT služeb, ale jeho výpadek by v souhrnu znamenal vážné riziko. Provádět pravidelné penetrační testy.

Aplikovat specifická bezpečnostní opatření, mezi něž patří řízení přístupu k datům a informačním systémům (včetně zajištění silného ověření), a implementace nástrojů a postupů pro zajištění ochrany dat (např. šifrování, prevence úniků dat, síťová bezpečnost atp.) Implementovat nástroje a postupy bezpečnostního monitoringu, sestavit plány reakce na bezpečnostní incidenty, zahrnující postup pro včasný reporting incidentů regulátorům a oznamování závažných incidentů uživatelům, včetně přijatých opatření k ochraně jejich prostředků a osobních údajů.

Zajistit bezpečný vývojový a životní cyklus softwaru - od školení vývojářů a uživatelů, přes připomínkování ze strany bezpečnosti v rámci změnového řízení až po bezpečnostní testy a systematickou detekci a ošetřování zranitelného softwaru.

Partnere Banku budujeme jako mobile only (prostředek elektronického platebního styku je pouze mobilní bankovnictví) a všechny informační systémy vyvíjíme tak, abychom umožnili jejich nativní provoz v cloudu s možností čerpat všechny výhody, které cloud computing nabízí. Mezi ty patří zejména: Finanční a provozní flexibilita.

Nativní geoclustering (geograficky oddělené servery) a vysoká dostupnost, tj. odolnost proti výpadkům. Moderní architektura jako investice do budoucna - dlouhodobý trend ukazuje jasnou výhodu firem schopných adopce cloud technologií.

Cloudová rizika

Na druhou stranu využití cloudu s sebou samozřejmě nese řadu rizik i z pohledu digitální a provozní odolnosti. Hlavními opatřeními (mitiganty) kjejich snížení jsou: Mitigace IT Security rizik vhodnou parametrizací cloud služeb - adopcí vhodného bezpečnostního standardu, jejž poskytovatelé jednotlivých cloudů nabízejí. A to na základě vyhodnocení rizik, které pro provoz banky bude využití konkrétní služby představovat. V důvodných případech doplněné o vlastní dodatečné bezpečnostní opatření, např. šifrování dat klíčem, jejž nemá provozovatel daného cloudu k dispozici.

Mitigace Vendor Lock rizik, tzn. rizik přílišné závislosti na jednom dodavateli, velmi obtížný - čas, peníze, kapacity - přechod k alternativnímu dodavateli nebo na vlastní řešení. Toto riziko lze snížit správným balancováním mezi využíváním exkluzivních služeb cloud providera a přenositelných technologií (např. Open source).

Mitigace rizika úpadku cloud providera, tj. schopnost plné přenositelnosti výpočetního střediska mezi různými cloud providery.

Mitigace rizika lidských zdrojů, tzn. nedostatku odborníků, kteří jsou schopni cloudové služby vyvíjet, integrovat, provozovat a kontrolovat. Jen málo 1T adminů je schopno změnit ze dne na den myšlení on premises -> cloud. Jen málo IT manažerů a finančních a licenčních specialistů je schopno rychle absorbovat změnu myšlení z CAPEX plánování na „pay as you go“, respektive „pay what your admin clicked and you did not approveď”. Od počátku nutno klást důraz na změnu přístupu, vychovávat vlastní talenty, „learning by doing“, schopnost rychlé reakce na neočekávané události a poučení se z vlastních chyb, byť dílčích a bez dopadu na provoz banky.

Zranitelnost plynoucí z využití sdílené infrastruktury, nedostatku výkonu nebo nedostatečné priority v případě většího výpadku poskytovatele cloudu. Větší zákazník bude mít při odstraňování problémů přednost. Lze řešit dedikovaným výpočetním výkonem (zajistit smluvně, kontrolovat) a připravenými náhradními řešeními a havarijními plány pro případ výpadku.

Odpovědnost zákazníka a odpovědnost poskytovatele cloudu

Využití cloudových služeb vyžaduje změnu přístupu k odpovědnosti za zabezpečení dat a digitální a provozní odolnost. Konečná odpovědnost zůstává na bance, resp. finanční instituci, která cloud nebo jakoukoliv další externí ICT službu či dodávku využívá. Platí to i pro odpovědnost za dodržování regulatorních povinností plynoucích například z nařízení DORA.

Poskytovatel cloudu je zodpovědný za „security of the cloud“ - budovy, hardware, připojení k internetu a podle využití (PaaS vs. IaaS) i chod služeb, jako jsou hypervisory, monitoring, zálohování atp.

Správné nastavení využívaných cloudových služeb (geoclustering, šifrování atp.) může významně snížit riziko, že bezpečnostní incident bude mít původ u poskytovatele cloudu. Informační bezpečnost tak bude víc pod kontrolou zákazníka.

Zákazník je zodpovědný za „security in the cloud“ - např. kdo a za jakých podmínek může přistupovat k datům a administrovat provoz a bezpečnost IS (uživatelské role a oprávnění), jestli existuje dostatek kvalitních logů pro šetření incidentů (v jakém rozsahu jsou logy pořizovány a uchovávány, zda jsou fakticky přístupné a mají při řešení incidentů vypovídací hodnotu, obsahují všechny relevantní informace), jestli jsou informační systémy zranitelné a jak to řešit atd.

Zákazník, banka nebo další finanční instituce vždy zodpovídají za to, jakým způsobem se předchází výskytu bezpečnostních událostí a incidentů, jak se monitorují bezpečnostní slabiny chyby a jaká je schopnost bezpečnostní problémy detekovat, včas odpracoval halit, rychle řešit a napravit. Cloud je právě tak bezpečný, do jaké míry si ho zákazník bezpečný udělá.

Správné nastavení využívaných cloudových služeb může významně snížit riziko, že bezpečnostní incident bude mít původ u poskytovatele cloudu. Informační bezpečnost tak bude víc pod kontrolou zákazníka.

Zdroj: bankovnictvionline.cz