Daniel Hejda
Spolumajitel, etický hacker a člen Red Teamu společnosti Cyber Rangers, s. r. o., jeden ze zakladatelů Cyber Intelligence Club. Jeho hlavní kompetencí je příprava simulovaných kybernetických útoků typu APT, zpravodajské činnosti ve vztahu ke kybernetické bezpečnosti a techniky sociálního inženýrství.
Michal Hanus
Specializuje se na kvantifikaci kybernetických rizik (CRQ/Open FAIR), řízení IT/OT bezpečnosti a ekonomiku bezpečnostních opatření. Pomáhá managementu rozhodovat tím, že převádí kybernetické hrozby, zranitelnosti a výsledky pentestů do finančních dopadů, priorit a investičních rozhodnutí. Je zakladatelem komunity QICS (Quant in Cyber Security) a je autorem prvního českého a slovenského vzdělávacího programu zaměřeného na CRQ, který propojuje bezpečnost, ekonomiku rizika a rozhodování na úrovni vedení firmy.
Kvantifikace kyber rizik a interpretace výsledků
Jak zjišťujete a verifikujete vstupní údaje do analýzy rizik?
Když vyjadřujeme riziko, musíme nejprve jasně říct, jakého časového horizontu se týká, typicky např. následujících 12 měsíců. Pravděpodobnost tzv. anualizujeme a škody nikdy nevyjadřujeme jedním číslem, ale vždy jako určité rozmezí reprezentující spektrum možných realizací daného scénáře. Základní podmínkou je správně vystavět a nadefinovat daný scénář, aby co nejvíc odpovídal očekávanému průběhu, tj. realistické cestě útoku (attack path) našeho typového útočníka. Nestačí tedy říct jen scénář „ransomware“. To je sice pojem, kterému management rozumí, ale pro modelování je potřeba jít hlouběji:
- Zaprvé určit základní mechaniku škodní události, tj. zda útok přichází přes koncovou stanici, uživatele, dodavatele, veřejně vystavenou službu nebo jiný vektor útoku a odhadnout preferovanou taktiku útočníka pro prvotní průnik (např. dle „initial access“v MITRE ATT&CK). Ve scénáři musí být zachyceno, kdo, kde a jak útok iniciuje, co se stane dál a jaký může být konečný dopad (typické následky). Kvantitativní přístup přitom často navazuje na už existující scénáře pro kvalitativní hodnocení, pokud jsou dobře připravené a danou situaci nám rámují a ohraničují.
- Zadruhé odhadnout očekávanou frekvenci takové události, kde je potřeba pracovat s regionálními a sektorovými reporty a průběžně kombinovat výchozí šanci na útok (apriorní pravděpodobnost) s evidencemi a podněty z vlastního prostředí jako jsou výsledky penetračních testů, zpravodajství o kybernetických hrozbách (cyber threat intelligence – CTI), vnitropodniková situace s nedávnými incidenty a skoro nehodami a aktuálními událostmi či signály z provozu a nakonec i expertní odhady a predikce zásadních změn okolo nás. To vše jde vložit do bayesovské statistiky a matematicky vyhodnotit do výsledné (aposteriorní) pravděpodobnosti.
- Zatřetí nemít na vstupech jen jedno číslo, ale rozmezí a distribuci možných hodnot. Jinak řečeno: nejde o mechanické vyplnění předdefinované tabulky nebo mřížky, ale o disciplinovanou práci se scénářem, daty a nejistotou.
Jak zabezpečujete porovnatelnost rizik mezi sebou?
To je jedna z největších výhod kvantitativního přístupu. Jakmile jsou všechna rizika převedena do stejných monetárních jednotek, tedy na koruny, eura nebo dolary, stávají se mezi sebou přímo porovnatelnými. Neplatí to jen uvnitř kybernetického portfolia, ale i napříč organizací. Lze tak srovnávat kybernetická rizika s požárem, BOZP, fyzickou bezpečností nebo provozními poruchami. Velkou výhodou kvantifikace je také možnost rizika dekomponovat na dílčí scénáře a následně je zase korektně agregovat. U kvalitativních katalogů rizik to nefunguje, jakmile jedno významné „červené“ riziko účelově rozdrobíte na několik „oranžových“ dílčích situací, málokdo je dokáže znovu složit dohromady. Kvantitativní model ale umožňuje matematicky správný rozpad i zpětné nasčítání, takže vidíme stále stejnou celkovou rizikovou zátěž (expozici). Díky tomu lze vytvářet mapu rizik a diskutovat s vedením firmy o tom, kolik rizika je v jednotlivých částech IT, které oblasti nesou největší zátěž a kde má smysl investovat do zmírnění nebo přenosu rizika. Vedle jednotlivých scénářů je navíc důležité vnímat a vizualizovat i koncentraci rizika a typicky situaci, kdy je příliš mnoho závislostí soustředěno na jednoho dodavatele, jeden systém, jednu technologii nebo jedno místo v architektuře. Právě tam se škody mohou výrazně kumulovat a amplifikovat. To jsou mimochodem místa a momenty, kdy se z jedné izolované bezpečnostní slabiny stává skutečný problém pro celou firmu.
Pokud organizace tvrdí, že řídí bezpečnost přes rizika (aplikuje risk-based security), ale neumí oddělit frekvenci od dopadu a transparentně pracovat s nejistotou, řídí ještě míru rizika – nebo jen formální klasifikaci?
Podle mě už v takovém případě nejde o skutečné řízení rizika, ale jen o formální klasifikaci. Na lidskou intuici se při práci s pravděpodobností a dopadem nemůžeme spoléhat, náš úsudek je plný systematických chyb a silných zkreslení. Spoléhat se při hodnocení rizik na nezkalibrované experty a jejich pocity na subjektivních škálách vede jen k „iluzi měření a komunikace rizik“ a k čistému placebo efektu. Riziko nejde jen cítit, musíme ho vyčíslit. Bez formální dekompozice situace, bez negativní (obrácené) korelace frekvence a dopadu daných variant scénáře a bez práce s nejistotou člověk vyhodnocuje rizika chybně. Typickým příkladem je rozdíl mezi jednorázovou katastrofou a sérií obdobných menších událostí. Psychologicky na nás působí úplně jinak, v naší paměti nastane tzv. zkreslení dostupnosti a emocionálně silné katastrofy si vybavíme hned a v plném detailu a podvědomě přeceníme jejich pravděpodobnost, ale z pohledu anualizovaného rizika mohou být kumulativní dopady těch menších událostí ekvivalentní nebo dokonce řádově větší. Pokud tedy organizace netrefuje nebo ani nemodeluje pro celé spektrum obdobných situací jejich individuální frekvence a dopady a nepracuje s definovanou mírou nejistoty, nemůže tvrdit, že je skutečně risk-based. Riziko, které není takto vyhodnocené, podle mě nelze ani tolerovat ani akceptovat, protože o něm ve skutečnosti nevíme nic podstatného. Máme jen pocit, že jsme ho někam zařadili.
Kde v praxi vzniká větší metodická chyba: při modelování rizika, nebo až při interpretaci výsledků pro management?
Především máme těch chyb při valuaci rizik celou řadu a typově pramení z omezených či neúplných znalostí a informací, z náhodnosti a variability veličin (faktorů) na pozadí, ze systematického zkreslení a ze zjednodušení nebo omezení v našem modelu (včetně matematických metod). Ta modelová chyba vzniká vždy už při samotném modelování, protože každý model je zjednodušením reality. Důležité ale není dokonalým modelem dosáhnout nulové chyby, nýbrž zlepšit naše odhady a predikce oproti současným metodám. Za zásadní problém považuji zejména běžně používané matice rizik (heat-mapy). Ty vytvářejí iluzi měření a komunikace rizik, i když ve skutečnosti pracují s pofiderním modelem, který matematicky násobí pořadové hodnoty (pořadová čísla jednotlivých kategorií), pro které je operace násobení nepřístupná.
Když se v jedné matici smíchá hrozba se zranitelností (ve formě jakési kategorie, míry či indexu), vznikne z toho cosi jako náhrada pravděpodobnosti (také ve formě míry či indexu), ta se pak násobí s dopadem vyjádřeným opět pořadovým číslem kategorie či jiným indexem v navazující matici a výsledkem je pak risk-index zobrazovaný na barevné mřížce, který vypadá jednoduše, srozumitelně a barevně, ale ve skutečnosti o daném riziku nic konkrétního a podstatného neříká. Právě v tom spočívá iluze měření a komunikace. Risk index může působit důvěryhodně, ale pokud vznikl násobením pořadových hodnot a nikde v systému nemáme definovaný počátek (nulu), míru a měrnou jednotku, nejde o skutečné měření a o daném scénáři vyprávíme pohádku s drastickým manažerským koncem typu „když jsme něco doopravdy nezměřili, tak jsme to nikdy reálně neřídili“. Oproti tomu kvantitativní model má výhodu v tom, že jsou v něm vidět použité jednotky (peníze), parametry a koeficienty, chyba je explicitní a pod kontrolou, model lze v čase revidovat a s přibývajícími daty zpřesňovat. Takže ano, chyba vzniká už při modelování, ale zásadní rozdíl je v tom, zda ji umíme přiznat, řídit a postupně snižovat a managementu nepředkládáme jen barevnou iluzi měření, komunikace a pseudo- -rozhodování o daném problému. To druhé je sice pohodlné, ale prokazatelně metodicky i matematicky pochybné.
Jak poznáme, že kvantifikace skutečně pomáhá rozhodovat a že nejde jen o numericky vyjádřenou iluzi přesnosti?
Kvantifikace pomáhá tehdy, když slouží jako rozhodovací nástroj. Smyslem není spočítat riziko „na korunu přesně“, ale dát managementu použitelné podklady (odhady na základě modelu) pro návazná rozhodnutí. Prakticky má kvantifikace odpovědět na tři základní otázky:
- zda je riziko tak velké, že si na něj máme vytvářet interní rezervu,
- zda je tak velké, že se na něj máme připojistit a
- zda má vzhledem k jeho povaze a velikosti smysl investovat do opatření, která sníží pravděpodobnost nebo dopad.
Plně kvantitativní model uvažuje celé spektrum (distribuci) možných hodnot (vyjádřených monetárně), umožňuje pracovat jak se střední (očekávanou) hodnotou ztráty, tak ukázat extrémní průběhy daného scénáře typu VaR 90 nebo VaR 99 (tedy odhad, jak velká může být ztráta v horším scénáři, který nastane zhruba v 10 % případů, nebo ve velmi krajním scénáři, který nastane přibližně v 1 % případů) pro úvahy o rezervách, spoluúčasti a limitech pojištění, porovnat různé varianty ošetření rizika přes návratnost investice do bezpečnostního opatření. U každého zvoleného mitigantu by mělo být vidět, zda dává ekonomický smysl. Pokud opatření nemá přiměřený přínos (tj. snížení očekávaných ekonomických ztrát) vůči jeho (také odhadované) ceně, nemá být dobrovolně do prostředí vůbec zaváděno.
Kvantifikace tedy není iluzí přesnosti, pracujeme s odhady a vedeme racionální ekonomické debaty s managementem, CFO nebo treasury o tom, o jak velké peníze se hraje, jaké jsou realistické extrémy a které investice riziko skutečně snižují. Zároveň brání tomu, aby se „vyhodnotila všechna možná rizika“ a „nakoupilo úplně všechno“, místo abychom se soustředili na ty významné (materiální) situace a vybírala se pro ně opatření s reálnou přidanou (tj. obrannou) a architektonickou hodnotou. Dobrá kvantifikace není ozdobou prezentace, ale oporou rozhodování.
Pokud regulace používá jazyk risk-based přístupu, ale nevyžaduje přesnou práci se scénáři, dopady a nejistotou, nevytváří tím pobídku k neprofesionální práci s rizikem?
Ano, podle mě takové nastavení vytváří prostor pro neprofesionální a často i formální práci s rizikem. V komunitě se dlouhodobě snažíme, aby se práce s rizikem profesionalizovala a aby se té profesi vrátila důvěryhodnost. To, co dnes často vidíme v praxi, je bohužel práce s barevnými maticemi bez skutečného pochopení jejich chybovosti, nespolehlivosti a faktické nepoužitelnosti.
Na druhou stranu bych nezahazoval stávající katalogy rizik. Pro regulatorní a auditorský soulad dávají smysl jako evidenční vrstva a auditor obvykle potřebuje vidět, že organizace má scénář, několik nezávislých opatření a základní kontrolní mechanismy. Ale to ještě není totéž jako dobré rozhodování. Smyslem by mělo být hlavně pomoci manažerům, CISO a CIO rozhodovat o tom, které situace (staré i nové scénáře) řešit, kolik peněz do nich dát v poměru k celkové rizikové expozici a jak je postupně řešit, aby to architektonicky i ekonomicky dávalo největší smysl. Pokud tedy regulace zůstane jen u obecného jazyka „risk-based“ a nevyžaduje kvalitní pokročilou práci se scénáři, pravděpodobností, dopadem a nejistotou, pak fakticky toleruje formalismus místo skutečného řízení rizika. Katalog může být užitečný pro audit, ale bez solidního rozhodovacího rámce sám o sobě nepomůže managementu rozhodovat (a investovat) lépe. A právě v tom je dnes podle mě největší (a systémová) slabina celé oblasti, protože jsme s útočníky v ekonomické válce na poli moderních technologií a už několik dekád prohráváme ve všech ohledech.
Pentesty, TLPT a jejich kvalita jako vstup do řízení rizika
Pentesty bývají často vnímány jako potvrzení bezpečnosti. Čím ve skutečnosti jsou z pohledu řízení rizik a čím naopak nejsou?
Podle mě by měl pentest firmě nastavit zrcadlo z pohledu bezpečnostních zranitelností a ukázat, s jakou pravděpodobností může určitá slabina vést k reálnému dopadu. Primární dopady totiž nevznikají na IT systémech samotných, ale na byznysových procesech, kde se pak projeví reputační nebo finanční škoda. IT systémy a další podpůrná aktiva jsou důležitá hlavně proto, že přes ně jsme schopni lépe odhadnout pravděpodobnost, s jakou může ke škodě dojít. Zároveň je ale potřeba říct, čím pentest není. Není to pouhé skenování zranitelností a generování seznamu CVE. A není to ani cvičení nebo trénink bezpečnostního týmu. Pentest je kreativní, řízená činnost, která se hodně opírá o hledání chyb v konfiguraci a o schopnost testera objevit takové slabiny, které automatické skenery v plné míře neodhalí. Současně jde o test, o němž organizace ví, bývá vedený v režimu Grey Box nebo White Box a vyžaduje intenzivní spolupráci s interním týmem, mimo jiné proto, že se často testují produkční systémy a je potřeba minimalizovat riziko provozního dopadu.
Doplňuje Michal Hanus: V řadě případů nejde o klasickou zranitelnost s CVE, ale o tzv. konfigurační slabinu, tedy o něco, co je prostě špatně nastavené. Právě tyhle chyby bývají v praxi velmi důležité, protože šikovný pentester je umí najít a zneužít, i když v systému formálně žádná známá CVE (technologická) zranitelnost evidovaná není, a tudíž ji ani skener nedokáže často odhalit.
Není největším problémem pentestů to, že se jejich výstupy často interpretují mimo hranice toho, co test skutečně prokázal?
Ano, to je podle mě jeden z velkých problémů. Hodně záleží na tom, jak je postavený report, jakou používá metodiku a jestli reflektuje standardní hodnocení např. typu FIRST CVSS (Common Vulnerability Secure Score). Když tester hodnotí nálezy čistě subjektivně, může jejich závažnost snadno „přepálit“ a z drobnější věci udělat kritický problém. Proto považuji za správné, aby vedle subjektivního komentáře vždy existovalo i standardizované skóre, které je mezi reporty srovnatelné. Ještě větší problém ale vzniká tehdy, když se výsledek pentestu používá manažersky zkratkovitě. Firma řekne, že „prošla pentestem“, auditor si odškrtne splněno, ale už nikdo neřeší, jak byl test koncipovaný, jaký měl scope, kolik měl času a jaké útočné vektory skutečně pokryl. U infrastruktury navíc neexistuje jednotný rámec, který by řekl, že těchto 20 věcí se musí vždycky otestovat. U webových aplikací máme alespoň OWASP a související standardy, ale u interní infrastruktury je to mnohem volnější a výsledek je závislý na kreativitě, zkušenostech a přístupu konkrétního testera.
Ve chvíli, kdy je scope časově nebo finančně omezený, tester se logicky soustředí na to, co mu přinese největší efekt, tedy na cesty k plné kompromitaci, vzdálenému spuštění kódu, eskalaci oprávnění nebo laterálnímu pohybu. To je legitimní, ale zároveň to znamená, že pentest nikdy neprokáže „bezpečnost celku“. Prokáže jen to, co v daném čase a rozsahu skutečně pokrýval.
Doplňuje Michal Hanus: Pentest report by měl umět číst i risk manager. Měl by si hlídat falešně pozitivní nálezy, tedy situace, kdy report něco přehání, i falešně negativní nálezy, kdy naopak tester něco zásadního přehlédne (obojí se v praxi děje) a cílit na formálně definovanou přesnost, protože je to pro nás další nástroj měření a má přinášet důkazy podle stejných pravidel. Bez kritického čtení reportu může organizace dojít k úplně mylnému závěru o své bezpečnostní úrovni.
Jak velké riziko je, když organizace bere výsledek pentestu bez širšího kontextu hrozeb, kritických aktiv a reálných dopadů?
To riziko je velké, protože bez kontextu se nedá správně prioritizovat. Když organizace nemá jasně definovanou metodiku, jak pracovat se zranitelnostmi, končí to často tak, že se soustředí na množství nálezů místo na jejich skutečný dopad. Typickým příkladem je situace, kdy nějaký nástroj nasbírá tisíce zranitelností a firma pak reportuje, kolik jich „opravila“. Jenže bez znalosti expozice, kritičnosti systému a vazby na klíčové byznysové procesy je to zavádějící metrika. Zranitelnost na kritické, externě exponované aplikaci má úplně jinou prioritu než stejná zranitelnost na interním systému, který není zvenku dosažitelný. Proto je zásadní mít metodiku, která řekne, co je opravdu kritické, kde musí být reakce okamžitá a kde je prostor řešit problém v delším horizontu. Jinak se snadno stane, že organizace začne řešit všechno stejně, zahltí se, a nakonec nebude efektivně řešit nic. Pentest sám o sobě tedy nestačí a musí být zasazený do širšího systému správy zranitelností a do rámce, který zohledňuje hrozby, kritická aktiva a obchodní dopady.
Doplňuje Michal Hanus: Risk manager by měl při čtení reportu rozlišovat, co je skutečně exponované a dosažitelné pro útočníka a co je sice technicky nalezené, ale v praxi těžko zneužitelné. Pokud tohle nerozliší, může uměle nafouknout pravděpodobnost průniku (uvést false positive) nebo naopak podcenit skutečně nebezpečnou cestu útoku (jako false negative).
TLPT je dnes hodně diskutované v souvislosti s DORA. V čem se threat-led penetration testing liší od běžného pentestu natolik, že má jinou hodnotu pro řízení reálného rizika?
Běžný pentest je většinou vedený podle určité metodiky a směřuje k ověření konkrétního systému nebo aplikace. Typicky se dostane maximálně na úroveň kompromitace daného systému, ale dál už obvykle nejde. TLPT je naopak postavené tak, aby co nejvěrněji simulovalo reálného útočníka. Všechny ochrany zůstávají zapnuté, zapojený je bezpečnostní tým, do testu vstupují detekční a reakční mechanismy a cílem je nejen najít zranitelnost, ale ověřit celý útočný vektor a kill chain v praxi.
Rozdíl je i v technice provedení. U běžného pentestu si můžete např. dočasně vypnout některá ochranná opatření, abyste otestovali samotnou aplikaci. U TLPT se nic nevypíná, protože jde právě o to zjistit, jak si obrana poradí v dané situaci. Testuje se tichý pohyb útočníka prostředím, obcházení bezpečnostních technologií, reakce interního týmu a schopnost zabránit dosažení cíle. Typickým cílem může být Active Directory, zálohovací infrastruktura, ERP systém nebo jiný systém, který představuje skutečné „crown jewels“ organizace. TLPT je navíc komplexnější i v tom, že by nemělo řešit jen digitální vrstvu. Mělo by spojovat technický, lidský i fyzický aspekt. Právě proto bývá výrazně delší a náročnější než běžný pentest. U podobných cvičení se běžně počítá s horizontem kolem půl roku. To už z něj dělá nástroj, který má pro řízení reálného rizika vyšší hodnotu, protože neověřuje jen technickou zranitelnost, ale i celkovou odolnost organizace a její schopnost reagovat.
Jak by měl vypadat výstup z pentestu nebo TLPT, aby byl opravdu použitelný nejen pro technický tým, ale i pro risk management a vedení firmy?
U pentestu by měl výstup vycházet z doporučených rámců a best practices. Měl by obsahovat manažerské shrnutí, popis metodiky testování, způsob hodnocení nálezů, detailní výsledky a doporučení k mitigaci. Nestačí jen seznam zranitelností, je důležité, aby z reportu bylo zřejmé, co bylo testováno, v jakém rozsahu, s jakým cílem a jaká je skutečná závažnost nálezů. U TLPT musí být výstup ještě širší. Nejde jen o technické nálezy, ale i o to, jak reagoval bezpečnostní tým, kdo co eskaloval, jak fungovaly detekce, jaké byly reakční časy a jak se útok vyvíjel v čase. Součástí mohou být i důkazní materiály, záznamy průběhu testu a jasné popsání toho, zda a jak bylo dosaženo stanoveného cíle.
Pro risk management má výstup smysl tehdy, když je navázaný na threat modeling. To znamená, že umí ukázat vazby mezi podpůrnými aktivy, jejich propojení na klíčové byznysové procesy a místo, kde v celém řetězci vzniká zranitelnost. Teprve pak lze říct, kde má být bariéra, jaká opatření je potřeba doplnit a jak se tím snižuje pravděpodobnost dosažení nejcennějších cílů organizace. Pro vedení firmy je důležité ještě něco navíc a to, že se musí rozumět i rizikům samotného testu. U TLPT je riziko provozního selhání vyšší než u běžného pentestu, protože se aktivně exploitují systémy a test se více blíží reálnému útoku. Management tedy musí vědět, jaké cíle byly stanoveny, jaké dopady může test mít a proč takový zásah dává smysl ve vztahu k rizikům, která by způsobil skutečný útočník. Výstupem pro vedení firmy proto nemá být jen technický report, ale i srozumitelný podklad pro rozhodnutí o prioritách a dalších krocích.
Doplňuje Michal Hanus: Jakékoli zadání, ať už jde o pentest, skenování zranitelností nebo TLPT, je potřeba plánovat mnohem pečlivěji, než bývá běžné. Nestačí říct „udělejte nám red team“ nebo „udělejte nám pentest“. Nejdřív je nutné správně komunikovat cíle, rozsah i rizika testu a teprve potom testovat. Stejně tak by výsledky neměly končit jednou ročně v šuplíku, ale měly by se průběžně promítat do registru rizik (jako nově naměřená rizika) a ideálně s nimi pracovat kontinuálně.
Děkuji za rozhovor.
Za DSM se ptal Martin Haloda.
