Imeli smo 2 analizatorja kode, 4 orodja za dinamično testiranje, lastne obrti in 250 skript. Ne gre za to, da je vse to potrebno v trenutnem procesu, a ko začnete izvajati DevSecOps, morate iti do konca.
. Ustvarjalca likov: Justin Roiland in Dan Harmon.
Kaj je SecDevOps? Kaj pa DevSecOps? Kakšne so razlike? Varnost aplikacij - za kaj gre? Zakaj klasični pristop ne deluje več? Pozna odgovor na vsa ta vprašanja Jurij Šabalin z dne Swordfish Security. Jurij bo podrobno odgovoril na vse in analiziral težave pri prehodu s klasičnega modela Application Security na proces DevSecOps: kako pravilno pristopiti k integraciji varnega razvojnega procesa v proces DevOps in ne pokvariti ničesar, kako iti skozi glavne faze varnostnega testiranja, katera orodja je mogoče uporabiti, v čem se razlikujejo in kako jih pravilno konfigurirati, da se izognete pastem.
O govorniku: Jurij Šabalin - Glavni varnostni arhitekt v podjetju Varnost Swordfish. Odgovoren za implementacijo SSDL, za celotno integracijo orodij za analizo aplikacij v enoten razvojni in testni ekosistem. 7 let izkušenj na področju informacijske varnosti. Delal je v Alfa-Bank, Sberbank in Positive Technologies, ki razvija programsko opremo in ponuja storitve. Predavatelj na mednarodnih konferencah ZerONights, PHDays, RISSPA, OWASP.
Varnost aplikacij: za kaj gre?
Varnost aplikacij - To je varnostni del, ki je odgovoren za varnost aplikacije. To ne velja za infrastrukturo ali varnost omrežja, temveč za to, kar pišemo in na čem delajo razvijalci – to so pomanjkljivosti in ranljivosti same aplikacije.
Smer - Življenjski cikel razvoja varnosti - razvil Microsoft. Diagram prikazuje kanonični model SDLC, katerega glavna naloga je sodelovanje varnosti na vseh stopnjah razvoja, od zahtev do izdaje in proizvodnje. Microsoft je ugotovil, da je v industriji preveč hroščev, da jih je več in da je treba glede tega nekaj narediti, in so predlagali ta pristop, ki je postal kanoničen.
Varnost aplikacij in SSDL nista namenjena odkrivanju ranljivosti, kot se običajno verjame, temveč preprečevanju njihovega pojava. Sčasoma je bil Microsoftov kanonični pristop izboljšan, razvit in uveden v globlji in podrobnejši potop.
Kanonični SDLC je zelo podroben v različnih metodologijah - OpenSAMM, BSIMM, OWASP. Metodologije so različne, a na splošno podobne.
Model gradnje varnosti v zrelosti
meni je najbolj všeč BSIMM - . Osnova metodologije je razdelitev procesa varnosti aplikacij na 4 področja: upravljanje, obveščanje, SSDL Touchpoints in uvajanje. Vsako področje ima 12 praks, ki so predstavljene kot 112 dejavnosti.
Vsaka od 112 dejavnosti ima 3 stopnje zrelosti: začetni, srednji in napredni. Vseh 12 praks lahko preučite odsek za odsekom, izberete stvari, ki so vam pomembne, ugotovite, kako jih implementirati in postopoma dodajate elemente, na primer statično in dinamično analizo kode ali pregled kode. Napišete si načrt in po njem mirno delate v sklopu izvajanja izbranih aktivnosti.
Zakaj DevSecOps
DevOps je splošen, velik proces, pri katerem je treba upoštevati varnost.
Sprva vključeni varnostni pregledi. V praksi je bilo število varnostnih ekip veliko manjše kot zdaj in niso delovale kot udeleženci v procesu, temveč kot kontrolni in nadzorni organ, ki mu nalaga zahteve in preverja kakovost izdelka ob koncu izdaje. To je klasičen pristop, pri katerem so bile varnostne ekipe za zidom razvoja in niso sodelovale v procesu.
Glavna težava je, da je informacijska varnost ločena od razvoja. Običajno je to neke vrste informacijsko varnostno vezje in vsebuje 2-3 velika in draga orodja. Enkrat na pol leta pride izvorna koda oziroma aplikacija, ki jo je treba preveriti, enkrat letno pa se izdelajo . Vse to vodi v dejstvo, da je datum izdaje za industrijo odložen, razvijalec pa je izpostavljen ogromnemu številu ranljivosti avtomatiziranih orodij. Vsega tega je nemogoče razstaviti in popraviti, ker rezultati za preteklih šest mesecev niso bili urejeni, a tukaj je nova serija.
Med delom našega podjetja opažamo, da varnost na vseh področjih in panogah razume, da je čas, da dohiti in se vrti z razvojem na istem kolesu - v . Paradigma DevSecOps se popolnoma ujema z agilno razvojno metodologijo, implementacijo, podporo in sodelovanjem pri vsaki izdaji in ponovitvi.
Prehod na DevSecOps
Najpomembnejša beseda v življenjskem ciklu razvoja varnosti je "proces". To morate razumeti, preden razmišljate o nakupu orodja.
Preprosta vključitev orodij v proces DevOps ni dovolj – pomembna sta komunikacija in razumevanje med udeleženci procesa.
Pomembnejši so ljudje, ne orodja.
Pogosto se načrtovanje varnega razvojnega procesa začne z izbiro in nakupom orodja in konča s poskusi integracije orodja v trenutni proces, ki ostanejo poskusi. To vodi do žalostnih posledic, saj imajo vsa orodja svoje značilnosti in omejitve.
Pogost primer je, ko je varnostni oddelek izbral dobro, drago orodje s širokimi zmožnostmi in prišel k razvijalcem, da ga vključijo v proces. Vendar se ne izide - proces je strukturiran tako, da se omejitve že kupljenega orodja ne ujemajo s trenutno paradigmo.
Najprej opišite, kakšen rezultat želite in kako bo izgledal postopek. To bo pomagalo razumeti vlogo orodja in varnosti v procesu.
Začnite s tem, kar je že v uporabi
Preden kupite drago orodje, poglejte, kaj že imate. Vsako podjetje ima varnostne zahteve za razvoj, obstajajo preverjanja, pentesti - zakaj ne bi vsega tega spremenili v obliko, ki je razumljiva in priročna za vse?
Običajno so zahteve papirnati Talmud, ki leži na polici. Bil je primer, ko smo prišli v podjetje pogledat procese in prosili za ogled varnostnih zahtev za programsko opremo. Specialist, ki se je ukvarjal s tem, je dolgo časa iskal:
- Zdaj, nekje v zapiskih je bila pot, kjer leži ta dokument.
Posledično smo dokument prejeli čez teden dni.
Za zahteve, čeke in ostalo ustvarite stran na npr. Sotočje - je priročno za vse.
Lažje je preoblikovati tisto, kar že imate, in to uporabiti za začetek.
Uporabite Security Champions
Običajno je v povprečnem podjetju s 100-200 razvijalci en strokovnjak za varnost, ki opravlja več funkcij in fizično nima časa, da bi vse preveril. Tudi če se bo trudil po svojih najboljših močeh, sam ne bo preveril vse kode, ki jo ustvari razvoj. Za takšne primere je bil razvit koncept - .
Varnostni šampioni so ljudje v razvojni skupini, ki jih zanima varnost vašega izdelka.
Security Champion je vstopna točka v razvojno ekipo in varnostni evangelist v enem.
Običajno, ko strokovnjak za varnost pride v razvojno ekipo in opozori na napako v kodi, prejme presenečen odgovor:
- In kdo si ti? Prvič te vidim. Z mano je vse v redu - moj starejši prijatelj mi je dal "prijavo" na pregled kode, gremo naprej!
To je tipična situacija, saj je veliko več zaupanja starejšim ali preprosto soigralcem, s katerimi razvijalec nenehno komunicira pri delu in pri pregledu kode. Če bo namesto varnostnika na napako in posledice opozoril prvak varnosti, bo njegova beseda imela večjo težo.
Poleg tega razvijalci poznajo svojo kodo bolje kot kateri koli strokovnjak za varnost. Za osebo, ki ima vsaj 5 projektov v orodju za statično analizo, si je običajno težko zapomniti vse nianse. Varnostni prvaki poznajo svoj izdelek: kaj je v interakciji s čim in kaj je treba najprej pogledati – učinkovitejši so.
Zato razmislite o implementaciji Security Champions in razširitvi vpliva vaše varnostne ekipe. To je koristno tudi za šampiona samega: strokovni razvoj na novem področju, širjenje njegovih tehničnih obzorij, nadgradnja tehničnih, vodstvenih in vodstvenih sposobnosti, povečanje tržne vrednosti. To je nekakšen element socialnega inženiringa, vaše "oči" v razvojni ekipi.
Faze testiranja
pravi, da 20 % truda prinese 80 % rezultatov. Teh 20 % je praks analize aplikacij, ki jih je mogoče in je treba avtomatizirati. Primeri takih dejavnosti so statična analiza - SAST, dinamična analiza - DAST и Nadzor odprte kode. Povedal vam bom podrobneje o dejavnostih, pa tudi o orodjih, s katerimi funkcijami se običajno srečujemo, ko jih uvajamo v proces, in kako to storiti pravilno.
Glavni problemi orodij
Izpostavil bom probleme, ki so pomembni za vse instrumente in zahtevajo pozornost. Podrobneje jih bom analiziral, da jih ne bom več ponavljal.
Dolg čas analize. Če od izdaje do izdaje traja 30 minut za vse preizkuse in sestavljanje, bodo preverjanja varnosti informacij trajala en dan. Torej nihče ne bo upočasnil procesa. Upoštevajte to funkcijo in naredite zaključke.
Visoka stopnja Lažno negativno ali Lažno pozitivno. Vsi izdelki so različni, vsi uporabljajo drugačna ogrodja in svoj slog kodiranja. Na različnih kodnih bazah in tehnologijah lahko orodja prikazujejo različne ravni lažno negativnih in lažno pozitivnih vrednosti. Poglejte torej, kaj točno je notri si podjetja in za svoj aplikacije bodo pokazale dobre in zanesljive rezultate.
Brez integracij z obstoječimi orodji. Oglejte si orodja v smislu integracij s tem, kar že uporabljate. Na primer, če imate Jenkins ali TeamCity, preverite integracijo orodij s to programsko opremo in ne z GitLab CI, ki ga ne uporabljate.
Pomanjkanje ali pretirana zapletenost prilagajanja. Če orodje nima API-ja, zakaj je potem potrebno? Vse, kar je mogoče narediti v vmesniku, bi moralo biti na voljo prek API-ja. V idealnem primeru bi moralo imeti orodje možnost prilagajanja preverjanj.
Ni načrta za razvoj izdelka. Razvoj ne miruje, vedno uporabljamo nova ogrodja in funkcije, prepisujemo staro kodo v nove jezike. Želimo biti prepričani, da bo orodje, ki ga kupimo, podpiralo nova ogrodja in tehnologije. Zato je pomembno vedeti, da je izdelek resničen in pravilen razvoj.
Funkcije procesa
Poleg značilnosti orodij upoštevajte tudi značilnosti razvojnega procesa. Na primer, oviranje razvoja je pogosta napaka. Poglejmo, katere druge značilnosti je treba upoštevati in na kaj mora biti pozorna varnostna ekipa.
Da ne zamudite rokov razvoja in izdaje, ustvarjajte različna pravila in drugačen pokazati zamaške — merila za zaustavitev procesa gradnje v prisotnosti ranljivosti — za različna okolja. Na primer, razumemo, da gre trenutna veja na razvojno stojalo ali UAT, kar pomeni, da se ne ustavimo in rečemo:
"Tu imate ranljivosti, ne boste šli nikamor dlje!"
Na tej točki je pomembno, da razvijalcem poveste, da obstajajo varnostna vprašanja, ki jim je treba posvetiti pozornost.
Prisotnost ranljivosti ni ovira za nadaljnje testiranje: ročni, integracijski ali ročni. Po drugi strani pa moramo nekako povečati varnost izdelka in tako, da razvijalci ne zanemarijo tistega, kar se jim zdi varno. Zato včasih naredimo to: na stojnici, ko je uveden v razvojno okolje, preprosto obvestimo razvoj:
- Fantje, imate težave, prosim, bodite pozorni nanje.
Na stopnji UAT znova prikažemo opozorila o ranljivostih, na stopnji izdaje pa rečemo:
- Fantje, večkrat smo vas opozorili, storili niste ničesar - s tem vas ne bomo izpustili.
Če govorimo o kodi in dinamiki, potem je treba pokazati in opozoriti na ranljivosti samo tistih funkcij in kode, ki je bila pravkar napisana v tej funkciji. Če razvijalec premakne gumb za 3 piksle in mu povemo, da ima tam vstavljen SQL in ga je zato treba nujno popraviti, je to narobe. Poglejte samo zdaj napisano in spremembo, ki pride v aplikacijo.
Recimo, da imamo določeno funkcionalno napako – način, na katerega aplikacija ne bi smela delovati: denar se ne prenese, ko kliknete na gumb, ni prehoda na naslednjo stran ali pa se izdelek ne naloži. Varnostne napake - gre za iste napake, vendar ne v smislu delovanja aplikacije, ampak v varnosti.
Vse težave s kakovostjo programske opreme niso varnostne težave. Toda vse varnostne težave so povezane s kakovostjo programske opreme. Sherif Mansour, Expedia.
Ker so vse ranljivosti enake napake, jih je treba nahajati na istem mestu kot vse razvojne napake. Zato pozabite na poročila in strašljive PDF-je, ki jih nihče ne bere.
Ko sem delal v razvojnem podjetju, sem prejel poročilo orodij za statično analizo. Odprla sem, se zgrozila, skuhala kavo, prelistala 350 strani, zaprla in delala naprej. Velika poročila so mrtva poročila. Običajno ne gredo nikamor, pisma so izbrisana, pozabljena, izgubljena ali pa podjetje pravi, da sprejema tveganja.
Kaj storiti? Potrjene napake, ki smo jih našli, preprosto pretvorimo v obliko, primerno za razvoj, na primer jih postavimo v zaostanek v Jiri. Napake razvrščamo po prioritetah in jih odpravljamo po prednostnem vrstnem redu, skupaj s funkcijskimi in testnimi napakami.
Statična analiza - SAST
To je analiza kode za ranljivosti., vendar ni isto kot SonarQube. Ne preverjamo samo vzorcev ali sloga. Pri analizi uporabljamo več pristopov: glede na drevo ranljivosti, glede na , z analizo konfiguracijskih datotek. To je vse, kar zadeva samo kodo.
Prednosti pristopa: prepoznavanje ranljivosti v kodi v zgodnji fazi razvojako še ni stojal ali pripravljenih orodij, in zmožnost postopnega skeniranja: skeniranje dela kode, ki se je spremenilo, in samo funkcije, ki jo trenutno izvajamo, kar skrajša čas skeniranja.
Proti - to je pomanjkanje podpore za potrebne jezike.
Potrebne integracije, kar bi po mojem subjektivnem mnenju moralo biti v orodjih:
- Integracijsko orodje: Jenkins, TeamCity in Gitlab CI.
- Razvojno okolje: Intellij IDEA, Visual Studio. Za razvijalca je bolj priročno, da ne krmari po nerazumljivem vmesniku, ki si ga je treba še zapomniti, ampak da vidi vse potrebne integracije in ranljivosti, ki jih je našel kar na delovnem mestu v lastnem razvojnem okolju.
- Pregled kode: SonarQube in ročni pregled.
- Sledilci napak: Jira in Bugzilla.
Slika prikazuje nekaj najboljših predstavnikov statične analize.
Niso pomembna orodja, ampak proces, zato obstajajo odprtokodne rešitve, ki so dobre tudi za testiranje procesa.
Odprtokodni SAST ne bo našel velikega števila ranljivosti ali zapletenih podatkovnih tokov, vendar jih je mogoče in treba uporabiti pri gradnji procesa. Pomagajo razumeti, kako bo zgrajen proces, kdo se bo odzval na hrošče, kdo bo poročal in kdo bo poročal. Če želite izvesti začetno stopnjo izgradnje varnosti vaše kode, uporabite odprtokodne rešitve.
Kako je to mogoče integrirati, če ste na začetku svoje poti in nimate ničesar: ne CI, ne Jenkinsa, ne TeamCityja? Razmislimo o integraciji v proces.
Integracija ravni CVS
Če imate Bitbucket ali GitLab, lahko integrirate na ravni .
Po dogodku - zahteva po vleki, potrditev. Skenirate kodo in status gradnje pokaže, ali je varnostni pregled uspel ali ni uspel.
Povratne informacije. Seveda je povratna informacija vedno potrebna. Če ste pravkar poskrbeli za varnost ob strani, jo dali v škatlo in nikomur niste ničesar povedali o tem, nato pa ste ob koncu meseca odvrgli kup hroščev - to ni pravilno in ni dobro.
Integracija s sistemom za pregled kode
Nekoč smo delovali kot privzeti ocenjevalec za tehničnega uporabnika AppSec v številnih pomembnih projektih. Odvisno od tega, ali so v novi kodi odkrite napake ali napak ni, pregledovalec nastavi status na zahtevi za vlečenje na »sprejmi« ali »potrebno je delo« - ali je vse v redu ali povezave do tega, kar je treba izboljšati je treba izboljšati. Za integracijo z različico, ki je v proizvodnji, smo omogočili prepoved spajanja, če test informacijske varnosti ni opravljen. To smo vključili v ročni pregled kode in drugi udeleženci v procesu so videli varnostne statuse za ta določen postopek.
Integracija s SonarQube
Mnogi so v smislu kakovosti kode. Tukaj je enako - enaka vrata lahko naredite samo za orodja SAST. Tam bo enak vmesnik, ista kakovostna vrata, le da se bo imenovala varnostna vrata. In tudi, če imate postopek, ki uporablja SonarQube, lahko preprosto integrirate vse tja.
Integracija na ravni CI
Tudi tukaj je vse precej preprosto:
- Na ravni avtotestov, testi enot.
- Delitev po razvojnih stopnjah: dev, test, prod. Vključeni so lahko različni sklopi pravil ali različni pogoji neuspeha: zaustavite sestavljanje, ne ustavite sestavljanja.
- Sinhroni/asinhroni zagon. Čakamo na konec varnostnih testov ali ne. Se pravi, samo zagnali smo jih in gremo naprej, potem pa dobimo status, da je vse dobro ali slabo.
Vse je v popolnem roza svetu. Tega v resničnem življenju ni, vendar si prizadevamo. Rezultat izvajanja varnostnih pregledov bi moral biti podoben rezultatom testov enote.
Na primer, vzeli smo velik projekt in se odločili, da ga bomo zdaj skenirali s SAST - OK. Ta projekt smo potisnili v SAST, dal nam je 20 ranljivosti in z dobrovoljno odločitvijo smo se odločili, da je vse v redu. 000 ranljivosti je naš tehnični dolg. Dolg bomo dali v škatlo, ga bomo počasi razčistili in dodajali hrošče v sledilnike napak. Najemimo podjetje, naredimo vse sami ali pa naj nam pomagajo Security Champions – in tehnični dolg se bo zmanjšal.
In vse novonastale ranljivosti v novi kodi je treba odpraviti na enak način kot napake v enoti ali v samodejnih testih. Relativno rečeno, montaža se je začela, izpeljali smo jo, dva testa in dva varnostna testa sta padla. V redu – šli smo, pogledali, kaj se je zgodilo, popravili eno stvar, popravili drugo, naslednjič zagnali – vse je bilo v redu, nobena nova ranljivost se ni pojavila, noben test ni bil neuspešen. Če je ta naloga globlja in jo morate dobro razumeti, ali če odpravljanje ranljivosti vpliva na velike plasti tega, kar se skriva pod pokrovom: sledilniku napak je bil dodan hrošč, je prednostno razvrščen in popravljen. Na žalost svet ni popoln in testi so včasih neuspešni.
Primer varnostnih vrat je analog kakovostnih vrat v smislu prisotnosti in števila ranljivosti v kodi.
Integriramo se s SonarQube - vtičnik je nameščen, vse je zelo priročno in kul.
Integracija z razvojnim okoljem
Možnosti integracije:
- Izvajanje skeniranja iz razvojnega okolja pred potrditvijo.
- Oglejte si rezultate.
- Analiza rezultatov.
- Sinhronizacija s strežnikom.
Takole izgleda prejemanje rezultatov s strežnika.
V našem razvojnem okolju preprosto se prikaže dodaten element, ki vas obvesti, da so bile med pregledom odkrite takšne ranljivosti. Takoj lahko uredite kodo, si ogledate priporočila in . Vse to se nahaja na delovnem mestu razvijalca, kar je zelo priročno - ni vam treba slediti drugim povezavam in pogledati nekaj dodatnega.
open Source
To je moja najljubša tema. Vsi uporabljajo odprtokodne knjižnice - zakaj bi pisali kup bergel in koles, če lahko vzamete že pripravljeno knjižnico, v kateri je že vse implementirano?
Seveda je to res, a tudi knjižnice pišejo ljudje, vključujejo tudi določena tveganja in obstajajo tudi ranljivosti, o katerih se občasno ali nenehno poroča. Zato obstaja naslednji korak v Varnosti aplikacij – to je analiza odprtokodnih komponent.
Analiza odprte kode - OSA
Orodje vključuje tri velike stopnje.
Iskanje ranljivosti v knjižnicah. Orodje na primer ve, da uporabljamo neko knjižnico in to v ali obstajajo nekatere ranljivosti v sledilnikih hroščev, ki se nanašajo na to različico knjižnice. Ko ga poskusite uporabiti, bo orodje izdalo opozorilo, da je knjižnica ranljiva, in vam svetuje, da uporabite drugo različico, ki nima ranljivosti.
Analiza licenčne čistosti. Pri nas to še ni posebej priljubljeno, a če delate v tujini, potem lahko tam občasno dobite davek za uporabo odprtokodne komponente, ki je ni mogoče uporabljati ali spreminjati. Po pravilniku licenčne knjižnice tega ne moremo narediti. Ali pa, če smo ga spremenili in uporabljali, bi morali objaviti svojo kodo. Seveda nihče ne želi objaviti kode svojih izdelkov, vendar se lahko tudi pred tem zaščitite.
Analiza komponent, ki se uporabljajo v industrijskem okolju. Predstavljajmo si hipotetično situacijo, da smo končno zaključili razvoj in izdali zadnjo izdajo naše mikrostoritve. Tam živi čudovito - teden, mesec, leto. Ne zbiramo ga, ne izvajamo varnostnih pregledov, zdi se, da je vse v redu. Toda nenadoma se dva tedna po izdaji pojavi kritična ranljivost v odprtokodni komponenti, ki jo uporabljamo v tej posebni gradnji, v industrijskem okolju. Če ne beležimo, kaj in kje uporabljamo, te ranljivosti preprosto ne bomo videli. Nekatera orodja imajo možnost spremljanja ranljivosti v knjižnicah, ki se trenutno uporabljajo v industriji. Je zelo uporaben.
Značilnosti:
- Različne politike za različne stopnje razvoja.
- Nadzor komponent v industrijskem okolju.
- Nadzor nad knjižnicami znotraj organizacije.
- Podpora za različne gradbene sisteme in jezike.
- Analiza Dockerjevih slik.
Nekaj primerov vodilnih v industriji, ki se ukvarjajo z analizo odprte kode.
Edini brezplačen je ta od OWASP. Lahko ga vklopite v prvih fazah, vidite, kako deluje in kaj podpira. V osnovi so to vsi produkti v oblaku ali na mestu uporabe, vendar so za svojo bazo še vedno poslani na internet. Ne pošiljajo vaših knjižnic, temveč zgoščene vrednosti ali lastne vrednosti, ki jih izračunajo, in prstne odtise na svoj strežnik, da prejmejo informacije o prisotnosti ranljivosti.
Integracija procesov
Perimetrski nadzor knjižnic, ki so preneseni iz zunanjih virov. Imamo zunanje in notranje repozitorije. Na primer, Event Central poganja Nexus in želimo zagotoviti, da v našem repozitoriju ni nobenih ranljivosti s statusom »kritično« ali »visoko«. Proxy lahko konfigurirate z orodjem Nexus Firewall Lifecycle, tako da so takšne ranljivosti odrezane in ne končajo v notranjem repozitoriju.
Integracija v CI. Na isti ravni z avtotesti, enotnimi testi in delitvijo na razvojne stopnje: dev, test, prod. Na vsaki stopnji lahko prenesete poljubne knjižnice, uporabite karkoli, če pa je s statusom "kritično" nekaj težko, je morda vredno opozoriti razvijalce na to na stopnji izdaje v produkcijo.
Integracija z artefakti: Nexus in JFrog.
Integracija v razvojno okolje. Orodja, ki jih izberete, morajo imeti integracijo z razvojnimi okolji. Razvijalec mora imeti dostop do rezultatov skeniranja s svojega delovnega mesta ali možnost, da sam skenira in preveri kodo za ranljivosti, preden se zaveže CVS.
Integracija CD-ja. To je kul funkcija, ki mi je zelo všeč in o kateri sem že govoril – spremljanje pojava novih ranljivosti v industrijskem okolju. Deluje nekako takole.
Imamo Repozitoriji javnih komponent — nekaj zunanjih orodij in naše notranje skladišče. Želimo, da vsebuje le zaupanja vredne komponente. Pri posredovanju zahteve preverimo, ali prenesena knjižnica nima ranljivosti. Če spada pod določene pravilnike, ki jih nastavimo in jih nujno uskladimo z razvojem, potem ga ne naložimo in smo pozvani, da uporabimo drugo različico. V skladu s tem, če je v knjižnici nekaj res kritičnega in slabega, potem razvijalec ne bo prejel knjižnice v fazi namestitve - naj uporabi višjo ali nižjo različico.
- Pri gradnji preverimo, da komu ni spodrsnilo kaj hudega, da so vsi sestavni deli varni in da ni kdo na flash pogonu prinesel česa nevarnega.
- V skladišču imamo samo zaupanja vredne komponente.
- Pri uvajanju še enkrat preverimo sam paket: war, jar, DL ali Docker image, da zagotovimo skladnost s pravilnikom.
- Ob vstopu v industrijo spremljamo dogajanje v industrijskem okolju: kritične ranljivosti se pojavljajo ali ne.
Dinamična analiza - DAST
Orodja za dinamično analizo se bistveno razlikujejo od vsega, kar je bilo prej povedano. To je nekakšna imitacija uporabnikovega dela z aplikacijo. Če je to spletna aplikacija, pošiljamo zahteve, simuliramo delo odjemalca, klikamo na gumbe na sprednji strani, pošiljamo umetne podatke iz obrazca: narekovaje, oklepaje, znake v različnih kodiranjih, da vidimo, kako aplikacija deluje in obdeluje zunanji podatki.
Isti sistem omogoča preverjanje ranljivosti predlog v odprtokodnem sistemu. Ker DAST ne ve, katero odprtokodno kodo uporabljamo, preprosto vrže "zlonamerne" vzorce in analizira odzive strežnika:
- Ja, tukaj je problem deserializacije, vendar ne tukaj.
Pri tem so velika tveganja, kajti če ta varnostni test izvajate na isti mizi, s katero delajo preizkuševalci, se lahko zgodijo neprijetne stvari.
- Velika obremenitev omrežja aplikacijskega strežnika.
- Brez integracij.
- Možnost spreminjanja nastavitev analizirane aplikacije.
- Ni podpore za potrebne tehnologije.
- Težava pri nastavitvi.
Imeli smo situacijo, ko smo končno zagnali AppScan: dolgo smo poskušali dobiti dostop do aplikacije, dobili 3 račune in bili srečni - končno bomo vse preverili! Zagnali smo skeniranje in AppScan je najprej šel v skrbniško ploščo, prebil vse gumbe, spremenil polovico podatkov in nato popolnoma ubil strežnik s svojim - zahteve. Razvoj s testiranjem je rekel:
- Fantje, se hecate?! Dali smo vam račune, vi pa ste postavili štant!
Upoštevajte možna tveganja. V idealnem primeru pripravite ločeno stojalo za testiranje informacijske varnosti, ki bo vsaj nekako izolirano od preostalega okolja, in pogojno preverite skrbniško ploščo, po možnosti v ročnem načinu. To je pentest - tisti preostali odstotki truda, ki jih zdaj ne upoštevamo.
Upoštevati je treba, da lahko to uporabite kot analogno testiranje obremenitve. Na prvi stopnji lahko vklopite dinamični skener z 10-15 niti in vidite, kaj se zgodi, vendar običajno, kot kaže praksa, nič dobrega.
Nekaj virov, ki jih običajno uporabljamo.
Vredno izpostaviti je "švicarski nož" za vsakega varnostnega strokovnjaka. Vsi ga uporabljajo in je zelo priročen. Izšla je nova demo različica poslovne izdaje. Če je bil prej le samostojen pripomoček z vtičniki, zdaj razvijalci končno izdelujejo velik strežnik, iz katerega bo mogoče upravljati več agentov. To je kul, priporočam, da poskusite.
Integracija procesov
Integracija poteka zelo dobro in preprosto: po uspešni namestitvi zaženite skeniranje aplikacije za stojalo in skeniranje po uspešnem testiranju integracije.
Če integracije ne delujejo ali obstajajo škrbine in lažne funkcije, je nesmiselno in neuporabno - ne glede na to, kakšen vzorec pošljemo, se bo strežnik še vedno odzval na enak način.
- Idealno bi bilo ločeno stojalo za testiranje.
- Pred testiranjem si zapišite zaporedje prijave.
- Testiranje administrativnega sistema je samo ročno.
Postopek
Malo posplošeno o procesu na splošno in o delu vsakega orodja posebej. Vse aplikacije so različne – ena bolje deluje z dinamično analizo, druga s statično analizo, tretja z analizo OpenSource, pentesti ali kaj drugega, na primer dogodki z .
Vsak proces potrebuje nadzor.
Če želite razumeti, kako proces deluje in kje ga je mogoče izboljšati, morate zbrati meritve iz vsega, kar vam pride pod roke, vključno s proizvodnimi meritvami, meritvami iz orodij in sledilcev napak.
Vsaka informacija je koristna. Z različnih zornih kotov je treba pogledati, kje je to ali ono orodje bolje uporabljeno, kje proces konkretno upade. Morda bi bilo vredno pogledati razvojne odzivne čase, da bi ugotovili, kje izboljšati proces glede na čas. Več kot je podatkov, več razdelkov je mogoče zgraditi od najvišje ravni do podrobnosti vsakega procesa.
Ker imajo vsi statični in dinamični analizatorji svoje API-je, lastne metode zagona, principe, nekateri imajo razporejevalnike, drugi ne - pišemo orodje AppSec Orchestrator, ki vam omogoča, da iz produkta ustvarite enotno vstopno točko v celoten proces in ga upravljate iz ene točke.
Vodje, razvijalci in varnostni inženirji imajo eno vstopno točko, s katere lahko vidijo, kaj se izvaja, konfigurirajo in zaženejo skeniranje, prejmejo rezultate skeniranja in predložijo zahteve. Poskušamo se odmakniti od papirologije, vse prevesti v človeško, kar uporablja razvoj - strani na Confluence s statusom in metriko, napake v Jiri ali v raznih sledilcih napak ali integracija v sinhroni/asinhroni proces v CI. /CD.
Ključni izdelki
Orodje ni glavno. Najprej razmislite o postopku - nato uporabite orodja. Orodja so dobra, a draga, tako da lahko začnete s postopkom in vzpostavite komunikacijo ter razumevanje med razvojem in varnostjo. Z vidika varnosti ni treba vsega "zaustavljati", z vidika razvoja, če je nekaj visoko mega super kritično, potem je treba to odpraviti, ne pa si zatiskati oči pred problemom.
Kakovost izdelka - skupni cilj varnost in razvoj. Delamo eno stvar, poskušamo zagotoviti, da vse deluje pravilno in ni tveganj za ugled ali finančnih izgub. Zato promoviramo pristop DevSecOps, SecDevOps za izboljšanje komunikacije in izboljšanje kakovosti izdelka.
Začnite s tem, kar že imate: zahteve, arhitektura, delna preverjanja, usposabljanja, smernice. Ni potrebe, da takoj uporabite vse prakse za vse projekte - premikati iterativno. Ni enotnega standarda - poskus in poskusite različne pristope in rešitve.
Med napakami v informacijski varnosti in funkcionalnimi napakami obstaja enak znak.
Avtomatizirajte vseki se premika. Kar se ne premakne, premaknite in avtomatizirajte. Če se nekaj naredi ročno, to ni dober del procesa. Morda ga je vredno pregledati in tudi avtomatizirati.
Če je velikost ekipe IS majhna - uporabite Security Champions.
Morda vam to, o čemer sem govoril, ne bo ustrezalo in boste prišli do nečesa svojega - in to je dobro. Ampak izberite orodja glede na zahteve za vaš proces. Ne ozirajte se na to, kaj pravi skupnost, da je to orodje slabo in to dobro. Morda bo za vaš izdelek veljalo nasprotno.
Zahteve za orodja.
- Lažno pozitiven nizek nivo.
- Ustrezen čas analize.
- Enostavnost uporabe.
- Razpoložljivost integracij.
- Razumevanje načrta razvoja izdelka.
- Možnost prilagajanja orodij.
Jurijevo poročilo je bilo izbrano za eno najboljših na DevOpsConf 2018. Če se želite seznaniti s še več zanimivimi idejami in praktičnimi primeri, pridite v Skolkovo 27. in 28. maja. znotraj . Še bolje, če ste pripravljeni deliti svoje izkušnje za poročilo do 21. aprila.
Vir: www.habr.com