Bezpečnost je třeba řešit během celého životního cyklu vývoje software. To znamená, že je nutné začít již ve fázi analýzy, návrhu a pokračovat i při vlastním programování. Spoléhat se na penetrační test nebo audit zdrojového kódu v závěrečných fázích před nasazením do produkčního prostředí je nesmysl.

Microsoft používá pro hodnocení rizik při vývoji webových aplikací metodiku DREAD, do češtiny by se dal její název přeložit asi jako HRŮZA. Ponechávám však na posouzení laskavého čtenáře, nakolik ji tento název vystihuje. Ve své podstatě se jedná o analýzu rizik založenou na expertním odhadu pravděpodobnosti hrozby a velikosti potenciální škody.

Vlastní analýza probíhá v následujících krocích:

• Identifikace aktiv

cílem je identifikovat cenná aktiva (data), která je třeba chránit před narušením důvěrnosti, integrity a dostupnosti.

• Popis architektury

cílem je popsat, jak aplikace funguje a znázornit ve formě diagramu vztahy mezi jejími jednotlivými částmi.

• Dekompozice aplikace

cílem je popsat, jak je řešena autentizace, autorizace, session management, auditing atd.

• Identifikace hrozeb

k identifikaci hrozeb ve vztahu k aktivům slouží STRIDE model.

• Dokumentace hrozeb

popis hrozby, způsob zneužití této hrozby a vhodná opatření

• Ohodnocení hrozeb

cílem je provést ohodnocení hrozeb podle metodiky DREAD.

Jako aktiva v této metodice vystupuje samotná aplikace, aplikační, webový a databázový server a samozřejmě operační systém a síťová infrastruktura.

Co se týká hrozeb, Microsoft je rozděluje do šesti kategorií podle cíle útoku. Tento způsob dělení označuje jako STRIDE. Název je vytvořen z počátečních písmen jednotlivých cílů útoků, kterými jsou:

• Spoofing
• Tampering
• Repudiation
• Information disclosure
• Denial of service
• Elevetion of privilege

V článku Kategorizace hrozeb si múžete prečíst, co je to hrozba a jaké je základní dělení hrozeb. Pro stanovení pravděpodobnosti hrozby a potenciální škody nám Microsoft předkládá sadu následujících pěti otázek.

• Damage potential (potenciální škoda)

Jak velká by byla potenciální škoda, když by byla zranitelnost zneužita?

• Reproducibility (reprodukovatelnost)

Je možné útok provést kdykoliv nebo musí být splněny určité podmínky?

• Exploitability (zneužitelnost)

Jaké jsou požadavky na úroveň znalostí útočníka, aby mohl být útok proveden?

• Affected users (zasažení uživatelé)

Kolik procent uživatelů bude hrozbou zasaženo?

• Discoverability (odhalitelnost)

Jak snadné je v systému přítomnost zranitelnosti odhalit?

Všimněte si, že počáteční písmena anglických termínů opět tvoří název této metodiky. U každé hrozby bychom si měli položit výše uvedených pět otázek a odpovědět, zda se jedná o hrozbu nízkou (1), střední (2) nebo vysokou (3). Hodnotu jednotlivých odpovědí pak sečteme a získáme výslednou hodnotu, která vyjadřuje pravděpodobnost dané hrozby. Vzhledem k tomu, že se jedná o sadu 5 otázek a 3 možných odpovědí, může pravděpodobnost hrozby nabývat pouze hodnot z intervalu <5,15>. Hodnota 5 vyjde, pokud na všech 5 otázek odpovíme, že pravděpodobnost hrozby je nízká 5*1=5. Hodnota 15 vyjde, pokud na všech 5 otázek odpovíme, že pravděpodobnost hrozby je vysoká 5*3=15.

Ač tato metodika vysvětluje, jak stanovit pravděpodobnost hrozby, aniž by uvedla jak stanovit velikost potenciální škody, hovoří o nízkém <5,7>, středním <8,11> a vysokém <12,15> riziku. Microsoft uživatele této metodiky trochu mate, když píše, že otázky slouží ke stanovení pravděpodobnosti hrozby. Nicméně to není podstatné, když se totiž hlouběji zamyslíme nad zněním výše uvedených pěti otázek, zjistíme, že první a čtvrtá otázka v pořadí nemá s určením pravděpodobnosti hrozby vůbec nic společného, a že se naopak jedná o stanovení hodnoty dopadu. Tím se vysvětluje, proč je možné po sečtení hodnot jednotlivých odpovědí hovořit o riziku.

Dovoluji si tvrdit, že v okamžiku, kdy by rizika byla řízena v průběhu celého životního cyklu vývoje software a je jedno zda za použití této nebo jiné metodiky, výrazně by poklesl i počet útoků využívající známé triviální chyby, jakými jsou např. neošetřené vstupy umožňující útoky typu XSS, SQL injection apod.

Zdroj: MSDN