Grėsmių modeliavimas: architektūrą paverskite saugumo sprendimais

Grėsmių modeliavimas klausia, kas konkrečioje sistemoje gali nepavykti ir ką komanda turėtų dėl to daryti. Naudingas jo rezultatas nėra bauginančių galimybių katalogas. Tai su architektūra susietų projektavimo ir įgyvendinimo sprendimų rinkinys su atsakingais asmenimis ir įrodymais, kad pasirinktos apsaugos priemonės veikia.

CTO pagrindinis klausimas yra tai, ar inžinerija gali paaiškinti, kaip svarbios saugumo savybės išlieka realiai veikiant sistemai: pakartotinių bandymų, foninių užduočių, privilegijuotų pagalbos veiksmų, tiekėjų sutrikimų ir kenkėjiškos įvesties metu. Diagrama padaro šiuos pokalbius konkrečius. Palaikomas grėsmių modelis išvadas paverčia įgyvendinimo darbu.

OWASP grėsmių modeliavimo gairės suteikia naudingą pagrindą: suprasti sistemą, nustatyti grėsmes, nuspręsti, kaip reaguoti, ir įvertinti, ar atlikto darbo pakanka. Toliau aprašyta darbo eiga šį mąstymą taiko inžineriniams sprendimams.

Aprašykite sistemą prieš aptardami atakas

Pradėkite nuo apibrėžtos funkcijos, pavyzdžiui, klientų duomenų eksporto, mokėjimo inicijavimo ar įrenginių atnaujinimų. Modeliuojant visą platformą iš karto dažnai gaunamos paviršutiniškos pastabos, nes niekas negali pakankamai išsamiai paaiškinti kiekvienos priklausomybės.

Turtą ir saugumo tikslus apibūdinkite veiklos terminais. „Apsaugoti klientų duomenis“ yra per plačiai. „Autentifikuotas naudotojas gali eksportuoti tik įrašus, priklausančius jo autorizuotam nuomininkui“ suteikia komandai savybę, kurią galima išbandyti. Kiti tikslai gali būti susiję su operacijų vientisumu, paslaugos prieinamumu, atkūrimu ar administracinių veiksmų priskyrimu.

Nustatykite naudotojus, paslaugas, duomenų saugyklas, išorines priklausomybes, įėjimo taškus ir pasitikėjimo ribas. Nubraižykite svarbius duomenų srautus, įskaitant asinchroninį apdorojimą ir administravimo kelius. Srautus pažymėkite perduodamais duomenimis, autentifikavimo mechanizmu ir autorizacijos kontekstu, kai jie turi įtakos analizei.

Pasitikėjimo riba žymi prielaidų ar įgaliojimų pasikeitimą, nebūtinai tinklo perimetrą. Naršyklė, kreipdamasi į API, kerta vieną ribą. Bendras darbinis procesas, veikiantis kliento vardu, kerta kitą, net jei abi paslaugos veikia tame pačiame klasteryje.

Daugianuomininkėje taikomojoje programoje parodykite, kur nustatoma nuomininko tapatybė ir kaip ji pasiekia autorizacijos patikras, fonines užduotis ir eksportus. Įtraukite paslaugų tapatybes, prieigą prie objektų saugyklos, pagalbos įrankius ir išorinius atgalinius iškvietimus. Kitaip diagrama gali aprašyti sklandų kelią, praleisdama kelius, kuriais izoliaciją apeiti tikėtiniausia.

Prielaidas užfiksuokite atskirai nuo faktų. „Klientai negali rašyti į eilę“ reikia pagrįsti konfigūracijos įrodymais. Nežinomi dalykai turėtų tapti tyrimo užduotimis, o ne tyliai priimtomis apsaugos priemonėmis.

Pasirinkite metodą, kuris padeda komandai mąstyti

Metodas suteikia klausimų ir struktūrą. Jis nenulemia, kurios grėsmės svarbiausios, neįrodo, kad projektas saugus, ir nepakeičia sistemos išmanymo.

STRIDE sisteminiams klausimams

STRIDE nagrinėja šešias kategorijas. Taikykite jas atitinkamiems komponentams, srautams ir riboms, o ne primeskite kiekvieną kategoriją kiekvienam diagramos elementui.

Vienas scenarijus gali apimti kelias kategorijas. Kai tinka, laikykite vieną įgyvendinamą įrašą, užuot kūrę pasikartojančias užduotis vien tam, kad patenkintumėte taksonomiją.

Kiti metodai kitiems klausimams

PASTA (Process for Attack Simulation and Threat Analysis) siūlo septynių etapų, į riziką orientuotą metodą, siejantį verslo tikslus, techninę apimtį, dekompoziciją, grėsmių ir pažeidžiamumų analizę, atakų modeliavimą ir rizikos valdymą. Jis tinka gilesnei analizei, kai užpuoliko elgsenai ir verslo pasekmėms reikia skirti aiškų dėmesį.

Atakų medžiai prasideda nuo užpuoliko tikslo ir išskaido jį į alternatyvius ar kombinuotus kelius. Tikslui „gauti kito nuomininko eksportą“ alternatyvos galėtų būti API autorizacijos apėjimas, darbinio proceso nuomininko konteksto supainiojimas ar atsisiuntimo kredencialų pavogimas. IR ryšiai žymi sąlygas, kurios turi įvykti kartu; ARBA ryšiai žymi alternatyvas.

VAST (Visual, Agile, and Simple Threat modeling) pabrėžia keičiamo mastelio modeliavimą taikomosios programos ir veiklos požiūriais. Šį metodą svarstančios komandos turėtų įvertinti, ar jų įrankiai ir kūrimo procesas gali nuosekliai palaikyti šiuos požiūrius.

Praktinė pradinė rekomendacija – duomenų srautų diagrama kartu su STRIDE, o tada atakų medis reikšmingiausiam scenarijui. Daugiau metodikos naudinga tik tada, kai ji pagerina sprendimus.

Peržiūrą organizuokite aplink konkrečius scenarijus

Pakvieskite žmones, kurie išmano įgyvendinimą ir veikimą: kūrėją, architektą ar techninį vadovą, saugumo peržiūrėtoją ir žmogų, susipažinusį su gamybinės aplinkos elgsena. Įtraukite produkto, privatumo ar tiekėjų specialistus, kai jų žinios daro įtaką apimčiai.

Prieš susitikimą išplatinkite diagramą, saugumo tikslus, atitinkamą konfigūraciją ir neišspręstas prielaidas. Peržiūros metu pereikite vieną užklausą ar įvykį nuo įėjimo iki užbaigimo. Klauskite, kur keičiasi tapatybė, kur išsaugomi duomenys, kas kartojama ir kuris komponentas turi įgaliojimus patvirtinti veiksmą.

Grėsmes aprašykite kaip scenarijus, o ne etiketes. „Autorizacijos problema“ nėra pakankamai naudinga. Stipresnis teiginys: „Autentifikuotas naudotojas pakeičia eksporto identifikatorių kito nuomininko identifikatoriumi; atsisiuntimo galinis taškas tikrina prisijungimą, bet ne objekto nuosavybę, todėl atskleidžiami klientų įrašai.“

Atskirkite tris sąvokas:

• Grėsmė apibūdina nepageidaujamą veiksmą ar įvykį, pavyzdžiui, neautorizuotą eksporto gavimą.
• Pažeidžiamumas yra silpnybė, kuri galėtų tai sudaryti sąlygas, pavyzdžiui, trūkstama nuosavybės patikra.
• Rizika įvertina scenarijaus tikimybę ir pasekmes realioje aplinkoje.

Grėsmę gali būti verta ištirti dar prieš patvirtinant pažeidžiamumą. Lygiai taip pat silpnybės radimas neįrodo, kad kiekviena įsivaizduojama ataka įmanoma.

Šalia išorinių atakų įtraukite teisėtų naudotojų piktnaudžiavimą, privilegijuotus vidinius asmenis, konfigūracijos klaidas ir tiekėjų gedimus. Paklauskite, kas nutinka, kai priklausomybei baigiasi skirtasis laikas arba ji grąžina netikėtą atsakymą. Elgsena, kai gedimo atveju prieiga paliekama atvira, ir nenuoseklūs pakartotiniai bandymai dažnai išryškėja būtent tokiose diskusijose.

Pavyzdys: daugianuomininkis eksporto konvejeris

Toliau pateikiamas pavyzdys yra iliustracinis. Tarkime, SaaS taikomąją programą sudaro naršyklės klientas, API, bendra duomenų bazė, užduočių eilė, eksporto darbinis procesas ir objektų saugykla. Nuomininkų naudotojai prašo CSV eksportų; darbinis procesas generuoja failus, o API išduoda laikinas atsisiuntimo nuorodas. Pagalbos tarnybos administratoriai turi atskirą trikčių šalinimo sąsają.

Saugumo tikslai – nuomininkų izoliacija, autorizuotas eksporto inicijavimas, ribotas išteklių naudojimas ir priskiriami pagalbos tarnybos veiksmai. Tarkime, darbinis procesas turi pakankamai plačią prieigą prie duomenų bazės, kad aptarnautų kelis nuomininkus. Dėl to jo atliekamas nuomininko konteksto tvarkymas tampa esminiu sprendimu, o ne smulkia įgyvendinimo detale.

Atsekite įgaliojimus per visą srautą

API lygmeniu autentifikuotas subjektas susiejamas su leidžiama naryste nuomininke. Naršyklės pateiktas nuomininko identifikatorius yra pasirinkimo prašymas, o ne autorizacijos įrodymas. API patikrina narystę ir eksporto leidimą prieš sukurdama nekeičiamą užduoties įrašą, kuriame yra autorizuotas nuomininkas, prašytojas ir leidžiama eksporto apimtis.

Eilės pranešimas nurodo į šį įrašą. Darbinis procesas patvirtina užduotį ir, rengdamas eksportą, užtikrina nuomininko apimtyje ribotą prieigą prie duomenų. Saugyklos metaduomenys gautą objektą susieja su užduotimi ir nuomininku. Prieš išduodama atsisiuntimo nuorodą, API patikrina dabartinio prašytojo autorizaciją pagal šį susiejimą.

Šiam projektui vis dar reikia aiškių sprendimų dėl prieigos atšaukimo: ar naudotojas, praradęs narystę po eksporto užklausos, turėtų išlaikyti prieigą prie užbaigto failo? Komanda turi apibrėžti šią politiką ir ją nuosekliai įgyvendinti.

Scenarijus paverskite kontrolės priemonėmis ir testais

Laikinos nuorodos sukuria likutinės rizikos langą: priklausomai nuo mechanizmo, nuorodos turėjimas gali leisti prieigą iki galiojimo pabaigos. Komanda turėtų nuspręsti, ar tai priimtina atitinkamiems duomenims, ar atsisiuntimams reikia autentifikuoto tarpininko, atliekančio dabartinės autorizacijos patikras.

Neužbaikite modelio išbandę vien sinchroninę API. Patikrinkite atidėtas užduotis, pakartotinius bandymus, atšauktas užklausas, pasibaigusią narystę, ištrintus nuomininkus ir dalinius gedimus. Pavyzdžiui, pakartotinai vykdoma užduotis neturi pakartotinai naudoti objekto, susieto su kitu nuomininku, arba paskelbti neužbaigto eksporto kaip sėkmingo.

Rezultatas – peržiūrėta architektūra, grėsmių registras, įgyvendinimo užduotys ir susieti patikrinimo rezultatai. Tai nėra vien diagrama.

Prioritetus nustatykite pagal poveikį ir pasekmes

Tikėtinų scenarijų prioritetus nustatykite pagal atvirumą, poveikį, išankstines sąlygas ir esamas apsaugos priemones. Atskirkite tiesiogiai pasiekiamą autorizacijos gedimą nuo scenarijaus, kuriam reikia kelių neįrodytų kompromitavimų. Kai svarbu, atsižvelkite į paveiktus duomenis, paslaugos sutrikimą, finansines pasekmes, poveikį saugai ir atkūrimo sudėtingumą.

Jei tai padeda komandai, naudokite paprastą nuoseklią skalę, tačiau užfiksuokite įvertinimo pagrindimą. Skaitinis balas su nepaaiškintais įvesties duomenimis sukuria tariamą tikslumą. CVSS gali padėti vertinti konkretų pažeidžiamumą; jis nepakeičia verslo poveikio supratimo ar architektūrinio piktnaudžiavimo atvejo.

Rizikos valdymo pasirinkimai apima projekto keitimą, atvirumo mažinimą, prevencinių ar aptikimo kontrolės priemonių pridėjimą, funkcijos atsisakymą ar likusios rizikos priėmimą. Sutartys su tiekėjais gali paskirstyti atsakomybes, tačiau jos nepanaikina techninių gedimų scenarijų.

Likutinė rizika turėtų turėti įvardytą sprendimų priėmėją, priežastį, galiojimo pabaigą ar peržiūros sukėlėją ir bet kokias veikimo sąlygas. Inžinerinio darbo užbaigimas ir rizikos priėmimas yra skirtingi sprendimai. Užduotis gali būti baigta, o reikšminga rizika – likti.

Modelį perkelkite į įgyvendinimą ir įrodymus

Kiekvienam reikšmingam scenarijui užfiksuokite jo identifikatorių, paveiktus komponentus, išankstines sąlygas, pasekmę, esamas apsaugos priemones, rizikos valdymo priemonę, atsakingą asmenį ir patikrinimo metodą. Susiekite įrašą su architektūros versija ir atitinkamu įgyvendinimo darbu, kad peržiūrėtojai matytų, koks projektas buvo įvertintas.

Rizikos valdymo priemones paverskite patikrinamais priėmimo kriterijais. „Pagerinti prieigos kontrolę“ yra miglota. „Nuomininkas A negali per jokį palaikomą galinį tašką prašyti, tikrinti būsenos, atšaukti ar atsisiųsti nuomininko B eksporto“ nurodo elgseną, kurią inžinerija gali patikrinti.

Naudokite teiginiui tinkamus įrodymus:

• Kodo peržiūra gali nustatyti, kur užtikrinama autorizacija.
• Konfigūracijos patikrinimas gali nustatyti paslaugų teises ir saugyklų atvirumą.
• Neigiami integracijos testai gali patikrinti tarpnuomininkines ir privilegijų ribas.
• Apkrovos ir gedimų įterpimo testai gali ištirti prieinamumą ir elgseną gedimų atveju.
• Tikslinis įsiskverbimo testavimas gali ištirti atakų kelius, kuriems reikia nepriklausomo tyrimo.

Joks pavienis artefaktas neįrodo viso modelio. Nustatymo ekrano nuotrauka neįrodo, kad jį naudoja kiekvienas darbinis procesas, o sėkmingas testas neįrodo neišbandyto kelio. Užfiksuokite testavimo aplinką, apimtį, rezultatus ir apribojimus.

Grėsmių modeliavimas papildo saugų programavimą, priklausomybių vertinimą, pažeidžiamumų skenavimą ir įsiskverbimo testavimą. Jo išskirtinis indėlis – architektūrinis mąstymas: jis gali atskleisti pavojingą įgaliojimų paskirstymą net tada, kai atskiri komponentai neturi žinomų pažeidžiamumų.

Įrankiai ir automatizavimas turi tarnauti modeliui

Bendra diagrama ir struktūrizuotas registras gali padėti atlikti tikslingą pirmąją peržiūrą. Specializuoti įrankiai tampa naudingi, kai komandoms reikia pakartotinai naudojamų komponentų bibliotekų, nuoseklių identifikatorių, bendradarbiavimo ir patikimų ryšių tarp grėsmių ir įgyvendinimo įrašų.

Įvertinkite, ar įrankis palaiko pasitikėjimo ribas, pasirinktinius scenarijus, versijų istoriją, eksportuojamus įrašus, atsakomybę ir nuorodas į įrodymus. Automatiškai sugeneruotos grėsmės yra paskata nagrinėti, o ne patvirtinti radiniai. Ilgi sąrašai be konteksto gali paslėpti tuos kelis sprendimus, kurie iš tikrųjų svarbūs.

DI pagalba gali parengti scenarijų aprašymų juodraščius, pasiūlyti trūkstamus kelius ar palyginti pokyčius su ankstesniu modeliu. Žmonės peržiūrėtojai vis tiek turi patvirtinti architektūrą, įgyvendinamumą, rizikos mažinimo priemonių aprėptį ir likutinę riziką. Konfidencialių diagramų ir kredencialų nekelkite į nepatvirtintas paslaugas. Grėsmių modelio generavimas taip pat skiriasi nuo aptikimo vykdymo metu; modelio sukūrimas neužtikrina nuolatinės stebėsenos ar automatinio taisymo.

Peržiūrėkite, kai pasikeičia architektūra ar prielaidos

Atnaujinkite modelį, kai atsiranda naujų integracijų, autentifikavimo pokyčių, privilegijuotų veiksmų, duomenų kategorijų, tinklo atvirumo ir didelių priklausomybių pokyčių. Incidentas ar netikėtas testo rezultatas taip pat gali paneigti ankstesnę prielaidą.

Skirtingoms sistemoms reikia skirtingo dėmesio. Debesijos taikomosiose programose reikia atkreipti dėmesį į tapatybių teises ir prieigą prie valdymo plokštumos. Mobilieji klientai turėtų būti laikomi užpuoliko kontroliuojama aplinka, o ne patikimais kontrolės užtikrinimo taškais. Prijungti įrenginiai sukelia fizinės prieigos, atnaujinimų vientisumo, atkūrimo ir galimų saugos pasekmių klausimų. DI funkcijos prideda nepatikimo turinio ir įrankių naudojimo ribas; autorizacija turi riboti veiksmus nepriklausomai nuo modelio išvesties.

Matuokite, ar svarbiems srautams yra aktualūs modeliai, ar aukšto prioriteto rizikos valdymo priemonės turi patikrinimo įrodymus, ar prielaidos lieka neišspręstos ir ar priimtų rizikų peržiūros vėluoja. Vien grėsmių skaičiavimas skatina kiekybę, o ne naudingą analizę. Periodiškai paprašykite nepriklausomo peržiūrėtojo kritiškai įvertinti vieną kritinį scenarijų ir jo įrodymus.

Pirmąją peržiūrą padarykite pakankamai mažą, kad ją užbaigtumėte

Secani gali išsaugoti šių sprendimų darbo eigą: sumodeliuoti atitinkamas sistemas ir priklausomybes, paskirti atsakingus asmenis ir peržiūrėtojus ir susieti įrodymus su reikalavimais, kontrolės priemonėmis ir sprendimais. Neišspręstos prielaidos tampa užduotimis; šaltinių medžiaga ir žmonių patvirtinimai lieka pridėti prie peržiūros. Bet kokie DI pasiūlymai turėtų būti patikrinti prieš patvirtinimą.

Pradėkite nuo vieno kritinio duomenų srauto. Atsekite jo įgaliojimus nuo pradžios iki galo, nustatykite kelis tikėtinus scenarijus ir užbaikite rizikos valdymo priemonėmis su atsakingais asmenimis bei aiškiais patikrinimo kriterijais. Kitą peržiūrą suplanuokite atsižvelgdami į architektūros pokyčius, kurie galėtų paneigti šiuos sprendimus.