Draudu modelēšana: pārvērtiet arhitektūru drošības lēmumos

Draudu modelēšana jautā, kas konkrētā sistēmā varētu noiet greizi un kas komandai būtu jādara šajā sakarā. Tās noderīgais rezultāts nav biedējošu iespēju katalogs. Tas ir ar arhitektūru saistītu dizaina un ieviešanas lēmumu kopums ar īpašniekiem un pierādījumiem, ka izvēlētās aizsardzības darbojas.

CTO galvenais jautājums ir, vai inženieri spēj izskaidrot, kā svarīgas drošības īpašības saglabājas reālas sistēmas uzvedības apstākļos: atkārtojumos, fona uzdevumos, priviliģētās atbalsta darbībās, piegādātāju dīkstāvēs un ļaunprātīgā ievadē. Diagramma padara šīs sarunas konkrētas. Uzturēts draudu modelis pārvērš secinājumus izstrādes darbā.

OWASP draudu modelēšanas vadlīnijas sniedz noderīgu pamatu: izprast sistēmu, identificēt draudus, izlemt, kā reaģēt, un novērtēt, vai darbs ir pietiekams. Turpmāk aprakstītā darbplūsma piemēro šo domāšanu inženierijas lēmumiem.

Aprakstiet sistēmu, pirms apspriežat uzbrukumus

Sāciet ar ierobežotu funkcionalitāti, piemēram, klientu eksportiem, maksājumu iniciēšanu vai ierīču atjauninājumiem. Visas platformas modelēšana uzreiz bieži dod virspusējus novērojumus, jo neviens nespēj pietiekami detalizēti izskaidrot katru atkarību.

Formulējiet aktīvus un drošības mērķus darbības terminos. „Aizsargāt klientu datus” ir pārāk plaši. „Autentificēts lietotājs var eksportēt tikai ierakstus, kas pieder viņa autorizētajam nomniekam” sniedz komandai pārbaudāmu īpašību. Citi mērķi var attiekties uz darījumu integritāti, pakalpojuma pieejamību, atjaunošanu vai administratīvo darbību attiecināmību.

Identificējiet lietotājus, pakalpojumus, datu krātuves, ārējās atkarības, ieejas punktus un uzticēšanās robežas. Uzzīmējiet svarīgās datu plūsmas, ieskaitot asinhrono apstrādi un administratīvos ceļus. Marķējiet plūsmas ar pārsūtītajiem datiem, autentifikācijas mehānismu un autorizācijas kontekstu, ja tie ietekmē analīzi.

Uzticēšanās robeža iezīmē pieņēmumu vai pilnvaru maiņu, ne obligāti tīkla perimetru. Pārlūks, kas izsauc API, šķērso vienu robežu. Kopīgs apstrādes process, kas darbojas klienta vārdā, šķērso citu, pat ja abi pakalpojumi darbojas vienā klasterī.

Vairāku nomnieku lietotnei parādiet, kur tiek noteikta nomnieka identitāte un kā tā sasniedz autorizācijas pārbaudes, fona uzdevumus un eksportus. Iekļaujiet servisu identitātes, piekļuvi objektu krātuvei, atbalsta rīkus un ārējos atzvanus. Citādi diagramma var aprakstīt ideālo ceļu, izlaižot tieši tos ceļus, kas visticamāk apies izolāciju.

Dokumentējiet pieņēmumus atsevišķi no faktiem. „Klienti nevar rakstīt rindā” prasa pamatojošus konfigurācijas pierādījumus. Nezināmajiem jākļūst par izpētes uzdevumiem, nevis klusi pieņemtām aizsardzībām.

Izvēlieties metodi, kas palīdz komandai spriest

Metode sniedz uzvednes un struktūru. Tā nenosaka, kuri draudi ir vissvarīgākie, nepierāda, ka dizains ir drošs, un neaizstāj zināšanas par sistēmu.

STRIDE sistemātiskām uzvednēm

STRIDE izskata sešas kategorijas. Piemērojiet tās attiecīgajiem komponentiem, plūsmām un robežām, nevis piespiediet katru kategoriju katram diagrammas elementam.

Viens scenārijs var aptvert vairākas kategorijas. Kur piemēroti, uzturiet vienu rīcībai noderīgu ierakstu, nevis veidojiet dublētus pieteikumus taksonomijas apmierināšanai.

Citas metodes citiem jautājumiem

PASTA (Process for Attack Simulation and Threat Analysis) piedāvā septiņu posmu, uz risku orientētu pieeju, kas savieno biznesa mērķus, tehnisko tvērumu, dekompozīciju, draudu un ievainojamību analīzi, uzbrukumu modelēšanu un riska apstrādi. Tā ir piemērota padziļinātai analīzei, kur skaidra uzmanība jāpievērš uzbrucēja uzvedībai un biznesa sekām.

Uzbrukumu koki sākas ar uzbrucēja mērķi un sadala to alternatīvos vai kombinētos ceļos. Mērķim „iegūt cita nomnieka eksportu” alternatīvas varētu ietvert API autorizācijas apiešanu, apstrādes procesa nomnieka konteksta sajaukšanu vai lejupielādes pilnvaras nozagšanu. UN attiecības attēlo nosacījumus, kuriem jāiestājas vienlaikus; VAI attiecības attēlo alternatīvas.

VAST (Visual, Agile, and Simple Threat modeling) uzsver mērogojamu modelēšanu gan lietotņu, gan darbības perspektīvā. Komandām, kas to apsver, jāizvērtē, vai to rīki un izstrādes process spēj konsekventi uzturēt šos skatus.

Praktisks sākuma ieteikums ir datu plūsmas diagramma kopā ar STRIDE, kam seko uzbrukumu koks visnozīmīgākajam scenārijam. Vairāk metodoloģijas ir noderīgi tikai tad, ja tā uzlabo lēmumus.

Veidojiet pārskatu ap konkrētiem scenārijiem

Piesaistiet cilvēkus, kas izprot ieviešanu un darbību: izstrādātāju, arhitektu vai tehnisko vadītāju, drošības pārskatītāju un kādu, kas pārzina ražošanas vides uzvedību. Iekļaujiet produkta, privātuma vai piegādātāju speciālistus, ja viņu zināšanas ietekmē tvērumu.

Pirms sesijas izsūtiet diagrammu, drošības mērķus, attiecīgo konfigurāciju un neatrisinātos pieņēmumus. Pārskata laikā izejiet cauri vienam pieprasījumam vai notikumam no ieejas līdz pabeigšanai. Jautājiet, kur mainās identitāte, kur dati tiek saglabāti, kas tiek atkārtots un kuram komponentam ir pilnvaras apstiprināt darbību.

Rakstiet draudus kā scenārijus, nevis apzīmējumus. „Autorizācijas problēma” nav pietiekami noderīgs formulējums. Spēcīgāks apgalvojums ir: „Autentificēts lietotājs aizstāj cita nomnieka eksporta identifikatoru; lejupielādes galapunkts pārbauda pieteikšanos, bet ne objekta piederību, atklājot klientu ierakstus.”

Nošķiriet trīs jēdzienus:

• Draudi apraksta nelabvēlīgu darbību vai notikumu, piemēram, nesankcionētu eksporta izgūšanu.
• Ievainojamība ir vājums, kas to varētu iespējot, piemēram, trūkstoša piederības pārbaude.
• Risks ņem vērā scenārija iespējamību un sekas faktiskajā vidē.

Draudus var būt vērts izpētīt, pirms ievainojamība ir apstiprināta. Tāpat vājuma atrašana nepierāda, ka katrs iedomājams uzbrukums ir īstenojams.

Līdztekus ārējiem uzbrukumiem iekļaujiet leģitīmu lietotāju ļaunprātīgu izmantošanu, priviliģētus iekšējos dalībniekus, konfigurācijas kļūdas un piegādātāju kļūmes. Jautājiet, kas notiek, ja atkarībai iestājas noildze vai tā atgriež negaidītu atbildi. Šajās diskusijās bieži atklājas uzvedība, kas kļūmes gadījumā atver piekļuvi (fail-open), un nekonsekventi atkārtojumi.

Piemērs: vairāku nomnieku eksporta konveijers

Šis piemērs ir ilustratīvs. Pieņemsim, ka SaaS lietotnei ir pārlūka klients, API, kopīga datubāze, uzdevumu rinda, eksporta apstrādes process un objektu krātuve. Nomnieku lietotāji pieprasa CSV eksportus; apstrādes process ģenerē failus, un API izsniedz pagaidu lejupielādes saites. Atbalsta administratoriem ir atsevišķa problēmu novēršanas saskarne.

Drošības mērķi ir nomnieku izolācija, autorizēta eksporta iniciēšana, ierobežots resursu patēriņš un attiecināmas atbalsta darbības. Pieņemsim, ka apstrādes procesam ir pietiekami plaša datubāzes piekļuve, lai apkalpotu vairākus nomniekus. Tas padara nomnieka konteksta apstrādi par centrālu lēmumu, nevis mazsvarīgu ieviešanas detaļu.

Izsekojiet pilnvarām cauri plūsmai

API līmenī autentificētais subjekts tiek saistīts ar atļauto dalību nomniekā. Pārlūka sniegtais nomnieka identifikators ir izvēles pieprasījums, nevis autorizācijas pierādījums. API pārbauda dalību un eksporta atļauju, pirms izveido nemainīgu uzdevuma ierakstu, kas satur autorizēto nomnieku, pieprasītāju un atļauto eksporta tvērumu.

Rindas ziņojums atsaucas uz šo ierakstu. Apstrādes process validē uzdevumu un, veidojot eksportu, īsteno nomniekam ierobežotu piekļuvi datiem. Krātuves metadati sasaista iegūto objektu ar uzdevumu un nomnieku. Pirms lejupielādes saites izsniegšanas API pārbauda pašreizējā pieprasītāja autorizāciju attiecībā pret šo sasaisti.

Šim dizainam joprojām nepieciešami skaidri lēmumi par piekļuves atsaukšanu: vai lietotājam, kurš zaudē dalību pēc eksporta pieprasīšanas, jāsaglabā piekļuve pabeigtajam failam? Komandai jādefinē šī politika un tā jāievieš konsekventi.

Pārvērtiet scenārijus kontrolēs un testos

Pagaidu saites rada atlikušā riska logu: atkarībā no mehānisma to valdījums var ļaut piekļūt līdz derīguma beigām. Komandai jāizlemj, vai tas ir pieņemami attiecīgajiem datiem, vai lejupielādēm nepieciešams autentificēts starpnieks ar aktuālām autorizācijas pārbaudēm.

Neslēdziet modeli pēc tam, kad pārbaudīts tikai sinhronais API. Pārbaudiet aizkavētus uzdevumus, atkārtojumus, atceltus pieprasījumus, beigušos dalību, dzēstus nomniekus un daļējas kļūmes. Piemēram, atkārtotam uzdevumam nedrīkst atkārtoti izmantot objektu, kas saistīts ar citu nomnieku, vai publicēt nepabeigtu eksportu kā veiksmīgu.

Iegūtais rezultāts ir pārskatīta arhitektūra, draudu reģistrs, ieviešanas uzdevumi un saistīti verifikācijas rezultāti. Tā nav tikai diagramma.

Prioritizējiet, izmantojot iedarbību un sekas

Prioritizējiet ticamus scenārijus, izmantojot iedarbību, ietekmi, priekšnoteikumus un esošās aizsardzības. Nošķiriet tieši sasniedzamu autorizācijas kļūmi no scenārija, kam nepieciešami vairāki nepierādīti kompromitējumi. Ja attiecināms, ņemiet vērā skartos datus, pakalpojuma traucējumus, finansiālās sekas, ietekmi uz funkcionālo drošumu un atjaunošanas grūtības.

Izmantojiet vienkāršu, konsekventu skalu, ja tā palīdz komandai, taču dokumentējiet vērtējuma pamatojumu. Skaitlisks vērtējums ar neizskaidrotiem ievaddatiem rada mākslīgu precizitāti. CVSS var palīdzēt novērtēt konkrētu ievainojamību; tas neaizstāj biznesa ietekmes vai arhitektūras ļaunprātīgas izmantošanas gadījuma izpratni.

Apstrādes izvēles ietver dizaina maiņu, iedarbības samazināšanu, preventīvu vai atklājošu kontroļu pievienošanu, funkcionalitātes atteikšanos vai atlikušā riska pieņemšanu. Piegādātāju līgumi var sadalīt pienākumus, taču tie nenovērš tehniskos kļūmju veidus.

Atlikušajam riskam jābūt ar nosauktu lēmumu pieņēmēju, iemeslu, derīguma termiņu vai pārskatīšanas ierosinātāju un jebkādiem darbības nosacījumiem. Inženierijas darba pabeigšana un riska pieņemšana ir atšķirīgi lēmumi. Pieteikums var būt pabeigts, kamēr būtisks risks saglabājas.

Pārnesiet modeli izstrādē un pierādījumos

Katram būtiskam scenārijam dokumentējiet tā identifikatoru, skartos komponentus, priekšnoteikumus, sekas, esošās aizsardzības, apstrādi, īpašnieku un verifikācijas metodi. Sasaistiet ierakstu ar arhitektūras versiju un attiecīgo ieviešanas darbu, lai pārskatītāji varētu noteikt, kurš dizains tika novērtēts.

Pārvērtiet apstrādes pārbaudāmos pieņemšanas kritērijos. „Uzlabot piekļuves kontroli” ir neskaidri. „A nomnieks nevar pieprasīt, aptaujāt, atcelt vai lejupielādēt B nomnieka eksportu caur nevienu atbalstītu galapunktu” identificē uzvedību, ko inženieri var pārbaudīt.

Izmantojiet apgalvojumam atbilstošus pierādījumus:

• Koda pārskatīšana var noteikt, kur tiek īstenota autorizācija.
• Konfigurācijas pārbaude var noteikt servisu atļaujas un krātuves pieejamību.
• Negatīvi integrācijas testi var pārbaudīt starpnomnieku un privilēģiju robežas.
• Slodzes un kļūmju injicēšanas testi var izvērtēt pieejamību un uzvedību kļūmju gadījumā.
• Mērķtiecīga ielaušanās testēšana var izpētīt uzbrukuma ceļus, kam nepieciešama neatkarīga izpēte.

Neviens atsevišķs artefakts nepierāda visu modeli. Iestatījuma ekrānuzņēmums nepierāda, ka katrs apstrādes process to izmanto, un veiksmīgs tests nepierāda nepārbaudītu ceļu. Dokumentējiet testa vidi, tvērumu, rezultātus un ierobežojumus.

Draudu modelēšana papildina drošu programmēšanu, atkarību novērtēšanu, ievainojamību skenēšanu un ielaušanās testēšanu. Tās īpašais ieguldījums ir arhitektūras spriešana: tā var atklāt bīstamu pilnvaru sadalījumu pat tad, ja atsevišķiem komponentiem nav zināmu ievainojamību.

Turiet rīkus un automatizāciju pakārtotus modelim

Kopīga diagramma un strukturēts reģistrs var atbalstīt fokusētu pirmo pārskatu. Specializēti rīki kļūst noderīgi, kad komandām nepieciešamas atkārtoti izmantojamas komponentu bibliotēkas, konsekventi identifikatori, sadarbība un uzticamas saites starp draudiem un izstrādes ierakstiem.

Izvērtējiet, vai rīks atbalsta uzticēšanās robežas, pielāgotus scenārijus, versiju vēsturi, eksportējamus ierakstus, īpašumtiesības un atsauces uz pierādījumiem. Automātiski ģenerēti draudi ir uzvednes izpētei, nevis apstiprināti konstatējumi. Gari saraksti bez konteksta var noslēpt tos dažus lēmumus, kas patiešām ir svarīgi.

MI atbalsts var sagatavot scenāriju aprakstu melnrakstus, ieteikt trūkstošus ceļus vai salīdzināt izmaiņas ar agrāku modeli. Cilvēkiem pārskatītājiem joprojām jāvalidē arhitektūra, īstenojamība, mazināšanas pasākumu pārklājums un atlikušais risks. Neļaujiet konfidenciālām diagrammām un piekļuves datiem nonākt neapstiprinātos pakalpojumos. Draudu modeļu ģenerēšana arī atšķiras no izpildlaika atklāšanas; modeļa izveide nenodrošina nepārtrauktu uzraudzību vai automatizētu novēršanu.

Pārskatiet, kad mainās arhitektūra vai pieņēmumi

Atjauniniet modeli jaunu integrāciju, autentifikācijas izmaiņu, priviliģētu darbību, datu kategoriju, tīkla pieejamības un būtisku atkarību izmaiņu gadījumā. Incidents vai negaidīts testa rezultāts arī var padarīt nederīgu agrāku pieņēmumu.

Dažādām sistēmām nepieciešami dažādi uzsvari. Mākoņlietotnēm nepieciešama uzmanība identitāšu atļaujām un piekļuvei pārvaldības plaknei. Mobilie klienti jāuzskata par uzbrucēja kontrolētām vidēm, nevis uzticamiem īstenošanas punktiem. Pieslēgtās ierīces ievieš fizisku piekļuvi, atjauninājumu integritāti, atjaunošanu un, iespējams, sekas funkcionālajam drošumam. MI iespējotas funkcijas pievieno neuzticamu saturu un rīku izmantošanas robežas; autorizācijai jāierobežo darbības neatkarīgi no modeļa izvades.

Mēriet, vai svarīgām plūsmām ir aktuāli modeļi, vai augstas prioritātes apstrādēm ir verifikācijas pierādījumi, vai pieņēmumi paliek neatrisināti un vai pieņemtajiem riskiem ir nokavētas pārskatīšanas. Tikai draudu skaitīšana atalgo apjomu, nevis noderīgu analīzi. Periodiski lūdziet neatkarīgam pārskatītājam apstrīdēt vienu kritisku scenāriju un tā pierādījumus.

Padariet pirmo pārskatu pietiekami mazu, lai to pabeigtu

Secani var saglabāt darbplūsmu ap šiem lēmumiem, modelējot attiecīgās sistēmas un atkarības, piešķirot īpašniekus un pārskatītājus un savienojot pierādījumus ar prasībām, kontrolēm un lēmumiem. Neatrisināti pieņēmumi kļūst par uzdevumiem; avota materiāli un cilvēku apstiprinājumi paliek piesaistīti pārskatam. Jebkuri MI atbalstīti ieteikumi jāpārbauda pirms apstiprināšanas.

Sāciet ar vienu kritisku datu plūsmu. Izsekojiet tās pilnvarām no sākuma līdz beigām, identificējiet nedaudzus ticamus scenārijus un noslēdziet ar apstrādēm, kurām ir īpašnieki, un skaidriem verifikācijas kritērijiem. Ieplānojiet nākamo pārskatu ap arhitektūras izmaiņām, kas varētu padarīt šos lēmumus nederīgus.