Alternativni threat modeli

Izvor: SIS Wiki

Skoči na: orijentacija, traži

Temu rezervirale: Tea Jurašić i Anamarija Macanga

Sadržaj

Modeliranje rizika prijetnji

Razvoj IT-temeljnog modeliranja prijetnji - s razvojem računalstva 1960.-ih godina prošlog stoljeća pojedinci su počeli tražiti načine kako iskoristiti ranjivost sustava u osobnu korist. Rezultiralo je time da su znanstvenici i inženjeri povezani s računalima počeli razvijati moguće koncepte modeliranja prijetnji za informacijske tehnologije. Prvi puta 1977.god Christopher Alexander je predstavio IT metodologiju modeliranja prijetnji koja se temeljila na konceptu arhitektonskih uzoraka. 1988. godine Robert Barnard razvija i primjenjuje prvi profil tzv. napadača IT sustava. Edward Amoroso 1994. godine objavljuje knjigu „Osnovne tehnike računalne sigurnosti“ gdje predstavlja koncept „stabla prijetnje“. „Stabla prijetnji“ grafički prikazuju kako se može iskoristiti potencijalna prijetnja informacijskom sustavu. Također, NSA i DARPA provode sličan rad, te Bruce Scheiner 1998.godine objavljuje rad u kojem objašnjava svoju analizu cyber rizika pomoću „stabla napada“. Taj rad bio je jedan od temeljnih doprinosa evoluciji modeliranja prijetnji za IT sustave. On je predstavio cilj napadača kao „korijenski čvor“ s potencijalnim sredstvima postizanja cilja predstavljenog kao „čvorovi listova“. Koristeći takvo stablo napada stručnjaci cybersecurity-a sustavno razmatraju više napadačkih vektora. 1999.godine Microsoftovi stručnjaci za kibernetsku sigurnost primijenili su analizu „stabla napada“ kako bi razvili metodičko sredstvo za razmatranje potencijalnih napada koji su relevantni za razvojno okruženje Microsoft Windows. Stvoren je model prijetnje STRIDE (o njemu će više riječi biti u nastavku teksta). Cilj je odrediti kako bi potencijalni napadač mogao iskoristiti bilo koju prijetnju kategoriziranu akronimom STRIDE na svakom čvoru jednog „stabla napada“. Već 2003.godine pojavljuje se OCTAVE metodologija modeliranja prijetnji temeljena na procjeni rizika odnosno na organizacijskom upravljanju rizicima. 2004. godine Frank Swiderski i Window Snyder napisali su „Modeliranje prijetnji“ u suradnji s Microsoft-om. U njemu su razvili koncept korištenja modela prijetnji radi stvaranja sigurnih aplikacija. 2014. godine Ryan Stilions izrazio je ideju da se cyber prijetnje trebaju izražavati s različitim semantičkim razinama, te predložiti model DML-a. Napad je instancija scenarija prijetnji koju uzrokuje određeni napadač s određenim ciljem. Cilj i strategija predstavljaju najviše semantičke razine DML modela. Slijedi TTP koji predstavljaju semantičke razine srednje vrijednosti. Najmanja semantička razina DML modela su alati koji koriste napadači, domaćini i promatrane mrežne artefakte, kao što su paketi i nosivi sadržaji. Na kraju su IP adrese na najnižoj semantičkoj razini. Trenutni SIEM alati obično daju indikatore na najnižoj semantičkoj razini. Stoga je potrebno razviti SIEM alate koji mogu pružiti pokazatelje prijetnji na višim semantičkim razinama.

Modeliranje prijetnji je pristup za analizu sigurnosti aplikacije. To je strukturirani pristup koji omogućuje prepoznavanje, kvantificiranje i rješavanje sigurnosnih rizika povezanih s aplikacijom. Njime se mogu identificirati potencijalne prijetnje, poput strukturalnih ranjivosti. Svrha cjelokupnog modela prijetnje je pružiti „braniteljima“ sustavnu analizu mogućeg napadača, njegov potencijalni profil i mogući vektor napada. Modeliranje prijetnji zapravo odgovara na nekoliko pitanja: „Gdje je imovina koja ima visoku vrijednost?“, „Gdje je poduzeće najosjetljivije za napad?“, „Koje su najrelevantnije prijetnje?“ i „Postoji li možda kakav vektor napada koji može proći nezapaženo?“. Modeliranje prijetnji nije pristup pregledavanju koda, ali nadopunjuje postupak pregleda sigurnosnog koda. Uključivanje modela prijetnji u SDLC može pomoći da se aplikacije razvijaju s ugrađenim sigurnosnim sustavom od samog početka. To, u kombinaciji s dokumentacijom koja je dobivena kao dio procesa modeliranja prijetnji, može ocjenjivaču dati veće razumijevanje sustava. To ocjenjivaču omogućava da vidi gdje su ulazne točke aplikacije te povezane prijetnje sa svakom ulaznom točkom. Koncept modeliranja prijetnji nije nov, ali posljednjih godina je došlo do jasne promjene načina razmišljanja. Moderno modeliranje prijetnji gleda na sustav iz perspektive potencijalnih napadača, za razliku od gledišta branitelja. Microsoft je bio snažan zagovornik procesa u posljednjih nekoliko godina. Oni su napravili prijetnju modeliranju jezgrene komponente svojih SDLC-a, za koje tvrde da su jedan od razloga povećane sigurnosti svojih proizvoda posljednjih godina. Kada se analiza izvornog koda obavlja izvan SDLC-a, kao što je na postojećim aplikacijama, rezultati modela prijetnji pomažu u smanjenju složenosti analize izvornog koda promicanjem u dubinu prvog pristupa nasuprot širini prvog pristupa. Umjesto pregledavanja cijelog izvornog koda s jednakim fokusom, možete odrediti prioritet pregleda sigurnosnih kodova komponenata čija je prijetnja modeliranja rangirana uz prijetnje visokim rizikom.

Postupak modeliranja prijetnji

Postupak modeliranja prijetnji može se podijeliti u 3 koraka visoke razine:

1. Korak: Razdijeliti aplikaciju. Prvi korak u procesu modeliranja prijetnji odnosi se na razumijevanja aplikacije i na interakciju s vanjskim entitetima. To uključuje stvaranje use-case-ova da bi razumjeli kako se aplikacija upotrebljava, prepoznajući ulazne točke da bi vidjeli gdje bi potencijalni napadač mogao stupiti u interakciju s aplikacijom, identificirajući sredstva, tj. područja za koja bi napadač mogao biti zainteresiran i identificirati razine povjerenja koje predstavljaju prava pristupa koju će aplikacija odobriti vanjskim subjektima. Ove se informacije dokumentiraju u dokumentu za model prijetnje, a koristi se i za izradu dijagrama toka podataka (DFD-ova) za aplikaciju. DFD-ovi prikazuju različite putove kroz sustav, ističući granice privilegija.

2. korak: Odrediti i rangirati prijetnje. Ključno je za identifikaciju prijetnji koristiti metodologiju kategorizacije prijetnji. Korištenje metodologije kategorizacije prijetnji kao što je STRIDE ili okvir za zaštitu aplikacija (ASF) koji definira kategorije prijetnji kao što su revizija i logiranje, autentifikacija, autorizacija, upravljanje konfiguracijom, zaštita podataka u pohrani i tranzitu, validacija podataka, upravljanje iznimkama. Cilj kategorizacije prijetnji je pomoći identificirati prijetnje i od napadača (STRIDE) i obrambene perspektive (ASF). DFD-ovi proizvedeni u 1. koraku pomažu pri identificiranju potencijalnih ciljeva prijetnji iz napadačke perspektive, kao što su izvori podataka, procesi, tokovi podataka i interakcije s korisnicima. Te prijetnje mogu se dodatno identificirati kao korijenje za stabla prijetnje; postoji jedno stablo za svaki cilj prijetnji. Iz obrambene perspektive, kategorizacija ASF pomaže prepoznati prijetnje kao slabosti sigurnosnih kontrola za takve prijetnje. Zajednički popisi prijetnji s primjerima mogu pomoći u prepoznavanju takvih prijetnji. Upotreba i zlouporaba slučajeva može ilustrirati kako se postojeće zaštitne mjere mogu zaobići ili gdje postoji nedostatak takve zaštite. Određivanje sigurnosnog rizika za svaku prijetnju može se utvrditi pomoću modela rizika temeljenog na vrijednosti kao što je DREAD ili manje subjektivni kvalitativni model rizika koji se temelji na općim čimbenicima rizika (npr. vjerojatnost i utjecaj).

3. korak: Odrediti protumjere i ublažavanje. Nedostatak zaštite od prijetnje može ukazivati na ranjivost čija se izloženost riziku može ublažiti provedbom protumjere. Takve protumjere mogu se identificirati pomoću popisa mapiranja prijetnji i protumjere. Jednom kad se prijetnja rangira za rizik, moguće je razvrstati prijetnje od najvišeg do najnižeg rizika i odrediti prioritet napora ublažavanja, kao što su reagiranje na takve prijetnje primjenom utvrđenih protumjera. Strategija za ublažavanje rizika može uključivati procjenu tih prijetnji od utjecaja poslovanja koji oni predstavljaju i smanjenja rizika. Ostale opcije mogu uključivati poduzimanje rizika, uz pretpostavku da je utjecaj poslovanja prihvatljiv zbog kompenzacijskih kontrola, informiranja korisnika o prijetnji, uklanjanja opasnosti od prijetnje u potpunosti ili najmanjom mogućom opcijom, to jest, da ništa ne učini. Svaki od navedenih koraka mora biti dokumentiran tijekom provođenja. Rezultat dokumenata je zapravo model prijetnje za aplikaciju.

Modeliranje rizika prijetnji korištenjem Microsoft Threat Modela

Proces modeliranja rizika ima pet stupnjeva:

  • Prepoznavanje sigurnosnih ciljeva 
  • Pregledavanje aplikacije
  • Razdjeljivanje aplikacije
  • Utvrđivanje prijetnji 
  • Prepoznavanje ranjivosti

1. Prepoznavanje sigurnosnih ciljeva (Identify Security Objectives) Potrebno je da vodstvo poduzeća bude u suradnji sa timovima za razvoj softvera i osiguravanje kvalitete te da svi razumiju sigurnosne ciljeve. Prvo se sigurnosni ciljevi aplikacije razbijaju u sljedeće kategorije:

  • Identitet: Da li program štiti identitet korisnika od zloupotrebe? Postoje li odgovarajuće 
    kontrole kako bi se osigurao dokaz identiteta? 
  • Financijska: Procijeniti razinu rizika koju je organizacija spremna apsorbirati u sanaciji, 
    kao potencijalni financijski gubitak. Na primjer, forumski softver može imati niži 
    procijenjeni financijski rizik od programa za internetsko bankarstvo. 
  • Reputacija: Kvantificirati ili procijeniti gubitak ugleda koji proizlazi iz uspješnog napada 
    i zloupotrebe aplikacije
  • Privatnost i regulacije: Koliko će aplikacija morati zaštititi korisničke podatke? Softver 
    za forum po svojoj prirodi je javan, ali aplikacija za pripremu poreza podložna je poreznim 
    propisima i zahtjevima zakonodavstva o zaštiti privatnosti u većini zemalja. 
  • Garancije o raspoloživosti: Da li je zahtjev morao biti dostupan prema ugovoru o razini 
    usluge (SLA) ili sličnim jamstvom? Je li to nacionalno zaštićena infrastruktura? Na koju će 
    razinu aplikacija biti dostupna?

2. Pregledavanje aplikacije (Survey the Application) Nakon definiranja sigurnosnih ciljeva, potrebno je analizirati dizajn aplikacije kako bi mogli utvrditi komponente, tokove podataka i granice povjerenja. Zbog toga je potrebno istražiti arhitekturu i projektnu dokumentaciju aplikacije, odnosno potražiti UML dijagrame komponenata. Takvi dijagrami komponenata visoke razine općenito su dovoljni za razumijevanje kako i zašto podaci teku na različita mjesta. Na primjer, potrebno je pažljivo analizirati kretanje podataka preko granice povjerenja (kao npr. s Interneta na mrežu ili iz poslovne logike na poslužitelj baze podataka), dok podaci koji teku unutar iste razine povjerenja ne trebaju veliku pažnju.

3. Razdjeljivanje aplikacije (Decompose it) Jednom kada se shvati aplikacijska arhitektura, potrebno je dalje razdijeliti aplikaciju radi identifikacije značajki i modula sa sigurnosnim učinkom koji treba procijeniti. Primjerice, prilikom ispitivanja modula za provjeru autentičnosti potrebno je razumjeti kako podaci ulaze u modul, kako modul potvrđuje i obrađuje podatke, gdje teče tok podataka, kako se pohranjuju podaci i koje temeljne odluke i pretpostavke donosi modul.

4. Utvrđivanje prijetnji (Identify Threats) Nemoguće je zapisivati nepoznate prijetnje, ali isto tako nije vjerojatno da će se stvoriti novi zlonamjerni softver za iskorištavanje novih ranjivosti unutar prilagođenih sustava. Stoga je potrebno usredotočiti se na poznate rizike, koji se lako mogu demonstrirati pomoću alata ili tehnika iz Bugtraq-a. Microsoft predlaže dva različita pristupa za pisanje prijetnji. Jedan je grafički prijetnji, a drugi je strukturirani popis. Onaj tko će napasti aplikaciju je izrazito motiviran da iskoristi prijetnje i propuste. Za lakše razumijevanje tko bi mogao napasti aplikaciju, prijetnje su podijeljene u različite kategorije:

  • slučajno otkrivanje – obični korisnik koji slučajno nailazi na funkcionalnu pogrešku u 
    aplikaciji, samo pomoću web preglednika i dobiva pristup privilegiranim informacijama ili 
    funkcijama
  • automatizirani malware-i – zlonamjerni softveri, programi ili skripte, koji traže poznate 
    ranjivosti, a zatim ih prijavljuju na središnju web stranicu zbirke
  • znatiželjni napadač – obični korisnik ili korisnik koji ima znanje o sigurnosti aplikacije i 
    cilj mu je istražiti potencijalne ranjivosti, kad primijeti nešto pogrešno u aplikaciji 
    odlučuje nastaviti dalje
  • script kiddies – osoba koja koristi postojeće skripte ili kod računala za hakiranje 
    računala, bez stručnosti za pisanje vlastitih – uobičajeni otpadnik, nastojeći 
    kompromitirati za dobivanje kolaterala, ugled ili politički plan, upotrebljavajući 
    kategorije napada opisane u OWASP kontrolnoj listi za probijanje web aplikacija
  • motivirani napadač – može biti potencijalni plaćeni profesionalni napadač ili član osoblja s 
    unutarnjim znanjem
  • organizirani kriminal – kriminalci koji traže velike isplate uloga, poput „puknuća“ e-
    trgovine ili korporativnih bankovnih aplikacija, za financijsku dobit.

5. Prepoznavanje ranjivosti (Identify Vulnerabilities)

Microsoftova praksa za modeliranje prijetnji usklađuje se s Direktivom o pouzdanom računalstvu od siječnja 2002., a njezina je primarna zadaća osigurati siguran softver tijekom faze projektiranja. Da bi aplikacija ispunila sigurnosna svojstva povjerljivosti (Confidentiality), integriteta (Integrity) i dostupnosti (Availability) (CIA), zajedno s autorizacijom, autentifikacijom i bez odricanja, Microsoft koristi metodologiju „STRIDE“. Microsoft je zapravo i osmislio STRIDE model prijetnje. Dijagram toka podataka (Dana Flow Diagram – DFD) koristi se za grafički prikaz sustava, a DFD-ovi koriste standardni skup simbola koji se sastoji od četiri elementa. Aplikacija se raspada u pojedinačne komponente, a odgovarajuće prijetnje iz STRIDE sustava mogu se primijeniti na svaku komponentu. Potrebno je odrediti ublažavajuće kontrole za svaku komponentu.

DREAD

DREAD – klasifikacijska shema za kvantificiranje, uspoređivanje i određivanje prioriteta količine rizika koje predstavlja svaka ocijenjena prijetnja. Koristi se zapravo za rangiranje prijetnji. DREAD akronim znači: D (Damage Potential – Potencijal štete. „Koji će biti utjecaj na eksploataciju?“), R (Reproducibility - Obnovljivost. „Kakva je jednostavnost ponovnog stvaranja napada?“), E (Exploitability – Iskorištavanje. „Kakva je minimalna razina vještine potrebna za pokretanje?“), A (Affected Users – Pogođeni korisnici. „Koliko će korisnika biti potencijalno pogođeno?“), D (Discoverability – Otkrivanje. „Kakva je jednostavnost pronalaženja ranjivosti?“) DREAD modeliranje utječe na razmišljanje iza postavljanja ocjene rizika, a također se koristi i za izravno sortiranje rizika. Navedeni algoritam se koristi za izračunavanje vrijednosti rizika, što je prosjek svih pet kategorija:

RIZIK = (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY)/5 Izračun uvijek daje broj između 0 i 10, a što je veći broj to je ozbiljniji rizik.

D (Damage Potential)– ako dođe do ostvarivanja prijetnji, koliko će štete biti prouzrokovano: 0 – Ništa, 5 – Pojedinačni korisnički podaci su ugroženi ili pogođeni, 10 – Potpuno uništavanje sustava ili podataka

R (Reproducibility)– koliko je lako reproducirati eksploataciju prijetnji: 0 – Vrlo teško ili nemoguće čak i za administratore, 5 – Potreban je jedan ili dva koraka, možda će trebati ovlašteni korisnik, 10 – Dovoljan je web preglednik i adresna traka, bez provjere autentičnosti

E (Exploitability)– što je potrebno za iskorištavanje prijetnje: 0 – Napredno programiranje i umrežavanje znanja uz prilagođene ili napredne alate za napad, 5 – Zlonamjerni softver postoji na Internetu ili su dostupni neki alati za napad, 10 – Dovoljan je web preglednik

A (Affected Users)– koliko je korisnika pogođeno: 0 – Ništa, 5 – Neki korisnici, ali ne svi, 10 – Pogođeni su svi korisnici

D (Discoverability)– koliko je lako otkriti prijetnju: 0 – Vrlo teško ili nemoguće, potreban je izvorni kod ili administratorski pristup, 5 – Može se utvrditi nagađanjem ili praćenjem mrežnih tragova, 9 – Pojedinosti takvih kvarova već su u javnoj domeni i lako se mogu otkriti pomoću tražilice, 10 – Informacije su vidljive u adresnoj traci web preglednika ili u obliku skrivene varijable

Napomena: Na početku je teško koristiti DREAD. Korisno je razmišljati o mogućim potencijalnim štetama i utjecajima korisnika u smislu utjecaja, a razmišljanje o ponovljivosti, iskoristivosti i otkrivenosti u smislu vjerojatnosti. Rezultati vjerojatnosti imaju veću težinu u ukupnom broju.

STRIDE

STRIDE – pristup oblikovanju prijetnji predstavljen je u Microsoft-u. On je zapravo klasifikacijska shema za opisivanje poznatih prijetnji prema vrstama iskorištavanja koja se koristi ili motivaciji napadača. Koristi se za modeliranje prijetnji. STRIDE akronim znači: S (Spoofing – Prijevara. „Oponašanje (predstavljanje) druge osobe/procesa.“), T (Tampering – Prekršaj. „Nevlaštene izmjene.“), R (Repudation – Odbacivanje. „Negiranje (odbacivanje) zahtjeva/neprovjerene radnje.“), I (Information Disclosure – Obavijest o informacijama. „Izlaganje neovlaštenoj osobi.“), D (Denial of Service – Uskraćivanje usluge. „Dostupnost usluge.“), E (Elevation of Privileges – Povišenje povlastica. „Povećanje procesne razina pristupa.“).

Uobičajeni napadi koji se odnose na STRIDE:

S (Spoofing Identity) – krivotvorenje identiteta – ključni je rizik za aplikacije koje imaju mnogo korisnika, ali pružaju jedan kontekst izvršenja na razini aplikacija i baze podataka. Konkretno, korisnici ne bi smjeli postati drugi korisnik ili preuzeti atribute drugog korisnika. Napad: podvala ponavljajućeg kolačića, preuzimanje sesije, CSRF.

T (Tampering with Data)– neovlašteno korištenje podataka – korisnici mogu potencijalno mijenjati isporučene podatke, vratiti ih i time potencijalno manipulirati provjerom na strani klijenta, GET i POST rezultate, kolačiće, HTTP zaglavlja. Aplikacija ne bi trebala slati podatke korisniku, kao što su kamatne stope koje se mogu dobiti iz same aplikacije. Aplikacija također treba pažljivo provjeriti podatke koje je primio korisnik i potvrditi da je to pravilno i primjenjivo prije spremanja ili korištenja. Napad: XSS, SQL Injection.

R (Repudiation)– odbacivanje – korisnici mogu osporiti transakcije ako nema dovoljno revizije ili evidentiranja njihovih aktivnosti. Također, ako ne mogu pratiti svoje aktivnosti putem aplikacije. Stoga, treba razmotriti je li aplikacija zahtjeva kontrole bez odbijanja, kao što su dnevnici web pristupa, revizijske staze na svakoj razini ili isti korisnički kontekst od vrha do dna. Poželjno je da se aplikacija pokreće s korisnikovim povlasticama, ne više, ali to možda nije moguće s brojnim okvirima za aplikaciju. Napad: brisanje revizije prijave, nesigurna sigurnosna kopija.

I (Information Disclosure)– objavljivanje informacija – korisnici su s pravom oprezni kod slanja privatnih podataka u sustav. Ako je moguće da napadač javno otkrije korisničke podatke, bilo anonimno ili kao ovlašteni korisnik, doći će do neposrednog gubitka povjerenja i znatnog razdoblja gubitka ugleda. Stoga, aplikacije moraju sadržavati jake kontrole kako bi se spriječilo neovlašteno miješanje korisnika i zloupotreba, osobito ako koriste jedan kontekst za pokretanje cijele aplikacije. Također, treba razmotriti mogućnost može li korisnikov web preglednik propustiti informacije. Neki web preglednici mogu zanemarivati direktive o cachingu u HTTP zaglavljima ili mogu neispravno njima rukovati. Na odgovarajući način, svaka sigurnost aplikacija ima odgovornost da to svede na najmanju moguću količinu informacija koje pohranjuje web preglednik. Nakon svega, treba imati da kod provedbe trajnih vrijednosti korištenje skrivenih polja je nesigurno po prirodi. Takvo pohranjivanje ne bi smjelo biti oslonjeno na sigurnost osjetljivih podataka ili pružanje odgovarajućih zaštitnih mjera osobne privatnosti. Napad: prisluškivanje, opširna iznimka.

D (Denial of Service)– uskraćivanje usluge – dizajneri aplikacija trebaju biti svjesni da njihovi programi mogu biti predmetom napada uskraćivanja usluga. Stoga se upotreba skupih resursa, kao što su velike datoteke, složeni izračuni, potraživanja ili drugi upiti trebaju rezervirati za ovjerene i ovlaštene korisnike, a da nisu dostupni anonimnim korisnicima. Za aplikacije koje nemaju tu mogućnost, svaki aspekt aplikacije treba biti osmišljen kako bi obavio što je moguće manje posla, da se brzo koristi i da sadrži malo upita za bazu podataka kako bi se izbjeglo izlaganje velikih datoteka ili jedinstvenih veza po korisniku, odnosno kako bi se spriječili jednostavni napadati uskraćivanja usluga. Napad: izbjegavanje web stranica.

E (Elevation of Privilege) – povišenje povlastica – ako aplikacija pruža različite korisničke i administrativne uloge, onda je od glavnog značaja osigurati da korisnik ne može podići svoju ulogu u višu privilegiju. Konkretno, jednostavno ne prikazivanje privilegiranih veza uloga nedovoljno je. Umjesto toga, sve radnje trebaju biti postavljene putem matrice za autorizaciju kako bi se osiguralo da samo dopuštene uloge mogu pristupiti privilegiranoj funkcionalnosti. Napad: napadi putem protoka logike.

Modeliranja rizika prijetnji korištenjem alternativnih modela prijetnji

Microsoftov proces modeliranja prijetnji ne odgovara svim organizacijama, kada STRIDE i DREAD modeli nisu prihvatljivi iz nekog razloga mogu se uzeti u obzir alternativni modeli prijetnji.

Trike

Trike je metodologija koja se koristi za izgradnju modela prijetnji kako bi se zadovoljio proces sigurnosne revizije iz perspektive upravljanja rizicima. Stvoritelji Trike-a također pružaju alat koji prati ovu metodologiju. Trike je okvir koji je sličan Microsoftovim procesima modeliranja prijetnji. Međutim, Trike se razlikuje jer upotrebljava pristup temeljen na riziku s različitim izvedbenim modelima, modelima prijetnji i modelima rizika, umjesto da koristi model agregirane prijetnje STRIDE / DREAD (napadi, prijetnje i slabosti). Njegovi ciljevi su: sustav podrazumijeva rizik za imovinu koji je prihvatljiv svim sudionicima unutar sustava, treba biti u stanju zaista reći jesmo li to učinili, treba razmijeniti informacije o tome što je učinjeno i kakve su posljedice na sudionike, također potrebno je osnažiti sudionike da razumiju i na taj način smanje rizik kako njima tako i ostalim zainteresiranim stranama podrazumijevani djelovanjem njihove domene. Temelj ove metodologije je "model zahtjeva" koji je osmišljen kako bi se osigurala razina rizika dodijeljenog svakoj imovini koja je "prihvatljiva" od strane dionika sustava. Nakon što je model zahtjeva postavljen, DFD-ovi se koriste za izradu modela implementacije koji ilustrira tokove podataka, uključujući radnje koje se mogu izvršiti u stvarnom vremenu i unutar stanja sustava. Konačno, model implementacije analizira se kako bi se stvorio model prijetnje. Kada se prijetnje nabrajaju, dodijeljene su odgovarajuće vrijednosti rizika i stvaraju se grafovi napada. Olakotne kontrole također su dodijeljene ranjivostima koji dovode do tih prijetnji. Nakon što se ovaj proces završi, model rizika nastaje na temelju imovine, uloga, djelovanja i izloženosti prijetnji. Čini se da je metodologija Trike u eksperimentalnoj fazi, a uz nedostatak značajne dokumentacije i podrške, čini se da ga je teško implementirati („pati“ od problema s perfomansama).

AS/NZS 4360:2004 Risk Management

Australski/novozelandski standard AS/NZS 4360 izdan je 1999. godine dok je revidiran 2004. godine. Prvi je svjetski standard za dokumentiranje i upravljanje rizikom i još je jedan od rijetkih formalnih standarda za upravljanje. Pristup standardu je jednostavan, fleksibilan i iterativan. Nadalje, ne zaključava organizacije u posebnu metodologiju upravljanja rizicima, pod uvjetom da metodologija ispunjava AS/NZS 4360 pet koraka. Također, pruža nekoliko skupova tablica rizika kao primjere i omogućava organizacijama slobodno razvijanje i usvajanje vlastitih rizika. Pet koraka procesa AS/NZS 4360 su:

1. Uspostaviti kontekst – uspostaviti domenu rizika, tj. koja su sredstva i koji su sustavi važni

2. Identificirati rizike – u domeni rizik, koji su specifični rizici očiti

3. Analizirati rizik – pogledati rizike i utvrditi postoje li nadređene kontrole

4. Procijeniti rizik – odrediti preostali rizik

5. Rješavanje rizika – opisati metodu za tretiranje rizika kako bi se rizici koji su odabrani od strane tvrtke ublažili

AS/NZS 4360 pretpostavlja da će rizik biti upravljan grupom operativnih rizika i da organizacija ima odgovarajuće resurse za upravljanje vještinama i rizicima kako bi pravovremeno identificirala, analizirala i postupila na odgovarajući način s rizicima. Prednosti AS/NZS 4360: dobro funkcionira kao metodologija upravljanja rizicima za organizacije koje preferiraju upravljanje rizicima na tradicionalan način, kao što je samo korištenje vjerojatnosti i posljedica za određivanje ukupnog rizika, poznat je većini menadžera koji se bave rizicima širom svijeta, svaka australska organizacija ga u pravu mora redovito revidirati i koristiti, ali model STRIDE/DREAD je kompatibilan sa AS/NZS 4360 što je povoljno za organizacije. Nedostaci (ograničenja) AS/NZS 4360: takav pristup najbolje odgovara poslovnim ili sustavnim rizicima nego tehničkim rizicima, AS/NZS 4360 ne definira metodologiju za obavljanje strukturiranog vježbanja modeliranja rizika prijetnji, budući da je AS/NZS 4360 generički okvir za upravljanje rizikom, ne pruža nikakvu strukturiranu metodu za nabrajanje sigurnosnih rizika za web aplikacije. Iako se AS/NZS 4360 može koristiti za rangiranje rizika za sigurnosne preglede, nedostatak strukturiranih metoda nabrajanja prijetnji za web aplikacije čini ga manje poželjnim od ostalih metodologija.

P.A.S.T.A (Process for Attack Simulation and Threat Analysis)

Proces simulacije napada i analiza prijetnji je metodologija usmjerena na rizik u sedam koraka. Pruža proces od sedam koraka za usklađivanje poslovnih ciljeva i tehničkih zahtjeva, uzimajući u obzir probleme s usklađenosti i analizom poslovanja. Namjera metode je pružiti dinamičnu identifikaciju prijetnji, popisivanja i procjenu bodovanja. Kada se model prijetnje dovrši, stručnjaci za sigurnost predmeta razvijaju detaljnu analizu identificiranih prijetnji. Konačno, odgovarajuće sigurnosne kontrole mogu se nabrojati. Ova je metodologija namijenjena za pružanje napadački centriranog prikaza aplikacije i infrastrukture od kojih „branitelji“ mogu razviti strategiju ublažavanja sredstava koja se temelje na imovini. Postupak započinje jasnom definicijom poslovnih ciljeva, sigurnosnim i sukladnim zahtjevima, zajedno s analizom poslovnih učinaka. Aplikacija se „raspada“ u komponente s dijagramima slučajeva korištenja i DFD-ovima koji se koriste za ilustraciju modela prijetnje, od kojeg se može izvršiti analiza ugroženosti i ranjivosti. Sljedeći korak uključuje korištenje stabala, slučajeva zlostavljanja (abuse cases), sustava bodovanja i popisivanja za detaljniju analizu. Korisnik tada može vidjeti model prijetnje iz napadačeve perspektive obavljajući modeliranje napada. U posljednjem koraku rizik i utjecaj poslovanja mogu se kvalificirati i kvantificirati, zajedno s potrebnim protumjerama. Ovaj proces zapravo kombinira najbolje od različitih pristupa pri modeliranju prijetnji pomoću „stabla napada“ kako bi se osigurao napadački centrični pogled na prijetnju, u kombinaciji s analizom rizika i utjecaja. To pomaže organizacijama da uspostave pristup središnjeg elementa za planiranje strategije ublažavanja. Korištenje stabala prijetnji za mapiranje prijetnji postojećim ranjivostima omogućuje se mnogo lakši i stabilniji proces upravljanja prijetnjama. Osim tehničkog aspekta ovog pristupa, analiza rizika i poslovnih utjecaja povećava modeliranje prijetnji povezujući ranjivost s poslovnom relevantnošću, jer uključuje sudjelovanje ključnih donositelja odluka u tom procesu. Ono što razlikuje ovu metodu od Trike metode jest da uključuje korake upravljanja rizikom u završnoj fazi postupka kako bi se osiguralo da metoda nije ograničena samo na specifičnu formulu za izračunavanje rizika.

CVSS

Američka služba za domovinsku sigurnost (DHS) osnovala je radnu grupu za otkrivanje ranjivosti NIAC-a, koja uključuje inpute iz Cisco Systems, Symantec-a, ISS, Qualys, Microsoft, CERT/CC i eBay. Jedan od izlaznih skupina je Zajednički sustav bodovanja ranjivosti (CVSS). Prednosti CVSS-a: ukoliko se primi obavijest od istraživača sigurnosti ili nekog drugog izvora da neki od proizvoda ima ranjivosti, a želi se osigurati preciznost, točnost i ozbiljnost, treba obavijestiti potrošače o određenim problemima i da se radi na njima kako bi ih se uklonilo, onda istražitelj za sigurnost pronađe neke poteškoće u programu unutar aplikacije te želi upotrijebiti sustav za rangiranje CVSS-a za izradu pouzdanog ranga rizika kako bi osigurali da ISV ozbiljno shvati iskorištavanje kako je naznačeno njihovim ocjenama, također CVSS preporučuje radnu skupinu za uporabu američkih vladinih odjela, međutim nije jasno da li će postati politika ili će biti široko prihvaćen. Nedostaci CVSS-a: CVSS ne pronađe i ne smanjuje površinu napada, te ne pomaže nabrojiti rizike unutar bilo kojeg proizvoljnog dijela koda jer je to samo sustav bodovanja, a ne metodologija modeliranja, on je složeniji od STRIDE/DREAD jer nastoji izračunati rizik najnovijih ranjivosti kao što se primjenjuje na implementiran softver i čimbenike okoline, rangiranje rizika kod CVSS-a je složeno jer proračunska komponenta rizika je potrebna za izračunavanje komponenata rizika (pretpostavka iza CVSS-a je da je identificirana i najavljena određena ranjivost ili je pušten crv ili trojanski konj koji cilja na mali broj napadačkih vektora), prekoračenje izračuna CVSS-ovog rangiranja vrlo je visoka ako se primjenjuje temeljit pregled koda, koji može imati 250 ili više prijetnji.

OCTAVE

OCTAVE je metoda pristupa metodologiji teške metode nastala na Institutu za softversko inženjerstvo Sveučilišta Carnegie Mellon (SEI) u suradnji s CERT-om. Usredotočuje se na organizacijski rizik, a ne na tehnički rizik. Dolazi u dvije verzije: puni OCTAVE – za velike organizacije i OCTAVE-S za male organizacije, od kojih obje imaju specifične kataloge prakse, profila i radnih listova za dokumentiranje ishoda modeliranja. OCTAVE je popularan kod mnogih web mjesta i koristan je kada: implementacija organizacijske kulture upravljanja rizikom i kontrole postaje neophodna, dokumentiranje i mjerenje poslovnog rizika postaje pravodobno, dokumentiranje i mjerenje cjelokupnog IT sigurnosnog rizika, pogotovo što se tiče korporacijskog IT rizika postaje neophodno, pri dokumentiranju rizika koji okružuju kompletne sustave postaje potrebno, kada bi se htjela prilagoditi temeljnoj organizaciji, odnosno kada organizacija nema metodologiju radnog rizika i zahtjeva uspostavu snažnog okvira upravljanja rizikom. Ograničenja OCTAVE su: OCTAVE nije kompatibilan s AS/NZS 4360 jer pretpostavlja da će prijetnja uvijek nastupiti i to je neprikladno za mnoge organizacije. OCTAVE-S čini uključivanje ove vjerojatnosti opcionalno, ali to nije dio OCTAVE standarda koji je opsežniji, sastoji se od 18 svezaka, OCTAVE je velik i složen s mnogo radnih listova i praksi koje treba provesti, ne daje popis prakse „izvan okvira“ za procjenu i ublažavanje rizika sigurnosti web aplikacija. Zbog tih problema, OWASP ne predviđa da će OCTAVE biti u velikoj mjeri iskorišten kod dizajniranja i programiranja aplikacija jer ne uzima u obzir modeliranje rizika prijetnji, što je korisno tijekom svih faza razvoja svih sudionika kako bi se smanjio ukupni rizik da aplikacija postane osjetljiva na napad.

VAST

VAST je skraćenica za modeliranje vizualnih (Visual), agilnih (Agile) i jednostavnih prijetnji (Simple Threat). Temeljna načela ove metodologije su nužnost skaliranja procesa modeliranja prijetnji kroz infrastrukturu te neprimjetno integriranje u metodologiju razvoja agilnog softvera. Metodologija nastoji osigurati djelotvorne rezultate za jedinstvene potrebe različitih dionika: arhitekata aplikacije i razvojnih programera, osoblja kibernetike i viših rukovoditelja. Metodologija pruža jedinstvenu shemu vizualizacije aplikacija i infrastrukture tako da stvaranje i korištenje modela prijetnje ne zahtjeva specifičnu stručnost u području sigurnosti. VAST metodologija dijeli modele prijetnje u dvije kategorije - model prijetnji aplikacija i operativni model prijetnji. Modeli prijetnji aplikacijama vizualno se konstruiraju dijagramima procesnih tokova i fokusiraju se samo na aplikaciju pod analizom. Dijagram toka procesa analizira aplikaciju na isti način kao što programeri razmišljaju o aplikacijama tijekom oblikovanja i kodiranja, u smislu značajki, komunikacijskih protokola i kodnih blokova. Dijagrami tijeka procesa omogućuju arhitektima aplikacija i razvojnim programerima koji su najviše upoznati s projektnim specifikacijama i zahtjevima za izmjenom za izgradnju i modificiranje modela prijetnji aplikacija. To ima dodatne prednosti modela prijetnji koji se neprimjetno integriraju s postojećim tijekovima rada i alatnom trakom razvijenog softvera, kao i pojačanim prihvaćanjem modeliranja prijetnji i prilagodbom izlaza za modeliranje prijetnji. Operativni modeli prijetnji, s druge strane, pružaju 'end-to-end' dijagram toka podataka koji su konkretniji i praktičniji od DFD-ova. Izrada dijagrama toka podataka od početka do kraja započinje prepoznavanjem svih komponenti - bilo izoliranih ili zajedničkih hardvera, softvera, elemenata treće strane, pa čak i korisnika - koji su uključeni u IT sustav komunikacijske protokole koji svaki element ima s drugim specifičnim elementima. Takvi dijagrami toka podataka dijele IT sustav u različite nezavisne, grupirane i dijeljene komponente. Svaka komponenta je opisana u smislu specifičnih atributa. Komponente se povezuju komunikacijskim putovima i protokolima. Rezultat operativnog modela prijetnji je kontekstualizirana komunikacijska karta koju članovi operativnog tima lako mogu razumjeti, stvoriti ili izmijeniti. DevOps timovi upravljaju procesima modeliranja prijetnji - što povećava učinkovitost sigurnosnog tima za uspostavljanje i provođenje sigurnosne politike tijekom čitavog portfelja aplikacije. Sigurnosni timovi mogu provesti sveobuhvatnu analizu napadačke površine i znati točno kako je nova opasna prijetnja relevantna za organizaciju, svodeći do ulaznih točaka potencijalnih prijetnji. To omogućuje menadžerima da procijene prednosti i povrat svojih inicijativa za modeliranje prijetnje, postavljaju politiku rizika i bolje održavaju cjelokupnu ERM strategiju. Nakon što se ATM i OTM konstruiraju, metodologija određuje kako se potencijalne prijetnje identificiraju, nabrajaju, prioritiziraju i povezuju s njihovim relevantnim rizicima.

Općeprihvaćeni procesi modeliranja IT prijetnji

Svi procesi modeliranja prijetnji koji se odnose na IT započinju stvaranjem vizualnog prikaza aplikacije i/ili infrastrukture koja se analizira. Aplikacija/infrastruktura razvrstavaju se u različite elemente kako bi pomogle u analizi. Kada se dovrši, vizualni prikaz koristi se za prepoznavanje i nabrajanje potencijalnih prijetnji. Daljnja analiza modela koji se odnosi na rizike povezane s utvrđenim prijetnjama, prioritetima prijetnji i popisivanjem odgovarajućih ublažavajućih kontrola ovisi o metodološkoj osnovi za korištenje procesa prijetnji.

Vizualni prikaz na temelju dijagrama toka podataka

Vizualni prikaz na temelju dijagrama toka podataka: Microsoft-ova metodologija, P.A.S.T.A., Trike te VAST (OTM) - svaka razvija vizualni prikaz aplikacijske infrastrukture pomoću dijagrama toka podataka (DFD). Dijagrami toka podataka su razvijeni u sedamdesetima kao alat za inženjere sustava da komuniciraju na visokoj razini, kako je aplikacija prouzročila protok podataka, pohranjuje i manipulira infrastrukturom na kojoj aplikacija radi. Tradicionalno, DFD-ovi koriste četiri jedinstvena simbola: tok podataka, spremište podataka, procese i interaktore. Početkom 2000.-ih dodani su dodatni simboli, poput granice povjerenja kako bi se DFD-ovi mogli koristiti za modeliranje prijetnji. Kada se sustav aplikacijske-infrastrukture raspada u pet elemenata, sigurnosni stručnjaci razmatraju svaku identificiranu točku prijetnje protiv svih poznatih kategorija prijetnji. Jednom kada se identificiraju potencijalne prijetnje, mogu se nabrojati sigurnosne kontrole ili se može provesti dodatna analiza.

Vizualni prikaz temeljen na dijagramima tijeka procesa

VAST metodologija razlikuje aplikacijske modele prijetnji (Application threat models – ATM) i operativne ili infrastrukturne prijetnje (Operational threat models – OTM). ATM su napravljeni pomoću dijagrama tijeka procesa. Dijagrami tijeka procesa razvijeni su 2011. godine kao alat koji omogućuje agilnim timovima za razvoj softvera stvaranje modela prijetnji temeljem procesa dizajna aplikacije. Prijave se raspoređuju u njihove različite značajke ili koriste slučajeve. Svaka je značajka opisana u smislu widget-a ili blokova za izradu koda koji su potrebni za izradu te značajke. Značajke se zatim povezuju komunikacijskim protokolima. Tako dobivena vizualizacija je karta o tome kako se korisnik kreće kroz različite značajke aplikacije.

Alati za modeliranje prijetnji

Trenutno postoji pet dostupnih alata za modeliranje organizacijskih prijetnji:

1. Microsoftov besplatni alat za modeliranje prijetnji (Threat Modeling Tool) - Ovaj alat također koristi Microsoftovu metodologiju modeliranja prijetnji, temelji se na DFD-u i identificira prijetnje temeljene na shemi klasifikacije prijetnji prema STRIDE modelu. Namijenjen je prvenstveno za opću upotrebu.

2. MyAppSecurity nudi prvi komercijalno dostupni alat za modeliranje prijetnji - ThreatModeler, a koristi VAST metodologiju, temelji se na PFD-u i prepoznaje prijetnje temeljene na prilagodljivoj sveobuhvatnoj knjižnici prijetnji. Namijenjen je zajedničkoj upotrebi u svim organizacijskim dijelovima.

3. IriusRisk - nudi besplatnu i komercijalnu inačicu alata. Ovaj alat se usredotočuje na stvaranje i održavanje prave vrste prijetnji kroz cijeli SDLC. To pokreće proces pomoću potpuno prilagodljivih upitnika i knjižnica rizika, te povezuje s drugim različitim alatima (OWASP ZAP, BDD-Security, Threadfix ...) kako bi osnažio automatizaciju.

4. securiCAD - alat za modeliranje prijetnji i upravljanje rizikom. Namijenjen je upravljanju računalnom sigurnošću tvrtke, od CISO-a, do sigurnosnog inženjera, do tehničara. securiCAD provodi automatske simulacije napada na postojeće i buduće IT arhitekture, identificira i kvantificira rizike holistički, uključujući strukturne ranjivosti, te pruža podršku odlučivanju na temelju rezultata. SecuriCAD se također nudi u besplatnom i komercijalnom izdanju.

5. SD Elements by Security Compass - platforma za upravljanje sigurnosnim zahtjevima softvera koja uključuje automatizirane mogućnosti modeliranja prijetnji. Skup prijetnji generira se dovršavanjem kratkog upitnika o tehničkim pojedinostima i podudarnosti upravljačkih programa aplikacije. Protumjere su uključene u oblik djelotvornih zadataka za programere koji se mogu pratiti i upravljati tijekom cijelog SDLC-a.

Zaključak

Dotakli smo se osnovnih načela modeliranja rizika prijetnji, upravljanja rizicima i sigurnosti web aplikacija. Aplikacije koje iskorištavaju temeljnu namjeru tih načela bit će sigurnije od ostalih koje će biti minimalno sukladne samo uključivanjem određenih kontrola. Također, mišljenja smo da je procjena modeliranja prijetnji za aplikacije gotovo danas standardna mjera koja traje u prosjeku 6 - 8 tjedana.