Hodnocení zranitelností – 4. díl

V červnu 2015 byla uvolněna nová verze metodiky pro hodnocení zranitelností CVSS v3.0. Ta oproti předchozí verzi přináší několik změn, které mají podstatný dopad na hodnocení zranitelností.

Pojďme se společně podívat, jaké změny to jsou, a jak ovlivňují výsledek hodnocení.

Attack vector

Access vector byl přejmenován na Attack vector avšak nadále platí, že s čím větší vzdálenosti je možné vést útok, tím vyšší je skóre. Nově se rozlišuje, zda je možné útok realizovat jen díky možnosti se přihlásit lokálně do daného systému (Local), anebo zda je nutné mít i fyzický přístup k danému zařízení (Physical).

Attack complexity

Access komplexity byl rozdělen na Attack complexity a User Interaction. Attack complexity může nabývat jen dvou hodnot a to Low (L), kdy k realizaci útoku nemusí být splněny žádné podmínky nebo High (H), kdy naopak musí být splněny určité podmínky.

User Interaction

User Interaction bylo vyčleněno z  Access complexity a může rovněž nabývat dvou hodnot, a to None (N), kdy žádná interakce ze strany oběti není k realizaci útoku nutná anebo Required (R), kdy jak již sama hodnota napovídá, je nějak interakce ze strany oběti vyžadována.

Privileges Required

Zde v zásadě došlo k přejmenování Authentication a k posunu významu tohoto kritéria hodnocení, které může nabývat třech hodnot. None (N), kdy útočník nemusí disponovat žádným účtem v systému, Low (L), kdy má útočník v systému nějaký účet s omezenými právy a High (H), kdy má v systému účet se silnými právy.

Scope

Zcela nový kritériem je tzv. Scope, který bere v úvahu tu skutečnost, že byť se zranitelnost může nacházet v jedné komponentě, tak úspěšný útok může mít dopad na zcela jinou komponentu. Scope tak může nabývat dvou hodnot: Unchanged (U), zranitelnost i dopad se týká stejné komponenty a Changed (C), kdy zneužití zranitelnosti má dopad na jinou komponentu.

SCOPE ovlivňuje Exploitability Subscore i Impact Subscore, byť se to v hodnocení těchto subscore v některých případech vůbec neprojeví. Pozor, někdy ne vždy musí být změna SCOPE jasná. Ke změně SCOPE dochází např. při úniku ze sandboxu, virtuálu, ale i při obyčejném XSS, kdy chyba v neošetřeném vstupu vede k narušení bezpečnosti na straně klienta.

Impact metrics

Zde se v zásadě nic nezměnilo, tedy kromě toho, že u Confidentiality, Integrity a Availability impact metrik byl pojem Partial (P) nahrazen pojmem Low (L) a Complete (C) nahrazen High (H). Osobně mi přišly pojmy Partial a Full výstižnější, ale budiž.

Temporal matrix

V zásadě došlo jen k přejmenování Exploitability na Exploit Code Maturity. Metriky Remediation Level a Report Confidence zůstávají beze změny.

Environmental matrix

Metriky Target Distribution a Collateral Damage Potential byly nahrazeny tzv. Modified factors, které umožňují hodnotiteli promítnout do hodnocení tu skutečnost, že může mít ve svém systému již implementována opatření, která mohou snižovat dopad.

Vyhodnocení zranitelností

Výsledkem hodnocení zranitelnosti je číslo z intervalu <0,10>, kdy 0 (žádná), 0,1 – 3,9 (nízká), 4,0 – 6,9 (střední), 7,0 – 8,9 (vysoká) a 9,0 – 10,0 (kritická). Vždy si ověřte, jaká verze metodiky byla pro hodnocení zranitelností použita, protože mnohdy vychází při hodnocení stejné zranitelnosti naprosto rozdílné hodnoty.

Závěr: Celkově lze změny, které přinesla ve své 3. verzi metodika CVSS, hodnotit jako pozitivní. Rozhodování, jakou hodnotu u jednotlivých metrik zvolit, je přímočařejší.

Stále přetrvává problém, jak hodnotit zranitelnosti, které lze označit jako information disclosure, umožňující odhalit třeba verzi software nebo strukturu databáze. Běžně bychom ji asi označili jako nízkou, nicméně v CVSS nelze hodnotit jinak než takto a výsledkem je pak střední zranitelnost.

uživatelské příručce v kapitole 5 dále najdete jednoduché a naprosto srozumitelné vysvětlení toho, jak jednotlivé metriky ovlivňují celkové skóre a osobně tuto část považuji za nejpřínosnější. Stejně tak vaši pozornosti doporučuji kapitolu 3, kde jsou vysvětleny nejčastější chyby, kterých se analytici při hodnocení zranitelností dopouští.

Např. když zranitelnost vede k získání hesla administrátora, měla by být hodnocena takto, byť získáním hesla admina dojde v prvopočátku jen k narušení důvěrnosti, nikoliv integrity a dostupnosti, ale je nutné předpokládat, že administrátorský přístup může být později zneužit k provedení jakékoliv akce.

Pokud vás tento článek zaujal, můžete odkaz na něj sdílet.

Štítky:


K článku “Hodnocení zranitelností – 4. díl” se zde nenachází žádný komentář - buďte první.

Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.

Přihlášeným uživatelům se tento formulář nezobrazuje - zaregistrujte se.

Jméno:(požadováno)
E-mail:(požadováno - nebude zobrazen)
Web:

Text vaší reakce: