Ohumodelleerimine: muutke arhitektuur turvaotsusteks

Ohumodelleerimine küsib, mis võib konkreetses süsteemis valesti minna ja mida meeskond peaks sellega ette võtma. Selle kasulik väljund ei ole hirmutavate võimaluste kataloog. See on arhitektuuriga seotud disaini- ja rakendusotsuste kogum, millel on omanikud ja tõendid selle kohta, et valitud kaitsemeetmed toimivad.

Tehnikajuhi jaoks on keskne küsimus, kas arendus suudab selgitada, kuidas olulised turvaomadused püsivad süsteemi tegeliku käitumise korral: korduskatsed, taustatööd, privilegeeritud klienditoe toimingud, tarnijate katkestused ja pahatahtlik sisend. Diagramm muudab need arutelud konkreetseks. Hooldatud ohumudel muudab järeldused elluviidavaks tööks.

OWASP-i ohumodelleerimise juhis annab kasuliku aluse: mõista süsteemi, tuvastada ohud, otsustada, kuidas reageerida, ja hinnata, kas tehtud töö on piisav. Allpool kirjeldatud töövoog rakendab seda mõtteviisi arendusotsustele.

Kirjeldage süsteemi enne rünnakute arutamist

Alustage piiritletud võimekusest, näiteks kliendiandmete ekspordist, maksete algatamisest või seadmete uuendamisest. Kogu platvormi korraga modelleerimine annab sageli pinnapealseid tähelepanekuid, sest keegi ei suuda iga sõltuvust piisavalt üksikasjalikult selgitada.

Sõnastage varad ja turvaeesmärgid tegevuslikult. „Kaitsta kliendiandmeid“ on liiga lai. „Autenditud kasutaja saab eksportida ainult oma volitatud kliendikeskkonnale kuuluvaid kirjeid“ annab meeskonnale testitava omaduse. Muud eesmärgid võivad puudutada tehingute terviklikkust, teenuse käideldavust, taastamist või haldustoimingute omistatavust.

Tuvastage kasutajad, teenused, andmehoidlad, välised sõltuvused, sisenemispunktid ja usalduspiirid. Joonistage olulised andmevood, sealhulgas asünkroonne töötlemine ja haldusteed. Märkige voogudele edastatavad andmed, autentimismehhanism ja autoriseerimiskontekst, kui need analüüsi mõjutavad.

Usalduspiir tähistab eelduste või volituste muutust, mitte tingimata võrgu perimeetrit. Brauser, mis kutsub välja API, ületab ühe piiri. Ühiskasutatav taustaprotsess, mis tegutseb kliendi nimel, ületab teise, isegi kui mõlemad teenused töötavad samas klastris.

Mitme kliendikeskkonnaga rakenduse puhul näidake, kus kliendikeskkonna identiteet määratakse ja kuidas see jõuab autoriseerimiskontrollide, taustatööde ja eksportideni. Kaasake teenuseidentiteedid, juurdepääs objektihoidlale, klienditoe tööriistad ja välised tagasikutsed. Muidu võib diagramm kirjeldada ideaalset teed, jättes välja need teed, mis kõige tõenäolisemalt isolatsioonist mööda lähevad.

Dokumenteerige eeldused faktidest eraldi. „Kliendid ei saa järjekorda kirjutada“ vajab toetavat konfiguratsioonitõendit. Teadmata asjadest peaksid saama uurimisülesanded, mitte vaikimisi aktsepteeritud kaitsemeetmed.

Valige meetod, mis aitab meeskonnal arutleda

Meetod annab suunavaid küsimusi ja struktuuri. See ei määra, millised ohud on kõige olulisemad, ei tõenda disaini turvalisust ega asenda süsteemi tundmist.

STRIDE süstemaatiliste küsimuste jaoks

STRIDE uurib kuut kategooriat. Rakendage neid asjaomastele komponentidele, voogudele ja piiridele, selle asemel et suruda iga kategooria igale diagrammi elemendile.

Üks stsenaarium võib hõlmata mitut kategooriat. Pidage vajaduse korral üht tegutsemist võimaldavat kirjet, selle asemel et luua taksonoomia rahuldamiseks dubleerivaid pileteid.

Muud meetodid muude küsimuste jaoks

PASTA (Process for Attack Simulation and Threat Analysis) pakub seitsmeetapilist riskikeskset lähenemisviisi, mis seob ärilised eesmärgid, tehnilise ulatuse, süsteemi lahtimõtestamise, ohtude ja haavatavuste analüüsi, rünnakute modelleerimise ja riskikäsitluse. See sobib põhjalikumaks analüüsiks, kus ründaja käitumine ja ärilised tagajärjed vajavad selgesõnalist tähelepanu.

Ründepuud algavad ründaja eesmärgist ja jaotavad selle alternatiivseteks või kombineeritud teedeks. Eesmärgi „saada kätte teise kliendikeskkonna eksport“ alternatiivid võivad olla API autoriseerimisest möödahiilimine, taustaprotsessi kliendikeskkonna konteksti segiajamine või allalaadimisvolituse varastamine. JA-seosed tähistavad tingimusi, mis peavad esinema koos; VÕI-seosed tähistavad alternatiive.

VAST (Visual, Agile, and Simple Threat modeling) rõhutab skaleeruvat modelleerimist nii rakenduse kui ka käituse vaatenurgast. Seda kaaluvad meeskonnad peaksid uurima, kas nende tööriistad ja arendusprotsess suudavad neid vaateid järjepidevalt hooldada.

Praktiline lähtesoovitus on andmevoodiagramm koos STRIDE’iga, millele järgneb kõige tagajärjerikkama stsenaariumi ründepuu. Rohkem metoodikat on kasulik ainult siis, kui see parandab otsuseid.

Viige ülevaatus läbi konkreetsete stsenaariumide ümber

Kaasake inimesed, kes mõistavad rakendust ja käitust: arendaja, arhitekt või tehniline juht, turvaülevaataja ja keegi, kes tunneb tootmiskeskkonna käitumist. Kaasake toote-, privaatsus- või tarnijaspetsialiste, kui nende teadmised mõjutavad ulatust.

Saatke enne kohtumist laiali diagramm, turvaeesmärgid, asjakohane konfiguratsioon ja lahendamata eeldused. Ülevaatuse ajal käige üks päring või sündmus läbi sisenemisest lõpetamiseni. Küsige, kus identiteet muutub, kus andmed püsivad, mida korratakse ja millisel komponendil on volitus toimingut heaks kiita.

Kirjutage ohud stsenaariumidena, mitte siltidena. „Autoriseerimisprobleem“ ei ole piisavalt kasulik. Tugevam väide on: „Autenditud kasutaja asendab teise kliendikeskkonna ekspordi identifikaatori; allalaadimise lõpp-punkt kontrollib sisselogimist, kuid mitte objekti omandiõigust, mis paljastab kliendiandmed.“

Eristage kolme mõistet.

• Oht kirjeldab kahjulikku tegevust või sündmust, näiteks volitamata ekspordi kättesaamist.
• Haavatavus on nõrkus, mis võiks seda võimaldada, näiteks puuduv omandiõiguse kontroll.
• Risk arvestab stsenaariumi tõenäosust ja tagajärge tegelikus keskkonnas.

Ohtu võib tasuda uurida enne, kui haavatavus on kinnitatud. Samamoodi ei tõenda nõrkuse leidmine, et iga mõeldav rünnak on teostatav.

Kaasake väliste rünnakute kõrval õiguspäraste kasutajate väärkasutus, privilegeeritud siseringi isikud, konfiguratsioonivead ja tarnijate tõrked. Küsige, mis juhtub, kui sõltuvus aegub või tagastab ootamatu vastuse. Neist aruteludest kerkivad sageli esile avatud olekusse jäävad tõrked (fail-open) ja ebajärjekindlad korduskatsed.

Näide: mitme kliendikeskkonnaga ekspordiahel

Järgmine näide on illustreeriv. Oletame, et SaaS-rakendusel on brauserklient, API, jagatud andmebaas, tööjärjekord, eksporditöötleja ja objektihoidla. Kliendikeskkondade kasutajad taotlevad CSV-eksporte; töötleja loob failid ja API väljastab ajutised allalaadimislingid. Klienditoe administraatoritel on eraldi tõrkeotsingu liides.

Turvaeesmärgid on kliendikeskkondade isolatsioon, volitatud ekspordi algatamine, piiratud ressursikasutus ja omistatavad klienditoe toimingud. Oletame, et töötlejal on andmebaasile piisavalt lai juurdepääs, et teenindada mitut kliendikeskkonda. See muudab kliendikeskkonna konteksti käsitlemise keskseks otsuseks, mitte väikeseks rakendusdetailiks.

Jälgige volitusi läbi voo

API-s seotakse autenditud subjekt lubatud kliendikeskkonna liikmesusega. Brauseri esitatud kliendikeskkonna identifikaator on valikutaotlus, mitte autoriseerimise tõend. API kontrollib liikmesust ja ekspordiõigust enne, kui loob muutumatu töökirje, mis sisaldab volitatud kliendikeskkonda, taotlejat ja lubatud ekspordiulatust.

Järjekorrasõnum viitab sellele kirjele. Töötleja valideerib töö ja jõustab ekspordi koostamisel kliendikeskkonna põhise andmetele juurdepääsu. Talletuse metaandmed seovad saadud objekti töö ja kliendikeskkonnaga. Enne allalaadimislingi väljastamist kontrollib API praeguse taotleja autoriseerimist selle seose alusel.

See disain vajab endiselt selgesõnalisi otsuseid juurdepääsu tühistamise kohta: kas kasutaja, kes kaotab liikmesuse pärast ekspordi taotlemist, peaks säilitama juurdepääsu valminud failile? Meeskond peab selle põhimõtte määratlema ja järjepidevalt rakendama.

Muutke stsenaariumid kontrollimeetmeteks ja testideks

Ajutised lingid tekitavad allesjääva riskiakna: olenevalt mehhanismist võib lingi valdamine võimaldada juurdepääsu kuni aegumiseni. Meeskond peaks otsustama, kas see on asjaomaste andmete puhul vastuvõetav või vajavad allalaadimised autenditud vahendajat, mis kontrollib ajakohast autoriseerimist.

Ärge sulgege mudelit pärast ainult sünkroonse API testimist. Kontrollige edasilükatud töid, korduskatseid, tühistatud päringuid, aegunud liikmesust, kustutatud kliendikeskkondi ja osalisi tõrkeid. Näiteks ei tohi korduskatse kasutada uuesti teise kliendikeskkonnaga seotud objekti ega avaldada poolikut eksporti edukana.

Tulemuseks on ülevaadatud arhitektuur, ohuregister, rakendusülesanded ja lingitud kontrollitulemused. See ei ole pelgalt diagramm.

Prioriseerige avatuse ja tagajärgede järgi

Prioriseerige usutavaid stsenaariume avatuse, mõju, eeltingimuste ja olemasolevate kaitsemeetmete alusel. Eristage otse ligipääsetavat autoriseerimisviga stsenaariumist, mis nõuab mitut tõendamata kompromiteerimist. Arvestage asjakohastel juhtudel mõjutatud andmeid, teenuse katkestust, rahalisi tagajärgi, ohutusmõjusid ja taastamise keerukust.

Kasutage lihtsat järjepidevat skaalat, kui see meeskonda aitab, kuid dokumenteerige hinnangu põhjendus. Selgitamata sisenditega numbriline skoor loob näilise täpsuse. CVSS võib aidata hinnata konkreetset haavatavust; see ei asenda ärilise mõju ega arhitektuurse väärkasutusjuhu mõistmist.

Käsitlusvalikud on disaini muutmine, avatuse vähendamine, ennetavate või avastavate kontrollimeetmete lisamine, võimekusest loobumine või allesjääva riski aktsepteerimine. Tarnijalepingud võivad vastutust jaotada, kuid ei kõrvalda tehnilisi tõrkeviise.

Jääkriskil peaks olema nimeliselt määratud otsustaja, põhjendus, aegumis- või ülevaatusajend ja vajaduse korral toimimistingimused. Arendustöö lõpetamine ja riski aktsepteerimine on erinevad otsused. Pilet võib olla lõpetatud, samal ajal kui oluline risk jääb alles.

Viige mudel elluviimisse ja tõenditesse

Iga olulise stsenaariumi puhul dokumenteerige selle identifikaator, mõjutatud komponendid, eeltingimused, tagajärg, olemasolevad kaitsemeetmed, käsitlus, omanik ja kontrollimeetod. Siduge kirje arhitektuuri versiooni ja asjaomase rakendustööga, et ülevaatajad saaksid aru, millist disaini hinnati.

Muutke käsitlused testitavateks vastuvõtukriteeriumideks. „Parandada juurdepääsukontrolli“ on ebamäärane. „Kliendikeskkond A ei saa ühegi toetatud lõpp-punkti kaudu taotleda, pärida, tühistada ega alla laadida kliendikeskkonna B eksporti“ määratleb käitumise, mida arendus saab kontrollida.

Kasutage väitele sobivaid tõendeid.

• Koodiülevaatus saab näidata, kus autoriseerimist jõustatakse.
• Konfiguratsiooni kontroll saab näidata teenuseõigusi ja talletuse avatust.
• Negatiivsed integratsioonitestid saavad läbi proovida kliendikeskkondade ja õiguste piire.
• Koormus- ja tõrkesüstimise testid saavad uurida käideldavust ja tõrkekäitumist.
• Sihitud läbistustestimine saab uurida ründeteid, mis vajavad sõltumatut uurimist.

Ükski üksik artefakt ei tõenda kogu mudelit. Seadistuse ekraanipilt ei tõenda, et iga töötleja seda kasutab, ja läbitud test ei näita testimata teed. Dokumenteerige testkeskkond, ulatus, tulemused ja piirangud.

Ohumodelleerimine täiendab turvalist programmeerimist, sõltuvuste hindamist, haavatavuste skannimist ja läbistustestimist. Selle eripärane panus on arhitektuurne arutlus: see võib paljastada ohtliku volituste jaotuse ka siis, kui üksikutel komponentidel pole ühtegi teadaolevat haavatavust.

Hoidke tööriistad ja automatiseerimine mudelile allutatuna

Jagatud diagramm ja struktureeritud register võivad toetada keskendunud esimest ülevaatust. Spetsiaalsed tööriistad muutuvad kasulikuks, kui meeskonnad vajavad taaskasutatavaid komponenditeeke, järjepidevaid identifikaatoreid, koostööd ning usaldusväärseid seoseid ohtude ja elluviimiskirjete vahel.

Hinnake, kas tööriist toetab usalduspiire, kohandatud stsenaariume, versiooniajalugu, eksporditavaid kirjeid, omanikke ja tõenditele viitamist. Automaatselt genereeritud ohud on uurimist vajavad vihjed, mitte kinnitatud leiud. Pikad loendid ilma kontekstita võivad peita need vähesed otsused, millel on tähtsust.

Tehisintellekti abi võib koostada stsenaariumide kirjelduste mustandeid, soovitada puuduvaid teid või võrrelda muudatusi varasema mudeliga. Inimülevaatajad peavad siiski valideerima arhitektuuri, teostatavuse, leevendusmeetmete katvuse ja jääkriski. Hoidke konfidentsiaalsed diagrammid ja juurdepääsuandmed heakskiitmata teenustest eemal. Ohumudeli genereerimine erineb ka käitusaegsest avastamisest; mudeli loomine ei taga pidevat seiret ega automatiseeritud parandamist.

Vaadake üle, kui arhitektuur või eeldused muutuvad

Ajakohastage mudelit uute integratsioonide, autentimismuudatuste, privilegeeritud toimingute, andmekategooriate, võrgu avatuse ja oluliste sõltuvusmuudatuste korral. Ka intsident või ootamatu testitulemus võib varasema eelduse kehtetuks muuta.

Eri süsteemid vajavad erinevat rõhuasetust. Pilverakendused nõuavad tähelepanu identiteediõigustele ja halduskihi juurdepääsule. Mobiilikliente tuleks käsitleda ründaja kontrollitava keskkonnana, mitte usaldusväärse jõustamispunktina. Ühendatud seadmed toovad kaasa füüsilise juurdepääsu, uuenduste terviklikkuse, taastamise ja võimalikud ohutusmõjud. Tehisintellektiga funktsioonid lisavad ebausaldusväärse sisu ja tööriistakasutuse piirid; autoriseerimine peab piirama toiminguid olenemata mudeli väljundist.

Mõõtke, kas olulistel voogudel on ajakohased mudelid, kas kõrge prioriteediga käsitlustel on kontrollitõendid, kas eeldused jäävad lahendamata ja kas aktsepteeritud riskide ülevaatused on hilinenud. Ainult ohtude loendamine premeerib mahtu, mitte kasulikku analüüsi. Paluge perioodiliselt sõltumatul ülevaatajal vaidlustada üks kriitiline stsenaarium ja selle tõendid.

Tehke esimene ülevaatus piisavalt väikeseks, et see lõpule viia

Secani saab säilitada nende otsuste ümber toimuva töövoo, modelleerides asjaomaseid süsteeme ja sõltuvusi, määrates omanikke ja ülevaatajaid ning sidudes tõendeid nõuete, kontrollimeetmete ja otsustega. Lahendamata eeldustest saavad ülesanded; lähtematerjal ja inimeste heakskiidud jäävad ülevaatuse juurde. Kõik tehisintellekti abil tehtud soovitused tuleks enne heakskiitmist üle kontrollida.

Alustage ühest kriitilisest andmevoost. Jälgige selle volitusi algusest lõpuni, tuvastage mõni usutav stsenaarium ja lõpetage omanikuga käsitluste ja selgesõnaliste kontrollikriteeriumidega. Kavandage järgmine ülevaatus nende arhitektuurimuudatuste ümber, mis võiksid need otsused kehtetuks muuta.