Turėjome 2 kodų analizatorius, 4 dinaminio testavimo įrankius, savo amatus ir 250 scenarijų. Tai nereiškia, kad viso to reikia dabartiniame procese, bet kai tik pradėsite diegti DevSecOps, turite eiti iki galo.
. Personažų kūrėjai: Justinas Roilandas ir Danas Harmonas.
Kas yra „SecDevOps“? O „DevSecOps“? Kokie yra skirtumai? Programų sauga – kas tai? Kodėl klasikinis požiūris nebeveikia? Žino atsakymus į visus šiuos klausimus Jurijus Šabalinas iš Swordfish Security. Jurijus į viską išsamiai atsakys ir išanalizuos perėjimo nuo klasikinio Application Security modelio prie DevSecOps proceso problemas: kaip tinkamai priartėti prie saugaus kūrimo proceso integravimo į DevOps procesą ir nieko nesulaužyti, kaip pereiti pagrindinius etapus. saugumo testavimo, kokius įrankius galima naudoti ir kuo jie skiriasi bei kaip teisingai juos sukonfigūruoti, kad būtų išvengta spąstų.
Apie kalbėtoją: Jurijus Šabalinas - Įmonės vyriausiasis apsaugos architektas Swordfish Security. Atsakingas už SSDL diegimą, už bendrą programų analizės įrankių integravimą į vieningą kūrimo ir testavimo ekosistemą. 7 metų patirtis informacijos apsaugos srityje. Dirbo Alfa-Bank, Sberbank ir Positive Technologies, kurios kuria programinę įrangą ir teikia paslaugas. Pranešėjas tarptautinėse konferencijose ZerONights, PHDays, RISSPA, OWASP.
Programos sauga: kas tai?
„Application Security“ - Tai saugos skyrius, atsakingas už programos saugumą. Tai netaikoma infrastruktūrai ar tinklo saugumui, o tai, ką rašome ir su kuo dirba kūrėjai – tai pačios programos trūkumai ir pažeidžiamumas.
kryptis - Saugumo kūrimo gyvavimo ciklas - sukūrė Microsoft. Diagramoje parodytas kanoninis SDLC modelis, kurio pagrindinė užduotis yra saugumo dalyvavimas kiekviename kūrimo etape, nuo reikalavimų iki išleidimo ir gamybos. „Microsoft“ suprato, kad pramonėje yra per daug klaidų, jų buvo daugiau ir dėl to reikėjo kažką daryti, ir pasiūlė šį metodą, kuris tapo kanoniniu.
„Application Security“ ir „SSDL“ nėra skirti aptikti pažeidžiamumą, kaip įprasta manyti, o užkirsti kelią jų atsiradimui. Laikui bėgant „Microsoft“ kanoninis požiūris buvo patobulintas, išplėtotas ir įtrauktas į gilesnį, išsamesnį nardymą.
Kanoninis SDLC yra labai detalus įvairiose metodikose – OpenSAMM, BSIMM, OWASP. Metodikos skirtingos, bet iš esmės panašios.
Pastato apsaugos brandos modelis
Man tai labiausiai patinka BSIMM - . Metodikos pagrindas – Application Security proceso padalijimas į 4 sritis: valdymas, žvalgyba, SSDL kontaktiniai taškai ir diegimas. Kiekviena sritis turi 12 praktikų, kurios pavaizduotos kaip 112 veiklų.
Kiekviena iš 112 veiklų turi 3 brandos lygiai: pradedantysis, vidutinis ir pažengęs. Galite išstudijuoti visas 12 praktikų po skyrelį, pasirinkti jums svarbius dalykus, sugalvoti, kaip juos įgyvendinti ir palaipsniui pridėti elementus, pavyzdžiui, statinę ir dinaminę kodo analizę ar kodo peržiūrą. Susirašote planą ir ramiai pagal jį dirbate, įgyvendindami pasirinktą veiklą.
Kodėl DevSecOps
„DevOps“ yra bendras, didelis procesas, kurio metu reikia atsižvelgti į saugumą.
Iš pradžių dalyvavo saugumo patikrinimai. Praktiškai saugos komandų skaičius buvo gerokai mažesnis nei dabar, jos veikė ne kaip proceso dalyvės, o kaip kontrolės ir priežiūros institucija, kuri kelia jai reikalavimus ir tikrina gaminio kokybę pasibaigus išleidimui. Tai klasikinis požiūris, kai apsaugos komandos buvo už sienos nuo kūrimo ir nedalyvavo procese.
Pagrindinė problema yra ta, kad informacijos saugumas yra atskirtas nuo plėtros. Paprastai tai yra tam tikra informacijos apsaugos grandinė, kurioje yra 2–3 dideli ir brangūs įrankiai. Kartą per šešis mėnesius atkeliauja šaltinio kodas arba programa, kurią reikia patikrinti, o kartą per metus jie gaminami . Visa tai lemia tai, kad pramonės išleidimo data vėluojama, o kūrėjas susiduria su daugybe automatinių įrankių spragų. Viso to išardyti ir taisyti neįmanoma, nes praėjusio šešių mėnesių rezultatai nebuvo sutvarkyti, bet čia yra nauja partija.
Vykdydami savo įmonės darbą matome, kad saugumas visose srityse ir pramonės šakose supranta, kad laikas pasivyti ir suktis su plėtra ant to paties rato. . „DevSecOps“ paradigma puikiai dera su judria kūrimo metodika, diegimu, palaikymu ir dalyvavimu kiekvienoje laidoje ir iteracijoje.
Perėjimas prie DevSecOps
Svarbiausias žodis saugumo plėtros gyvavimo cikle yra "procesas". Prieš galvodami apie įrankių pirkimą, turite tai suprasti.
Neužtenka vien įtraukti įrankius į „DevOps“ procesą – svarbus proceso dalyvių bendravimas ir supratimas.
Svarbesni žmonės, o ne įrankiai.
Dažnai saugaus kūrimo proceso planavimas prasideda nuo įrankio pasirinkimo ir įsigijimo, o baigiasi bandymais integruoti įrankį į esamą procesą, o tai ir lieka bandymais. Tai sukelia apgailėtinas pasekmes, nes visos priemonės turi savo ypatybes ir apribojimus.
Dažnas atvejis, kai saugumo skyrius išsirinko gerą, brangų įrankį su plačiomis galimybėmis ir atėjo pas kūrėjus integruoti jį į procesą. Bet tai nepavyksta – procesas sukonstruotas taip, kad jau įsigyto įrankio apribojimai netelpa į dabartinę paradigmą.
Pirmiausia aprašykite, kokio rezultato norite ir kaip atrodys procesas. Tai padės suprasti įrankio ir saugos vaidmenį procese.
Pradėkite nuo to, kas jau naudojama
Prieš pirkdami brangius įrankius, pažiūrėkite, ką jau turite. Kiekviena įmonė turi saugumo reikalavimus plėtrai, yra čekių, pentestų – kodėl viso to nepakeitus į visiems suprantamą ir patogią formą?
Paprastai reikalavimai yra popierinis Talmudas, kuris guli lentynoje. Buvo atvejis, kai atėjome į įmonę pasižiūrėti procesų ir paprašėme pamatyti programinės įrangos saugumo reikalavimus. Su tuo susidūręs specialistas ilgai ieškojo:
– Dabar kažkur užrašuose buvo kelias, kur guli šis dokumentas.
Dėl to dokumentą gavome po savaitės.
Dėl reikalavimų, čekių ir kitų dalykų sukurkite puslapį pvz. Santaka - tai patogu visiems.
Lengviau iš naujo suformatuoti tai, ką jau turite, ir pradėti naudoti.
Naudokite saugumo čempionus
Paprastai vidutinėje įmonėje, kurioje dirba 100-200 kūrėjų, yra vienas saugos specialistas, kuris atlieka kelias funkcijas ir fiziškai nespėja visko patikrinti. Net jei jis stengsis, jis vienas nepatikrins viso kodo, kurį sukuria plėtra. Tokiems atvejams buvo sukurta koncepcija - .
Saugumo čempionai yra kūrėjų komandos žmonės, kurie domisi jūsų produkto saugumu.
Saugumo čempionas yra įėjimo taškas į kūrėjų komandą ir saugumo evangelistas, įtrauktas į vieną.
Dažniausiai saugumo specialistui atėjęs į kūrimo komandą ir nurodęs klaidą kode, jis sulaukia nustebusio atsakymo:
- Ir kas tu esi? Aš tave matau pirmą kartą. Viskas su manimi gerai - mano vyresnysis draugas man davė „aprašyti“ kodo peržiūroje, judame toliau!
Tai tipiška situacija, nes kur kas labiau pasitikima senjorais ar tiesiog komandos draugais, su kuriais kūrėjas nuolat bendrauja darbe ir kodų peržiūroje. Jei vietoj apsaugos pareigūno Saugumo čempionas nurodys klaidą ir pasekmes, tada jo žodis turės daugiau svorio.
Be to, kūrėjai savo kodą žino geriau nei bet kuris saugos specialistas. Žmogui, turinčiam bent 5 projektus statinės analizės įrankyje, dažniausiai sunku prisiminti visus niuansus. Saugumo čempionai žino savo produktą: kas su kuo sąveikauja ir į ką pirmiausia reikia žiūrėti – jie efektyvesni.
Taigi apsvarstykite galimybę įdiegti saugumo čempionus ir išplėsti savo apsaugos komandos įtaką. Tai naudinga ir pačiam čempionui: profesinis tobulėjimas naujoje srityje, techninio akiračio plėtimas, techninių, vadybinių ir lyderystės įgūdžių tobulinimas, rinkos vertės didinimas. Tai yra tam tikras socialinės inžinerijos elementas, jūsų „akys“ kūrimo komandoje.
Testavimo etapai
sako, kad 20% pastangų duoda 80% rezultatų. Šie 20 % yra taikomųjų programų analizės praktika, kurią galima ir reikia automatizuoti. Tokios veiklos pavyzdžiai yra statinė analizė – SAST, dinaminė analizė - DAST и Atvirojo kodo valdymas. Papasakosiu plačiau apie veiklas, taip pat apie priemones, su kokiomis savybėmis dažniausiai susiduriame įvesdami jas į procesą ir kaip tai padaryti teisingai.
Pagrindinės įrankių problemos
Išskirsiu visiems instrumentams aktualias ir dėmesio reikalaujančias problemas. Išanalizuosiu juos išsamiau, kad daugiau nesikartočiau.
Ilgas analizės laikas. Jei nuo įsipareigojimo iki išleidimo visi bandymai ir surinkimas užtrunka 30 minučių, informacijos saugumo patikros užtruks vieną dieną. Taigi proceso niekas nesustabdys. Atsižvelkite į šią savybę ir padarykite išvadas.
Aukšto lygio klaidingas neigiamas arba klaidingas teigiamas. Visi produktai yra skirtingi, visi naudoja skirtingus rėmus ir savo kodavimo stilių. Skirtingose kodų bazėse ir technologijose įrankiai gali rodyti skirtingus klaidingo neigiamo ir klaidingo teigiamo lygius. Taigi pažiūrėkite, kas tiksliai yra iš jūsų įmonėms ir už tavo programos parodys gerus ir patikimus rezultatus.
Jokių integracijų su esamais įrankiais. Pažvelkite į įrankius kaip integraciją su tuo, ką jau naudojate. Pavyzdžiui, jei turite Jenkins arba TeamCity, patikrinkite įrankių integraciją su šia programine įranga, o ne su GitLab CI, kurios nenaudojate.
Tinkinimo trūkumas arba per didelis sudėtingumas. Jei įrankis neturi API, kodėl jis reikalingas? Viskas, ką galima padaryti sąsajoje, turėtų būti pasiekiama per API. Idealiu atveju įrankis turėtų turėti galimybę tinkinti patikras.
Nėra produkto plėtros plano. Plėtra nestovi vietoje, mes nuolat naudojame naujas sistemas ir funkcijas, perrašome seną kodą į naujas kalbas. Norime būti tikri, kad mūsų perkamas įrankis palaikys naujas sistemas ir technologijas. Todėl svarbu žinoti, kad produktas yra tikras ir teisingas plėtra.
Proceso ypatybės
Be įrankių savybių, atsižvelkite į kūrimo proceso ypatybes. Pavyzdžiui, stabdyti vystymąsi yra dažna klaida. Pažiūrėkime, į kokias kitas ypatybes reikėtų atsižvelgti ir į ką saugos komanda turėtų atkreipti dėmesį.
Kad nepraleistumėte tobulinimo ir išleidimo terminų, sukurkite skirtingos taisyklės ir kitoks parodyti kamštelius — kriterijai, pagal kuriuos būtų stabdomas kūrimo procesas, kai yra pažeidžiamumų, skirtingoms aplinkoms. Pavyzdžiui, mes suprantame, kad dabartinė šaka eina į plėtros stendą arba UAT, o tai reiškia, kad nesustosime ir nesakome:
„Čia turite pažeidžiamumų, niekur toliau nenueisite!
Šiuo metu svarbu pasakyti kūrėjams, kad yra saugumo problemų, į kurias reikia atkreipti dėmesį.
Pažeidžiamumų buvimas nėra kliūtis tolesniam bandymui: rankinis, integracinis arba rankinis. Kita vertus, turime kažkaip padidinti produkto saugumą ir kad kūrėjai nepaisytų to, kas jiems atrodo saugi. Todėl kartais taip ir darome: stende, kai jis iškeliamas į kūrimo aplinką, tiesiog pranešame kūrimui:
- Vaikinai, jūs turite problemų, atkreipkite į jas dėmesį.
UAT etape vėl rodome įspėjimus apie pažeidžiamumą, o išleidimo etape sakome:
- Vaikinai, mes jus kelis kartus perspėjome, jūs nieko nepadarėte - mes jūsų neišleisime.
Jei mes kalbame apie kodą ir dinamiką, tada būtina parodyti ir įspėti apie pažeidžiamumą tik tų funkcijų ir kodo, kuris buvo ką tik parašytas šioje funkcijoje. Jei kūrėjas perkelia mygtuką 3 pikseliais ir mes jam sakome, kad jis ten įvedė SQL, todėl jį reikia skubiai pataisyti, tai neteisinga. Pažiūrėkite tik į tai, kas parašyta dabar, ir į programos pakeitimus.
Tarkime, turime tam tikrą funkcinį defektą – taip, kaip programa neturėtų veikti: pinigai nepervedami, paspaudus mygtuką nepereina į kitą puslapį arba prekė neįkeliama. Saugumo defektai - tai tie patys defektai, bet ne programos veikimo, o saugumo požiūriu.
Ne visos programinės įrangos kokybės problemos yra saugumo problemos. Tačiau visos saugumo problemos yra susijusios su programinės įrangos kokybe. Sherif Mansour, Expedia.
Kadangi visi pažeidžiamumai yra tie patys defektai, jie turėtų būti toje pačioje vietoje kaip ir visi vystymosi defektai. Taigi pamirškite ataskaitas ir baisius PDF failus, kurių niekas neskaito.
Kai dirbau kūrimo įmonėje, gavau ataskaitą iš statinės analizės įrankių. Atidariau, išsigandau, išsiviriau kavos, perverčiau 350 puslapių, užverčiau ir dirbau toliau. Didelės ataskaitos yra negyvos ataskaitos. Dažniausiai jie niekur nedingsta, laiškai ištrinami, pamirštami, pamesti arba verslas sako, kad prisiima riziką.
Ką daryti? Mes tiesiog paverčiame patvirtintus defektus, kuriuos radome, į patogią plėtrai formą, pavyzdžiui, įtraukiame juos į Jira atsilikimą. Defektams teikiame pirmenybę ir juos šaliname prioriteto tvarka, kartu su funkciniais ir bandomaisiais defektais.
Statinė analizė – SAST
Tai pažeidžiamumų kodo analizė., bet tai nėra tas pats, kas SonarQube. Mes ne tik tikriname modelius ar stilių. Atliekant analizę naudojami keli požiūriai: pagal pažeidžiamumo medį, pagal , analizuodami konfigūracijos failus. Tai viskas, kas susiję su pačiu kodu.
Požiūrio privalumai: kodo pažeidžiamumų nustatymas ankstyvame kūrimo etapekai dar nėra stovų ar paruoštų įrankių, ir laipsniško nuskaitymo galimybė: nuskaitoma pasikeitusi kodo dalis ir tik šiuo metu vykdoma funkcija, kuri sumažina nuskaitymo laiką.
Trūkumai – tai reikalingų kalbų palaikymo trūkumas.
Būtinos integracijos, kurie, mano subjektyvia nuomone, turėtų būti įrankiuose:
- Integravimo įrankis: Jenkins, TeamCity ir Gitlab CI.
- Kūrimo aplinka: Intellij IDEA, Visual Studio. Kūrėjui patogiau ne naršyti nesuprantamoje sąsajoje, kurią dar reikia įsiminti, o pamatyti visas būtinas integracijas ir pažeidžiamumus, kuriuos jis rado tiesiog darbo vietoje, savo kūrimo aplinkoje.
- Kodo peržiūra: „SonarQube“ ir rankinė peržiūra.
- Defektų stebėjimo priemonės: Jira ir Bugzilla.
Paveikslėlyje pavaizduoti vieni geriausių statinės analizės atstovų.
Svarbu ne įrankiai, o procesas, todėl yra atvirojo kodo sprendimų, kurie taip pat tinka procesui išbandyti.
SAST atvirasis šaltinis neras daugybės pažeidžiamumų ar sudėtingų duomenų srautų, tačiau juos galima ir reikia naudoti kuriant procesą. Jie padeda suprasti, kaip bus kuriamas procesas, kas reaguos į klaidas, kas praneš, o kas praneš. Jei norite atlikti pradinį kodo saugumo kūrimo etapą, naudokite atvirojo kodo sprendimus.
Kaip tai galima integruoti, jei esate savo kelionės pradžioje ir nieko neturite: nei CI, nei Jenkins, nei TeamCity? Panagrinėkime integraciją į procesą.
CVS lygio integracija
Jei turite „Bitbucket“ arba „GitLab“, galite integruoti lygiu .
Pagal įvykį - traukti prašymą, įsipareigoti. Nuskaitote kodą ir kūrimo būsena parodo, ar saugos patikra buvo atlikta, ar nepavyko.
Atsiliepimai. Žinoma, grįžtamasis ryšys visada reikalingas. Jei ką tik padarėte apsaugą šone, įdėjote į dėžę ir niekam nieko apie tai nesakėte, o tada mėnesio pabaigoje išmetėte krūvą klaidų - tai neteisinga ir nėra gerai.
Integracija su kodų peržiūros sistema
Kai kuriuose svarbiuose projektuose dirbome kaip numatytasis techninio AppSec vartotojo apžvalgininkas. Priklausomai nuo to, ar naujame kode aptiktos klaidos, ar klaidų nėra, recenzentas nustato ištraukimo užklausos būseną į „priimti“ arba „reikia dirbti“ - arba viskas gerai, arba nuorodos į tai, ką tiksliai reikia patobulinti. reikia tobulinti. Norėdami integruoti su versija, kuri pradedama gaminti, įgalinome draudimą sujungti, jei informacijos saugos testas nėra išlaikytas. Įtraukėme tai į rankinio kodo peržiūrą, o kiti proceso dalyviai matė šio konkretaus proceso saugos būsenas.
Integracija su SonarQube
Daugelis turi kalbant apie kodo kokybę. Čia tas pats – tuos pačius vartus galite pagaminti tik SAST įrankiams. Bus ta pati sąsaja, tokie pat kokybės vartai, tik jie bus vadinami apsauginiai vartai. Be to, jei naudojate „SonarQube“ procesą, galite lengvai viską integruoti.
Integracija CI lygiu
Viskas čia taip pat gana paprasta:
- Lygiai su automatiniais testais, vienetiniai testai.
- Suskirstymas pagal vystymosi etapus: kūrėjas, bandymas, prod. Gali būti įtraukti skirtingi taisyklių rinkiniai arba skirtingos gedimo sąlygos: sustabdykite surinkimą, nesustabdykite surinkimo.
- Sinchroninis / asinchroninis paleidimas. Laukiame saugumo testų pabaigos ar ne. Tai yra, mes tiesiog juos paleidome ir judame toliau, o tada gauname statusą, kad viskas gerai arba blogai.
Visa tai tobulame rožiniame pasaulyje. Realiame gyvenime tokio dalyko nėra, bet mes stengiamės. Saugumo patikrų rezultatai turėtų būti panašūs į vienetų testų rezultatus.
Pavyzdžiui, ėmėmės didelio projekto ir nusprendėme, kad dabar jį nuskaitysime su SAST – OK. Mes įstūmėme šį projektą į SAST, jis mums suteikė 20 000 pažeidžiamumų ir stipriu sprendimu nusprendėme, kad viskas gerai. 20 000 pažeidžiamumų yra mūsų techninė skola. Įdėsime skolą į dėžutę, pamažu išvalysime ir pridėsime klaidų prie defektų sekimo priemonių. Pasamdykime įmonę, padarykime viską patys arba padėsime Saugos Čempionams – ir techninės skolos sumažės.
Ir visi naujai atsirandantys naujojo kodo pažeidžiamumai turi būti pašalinti taip pat, kaip ir klaidos vienete ar atliekant automatinius testus. Santykinai kalbant, surinkimas prasidėjo, mes jį paleidome, du bandymai ir du saugumo testai nepavyko. Gerai - nuėjome, pažiūrėjome, kas atsitiko, vieną taisėme, kitą sutvarkėme, paleidome kitą kartą - viskas buvo gerai, neatsirado naujų spragų, nepavyko atlikti bandymų. Jei ši užduotis yra gilesnė ir jums reikia ją gerai suprasti, arba pažeidžiamumų taisymas paveikia didelius sluoksnius to, kas slypi po gaubtu: defektų sekimo priemonėje buvo pridėta klaida, ji suteikiama pirmenybė ir ištaisoma. Deja, pasaulis nėra tobulas ir bandymai kartais žlunga.
Apsaugos vartų pavyzdys yra kokybiškų vartų analogas, atsižvelgiant į pažeidžiamumų buvimą ir skaičių kode.
Integruojame su SonarQube – įskiepis įdiegtas, viskas labai patogu ir šaunu.
Integracija su kūrimo aplinka
Integravimo parinktys:
- Nuskaitymas iš kūrimo aplinkos prieš įsipareigojimą.
- Žiūrėti rezultatus.
- Rezultatų analizė.
- Sinchronizavimas su serveriu.
Taip atrodo gauti rezultatus iš serverio.
Mūsų vystymosi aplinkoje tiesiog pasirodo papildomas elementas, informuojantis, kad tokie pažeidžiamumai buvo aptikti nuskaitymo metu. Galite iš karto redaguoti kodą, peržiūrėti rekomendacijas ir . Visa tai yra kūrėjo darbo vietoje, o tai labai patogu - nereikia sekti kitų nuorodų ir ieškoti kažko papildomo.
Open Source
Tai mano mėgstamiausia tema. Visi naudojasi atvirojo kodo bibliotekomis – kam rašyti krūvą ramentų ir dviračių, kai galima pasiimti jau paruoštą biblioteką, kurioje viskas jau įdiegta?
Žinoma, tai tiesa, bet bibliotekas taip pat rašo žmonės, jos taip pat apima tam tikras rizikas, taip pat yra pažeidžiamumų, apie kuriuos periodiškai arba nuolat pranešama. Todėl yra kitas Application Security žingsnis – tai atvirojo kodo komponentų analizė.
Atvirojo kodo analizė – OSA
Įrankį sudaro trys dideli etapai.
Bibliotekų pažeidžiamumų paieška. Pavyzdžiui, įrankis žino, kad naudojame tam tikrą biblioteką, ir tai yra arba yra tam tikrų su šia bibliotekos versija susijusių klaidų sekimo priemonių spragų. Kai bandysite juo naudotis, įrankis įspės, kad biblioteka yra pažeidžiama, ir patars naudoti kitą versiją, kurioje nėra pažeidžiamumų.
Licencijos grynumo analizė. Tai kol kas nėra itin populiaru pas mus, bet jei dirbate užsienyje, tai karts nuo karto ten galite gauti mokestį už atvirojo kodo komponento naudojimą, kurio negalima naudoti ar modifikuoti. Pagal licencijuotos bibliotekos politiką to daryti negalime. Arba, jei jį modifikavome ir naudojame, turėtume paskelbti savo kodą. Žinoma, niekas nenori skelbti savo produktų kodo, bet jūs taip pat galite apsisaugoti nuo to.
Komponentų, naudojamų pramoninėje aplinkoje, analizė. Įsivaizduokime hipotetinę situaciją, kai pagaliau baigėme kūrimą ir išleidome naujausią savo mikropaslaugos leidimą. Jis ten gyvena nuostabiai – savaitę, mėnesį, metus. Mes jo nerenkame, neatliekame saugumo patikrinimų, atrodo, kad viskas gerai. Tačiau staiga, praėjus dviem savaitėms po išleidimo, atvirojo kodo komponente, kurį naudojame šiame konkrečiame versijoje, pramoninėje aplinkoje atsiranda kritinis pažeidžiamumas. Jei neįrašysime, ką ir kur naudojame, tada šio pažeidžiamumo tiesiog nematysime. Kai kurie įrankiai turi galimybę stebėti bibliotekų, kurios šiuo metu naudojamos pramonėje, pažeidžiamumą. Tai labai naudinga.
Savybės:
- Skirtingos politikos skirtingiems vystymosi etapams.
- Komponentų stebėjimas pramoninėje aplinkoje.
- Bibliotekų kontrolė organizacijos viduje.
- Įvairių kūrimo sistemų ir kalbų palaikymas.
- Docker vaizdų analizė.
Keletas pramonės lyderių, kurie užsiima atvirojo kodo analize, pavyzdžiai.
Vienintelis nemokamas yra šis iš OWASP. Galite jį įjungti pirmaisiais etapais, pamatyti, kaip jis veikia ir ką palaiko. Iš esmės tai visi debesies produktai arba vietiniai, tačiau už jų bazės jie vis tiek siunčiami į internetą. Jie siunčia ne jūsų bibliotekas, o maišas arba savo vertes, kurias apskaičiuoja, ir pirštų atspaudus į savo serverį, kad gautų informaciją apie pažeidžiamumą.
Proceso integravimas
Bibliotekų perimetro kontrolė, kurie atsisiunčiami iš išorinių šaltinių. Turime išorines ir vidines saugyklas. Pavyzdžiui, „Event Central“ veikia „Nexus“, todėl norime užtikrinti, kad mūsų saugykloje nebūtų pažeidžiamumų, kurių būsena „kritinė“ arba „aukšta“. Galite sukonfigūruoti tarpinį serverį naudodami „Nexus Firewall Lifecycle“ įrankį, kad tokie pažeidžiamumai būtų pašalinti ir nepatektų į vidinę saugyklą.
Integracija į CI. Tame pačiame lygyje su automatiniais testais, vienetų testais ir padalijimu į kūrimo etapus: dev, test, prod. Kiekviename etape galite atsisiųsti bet kokias bibliotekas, naudoti bet ką, tačiau jei yra kažkas sudėtingo dėl „kritinės“ būsenos, galbūt verta atkreipti kūrėjų dėmesį į tai leidimo į gamybą etape.
Integracija su artefaktais: Nexus ir JFrog.
Integracija į vystymosi aplinką. Pasirinkti įrankiai turi būti integruoti su kūrimo aplinkomis. Prieš įsipareigodamas naudoti CVS, kūrėjas turi turėti prieigą prie nuskaitymo rezultatų iš savo darbo vietos arba turėti galimybę pats nuskaityti ir patikrinti kodą, ar nėra pažeidžiamumų.
CD integracija. Tai šauni funkcija, kuri man labai patinka ir apie kurią jau kalbėjau – naujų pažeidžiamumų atsiradimo pramoninėje aplinkoje stebėjimas. Tai veikia maždaug taip.
Mes turime Viešosios komponentų saugyklos - kai kurie įrankiai išorėje ir mūsų vidinė saugykla. Norime, kad jame būtų tik patikimi komponentai. Perduodami užklausą tarpiniam serveriui, patikriname, ar atsisiųstoje bibliotekoje nėra pažeidžiamumų. Jei jai taikoma tam tikra politika, kurią nustatome ir būtinai suderiname su plėtra, tada jos neįkeliame ir esame raginami naudoti kitą versiją. Atitinkamai, jei bibliotekoje yra kažkas tikrai kritiško ir blogo, kūrėjas negaus bibliotekos diegimo etape - tegul naudojasi aukštesne ar žemesne versija.
- Statydami tikriname, ar niekas nieko blogo nepaslydo, ar visi komponentai yra saugūs ir niekas į „flash drive“ neatsinešė nieko pavojingo.
- Saugykloje turime tik patikimus komponentus.
- Diegdami dar kartą patikriname patį paketą: war, jar, DL arba Docker image, kad įsitikintume, ar jis atitinka politiką.
- Įeidami į industriją stebime, kas vyksta pramoninėje aplinkoje: atsiranda arba neatsiranda kritinių pažeidžiamumų.
Dinaminė analizė – DAST
Dinaminės analizės įrankiai iš esmės skiriasi nuo visko, kas buvo pasakyta anksčiau. Tai savotiška vartotojo darbo su programa imitacija. Jei tai žiniatinklio aplikacija, siunčiame užklausas, imituojančias kliento darbą, paspaudžiame priekyje esančius mygtukus, siunčiame dirbtinius duomenis iš formos: kabutes, skliaustus, simbolius skirtingomis koduotėmis, norėdami pamatyti, kaip programa veikia ir apdoroja. išoriniai duomenys.
Ta pati sistema leidžia patikrinti atvirojo kodo šablonų spragas. Kadangi DAST nežino, kurį atvirąjį šaltinį naudojame, jis tiesiog meta „kenkėjiškus“ šablonus ir analizuoja serverio atsakymus:
- Taip, čia yra deserializacijos problema, bet ne čia.
Tai turi didelę riziką, nes jei atliksite šį saugumo testą tame pačiame stende, su kuriuo dirba bandytojai, gali nutikti nemalonių dalykų.
- Didelė apkrova taikomųjų programų serverių tinkle.
- Jokių integracijų.
- Galimybė keisti analizuojamos programos nustatymus.
- Nėra paramos reikalingoms technologijoms.
- Sunkumai nustatant.
Susidūrėme su situacija, kai pagaliau paleidome „AppScan“: ilgai bandėme pasiekti programą, gavome 3 paskyras ir buvome laimingi – pagaliau viską patikrinsime! Pradėjome nuskaitymą ir pirmas dalykas, kurį „AppScan“ padarė, buvo įeiti į administratoriaus skydelį, pradurti visus mygtukus, pakeisti pusę duomenų ir visiškai užmušti serverį. - prašymai. Kūrimas su bandymais sakė:
- Vaikinai, ar juokaujate?! Mes davėme jums sąskaitas, o jūs pastatėte stendą!
Apsvarstykite galimus pavojus. Idealiu atveju paruoškite atskirą stendą informacijos saugumo testavimui, kuris bus bent kažkaip izoliuotas nuo likusios aplinkos ir sąlygiškai patikrinkite admin panelę, geriausia rankiniu režimu. Tai pentestas – tie likę pastangų procentai, kurių dabar nesvarstome.
Verta manyti, kad tai galite naudoti kaip apkrovos testavimo analogą. Pirmajame etape galite įjungti dinaminį skaitytuvą su 10–15 gijų ir pamatyti, kas atsitiks, tačiau paprastai, kaip rodo praktika, nieko gero.
Keletas išteklių, kuriuos paprastai naudojame.
Verta pabrėžti yra „šveicariškas peilis“ bet kuriam apsaugos specialistui. Visi juo naudojasi ir tai labai patogu. Dabar buvo išleista nauja įmonės leidimo demonstracinė versija. Jei anksčiau tai buvo tik atskira programa su papildiniais, tai dabar kūrėjai pagaliau sukuria didelį serverį, iš kurio bus galima valdyti kelis agentus. Tai šaunu, rekomenduoju išbandyti.
Proceso integravimas
Integracija vyksta gana gerai ir paprastai: sėkmingai įdiegę pradėkite nuskaitymą paraiškos stendui ir nuskaitymas po sėkmingo integravimo bandymo.
Jei integracijos neveikia arba yra stuburo ir apgaulingų funkcijų, tai beprasmiška ir nenaudinga – nesvarbu, kokį šabloną siųsime, serveris vis tiek reaguos taip pat.
- Idealiu atveju atskiras bandymų stendas.
- Prieš testuodami užsirašykite prisijungimo seką.
- Administravimo sistemos testavimas atliekamas tik rankiniu būdu.
procesas
Šiek tiek apibendrintai apie procesą apskritai ir apie kiekvieno įrankio darbą konkrečiai. Visos programos yra skirtingos – viena geriau veikia su dinamine analize, kita su statine analize, trečia su OpenSource analize, pentestais ar dar kažkuo, pavyzdžiui, įvykiai su .
Kiekvienam procesui reikia kontrolės.
Kad suprastumėte, kaip veikia procesas ir kur jį galima patobulinti, turite rinkti metriką iš visko, kas tik įmanoma, įskaitant gamybos metriką, įrankių metriką ir defektų stebėjimo priemones.
Bet kokia informacija naudinga. Reikia iš įvairių pusių pažvelgti, kur geriau panaudoti tą ar kitą priemonę, kur konkrečiai smunka procesas. Galbūt verta pažvelgti į kūrimo reakcijos laiką, kad pamatytumėte, kur patobulinti procesą atsižvelgiant į laiką. Kuo daugiau duomenų, tuo daugiau skyrių galima sukurti nuo aukščiausio lygio iki kiekvieno proceso detalių.
Kadangi visi statiniai ir dinaminiai analizatoriai turi savo API, savo paleidimo būdus, principus, vieni turi planuoklius, kiti neturi – rašome įrankį „AppSec Orchestrator“., kuri leidžia iš produkto sukurti vieną įėjimo į visą procesą tašką ir valdyti jį iš vieno taško.
Vadovai, kūrėjai ir saugos inžinieriai turi vieną įėjimo tašką, iš kurio jie gali matyti, kas veikia, konfigūruoti ir vykdyti nuskaitymą, gauti nuskaitymo rezultatus ir pateikti reikalavimus. Stengiamės nutolti nuo popierizmo, viską išversti į žmogišką, kurią naudoja kūrimas - puslapiai apie Confluence su būsena ir metrika, Jira ar įvairių defektų sekimo priemonių defektai arba integracija į sinchroninį / asinchroninį procesą CI. /CD.
Pagrindiniai taksieji
Įrankiai nėra pagrindinis dalykas. Pirmiausia pagalvokite apie procesą – tada įgyvendinkite įrankius. Priemonės yra geros, bet brangios, todėl galite pradėti nuo proceso ir užmegzti ryšį bei supratimą tarp plėtros ir saugumo. Saugumo požiūriu nereikia visko "stabdyti". Plėtros požiūriu, jei yra kažkas aukšto mega superkritinio, tai jį reikia šalinti, o ne užmerkti akis į problemą.
Produkto kokybė - bendras tikslas tiek saugumui, tiek plėtrai. Mes darome vieną dalyką – stengiamės, kad viskas veiktų teisingai ir nekiltų reputacijos rizikos ar finansinių nuostolių. Štai kodėl mes reklamuojame DevSecOps, SecDevOps metodą, kad pagerintume komunikaciją ir pagerintume produkto kokybę.
Pradėkite nuo to, ką jau turite: reikalavimai, architektūra, daliniai patikrinimai, mokymai, gairės. Nereikia nedelsiant taikyti visų praktikų visiems projektams - judėti iteratyviai. Nėra vieno standarto - eksperimentas ir išbandyti įvairius metodus bei sprendimus.
Tarp informacijos saugumo defektų ir funkcinių defektų yra lygybės ženklas.
Automatizuoti viskąkad juda. Kas nejuda, perkelkite ir automatizuokite. Jei kažkas daroma rankomis, tai nėra gera proceso dalis. Galbūt verta jį peržiūrėti ir automatizuoti.
Jei IS komandos dydis mažas - naudokite saugumo čempionus.
Galbūt tai, apie ką kalbėjau, jums netiks ir jūs sugalvosite ką nors savo - ir tai gerai. Bet pasirinkti įrankius pagal savo proceso reikalavimus. Nežiūrėkite, ką sako bendruomenė, kad ši priemonė bloga, o ši gera. Galbūt jūsų produktui bus atvirkščiai.
Reikalavimai įrankiams.
- Žemas lygis Klaidingai teigiamas.
- Pakankamas analizės laikas.
- Naudojimo patogumas.
- Integracijų prieinamumas.
- Produkto kūrimo plano supratimas.
- Galimybė pritaikyti įrankius pagal užsakymą.
Jurijaus pranešimas buvo išrinktas vienu geriausių DevOpsConf 2018. Norėdami susipažinti su dar įdomesnėmis idėjomis ir praktiniais atvejais, atvykite į Skolkovo gegužės 27 ir 28 d. viduje . Dar geriau, jei esate pasirengęs pasidalinti savo patirtimi ataskaitai iki balandžio 21 d.
Šaltinis: www.habr.com