Vykdydami savo profesinę veiklą kūrėjai, bandytojai ir saugos specialistai turi susidoroti su tokiais procesais kaip pažeidžiamumo valdymas (VM), (saugus) SDLC.
Po šiomis frazėmis yra įvairių praktikų ir naudojamų įrankių rinkinių, kurie yra persipynę, nors jų vartotojai skiriasi.
Technologijų pažanga dar nepasiekė tiek, kad vienas įrankis galėtų pakeisti žmogų, analizuojantį infrastruktūros ir programinės įrangos saugumą.
Įdomu suprasti, kodėl taip yra ir su kokiomis problemomis tenka susidurti.
Procesai
Pažeidžiamumo valdymo procesas skirtas nuolat stebėti infrastruktūros saugumą ir pataisų valdymą.
Saugus SDLC procesas („saugaus kūrimo ciklas“) skirtas palaikyti programos saugumą kūrimo ir veikimo metu.
Panaši šių procesų dalis yra pažeidžiamumo vertinimo procesas – pažeidžiamumo įvertinimas, pažeidžiamumo nuskaitymas.
Pagrindinis skirtumas tarp nuskaitymo VM ir SDLC yra tas, kad pirmuoju atveju tikslas yra rasti žinomus trečiosios šalies programinės įrangos arba konfigūracijos pažeidžiamumus. Pavyzdžiui, pasenusi Windows versija arba numatytoji SNMP bendruomenės eilutė.
Antruoju atveju siekiama aptikti pažeidžiamumą ne tik trečiųjų šalių komponentuose (priklausomybėse), bet pirmiausia naujo produkto kode.
Tai lemia įrankių ir metodų skirtumus. Mano nuomone, užduotis rasti naujų programos spragų yra daug įdomesnė, nes tai neapsiriboja versijos pirštų atspaudų ėmimu, reklamjuosčių rinkimu, slaptažodžiu brutaline jėga ir pan.
Aukštos kokybės automatizuotam programų pažeidžiamumui nuskaityti reikalingi algoritmai, kurie atsižvelgtų į programos semantiką, paskirtį ir konkrečias grėsmes.
Infrastruktūros skaitytuvas dažnai gali būti pakeistas laikmačiu, kaip . Esmė ta, kad grynai statistiškai savo infrastruktūrą galite laikyti pažeidžiama, jei jos neatnaujinote, tarkime, mėnesį.
Įrankiai
Nuskaitymas, taip pat saugumo analizė gali būti atliekama kaip juoda arba balta dėžė.
Black Box
Naudojant juodosios dėžės nuskaitymą, įrankis turi turėti galimybę dirbti su paslauga per tas pačias sąsajas, kuriomis naudotojai dirba su ja.
Infrastruktūros skaitytuvai (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose ir kt.) ieško atvirų tinklo prievadų, renka „banerius“, identifikuoja įdiegtas programinės įrangos versijas ir savo žinių bazėje ieško informacijos apie šių versijų pažeidžiamumą. Jie taip pat bando aptikti konfigūracijos klaidas, pvz., numatytuosius slaptažodžius arba viešą prieigą prie duomenų, silpnus SSL šifrus ir kt.
Žiniatinklio programų skaitytuvai (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP ir kt.) taip pat gali aptikti žinomus komponentus ir jų versijas (pvz., TVS, karkasus, JS bibliotekas). Pagrindiniai nuskaitymo žingsniai yra šliaužimas ir miglojimas.
Tikrinimo metu tikrinimo programa renka informaciją apie esamas programų sąsajas ir HTTP parametrus. Aptikimo metu visi aptikti parametrai pakeičiami mutuotais arba sugeneruotais duomenimis, siekiant sukelti klaidą ir aptikti pažeidžiamumą.
Tokie programų skaitytuvai priklauso DAST ir IAST klasėms – atitinkamai Dynamic ir Interactive Application Security Testing.
Balta dėžutė
Naudojant „whitebox“ nuskaitymą, yra daugiau skirtumų.
Vykdant VM procesą, skaitytuvams (Vulners, Insecurity Couch, Vuls, Tenable Nessus ir kt.) dažnai suteikiama prieiga prie sistemų atliekant autentifikuotą nuskaitymą. Taigi skaitytuvas gali atsisiųsti įdiegtų paketų versijas ir konfigūracijos parametrus tiesiai iš sistemos, neatspėdamas jų iš tinklo paslaugų reklamjuosčių.
Nuskaitymas yra tikslesnis ir išsamesnis.
Jei kalbame apie programų nuskaitymą (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs ir kt.), tai dažniausiai kalbame apie statinio kodo analizę ir atitinkamų SAST klasės įrankių – Static Application Security Testing – naudojimą.
Problemos
Yra daug problemų su nuskaitymu! Su daugeliu jų tenka susidurti asmeniškai, teikiant pastatų skenavimo ir saugaus kūrimo procesų paslaugą, taip pat atliekant saugumo analizės darbus.
Išskirsiu 3 pagrindines problemų grupes, kurias patvirtina ir pokalbiai su įvairių įmonių inžinieriais bei informacijos saugos tarnybų vadovais.
Žiniatinklio programų nuskaitymo problemos
- Įgyvendinimo sunkumas. Kad skaitytuvai būtų veiksmingi, juos reikia įdiegti, sukonfigūruoti, pritaikyti kiekvienai programai, nuskaityti bandomąją aplinką ir įdiegti CI / CD procese. Priešingu atveju tai bus nenaudinga formali procedūra, išduodanti tik klaidingus teigiamus rezultatus
- Nuskaitymo trukmė. Skaitytuvai net 2019 m. prastai atlieka sąsajų dubliavimo panaikinimą ir gali ištisas dienas nuskaityti tūkstantį puslapių su 10 parametrų, laikydami juos skirtingais, nors už juos atsakingas tas pats kodas. Tuo pačiu metu sprendimas įdiegti gamybą per kūrimo ciklą turi būti priimtas greitai.
- Prastos rekomendacijos. Skaitytuvai pateikia gana bendras rekomendacijas, ir ne visada kūrėjas iš jų gali greitai suprasti, kaip sumažinti rizikos lygį, o svarbiausia, ar tai reikia padaryti dabar, ar dar nebaisu.
- Destruktyvus poveikis programai. Skaitytuvai gali lengvai atlikti programos DoS ataką, taip pat gali sukurti daugybę objektų arba pakeisti esamus (pavyzdžiui, tinklaraštyje sukurti dešimtis tūkstančių komentarų), todėl neturėtumėte neapgalvotai atlikti produkto nuskaitymo.
- Prasta pažeidžiamumo aptikimo kokybė. Skaitytuvai paprastai naudoja fiksuotą naudingųjų apkrovų masyvą ir gali lengvai praleisti pažeidžiamumą, kuris neatitinka žinomos programos veikimo.
- Skaitytuvas nesupranta programos funkcijų. Patys skaitytuvai nežino, kas yra „interneto bankas“, „mokėjimas“, „komentaras“. Jiems yra tik nuorodos ir parametrai, todėl didžiulis galimų verslo logikos pažeidžiamumų sluoksnis lieka visiškai neatskleistas, jie nespės atlikti dvigubo nurašymo, peržvelgti kitų žmonių duomenis pagal ID ar suvynioti likutį apvalindami.
- Skaitytuvo klaidingas puslapio semantikos supratimas. Skaitytuvai negali skaityti DUK, negali atpažinti captchų, patys nesupras kaip užsiregistruoti, o paskui vėl prisijungti, kad negalima spustelėti „atsijungti“ ir kaip pasirašyti užklausas keičiant parametrų reikšmes. Dėl to didžioji programos dalis gali likti nenuskaityta.
Šaltinio kodo nuskaitymo problemos
- Klaidingi teigiami rezultatai. Statinė analizė yra sudėtinga užduotis, apimanti daugybę kompromisų. Dažnai tenka paaukoti tikslumą, o net brangūs įmonės skaitytuvai pateikia daugybę klaidingų teigiamų rezultatų.
- Įgyvendinimo sunkumas. Norint padidinti statinės analizės tikslumą ir išsamumą, būtina patikslinti nuskaitymo taisykles, o šių taisyklių rašymas gali užtrukti per daug laiko. Kartais lengviau surasti visas kode vietas su kokia nors klaida ir jas pataisyti, nei parašyti taisyklę, kuri aptiktų tokius atvejus.
- Priklausomybės palaikymo trūkumas. Dideli projektai priklauso nuo daugybės bibliotekų ir struktūrų, praplečiančių programavimo kalbos galimybes. Jei skaitytuvo žinių bazėje nėra informacijos apie pavojingas vietas ("skęstuves") šiose sistemose, tai taps akla dėme, o skaitytuvas tiesiog net nesupras kodo.
- Nuskaitymo trukmė. Kodo pažeidžiamumų paieška yra sudėtinga užduotis ir algoritmų požiūriu. Todėl procesas gali būti atidėtas ir pareikalauti didelių skaičiavimo išteklių.
- Maža aprėptis. Nepaisant išteklių suvartojimo ir nuskaitymo trukmės, SAST įrankių kūrėjai vis tiek turi ieškoti kompromisų ir analizuoti ne visas būsenas, kuriose gali būti programa.
- Atkuriamumo radimas. Nurodymas į konkrečią linijos ir skambučių krūvą, dėl kurio atsiranda pažeidžiamumas, yra puiku, tačiau iš tikrųjų dažnai skaitytuvas nepateikia pakankamai informacijos, kad būtų galima patikrinti, ar nėra išorinio pažeidžiamumo. Juk trūkumas gali būti ir mirusiame kode, kuris užpuolikui nepasiekiamas.
Infrastruktūros nuskaitymo problemos
- Nepakankamas inventorius. Didelėse infrastruktūrose, ypač geografiškai atskirtose, dažnai būna sunkiausia išsiaiškinti, kuriuos pagrindinius kompiuterius reikia nuskaityti. Kitaip tariant, nuskaitymo užduotis yra glaudžiai susijusi su turto valdymo užduotimi.
- Blogas prioritetų nustatymas. Tinklo skaitytuvai dažnai duoda daug rezultatų su trūkumais, kurie praktiškai nepanaudojami, tačiau formaliai jų rizikos lygis yra didelis. Vartotojas gauna pranešimą, kurį sunku interpretuoti, ir neaišku, ką pirmiausia reikia taisyti
- Prastos rekomendacijos. Skaitytuvo žinių bazėje dažnai yra tik labai bendros informacijos apie pažeidžiamumą ir kaip jį ištaisyti, todėl administratoriams teks apsiginkluoti „Google“. Situacija yra šiek tiek geresnė naudojant „whitebox“ skaitytuvus, kurie gali išduoti konkrečią komandą, kurią reikia išspręsti
- Rankų darbo. Infrastruktūra gali turėti daug mazgų, o tai reiškia, kad gali būti daug trūkumų, kurių ataskaitas reikia išanalizuoti ir analizuoti rankiniu būdu kiekvienos iteracijos metu.
- Bloga aprėptis. Infrastruktūros nuskaitymo kokybė tiesiogiai priklauso nuo žinių bazės apie pažeidžiamumą ir programinės įrangos versijas dydžio. kur, , net rinkos lyderiai neturi išsamios žinių bazės, o nemokamų sprendimų duomenų bazėse yra daug informacijos, kurios lyderiai neturi
- Problemos su pataisymu. Dažniausiai infrastruktūros pažeidžiamumų taisymas yra paketo atnaujinimas arba konfigūracijos failo keitimas. Didelė problema yra ta, kad sistema, ypač senoji, dėl atnaujinimo gali veikti nenuspėjamai. Tiesą sakant, turėsite atlikti tiesioginės gamybos infrastruktūros integravimo testus.
Prieigos
Kaip tai gali būti?
Toliau pateiktose dalyse papasakosiu apie pavyzdžius ir kaip spręsti daugelį šių problemų, tačiau kol kas nurodysiu pagrindines sritis, kuriose galite dirbti:
- Įvairių nuskaitymo įrankių agregavimas. Teisingai naudojant kelis skaitytuvus, galima žymiai padidinti žinių bazę ir aptikimo kokybę. Galite rasti net daugiau pažeidžiamumų nei sudėjus visų atskirai veikiančių skaitytuvų sumą, tuo pačiu galite tiksliau įvertinti rizikos lygį ir pateikti daugiau rekomendacijų
- SAST ir DAST integracija. Galima padidinti DAST aprėptį ir SAST tikslumą dalijantis informacija tarp jų. Iš šaltinio galite gauti informacijos apie esamus maršrutus, o su DAST pagalba galite patikrinti, ar pažeidžiamumas matomas iš išorės
- Mašininis mokymasis™. 2015 metais I (ir ) apie statistikos naudojimą siekiant suteikti skaitytuvams įsilaužėlių intuiciją ir juos pagreitinti. Tai neabejotinai yra maistas automatizuotos saugumo analizės plėtrai ateityje.
- IAST integracija su automatiniais testais ir OpenAPI. CI/CD dujotiekyje galima sukurti nuskaitymo procesą, pagrįstą įrankiais, kurie veikia kaip HTTP tarpiniai serveriai, ir funkciniais testais, kurie veikia per HTTP. OpenAPI/Swagger testai ir sutartys suteiks skaitytuvui trūkstamą informaciją apie duomenų srautus, leis nuskaityti aplikaciją įvairiose būsenose
- Teisinga konfigūracija. Kiekvienai programai ir infrastruktūrai turite sukurti tinkamą nuskaitymo profilį, atsižvelgdami į sąsajų skaičių ir pobūdį, naudojamas technologijas.
- Skaitytuvo pritaikymas. Dažnai programos negalima nuskaityti nepakeitus skaitytuvo. Pavyzdys yra mokėjimo šliuzas, kuriame kiekvienas prašymas turi būti pasirašytas. Neįrašę jungties prie šliuzo protokolo, skaitytuvai be proto ims ieškoti užklausų su neteisingu parašu. Taip pat būtina rašyti specializuotus skaitytuvus tam tikro tipo trūkumams, pvz
- Rizikos valdymas. Įvairių skaitytuvų naudojimas ir integracija su išorinėmis sistemomis, tokiomis kaip turto valdymas ir grėsmių valdymas, leis naudoti kelis parametrus rizikos lygiui įvertinti, kad vadovybė galėtų susidaryti tinkamą vaizdą apie dabartinę plėtros ar infrastruktūros saugumo būklę.
Sekite naujienas ir sutrukdykime pažeidžiamumo nuskaitymą!
Šaltinis: www.habr.com