Webové aplikace s sebou přinášejí různě závažná rizika (dokončení)

4. krok: Stanovení závažnosti rizika

A teď si všechna ta čísla dáme dohromady. Konečně se dopracujeme k tomu, zda je celková závažnost rizika nízká, střední, vysoká anebo kritická.

Získané odhady pravděpodobnosti:

Útočník: 6 b.

Zranitelnost: 5,75 b.

Pravděpodobnost – průměr: (23 + 24) / (4 + 4) = 47 / 8 = 5,875 b.

Získané odhady dopadů:

Technické dopady: 6,5 b.

Business dopady: 6,5 b

Dopad – průměr: (26 + 26) / (4 + 4) = 52 / 8 = 6,5 b.

Nyní nám stačí převést čísla do slov, říci si, jaké bodové rozmezí je malé, střední a značné:

Příklad: V našem příkladu jsme si obodovali pravděpodobnost na 5,875 bodu, čímž se vlezeme na „střední pravděpodobnost“.

Příklad: V našem příkladu jsme si obodovali dopad na 6 bodu, čímž se vlezeme na „značný dopad“.

A jaká je celková závažnost rizika? Vzpomeňme si na formuli:

RIZIKO = PRAVDĚPODOBNOST X DOPAD

Převeďme ji do tabulky:

Příklad: V našem příkladu jsme zjistili „střední pravděpodobnost“ a „značný dopad“. Celková závažnost tedy je „vysoká“.

Rozhodnete-li se zavést si podobnou metodiku ve vaší společnosti, doporučuji držet se několika bodů:

Systém hodnocení rizik má:

• čas šetřit, ne jej ztrácet

• eliminovat případné diskuse o prioritách

• umožňovat soustředit se na vážnější rizika a bránit rozptylování se riziky méně závažnými

Zvažte sami, zda je pro vás lepší využívat jen velmi hrubý odhad daný tabulkou „Celková závažnost rizika“ anebo jestli chcete použít detailní rozbor jednotlivých nálezů. Mně osobně se osvědčilo používání právě tabulky „Celková závažnost rizika“, kterou si člověk snadno zapamatuje a v mžiku je schopen alespoň „od pasu zamířit“. Podrobnější rozbor mi slouží jako prevence před různými spekulacemi a také jako něco, co se dá přizpůsobovat potřebám toho či onoho projektu – lze si vymyslet různé faktory jak pro pravděpodobnost, tak pro dopady; záleží však na charakteru použití obdobné metodiky. Pro firmu je pochopitelně středobodem pro takovou metodiku podnikatelské riziko.

A co dál?

Objevili jsme spoustu rizik, dokázali jsme v jednotlivých případech určit jejich závažnost. Ale co dál?

1. Na řadě je jejich oprava. Platí pravidlo, že bychom nejdříve měli zacelit ty nejzávažnější díry a poté postupovat k těm méně závažným. Ne každá oprava však stojí za to. Představte si, že by vás oprava přišla na 500 000 Kč. Avšak celková závažnost rizika je nízká a dopadem by byla vyčíslená ztráta 10 000 Kč. V takovém případě bych se do opravy zřejmě nepouštěl.

2. Přizpůsobte si model hodnocení rizika podle svého hodnocení:

   1. Určete si své faktory, které nejlépe reprezentují daný projekt (anebo vaši společnost)

   2. Přizpůsobte možnosti jednotlivých faktorů (spektrum, skóre aj.);

   3. …

Jaká je praxe?

Přese všechna výše uvedená povídání je třeba si přiznat, že reálná praxe je diametrálně odlišná. V „garážovkách“, bez jasně vymezených procesů se úvahy o modelování hrozeb, hodnocení míry rizikovosti či budování testovacích scénářů tříští. Mnoho malých firem nedostatky nakupené zanedbanými počátečními fázemi vývoje webové aplikace dohání v mnohdy ztrátových servisních či záručních fázích. Dokonce i v případě, že je přistoupeno k penetračnímu otestování po vyhotovení aplikace, zjistí se, že náklady na opravu bezpečnostní chyby jsou příliš vysoké a z finančního hlediska neřešitelné anebo ztrátové. Známé tvrzení „Čím později nalezená chyba, tím dražší oprava.“ platí i pro bezpečnostní chyby – navíc k tomu připočtěme možné ztráty tím či oním dopadem; oproti mnohým „krabicovým“ systémům uvedené pro webové aplikace platí několikanásobně.

Za vůbec nejzávažnější riziko mnoha vývojářských společností považuji absenci zájmu o vývoj bezpečných aplikací. Méně závažné, ale nepochybně značně rizikové pro softwarovou společnost je pouhé otestování až po vyhotovení produktu – což může vést k nereálnosti o­prav.

Důležitým aktem při vývoji webových aplikací je zahrnout téma bezpečnosti vyvíjených aplikací do celého procesu vývoje ať to je proces jakýkoliv.

Je třeba podotknout, že obdobné metodiky v každé společnosti potřebují dozrát s nabývajícími zkušenostmi a know-how.

Někdy však plně postačí, když se vývojářský tým zaměří na některá nejzásadnější bezpečnostní rizika. Např. OWASP Top Ten, to však bruslíme již do tématu našeho příštího seriálového tématu.