Modeliranje prijetnji: pretvorite arhitekturu u sigurnosne odluke

Modeliranje prijetnji postavlja pitanje što bi u određenom sustavu moglo poći po zlu i što bi tim trebao poduzeti u vezi s tim. Njegov koristan rezultat nije katalog zastrašujućih mogućnosti. To je skup odluka o dizajnu i implementaciji vezanih uz arhitekturu, s vlasnicima i dokazima da odabrane obrane funkcioniraju.

Za tehničkog direktora središnje je pitanje može li inženjering objasniti kako važna sigurnosna svojstva opstaju u stvarnom ponašanju sustava: kod ponovnih pokušaja, pozadinskih zadataka, povlaštenih radnji podrške, ispada dobavljača i zlonamjernog unosa. Dijagram te razgovore čini konkretnima. Održavani model prijetnji pretvara zaključke u posao isporuke.

Smjernice OWASP-a za modeliranje prijetnji pružaju korisne temelje: razumjeti sustav, identificirati prijetnje, odlučiti kako odgovoriti i procijeniti je li posao dovoljan. Tijek rada u nastavku primjenjuje taj način razmišljanja na inženjerske odluke.

Opišite sustav prije rasprave o napadima

Počnite s ograničenom sposobnošću, kao što su izvozi za kupce, iniciranje plaćanja ili ažuriranja uređaja. Modeliranje cijele platforme odjednom često daje površna zapažanja jer nitko ne može dovoljno detaljno objasniti svaku ovisnost.

Navedite imovinu i sigurnosne ciljeve operativnim izrazima. „Zaštititi podatke kupaca“ preširoko je. „Autentificirani korisnik može izvesti samo zapise koji pripadaju njegovu ovlaštenom zakupcu“ daje timu svojstvo koje može testirati. Drugi ciljevi mogu se odnositi na cjelovitost transakcija, dostupnost usluge, oporavak ili pripisivanje administrativnih radnji.

Identificirajte korisnike, usluge, spremišta podataka, vanjske ovisnosti, ulazne točke i granice povjerenja. Nacrtajte važne tokove podataka, uključujući asinkronu obradu i administrativne putove. Označite tokove podacima koje prenose, mehanizmom autentifikacije i kontekstom autorizacije kada to utječe na analizu.

Granica povjerenja označava promjenu pretpostavki ili ovlasti, a ne nužno mrežni perimetar. Preglednik koji poziva API prelazi jednu granicu. Zajednički proces (worker) koji djeluje u ime kupca prelazi drugu, čak i ako se obje usluge izvode u istom klasteru.

Za aplikaciju s više zakupaca (multi-tenant) pokažite gdje se utvrđuje identitet zakupca i kako on stiže do provjera autorizacije, pozadinskih zadataka i izvoza. Uključite identitete usluga, pristup spremištu objekata, alate za podršku i vanjske povratne pozive. U protivnom dijagram može opisivati idealan put, a izostaviti upravo putove koji će najvjerojatnije zaobići izolaciju.

Bilježite pretpostavke odvojeno od činjenica. „Kupci ne mogu pisati u red čekanja“ treba potkrijepiti dokazima o konfiguraciji. Nepoznanice trebaju postati istraživački zadaci, a ne prešutno prihvaćene obrane.

Odaberite metodu koja timu pomaže u razmišljanju

Metoda pruža poticaje i strukturu. Ona ne određuje koje su prijetnje najvažnije, ne dokazuje da je dizajn siguran niti zamjenjuje poznavanje sustava.

STRIDE za sustavne poticaje

STRIDE ispituje šest kategorija. Primijenite ih na relevantne komponente, tokove i granice umjesto da svaku kategoriju nametnete svakom elementu dijagrama.

Jedan scenarij može obuhvaćati nekoliko kategorija. Gdje je to primjereno, vodite jedan zapis na temelju kojeg se može djelovati umjesto da stvarate duplikate zahtjeva kako biste zadovoljili taksonomiju.

Druge metode za druga pitanja

PASTA (Process for Attack Simulation and Threat Analysis) nudi sedmofazni pristup usmjeren na rizik koji povezuje poslovne ciljeve, tehnički opseg, dekompoziciju, analizu prijetnji i ranjivosti, modeliranje napada i obradu rizika. Prikladna je za dublju analizu kada ponašanje napadača i poslovne posljedice trebaju izričitu pozornost.

Stabla napada (attack trees) počinju ciljem napadača i razlažu ga na alternativne ili kombinirane putove. Za cilj „pribaviti izvoz drugog zakupca“ alternative mogu uključivati zaobilaženje autorizacije API-ja, zbunjivanje konteksta zakupca u procesu ili krađu vjerodajnice za preuzimanje. Odnosi AND predstavljaju uvjete koji se moraju ostvariti zajedno; odnosi OR predstavljaju alternative.

VAST (Visual, Agile, and Simple Threat modeling) naglašava skalabilno modeliranje iz aplikacijske i operativne perspektive. Timovi koji ga razmatraju trebaju ispitati mogu li njihovi alati i razvojni proces dosljedno održavati te prikaze.

Praktična početna preporuka jest dijagram toka podataka uz STRIDE, a zatim stablo napada za scenarij s najtežim posljedicama. Više metodologije korisno je samo kada poboljšava odluke.

Provedite pregled oko konkretnih scenarija

Okupite ljude koji razumiju implementaciju i rad: razvojnog inženjera, arhitekta ili tehničkog voditelja, sigurnosnog recenzenta i nekoga tko poznaje ponašanje u produkciji. Uključite stručnjake za proizvod, privatnost ili dobavljače kada njihovo znanje utječe na opseg.

Prije sastanka podijelite dijagram, sigurnosne ciljeve, relevantnu konfiguraciju i neriješene pretpostavke. Tijekom pregleda provedite jedan zahtjev ili događaj od ulaza do dovršetka. Pitajte gdje se mijenja identitet, gdje se podaci trajno pohranjuju, što se ponovno pokušava i koja komponenta ima ovlast odobriti radnju.

Zapisujte prijetnje kao scenarije, a ne kao oznake. „Problem s autorizacijom“ nije dovoljno koristan. Snažnija izjava glasi: „Autentificirani korisnik zamjenjuje identifikator izvoza drugog zakupca; krajnja točka za preuzimanje provjerava prijavu, ali ne i vlasništvo nad objektom, čime se izlažu zapisi kupaca.“

Razdvojite tri pojma:

• Prijetnja opisuje štetnu radnju ili događaj, kao što je neovlašteno preuzimanje izvoza.
• Ranjivost je slabost koja bi to mogla omogućiti, kao što je nedostajuća provjera vlasništva.
• Rizik razmatra vjerojatnost i posljedicu scenarija u stvarnom okruženju.

Prijetnju može vrijediti istražiti i prije nego što se ranjivost potvrdi. Jednako tako, pronalazak slabosti ne utvrđuje da je izvediv svaki zamislivi napad.

Uz vanjske napade uključite zlouporabu od strane legitimnih korisnika, povlaštene unutarnje osobe, pogreške u konfiguraciji i neuspjehe dobavljača. Pitajte što se događa kada ovisnost istekne ili vrati neočekivani odgovor. Ponašanje koje u slučaju neuspjeha ostavlja pristup otvorenim (fail-open) i nedosljedni ponovni pokušaji često izranjaju iz takvih rasprava.

Razrađeni primjer: cjevovod izvoza s više zakupaca

Sljedeći je primjer ilustrativan. Pretpostavimo da SaaS aplikacija ima klijent u pregledniku, API, zajedničku bazu podataka, red čekanja zadataka, proces za izvoz i spremište objekata. Korisnici zakupca traže izvoze u formatu CSV; proces generira datoteke, a API izdaje privremene poveznice za preuzimanje. Administratori podrške imaju zasebno sučelje za otklanjanje poteškoća.

Sigurnosni ciljevi jesu izolacija zakupaca, ovlašteno pokretanje izvoza, ograničena potrošnja resursa i pripisive radnje podrške. Pretpostavimo da proces ima pristup bazi podataka dovoljno širok da opslužuje više zakupaca. Zbog toga njegovo postupanje s kontekstom zakupca postaje središnja odluka, a ne sporedan implementacijski detalj.

Pratite ovlasti kroz tok

Na razini API-ja autentificirani subjekt povezan je s dopuštenim članstvom u zakupcu. Identifikator zakupca koji šalje preglednik zahtjev je za odabir, a ne dokaz autorizacije. API provjerava članstvo i dopuštenje za izvoz prije stvaranja nepromjenjivog zapisa zadatka koji sadrži ovlaštenog zakupca, podnositelja zahtjeva i dopušteni opseg izvoza.

Poruka u redu čekanja upućuje na taj zapis. Proces provjerava zadatak i pri izradi izvoza provodi pristup podacima ograničen na zakupca. Metapodaci spremišta povezuju nastali objekt sa zadatkom i zakupcem. Prije izdavanja poveznice za preuzimanje API provjerava autorizaciju trenutačnog podnositelja zahtjeva u odnosu na tu povezanost.

Ovaj dizajn i dalje treba izričite odluke o opozivu pristupa: treba li korisnik koji izgubi članstvo nakon što je zatražio izvoz zadržati pristup dovršenoj datoteci? Tim mora definirati tu politiku i dosljedno je implementirati.

Pretvorite scenarije u kontrole i testove

Privremene poveznice uvode preostali prozor izloženosti: posjedovanje poveznice može, ovisno o mehanizmu, omogućiti pristup do isteka. Tim treba odlučiti je li to prihvatljivo za uključene podatke ili preuzimanja trebaju autentificiranog posrednika s aktualnim provjerama autorizacije.

Ne zatvarajte model nakon testiranja samo sinkronog API-ja. Provjerite odgođene zadatke, ponovne pokušaje, otkazane zahtjeve, isteklo članstvo, izbrisane zakupce i djelomične neuspjehe. Primjerice, ponovno pokrenuti zadatak ne smije ponovno upotrijebiti objekt povezan s drugim zakupcem niti objaviti nepotpun izvoz kao uspješan.

Konačni rezultat jest pregledana arhitektura, registar prijetnji, implementacijski zadaci i povezani rezultati provjere. To nije samo dijagram.

Određujte prioritete prema izloženosti i posljedicama

Odredite prioritete vjerojatnih scenarija prema izloženosti, utjecaju, preduvjetima i postojećim obranama. Razlikujte izravno dostupan neuspjeh autorizacije od scenarija koji zahtijeva nekoliko nedokazanih kompromitacija. Razmotrite pogođene podatke, poremećaj usluge, financijske posljedice, implikacije za sigurnost ljudi i težinu oporavka gdje je to relevantno.

Koristite jednostavnu dosljednu ljestvicu ako pomaže timu, ali zabilježite obrazloženje ocjene. Brojčana ocjena s neobjašnjenim ulaznim podacima stvara lažnu preciznost. CVSS može informirati procjenu konkretne ranjivosti; on nije zamjena za razumijevanje poslovnog utjecaja ili arhitektonskog slučaja zlouporabe.

Mogućnosti obrade uključuju promjenu dizajna, smanjenje izloženosti, dodavanje preventivnih ili detektivnih kontrola, izbjegavanje sposobnosti ili prihvaćanje preostalog rizika. Ugovori s dobavljačima mogu raspodijeliti odgovornosti, ali ne uklanjaju tehničke načine zakazivanja.

Preostali rizik treba imati imenovanog donositelja odluke, razlog, istek ili okidač preispitivanja te eventualne uvjete rada. Inženjerski dovršetak i prihvaćanje rizika različite su odluke. Zahtjev može biti dovršen dok značajan rizik i dalje postoji.

Prenesite model u isporuku i dokaze

Za svaki bitan scenarij zabilježite njegov identifikator, pogođene komponente, preduvjete, posljedicu, postojeće obrane, obradu, vlasnika i metodu provjere. Povežite zapis s verzijom arhitekture i relevantnim implementacijskim radom kako bi recenzenti znali koji je dizajn procijenjen.

Pretvorite obrade u kriterije prihvaćanja koji se mogu testirati. „Poboljšati kontrolu pristupa“ nejasno je. „Zakupac A ne može zatražiti, provjeravati stanje, otkazati ni preuzeti izvoz zakupca B ni putem jedne podržane krajnje točke“ identificira ponašanje koje inženjering može provjeriti.

Koristite dokaze primjerene tvrdnji:

• Pregled koda može utvrditi gdje se provodi autorizacija.
• Pregled konfiguracije može utvrditi dopuštenja usluga i izloženost spremišta.
• Negativni integracijski testovi mogu iskušati granice između zakupaca i granice ovlasti.
• Testovi opterećenja i ubacivanja kvarova mogu ispitati dostupnost i ponašanje pri neuspjehu.
• Ciljano penetracijsko testiranje može istražiti putove napada koji zahtijevaju neovisno istraživanje.

Nijedan pojedinačni artefakt ne dokazuje cijeli model. Snimka zaslona postavke ne dokazuje da je koristi svaki proces, a uspješan test ne dokazuje netestirani put. Zabilježite testno okruženje, opseg, rezultate i ograničenja.

Modeliranje prijetnji nadopunjuje sigurno kodiranje, procjenu ovisnosti, skeniranje ranjivosti i penetracijsko testiranje. Njegov je osobit doprinos arhitektonsko razmišljanje: može otkriti opasnu raspodjelu ovlasti čak i kada pojedinačne komponente nemaju poznatih ranjivosti.

Neka alati i automatizacija budu podređeni modelu

Zajednički dijagram i strukturirani registar mogu podržati usredotočen prvi pregled. Namjenski alati postaju korisni kada timovima trebaju knjižnice komponenti za ponovnu upotrebu, dosljedni identifikatori, suradnja i pouzdane poveznice između prijetnji i zapisa o isporuci.

Ocijenite podržava li alat granice povjerenja, prilagođene scenarije, povijest verzija, izvozive zapise, vlasništvo i reference na dokaze. Automatski generirane prijetnje poticaji su za ispitivanje, a ne potvrđeni nalazi. Dugi popisi bez konteksta mogu sakriti nekoliko odluka koje su važne.

Pomoć umjetne inteligencije može izraditi nacrte opisa scenarija, predložiti putove koji nedostaju ili usporediti promjene s ranijim modelom. Ljudski recenzenti i dalje moraju potvrditi arhitekturu, izvedivost, pokrivenost mjerama ublažavanja i preostali rizik. Držite povjerljive dijagrame i vjerodajnice izvan neodobrenih usluga. Generiranje modela prijetnji također se razlikuje od otkrivanja tijekom rada; izrada modela ne uspostavlja kontinuirano praćenje ni automatizirano otklanjanje.

Preispitajte model kada se arhitektura ili pretpostavke promijene

Ažurirajte model za nove integracije, promjene autentifikacije, povlaštene radnje, kategorije podataka, mrežnu izloženost i velike promjene ovisnosti. Incident ili neočekivan rezultat testa također može poništiti raniju pretpostavku.

Različiti sustavi trebaju različit naglasak. Aplikacije u oblaku zahtijevaju pozornost prema dopuštenjima identiteta i pristupu upravljačkoj razini. Mobilne klijente treba tretirati kao okruženja pod kontrolom napadača, a ne kao pouzdane točke provedbe. Povezani uređaji uvode fizički pristup, cjelovitost ažuriranja, oporavak i potencijalne posljedice za sigurnost ljudi. Funkcije koje se oslanjaju na umjetnu inteligenciju dodaju nepouzdan sadržaj i granice upotrebe alata; autorizacija mora ograničavati radnje bez obzira na izlazni rezultat modela.

Mjerite imaju li važni tokovi aktualne modele, imaju li obrade visokog prioriteta dokaze provjere, ostaju li pretpostavke neriješene i imaju li prihvaćeni rizici zakašnjela preispitivanja. Samo brojanje prijetnji nagrađuje količinu umjesto korisne analize. Povremeno zamolite neovisnog recenzenta da preispita jedan kritičan scenarij i njegove dokaze.

Neka prvi pregled bude dovoljno malen da se može dovršiti

Secani može sačuvati tijek rada oko tih odluka modeliranjem relevantnih sustava i ovisnosti, dodjeljivanjem vlasnika i recenzenata te povezivanjem dokaza sa zahtjevima, kontrolama i odlukama. Neriješene pretpostavke postaju zadaci; izvorni materijali i ljudska odobrenja ostaju vezani uz pregled. Sve prijedloge potpomognute umjetnom inteligencijom treba provjeriti prije odobrenja.

Počnite s jednim kritičnim tokom podataka. Pratite njegove ovlasti od početka do kraja, identificirajte nekoliko vjerojatnih scenarija i završite s obradama koje imaju vlasnike i izričitim kriterijima provjere. Zakažite sljedeći pregled oko arhitektonskih promjena koje bi mogle poništiti te odluke.