Imali smo 2 analizatora koda, 4 alata za dinamičko testiranje, vlastite rukotvorine i 250 skripti. Nije da je sve ovo bilo potrebno u trenutnom procesu, ali kada počnete da implementirate DevSecOps, morate ići do kraja.
. Likove kreirali Justin Roiland i Dan Harmon.
Šta je SecDevOps? Šta je sa DevSecOps-om? Koje su razlike? Sigurnost aplikacija - o čemu se radi? Zašto klasični pristup više ne funkcioniše? Sva ova pitanja znaju odgovor Yuri Shabalin из Swordfish Security. Yuriy će na sve detaljno odgovoriti i analizirati probleme prijelaza s klasičnog modela sigurnosti aplikacija na proces DevSecOps: kako pravilno pristupiti integraciji sigurnog razvojnog procesa u DevOps proces i ne prekinuti ništa, kako proći kroz glavne faze sigurnosnog testiranja, koji alati se mogu koristiti, kako se razlikuju i kako ih pravilno konfigurirati kako bi se izbjegle zamke.
O zvučniku: Jurij Šabalin - Glavni sigurnosni arhitekta u kompaniji Swordfish Security. Odgovoran za implementaciju SSDL-a, za cjelokupnu integraciju alata za analizu aplikacija u jedinstven razvojni i testni ekosistem. 7 godina iskustva u informacionoj sigurnosti. Radio je u Alfa-Bank, Sberbanci i Positive Technologies, koja razvija softver i pruža usluge. Govornik međunarodnih konferencija ZerONights, PHDays, RISSPA, OWASP.
Sigurnost aplikacija: o čemu se radi?
Sigurnost aplikacija je sigurnosni odjeljak koji je odgovoran za sigurnost aplikacije. Ne radi se o infrastrukturi ili sigurnosti mreže, već o tome šta pišemo i na čemu rade programeri - to su nedostaci i ranjivosti same aplikacije.
Destinacija - Životni ciklus razvoja sigurnosti - Razvio Microsoft. Dijagram prikazuje kanonski SDLC model, čiji je glavni zadatak učešće sigurnosti u svakoj fazi razvoja, od zahtjeva, preko izdavanja i puštanja u proizvodnju. Microsoft je shvatio da ima previše grešaka na maturalnoj večeri, da ih je više i da se nešto mora učiniti po tom pitanju, te su predložili ovaj pristup koji je postao kanonski.
Sigurnost aplikacija i SSDL nisu usmjereni na otkrivanje ranjivosti, kako se uobičajeno vjeruje, već na sprječavanje njihovog nastanka. S vremenom je kanonski pristup iz Microsofta poboljšan, razvijen, ima dublje detaljnije uranjanje.
Kanonski SDLC je vrlo detaljan u različitim metodologijama - OpenSAMM, BSIMM, OWASP. Metodologije se razlikuju, ali su generalno slične.
Model izgradnje sigurnosti u zrelosti
Najviše mi se sviđa BSIMM - . Osnova metodologije je podjela procesa sigurnosti aplikacije na 4 domena: upravljanje, inteligencija, SSDL dodirne tačke i implementacija. Svaka domena ima 12 praksi, koje su predstavljene kao 112 aktivnosti.
Svaka od 112 aktivnosti ima 3 stepena zrelosti: početni, srednji i napredni. Možete proučavati svih 12 praksi u sekcijama, odabrati stvari koje su vam važne, smisliti kako ih implementirati i postepeno dodavati elemente, na primjer, statičku i dinamičku analizu koda ili pregled koda. Sastavljate plan i mirno radite po njemu u sklopu realizacije odabranih aktivnosti.
Zašto DevSecOps
DevOps je sveukupno veliki proces u kojem treba voditi računa o sigurnosti.
u početku uključivale sigurnosne provjere. U praksi je broj sigurnosnih timova bio znatno manji nego sada, a oni nisu djelovali kao učesnici u procesu, već kao kontrolno i nadzorno tijelo koje mu postavlja zahtjeve i provjerava kvalitet proizvoda na kraju puštanja u promet. Ovo je klasičan pristup u kojem su sigurnosni timovi bili iza zida od razvoja i nisu učestvovali u procesu.
Glavni problem je što je sigurnost informacija odvojena od razvoja. Obično je ovo neka vrsta IB kola i sadrži 2-3 velika i skupa alata. Jednom u šest mjeseci, izvorni kod ili aplikacija stiže na testiranje, i to jednom godišnje . Sve to dovodi do činjenice da su datumi izlaska za industriju odgođeni, a veliki broj ranjivosti automatiziranih alata pada na programera. Nemoguće je sve ovo rastaviti i popraviti, jer ni u prethodnih šest meseci rezultati nisu demontirani, a evo nove serije.
U toku rada naše kompanije vidimo da bezbednost u svim oblastima i industrijama shvata da je vreme da sustignemo i zavrtimo razvoj u jednom točku - u . DevSecOps paradigma se savršeno uklapa u agilnu razvojnu metodologiju, implementaciju, podršku i učešće u svakom izdanju i iteraciji.
Prijelaz na DevSecOps
Najvažnija riječ u životnom ciklusu razvoja sigurnosti je "proces". Ovo morate razumjeti prije nego što razmislite o kupovini alata.
Samo uključivanje alata u DevOps proces nije dovoljno – komunikacija i razumijevanje između učesnika procesa su važni.
Ljudi su važniji od alata
Često planiranje sigurnog razvojnog procesa počinje odabirom i kupovinom alata, a završava se pokušajima integracije alata u tekući proces, koji ostaju pokušaji. To dovodi do tužnih posljedica, jer svi alati imaju svoje karakteristike i ograničenja.
Uobičajeni slučaj je kada je odjel sigurnosti odabrao dobar, skup alat sa širokim spektrom funkcija i došao do programera da ga ugrade u proces. Ali ne ide - proces je dizajniran na način da se ograničenja već kupljenog instrumenta ne uklapaju u trenutnu paradigmu.
Prvo opišite kakav rezultat želite i kako će proces izgledati. Ovo će pomoći da se razumiju uloge alata i sigurnosti u procesu.
Počnite s onim što je već u upotrebi
Prije kupovine skupih alata, pogledajte šta već imate. Svaka kompanija ima sigurnosne zahtjeve koji se odnose na razvoj, postoje provjere, testovi penetracije - zašto sve to ne pretvoriti u razumljiv i pogodan oblik za svakoga?
Obično su zahtjevi papirni Talmud koji leži na polici. Bio je slučaj kada smo došli u kompaniju da pogledamo procese i zamolimo da nam pokažu bezbednosne zahteve za softver. Specijalista koji je ovo uradio dugo je tražio:
- E sad, negde u beleškama je bila staza gde leži ovaj dokument.
Kao rezultat toga, dobili smo dokument nedelju dana kasnije.
Za zahtjeve, provjere i više, kreirajte stranicu, na primjer na Sotočje - zgodno je za sve.
Lakše je preformatirati ono što je već tu i koristiti to za početak.
Koristite Security Champions
Obično, u prosječnoj kompaniji za 100-200 programera, postoji jedan službenik sigurnosti koji obavlja nekoliko funkcija i nema fizički vremena da sve provjeri. Čak i ako se potrudi, on sam neće provjeriti sav kod koji razvoj generiše. Za takve slučajeve razvijen je koncept - .
Security Champions je osoba unutar razvojnog tima koja je zainteresirana za sigurnost vašeg proizvoda.
Bezbjednosni šampion je ulazna tačka za razvojni tim i bezbednosni evanđelista, svi zajedno.
Obično, kada službenik sigurnosti dođe u razvojni tim i ukaže na grešku u kodu, dobije iznenađen odgovor:
- I ko si ti? Vidim te prvi put. Sve je u redu sa mnom - moj stariji prijatelj je stavio "prijavi" na pregled koda, idemo dalje!
Ovo je tipična situacija, jer postoji mnogo više povjerenja u seniore ili samo saigrače s kojima programer stalno komunicira na poslu i u pregledu koda. Ako umjesto zaštitara Šampion sigurnosti ukaže na grešku i posljedice, tada će njegova riječ imati veću težinu.
Takođe, programeri znaju svoj kod bolje od bilo kog bezbednosnog tipa. Za osobu koja ima najmanje 5 projekata u alatu za statičku analizu, obično je teško zapamtiti sve nijanse. Bezbednosni šampioni znaju svoj proizvod: šta je u interakciji sa čime i na šta treba obratiti pažnju – efikasniji su.
Stoga razmislite o implementaciji Security Champions i proširenju utjecaja sigurnosnog tima. Za samog šampiona, ovo je takođe korisno: profesionalni razvoj u novoj oblasti, širenje tehničkih horizonata, pumpanje tehničkih, menadžerskih i liderskih veština, povećanje tržišne vrednosti. Ovo je neki element društvenog inženjeringa, vaše "oči" u razvojnom timu.
Faze testiranja
kaže da 20% napora daje 80% rezultata. Ovih 20% su prakse analize aplikacija koje se mogu i trebaju automatizirati. Primjeri takvih aktivnosti su statička analiza − SAST, dinamička analiza — DAST и kontrola otvorenog koda. Reći ću vam više o aktivnostima, kao i o alatima, s kojim se karakteristikama obično susrećemo kada ih uvedemo u proces i kako to ispravno raditi.
Glavni problemi sa alatom
Istaknut ću probleme koji su relevantni za sve instrumente koji zahtijevaju pažnju. Ja ću ih detaljnije analizirati da se ne ponavljam dalje.
Dugo vreme analize. Ako je potrebno 30 minuta za sve testove i sklapanje od urezivanja do puštanja za proizvodnju, tada će provjere sigurnosti informacija trajati jedan dan. Tako da niko neće usporiti proces. Razmotrite ovu osobinu i izvucite zaključke.
Visoki lažno negativan ili lažno pozitivan. Svi proizvodi su različiti, svi koriste različite okvire i vlastiti stil kodiranja. Na različitim bazama koda i tehnologijama, alati mogu pokazati različite nivoe lažno negativnih i lažno pozitivnih. Pa pogledajte šta je unutra your kompanije i za vaša aplikacije će pokazati dobar i pouzdan rezultat.
Nema integracije sa postojećim alatima. Pogledajte alate u smislu integracije sa onim što već koristite. Na primjer, ako imate Jenkins ili TeamCity, provjerite integraciju alata sa ovim softverom, a ne sa GitLab CI, koji ne koristite.
Nedostatak ili prekomjerna složenost prilagođavanja. Ako alat nema API, zašto je onda potreban? Sve što se može uraditi u interfejsu treba da bude dostupno preko API-ja. U idealnom slučaju, alat bi trebao imati mogućnost prilagođavanja provjera.
Nema plana razvoja proizvoda. Razvoj ne miruje, uvijek koristimo nove okvire i funkcije, prepisujemo stari kod u nove jezike. Želimo biti sigurni da će alat koji kupujemo podržavati nove okvire i tehnologije. Stoga je važno znati da proizvod ima pravi i ispravan razvoj.
Procesne funkcije
Pored karakteristika alata, razmotrite karakteristike procesa razvoja. Na primjer, ometanje razvoja je tipična greška. Hajde da vidimo koje druge karakteristike treba uzeti u obzir i na šta bezbednosni tim treba da obrati pažnju.
Kako ne biste poremetili razvoj i rokove puštanja, kreirajte drugačija pravila i drugačije pokazati stopere - kriterijumi za zaustavljanje procesa izgradnje u prisustvu ranjivosti - za različita okruženja. Na primjer, razumijemo da trenutna grana ide na razvojni štand ili UAT, tako da ne stanemo i kažemo:
- Ovdje imate ranjivosti, nećete nigdje dalje!
U ovom trenutku, važno je reći programerima da postoje sigurnosni problemi na koje treba obratiti pažnju.
Prisustvo ranjivosti nije prepreka za dalje testiranje: ručno, integracijsko ili ručno. S druge strane, moramo nekako poboljšati sigurnost proizvoda, a da programeri ne boduju po onome što sigurnost pronađe. Stoga, ponekad radimo ovo: na štandu, kada se pokrene u razvojno okruženje, jednostavno obavještavamo razvoj:
- Ljudi, imate problema, obratite pažnju na njih.
U fazi UAT-a ponovo prikazujemo upozorenja o ranjivosti, a na izlaznoj fazi maturalne večeri kažemo:
“Momci, upozoravali smo vas nekoliko puta, ništa niste uradili – nećemo vas pustiti sa ovim.
Ako govorimo o kodu i dinamici, onda je potrebno pokazati i upozoriti na ranjivosti samo onih karakteristika i koda koji je upravo napisan u ovoj funkciji. Ako je programer pomaknuo dugme za 3 piksela i mi mu kažemo da tamo ima SQL injekciju i da ga stoga treba hitno popraviti, ovo je pogrešno. Pogledajte samo ono što je sada napisano, i promjenu koja dolazi u aplikaciji.
Recimo da imamo neki funkcionalni nedostatak – način na koji aplikacija ne treba da radi: novac se ne prenosi, kada kliknete na dugme, nema prelaska na sledeću stranicu ili se proizvod ne učitava. Sigurnosni nedostaci - radi se o istim nedostacima, ali ne u kontekstu aplikacije, već sigurnosti.
Nisu svi problemi s kvalitetom softvera sigurnosni. Ali svi sigurnosni problemi povezani su s kvalitetom softvera. Šerif Mansour, Expedia.
Pošto su sve ranjivosti isti nedostaci, trebalo bi da se nalaze na istom mestu kao i svi razvojni nedostaci. Zato zaboravite na izvještaje i strašne PDF-ove koje niko ne čita.
Kada sam radio za razvojnu kompaniju, dobio sam izvještaj od alata za statičku analizu. Otvorio sam ga, zgrozio se, skuvao kafu, prelistao 350 stranica, zatvorio i nastavio na posao. Veliki izvještaji su mrtvi izvještaji. Obično ne idu nikuda, e-poruke se brišu, zaboravljaju, gube ili kompanija kaže da preuzima rizik.
sta da radim? Jednostavno konvertujemo potvrđene nedostatke koje smo pronašli u oblik pogodan za razvoj, na primjer, dodamo ga u zaostatak u Jira. Defekti su prioritetni i eliminisani po prioritetu zajedno sa funkcionalnim defektima i defektima testa.
Statička analiza - SAST
Ovo je analiza koda za ranjivosti., ali nije isto što i SonarQube. Ne provjeravamo samo uzorke ili stil. Analiza koristi nekoliko pristupa: po stablu ranjivosti, po , analizom konfiguracijskih datoteka. To je sve za sam kod.
Prednosti pristupa: prepoznavanje ranjivosti u kodu u ranoj fazi razvojakada nema postolja i gotovih alata, i mogućnost inkrementalnog skeniranja: skenira dio koda koji se promijenio i samo funkciju koju trenutno radimo, što skraćuje vrijeme skeniranja.
Minusy je nedostatak podrške za tražene jezike.
Potrebne integracije, koji bi trebao biti u alatima, po mom subjektivnom mišljenju:
- Alat za integraciju: Jenkins, TeamCity i Gitlab CI.
- Razvojno okruženje: Intellij IDEA, Visual Studio. Programeru je zgodnije da se ne penje u nerazumljivo sučelje koje još treba zapamtiti, već da vidi sve potrebne integracije i ranjivosti koje je pronašao na radnom mjestu u vlastitom razvojnom okruženju.
- Pregled koda: SonarQube i ručni pregled.
- Praćenje grešaka: Jira i Bugzilla.
Na slici su neki od najboljih predstavnika statičke analize.
Nisu bitni alati, već proces, tako da postoje rješenja otvorenog koda koja su također dobra za pokretanje procesa.
SAST Open Source neće pronaći veliki broj ranjivosti ili složenog protoka podataka, ali ih se može i treba koristiti prilikom izgradnje procesa. Oni pomažu da se shvati kako će se proces izgraditi, ko će odgovoriti na greške, ko će prijaviti, ko će prijaviti. Ako želite izvršiti početnu fazu izgradnje sigurnosti vašeg koda, koristite rješenja otvorenog koda.
Kako se ovo može integrirati ako ste na početku putovanja, nemate ništa: ni CI, ni Jenkins, ni TeamCity? Razmislite o integraciji procesa.
Integracija na nivou CVS
Ako imate Bitbucket ili GitLab, možete izvršiti integraciju na nivou .
Po događaju zahtjev za povlačenjem, urezivanje. Skenirate kod i prikazujete u statusu izrade da je sigurnosna provjera prošla ili nije uspjela.
Povratne informacije. Naravno, povratna informacija je uvijek potrebna. Ako ste to samo uradili sa sigurnosne strane, stavili u kutiju i nikome ništa o tome niste rekli, a zatim izbacili gomilu grešaka na kraju mjeseca, ovo nije u redu i nije dobro.
Integracija sa sistemom za pregled koda
Jednom smo postavili AppSec tehničkog korisnika kao zadanog recenzenta u nizu važnih projekata. U zavisnosti od toga da li su pronađene greške u novom kodu ili nema grešaka, recenzent postavlja status na pull request "prihvatam" ili "treba raditi" - ili je sve u redu, ili treba finalizirati i povezivati se na šta točno finalizirati. Za integraciju sa verzijom koja se izdaje, onemogućili smo spajanje ako IS test nije prošao. Uključili smo ovo u ručni pregled koda, a ostali učesnici procesa su vidjeli sigurnosne statuse za ovaj konkretni proces.
Integracija sa SonarQube
Mnogi jesu u smislu kvaliteta koda. I ovdje je isto - iste kapije možete napraviti samo za SAST instrumente. Biće isti interfejs, isti kvalitet kapije, samo što će se zvati sigurnosna kapija. Takođe, ako imate proces postavljen pomoću SonarQube-a, možete lako integrirati sve tamo.
Integracija na nivou CI
I ovdje je sve prilično jednostavno:
- U rangu sa autotestovima, jedinični testovi.
- Podjela po fazama razvoja: dev, test, prod. Mogu biti uključeni različiti skupovi pravila ili različiti uslovi neuspjeha: zaustavljamo montažu, ne zaustavljamo montažu.
- Sinhroni/asinkroni rad. Čekamo završetak sigurnosnih testova ili ne čekamo. Odnosno, samo smo ih pokrenuli i idemo dalje, a onda dobijemo status da je sve dobro ili loše.
Sve je u savršenom ružičastom svijetu. U stvarnom životu to nije slučaj, ali mi se trudimo. Rezultat izvođenja sigurnosnih provjera trebao bi biti sličan rezultatima jediničnih testova.
Na primjer, uzeli smo veliki projekat i odlučili da ćemo ga sada skenirati sa SAST-om - OK. Ugurali smo ovaj projekat u SAST, dao nam je 20 ranjivosti i donijeli smo čvrstu odluku da je sve u redu. 000 ranjivosti je naš tehnički dug. Stavićemo dug u kutiju, polako ćemo ga zgrabiti i pokrenuti bagove u defekt trackerima. Angažirajte kompaniju, uradite sve sami ili neka nam pomognu Sigurnosni šampioni i tehnički dug će se smanjiti.
I sve novonastale ranjivosti u novom kodu treba da budu eliminisane na isti način kao i greške u jedinici ili u autotestovima. Relativno govoreći, montaža je krenula, odvezla se, pala su dva testa i dva sigurnosna. OK - otišli smo, pogledali šta se desilo, ispravili jedno, ispravili drugo, odvezli se drugi put - sve je u redu, nisu se pojavile nove ranjivosti, testovi nisu pali. Ako je ovaj zadatak dublji i trebate ga dobro razumjeti, ili popravljanje ranjivosti utječe na velike slojeve onoga što se nalazi ispod haube: greška se unosi u detektor za praćenje grešaka, ona se daje prioritet i ispravlja. Nažalost, svijet nije savršen i testovi ponekad ne uspijevaju.
Primjer sigurnosne kapije je analogni kvalitetnoj kapiji, u smislu prisutnosti i broja ranjivosti u kodu.
Integriramo se sa SonarQube - dodatak je instaliran, sve je vrlo zgodno i cool.
Integracija razvojnog okruženja
Opcije integracije:
- Pokretanje skeniranja iz razvojnog okruženja čak i prije urezivanja.
- Pogledaj rezultate.
- Analiza rezultata.
- Sinhronizacija sa serverom.
Ovako izgleda dobijanje rezultata sa servera.
U našem razvojnom okruženju samo se pojavljuje dodatna stavka koja kaže da su takve ranjivosti pronađene tokom skeniranja. Možete odmah urediti kod, pogledati preporuke i . Sve se to nalazi na radnom mjestu programera, što je vrlo zgodno - ne morate pratiti ostale linkove i gledati nešto dodatno.
Open Source
Ovo je moja omiljena tema. Svi koriste biblioteke otvorenog koda - zašto pisati gomilu štaka i bicikala kada možete uzeti gotovu biblioteku u kojoj je sve već implementirano?
Naravno, to je tačno, ali biblioteke pišu i ljudi, uključuju i određene rizike, a postoje i ranjivosti o kojima se periodično ili stalno prijavljuju. Stoga, postoji sljedeći korak u sigurnosti aplikacija - ovo je analiza komponenti otvorenog koda.
Analiza otvorenog koda - OSA
Alat uključuje tri glavna koraka.
Pronalaženje ranjivosti u bibliotekama. Na primjer, alat zna da koristimo neku vrstu biblioteke i to u ili u programima za praćenje grešaka postoje neke ranjivosti koje se odnose na ovu verziju biblioteke. Ako pokušate da ga koristite, alat će vas upozoriti da je biblioteka ranjiva i savetovati vam da koristite drugu verziju u kojoj nema ranjivosti.
Analiza čistoće licence. Ovo kod nas još nije jako popularno, ali ako radite sa stranom državom, tamo možete povremeno dobiti napad zbog korištenja komponente otvorenog koda koja se ne može koristiti ili modificirati. Prema politici licencirane biblioteke, to ne možemo učiniti. Ili, ako smo ga izmijenili i koristili, moramo objaviti naš kod. Naravno, niko ne želi objaviti šifru svojih proizvoda, ali se od ovoga možete i zaštititi.
Analiza komponenti koje se koriste u industrijskom okruženju. Zamislite hipotetičku situaciju da smo konačno završili razvoj i pustili najnovije izdanje našeg mikroservisa za industriju. Živi tamo divno - sedmicu, mjesec, godinu. Ne prikupljamo, ne vršimo sigurnosne provjere, čini se da je sve u redu. Ali iznenada, dvije sedmice nakon objavljivanja, pojavljuje se kritična ranjivost komponente otvorenog koda, koju koristimo u ovom konkretnom sklopu, u industrijskom okruženju. Ako ne bilježimo šta i gdje koristimo, onda se ta ranjivost jednostavno neće vidjeti. Neki alati imaju mogućnost praćenja ranjivosti u bibliotekama koje se trenutno koriste na maturalnoj večeri. Veoma je korisno.
Karakteristike:
- Različite politike za različite faze razvoja.
- Nadgledajte komponente u industrijskom okruženju.
- Kontrola biblioteka u konturi organizacije.
- Podrška za različite sisteme izgradnje i jezike.
- Analiza Docker slika.
Nekoliko primjera lidera u ovoj oblasti koji se bave analizom otvorenog koda.
Jedina besplatna je od OWASP. Možete ga uključiti u prvim fazama, vidjeti kako radi i šta podržava. U osnovi, sve su to proizvodi u oblaku, ili on-premise, ali iza svoje baze oni i dalje idu na internet. Oni ne šalju vaše biblioteke, već hasheve ili njihove vrijednosti koje izračunaju i otiske prstiju svom serveru kako bi primili vijesti o prisutnosti ranjivosti.
Integracija procesa
Kontrola biblioteke perimetrakoji se preuzimaju sa eksternih izvora. Imamo eksterna i interna spremišta. Na primjer, imamo Nexus unutar Event Centrala i želimo biti sigurni da nema ranjivosti sa "kritičnim" ili "visokim" statusom unutar našeg spremišta. Možete postaviti proxy korištenjem alata Nexus Firewall Lifecycle alata tako da takve ranjivosti budu odsječene i ne uključene u interno spremište.
CI integracija. Na istoj razini sa autotestovima, jediničnim testovima i podjelom na razvojne faze: dev, test, prod. U svakoj fazi možete preuzeti bilo koju biblioteku, koristiti bilo šta, ali ako je nešto teško sa statusom „kritično“, vjerovatno biste trebali skrenuti pažnju programera na to u fazi ulaska na maturalnu večer.
Integracija artefakata: Nexus i JFrog.
Integracija u razvojno okruženje. Alati koje odaberete treba da imaju integraciju sa razvojnim okruženjima. Programer mora imati pristup rezultatima skeniranja sa svog radnog mjesta ili mogućnost skeniranja i provjere koda za ranjivosti prije nego što ga unese u CVS.
CD integracija. Ovo je super karakteristika koja mi se jako sviđa i o kojoj sam već govorio – praćenje pojave novih ranjivosti u industrijskom okruženju. Radi ovako.
Imamo Javna spremišta komponenti - neki alati izvana i naše interno spremište. Želimo da u njemu budu samo pouzdane komponente. Prilikom proxyja zahtjeva, provjeravamo da preuzeta biblioteka nema ranjivosti. Ako potpada pod određene politike koje postavljamo i nužno koordiniramo s razvojem, onda ga ne prenosimo i dobijamo odbijenicu da koristimo drugu verziju. Shodno tome, ako postoji nešto stvarno kritično i loše u biblioteci, programer neće dobiti biblioteku čak ni u fazi instalacije - neka koristi verziju višu ili nižu.
- Prilikom izrade provjeravamo da niko nije provukao ništa loše, da su sve komponente sigurne i da niko nije unio ništa opasno na fleš disk.
- Imamo samo pouzdane komponente u spremištu.
- Prilikom implementacije još jednom provjeravamo sam paket: war, jar, DL ili Docker image da li je u skladu sa politikom.
- Prilikom ulaska u industrijsko okruženje, pratimo šta se dešava u industrijskom okruženju: pojavljuju se ili ne pojavljuju kritične ranjivosti.
Dinamička analiza - DAST
Alati za dinamičku analizu su fundamentalno drugačiji od svega što je ranije rečeno. Ovo je svojevrsna imitacija rada korisnika sa aplikacijom. Ako se radi o web aplikaciji, šaljemo zahtjeve koji imitiraju rad klijenta, kliknemo na dugmad na prednjoj strani, šaljemo umjetne podatke iz obrasca: navodnike, zagrade, znakove u različitim kodovima kako bismo pogledali kako aplikacija radi i obrađuje eksterne podaci.
Isti sistem vam omogućava da provjerite ranjivosti šablona u otvorenom kodu. Pošto DAST ne zna koji Open Source koristimo, on jednostavno baca "zlonamjerne" obrasce i analizira odgovore servera:
- Da, ovdje postoji problem deserijalizacije, ali ne ovdje.
U tome postoje veliki rizici, jer ako ovaj sigurnosni test provedete na istom štandu s kojim rade testeri, mogu se dogoditi neugodne stvari.
- Visoko opterećenje na mreži aplikacijskog servera.
- Nema integracija.
- Mogućnost promjene postavki analizirane aplikacije.
- Ne postoji podrška za potrebne tehnologije.
- Poteškoće pri postavljanju.
Imali smo situaciju kada smo konačno pokrenuli AppScan: dugo smo isključili pristup aplikaciji, dobili 3 računa i bili smo oduševljeni - konačno ćemo sve provjeriti! Pokrenuli smo skeniranje, a prva stvar koju je AppScan uradio je ušao u admin panel, probio sve dugmad, promijenio polovicu podataka, a zatim ubio server svojim vlastitim -zahtjevi. Development with Testing je rekao:
“Momci, da li me zezate?! Dali smo vam račune, a vi ste stali!
Razmotrite moguće rizike. U idealnom slučaju, pripremite poseban štand za testiranje informacione sigurnosti, koji će se barem nekako izolirati od ostatka okruženja i uvjetno provjeriti admin panel, po mogućnosti u ručnom načinu rada. Ovo je pentest - oni preostali procenti napora koje sada ne razmatramo.
Vrijedno je uzeti u obzir da ovo možete koristiti kao analogno testiranje opterećenja. U prvoj fazi možete uključiti dinamički skener u 10-15 niti i vidjeti što se događa, ali obično, kao što praksa pokazuje, ništa dobro.
Nekoliko resursa koje obično koristimo.
Vrijedi istaknuti je "švajcarski nož" za svakog profesionalca u oblasti bezbednosti. Svi ga koriste i veoma je zgodno. Nova demo verzija izdanja za preduzeća je sada objavljena. Ako je ranije to bio samo samostalni uslužni program sa dodacima, sada programeri konačno prave veliki server sa kojeg će biti moguće upravljati nekoliko agenata. Super je, preporučujem da probate.
Integracija procesa
Integracija je prilično dobra i jednostavna: pokrenite skeniranje nakon uspješne instalacije aplikacije na štandu i skeniranje nakon uspješnog integracijskog testiranja.
Ako integracije ne rade ili postoje stubovi i lažne funkcije, to je besmisleno i beskorisno - bez obzira koji obrazac pošaljemo, server će i dalje odgovoriti na isti način.
- U idealnom slučaju, zasebna ispitna ploča.
- Prije testiranja, zapišite redoslijed prijave.
- Testiranje administrativnog sistema je samo ručno.
proces
Malo generalizirano o procesu općenito i o radu svakog alata, posebno. Sve aplikacije su različite – jedna radi bolje sa dinamičkom analizom, druga sa statičkom analizom, treća sa OpenSource analizom, pentestom ili nečim drugim općenito, na primjer, događaji sa .
Svaki proces treba kontrolisati.
Da biste razumjeli kako proces funkcionira i gdje se može poboljšati, morate prikupiti metriku od svega što vam može doći, uključujući proizvodne metrike, metrike iz alata i detektore grešaka.
Svaka informacija je od pomoći. Potrebno je pogledati u različitim odjeljcima gdje se ovaj ili onaj alat bolje koristi, gdje proces posebno pada. Možda bi bilo vrijedno pogledati vrijeme odgovora razvoja kako biste vidjeli gdje poboljšati proces na osnovu vremena. Što više podataka, to se više rezova može napraviti od najvišeg nivoa do detalja svakog procesa.
Pošto svi statički i dinamički analizatori imaju svoje API-je, svoje metode pokretanja, principe, neki imaju planere, drugi ne - pišemo alat AppSec Orchestrator, koji vam omogućava da napravite jednu ulaznu tačku u cijeli proces od proizvoda i upravljate njime iz jedne točke.
Menadžeri, programeri i sigurnosni inženjeri imaju jednu ulaznu tačku iz koje mogu vidjeti što se pokreće, konfigurirati i pokrenuti skeniranje, dobiti rezultate skeniranja i podnijeti zahtjeve. Trudimo se da se odmaknemo od papirića, prevedemo sve u ljudsko ono što razvoj koristi - stranice na Konfluence sa statusom i metrikom, defekti u Jira ili u raznim defekt trackerima, ili ugrađivanje u sinhroni/asinhroni proces u CI/CD.
Key Takeaways
Alati nisu bitni. Prvo razmislite o procesu, a zatim implementirajte alate. Alati su dobri, ali skupi, tako da možete započeti s procesom i fino podesiti interakciju i razumijevanje između razvoja i sigurnosti. Sa sigurnosne tačke gledišta nema potrebe "zaustavljati" sve redom. Sa stanovišta razvoja, ako postoji nešto visoko mega super kritično, onda se to mora eliminisati, a ne zatvoriti problem .
Kvalitet proizvoda - zajednički cilj i sigurnost i razvoj. Radimo jednu stvar, trudimo se da sve funkcioniše kako treba i da nema reputacionih rizika i finansijskih gubitaka. Zato promovišemo pristup DevSecOps-u, SecDevOps-u kako bismo uspostavili komunikaciju i učinili proizvod boljim.
Počnite sa onim što već postoji: zahtjevi, arhitektura, djelomične provjere, obuke, smjernice. Nije potrebno odmah primijeniti sve prakse na sve projekte - kretati se iterativno. Ne postoji jedinstven standard eksperiment i isprobati različite pristupe i rješenja.
Znak jednakosti između IS defekata i funkcionalnih defekata.
Automatiziraj sveto se kreće. Sve što se ne kreće, kreće se i automatizira. Ako se nešto radi ručno, to nije dobar dio procesa. Možda je vrijedno ponovnog razmatranja i automatizacije.
Ako je veličina IB tima mala - koristite Security Champions.
Možda vam ovo o čemu sam pričao neće odgovarati pa ćete smisliti nešto svoje - i to je dobro. Ali izaberite alate na osnovu zahteva vašeg procesa. Ne gledajte šta zajednica kaže da je ovaj alat loš, a ovaj dobar. Možda će na vašem proizvodu biti obrnuto.
Zahtevi za alat.
- Low False Positive.
- Odgovarajuće vrijeme za analizu.
- Pogodnost upotrebe.
- Dostupnost integracija.
- Razumijevanje plana razvoja proizvoda.
- Mogućnost prilagođavanja alata.
Jurijev izvještaj izabran je kao jedan od najboljih na DevOpsConf 2018. Da biste se upoznali sa još zanimljivijim idejama i praktičnim slučajevima, dođite u Skolkovo 27. i 28. maja unutar . Još bolje, ako ste voljni podijeliti svoje iskustvo Podnesite svoj izvještaj do 21. aprila.
izvor: www.habr.com