Modeliranje groženj: arhitekturo pretvorite v varnostne odločitve

Modeliranje groženj sprašuje, kaj bi lahko v določenem sistemu šlo narobe in kaj naj ekipa glede tega stori. Njegov uporaben rezultat ni katalog strašljivih možnosti. Je nabor odločitev o zasnovi in izvedbi, vezanih na arhitekturo, z lastniki in dokazi, da izbrane obrambe delujejo.

Za tehničnega direktorja (CTO) je osrednje vprašanje, ali zna inženiring pojasniti, kako pomembne varnostne lastnosti preživijo dejansko vedenje sistema: ponovne poskuse, opravila v ozadju, privilegirana dejanja podpore, izpade dobaviteljev in zlonamerne vnose. Diagram te pogovore naredi konkretne. Vzdrževan model groženj sklepe pretvori v delo pri izvedbi.

Smernice OWASP za modeliranje groženj so uporaben temelj: razumeti sistem, prepoznati grožnje, odločiti o odzivu in oceniti, ali je delo zadostno. Spodnji delovni tok ta način razmišljanja uporabi za inženirske odločitve.

Sistem opišite, preden razpravljate o napadih

Začnite z omejeno zmožnostjo, kot so izvozi za stranke, sprožitev plačil ali posodobitve naprav. Modeliranje celotne platforme naenkrat pogosto prinese površna opažanja, ker nihče ne zna dovolj podrobno pojasniti vseh odvisnosti.

Sredstva in varnostne cilje navedite v operativnih izrazih. »Zaščititi podatke strank« je preširoko. »Avtenticiran uporabnik lahko izvozi samo zapise, ki pripadajo njegovemu pooblaščenemu najemniku« ekipi da lastnost, ki jo lahko preizkusi. Drugi cilji se lahko nanašajo na celovitost transakcij, razpoložljivost storitve, obnovitev ali pripisljivost skrbniških dejanj.

Prepoznajte uporabnike, storitve, podatkovne shrambe, zunanje odvisnosti, vstopne točke in meje zaupanja. Narišite pomembne podatkovne tokove, vključno z asinhrono obdelavo in skrbniškimi potmi. Tokove označite s prenesenimi podatki, mehanizmom avtentikacije in kontekstom avtorizacije, kjer ti vplivajo na analizo.

Meja zaupanja označuje spremembo predpostavk ali pooblastil, ne nujno omrežnega perimetra. Brskalnik, ki kliče API, prečka eno mejo. Skupni delavski proces (worker), ki deluje v imenu stranke, prečka drugo, tudi če obe storitvi tečeta v isti gruči.

Pri aplikaciji z več najemniki pokažite, kje se vzpostavi identiteta najemnika in kako doseže preverjanja avtorizacije, opravila v ozadju in izvoze. Vključite storitvene identitete, dostop do objektne shrambe, orodja podpore in zunanje povratne klice. Sicer lahko diagram opisuje srečno pot, izpusti pa poti, ki bodo najverjetneje zaobšle izolacijo.

Predpostavke zapisujte ločeno od dejstev. »Stranke ne morejo pisati v čakalno vrsto« potrebuje podporne dokaze o konfiguraciji. Neznanke naj postanejo naloge preiskave, ne tiho sprejete obrambe.

Izberite metodo, ki ekipi pomaga razmišljati

Metoda daje spodbude in strukturo. Ne določa, katere grožnje so najpomembnejše, ne dokazuje, da je zasnova varna, in ne nadomešča poznavanja sistema.

STRIDE za sistematične spodbude

STRIDE preučuje šest kategorij. Uporabite jih za relevantne komponente, tokove in meje, namesto da bi vsako kategorijo vsilili vsakemu elementu diagrama.

En scenarij lahko obsega več kategorij. Kjer je primerno, vodite en sam zapis, na podlagi katerega je mogoče ukrepati, namesto da bi ustvarjali podvojene zahtevke, da bi zadostili taksonomiji.

Druge metode za druga vprašanja

PASTA (Process for Attack Simulation and Threat Analysis) ponuja sedemstopenjski pristop, usmerjen v tveganja, ki povezuje poslovne cilje, tehnični obseg, razčlenitev, analizo groženj in ranljivosti, modeliranje napadov in obravnavo tveganj. Primeren je za poglobljeno analizo, kjer je treba izrecno upoštevati vedenje napadalcev in poslovne posledice.

Drevesa napadov se začnejo s ciljem napadalca in ga razčlenijo na alternativne ali kombinirane poti. Pri cilju »pridobiti izvoz drugega najemnika« lahko alternative vključujejo obvod avtorizacije API, zmedo v kontekstu najemnika v delavskem procesu ali krajo poverilnice za prenos. Razmerja IN predstavljajo pogoje, ki morajo nastopiti skupaj; razmerja ALI predstavljajo alternative.

VAST (Visual, Agile, and Simple Threat modeling) poudarja razširljivo modeliranje z aplikacijskega in operativnega vidika. Ekipe, ki ga razmišljajo uporabiti, naj preverijo, ali lahko njihova orodja in razvojni proces ta pogleda dosledno vzdržujejo.

Praktično izhodiščno priporočilo je diagram podatkovnih tokov skupaj s STRIDE, nato pa drevo napadov za scenarij z najhujšimi posledicami. Več metodologije je koristno le, kadar izboljša odločitve.

Pregled izvedite okoli konkretnih scenarijev

Pritegnite ljudi, ki razumejo izvedbo in delovanje: razvijalca, arhitekta ali tehničnega vodjo, varnostnega pregledovalca in nekoga, ki pozna vedenje v produkciji. Vključite strokovnjake za izdelek, zasebnost ali dobavitelje, kadar njihovo znanje vpliva na obseg.

Pred sestankom razpošljite diagram, varnostne cilje, relevantno konfiguracijo in nerazrešene predpostavke. Med pregledom sledite eni zahtevi ali dogodku od vstopa do zaključka. Vprašajte, kje se identiteta spremeni, kje se podatki trajno shranijo, kaj se ponovno poskusi in katera komponenta ima pooblastilo za odobritev dejanja.

Grožnje zapišite kot scenarije, ne kot oznake. »Težava z avtorizacijo« ni dovolj uporabna. Močnejša izjava je: »Avtenticiran uporabnik zamenja identifikator izvoza drugega najemnika; končna točka za prenos preveri prijavo, ne pa lastništva objekta, zato razkrije zapise strank.«

Ločite tri pojme:

• Grožnja opisuje škodljivo dejanje ali dogodek, na primer nepooblaščen prevzem izvoza.
• Ranljivost je šibkost, ki bi to lahko omogočila, na primer manjkajoče preverjanje lastništva.
• Tveganje upošteva verjetnost in posledice scenarija v dejanskem okolju.

Grožnjo je lahko vredno raziskati, še preden je ranljivost potrjena. Prav tako odkritje šibkosti ne pomeni, da je izvedljiv vsak predstavljiv napad.

Poleg zunanjih napadov vključite zlorabo s strani legitimnih uporabnikov, privilegirane notranje osebe, napake v konfiguraciji in odpovedi dobaviteljev. Vprašajte, kaj se zgodi, ko odvisnost preseže časovno omejitev ali vrne nepričakovan odziv. Iz teh razprav pogosto izide vedenje »fail-open« in nedosledni ponovni poskusi.

Primer: cevovod izvozov za več najemnikov

Naslednji primer je ponazoritven. Predpostavimo, da ima aplikacija SaaS brskalniškega odjemalca, API, skupno podatkovno bazo, čakalno vrsto opravil, delavski proces za izvoze in objektno shrambo. Uporabniki najemnikov zahtevajo izvoze CSV; delavski proces ustvari datoteke, API pa izda začasne povezave za prenos. Skrbniki podpore imajo ločen vmesnik za odpravljanje težav.

Varnostni cilji so izolacija najemnikov, pooblaščena sprožitev izvoza, omejena poraba virov in pripisljiva dejanja podpore. Predpostavimo, da ima delavski proces dovolj širok dostop do podatkovne baze, da streže več najemnikom. Zaradi tega je njegovo ravnanje s kontekstom najemnika osrednja odločitev, ne pa manjša podrobnost izvedbe.

Sledite pooblastilom skozi tok

Na ravni API je avtenticiran subjekt povezan z dovoljenim članstvom v najemniku. Identifikator najemnika, ki ga posreduje brskalnik, je zahteva za izbiro, ne dokaz avtorizacije. API preveri članstvo in dovoljenje za izvoz, preden ustvari nespremenljiv zapis opravila, ki vsebuje pooblaščenega najemnika, zahtevnika in dovoljeni obseg izvoza.

Sporočilo v čakalni vrsti se sklicuje na ta zapis. Delavski proces preveri opravilo in pri pripravi izvoza uveljavlja dostop do podatkov, omejen na najemnika. Metapodatki shrambe nastali objekt povežejo z opravilom in najemnikom. Pred izdajo povezave za prenos API preveri avtorizacijo trenutnega zahtevnika glede na to povezavo.

Ta zasnova še vedno potrebuje izrecne odločitve o preklicu dostopa: ali naj uporabnik, ki po zahtevi za izvoz izgubi članstvo, obdrži dostop do dokončane datoteke? Ekipa mora to politiko opredeliti in jo dosledno izvajati.

Scenarije pretvorite v kontrole in teste

Začasne povezave uvedejo okno preostale izpostavljenosti: posest lahko glede na mehanizem omogoča dostop do poteka. Ekipa naj odloči, ali je to za zadevne podatke sprejemljivo ali pa prenosi potrebujejo avtenticiranega posrednika s sprotnimi preverjanji avtorizacije.

Modela ne zaprite, ko ste preizkusili samo sinhroni API. Preverite zakasnjena opravila, ponovne poskuse, preklicane zahteve, poteklo članstvo, izbrisane najemnike in delne odpovedi. Ponovno poskušeno opravilo na primer ne sme ponovno uporabiti objekta, povezanega z drugim najemnikom, ali objaviti nepopolnega izvoza kot uspešnega.

Nastali rezultat je pregledana arhitektura, register groženj, naloge izvedbe in povezani rezultati preverjanja. Ni zgolj diagram.

Prednosti določite glede na izpostavljenost in posledice

Verjetne scenarije razvrstite po izpostavljenosti, vplivu, predpogojih in obstoječih obrambah. Ločite neposredno dosegljivo napako avtorizacije od scenarija, ki zahteva več nedokazanih ogrožanj. Kjer je relevantno, upoštevajte prizadete podatke, motnje storitve, finančne posledice, vplive na varnost ljudi in težavnost obnovitve.

Če ekipi pomaga, uporabite preprosto dosledno lestvico, vendar zapišite utemeljitev ocene. Številčna ocena z nepojasnjenimi vhodnimi podatki ustvarja lažno natančnost. CVSS lahko podpira oceno konkretne ranljivosti; ne nadomešča pa razumevanja poslovnega vpliva ali arhitekturnega primera zlorabe.

Možnosti obravnave vključujejo spremembo zasnove, zmanjšanje izpostavljenosti, dodajanje preventivnih ali detektivnih kontrol, opustitev zmožnosti ali sprejetje preostalega tveganja. Pogodbe z dobavitelji lahko razdelijo odgovornosti, ne odpravijo pa tehničnih načinov odpovedi.

Preostalo tveganje naj ima poimensko določenega odločevalca, razlog, potek ali sprožilec pregleda in morebitne pogoje delovanja. Dokončanje inženirskega dela in sprejetje tveganja sta različni odločitvi. Zahtevek je lahko zaključen, medtem ko ostaja pomembno tveganje.

Model prenesite v izvedbo in dokaze

Za vsak bistven scenarij zapišite njegov identifikator, prizadete komponente, predpogoje, posledico, obstoječe obrambe, obravnavo, lastnika in metodo preverjanja. Zapis povežite z različico arhitekture in relevantnim delom pri izvedbi, da pregledovalci vidijo, katera zasnova je bila ocenjena.

Obravnave prevedite v preizkusljiva merila sprejemljivosti. »Izboljšati nadzor dostopa« je nejasno. »Najemnik A prek nobene podprte končne točke ne more zahtevati, preverjati, preklicati ali prenesti izvoza najemnika B« opredeljuje vedenje, ki ga inženiring lahko preveri.

Uporabite dokaze, primerne trditvi:

• Pregled kode lahko ugotovi, kje se avtorizacija uveljavlja.
• Pregled konfiguracije lahko ugotovi dovoljenja storitev in izpostavljenost shrambe.
• Negativni integracijski testi lahko preizkusijo meje med najemniki in meje privilegijev.
• Obremenitveni testi in testi vnašanja napak lahko preučijo razpoložljivost in vedenje ob odpovedi.
• Ciljno usmerjeno penetracijsko testiranje lahko razišče poti napadov, ki potrebujejo neodvisno raziskovanje.

Noben posamezen artefakt ne dokazuje celotnega modela. Posnetek zaslona nastavitve ne dokazuje, da jo uporablja vsak delavski proces, uspešen test pa ne izkazuje nepreizkušene poti. Zapišite testno okolje, obseg, rezultate in omejitve.

Modeliranje groženj dopolnjuje varno programiranje, ocenjevanje odvisnosti, pregledovanje ranljivosti in penetracijsko testiranje. Njegov značilen prispevek je arhitekturno razmišljanje: razkrije lahko nevarno razporeditev pooblastil, tudi kadar posamezne komponente nimajo znanih ranljivosti.

Orodja in avtomatizacija naj bodo podrejeni modelu

Skupni diagram in strukturiran register lahko podpirata osredotočen prvi pregled. Namenska orodja postanejo uporabna, ko ekipe potrebujejo ponovno uporabne knjižnice komponent, dosledne identifikatorje, sodelovanje in zanesljive povezave med grožnjami in zapisi o izvedbi.

Ovrednotite, ali orodje podpira meje zaupanja, scenarije po meri, zgodovino različic, izvozljive zapise, lastništvo in sklice na dokaze. Samodejno ustvarjene grožnje so spodbude za pregled, ne potrjene ugotovitve. Dolgi seznami brez konteksta lahko skrijejo tistih nekaj odločitev, ki so pomembne.

Pomoč umetne inteligence lahko pripravi osnutke opisov scenarijev, predlaga manjkajoče poti ali primerja spremembe s prejšnjim modelom. Človeški pregledovalci morajo še vedno potrditi arhitekturo, izvedljivost, pokritost ublažitev in preostalo tveganje. Zaupnih diagramov in poverilnic ne vnašajte v neodobrene storitve. Ustvarjanje modela groženj je tudi ločeno od zaznavanja med izvajanjem; izdelava modela ne vzpostavi neprekinjenega spremljanja ali samodejne odprave.

Pregled opravite, ko se arhitektura ali predpostavke spremenijo

Model posodobite ob novih integracijah, spremembah avtentikacije, privilegiranih dejanjih, kategorijah podatkov, omrežni izpostavljenosti in večjih spremembah odvisnosti. Tudi incident ali nepričakovan rezultat testa lahko razveljavi prejšnjo predpostavko.

Različni sistemi potrebujejo različne poudarke. Aplikacije v oblaku zahtevajo pozornost do dovoljenj identitet in dostopa do upravljavske ravnine. Mobilne odjemalce je treba obravnavati kot okolja pod nadzorom napadalca, ne kot zaupanja vredne točke uveljavljanja. Povezane naprave uvajajo fizični dostop, celovitost posodobitev, obnovitev in morebitne posledice za varnost ljudi. Funkcije z umetno inteligenco dodajo nezaupljivo vsebino in meje uporabe orodij; avtorizacija mora omejevati dejanja ne glede na izhod modela.

Merite, ali imajo pomembni tokovi aktualne modele, ali imajo obravnave z visoko prednostjo dokaze o preverjanju, ali predpostavke ostajajo nerazrešene in ali imajo sprejeta tveganja zapadle preglede. Zgolj štetje groženj nagrajuje količino namesto uporabne analize. Občasno prosite neodvisnega pregledovalca, naj izpodbija en kritičen scenarij in njegove dokaze.

Prvi pregled naj bo dovolj majhen, da ga dokončate

Secani lahko ohrani delovni tok okoli teh odločitev z modeliranjem relevantnih sistemov in odvisnosti, dodeljevanjem lastnikov in pregledovalcev ter povezovanjem dokazov z zahtevami, kontrolami in odločitvami. Nerazrešene predpostavke postanejo naloge; izvorno gradivo in človeške odobritve ostanejo pripete k pregledu. Morebitne predloge, podprte z umetno inteligenco, je treba pred odobritvijo preveriti.

Začnite z enim kritičnim podatkovnim tokom. Sledite njegovim pooblastilom od začetka do konca, prepoznajte peščico verjetnih scenarijev in zaključite z obravnavami z lastniki in izrecnimi merili preverjanja. Naslednji pregled načrtujte okoli arhitekturnih sprememb, ki bi lahko te odločitve razveljavile.