V minulém příspěvku jsem psal o risk appetite, dnes bych se rád krátce zmínil o risk tolerance.

Tyto pojmy se v oblasti řízení informačních rizik příliš nepoužívají a setkáme se s nimi spíše v akademické sféře a v publikacích nejrůznějších institucí. A pokud už někdo s těmito pojmy pracuje, tak je používá ve stejném kontextu, tj. špatně. Navíc zde můžeme narazit na dvě rozdílné interpretace těchto pojmů.

Pojďme se společně podívat, jak se provádí hodnocení zranitelností podle metodiky CVSS.

Aby se na zranitelnosti dalo snadno odkazovat, definuje CVE jak nové zranitelnosti přidělit jednoznačný identifikátor. Detailní popis a skóre, kterého jednotlivé zranitelnosti dosáhly, je pak uveden v National Vulnerability Database, zkr. NVD. Samotné skóre je pak počítáno podle metodiky pro hodnocení zranitelností, kterou spravuje First a je nazýváno CVSS, což je zkratka pro Common Vulnerability Scoring System.

Zatímco v minulých letech jsme byli svědky toho, že informační rizika byla velmi často bagatelizována a management většiny organizací měl snahu tato rizika akceptovat, dnes je situace přesně opačná.

Ano, tam kde se dříve management nad vysokými riziky pozastavoval a ptal se, zda jsou opravdu tak vysoká, hledí nyní se stejnou nedůvěrou na nízká rizika. Možná že je to dáno jen nešťastným způsobem prezentace některých kybernetických útoků v bulvárních mediích, a zvýšenou pozorností, která je těmto útokům věnována.

Risk appetite je klíčový faktor v procesu řízení rizik, neboť vyjadřuje úroveň rizika, kterou je organizace ochotna akceptovat.

V mezinárodním standardu ISO 31000, Risk management – Principles and guidelines, který určuje základní rámec pro řízení rizik, je risk appetite definován jako „Amount and type of risk that an organization is prepared to pursue, retain or take“.

Riziko je odvozeno z pravděpodobnosti hrozby, míry zranitelnosti a hodnoty dopadu.

Riziko můžeme definovat jako pravděpodobnost, že se vyskytne určitá hrozba, která překoná bezpečnostní opatření, zneužije nějaké zranitelnosti a způsobí škodu plynoucí z úniku citlivých informací, jejich nežádoucí změny nebo zničení. Hrozba je pak někdo/něco, kdo/co má potenciál způsobit nějakou škodu na aktivu a zranitelnost je vlastnost samotného aktiva.

Je způsob výpočtu rizika, tak jak je uveden v mezinárodních standardech, použitelný i v případech, kdy jedna hodnota nabývá svého minima a druhá naopak svého maxima?

Při analýze rizik zcela jistě narazíte jak na hrozby vyskytující se velice často, a mající na organizaci naprosto zanedbatelný dopad, tak i na hrozby, které se nevyskytují prakticky vůbec, ale přitom by jejich dopad na organizaci mohl být zdrcující. V rámci analýzy rizik vám však v obou těchto případech vyjde riziko spíše nízké nebo střední, a to bez ohledu na to, jaký použijete matematický aparát. Je to tak ale v pořádku?

Tento příspěvek doplňuje informace uvedené v knize „Řízení informačních rizik v praxi“ a upozorňuje na co si dát pozor při výpočtu zbytkového rizika.

V naší úvaze budeme vycházet z předpokladu, že riziko je dáno vztahem R=A*H*Z, kde R je riziko, A je hodnota dopadu, H je pravděpodobnost hrozby a Z je míra zranitelnosti. Dále budeme předpokládat, že zbytkové riziko po implementaci opatření lze vyjádřit jako RR=R/O, přičemž RR je zbytkové riziko a O je opatření, které dané riziko R snižuje.

V tomto příspěvku se zamyslíme nad otázkami, které by nám měly pomoci určit závažnost zranitelnosti.

Podobné otázky pro hodnocení zranitelností používá např. Common Vulnerability Scoring System (CVSS) nebo i taková společnosti jako je Microsoft.

Zranitelnost (vulnerability) je v oblasti informační bezpečnosti definována jako slabina systému, aplikace nebo služby, která může být zneužita hrozbou.

Při stanovení závažnosti zranitelnosti hodnotíme, zda dané zranitelnosti může být v konečném důsledku zneužito k narušení důvěrnosti, integrity nebo dostupnosti. Jinými slovy zda nemůže dojít k získání informací, k jejich změně, zničení nebo způsobení nedostupnosti systému.

Zavedení určitého opatření byste měli dokumentovat proto, abyste byli schopni i po letech jeho smysluplnost obhájit a vysvětlit, proč není vhodné dané opatření kvůli snižování nákladů rušit, a že se v případě administrativních opatření dokonce nejedná ani o nějakou zbytečnou byrokracii, jak se mnozí mylně domnívají.

Vždy je nutné si uvědomit, že máme bezpečnostní opatření, která slouží k prevenci, k detekci a k reakci na incident. Zatímco u posledních dvou opatření můžeme poměrně přesně vyčíslit, kolik pokusů o průnik do systému nebo narušení bezpečnosti jsme detekovali, tak u prvně zmíněného můžeme jen hádat.