Imeli smo 2 analizatorja kode, 4 orodja za dinamično testiranje, svoje pripomočke in 250 skript. Ne, da bi bilo vse to potrebno v trenutnem procesu, ampak če sem začel uvajati DevSecOps, moram to narediti do konca.
. Avtorja likov: Justin Roiland in Dan Harmon.
Kaj je SecDevOps? In DevSecOps? Kakšne so razlike? Varnost aplikacij - o čem govorimo? Zakaj klasičen pristop ne deluje več? Na vse te vprašanja pozna odgovor Juri Šabalin iz Swordfish Security. Juri bo podrobno odgovoril na vse in razložil težave prehoda z klasičnega modela varnosti aplikacij na proces DevSecOps: kako pravilno pristopiti k vključitvi procesa varnega razvoja v proces DevOps, ne da bi pri tem kaj uničili, kako preiti osnovne etape testiranja na varnost, katera orodja se lahko uporabljajo, kako se razlikujejo in kako jih pravilno nastaviti, da se izognemo podvodnim kamenjem.
O govorniku: Juri Šabalin - glavni arhitekt varnosti v podjetju Swordfish Security. Odgovoren za uvajanje SSDL, za splošno integracijo orodij za analizo aplikacij v enotno ekosistem razvoja in testiranja. 7 let izkušenj na področju informacijske varnosti. Delal je v Alfa-Banku, Sberbank in v Positive Technologies, ki razvija programsko opremo in nudi storitve. Govornik mednarodnih konferenc ZerONights, PHDays, RISSPA, OWASP.
Varnost aplikacij: o čem govorimo?
Varnost aplikacij je področje varnosti, ki je odgovorno za varnost aplikacij. To se ne nanaša na infrastrukturo ali mrežno varnost, ampak natančno na to, kar pišemo in nad čimer delajo razvijalci - to so pomanjkljivosti in ranljivosti same aplikacije.
Usmeritev — Cikel razvoja varnosti je razvila družba Microsoft. Na diagramu je kanonični model SDLC, katerega glavni cilj je vključitev varnosti v vsakem koraku razvoja, od zahtev do izdaje in prehoda v produkcijo. V Microsoftu so spoznali, da je v industriji preveč napak, da jih je vse več in da je treba nekaj storiti, ter predlagali ta pristop, ki je postal kanoničen.
Varnost aplikacij in SSDL nista namenjena samo odkrivanju ranljivosti, kot se pogosto misli, temveč preprečevanju njihovega pojava. S časom je kanonični pristop podjetja Microsoft izboljšan, razvit in v njem je prišlo do globljega podrobnega poglabljanja.
Kanonik SDLC je zelo podroben v različnih metodologijah – OpenSAMM, BSIMM, OWASP. Metodologije se razlikujejo, vendar so na splošno podobne.
Model zrelosti za vključevanje varnosti
Najbolj mi je všeč BSIMM — . Osnova metodologije je razdelitev procesa Application Security na 4 dome: Upravljanje, Obveščanje, SSDL Touchpoints in Uvedba. V vsakem domu je 12 praks, predstavljenih v obliki 112 aktivnosti.
Vsaka od 112 aktivnosti ima 3 stopnje zrelosti: začetna, srednja in napredna. Vse 12 praks je mogoče raziskovati po razdelkih, izbirati pomembne za vas ter ugotoviti, kako jih uvesti in postopoma dodajati elemente, na primer, statično in dinamično analizo kode ali pregled kode. Obrazložite načrt in po njem mirno delate v okviru uvajanja izbranih aktivnosti.
Zakaj DevSecOps
DevOps je skupen velik proces, v katerem je treba poskrbeti za varnost.
Izvorno predvidevala preverjanja varnosti. V praksi je bilo število varnostnih ekip veliko manjše, kot je danes, in niso delovale kot udeleženci procesa, temveč kot nadzorni organ, ki postavlja zahteve in preverja kakovost izdelka na koncu izdaje. To je klasični pristop, kjer so se ekipe za varnost nahajale za zidom razvoja in niso sodelovale v procesu.
Glavni problem je prav to, da se IKT ločuje od razvoja. Običajno gre za nek kontur IKT, v katerem so 2-3 velika in draga orodja. Enkrat na šest mesecev pride izvorna koda ali aplikacija, ki jo je treba preveriti, nato pa se enkrat na leto izvedejo . Vse to pripelje do zamud pri izidu izdelkov, medtem ko se na razvijalca zgrne ogromno število ranljivosti iz avtomatiziranih sredstev. Vsega tega ni mogoče razčistiti in popraviti, ker še prejšnjih šest mesecev niso razjasnili rezultatov, zdaj pa je prišla nova serija.
V procesu dela naše podjetja opažamo, da varnost v vseh sektorjih in industrijah razume, da je čas, da se začnejo prilagajati in se premikati z razvojem v istem kolesu – v . Paradigma DevSecOps se odlično prilega metodologiji agilnega razvoja, implementaciji, podpori in sodelovanju pri vsaki izdaji in iteraciji.
Prehod na DevSecOps
Najbolj pomembna beseda v Security Development Lifecycle je "proces". Morate to razumeti pre nego što pomislite na kupovinu alata.
Samo uključivanje alata u DevOps proces nije dovoljno - važno je interakcija i razumevanje među učesnicima procesa.
Ljudi su važniji od alata
Često planiranje procesa sigurnog razvoja počinje izborom i kupovinom alata, a završava pokušajima integracije alata u postojeći proces, koji ostaju samo pokušaji. To vodi do tužnih posledica, jer svaki alat ima svoje karakteristike i ograničenja.
Uobičajen slučaj je kada odeljenje za sigurnost izabere dobar, skup alat sa širokim mogućnostima, i dođe do programera - da ga integrišu u proces. Ali ne ide - proces je postavljen tako da ograničenja već kupljenog alata ne odgovaraju trenutnoj paradigmi.
Prvo opišite koji rezultat želite i kako će izgledati proces. To će pomoći da se razumeju uloge alata i sigurnosti u procesu.
Počnite s onim što se već koristi
Pre kupovine skupih alata, pogledajte šta već imate. U svakoj kompaniji postoje zahtevi za sigurnost koji se postavljaju pred razvoj, postoje provere, pentesti - zašto ne bi sve to pretvorili u razumljiv i zgodan oblik za sve?
Obično su zahtevi - to je papirna hrpa koja leži na polici. Bio je slučaj kada smo došli u kompaniju da pogledamo procese i tražili da pokažu zahteve za sigurnost softvera. Specijalista koji se time bavio dugo je tražio:
- Sada, negde u beleškama je putanja gde leži taj dokument.
Na kraju smo dobili dokument nakon nedelju dana.
Za zahteve, provere i ostalo, napravite stranicu, na primer, na Confluence — to je svima zgodno.
Lakše je preformatirati ono što već postoji i koristiti to kao polaznu tačku.
Koristite Security Champions
Obično, u prosečnoj kompaniji sa 100-200 programera radi jedan stručnjak za sigurnost, koji obavlja nekoliko funkcija, i fizički ne može sve da proveri. Čak i ako se trudi koliko može - ne može sam da proveri sav kod koji generiše razvoj. Za takve slučajeve razvijen je koncept - .
Security Champions so osebak znotraj razvojne ekipe, ki je zainteresiran za varnost vašega izdelka.
Security Champion je vstopna točka v razvojno ekipo in evangelist varnosti v enem.
Običajno, ko v razvojno ekipo pride varnostnik in pokaže na napako v kodi, dobi presenečen odgovor:
- Kdo ste pa vi? Vidim vas prvič. Pri meni je vse v redu - moj starejši kolega je na code review odobril, gremo naprej!
To je tipična situacija, saj imajo starejši ali enostavno kolegi iz ekipe, s katerimi razvijalec nepretrgoma sodeluje pri delu in code review, precej več zaupanja. Če namesto varnostnika na napako in posledice pokaže Security Champion, bo njegova beseda imela večjo težo.
Prav tako razvijalci bolje poznajo svojo kodo kot kateri koli varnostnik. Človeku, ki ima vsaj 5 projektov v orodju za statično analizo, je običajno težko zapomniti vse podrobnosti. Security Champions poznajo svoj izdelek: kaj kjer sodeluje in na kaj se osredotočiti najprej - so učinkovitejši.
Zato razmislite o uvedbi Security Champions in razširitvi vpliva varnostne ekipe. Za samega prvaka je to prav tako koristno: strokovni razvoj na novem področju, širitev tehničnega obzorja, izboljšanje tehničnih, upravljalskih in vodstvenih sposobnosti, povečanje tržne vrednosti. To je nekakšna oblika socialne inženiringa, vaše 'očesi' v razvojni ekip.
Faze testiranja
pravi, da 20% truda prinaša 80% rezultata. Ta 20% so prakse analize aplikacij, ki jih lahko in jih je treba avtomatizirati. Primeri takšnih aktivnosti so statična analiza - SAST, dinamična analiza - DAST, in nadzor odprtokodnega. Povedal vam bom več o aktivnostih, ter orodjih, s katerimi se običajno srečujemo pri njihovi uvedbi v proces, in kako to izvesti pravilno.
Glavne težave z orodji
Označil bom aktualne težave, ki se pojavljajo pri vseh orodjih in zahtevajo pozornost. Razdelil jih bom podrobneje, da se ne ponavljam.
Dolgo trajanje analize. Če od commita do proizvodnje mine 30 minut za vse teste in zbiranje, bodo preverjanja informacijske varnosti trajala en dan. Nihče ne bo zaviral procesa. Upoštevajte to posebnost in delajte sklepe.
Visoka raven False Negative ali False Positive. Vsi izdelki so različni, vsi uporabljajo različne ogrodja in svoj slog pisanja kode. Na različni kodni osnovi in tehnologijah lahko orodja prikažejo različno raven False Negative in False Positive. Zato glejte, kaj točno v vaši podjetju in za vaše aplikacije bo prikazalo dobre in zanesljive rezultate.
Ni integracij z obstoječimi orodji. Oglejte si orodja z vidika integracij, s tistim, kar že uporabljate. Na primer, če imate Jenkins ali TeamCity - preverite integracijo orodij ravno s tem programom, in ne z GitLab CI, ki ga ne uporabljate.
Pomanjkanje ali prekomerna zapletenost prilagoditev. Če orodje nima API-ja, zakaj bi ga potrebovali? Vse, kar lahko naredite v vmesniku, bi moralo biti dostopno prek API-ja. Idealno bi imelo orodje možnost prilagajanja preverjanj.
Ni Roadmap razvoja produkta. Razvoj ne stoji na mestu, vedno uporabljamo nove ogrodja in funkcije, staro kodo prepisujemo v nove jezike. Želimo biti prepričani, da bo orodje, ki ga kupimo, podpiralo nove ogrodja in tehnologije. Zato je pomembno vedeti, da ima izdelek realen in pravilen razvoj.
Posebnosti procesa
Poleg posebnosti orodij upoštevajte tudi posebnosti razvoja. Na primer, motenje razvoja je tipična napaka. Poglejmo, katere druge posebnosti je treba upoštevati in na kaj mora ekipa za varnost dati pozornost.
Da ne bi zamudili rokov razvoja in izdaje, ustvarite različna pravila in različne show stoppers — kriteriji za zaustavitev procesa zbiranja v primeru ranljivosti — za različna okolja.Na primer, razumemo, da trenutna veja gre na razvojno stojalo ali UAT, zato ne ustavljamo in ne rečemo:
— Imate tukaj ranljivosti, ne boste šli naprej!
Na tej točki je pomembno, da razvijalcem poveste, da so prisotne varnostne težave, na katere je treba opozoriti.
Prisotnost ranljivosti ni ovira za nadaljnje testiranje.: ročnega, integracijskega ali manualnega. Po drugi strani pa moramo na nek način izboljšati varnost izdelka, da razvijalci ne pozabijo na to, kar ugotovi varnost. Zato včasih ravnamo tako: na testnem okolju, ko se izda nova različica, preprosto obvestimo razvojno skupino:
— Fantje, imate težave, prosimo, posvetite jim pozornost.
V fazi UAT ponovno prikazujemo opozorila o ranljivostih, medtem ko v fazi prehoda na produkcijo povemo:
— Fantje, večkrat smo vas opozorili, niste storili ničesar – s tem vas ne bomo pustili ven.
Če govorimo o kodi in dinamiki, je treba prikazovati in opozarjati na ranljivosti samo tistih funkcij in kode, ki so bile pravkar napisane v tej funkciji. Če je razvijalec premaknil gumb za 3 piksle in mu povemo, da ima tam SQL injekcijo in da jo mora nujno popraviti – to ni pravilno. Poglejte le na to, kar je zdaj napisano, in na spremembo, ki prihaja v aplikacijo.
Recimo, da imamo nek funkcionalni defect – to, kako aplikacija ne bi smela delovati: sredstva se ne prenesejo, ob kliku na gumb ni prehoda na naslednjo stran ali izdelek se ne naloži. Varnostni defekti so enaki defektom, vendar ne v kontekstu delovanja aplikacije, temveč varnosti.
Niso vse težave kvalitete programske opreme težave z varnostjo. Vendar so vse varnostne težave povezane s kakovostjo programske opreme. Sherif Mansour, Expedia.
Ker so vse ranljivosti enaki defekti, morajo biti na istem mestu kot vsi defekti razvoja. Zato pozabite na poročila in strašne PDF dokumente, ki jih nihče ne bere.
Ko sem delal v podjetju, ki se ukvarja z razvojem, sem prejel poročilo iz orodij za statično analizo. Odprl sem ga, se šokiral, skuhal kavo, prelistal 350 strani, zaprl in šel naprej delati. Velika poročila so mrtva poročila. Običajno nikamor ne gredo, e-pošta se izbriše, pozabi, izgubi ali pa poslovanje pravi, da prevzema tveganja.
Kaj narediti? Potrjeni napaki, ki smo jih odkrili, enostavno pretvorimo v obliko, primerno za razvoj, na primer jih uvrstimo v backlog v Jira. Napake prioritetiziramo in jih odpravljamo po vrstnem redu prednosti, skupaj s funkcionalnimi napakami in napakami testov.
Statistična analiza - SAST
To je analiza kode za prisotnost ranljivosti, vendar to ni isto kot SonarQube. Preverjamo ne le po vzorcih ali slogu. Pri analizi se uporablja vrsta pristopov: po drevesu ranljivosti, po , po analizi konfiguracijskih datotek. To je vse, kar se nanaša neposredno na kodo.
Prednosti pristopa: odkrivanje ranljivosti v kodi v zgodnji fazi razvoja, ko še ni postavljenih okolij in končnih orodij, ter možnost inkrementalnega skeniranja: skeniranje dela kode, ki se je spremenilo, in samo funkcije, ki jo trenutno razvijamo, kar zmanjšuje čas skeniranja.
Недостатки — to je odsotnost podpore potrebnim jeziku.
Potrebne integracije, ki bi morale biti v orodjih, po mojem subjektivnem mnenju:
- Integracijsko orodje: Jenkins, TeamCity in Gitlab CI.
- Razvojno okolje: Intellij IDEA, Visual Studio. Razvijalcu je lažje ne iskati v nerazumljivem vmesniku, ki si ga je še treba zapomniti, ampak na svojem delovnem mestu v svojem razvojnem okolju videti vse potrebne integracije in ranljivosti, ki jih je odkril.
- Pregled kode: SonarQube in ročni pregled.
- Sledenje napakam: Jira in Bugzilla.
Na sliki je nekaj najboljših predstavnikov statične analize.
Pomembni niso orodja, ampak proces, zato obstajajo Open Source rešitve, ki so prav tako dobre za preizkušanje procesa.
SAST Open Source ne bo našel ogromnega števila ranljivosti ali zapletenih DataFlow, vendar jih je pri postavitvi procesa mogoče in treba uporabljati. Pomagajo razumeti, kako bo postavljen proces, kdo bo odgovoren za napake, kdo jih bo poročal, kdo - poročal. Če želite izvesti začetno fazo postavitve varnosti vaše kode - uporabite Open Source rešitve.
Kako to integrirati, če ste na začetku poti in nimate ničesar: niti CI, niti Jenkins, niti TeamCity? Preglejmo integracije v proces.
Integracija na ravni CVS
Če imate Bitbucket ali GitLab, lahko izvesti integracijo na ravni .
Po dogodku — pull request, commit. Skenirate kodo in v statusu builda pokažete, ali je pregled varnosti uspel ali ne.
Povratne informacije. Seveda, povratne informacije so vedno potrebne. Če ste le izvedli nalogo na področju varnosti, vse spakirali v škatlo in nikomur nič povedali o tem, na koncu meseca pa nato izmeteli kup napak – to ni prav in ni dobro.
Integracija s sistemom za pregled kode
Nekoč smo v vrsti pomembnih projektov nastavili tehničnega uporabnika AppSec kot privzetega pregledovalca. Odvisno od tega, ali so bile napake ugotovljene v novem kodu ali ne, pregledovalec na pull requestu nastavi status na 'sprejeto' ali 'potrebuje delo' – ali je vse v redu, ali pa je potrebno dopolniti in dodati povezave, kaj točno je potrebno dopolniti. Za integracijo z različico, ki gre v produkcijo, smo imeli vključen prepoved merah, če testiranje varnosti ni bilo opravljeno. To smo vključevali v ročni pregled kode, ostali udeleženci v procesu so videli statuse glede varnosti prav za ta specifičen postopek.
Integracija s SonarQube
Mnogi imajo za kakovost kode. Tudi tukaj velja enako – mogoče je narediti iste gates samo za orodja SAST. Imeli bomo isti vmesnik, isti quality gate, le da se bo imenoval security gate. In tako, če imate nastavljen proces z uporabo SonarQube, lahko vse enostavno integrirate tja.
Integracija na ravni CI
Tudi tukaj je vse kar preprosto:
- Na istem nivoju kot avtotesti, enotni test.
- Razdelitev po fazah razvoja: dev, test, prod. Morda vključuje različne sklope pravil ali različne pogoje neuspeha: ustavimo gradnjo, ne ustavimo gradnje.
- Sinhrono/asinhrono izvajanje. Čakamo na zaključek preverjanja testov varnosti ali ne čakamo. To pomeni, da smo jih le zagnali in šli naprej, nato pa nam pride status, da je vse dobro ali slabo.
To je vse v idealnem rožnatem svetu. V resničnem življenju to ni tako, vendar se trudimo. Rezultat izvajanja varnostnih pregledov bi moral biti podoben rezultatom enotnih testov.
Na primer, vzeli smo velik projekt in se odločili, da ga bomo zdaj skenirali s SAST-om — OK. Ta projekt smo dali v SAST, rezultati pa so pokazali 20.000 ranljivosti, s trdno odločitvijo smo sprejeli, da je vse v redu. 20.000 ranljivosti — to je naš tehnični dolg. Dolg bomo dali v škatlo in počasi ga bomo razreševali ter odpravljali napake v orodjih za sledenje napakam. Najeli bomo podjetje, naredili bomo vse sami ali pa nam bodo pomagali Security Champions — in tehnični dolg se bo zmanjšal.
In vse nove ranljivosti v novem kodu morajo biti odpravljene na enak način kot napake v enotnih ali avto testih. Pogoja, da se je gradnja zagnala, so se pojavili dva testa in dva testa v zvezi z varnostjo. OK — smo šli pogledat, kaj se je zgodilo, popravili eno, popravili drugo, naslednjič smo zagnali — vse je v redu, novih ranljivosti ni, testi niso bili neuspešni. Če je ta naloga bolj zapletena in jo je treba dobro razumeti, ali pa popravilo ranljivosti zajema velike dele pod masko: odprli smo napako v orodju za sledenje napakam, ta se prioritizira in odpravi. Žal svet ni popoln in testiranja včasih odpadejo.
Primer security gate — enakovreden quality gate, glede na prisotnost in število ranljivosti v kodi.
Integriramo z SonarQube — vtičnik se namesti, vse je zelo udobno in super.
Integracija z razvojnim okoljem
Možnosti integracije:
- Zagon skeniranja iz razvojnega okolja še pred commit.
- Pregled rezultatov.
- Analiza rezultatov.
- Sinhronizacija s strežnikom.
Tako nekako izgleda pridobivanje rezultatov s strežnika.
V našem razvojnem okolju preprosto se pojavi dodatna točka, ki sporoča, da so bile med skeniranjem odkrite takšne ranljivosti. Takoj lahko popravite kodo, pregledate priporočila in . Vse to je na delovnem mestu razvijalca, kar je zelo priročno — ni vam treba hoditi na druge povezave in dodatno iskati kaj.
Open Source
To je moja najljubša tema. Vsi uporabljajo Open Source biblioteke — zakaj pisati kup podpornih kod in koles, ko lahko vzamete že pripravljeno knjižnico, v kateri je vse že izvedeno?
Seveda, to drži, vendar so knjižnice tudi zapisane s strani ljudi, vsebujejo določena tveganja in vsebujejo ranljivosti, o katerih se občasno ali stalno poroča. Zato je naslednji korak v varnosti aplikacij analiza komponent odprte kode.
Analiza odprte kode – OSA
Orodje vključuje tri velike faze.
Iskanje ranljivosti v knjižnicah. Na primer, orodje ve, da uporabljamo določeno knjižnico in da ali v bug trackerjih obstajajo ranljivosti, povezane s to različico knjižnice. Ko poskušamo uporabiti to knjižnico, orodje izda opozorilo, da je knjižnica ranljiva in priporoča uporabo druge različice, kjer ranljivosti ni.
Analiza licenčne čistosti. Pri nas to še ni posebej priljubljeno, vendar če delate s tujino, lahko občasno dobite kazen za uporabo komponente z odprto kodo, ki je ne smete uporabljati ali spreminjati. V skladu s politiko licenciranja knjižnice tega ne smemo početi. Ali pa, če smo jo spremenili in jo uporabljamo, moramo objaviti svojo kodo. Seveda nihče noče objaviti kode svojih izdelkov, vendar se pred tem lahko zaščitimo.
Analiza komponent, ki se uporabljajo v industrijskem okolju. Predstavljamo si hipotezo, da smo končno končali razvoj in izdali naš zadnji izdelek mikroservisa. Odlično deluje teden, mesec, leto. Je ne zbiramo, varnostne teste ne izvajamo, vse se zdi v redu. A nenadoma, dve tedni po izdaji, pride do kritične ranljivosti v odprtokodni komponenti, ki jo uporabljamo v tej gradnji v proizvodnem okolju. Če ne zapišemo, kaj in kje uporabljamo, te ranljivosti preprosto ne bomo opazili. Nekatera orodja omogočajo spremljanje ranljivosti v knjižnicah, ki se zdaj uporabljajo v proizvodnji. To je zelo koristno.
Mogućnosti:
- Različne politike za različne faze razvoja.
- Spremljanje komponent v industrijskem okolju.
- Nadzor knjižnic v okviru organizacije.
- Podpora za različne sisteme zbiranja in jezike.
- Analiza Docker slik.
Nekaj primerov vodilnih podjetij, ki se ukvarjajo z analizo odprte kode.
Eden edini brezplačen med njimi je from OWASP. You can enable it in the early stages, see how it works and what it supports. Primarily, it covers all cloud products or on-premise, but their database is still sent online. They send not your libraries, but hashes or their computed values, and fingerprints to their server to get notified about vulnerabilities.
Integration into the process
Library control within the perimeter, which are downloaded from external sources. We have external and internal repositories. For example, within Event Central, there is Nexus, and we want there to be no vulnerabilities with a status of 'critical' or 'high' in our internal repository. Proxying can be configured using the Nexus Firewall Lifecycle tool to ensure such vulnerabilities are filtered out and do not enter the internal repository.
Integration into CI. At the same level as automated tests, unit tests, and phase separation in development: dev, test, prod. At each stage, any libraries can be downloaded and anything can be used, but if there is something severe with a status of 'critical', it may be worth bringing this to the developers' attention before going live.
Integration with artifacts: Nexus and JFrog.
Integration into the development environment. The tools you choose should integrate with development environments. Developers should have access to scanning results from their workstations, or the ability to scan and check the code for vulnerabilities before committing to CVS.
Integration into CD. This is a cool feature that I really like and have already talked about—monitoring the emergence of new vulnerabilities in the production environment. It works roughly like this.
We have Public Component Repositories — neki alati vani i naš unutarnji repozitorij. Želimo da u njemu budu samo pouzdane komponente. Kada proksiramo zahtjev, provjeravamo da preuzeta biblioteka nema ranjivosti. Ako spada pod određene politike koje postavljamo i obavezno dogovaramo s razvojem, onda je ne preuzimamo i dolazi obavijest o korištenju druge verzije. Također, ako u biblioteci postoji nešto stvarno kritično i loše, tada programer i na fazi instalacije neće dobiti biblioteku — neka koristi verziju iznad ili ispod.
- Prilikom gradnje provjeravamo da nitko nije podmetnuo ništa loše, da su svi komponenti sigurni i da nitko nije donio ništa opasno na USB-u.
- U repozitoriju imamo samo pouzdane komponente.
- Prilikom implementacije još jednom provjeravamo sam paket: war, jar, DL ili Docker sliku da li odgovara politici.
- Kada izlazimo u produkciju, pratimo što se događa u industrijskom okruženju: pojavljuju li se ili ne pojavljuju kritične ranjivosti.
Dinamička analiza — DAST
Alati za dinamičku analizu se drastično razlikuju od svega što je ranije rečeno. Ovo je neka simulacija rada korisnika s aplikacijom. Ako je to web aplikacija, šaljemo zahtjeve, imitujući rad klijenta, klikamo na gumbe na prednjem dijelu, šaljemo umjetne podatke iz obrasca: navodnike, zagrade, simbole u različitim kodiranjima, kako bismo vidjeli kako aplikacija radi i obrađuje vanjske podatke.
Ovaj sustav također omogućava provjeru standardnih ranjivosti u otvorenom kodu. Budući da DAST ne zna koji otvoreni kod koristimo, jednostavno prikazuje "zlonamjerne" uzorke i analizira odgovore servera:
— Aha, ovdje postoji problem deserializacije, a ovdje nema.
U tome postoji veliki rizik, jer ako provodite ovaj test sigurnosti na istom okruženju s kojim rade testeri — mogu se dogoditi neugodne stvari.
- Visoka opterećenja na mrežnom serveru aplikacije.
- Nema integracija.
- Mogućnost promjene postavki analizirane aplikacije.
- Nema podrške za potrebne tehnologije.
- Složenost podešavanja.
Imeli smo situacijo, ko smo končno zagnali AppScan: dolgo smo se trudili pridobiti dostop do aplikacije, dobili 3 račune in se razveselili - končno bomo vse preverili! Zagnali smo skeniranje in prvo, kar je naredil AppScan - se je povzpel v administracijski panel, preizkusil vse gumbe, spremenil polovico podatkov, nato pa je celo ubil strežnik s svojim -zahtevami. Razvoj s testiranjem je rekel:
- Fantje, norčujete se?! Dali smo vam račune, vi pa ste uničili stalno okolje!
Upoštevajte morebitna tveganja. V idealnem primeru pripravite ločeno okolje za testiranje varnosti, ki bo vsaj nekoliko izolirano od drugega okolja, in administracijo preverjajte raje v ročnem načinu. To je pentest - tisti preostali odstotki truda, ki jih trenutno ne obravnavamo.
Treba je upoštevati, da lahko to uporabimo kot alternativo obremenitvenemu testiranju. V prvi fazi lahko aktivirate dinamični skener v 10-15 tokov in pogledate, kaj se zgodi, vendar običajno praksa pokaže, da ne prinese nič dobrega.
Nekaj virov, ki jih običajno uporabljamo.
Izpostaviti je treba - to je 'švicarski nož' za vsakega strokovnjaka za varnost. Vsi ga uporabljajo in je zelo priročen. Sedaj je izšla nova demo različica enterprise edition. Če je prej to bila le samostojna orodja s plugin-i, so zdaj končno razvijalci naredili velik strežnik, s katerega bo mogoče upravljati več agentov. To je super, priporočam, da preizkusite.
Integration into the process
Integracija poteka dovolj dobro in preprosto: zagon skeniranja po uspešni namestitvi aplikacije na okolju in skeniranje po uspešno opravljenem integracijskem testiranju.
Če integracije ne delujejo ali so tam le nadomestki in mock-funkcije, je to brezsmiselno in brezpredmetno - karkoli vzorec pošljemo, bo strežnik enako odgovarjal.
- Idealno je ločeno okolje za testiranje.
- Pred začetkom testiranja zapišite zaporedje prijave.
- Testiranje sistema upravljanja - le ročno.
Postopek
Malo splošno o procesu na splošno in o delovanju vsakega orodja posebej. Vse aplikacije so različne - pri eni bolje deluje dinamična analiza, pri drugi statična, pri tretji analiza OpenSource, pentesti ali sploh kaj drugega, na primer dogodki z. .
Vsak proces potrebuje nadzor.
Da bi razumeli, kako proces deluje in kje ga je mogoče izboljšati, je treba zbirati metrike iz vsega, kar je mogoče doseči, vključno s proizvodnimi metrikami, metrikami orodij in iz sledilnikov napak.
Vsaki podatki so koristni. Treba je gledati z različnih vidikov, kje se bolje uporablja tisto ali drugo orodje, kje proces konkretno ni učinkovit. Morda bi bilo smiselno pogledati na čas odziva razvoja, da bi razumeli, kje izboljšati proces na podlagi časa. Več podatkov, več vidikov lahko zgradimo od splošnih do podrobnosti vsakega procesa.
Ker imajo vsi statični in dinamični analizatorji svoja API, svoje načine zagonov in načela, nekateri imajo načrtovalnike, drugi ne – mi razvijamo orodje AppSec Orkestrator, ki omogoča enotno točko dostopa do celotnega procesa izdelave in upravljanje iz enega mesta.
Za managerje, razvijalce in inženirje varnosti je ena sama točka dostopa, iz katere lahko pogledajo, kaj je zagnano, nastavijo in zagnajo skeniranje, dobijo rezultate skeniranja in postavijo zahteve. Trudimo se, da bi se izognili papirjem in vse prevedli v človeški jezik, ki ga uporablja razvoj – strani na Confluence z statusi in metričnimi podatki, napake v Jira ali v različnih sledilnikih napak, ali pa vgraditev v sinhroni/asinhroni proces v CI/CD.
Ključna sporočila
Orodja niso glavna. Najprej premislite o procesu – nato uvedite orodja. Orodja so primerna, a draga, zato lahko začnete s procesom in nastavite sodelovanje ter razumevanje med razvojem in varnostjo. Z vidika varnosti – ne bi smeli "ustavljati" vsega, kar pride na uho, z vidika razvoja – če je kaj izjemno kritičnega, je to treba rešiti, ne pa prezreti.
Kakovost izdelka je skupni cilj tako za varnost kot razvoj. Dela uresničujemo isto, trudimo se, da vse pravilno deluje, ter se izognemo tveganju za sloves in finančnim izgubam. Prav zato spodbujamo pristop k DevSecOps in SecDevOps, da bi izboljšali komunikacijo in naredili izdelek bolj kakovosten.
Začnite s tem, kar že imate.: zahteve, arhitektura, parcialne provjere, obuke, smjernice. Nije potrebno odmah primijeniti sve prakse na sve projekte — napredujte iterativno. Ne postoji jedinstveni standard — eksperimentirajte i isprobavajte različite pristupe i rješenja.
Između nedostataka IB i funkcionalnih nedostataka postoji znak jednakosti.
Automatizirajte sve, što se pomiče. Sve što se ne pomiče — pokrenite i automatizirajte. Ako se nešto radi ručno, to nije dobar dio procesa. Možda bi ga trebalo preispitati i takođe automatizirati.
Ako je veličina tima IB mala — koristite Security Champions.
Možda to o čemu sam govorio neće odgovarati vama i smišljate nešto svoje — i to je dobro. Ali birajte alate, uzimajući u obzir zahtjeve svog procesa. Ne slušajte šta zajednica govori, da je ovaj alat loš, a taj dobar. Možda, na vašem proizvodu, sve će ispasti obrnuto.
Zahtjevi za alate.
- Nizak nivo False Positive.
- Razuman vrijeme analize.
- Jednostavnost korištenja.
- Prisutnost integracija.
- Razumijevanje Roadmap-a razvoja proizvoda.
- Mogućnost prilagodbe alata.
Izlaganje Jurija izabrano je kao jedno od najboljih na DevOpsConf 2018. Da biste se upoznali s još većim brojem zanimljivih ideja i praktičnih slučajeva, dođite 27. i 28. maja u Skolkovo na u okviru . A još bolje, ako ste spremni dijeliti svoje iskustvo, tada za izlaganje do 21. aprila.
Izvor: habr.com
