Kiire turvaline arendus, kasutades lihtsat ohumudelit

Uudsed arendused toimuvad hõivatud tarkvaraettevõtetes kogu aeg. Kuid kas toimub ka turvaline areng?

Protsess, mida nimetatakse lihtsaks ohu modelleerimiseks (LTM), kaasab sidusrühmad turvalisse arendusse, tagades, et turvalisus on sisse ehitatud ja mitte poltidega kinnitatud. Mis on LTM ja mille poolest see erineb traditsioonilisest ohumudelist?

Lihtne ohu modelleerimise lähenemisviis

LTM on tõhus lähenemisviis süsteemi või rakenduse võimalike turvaohtude ja haavatavuste tuvastamiseks, hindamiseks ja leevendamiseks. See on lihtsustatud versioon traditsiooniline ohu modelleerimine, mis hõlmab tavaliselt põhjalikumat ja üksikasjalikumat turvariskide analüüsi.

LTM-iga ei torka me käsitsi tihvte süsteemi või rakendusse, et näha, kas see puruneb, nagu teeksime pliiatsi testimisel. Pigem torkame rakendusse "teoreetilisi auke", avastades võimalikud ründeviisid ja haavatavused.

Siin on mõned küsimused, mida võiks küsida.

• Kes tahaks meie süsteeme rünnata?
• Milliseid süsteemi komponente saab rünnata ja kuidas?
• Mis on halvim asi, mis võib juhtuda, kui keegi sisse tungib?
• Millist negatiivset mõju see meie ettevõttele avaldaks? Meie klientidele?

Millal LTM-e tehakse? 

LTM on kõige parem teha iga kord, kui väljastatakse uus funktsioon, muudetakse turvakontrolli või tehakse muudatusi olemasolevas süsteemiarhitektuuris või infrastruktuuris.

Ideaalis tehakse LTM-e pärast projekteerimise etapp ja enne rakendamine. Lõppude lõpuks on haavatavust palju-palju lihtsam parandada enne, kui see tootmisse jõuab. LTM-ide laiendamiseks kogu oma organisatsioonis kehtestage kindlasti selged ja järjepidevad protsessid ja standardid. See võib hõlmata ühtse ohukategooriate komplekti määratlemist, ühiste ohtude ja haavatavuste allikate tuvastamist ning standardsete protseduuride väljatöötamist riskide hindamiseks ja maandamiseks.

Kuidas teostada LTM-e oma organisatsioonis 

Et alustada LTM-ide teostamist oma organisatsioonis, laske esmalt oma LTM-vestlusi juhtida siseturbemeeskondadel. Kui teie insenerimeeskonnad saavad protsessiga paremini tuttavaks, saavad nad hakata rakendama oma ohumudeleid.

LTM-ide laiendamiseks kogu oma organisatsioonis kehtestage kindlasti selged ja järjepidevad protsessid ja standardid. See võib hõlmata ühtse ohukategooriate komplekti määratlemist, ühiste ohtude ja haavatavuste allikate tuvastamist ning standardsete protseduuride väljatöötamist riskide hindamiseks ja maandamiseks.

Levinud LTM-i vead, mida vältida

Turvatöötajad oskavad suurepäraselt ohtusid modelleerida: nad ootavad sageli halvimat ja on piisavalt fantaasiarikkad, et välja mõelda äärmuslikud juhtumid. Kuid need omadused viivad nad ka LTM-i lõksudesse, näiteks:

• Liiga keskendumine kõrvalekalletele. See juhtub LTM-harjutuse ajal, kui vestluse fookus kaldub kõrvale kõige realistlikumatest ohtudest selle kõrvalekalletele. Selle lahendamiseks mõistke kindlasti põhjalikult oma ökosüsteemi. Kasutage oma turbeteabe ja -sündmuste haldamise (SIEM) ja muude turvaseiresüsteemide teavet. Kui teil on näiteks 10,000 XNUMX rünnakut, mis tabavad teie rakenduste programmeerimisliidese (API) lõpp-punkte, siis teate, et just sellele on teie vastased keskendunud. Sellele peaks keskenduma ka teie LTM.
• Läheb liiga tehniliseks. Sageli, kui teoreetiline haavatavus on avastatud, hüppavad tehnilised inimesed "probleemide lahendamise režiimi". Lõpuks lahendavad nad probleemi ja räägivad tehnilisest rakendamisest, selle asemel, et rääkida haavatavuse mõjust organisatsioonile. Kui leiate, et see juhtub teie LTM-harjutuste ajal, proovige vestlust tagasi tõmmata: öelge meeskonnale, et te ei räägi veel rakendamisest. Rääkige läbi risk ja mõju esiteks
• Eeldades, et ainult tööriistad juhivad riske. Sageli loodavad arendajad, et nende tööriistad leiavad kõik probleemid. Lõppude lõpuks on reaalsus see, et ohumudel ei ole mõeldud konkreetse haavatavuse leidmiseks. Pigem on see mõeldud süsteemi üldise riski vaatamiseks arhitektuuri tasandil. Tegelikult oli ebaturvaline disain OWASPi üks viimaseid Top 10 veebirakenduste turberiski. Te vajate ohumudeleid arhitektuuritasandil, sest arhitektuurseid turvaprobleeme on kõige raskem parandada.
• Võimalike ohtude ja haavatavuste tähelepanuta jätmine. Ohu modelleerimine ei ole ühekordne harjutus. Oluline on regulaarselt ümber hinnata võimalikke ohte ja haavatavust, et püsida ees pidevalt muutuvatest rünnakuvektoritest ja ohus osalejatest.
• Kõrgetasemeliste rakendusstrateegiate ülevaatamine. Kui võimalikud ohud ja haavatavused on tuvastatud, on oluline rakendada tõhusaid vastumeetmeid nende leevendamiseks või kõrvaldamiseks. See võib hõlmata tehniliste kontrollide rakendamist, nagu sisendi valideerimine, juurdepääsu kontroll või krüpteerimine, aga ka mittetehnilisi juhtelemente, nagu töötajate koolitus või halduspoliitika.

Järeldus

LTM on tõhus lähenemisviis võimalike turvaohtude ja haavatavuste tuvastamiseks, hindamiseks ja leevendamiseks. See on äärmiselt arendajasõbralik ja selle kaudu liigub turvaline kood varakult ohtude modelleerimist tarkvaraarenduse elutsüklis (SDLC). Veelgi parem, LTM-i saavad teha tarkvaraarendajad ja arhitektid ise, mitte ei loota ohtude modelleerimisel laboritele.

LTM-e järjepidevalt ja tõhusalt arendades ja juurutades saavad organisatsioonid kiiresti ja tõhusalt tuvastada ja käsitleda kõige kriitilisemaid turberiske, vältides samas levinud lõkse ja vigu.

• SEO-põhise sisu ja PR-levi. Võimenduge juba täna.
• Platoblockchain. Web3 metaversiooni intelligentsus. Täiustatud teadmised. Juurdepääs siia.
• Allikas: https://www.darkreading.com/vulnerabilities-threats/fast-track-secure-development-using-lite-threat-modeling