Strah i prijezir prema DevSecOps-u

Imali smo 2 analizatora koda, 4 alata za dinamičko testiranje, vlastite rukotvorine i 250 skripti. Nije da je sve to potrebno u trenutnom procesu, ali kad jednom počnete implementirati DevSecOps, morate ići do kraja.

Источник. Tvorci likova: Justin Roiland i Dan Harmon.

Što je SecDevOps? Što je s DevSecOpsom? Koje su razlike? Sigurnost aplikacije - o čemu se radi? Zašto klasični pristup više ne funkcionira? Zna odgovor na sva ova pitanja Jurij Šabalin od Sigurnost Swordfish. Yuri će detaljno odgovoriti na sve i analizirati probleme prijelaza s klasičnog modela Application Security na DevSecOps proces: kako pravilno pristupiti integraciji sigurnog razvojnog procesa u DevOps proces i ne pokvariti ništa, kako proći kroz glavne faze sigurnosnog testiranja, koji se alati mogu koristiti, u čemu se razlikuju i kako ih ispravno konfigurirati da izbjegnete zamke.

O govorniku: Jurij Šabalin - Glavni arhitekt sigurnosti u tvrtki Sigurnost Swordfish. Odgovoran za implementaciju SSDL-a, za cjelokupnu integraciju alata za analizu aplikacija u objedinjeni ekosustav razvoja i testiranja. 7 godina iskustva u informacijskoj sigurnosti. Radio je u Alfa-Bank, Sberbank i Positive Technologies, koja razvija softver i pruža usluge. Govornik na međunarodnim konferencijama ZerONights, PHDays, RISSPA, OWASP.

Sigurnost aplikacije: o čemu se radi?

Sigurnost aplikacije - Ovo je sigurnosni dio koji je odgovoran za sigurnost aplikacije. Ovo se ne odnosi na infrastrukturu ili mrežnu sigurnost, već na ono što pišemo i na čemu programeri rade - to su nedostaci i ranjivosti same aplikacije.

smjer SDL ili SDLC - Životni ciklus razvoja sigurnosti - razvijen od strane Microsofta. Dijagram prikazuje kanonski SDLC model, čija je glavna zadaća sudjelovanje sigurnosti u svakoj fazi razvoja, od zahtjeva do izdanja i proizvodnje. Microsoft je shvatio da u industriji ima previše bugova, da ih je sve više i da se s tim nešto mora poduzeti, te su predložili ovaj pristup koji je postao kanonski.

Application Security i SSDL nisu usmjereni na otkrivanje ranjivosti, kao što se uobičajeno vjeruje, već na sprječavanje njihove pojave. S vremenom je Microsoftov kanonski pristup poboljšan, razvijen i uveden u dublje, detaljnije zaranjanje.

Kanonski SDLC vrlo je detaljan u različitim metodologijama - OpenSAMM, BSIMM, OWASP. Metodologije su različite, ali općenito slične.

Izgradnja sigurnosti u modelu zrelosti

Najviše mi se sviđa BSIMM - Izgradnja sigurnosti u modelu zrelosti. Osnova metodologije je podjela procesa Application Security u 4 domene: upravljanje, inteligencija, SSDL dodirne točke i implementacija. Svaka domena ima 12 praksi, koje su predstavljene kao 112 aktivnosti.

Svaka od 112 aktivnosti ima 3 stupnja zrelosti: početni, srednji i napredni. Možete proučavati svih 12 praksi odjeljak po odjeljak, odabrati stvari koje su vam važne, smisliti kako ih implementirati i postupno dodavati elemente, na primjer, statičku i dinamičku analizu koda ili pregled koda. Zapisujete plan i smireno radite po njemu u sklopu provedbe odabranih aktivnosti.

Zašto DevSecOps

DevOps je opći, veliki proces u kojem se mora voditi računa o sigurnosti.

U početku DevOps uključene sigurnosne provjere. U praksi je broj sigurnosnih timova bio znatno manji nego sada, a oni nisu bili sudionici procesa, već kontrolno-nadzorno tijelo koje postavlja zahtjeve i provjerava kvalitetu proizvoda na kraju puštanja u promet. Ovo je klasičan pristup u kojem su sigurnosni timovi bili iza zida od razvoja i nisu sudjelovali u procesu.

Glavni problem je što je informacijska sigurnost odvojena od razvoja. Obično je to neka vrsta sklopa za informacijsku sigurnost i sadrži 2-3 velika i skupa alata. Jednom u šest mjeseci stiže izvorni kod ili aplikacija koju je potrebno provjeriti, a jednom godišnje se izrađuju pentesti. Sve to dovodi do činjenice da je datum izlaska za industriju odgođen, a programer je izložen ogromnom broju ranjivosti automatiziranih alata. Sve je to nemoguće rastaviti i popraviti jer nisu sređeni rezultati za prethodnih šest mjeseci, ali evo nove serije.

Tijekom rada naše tvrtke vidimo da sigurnost u svim područjima i industrijama shvaća da je vrijeme za sustizanje i vrtenje razvoja na istom kotaču - u Okretan. Paradigma DevSecOps savršeno se uklapa s agilnom razvojnom metodologijom, implementacijom, podrškom i sudjelovanjem u svakom izdanju i iteraciji.

Prijelaz na DevSecOps

Najvažnija riječ u životnom ciklusu razvoja sigurnosti je "postupak". Ovo morate shvatiti prije nego što razmišljate o kupnji alata.

Jednostavno uključivanje alata u DevOps proces nije dovoljno — važna je komunikacija i razumijevanje između sudionika procesa.

Važniji su ljudi, a ne alati.

Često planiranje sigurnog procesa razvoja počinje odabirom i kupnjom alata, a završava pokušajima integracije alata u trenutni proces, koji ostaju pokušaji. To dovodi do nesretnih posljedica, jer svi alati imaju svoje karakteristike i ograničenja.

Čest slučaj je kada je odjel za sigurnost odabrao dobar, skup alat sa širokim mogućnostima, i došao kod programera da ga integriraju u proces. Ali ne ide - proces je strukturiran na takav način da se ograničenja već kupljenog alata ne uklapaju u trenutnu paradigmu.

Prvo opišite kakav rezultat želite i kako će proces izgledati. To će pomoći u razumijevanju uloge alata i sigurnosti u procesu.

Počnite s onim što je već u upotrebi

Prije kupnje skupih alata, pogledajte što već imate. Svaka tvrtka ima sigurnosne zahtjeve za razvoj, postoje provjere, pentestovi - zašto ne transformirati sve to u oblik koji je svima razumljiv i prikladan?

Obično su zahtjevi papirnati Talmud koji leži na polici. Bio je slučaj kada smo došli u tvrtku pogledati procese i tražili da vidimo sigurnosne zahtjeve za softver. Specijalist koji se time bavio dugo je tražio:

- E sad, negdje u bilješkama je bio put gdje leži ovaj dokument.

Kao rezultat toga, dokument smo dobili tjedan dana kasnije.

Za zahtjeve, provjere i ostalo napravite stranicu na npr. ušće - pogodno je za sve.

Lakše je preoblikovati ono što već imate i upotrijebiti to za početak.

Koristite Security Champions

Obično u prosječnoj tvrtki sa 100-200 programera postoji jedan stručnjak za sigurnost koji obavlja nekoliko funkcija i fizički nema vremena provjeriti sve. Čak i ako da sve od sebe, on sam neće provjeriti sav kod koji razvoj generira. Za takve slučajeve razvijen je koncept - Šampioni sigurnosti.

Šampioni sigurnosti su ljudi unutar razvojnog tima koji su zainteresirani za sigurnost vašeg proizvoda.

Security Champion je ulazna točka u razvojni tim i sigurnosni evangelizator zajedno.

Obično, kada stručnjak za sigurnost dođe u razvojni tim i ukaže na pogrešku u kodu, dobije iznenađeni odgovor:

- A tko si ti? Vidim te prvi put. Sa mnom je sve u redu - moj stariji prijatelj mi je dao "prijavu" na pregled koda, idemo dalje!

Ovo je tipična situacija, jer postoji puno više povjerenja u starije osobe ili jednostavno suigrače s kojima programer stalno komunicira na poslu i pregledu koda. Ako umjesto zaštitara Šampion sigurnosti ukaže na pogrešku i posljedice, tada će njegova riječ imati veću težinu.

Također, programeri poznaju svoj kod bolje od bilo kojeg stručnjaka za sigurnost. Za osobu koja ima najmanje 5 projekata u alatu za statičku analizu, obično je teško zapamtiti sve nijanse. Sigurnosni šampioni znaju svoj proizvod: što je u interakciji s čime i što prvo treba pogledati - oni su učinkovitiji.

Stoga razmislite o implementaciji Security Championsa i proširenju utjecaja vašeg sigurnosnog tima. Ovo je također korisno za samog prvaka: profesionalni razvoj u novom području, širenje njegovih tehničkih horizonata, nadogradnja tehničkih, menadžerskih i liderskih vještina, povećanje tržišne vrijednosti. Ovo je neki element društvenog inženjeringa, vaše "oči" u razvojnom timu.

Faze testiranja

Paradigma 20 do 80 kaže da 20% truda 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 detaljnije o aktivnostima, kao io alatima, koje značajke obično susrećemo kada ih uvodimo u proces i kako to učiniti ispravno.

Glavni problemi alata

Naglasit ću probleme koji su relevantni za sve instrumente i zahtijevaju pozornost. Analizirat ću ih detaljnije da ih više ne ponavljam.

Dugo vrijeme analize. Ako od predaje do objave treba 30 minuta za sve testove i sklapanje, tada će sigurnosne provjere informacija trajati jedan dan. Dakle, nitko neće usporiti proces. Uzmite u obzir ovu značajku i izvucite zaključke.

Visoka razina lažno negativna ili lažno pozitivna. Svi su proizvodi različiti, svi koriste različite okvire i vlastiti stil kodiranja. Na različitim bazama koda i tehnologijama, alati mogu pokazivati ​​različite razine lažno negativnih i lažno pozitivnih. Dakle, pogledajte što je točno unutra vaš poduzeća i za tvoj primjene pokazat će dobre i pouzdane rezultate.

Nema integracija s postojećim alatima. Pogledajte alate u smislu integracije s onim što već koristite. Na primjer, ako imate Jenkins ili TeamCity, provjerite integraciju alata s ovim softverom, a ne s GitLab CI, koji ne koristite.

Nedostatak ili pretjerana složenost prilagodbe. Ako alat nema API, zašto je onda potreban? Sve što se može učiniti u sučelju mora biti dostupno kroz API. U idealnom slučaju, alat bi trebao imati mogućnost prilagodbe provjera.

Nema plana razvoja proizvoda. Razvoj ne stoji na mjestu, uvijek koristimo nove okvire i funkcije, prepisujemo stari kod na nove jezike. Želimo biti sigurni da će alat koji kupujemo podržavati nove okvire i tehnologije. Stoga je važno znati da je proizvod pravi i ispravan Putokaz razvoj.

Značajke procesa

Osim značajki alata, uzmite u obzir značajke procesa razvoja. Na primjer, kočenje razvoja je uobičajena pogreška. Pogledajmo koje druge značajke treba uzeti u obzir i na što sigurnosni tim treba obratiti pozornost.

Kako ne biste propustili rokove razvoja i izdavanja, stvarajte drugačija pravila i drugačije pokazati čepove — kriteriji za zaustavljanje procesa izgradnje u prisutnosti ranjivosti — za različite sredine. Na primjer, razumijemo da trenutna grana ide na razvojni štand ili UAT, što znači da se ne zaustavljamo i kažemo:

"Ovdje imate ranjivosti, nećete ići nikamo dalje!"

U ovom trenutku, važno je reći programerima da postoje sigurnosni problemi na koje treba obratiti pozornost.

Prisutnost ranjivosti nije prepreka daljnjem testiranju: ručno, integracija ili ručno. S druge strane, moramo nekako povećati sigurnost proizvoda, a da programeri ne zanemaruju ono što smatraju sigurnim. Stoga, ponekad radimo ovo: na štandu, kada se izbaci u razvojno okruženje, jednostavno obavijestimo razvoj:

- Dečki, imate problema, molim vas obratite pozornost na njih.

U fazi UAT ponovno prikazujemo upozorenja o ranjivostima, a u fazi izdanja kažemo:

- Ljudi, upozorili smo vas nekoliko puta, ništa niste napravili - nećemo vas pustiti s ovim.

Ako govorimo o kodu i dinamici, tada je potrebno pokazati i upozoriti na ranjivosti samo onih značajki i koda koji je upravo napisan u ovoj značajci. Ako programer pomakne gumb za 3 piksela, a mi mu kažemo da tamo ima SQL injekciju i da je stoga treba hitno popraviti, to je pogrešno. Gledajte samo ono što je sada napisano i promjenu koja dolazi u aplikaciji.

Recimo da imamo određeni funkcionalni nedostatak - način na koji aplikacija ne bi trebala raditi: novac se ne prenosi, kada kliknete na gumb nema prijelaza na sljedeću stranicu ili se proizvod ne učitava. Sigurnosni nedostaci - to su isti nedostaci, ali ne u smislu rada aplikacije, već u sigurnosti.

Nisu svi problemi kvalitete softvera sigurnosni problemi. Ali svi sigurnosni problemi povezani su s kvalitetom softvera. Sherif Mansour, Expedia.

Budući da su sve ranjivosti isti nedostaci, treba ih nalaziti na istom mjestu kao i sve nedostatke u razvoju. Zato zaboravite na izvješća i strašne PDF-ove koje nitko ne čita.

Dok sam radio u razvojnoj tvrtki, primio sam izvještaj od alata za statičku analizu. Otvorio sam ga, zgrozio se, skuhao kavu, prelistao 350 stranica, zatvorio i nastavio raditi. Velika izvješća su mrtva izvješća. Obično ne odu nikamo, pisma se izbrišu, zaborave, izgube ili tvrtka kaže da prihvaća rizike.

Što uraditi? Potvrđene nedostatke koje smo pronašli jednostavno pretvaramo u oblik prikladan za razvoj, na primjer, stavljamo ih u zaostatak u Jiri. Dajemo prioritet nedostacima i otklanjamo ih po prioritetu, zajedno s funkcionalnim i testnim nedostacima.

Statička analiza - SAST

Ovo je analiza koda za ranjivosti., ali nije isto što i SonarQube. Ne provjeravamo samo uzorke ili stil. U analizi se koristi više pristupa: prema stablu ranjivosti, prema Protok podataka, analizom konfiguracijskih datoteka. To je sve što se tiče samog koda.

Prednosti pristupa: prepoznavanje ranjivosti u kodu u ranoj fazi razvojakada još nema postolja ni gotovih alata i mogućnost inkrementalnog skeniranja: skeniranje dijela koda koji je promijenjen i samo značajka koju trenutno radimo, što smanjuje vrijeme skeniranja.

Cons - ovo je nedostatak podrške za potrebne jezike.

Potrebne integracije, što bi trebalo 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 ne kretati se nerazumljivim sučeljem koje još treba naučiti napamet, već vidjeti sve potrebne integracije i ranjivosti koje je pronašao na radnom mjestu u vlastitom razvojnom okruženju.
• Pregled koda: SonarQube i ručni pregled.
• Pratioci grešaka: Jira i Bugzilla.

Na slici su prikazani neki od najboljih predstavnika statičke analize.

Nisu važni alati, već proces, pa postoje Open Source rješenja koja su dobra i za testiranje procesa.

SAST Open Source neće pronaći ogroman broj ranjivosti ili složenih tokova podataka, ali se mogu i trebaju koristiti pri izgradnji procesa. Oni pomažu razumjeti kako će se proces izgraditi, tko će odgovoriti na bugove, tko će prijaviti, a tko će prijaviti. Ako želite provesti početnu fazu izgradnje sigurnosti vašeg koda, koristite Open Source rješenja.

Kako se to može integrirati ako ste na početku svog putovanja i nemate ništa: ni CI, ni Jenkins, ni TeamCity? Razmotrimo integraciju u proces.

Integracija razine CVS

Ako imate Bitbucket ili GitLab, možete se integrirati na razini Sustav istodobnih verzija.

Po događaju - zahtjev za povlačenjem, commit. Skenirate kod i status izrade pokazuje je li sigurnosna provjera prošla ili nije.

Povratne informacije. Naravno, povratna informacija je uvijek potrebna. Ako ste samo osigurali sa strane, stavili ga u kutiju i nikome niste ništa rekli o tome, a onda ste na kraju mjeseca bacili hrpu grešaka - to nije ispravno i nije dobro.

Integracija sa sustavom za pregled koda

Jednom smo djelovali kao zadani recenzent za tehničkog AppSec korisnika u nizu važnih projekata. Ovisno o tome jesu li pogreške identificirane u novom kodu ili nema pogrešaka, recenzent postavlja status na zahtjev za povlačenjem na "prihvaćam" ili "treba raditi" - ili je sve u redu, ili veze na ono što točno treba poboljšati treba poboljšati. Za integraciju s verzijom koja ide u proizvodnju, omogućili smo zabranu spajanja ako test informacijske sigurnosti nije prošao. Uključili smo to u ručni pregled koda, a drugi sudionici u procesu vidjeli su sigurnosne statuse za ovaj određeni proces.

Integracija sa SonarQube

Mnogi jesu kvalitetna vrata u smislu kvalitete koda. Ovdje je isto - možete napraviti ista vrata samo za SAST alate. Bit će isto sučelje, vrata iste kvalitete, samo će se zvati sigurnosna vrata. I također, ako imate proces koji koristi SonarQube, možete lako sve integrirati tamo.

Integracija na razini CI

I ovdje je sve vrlo jednostavno:

• U rangu s autotestovima, jedinični testovi.
• Podjela po razvojnim fazama: dev, test, prod. Mogu biti uključeni različiti skupovi pravila ili različiti uvjeti neuspjeha: zaustavite sklop, nemojte zaustaviti sklop.
• Sinkrono/asinkrono pokretanje. Čekamo li kraj sigurnosnih testova ili ne. Odnosno, samo smo ih pokrenuli i idemo dalje, a onda dobijemo status da je sve dobro ili loše.

Sve je to u savršenom ružičastom svijetu. Toga u stvarnom životu nema, ali mi težimo. Rezultat izvođenja sigurnosnih provjera trebao bi biti sličan rezultatima jediničnih testova.

Na primjer, uzeli smo veliki projekt i odlučili da ćemo ga sada skenirati SAST-om - OK. Gurnuli smo ovaj projekt u SAST, dao nam je 20 ranjivosti i dobrovoljno smo odlučili da je sve u redu. 000 ranjivosti naš je tehnički dug. Dug ćemo staviti u kutiju, polako ćemo ga raščistiti i dodati bugove u defect trackere. Unajmimo tvrtku, napravimo sve sami ili neka nam pomognu Security Champions – i tehnički dug će se smanjiti.

A sve novonastale ranjivosti u novom kodu moraju se eliminirati na isti način kao greške u jedinici ili u autotestovima. Relativno rečeno, montaža je krenula, vodili smo je, dva testa i dva sigurnosna testa su pala. OK - otišli smo, pogledali što se dogodilo, popravili jednu stvar, popravili drugu, pokrenuli sljedeći put - sve je bilo u redu, nisu se pojavile nove ranjivosti, nijedan test nije pao. Ako je ovaj zadatak dublji i morate ga dobro razumjeti, ili popravljanje ranjivosti utječe na velike slojeve onoga što leži ispod haube: bug je dodan u alat za praćenje nedostataka, daje mu se prioritet i ispravlja se. Nažalost, svijet nije savršen i testovi ponekad padaju.

Primjer sigurnosnih vrata je analogan kvalitetnim vratima, u smislu prisutnosti i broja ranjivosti u kodu.

Integriramo se sa SonarQube - dodatak je instaliran, sve je vrlo zgodno i cool.

Integracija s razvojnim okruženjem

Mogućnosti integracije:

• Pokretanje skeniranja iz razvojnog okruženja prije predaje.
• Pogledaj rezultate.
• Analiza rezultata.
• Sinkronizacija sa serverom.

Ovako izgleda primanje rezultata s poslužitelja.

U našem razvojnom okruženju Intellij IDEJA jednostavno se pojavljuje dodatna stavka koja vas obavještava da su takve ranjivosti otkrivene tijekom skeniranja. Možete odmah urediti kod, pogledati preporuke i Grafikon toka. Sve se to nalazi na radnom mjestu programera, što je vrlo zgodno - nema potrebe pratiti druge veze i gledati nešto dodatno.

Open Source

Ovo je moja omiljena tema. Svi koriste Open Source biblioteke - zašto pisati hrpu štaka i bicikala kada možete uzeti gotovu biblioteku u kojoj je sve već implementirano?

Naravno, to je istina, ali biblioteke također pišu ljudi, one također uključuju određene rizike, a postoje i ranjivosti koje se povremeno ili stalno prijavljuju. Stoga postoji sljedeći korak u Sigurnosti aplikacija - to je analiza komponenti otvorenog koda.

Analiza otvorenog koda - OSA

Alat uključuje tri velika stupnja.

Traženje ranjivosti u knjižnicama. Na primjer, alat zna da koristimo neku biblioteku i to u CVE ili postoje neke ranjivosti u alatima za praćenje grešaka koje se odnose na ovu verziju biblioteke. Kada ga pokušate koristiti, alat će izdati upozorenje da je biblioteka ranjiva i savjetuje vam da koristite drugu verziju koja nema ranjivosti.

Analiza čistoće licence. Kod nas to još nije posebno popularno, ali ako radite u inozemstvu, onda s vremena na vrijeme tamo možete dobiti porez za korištenje komponente otvorenog koda koja se ne može koristiti ili mijenjati. Prema politici ovlaštene knjižnice, ne možemo to učiniti. Ili, ako smo ga izmijenili i koristimo, trebali bismo objaviti naš kod. Naravno, nitko ne želi objaviti šifru svojih proizvoda, ali i od toga se možete zaštititi.

Analiza komponenti koje se koriste u industrijskom okruženju. Zamislimo hipotetsku situaciju da smo konačno dovršili razvoj i objavili najnovije izdanje naše mikroservise. Živi tamo divno - tjedan, mjesec, godinu. Ne prikupljamo ga, ne provodimo sigurnosne provjere, čini se da je sve u redu. Ali iznenada, dva tjedna nakon izdanja, pojavljuje se kritična ranjivost u Open Source komponenti, koju koristimo u ovoj posebnoj verziji, u industrijskom okruženju. Ako ne bilježimo što i gdje koristimo, jednostavno nećemo vidjeti ovu ranjivost. Neki alati imaju mogućnost praćenja ranjivosti u bibliotekama koje se trenutno koriste u industriji. Vrlo je koristan.

Značajke:

• Različite politike za različite faze razvoja.
• Nadzor komponenti u industrijskom okruženju.
• Kontrola knjižnica unutar organizacije.
• Podrška za različite sustave izrade i jezike.
• Analiza Docker slika.

Nekoliko primjera lidera u industriji koji se bave analizom otvorenog koda.

Jedini besplatni je ovaj Provjera ovisnosti od OWASP-a. Možete ga uključiti u prvim fazama, vidjeti kako radi i što podržava. Uglavnom, to su sve cloud proizvodi, ili on-premise, ali iza svoje baze oni ipak idu na Internet. Oni ne šalju vaše biblioteke, već hashove ili vlastite vrijednosti, koje izračunavaju, i otiske prstiju na svoj poslužitelj kako bi primili informacije o prisutnosti ranjivosti.

Integracija procesa

Kontrola perimetra knjižnica, koji su preuzeti iz vanjskih izvora. Imamo eksterne i interne repozitorije. Na primjer, Event Central pokreće Nexus i želimo osigurati da nema ranjivosti unutar našeg repozitorija sa statusom "kritično" ili "visoko". Možete konfigurirati proxy korištenjem alata Nexus Firewall Lifecycle tako da se takve ranjivosti odsjeku i da ne završe u internom repozitoriju.

Integracija u CI. Na istoj razini s autotestovima, unit testovima i podjelom na razvojne stupnjeve: dev, test, prod. U svakoj fazi možete preuzeti bilo koju biblioteku, koristiti bilo što, ali ako postoji nešto teško s "kritičnim" statusom, možda je vrijedno skrenuti pozornost programera na to u fazi puštanja u proizvodnju.

Integracija s artefaktima: Nexus i JFrog.

Integracija u razvojno okruženje. Alati koje odaberete trebaju imati integraciju s razvojnim okruženjima. Programer mora imati pristup rezultatima skeniranja sa svog radnog mjesta ili mogućnost da sam skenira i provjeri ranjivosti koda prije nego što se posveti CVS-u.

Integracija CD-a. Ovo je cool značajka koja mi se jako sviđa i o kojoj sam već govorio – praćenje pojave novih ranjivosti u industrijskom okruženju. Djeluje otprilike ovako.

Imamo Javna spremišta komponenti — neki vanjski alati i naše interno spremište. Želimo da sadrži samo pouzdane komponente. Prilikom slanja proxy zahtjeva provjeravamo da preuzeta biblioteka nema ranjivosti. Ako potpada pod određena pravila koja smo postavili i nužno uskladili s razvojem, tada ga ne učitavamo i od nas se traži da koristimo drugu verziju. Prema tome, ako u biblioteci postoji nešto stvarno kritično i loše, programer neće primiti biblioteku u fazi instalacije - neka koristi višu ili nižu verziju.

• Prilikom izgradnje provjeravamo da nije netko nešto loše poskliznuo, da su sve komponente sigurne i da nitko nije donio ništa opasno na flash disku.
• U repozitoriju imamo samo pouzdane komponente.
• Prilikom implementacije još jednom provjeravamo sam paket: war, jar, DL ili Docker sliku kako bismo bili sigurni da je u skladu s pravilima.
• Pri ulasku u industriju pratimo što se događa u industrijskom okruženju: pojavljuju se ili ne pojavljuju kritične ranjivosti.

Dinamička analiza - DAST

Alati za dinamičku analizu bitno su drugačiji od svega što je prije rečeno. Ovo je svojevrsna imitacija rada korisnika s aplikacijom. Ako je ovo web aplikacija, šaljemo zahtjeve, simuliramo rad klijenta, klikamo na gumbe s prednje strane, šaljemo umjetne podatke iz forme: navodnike, zagrade, znakove u različitim kodovima, da vidimo kako aplikacija radi i obrađuje vanjski podaci.

Isti sustav omogućuje provjeru ranjivosti predložaka u Open Sourceu. Budući da DAST ne zna koji Open Source koristimo, jednostavno baca "zlonamjerne" uzorke i analizira odgovore poslužitelja:

- Da, ovdje postoji problem deserijalizacije, ali ne ovdje.

U tome postoje veliki rizici, jer ako ovaj sigurnosni test provodite na istom stolu s kojim rade testeri, mogu se dogoditi neugodne stvari.

• Veliko opterećenje mreže aplikacijskog poslužitelja.
• Nema integracija.
• Mogućnost promjene postavki analizirane aplikacije.
• Ne postoji podrška za potrebne tehnologije.
• Poteškoće s postavljanjem.

Imali smo situaciju kada smo konačno pokrenuli AppScan: dugo smo pokušavali dobiti pristup aplikaciji, dobili smo 3 računa i bili sretni - konačno ćemo sve provjeriti! Pokrenuli smo skeniranje i prvo što je AppScan učinio bilo je da uđe u administratorsku ploču, probije sve gumbe, promijeni polovicu podataka, a zatim potpuno ubije poslužitelj svojim poštanski obrazac-zahtjevi. Razvoj s testiranjem rekao je:

- Ljudi, je l' vi mene zezate?! Mi smo vam dali račune, a vi ste postavili štand!

Razmotrite moguće rizike. U idealnom slučaju, pripremite zasebno postolje za testiranje informacijske sigurnosti, koje će biti barem nekako izolirano od ostatka okoline, i uvjetno provjerite administrativnu ploču, po mogućnosti u ručnom načinu rada. Ovo je pentest - oni preostali postoci truda koje sada ne razmatramo.

Vrijedno je uzeti u obzir da ovo možete koristiti kao analogno testiranju opterećenja. U prvoj fazi možete uključiti dinamički skener s 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 Suite podrigivanja je “švicarski nož” za svakog sigurnosnog profesionalca. Svi ga koriste i vrlo je zgodan. Sada je objavljena nova demo verzija izdanja za poduzeća. Ako je ranije to bio samo samostalni uslužni program s dodacima, sada programeri konačno prave veliki poslužitelj s kojeg će biti moguće upravljati s nekoliko agenata. Ovo je super, preporučujem da probate.

Integracija procesa

Integracija se odvija prilično dobro i jednostavno: pokrenite skeniranje nakon uspješne instalacije aplikacije za stalak i skeniranje nakon uspješnog testiranja integracije.

Ako integracije ne rade ili postoje nedorečenosti i lažne funkcije, to je besmisleno i beskorisno - bez obzira koji uzorak pošaljemo, poslužitelj će i dalje odgovoriti na isti način.

• Idealno, zasebno postolje za testiranje.
• Prije testiranja zapišite redoslijed prijave.
• Testiranje administrativnog sustava je samo ručno.

proces

Malo općenito o procesu općenito io radu svakog alata posebno. Sve su aplikacije različite - jedna radi bolje s dinamičkom analizom, druga sa statičkom analizom, treća s OpenSource analizom, pentestovima ili nečim sasvim drugim, na primjer, događaji s WAF.

Svaki proces zahtijeva kontrolu.

Da biste razumjeli kako proces funkcionira i gdje se može poboljšati, morate prikupiti metrike iz svega što vam se nađe pod rukom, uključujući metrike proizvodnje, metrike iz alata i iz alata za praćenje grešaka.

Svaka informacija je korisna. Potrebno je pogledati iz različitih kutova gdje se ovaj ili onaj alat bolje koristi, gdje proces konkretno posustaje. Možda bi bilo vrijedno pogledati vremena odgovora razvoja kako biste vidjeli gdje poboljšati proces na temelju vremena. Što je više podataka, to se više odjeljaka može izgraditi od najviše razine do detalja svakog procesa.

Budući da svi statički i dinamički analizatori imaju svoje API-je, vlastite metode pokretanja, principe, neki imaju planere, drugi nemaju - mi pišemo alat AppSec orkestrator, koji vam omogućuje stvaranje jedinstvene ulazne točke u cijeli proces iz proizvoda i upravljanje s jedne točke.

Menadžeri, programeri i sigurnosni inženjeri imaju jednu ulaznu točku s koje mogu vidjeti što se izvodi, konfigurirati i pokrenuti skeniranje, primiti rezultate skeniranja i poslati zahtjeve. Pokušavamo se odmaknuti od papirologije, prevesti sve u ljudsko, što koristi razvoj - stranice na Confluenceu sa statusom i metricama, defekti u Jiri ili u raznim defect trackerima, ili integracija u sinkroni/asinkroni proces u CI-ju /CD.

Ključni za poneti

Alat nije glavna stvar. Prvo razmislite o procesu - zatim implementirajte alate. Alati su dobri, ali skupi, tako da možete započeti s procesom i izgraditi komunikaciju i razumijevanje između razvoja i sigurnosti. Sa sigurnosne točke gledišta, nema potrebe sve “stopirati”, s razvojne strane, ako postoji nešto visoko mega super kritično, onda to treba eliminirati, a ne zatvarati oči pred problemom.

Kvaliteta proizvoda - zajednički cilj i sigurnost i razvoj. Radimo jednu stvar, nastojimo osigurati da sve radi ispravno i da nema reputacijskih rizika ili financijskih gubitaka. Zbog toga promoviramo DevSecOps, SecDevOps pristup za poboljšanje komunikacije i poboljšanje kvalitete proizvoda.

Počnite s onim što već imate: zahtjevi, arhitektura, djelomične provjere, treninzi, smjernice. Nema potrebe odmah primijeniti sve prakse na sve projekte - kretati se iterativno. Ne postoji jedinstven standard - eksperiment i isprobati različite pristupe i rješenja.

Postoji znak jednakosti između nedostataka informacijske sigurnosti i funkcionalnih nedostataka.

Automatizirajte svekoji se kreće. Sve što se ne miče, pomaknite i automatizirajte. Ako se nešto radi ručno, to nije dobar dio procesa. Možda ga vrijedi pregledati i automatizirati.

Ako je veličina IS tima mala - koristiti Security Champions.

Možda vam ono o čemu sam govorio neće odgovarati i smislit ćete nešto svoje - i to je dobro. Ali odaberite alate na temelju zahtjeva za vaš proces. Ne gledajte što zajednica kaže, da je ovaj alat loš, a ovaj dobar. Možda će za vaš proizvod vrijediti suprotno.

Zahtjevi za alate.

• Niska razina Lažno pozitivno.
• Adekvatno vrijeme analize.
• Pogodnost korištenja.
• Dostupnost integracija.
• Razumijevanje plana razvoja proizvoda.
• Mogućnost prilagođavanja alata.

Yurijevo izvješće odabrano je kao jedno od najboljih na DevOpsConfu 2018. Da biste se upoznali s još zanimljivijim idejama i praktičnim slučajevima, dođite u Skolkovo 27. i 28. svibnja DevOpsConf unutar festival RIT++. Još bolje, ako ste spremni podijeliti svoje iskustvo primijeniti za izvješće do 21. travnja.

Izvor: www.habr.com