Alternativa má jméno FRAP aneb jak se v analýze rizik neutopit

Existuje celá řada většinou „velmi formálních“ metodik, které vám pomohou provést smysluplnou analýzu rizik (ISO/IEC 27005, 31010, vyhláška o kybernetické bezpečnosti atd.). Tyto metodiky se drží klasického přístupu: definice rozsahu analýzy – identifikace a ohodnocení aktiv – identifikace a ohodnocení hrozeb a zranitelností – ohodnocení rizik – návrh (proti)opatření – rozplánování jejich realizace v čase. V organizacích s velkým počtem zaměstnanců a systémů se obvykle jedná o zdlouhavý, tedy časově a finančně náročný proces. Před skoro 20 lety představil v tomto časopise kolega Viktor Seige alternativu k takovýmto klasickým metodikám. Jedná se o článek „Alternativa má jméno FRAP“ (Facilitated Risk Analysis Process) v čísle 2003/1, který i po těch letech doporučuji.

analýza rizik        FRAP         bezpečnost informací           řízení rizik          kvalitativní metoda          ISMS

Proč nezůstat u klasiky a použít FRAP? Kolega Seige v citovaném článku uvádí stále platné charakteristické rysy, k nimž si dovolíme stručné doplnění:

1. Metodika je velmi flexibilní. Lze ji použít na jakoukoli oblast, tedy nejen na IT. Záleží v zásadě pouze na facilitátorovi, jak rychle a jak do hloubky bude celý proces analýzy rizik probíhat, tedy jak dlouho bude trvat a jak dlouhý seznam rizik bude na jeho konci.
2. Poskytuje rychle použitelné výsledky. S trochou nadsázky lze říci, že (dílčí) výsledky mohou být k dispozici v zásadě obratem.
3. Do řešení bezpečnosti jsou aktivně vtaženi pracovníci z různých oblastí organizace. Díky tomu, že se na analýze aktivně podílejí, jsou ti aktivnější vtaženi do řešení rizik a o to aktivněji se podílejí na realizaci (proti)opatření. Ti pasivnější jsou alespoň „kompromitováni účastí“ a nemohou se tvářit, že se jich výsledky netýkají, což je častým neduhem zejména dotazníkových postupů.

Cílem tohoto pokračování je ukázat, jak může být metodika FRAP implementována. Za léta, kdy FRAP používáme, jsme nastřádali řadu (věříme) užitečných doporučení. Pokusíme se popsat: co považujeme za rozumnou oblast pro provedení analýzy, jak chápat pojem riziko, jak rizika ohodnocovat a jak analýzu konkrétně provést. Ale také na co si dát opravdu pozor a proč.

Na úvod trocha teorie

Riziko je chápáno jako funkce zranitelnosti, hrozby a dopadu a k jeho eliminaci se přijímají opatření. S dopadem a opatřením obvykle problém nebývá, protože s těmito entitami uživatelé, administrátoři atd. (obecně respondenti v procesu analýzy rizik) v životě běžně pracují. Asi všichni máme osobní zkušenost s odhadem škod (dopad) při vykradení bytu (riziko), kdy pro jejich eliminaci uzavíráme pojistky (opatření). Horší už to je s pojmy zranitelnost a hrozba.

Zkuste si sami rozpitvat riziko vykradení bytu na zranitelnosti a hrozby. V lepším případě to dá nějakou práci. A co pak zranitelnosti a hrozby ve světě informační bezpečnosti, ve kterém se respondenti ne zcela přesně orientují. Proto používáme určitou modifikaci pojmu riziko. Je to:

• ošklivá událost (byl jsem vykraden) – koreluje s hrozbami (žiji v zemi, kde se hodně krade, dávám na odiv své bohatství, bydlím ve čtvrti se silnou koncentrací zlodějů),
• která se stane s jistou pravděpodobností – koreluje se zranitelnostmi (sousedé nezavírají vchodové dveře, bydlím v přízemí bez mříží na oknech, dveře do bytu dokážu bez klíče „otevřít“ i já),
• může mít negativní dopad (mám drahou televizi, běžně mám doma velkou hotovost) – to je ten bezproblémový dopad,
• a pro jeho eliminaci/snížení přijímám opatření (uzavírám pojištění) – to je to bezproblémové opatření.

Podívejme se nyní na hodnocení pravděpodobnosti a dopadu. Pro obě entity doporučujeme třístupňovou kvalitativní škálu. Počet hodnotících stupňů může být i vyšší, ale je potřeba vždy vycházet z konkrétních podmínek a přihlédnout k úrovni orientace účastníků analýzy v oblasti bezpečnosti a hodnocení rizik. Např. čtyřstupňová škála uvedená ve vyhlášce o kybernetické bezpečnosti má podle našeho názoru jedno základní úskalí – nekonečné diskuse zejména v případě těch dvou stupňů uprostřed („málo pravděpodobné až pravděpodobné“ vs. „pravděpodobné až velmi pravděpodobné“), při kterých ani slovní popis nemusí být dostatečným pomocníkem. A pětistupňová škála, kterou používá např. ISO/IEC 27005 a 31010, může být zejména zpočátku pro respondenty zbytečně rozsáhlá.

Je na facilitátorovi se v průběhu workshopu přizpůsobit dané situaci tak, aby hodnotitelé jednotlivé úrovně pravděpodobnosti a dopadu intuitivně chápali. Každopádně je nutné zdůraznit, že volba škály hodnocení pravděpodobnosti, dopadu a rizik nemá na proces jako takový žádný vliv.

Tím je dán základní rámec pro identifikaci a hodnocení rizik a můžeme přejít k tomu, jak vypadá upravený průběh FRAPu. Základní pravidla a postupy, které popsal kolega Seige (rozdělení na oblasti, příprava FRAP workshopu, FRAP workshop, FRAP zpracování, příprava a formulace výstupní zprávy), jsme trochu upravili do podoby jakési dodavatelské modifikace FRAPu. Facilitátora, který to celé odřídí, jsme nahradili menším realizačním týmem, který část činností udělá za analyzovanou organizaci. Jeden FRAP workshop jsme nahradili dvěma: jedním „analytickým“, jehož cílem je popis stavu (realizační tým musí přesně vědět, jak analyzovaná oblast a její IT podpora funguje), a druhým „hodnotitelským“, jehož cílem je identifikace a ohodnocení (prioritizace) rizik. Jak tedy celý průběh FRAP analýzy vypadá?

Definování analyzované oblasti

Za tu doporučujeme považovat jeden informační systém. Odpovídá to i odpovědnostem ze zákona o kybernetické bezpečnosti, resp. konkrétně odpovědnosti správce. Ten věcně řídí určitou oblast, která je typicky podporována jedním informačním systémem: personalistika má svůj personální systém, finanční řízení ekonomický systém atd. Rozhodně nevadí, že se nám analyzované oblasti mohou překrývat (rozhraní, společná úložiště). Jen je potřeba při analýzách případná rizika identifikovat a ohodnotit i s ohledem na tyto překryvy.

Sestavení realizačního týmu

Ve velkých organizacích je obvykle složité, ne-li nemožné, sezvat všechny respondenty na zhruba půldenní až celodenní workshop. Proto jsme postup trochu upravili. Pro získání detailního přehledu o analyzovaném systému absolvujeme jeden analytický workshop. Resp. jedná se o několik samostatných workshopů s několika kategoriemi respondentů:

• uživatelé, přesněji zástupce věcně příslušné organizační jednotky (správce primárních aktiv), a uživatelé systému,
• dodavatel aplikace (není podstatné, zda je aplikace dodána interně nebo externě),
• dodavatel infrastruktury (opět není podstatné, zda je infrastruktura provozována interně nebo externě).

V případě analýzy rizik aplikací provozovaných v cloudu pravděpodobně nebude možné realizovat workshopy s jeho provozovatelem. Určitě ale musí být jedním z respondentů pracovník, který má na starosti konfiguraci a dohled nad tímto cloudovým řešením. A do analýzy je nutné zahrnout možnosti nastavení prostředí a dostupných bezpečnostních mechanismů cloudu. V jejím průběhu pak musí být posouzeno nastavení těchto bezpečnostních mechanismů (např. ponechání defaultního nastavení nebo uplatnění požadavku na jeho úpravu v rámci možností, které daný cloud poskytuje).

Realizační tým musí svými znalostmi a praktickými zkušenostmi pokrýt celou diskutovanou problematiku. Minimalistické složení obvykle stačí:

• někdo za procesní stránku bezpečnosti (jak funguje ISMS a ITIL),
• někdo za technickou stránku bezpečnosti (vždy podle definovaného rozsahu analýzy – síťový design, segmentace, řízení/filtrace síťového provozu, operační systémy, virtualizace, kontejnerizace, databáze, vícevrstevná aplikační architektura, uživatelská zařízení),
• někdo za fyzickou bezpečnost, pokud je v rozsahu analýzy (bezpečnostní dveře, zámky, řízení fyzického přístupu, EZS a EPS systémy).

Získání podkladů

Po sestavení realizačního týmu oslovíme zástupce věcně příslušné organizační jednotky (správci primárních aktiv) a provozovatele za účelem:

• získání obecného popisu agendy a zpracovávaných dat (proč a za jakým účelem se dané činnosti dělají, kolik a jakých pracovníků s analyzovaným systémem/agendou pracuje, existuje-li veřejná neautorizovaná část, případně naopak jsou-li některé části ve zvláštním režimu, např. dle zákona 412/2005 sb., apod.),
• získání informací o procesní stránce agendy, které její části/procesy jsou řešeny digitálně a které papírově, jak funguje archivace historických dat,
• získání dokumentace, smluv, SLA,
• získání kontaktů na osoby, které daným materiálům rozumějí a orientují se v dané problematice, tedy potenciální respondenty,
• informování budoucích respondentů, jakou součinnost budeme z jejich strany potřebovat.

Příprava „analytického“ FRAP workshopu

Kvalitní příprava tohoto FRAP workshopu zcela zásadně ovlivní kvalitu celé analýzy. Realizační tým musí ze získaných podkladů připravit vlastní podklady, se kterými bude v rámci workshopu aktivně pracovat. Typicky se jedná o:

• seznam aktiv (primární, podpůrná, externí),
• interní předpisy/směrnice na téma práce s informačním systémem, osobními údaji apod. (existují-li),
• dokumentaci (instalační, administrátorská, bezpečnostní, uživatelská, havarijní plány),
• smluvní zajištění včetně SLA.

Na základě těchto podkladů si předem připravíme seznam oblastí, o kterých je nezbytné s uživateli a provozovateli diskutovat. Nejvíce se nám osvědčil seznam bodů (odrážek) v rozsahu jedné až dvou stránek. Tento seznam předem pošleme respondentům, aby věděli, čeho se bude workshop týkat. Např. s uživateli diskutujeme zhruba o těchto oblastech: uživatelské účty a role, práce s PC, práce s aplikací, způsob práce s primárními aktivy nejen v rámci aplikace, ale např. i s tisky, uživatelská podpora, zabezpečení přístupu na pracoviště, výpadky systému a jejich řešení atd.

„Analytický“ FRAP workshop

Na úvod workshopu je nezbytné respondentům objasnit, co je analýza rizik, jaké jsou její cíle, jednotlivé kroky, jaké informace o nich potřebujeme získat a co bude po workshopu následovat. Důležité je vysvětlit, že analýza rizik není audit ani kontrola, a tedy v případě, že některé informace respondenti nemají, je „nevím“ správnou odpovědí. Vhodné je též upozornit, že se budeme ptát i na záležitosti, které známe nebo si alespoň myslíme, že víme, jak jsou řešeny. Podstatné totiž je, jak „to“ vidí a posuzuje zpovídaný respondent.

Workshop nesmí z pohledu respondentů vypadat jako „křížový“ výslech. Proto jej vždy vede jeden z členů analytického týmu, další se zapojují pouze v případě, že je potřeba informace z jejich úhlu pohledu doplnit nebo upřesnit.

Vlastní workshop sice vedeme podle předem připraveného seznamu oblastí, což ale neznamená, že na základě odpovědí nemůžeme diskusi rozšířit – připravený seznam je pomůckou, nikoli dogmatem. Otázky je nutné formulovat tak, aby bylo možné získat nejen jednoznačnou, ale hlavně úplnou odpověď. Musíme si také uvědomit, že většina respondentů se nezabývá bezpečností a riziky, a tedy je nutné odbornou terminologii přeložit do běžně srozumitelného jazyka. V případě nepochopení otázky ji formulovat jinak nebo vysvětlit, proč se na danou věc ptáme, resp. jaké informace potřebujeme získat a proč.

Pokud na některé otázky není respondent schopen okamžitě odpovědět, protože např. nemá všechny informace v hlavě, ale je schopen odpověď dodat později, nejedná se o problém a na pozdějším doplnění se domluvíme.

Odpovědi respondentů doporučujeme zaznamenávat přímo při workshopu. Snižuje se tak riziko jejich špatné interpretace. Toto riziko dále snižujeme tím, že zaznamenané odpovědi necháme respondenty následně (v klidu) autorizovat.

Autorizaci doporučujeme využít i pro doplnění informací, které se nepodařilo získat přímo při workshopu.

Příprava na „hodnotící“ FRAP workshop

Po absolvování „analytických“ workshopů se všemi identifikovanými skupinami respondentů popíše realizační tým veškerá aktiva a identifikuje potenciální rizika. Tento proces nebudeme podrobněji popisovat – předpokládáme, že identifikace rizik a jejich ohodnocení (prioritizace) je pro čtenáře DSM „běžným denním chlebem“. Nicméně si dovolíme několik doporučení.

1. Nepracujeme s jednotlivými aktivy, ale slučujeme je do skupin a dále pracujeme již „jen“ s těmito skupinami. Např. hardware, operační systém a vlastní aplikaci provozovanou na několika aplikačních serverech můžeme seskupit do jednoho podpůrného aktiva „Aplikační server“ za předpokladu, že se všemi aplikačními servery (resp. se všemi jejich vrstvami – HW, OS, aplikace) se v rámci systému pracuje stejně (administrace, patchování atd.). Tím dosáhneme větší přehlednosti celé analýzy a můžeme snížit celkový počet identifikovaných rizik bez dopadů na faktické výsledky analýzy, resp. na výsledný plán zvládání rizik.
2. Každé riziko musí být navázané na konkrétní primární aktivum. Nicméně tato vazba může být zjednodušena navázáním na podpůrné aktivum, které zajišťuje zpracování primárního aktiva. Jen je nutné mít tyto vazby zmapované.
3. Rizika můžeme podobně jako aktiva slučovat, a tím dosáhnout snížení jejich počtu bez dopadu do jejich hodnocení, (prioritizace) a plánu zvládání.

Ukažme si to na konkrétním příkladu. Analyzujeme webovou aplikaci a riziko napadení hackerem. Riziko můžeme namapovat na jednotlivá primární aktiva a následně na podpůrná aktiva – aplikační servery, jejich operační systém, webový server a vlastní aplikace, protože útok může být veden na zranitelnost kterékoli zmíněné komponenty. Hacker svým útokem může způsobit např. zhroucení webového serveru (nedostupnost aplikace pro uživatele), vykopírovat data (ztráta jejich důvěrnosti) nebo je pozměnit (ztráta integrity dat). Pokud budeme postupovat formálně, získáme tím mnoho jednotlivých rizik, a tedy výrazně navýšíme objem činností spojených s jejich evidencí a řízením. Na druhou stranu můžeme tato rizika i dotčená aktiva sloučit a následně pracovat pouze s jedním (sloučeným) rizikem „Útok hackera“ namapovaným na jedno (sloučené) aktivum „Aplikační server“.

Jednotlivá identifikovaná rizika, jejich ohodnocení a návrh opatření přirozeně popisujeme „jazykem kmene bezpečáků“. Nicméně pro potřeby „hodnotitelského“ FRAP workshopu vždy doplníme i popis srozumitelný respondentům, kteří se bezpečností primárně nezabývají.

Hodnotící FRAP workshop

Tento workshop v zásadě koresponduje s FRAP workshopem kolegy Seigeho. Jen s tím rozdílem, že je vše předpřipraveno. Neopominutelnými účastníky jsou:

• zástupce věcně příslušné organizační jednotky (správce primárních aktiv),
• uživatel, který ji „dělá rukama“,
• zástupci provozovatele(ů) – analytik, administrátor,
• zástupce pracovníků vývoje, jedná-li se o SW dodaný „na klíč“,
• případně zástupci podpůrných procesů (právníci, zaměstnanci interního HelpDesku atd.).

Tím končí vše, co je na analýze rizik z pohledu tohoto článku zajímavé, a následují víceméně rutinní nudné činnosti:

• plán zvládání rizik,
• příprava výstupní zprávy,
• schválení výstupní zprávy a „rozchod“.

Ještě doplníme dvě upozornění, která s uvedenou modifikací FRAPu nesouvisejí, ale považujeme je za zásadní:

• zadavateli musí být jasné, že se v rámci analýzy rizik nedozví nic, co by již nevěděl; pouze to bude mít utříděné,
• není nezbytně nutné jít v analýze „až na dřeň“, pokud víme, že se bude v následujících letech opakovat (aktualizovat); tomu pak lze přizpůsobit míru detailu zejména při úvodní analýze, kdy hrozí, že se hned v prvním kole „všichni společně utopí“ v detailech, množství rizik atd.

Na závěr si dovolíme krátké shrnutí. Tento článek společně s článkem kolegy Seigeho (kromě našich osobních zkušeností je to jediný formální zdroj) ukazuje, jak je možné zefektivnit proces analýzy a jak ho udělat flexibilnějším oproti klasickým metodikám. Je však nutné si dát pozor na několik klíčových předpokladů úspěchu:

• mít zdatného facilitátora s výbornými komunikačními a lektorskými schopnostmi, znalého problematiky informační bezpečnosti, resp. dané oblasti analýzy, schopného analyzovat vyjádření respondentů v reálném čase a vhodně na ně reagovat,
• mít kvalitní realizační tým, který svými znalostmi pokrývá analyzované oblasti a je facilitátorovi k ruce,
• být důsledný v přípravě a při workshopech při dodržení pravidla „všichni všem musejí rozumět“,
• sloučit aktiva a rizika do skupin tak, aby se zjednodušila jejich evidence a zároveň byly zachovány potřebné vazby,
• nejít zbytečně do hloubky v situaci, kdy již na povrchu toho najdeme dost,
• mít s organizací jasnou dohodu, co se od analýzy očekává – rozhodně se organizace o sobě nedozví nic nového.

A nyní již jen popřejeme „příjemné, ničím nerušené a nepřerušované frapování“.

Tato e-mailová adresa je chráněna před spamboty. Pro její zobrazení musíte mít povolen Javascript.Tato e-mailová adresa je chráněna před spamboty. Pro její zobrazení musíte mít povolen Javascript.