Dread – analýza rizík podľa Microsoftu

Bez­peč­nosť tre­ba rie­šiť po­čas ce­lé­ho ži­vot­né­ho cyk­lu vý­vo­ja sof­tvé­ru. To zna­me­ná, že je pot­reb­né za­čať už vo fá­ze ana­lý­zy, návr­hu a pok­ra­čo­vať aj pri vlas­tnom prog­ra­mo­va­ní. Spo­lie­hať sa na pe­net­rač­ný test ale­bo audit zdro­jo­vé­ho kó­du v zá­ve­reč­ných fá­zach pred na­sa­de­ním do pro­duk­čné­ho pros­tre­dia je nez­my­sel.

Mic­ro­soft pou­ží­va na hod­no­te­nie ri­zík pri vý­vo­ji webo­vých ap­li­ká­cií me­to­di­ku DREAD, do slo­ven­či­ny by sa jej ná­zov dal pre­lo­žiť asi ako HRÔZA. Po­ne­chá­va­me však na po­sú­de­nie lás­ka­vé­ho či­ta­te­ľa, na­koľ­ko ju ten­to ná­zov vy­sti­hu­je. V pod­sta­te ide o ana­lý­zu ri­zík, za­lo­že­nú na exper­tnom od­ha­de prav­de­po­dob­nos­ti hroz­by a veľ­kos­ti po­ten­ciál­nej ško­dy.

Vlas­tná ana­lý­za pre­bie­ha v nas­le­du­jú­cich kro­koch:
* Iden­ti­fi­ká­cia ak­tív- cie­ľom je iden­ti­fi­ko­vať hod­not­né ak­tí­va (dá­ta), kto­ré tre­ba chrá­niť pred na­ru­še­ním dô­ver­nos­ti, in­teg­ri­ty a dos­tup­nos­ti.
* Opis ar­chi­tek­tú­ry - cie­ľom je opí­sať, ako ap­li­ká­cia fun­gu­je, a zná­zor­niť vo for­me di­ag­ra­mu vzťa­hy me­dzi jej jed­not­li­vý­mi čas­ťa­mi.
* De­kom­po­zí­cia ap­li­ká­cie - cie­ľom je opí­sať, ako je rie­še­ná auten­ti­fi­ká­cia, auto­ri­zá­cie, ses­sion ma­na­ge­ment, audi­ting atď.
* Iden­ti­fi­ká­cia hro­zieb - na iden­ti­fi­ká­ciu hro­zieb vo vzťa­hu k ak­tí­vam slú­ži mo­del STRI­DE.
* Do­ku­men­tá­cia hro­zieb - opis hroz­by, spô­sob jej zneu­ži­tia a vhod­né opat­re­nia
* Ohod­no­te­nie hro­zieb - cie­ľom je vy­ko­nať hod­no­te­nie hro­zieb pod­ľa me­to­di­ky DREAD.

Ako ak­tí­va v tej­to me­to­di­ke vy­stu­pu­jú sa­mot­ná ap­li­ká­cia, ap­li­kač­ný, webo­vý a da­ta­bá­zo­vý server a, sa­moz­rej­me, ope­rač­ný sys­tém a sie­ťo­vá infra­štruk­tú­ra.
Čo sa tý­ka hro­zieb, Mic­ro­soft ich roz­de­ľu­je do šies­tich ka­te­gó­rií pod­ľa cie­ľa úto­ku. Ten­to spô­sob de­le­nia ozna­ču­je ako STRI­DE. Ná­zov je vy­tvo­re­ný z po­čia­toč­ných pís­men jed­not­li­vých cie­ľov úto­ku, kto­rý­mi sú:

* Spoo­fing
* Tam­pe­ring
* Re­pu­dia­tion
* In­for­ma­tion dis­clo­su­re
* De­nial of servic­e
* Ele­ve­tion of pri­vi­le­ge

V člán­ku Ka­te­go­ri­zá­cia hro­zieb si mô­že­te pre­čí­tať, čo je to hroz­ba a aké je zá­klad­né de­le­nie hro­zieb. Na ur­če­nie prav­de­po­dob­nos­ti hroz­by a po­ten­ciál­nej ško­dy nám Mic­ro­soft pred­kla­dá sú­bor nas­le­du­jú­cich pia­tich otá­zok.

* Da­ma­ge po­ten­tial (po­ten­ciál­na ško­da) - Aká veľ­ká by bo­la po­ten­ciál­na ško­da, ke­by bo­la zra­ni­teľ­nosť zneu­ži­tá?
* Rep­ro­du­ci­bi­li­ty (rep­ro­du­ko­va­teľ­nosť) - Je mož­né útok vy­ko­nať ke­dy­koľ­vek ale­bo mu­sia byť spl­ne­né ur­či­té pod­mien­ky?
* Exploi­ta­bi­li­ty (zneu­ži­teľ­nosť) - Aké sú po­žia­dav­ky na úro­veň ve­do­mos­tí útoč­ní­ka, aby mo­hol byť útok vy­ko­na­ný?
* Af­fec­ted users (za­siah­nu­tí pou­ží­va­te­lia) - Koľ­ko per­cent pou­ží­va­te­ľov bu­de hroz­bou poz­na­če­ných?
* Dis­co­ve­ra­bi­li­ty (od­ha­li­teľ­nosť) - Ako ľah­ké je v sys­té­me od­ha­liť prí­tom­nosť zra­ni­teľ­nos­ti?

Všim­ni­te si, že po­čia­toč­né pís­me­ná an­glic­kých ter­mí­nov opäť tvo­ria ná­zov tej­to me­to­di­ky. Pri kaž­dej hroz­be by sme si ma­li po­lo­žiť uve­de­ných päť otá­zok a od­po­ve­dať, či ide o níz­ke (1), stred­né (2) ale­bo vy­so­ké (3) oh­ro­ze­nie. Hod­no­tu jed­not­li­vých od­po­ve­dí po­tom spo­čí­ta­me a zís­ka­me vý­sled­nú hod­no­tu, kto­rá vy­jad­ru­je prav­de­po­dob­nosť da­nej hroz­by.
Vzhľa­dom na to, že ide o sú­bor 5 otá­zok a 3 mož­ných od­po­ve­dí, mô­že prav­de­po­dob­nosť hroz­by na­do­bú­dať iba hod­no­ty z inter­va­lu <5,15>. Hod­no­ta 5 vy­jde, ak na všet­kých 5 otá­zok od­po­vie­me, že prav­de­po­dob­nosť oh­ro­ze­nia je níz­ka 5 * 1 = 5. Hod­no­ta 15 vy­jde, ak na všet­kých 5 otá­zok od­po­vie­me, že prav­de­po­dob­nosť oh­ro­ze­nia je vy­so­ká 5 * 3 = 15.

Ho­ci tá­to me­to­di­ka vy­svet­ľu­je, ako ur­čiť prav­de­po­dob­nosť hroz­by, bez to­ho, aby uvied­la, ako ur­čiť veľ­kosť po­ten­ciál­nej ško­dy, ho­vo­rí o níz­kom <5,7>, stred­nom <8,11> a vy­so­kom <12,15> ri­zi­ku. Mic­ro­soft pou­ží­va­te­ľa tej­to me­to­di­ky tro­chu ple­tie, keď pí­še, že otáz­ky slú­žia na sta­no­ve­nie prav­de­po­dob­nos­ti hroz­by. To však nie je pod­stat­né, keď sa to­tiž hlb­šie za­mys­lí­me nad zne­ním uve­de­ných pia­tich otá­zok, zis­tí­me, že pr­vá a štvr­tá otáz­ka v po­ra­dí ne­má s ur­če­ním prav­de­po­dob­nos­ti hroz­by vô­bec nič spo­loč­né, že ide, nao­pak, o sta­no­ve­nie hod­no­ty do­sa­hu. Tým sa vy­svet­ľu­je, pre­čo mož­no po spo­čí­ta­ní hod­nôt jed­not­li­vých od­po­ve­dí ho­vo­riť o ri­zi­ku.

Do­vo­ľu­jem si tvr­diť, že ke­by ri­zi­ká bo­li ria­de­né v prie­be­hu ce­lé­ho ži­vot­né­ho cyk­lu vý­vo­ja sof­tvé­ru, je jed­no, či za pou­ži­tia tej­to ale­bo inej me­to­di­ky, vý­raz­ne by sa zní­žil aj po­čet úto­kov vy­uží­va­jú­cich zná­me tri­viál­ne chy­by, ako sú nap­rík­lad neo­šet­re­né vstu­py umož­ňu­jú­ce úto­ky ty­pu XSS, SQL in­jec­tion a pod.

Zdroj: Synopsi blog

---