Poročanje in ocena tveganja

CVSS ni tveganje. Tukaj je razlog. CVSS vam pove tehnično resnost ranljivosti v vakuumu. Ne pove vam, kaj to pomeni za vaše poslovanje. SQL injection na javni strani je drugačna od SQL injection na internem admin panelu. Kontekstualna ocena tveganja in jasno poročanje sta ključna za učinkovito odpravljanje ranljivosti.

Omejitve CVSS

Common Vulnerability Scoring System (CVSS) je industrijski standard za ocenjevanje ranljivosti, a ima pomembne omejitve, ki jih morate razumeti.

Kaj CVSS meri

CVSS ocena vključuje več metrik:

  • Attack Vector (AV) — Od kod je napad možen (omrežje, sosednji segment, lokalno, fizično).
  • Attack Complexity (AC) — Kako zahtevno je izkoristiti ranljivost.
  • Privileges Required (PR) — Ali napadalec potrebuje obstoječa pooblastila.
  • User Interaction (UI) — Ali je potrebna interakcija uporabnika.
  • Scope (S) — Ali napad vpliva na komponente izven ranljive komponente.
  • Confidentiality/Integrity/Availability (C/I/A) — Vpliv na zaupnost, celovitost in razpoložljivost.

Kaj CVSS NE meri

  • Poslovni kontekst — CVSS ne ve, da je ta strežnik vaš najpomembnejši produkcijski sistem.
  • Vrednost podatkov — Ne razlikuje med testnimi in produkcijskimi podatki.
  • Kompenzacijski kontrolniki — Ignorira WAF, segmentacijo, monitoring.
  • Dejanska izpostavljenost — Ranljivost na interni aplikaciji ima drugačno tveganje kot na javni.
  • Verjetnost napada — Ali je ta ranljivost aktivno izkoriščana v divjini?
  • Regulativni vpliv — Ne upošteva GDPR, PCI-DSS ali drugih zahtev.

Primer razlike

Dve ranljivosti s CVSS 9.8:

  • Ranljivost A — RCE na javnem spletnem strežniku, ki hrani podatke strank. Exploit je javno dostopen.
  • Ranljivost B — RCE na razvojnem strežniku v internem omrežju, dostopnem samo 5 razvijalcem.

Isti CVSS, povsem različno dejansko tveganje. Prioritizacija samo po CVSS bi bila napačna.

Moj pristop k oceni tveganja

Vsako ranljivost ocenjujem v kontekstu vašega specifičnega okolja. To vključuje:

1. Poslovni vpliv

Kaj napadalec dejansko lahko stori? Kakšna je škoda?

  • Finančna škoda — Neposredna izguba (kraja, izsiljevanje), posredna izguba (izpad, sanacije).
  • Reputacijska škoda — Izguba zaupanja strank, negativna medijska pozornost.
  • Regulativne posledice — Kazni GDPR (do 4% globalnega prometa), PCI-DSS, NIS2.
  • Operativne posledice — Izpad poslovanja, čas za obnovitev.
  • Strateški vpliv — Izguba konkurenčne prednosti, uhajanje intelektualne lastnine.

2. Verjetnost izkoristka

Ali je to trivialno ali zahteva visoko usposobljenega napadalca?

  • Tehnična zahtevnost — Je exploit point-and-click ali zahteva raziskovanje?
  • Dostopnost exploit-a — Je javno dostopen? V Metasploit-u? 0-day?
  • Avtomatizacija — Obstajajo orodja za množično skeniranje te ranljivosti?
  • Aktivna izraba — Je ranljivost trenutno izkoriščana v divjini?
  • Motivacija napadalcev — Je vaša organizacija zanimiva tarča za specifične grožnje?

3. Izpostavljenost

Kdo ima dostop? Kakšni kontrolniki obstajajo?

  • Dostopnost — Javno dostopno, za prijavljene uporabnike, samo interno, VPN.
  • Obstoječi kontrolniki — WAF, IDS/IPS, segmentacija, monitoring.
  • Avtentikacija — Ali je potrebna? Kako močna?
  • Geografske omejitve — Geoblokiranje, IP whitelisting.

4. Verige napadov

Ali ta ranljivost omogoča druge napade?

  • Vstopna točka — Je to prva stopnica za nadaljnje napade?
  • Privilege escalation — Omogoča dvig privilegijev?
  • Lateral movement — Omogoča premik v druge sisteme?
  • Persistence — Omogoča trajni dostop?

Struktura mojih poročil

Ustvarjam dve verziji vsakega poročila: tehnično za IT ekipo in izvršni povzetek za vodstvo.

Izvršni povzetek

Za vodstvo, ki potrebuje hiter pregled brez tehničnih podrobnosti:

  • Obseg testiranja — Kaj smo testirali in kaj ne.
  • Ključne ugotovitve — Najpomembnejše ranljivosti v poslovnem jeziku.
  • Ocena tveganja — Celostna ocena varnostne drže organizacije.
  • Primerjava — Kje ste glede na industrijo.
  • Prioritete — Kaj najprej, razvrščeno po poslovnem tveganju.
  • Priporočeni naslednji koraki — Konkretne akcije.

Tehnično poročilo

Za IT ekipo, ki bo ranljivosti odpravljala:

  • Metodologija — Kako smo testirali, katera orodja smo uporabili.
  • Podrobne ugotovitve — Vsaka ranljivost posebej.
  • Reprodukcija — Korak-po-korak navodila za reprodukcijo.
  • Dokazi — Posnetki zaslona, HTTP zahteve/odgovori, log izvlečki.
  • Navodila za odpravo — Konkretni koraki za popravek.
  • Reference — OWASP, CWE, CVE, proizvajalčeva dokumentacija.

Struktura posamezne ugotovitve

  1. Naslov — Kratek, opisujoč opis ranljivosti.
  2. Resnost — Kritična/Visoka/Srednja/Nizka + moja kontekstualna ocena.
  3. CVSS — Standardna ocena za primerjavo.
  4. Prizadeta sredstva — Kateri sistemi/komponente so ranljivi.
  5. Opis — Kaj je ranljivost in zakaj je problem.
  6. Poslovni vpliv — Kaj napadalec lahko stori v vašem kontekstu.
  7. Reprodukcija — Korak-po-korak navodila.
  8. Dokaz koncepta — Minimalen exploit, ki dokazuje ranljivost.
  9. Odprava — Kako popraviti, s primeri kode kjer je primerno.
  10. Reference — Dodatni viri za razumevanje.

Prioritizacija odpravljanja

Ne vse ranljivosti zahtevajo takojšnje ukrepanje. Moj pristop k prioritizaciji:

Kritična prioriteta (takoj)

  • Aktivno izkoriščane ranljivosti
  • Ranljivosti z javnim exploit-om na javno dostopnih sistemih
  • Direkten dostop do občutljivih podatkov brez avtentikacije
  • Remote Code Execution na kritičnih sistemih

Visoka prioriteta (teden)

  • Ranljivosti, ki omogočajo verigo do kritičnih sistemov
  • Privilege escalation v produkcijskem okolju
  • Ranljivosti na sistemih z občutljivimi podatki

Srednja prioriteta (mesec)

  • Ranljivosti na internih sistemih z omejitvami dostopa
  • Informacijsko razkritje brez neposrednega napadalnega vektorja
  • Ranljivosti, ki zahtevajo kompleksen exploit

Nizka prioriteta (četrtletje)

  • Best practice priporočila
  • Ranljivosti z minimalnim vplivom
  • Ranljivosti na nekritičnih testnih sistemih

Merjenje napredka

Varnost ni enkratni projekt, temveč kontinuiran proces. Spremljam:

  • MTTD (Mean Time to Detect) — Kako hitro odkrijete ranljivosti.
  • MTTR (Mean Time to Remediate) — Kako hitro jih odpravite.
  • Trend ranljivosti — Ali se število zmanjšuje čez čas?
  • Ponavljajoče se ranljivosti — Ali se iste napake pojavljajo znova?
  • Pokritost — Kolikšen del infrastrukture je redno testiran?

Komunikacija z vodstvom

Tehnična poročila redko dosežejo vodstvo v učinkoviti obliki. Moja priporočila za komunikacijo:

  • Govorite jezik poslovanja — Finančno tveganje, ne tehnični žargon.
  • Uporabljajte scenarije — "Če napadalec izrabi to ranljivost, lahko..." ne "Buffer overflow omogoča RCE."
  • Primerjajte z industrijo — "Vaši konkurenti imajo povprečno X dni za odpravo takšnih ranljivosti."
  • Pokažite ROI varnosti — Strošek napada vs. strošek zaščite.
  • Predlagajte konkretne korake — Ne le probleme, tudi rešitve.

Moja poročila niso le seznam ranljivosti — so načrt za izboljšanje vaše varnostne drže, prilagojen vašemu poslu in vašim tveganjem.