{"id":31852,"date":"2019-10-31T21:43:30","date_gmt":"2019-10-31T18:43:30","guid":{"rendered":"https:\/\/prohoster.info\/blog\/strah-i-nenavist-devsecops\/"},"modified":"2019-10-31T21:43:30","modified_gmt":"2019-10-31T18:43:30","slug":"strah-i-nenavist-devsecops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/strah-i-nenavist-devsecops","title":{"rendered":"Strah i mr\u017enja DevSecOps-a","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Imeli smo 2 analizatorja kode, 4 orodja za dinami\u010dno testiranje, svoje pripomo\u010dke in 250 skript. Ne, da bi bilo vse to potrebno v trenutnem procesu, ampak \u010de sem za\u010del uvajati DevSecOps, moram to narediti do konca.<\/p>\n

\"Strah
\n
\nSource<\/a><\/noindex>. Avtorja likov: Justin Roiland in Dan Harmon.<\/i><\/p>\n

Kaj je SecDevOps? In DevSecOps? Kak\u0161ne so razlike? Varnost aplikacij - o \u010dem govorimo? Zakaj klasi\u010den pristop ne deluje ve\u010d? Na vse te vpra\u0161anja pozna odgovor Juri \u0160abalin<\/b> iz\u00a0Swordfish Security. <\/b>Juri bo podrobno odgovoril na vse in razlo\u017eil te\u017eave prehoda z klasi\u010dnega modela varnosti aplikacij na proces DevSecOps: kako pravilno pristopiti k vklju\u010ditvi procesa varnega razvoja v proces DevOps, ne da bi pri tem kaj uni\u010dili, 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.
\n<\/a><\/noindex>
\n

\r\n \"Predvajaj\r\n
<\/div>\r\n <\/div><\/center>
\nO govorniku:<\/b> Juri \u0160abalin - <\/b>glavni arhitekt varnosti v podjetju Swordfish Security<\/b>. Odgovoren za uvajanje SSDL, za splo\u0161no integracijo orodij za analizo aplikacij v enotno ekosistem razvoja in testiranja. 7 let izku\u0161enj na podro\u010dju 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.<\/p>\n

Varnost aplikacij: o \u010dem govorimo?<\/h2>\n

\nVarnost aplikacij<\/b>\u00a0je podro\u010dje varnosti, ki je odgovorno za varnost aplikacij. To se ne nana\u0161a na infrastrukturo ali mre\u017eno varnost, ampak natan\u010dno na to, kar pi\u0161emo in nad \u010dimer delajo razvijalci - to so pomanjkljivosti in ranljivosti same aplikacije.<\/p>\n

Usmeritev SDL ali SDLC<\/a><\/noindex>\u00a0\u2014 Cikel razvoja varnosti<\/b>\u00a0je razvila dru\u017eba Microsoft. Na diagramu je kanoni\u010dni model SDLC, katerega glavni cilj je vklju\u010ditev varnosti v vsakem koraku razvoja, od zahtev do izdaje in prehoda v produkcijo. V Microsoftu so spoznali, da je v industriji preve\u010d napak, da jih je vse ve\u010d in da je treba nekaj storiti, ter predlagali ta pristop, ki je postal kanoni\u010den.<\/p>\n

\"Strah
\n
\nVarnost aplikacij in SSDL nista namenjena samo odkrivanju ranljivosti, kot se pogosto misli, temve\u010d prepre\u010devanju njihovega pojava. S \u010dasom je kanoni\u010dni pristop podjetja Microsoft izbolj\u0161an, razvit in v njem je pri\u0161lo do globljega podrobnega poglabljanja.<\/p>\n

\"Strah
\n
\nKanonik SDLC je zelo podroben v razli\u010dnih metodologijah \u2013 OpenSAMM, BSIMM, OWASP. Metodologije se razlikujejo, vendar so na splo\u0161no podobne.<\/p>\n

Model zrelosti za vklju\u010devanje varnosti<\/h3>\n

\nNajbolj mi je v\u0161e\u010d BSIMM<\/b>\u00a0\u2014 Model zrelosti za vklju\u010devanje varnosti<\/a><\/noindex>. Osnova metodologije je razdelitev procesa Application Security na 4 dome: Upravljanje, Obve\u0161\u010danje, SSDL Touchpoints in Uvedba. V vsakem domu je 12 praks, predstavljenih v obliki 112 aktivnosti.<\/p>\n

\"Strah
\n
\nVsaka od 112 aktivnosti ima 3 stopnje zrelosti<\/b>: za\u010detna, srednja in napredna. Vse 12 praks je mogo\u010de raziskovati po razdelkih, izbirati pomembne za vas ter ugotoviti, kako jih uvesti in postopoma dodajati elemente, na primer, stati\u010dno in dinami\u010dno analizo kode ali pregled kode. Obrazlo\u017eite na\u010drt in po njem mirno delate v okviru uvajanja izbranih aktivnosti.<\/p>\n

Zakaj DevSecOps<\/h2>\n

<\/p>\n

DevOps je skupen velik proces, v katerem je treba poskrbeti za varnost.<\/p><\/blockquote>\n

\nIzvorno DevOps<\/b><\/a><\/noindex> predvidevala preverjanja varnosti. V praksi je bilo \u0161tevilo varnostnih ekip veliko manj\u0161e, kot je danes, in niso delovale kot udele\u017eenci procesa, temve\u010d kot nadzorni organ, ki postavlja zahteve in preverja kakovost izdelka na koncu izdaje. To je klasi\u010dni pristop, kjer so se ekipe za varnost nahajale za zidom razvoja in niso sodelovale v procesu.<\/p>\n

\"Strah
\n
\nGlavni problem je prav to, da se IKT lo\u010duje od razvoja. Obi\u010dajno gre za nek kontur IKT, v katerem so 2-3 velika in draga orodja. Enkrat na \u0161est mesecev pride izvorna koda ali aplikacija, ki jo je treba preveriti, nato pa se enkrat na leto izvedejo pentesti<\/a><\/noindex>. Vse to pripelje do zamud pri izidu izdelkov, medtem ko se na razvijalca zgrne ogromno \u0161tevilo ranljivosti iz avtomatiziranih sredstev. Vsega tega ni mogo\u010de raz\u010distiti in popraviti, ker \u0161e prej\u0161njih \u0161est mesecev niso razjasnili rezultatov, zdaj pa je pri\u0161la nova serija.<\/p>\n

V procesu dela na\u0161e podjetja opa\u017eamo, da varnost v vseh sektorjih in industrijah razume, da je \u010das, da se za\u010dnejo prilagajati in se premikati z razvojem v istem kolesu \u2013 v\u00a0Agile<\/b><\/a><\/noindex>. Paradigma DevSecOps se odli\u010dno prilega metodologiji agilnega razvoja, implementaciji, podpori in sodelovanju pri vsaki izdaji in iteraciji.<\/p>\n

\"Strah
\n<\/p>\n

Prehod na DevSecOps<\/h2>\n

\nNajbolj pomembna beseda v Security Development Lifecycle je \"proces\"<\/b>. Morate to razumeti pre nego \u0161to pomislite na kupovinu alata.<\/p>\n

Samo uklju\u010divanje alata u DevOps proces nije dovoljno - va\u017eno je interakcija i razumevanje me\u0111u u\u010desnicima procesa.<\/p><\/blockquote>\n

<\/p>\n

Ljudi su va\u017eniji od alata<\/h3>\n

\n\u010cesto planiranje procesa sigurnog razvoja po\u010dinje izborom i kupovinom alata, a zavr\u0161ava poku\u0161ajima integracije alata u postoje\u0107i proces, koji ostaju samo poku\u0161aji. To vodi do tu\u017enih posledica, jer svaki alat ima svoje karakteristike i ograni\u010denja.<\/p>\n

Uobi\u010dajen slu\u010daj je kada odeljenje za sigurnost izabere dobar, skup alat sa \u0161irokim mogu\u0107nostima, i do\u0111e do programera - da ga integri\u0161u u proces. Ali ne ide - proces je postavljen tako da ograni\u010denja ve\u0107 kupljenog alata ne odgovaraju trenutnoj paradigmi.<\/p>\n

Prvo opi\u0161ite koji rezultat \u017eelite i kako \u0107e izgledati proces. To \u0107e pomo\u0107i da se razumeju uloge alata i sigurnosti u procesu.<\/p><\/blockquote>\n

<\/p>\n

Po\u010dnite s onim \u0161to se ve\u0107 koristi<\/h3>\n

\nPre kupovine skupih alata, pogledajte \u0161ta ve\u0107 imate. U svakoj kompaniji postoje zahtevi za sigurnost koji se postavljaju pred razvoj, postoje provere, pentesti - za\u0161to ne bi sve to pretvorili u razumljiv i zgodan oblik za sve?<\/p>\n

Obi\u010dno su zahtevi - to je papirna hrpa koja le\u017ei na polici. Bio je slu\u010daj kada smo do\u0161li u kompaniju da pogledamo procese i tra\u017eili da poka\u017eu zahteve za sigurnost softvera. Specijalista koji se time bavio dugo je tra\u017eio:<\/p>\n

- Sada, negde u bele\u0161kama je putanja gde le\u017ei taj dokument.<\/i><\/p>\n

Na kraju smo dobili dokument nakon nedelju dana.<\/p>\n

Za zahteve, provere i ostalo, napravite stranicu, na primer, na\u00a0Confluence<\/b>\u00a0\u2014 to je svima zgodno.<\/p>\n

Lak\u0161e je preformatirati ono \u0161to ve\u0107 postoji i koristiti to kao polaznu ta\u010dku.<\/p><\/blockquote>\n

<\/p>\n

Koristite Security Champions <\/h3>\n

\nObi\u010dno, u prose\u010dnoj kompaniji sa 100-200 programera radi jedan stru\u010dnjak za sigurnost, koji obavlja nekoliko funkcija, i fizi\u010dki ne mo\u017ee sve da proveri. \u010cak i ako se trudi koliko mo\u017ee - ne mo\u017ee sam da proveri sav kod koji generi\u0161e razvoj. Za takve slu\u010dajeve razvijen je koncept - Security Champions<\/b><\/a><\/noindex>.<\/p>\n

Security Champions so osebak znotraj razvojne ekipe, ki je zainteresiran za varnost va\u0161ega izdelka.<\/p><\/blockquote>\n

\"Strah
\n
\nSecurity Champion je vstopna to\u010dka v razvojno ekipo in evangelist varnosti v enem.<\/p>\n

Obi\u010dajno, ko v razvojno ekipo pride varnostnik in poka\u017ee na napako v kodi, dobi presene\u010den odgovor:<\/p>\n

- Kdo ste pa vi? Vidim vas prvi\u010d. Pri meni je vse v redu - moj starej\u0161i kolega je na code review odobril, gremo naprej!<\/i><\/p>\n

To je tipi\u010dna situacija, saj imajo starej\u0161i ali enostavno kolegi iz ekipe, s katerimi razvijalec nepretrgoma sodeluje pri delu in code review, precej ve\u010d zaupanja. \u010ce namesto varnostnika na napako in posledice poka\u017ee Security Champion, bo njegova beseda imela ve\u010djo te\u017eo.<\/p>\n

Prav tako razvijalci bolje poznajo svojo kodo kot kateri koli varnostnik. \u010cloveku, ki ima vsaj 5 projektov v orodju za stati\u010dno analizo, je obi\u010dajno te\u017eko zapomniti vse podrobnosti. Security Champions poznajo svoj izdelek: kaj kjer sodeluje in na kaj se osredoto\u010diti najprej - so u\u010dinkovitej\u0161i.<\/p>\n

Zato razmislite o uvedbi Security Champions in raz\u0161iritvi vpliva varnostne ekipe. Za samega prvaka je to prav tako koristno: strokovni razvoj na novem podro\u010dju, \u0161iritev tehni\u010dnega obzorja, izbolj\u0161anje tehni\u010dnih, upravljalskih in vodstvenih sposobnosti, pove\u010danje tr\u017ene vrednosti. To je nekak\u0161na oblika socialne in\u017eeniringa, va\u0161e 'o\u010desi' v razvojni ekip.<\/p>\n

Faze testiranja<\/h2>\n

\nParadigma 20 na 80<\/a><\/noindex>\u00a0pravi, da 20% truda prina\u0161a 80% rezultata. Ta 20% so prakse analize aplikacij, ki jih lahko in jih je treba avtomatizirati. Primeri tak\u0161nih aktivnosti so stati\u010dna analiza - SAST<\/b>, dinami\u010dna analiza - DAST,<\/b> in\u00a0nadzor odprtokodnega<\/b>. Povedal vam bom ve\u010d o aktivnostih, ter orodjih, s katerimi se obi\u010dajno sre\u010dujemo pri njihovi uvedbi v proces, in kako to izvesti pravilno.<\/p>\n

\"Strah
\n<\/p>\n

Glavne te\u017eave z orodji<\/h3>\n

\nOzna\u010dil bom aktualne te\u017eave, ki se pojavljajo pri vseh orodjih in zahtevajo pozornost. Razdelil jih bom podrobneje, da se ne ponavljam.<\/p>\n

Dolgo trajanje analize. <\/b>\u010ce od commita do proizvodnje mine 30 minut za vse teste in zbiranje, bodo preverjanja informacijske varnosti trajala en dan. Nih\u010de ne bo zaviral procesa. Upo\u0161tevajte to posebnost in delajte sklepe.<\/p>\n

Visoka raven False Negative ali False Positive. <\/b>Vsi izdelki so razli\u010dni, vsi uporabljajo razli\u010dne ogrodja in svoj slog pisanja kode. Na razli\u010dni kodni osnovi in tehnologijah lahko orodja prika\u017eejo razli\u010dno raven False Negative in False Positive. Zato glejte, kaj to\u010dno v\u00a0va\u0161i<\/b> podjetju in za va\u0161e<\/b> aplikacije bo prikazalo dobre in zanesljive rezultate.<\/p>\n

Ni integracij z obstoje\u010dimi orodji<\/b>. Oglejte si orodja z vidika integracij, s tistim, kar \u017ee uporabljate. Na primer, \u010de imate Jenkins ali TeamCity - preverite integracijo orodij ravno s tem programom, in ne z GitLab CI, ki ga ne uporabljate.<\/p>\n

Pomanjkanje ali prekomerna zapletenost prilagoditev. <\/b>\u010ce 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\u017enost prilagajanja preverjanj.<\/p>\n

Ni Roadmap razvoja produkta. <\/b>Razvoj ne stoji na mestu, vedno uporabljamo nove ogrodja in funkcije, staro kodo prepisujemo v nove jezike. \u017delimo biti prepri\u010dani, da bo orodje, ki ga kupimo, podpiralo nove ogrodja in tehnologije. Zato je pomembno vedeti, da ima izdelek realen in pravilen Na\u010drt<\/a><\/noindex> razvoj.<\/p>\n

Posebnosti procesa<\/h3>\n

\nPoleg posebnosti orodij upo\u0161tevajte tudi posebnosti razvoja. Na primer, motenje razvoja je tipi\u010dna napaka. Poglejmo, katere druge posebnosti je treba upo\u0161tevati in na kaj mora ekipa za varnost dati pozornost.<\/p>\n

Da ne bi zamudili rokov razvoja in izdaje, ustvarite razli\u010dna pravila<\/b> in razli\u010dne show stoppers\u00a0<\/b>\u2014 kriteriji za zaustavitev procesa zbiranja v primeru ranljivosti \u2014 za razli\u010dna okolja.<\/b>Na primer, razumemo, da trenutna veja gre na razvojno stojalo ali UAT, zato ne ustavljamo in ne re\u010demo:<\/p>\n

\u2014 Imate tukaj ranljivosti, ne boste \u0161li naprej!<\/i><\/p>\n

Na tej to\u010dki je pomembno, da razvijalcem poveste, da so prisotne varnostne te\u017eave, na katere je treba opozoriti.<\/p>\n

Prisotnost ranljivosti ni ovira za nadaljnje testiranje.<\/b>: ro\u010dnega, integracijskega ali manualnega. Po drugi strani pa moramo na nek na\u010din izbolj\u0161ati varnost izdelka, da razvijalci ne pozabijo na to, kar ugotovi varnost. Zato v\u010dasih ravnamo tako: na testnem okolju, ko se izda nova razli\u010dica, preprosto obvestimo razvojno skupino:<\/p>\n

\u2014 Fantje, imate te\u017eave, prosimo, posvetite jim pozornost.<\/i><\/p>\n

V fazi UAT ponovno prikazujemo opozorila o ranljivostih, medtem ko v fazi prehoda na produkcijo povemo:<\/p>\n

\u2014 Fantje, ve\u010dkrat smo vas opozorili, niste storili ni\u010desar \u2013 s tem vas ne bomo pustili ven.<\/i><\/p>\n

\u010ce 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. \u010ce je razvijalec premaknil gumb za 3 piksle in mu povemo, da ima tam SQL injekcijo in da jo mora nujno popraviti \u2013 to ni pravilno. Poglejte le na to, kar je zdaj napisano, in na spremembo, ki prihaja v aplikacijo.<\/p>\n

Recimo, da imamo nek funkcionalni defect \u2013 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\u017ei. Varnostni defekti<\/b>\u00a0so enaki defektom, vendar ne v kontekstu delovanja aplikacije, temve\u010d varnosti. <\/p>\n

Niso vse te\u017eave kvalitete programske opreme te\u017eave z varnostjo. Vendar so vse varnostne te\u017eave povezane s kakovostjo programske opreme. Sherif Mansour, Expedia.<\/p><\/blockquote>\n

\nKer so vse ranljivosti enaki defekti, morajo biti na istem mestu kot vsi defekti razvoja. Zato pozabite na poro\u010dila in stra\u0161ne PDF dokumente, ki jih nih\u010de ne bere.<\/p>\n

\"Strah
\n
\nKo sem delal v podjetju, ki se ukvarja z razvojem, sem prejel poro\u010dilo iz orodij za stati\u010dno analizo. Odprl sem ga, se \u0161okiral, skuhal kavo, prelistal 350 strani, zaprl in \u0161el naprej delati. Velika poro\u010dila so mrtva poro\u010dila<\/b>. Obi\u010dajno nikamor ne gredo, e-po\u0161ta se izbri\u0161e, pozabi, izgubi ali pa poslovanje pravi, da prevzema tveganja.<\/p>\n

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.<\/p>\n

Statisti\u010dna analiza - SAST<\/h2>\n

\nTo je analiza kode za prisotnost ranljivosti<\/b>, vendar to ni isto kot SonarQube. Preverjamo ne le po vzorcih ali slogu. Pri analizi se uporablja vrsta pristopov: po drevesu ranljivosti, po\u00a0DataFlow<\/a><\/noindex>, po analizi konfiguracijskih datotek. To je vse, kar se nana\u0161a neposredno na kodo.<\/p>\n

Prednosti pristopa<\/b>: odkrivanje ranljivosti v kodi v zgodnji fazi razvoja<\/b>, ko \u0161e ni postavljenih okolij in kon\u010dnih orodij, ter\u00a0mo\u017enost inkrementalnega skeniranja<\/b>: skeniranje dela kode, ki se je spremenilo, in samo funkcije, ki jo trenutno razvijamo, kar zmanj\u0161uje \u010das skeniranja.<\/p>\n

\u041d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u043a\u0438<\/b>\u00a0\u2014 to je odsotnost podpore potrebnim jeziku.<\/p>\n

Potrebne integracije, <\/b>ki bi morale biti v orodjih, po mojem subjektivnem mnenju:<\/p>\n