Bailes un riebums no DevSecOps

Mums bija 2 kodu analizatori, 4 dinamiskās testÄ“Å”anas rÄ«ki, mÅ«su paÅ”u amatniecÄ«ba un 250 skripti. Nav tā, ka tas viss ir vajadzÄ«gs paÅ”reizējā procesā, taču, tiklÄ«dz sākat ieviest DevSecOps, jums ir jāiet lÄ«dz beigām.

Bailes un riebums no DevSecOps

Avots. Varoņu veidotāji: Džastins Roilends un Dens Harmons.

Kas ir SecDevOps? Kā ar DevSecOps? Kādas ir atŔķirÄ«bas? Lietojumprogrammu droŔība ā€” par ko tā ir? Kāpēc klasiskā pieeja vairs nedarbojas? Zina atbildes uz visiem Å”iem jautājumiem Jurijs Å abaļins no Zobenzivs droŔība. Jurijs atbildēs uz visu detalizēti un analizēs pārejas problēmas no klasiskā Application Security modeļa uz DevSecOps procesu: kā pareizi pieiet droÅ”as izstrādes procesa integrācijai DevOps procesā un neko nesalauzt, kā iziet cauri galvenajiem posmiem. droŔības pārbaudes, kādus rÄ«kus var izmantot un ar ko tie atŔķiras un kā tos pareizi konfigurēt, lai izvairÄ«tos no kļūmēm.


Par runātāju: Jurijs Å abaļins - Uzņēmuma galvenais apsardzes arhitekts Zobenzivs droŔība. AtbildÄ«gs par SSDL ievieÅ”anu, par lietojumprogrammu analÄ«zes rÄ«ku vispārēju integrāciju vienotā izstrādes un testÄ“Å”anas ekosistēmā. 7 gadu pieredze informācijas droŔības jomā. Strādājis Alfa-Bank, Sberbank un Positive Technologies, kas izstrādā programmatÅ«ru un sniedz pakalpojumus. Runātājs starptautiskajās konferencēs ZerONights, PHDays, RISSPA, OWASP.

Lietojumprogrammu droŔība: par ko tā ir?

Lietojumprogrammu droŔība - Å Ä« ir droŔības sadaļa, kas ir atbildÄ«ga par lietojumprogrammu droŔību. Tas neattiecas uz infrastruktÅ«ru vai tÄ«kla droŔību, bet gan uz to, ko mēs rakstām un pie kā strādā izstrādātāji ā€“ tie ir paÅ”as lietojumprogrammas trÅ«kumi un ievainojamÄ«bas.

Virziens SDL vai SDLC Sākot no DroŔības izstrādes dzÄ«ves cikls - izstrādājis Microsoft. Diagrammā parādÄ«ts kanoniskais SDLC modelis, kura galvenais uzdevums ir droŔības lÄ«dzdalÄ«ba katrā izstrādes posmā no prasÄ«bām lÄ«dz izlaiÅ”anai un ražoÅ”anai. Microsoft saprata, ka nozarē ir pārāk daudz kļūdu, to ir vairāk un ar to kaut kas ir jādara, un viņi ierosināja Å”o pieeju, kas ir kļuvusi par kanonisku.

Bailes un riebums no DevSecOps

Lietojumprogrammu droŔības un SSDL mērÄ·is nav atklāt ievainojamÄ«bas, kā parasti tiek uzskatÄ«ts, bet gan novērst to raÅ”anos. Laika gaitā Microsoft kanoniskā pieeja ir uzlabota, attÄ«stÄ«ta un ieviesta dziļākā, detalizētākā nirÅ”anā.

Bailes un riebums no DevSecOps

Kanoniskais SDLC ir ļoti detalizēts dažādās metodoloģijās - OpenSAMM, BSIMM, OWASP. Metodoloģijas ir dažādas, bet kopumā līdzīgas.

Ēkas droŔības modelis brieduma periodā

Man tas visvairāk patÄ«k BSIMM Sākot no Ēkas droŔības modelis brieduma periodā. MetodoloÄ£ijas pamatā ir Lietojumprogrammu droŔības procesa sadalÄ«Å”ana 4 jomās: pārvaldÄ«ba, izlÅ«koÅ”ana, SSDL saskares punkti un izvietoÅ”ana. Katrā domēnā ir 12 prakses, kas ir attēlotas kā 112 aktivitātes.

Bailes un riebums no DevSecOps

Katrai no 112 aktivitātēm ir 3 brieduma lÄ«meņi: iesācējs, vidējs un progresÄ«vs. JÅ«s varat izpētÄ«t visas 12 prakses sadaļas pēc sadaļas, atlasÄ«t sev svarÄ«gas lietas, izdomāt, kā tās ieviest un pakāpeniski pievienot elementus, piemēram, statisko un dinamisko koda analÄ«zi vai koda pārskatÄ«Å”anu. JÅ«s pierakstāt plānu un mierÄ«gi strādājat saskaņā ar to kā daļu no izvēlēto aktivitāŔu Ä«stenoÅ”anas.

Kāpēc DevSecOps

DevOps ir vispārējs, liels process, kurā ir jāņem vērā droŔība.

Sākotnēji DevOps iesaistÄ«tas droŔības pārbaudes. Praksē apsardzes komandu skaits bija daudz mazāks nekā Å”obrÄ«d, un tās darbojās nevis kā procesa dalÄ«bnieki, bet gan kā kontroles un uzraudzÄ«bas institÅ«cija, kas tai uzliek prasÄ«bas un izlaiduma beigās pārbauda produkta kvalitāti. Å Ä« ir klasiska pieeja, kurā droŔības komandas stāvēja aiz sienas no izstrādes un nepiedalÄ«jās procesā.

Bailes un riebums no DevSecOps

Galvenā problēma ir tā, ka informācijas droŔība ir noŔķirta no attÄ«stÄ«bas. Parasti Ŕī ir sava veida informācijas droŔības shēma, un tajā ir 2-3 lieli un dārgi rÄ«ki. Reizi seÅ”os mēneÅ”os pienāk pirmkods vai lietojumprogramma, kas ir jāpārbauda, ā€‹ā€‹un reizi gadā tie tiek ražoti pentesti. Tas viss noved pie tā, ka nozares izlaiÅ”anas datums tiek aizkavēts, un izstrādātājs ir pakļauts milzÄ«gam skaitam automatizētu rÄ«ku ievainojamÄ«bu. To visu izjaukt un salabot nav iespējams, jo iepriekŔējā pusgada rezultāti nebija sakārtoti, bet te ir jauna partija.

MÅ«su uzņēmuma darba gaitā mēs redzam, ka droŔība visās jomās un nozarēs saprot, ka ir laiks panākt un griezties ar attÄ«stÄ«bu uz viena riteņa veikls. DevSecOps paradigma lieliski atbilst veiklajai izstrādes metodoloÄ£ijai, ievieÅ”anai, atbalstam un dalÄ«bai katrā laidienā un iterācijā.

Bailes un riebums no DevSecOps

Pāreja uz DevSecOps

Vissvarīgākais vārds droŔības attīstības dzīves ciklā ir "process". Tas ir jāsaprot, pirms domājat par rīku iegādi.

Nepietiek tikai ar rÄ«ku iekļauÅ”anu DevOps procesā ā€” svarÄ«ga ir komunikācija un sapratne starp procesa dalÄ«bniekiem.

Cilvēki ir svarīgāki, nevis instrumenti.

Bieži vien droÅ”a izstrādes procesa plānoÅ”ana sākas ar rÄ«ka izvēli un iegādi un beidzas ar mēģinājumiem integrēt rÄ«ku paÅ”reizējā procesā, kas paliek mēģinājumi. Tas noved pie neveiksmÄ«gām sekām, jo ā€‹ā€‹visiem instrumentiem ir savas Ä«paŔības un ierobežojumi.

IzplatÄ«ts gadÄ«jums ir, kad droŔības nodaļa izvēlējās labu, dārgu rÄ«ku ar plaŔām iespējām un nāca pie izstrādātājiem, lai to integrētu procesā. Bet tas neizdodas - process ir strukturēts tā, ka jau iegādātā rÄ«ka ierobežojumi neietilpst paÅ”reizējā paradigmā.

Vispirms aprakstiet, kādu rezultātu vēlaties un kā process izskatÄ«sies. Tas palÄ«dzēs izprast instrumenta un droŔības lomu procesā.

Sāciet ar to, kas jau tiek izmantots

Pirms dārgu instrumentu iegādes apskatiet, kas jums jau ir. Katram uzņēmumam ir izstrādātas droŔības prasÄ«bas attÄ«stÄ«bai, ir čeki, pentesti - kāpēc gan to visu nepārveidot ikvienam saprotamā un ērtā formā?

Parasti prasÄ«bas ir papÄ«ra Talmuds, kas atrodas plauktā. Bija gadÄ«jums, kad atnācām uz kādu uzņēmumu apskatÄ«t procesus un lÅ«dzām apskatÄ«t programmatÅ«ras droŔības prasÄ«bas. Speciālists, kurÅ” ar to nodarbojās, ilgu laiku meklēja:

- Tagad kaut kur piezÄ«mēs bija ceļŔ, kur atrodas Å”is dokuments.

Rezultātā dokumentu saņēmām nedēļu vēlāk.

PrasÄ«bām, čekiem un citām lietām izveido lapu piem. SaplÅ«Å”ana - tas ir ērti ikvienam.

Ir vieglāk pārformatēt to, kas jums jau ir, un izmantot to, lai sāktu.

Izmantojiet droŔības čempionus

Parasti vidējā uzņēmumā ar 100-200 izstrādātājiem ir viens droŔības speciālists, kurÅ” veic vairākas funkcijas un fiziski nav laika visu pārbaudÄ«t. Pat ja viņŔ cenÅ”as visu iespējamo, viņŔ viens pats nepārbaudÄ«s visu izstrādes radÄ«to kodu. Šādiem gadÄ«jumiem ir izstrādāta koncepcija - DroŔības čempioni.

DroŔības čempioni ir izstrādātāju komandas cilvēki, kurus interesē jÅ«su produkta droŔība.

Bailes un riebums no DevSecOps

DroŔības čempions ir ieejas punkts izstrādes komandā un droŔības evaņģēlists.

Parasti, kad droŔības speciālists ierodas izstrādes komandā un norāda uz kļūdu kodā, viņŔ saņem pārsteigtu atbildi:

- Un kas esi tu? Es tevi redzu pirmo reizi. Ar mani viss ir kārtÄ«bā - vecākais draugs man iedeva ā€œpieteiktiesā€ koda pārskatÄ«Å”anā, mēs virzāmies tālāk!

Tā ir tipiska situācija, jo daudz vairāk uzticas senioriem vai vienkārÅ”i komandas biedriem, ar kuriem izstrādātājs nemitÄ«gi sazinās darbā un koda pārskatÄ«Å”anā. Ja apsardzes virsnieka vietā uz kļūdu un sekām norādÄ«s DroŔības čempions, tad viņa vārdam bÅ«s lielāks svars.

Turklāt izstrādātāji zina savu kodu labāk nekā jebkurÅ” droŔības speciālists. Personai, kurai statiskās analÄ«zes rÄ«kā ir vismaz 5 projekti, parasti ir grÅ«ti atcerēties visas nianses. DroŔības čempioni zina savu produktu: kas ar ko mijiedarbojas un uz ko vispirms jāskatās ā€“ tie ir efektÄ«vāki.

Tāpēc apsveriet iespēju ieviest droŔības čempionus un paplaÅ”ināt savas droŔības komandas ietekmi. Tas noder arÄ« paÅ”am čempionam: profesionālā izaugsme jaunā jomā, tehniskā redzesloka paplaÅ”ināŔana, tehnisko, vadÄ«bas un lÄ«dera iemaņu celÅ”ana, tirgus vērtÄ«bas palielināŔana. Tas ir sociālās inženierijas elements, jÅ«su ā€œacisā€ izstrādes komandā.

Pārbaudes posmi

Paradigma no 20 lÄ«dz 80 saka, ka 20% pūļu dod 80% rezultātu. Å ie 20% ir lietojumprogrammu analÄ«zes prakse, ko var un vajadzētu automatizēt. Šādu darbÄ«bu piemēri ir statiskā analÄ«ze - SAST, dinamiskā analÄ«ze - DAST Šø Atvērtā pirmkoda vadÄ«ba. SÄ«kāk pastāstÄ«Å”u par aktivitātēm, kā arÄ« par rÄ«kiem, ar kādām funkcijām parasti sastopamies, tos ievieÅ”ot procesā, un kā to pareizi darÄ«t.

Bailes un riebums no DevSecOps

Galvenās instrumentu problēmas

Es izcelÅ”u problēmas, kas attiecas uz visiem instrumentiem un kurām jāpievērÅ” uzmanÄ«ba. Es tos analizÄ“Å”u sÄ«kāk, lai turpmāk neatkārtotos.

Ilgs analÄ«zes laiks. Ja no apņemÅ”anās lÄ«dz izlaiÅ”anai visas pārbaudes un montāža aizņem 30 minÅ«tes, tad informācijas droŔības pārbaudes prasÄ«s vienu dienu. Tātad neviens procesu nepalēninās. Ņemiet vērā Å”o funkciju un izdariet secinājumus.

Augsts lÄ«menis viltus negatÄ«vs vai viltus pozitÄ«vs. Visi produkti ir atŔķirÄ«gi, visi izmanto dažādus ietvarus un savu kodÄ“Å”anas stilu. Dažādās kodu bāzēs un tehnoloÄ£ijās rÄ«ki var parādÄ«t dažādus viltus negatÄ«vu un viltus pozitÄ«vo vērtÄ«bu lÄ«meņus. Tātad, paskatieties, kas Ä«sti ir iekŔā jÅ«su uzņēmumiem un par jÅ«su lietojumprogrammas parādÄ«s labus un uzticamus rezultātus.

Nav integrācijas ar esoÅ”ajiem rÄ«kiem. Apskatiet rÄ«kus saistÄ«bā ar integrāciju ar to, ko jau izmantojat. Piemēram, ja jums ir Jenkins vai TeamCity, pārbaudiet rÄ«ku integrāciju ar Å”o programmatÅ«ru, nevis ar GitLab CI, kuru neizmantojat.

PielāgoÅ”anas trÅ«kums vai pārmērÄ«ga sarežģītÄ«ba. Ja rÄ«kam nav API, tad kāpēc tas ir vajadzÄ«gs? Visam, ko var paveikt saskarnē, jābÅ«t pieejamam, izmantojot API. Ideālā gadÄ«jumā rÄ«kam vajadzētu bÅ«t iespējai pielāgot pārbaudes.

Nav produktu attīstības ceļveža. Attīstība nestāv uz vietas, mēs vienmēr izmantojam jaunus ietvarus un funkcijas, pārrakstot veco kodu jaunās valodās. Mēs vēlamies būt pārliecināti, ka mūsu iegādātais rīks atbalstīs jaunas sistēmas un tehnoloģijas. Tāpēc ir svarīgi zināt, ka precei ir īsta un pareiza Ceļvedis attīstību.

Procesa funkcijas

Papildus rÄ«ku iezÄ«mēm ņemiet vērā izstrādes procesa iezÄ«mes. Piemēram, attÄ«stÄ«bas kavÄ“Å”ana ir izplatÄ«ta kļūda. ApskatÄ«sim, kādas vēl funkcijas bÅ«tu jāņem vērā un kam jāpievērÅ” uzmanÄ«ba droŔības komandai.

Lai nepalaistu garām izstrādes un izlaiÅ”anas termiņus, izveidojiet dažādi noteikumi un dažādi parādÄ«t aizbāžņus ā€” kritēriji izveides procesa apturÄ“Å”anai ievainojamÄ«bu gadÄ«jumā, dažādām vidēm. Piemēram, mēs saprotam, ka paÅ”reizējā filiāle iet uz izstrādes stendu vai UAT, kas nozÄ«mē, ka mēs neapstājamies un nesakām:

"Tev ir ievainojamības, jūs nekur tālāk netiksit!"

Å ajā brÄ«dÄ« ir svarÄ«gi pastāstÄ«t izstrādātājiem, ka ir droŔības problēmas, kurām jāpievērÅ” uzmanÄ«ba.

IevainojamÄ«bu klātbÅ«tne nav Ŕķērslis turpmākai pārbaudei: manuāla, integrācija vai manuāla. No otras puses, mums ir kaut kā jāpaaugstina produkta droŔība un lai izstrādātāji nepamestu novārtā to, ko viņi uzskata par droÅ”u. Tāpēc dažreiz mēs darām tā: stendā, kad tas tiek izrullēts izstrādes vidē, mēs vienkārÅ”i paziņojam izstrādei:

- PuiÅ”i, jums ir problēmas, lÅ«dzu, pievērsiet tām uzmanÄ«bu.

UAT posmā mēs atkal rādām brÄ«dinājumus par ievainojamÄ«bām, un izlaiÅ”anas stadijā mēs sakām:

- PuiÅ”i, mēs jÅ«s vairākas reizes brÄ«dinājām, jÅ«s neko nedarÄ«jāt - mēs jÅ«s ar to neizlaidÄ«sim.

Ja mēs runājam par kodu un dinamiku, tad ir jāparāda un jābrÄ«dina par ievainojamÄ«bām tikai tām funkcijām un kodam, kas tikko tika ierakstÄ«ts Å”ajā funkcijā. Ja izstrādātājs pabÄ«da pogu par 3 pikseļiem un mēs viņam sakām, ka viņam tur ir SQL injekcija un tāpēc tas ir steidzami jālabo, tas ir nepareizi. Paskatieties tikai uz to, kas tagad ir rakstÄ«ts, un uz izmaiņām, kas nāk aplikācijā.

Pieņemsim, ka mums ir zināms funkcionāls defekts ā€“ tas, kā aplikācijai nevajadzētu darboties: nauda netiek pārskaitÄ«ta, nospiežot uz pogas nenotiek pāreja uz nākamo lapu vai arÄ« prece netiek ielādēta. DroŔības defekti - tie ir tie paÅ”i defekti, bet ne lietojumprogrammas darbÄ«bas, bet droŔības ziņā.

Ne visas programmatÅ«ras kvalitātes problēmas ir droŔības problēmas. Bet visas droŔības problēmas ir saistÄ«tas ar programmatÅ«ras kvalitāti. Å erifs Mansurs, Expedia.

Tā kā visas ievainojamÄ«bas ir vieni un tie paÅ”i defekti, tām jāatrodas tajā paŔā vietā, kur visi attÄ«stÄ«bas defekti. Tāpēc aizmirstiet par ziņojumiem un biedējoÅ”iem PDF failiem, kurus neviens nelasa.

Bailes un riebums no DevSecOps

Kad es strādāju izstrādes uzņēmumā, es saņēmu ziņojumu no statiskās analÄ«zes rÄ«kiem. Atvēru, Å”ausminājos, uztaisÄ«ju kafiju, pārlapoju 350 lappuses, aizvēru un turpināju strādāt. Lielie ziņojumi ir miruÅ”i ziņojumi. Parasti viņi nekur nenonāk, vēstules tiek izdzēstas, aizmirstas, pazaudētas vai uzņēmums saka, ka uzņemas risku.

Ko darÄ«t? Mēs vienkārÅ”i pārveidojam apstiprinātos defektus, ko atradām, izstrādei ērtā formā, piemēram, ievietojam tos Jira atlikumā. Mēs pieŔķiram prioritāti defektiem un novērÅ”am tos prioritārā secÄ«bā, kā arÄ« funkcionālos defektus un pārbaudes defektus.

Statiskā analÄ«ze ā€” SAST

Å Ä« ir ievainojamÄ«bu koda analÄ«ze., taču tas nav tas pats, kas SonarQube. Mēs ne tikai pārbaudām modeļus vai stilu. AnalÄ«zē tiek izmantotas vairākas pieejas: saskaņā ar ievainojamÄ«bas koku, saskaņā ar Datu plÅ«sma, analizējot konfigurācijas failus. Tas ir viss, kas attiecas uz paÅ”u kodu.

Pieejas plusi: koda ievainojamÄ«bu identificÄ“Å”ana agrÄ«nā izstrādes stadijākad vēl nav stendu vai gatavu instrumentu, un pakāpeniska skenÄ“Å”anas iespēja: tiek skenēta koda sadaļa, kas ir mainÄ«ta, un tikai tā funkcija, ko mēs paÅ”laik darām, kas samazina skenÄ“Å”anas laiku.

MÄ«nusi - tas ir atbalsta trÅ«kums nepiecieÅ”amajām valodām.

NepiecieÅ”amās integrācijas, kam, manuprāt, vajadzētu bÅ«t rÄ«kos:

  • Integrācijas rÄ«ks: Jenkins, TeamCity un Gitlab CI.
  • Izstrādes vide: Intellij IDEA, Visual Studio. Izstrādātājam ērtāk ir nevis orientēties pa nesaprotamu interfeisu, kas vēl jāiegaumē, bet gan redzēt visas nepiecieÅ”amās integrācijas un ievainojamÄ«bas, ko viņŔ ir atradis tieÅ”i darba vietā savā izstrādes vidē.
  • Koda pārskatÄ«Å”ana: SonarQube un manuāla pārskatÄ«Å”ana.
  • Defektu izsekotāji: Jira un Bugzilla.

Attēlā redzami daži no labākajiem statiskās analīzes pārstāvjiem.

Bailes un riebums no DevSecOps

Svarīgi ir nevis rīki, bet process, tāpēc ir atvērtā koda risinājumi, kas ir labi arī procesa pārbaudei.

Bailes un riebums no DevSecOps

SAST Open Source neatradÄ«s milzÄ«gu skaitu ievainojamÄ«bu vai sarežģītu DataFlow, taču tos var un vajadzētu izmantot, veidojot procesu. Tie palÄ«dz saprast, kā process tiks veidots, kurÅ” reaģēs uz kļūdām, kurÅ” ziņos un kurÅ” ziņos. Ja vēlaties veikt koda droŔības izveides sākotnējo posmu, izmantojiet atvērtā pirmkoda risinājumus.

Kā to var integrēt, ja atrodaties sava ceļojuma sākumā un jums nav nekā: ne CI, ne Dženkinsa, ne TeamCity? Apsvērsim integrāciju procesā.

CVS līmeņa integrācija

Ja jums ir Bitbucket vai GitLab, varat integrēties līmenī Vienlaicīgu versiju sistēma.

Pēc notikuma - izvilkt pieprasÄ«jumu, apņemties. JÅ«s skenējat kodu, un bÅ«vējuma statuss parāda, vai droŔības pārbaude ir izturēta vai neizdevusies.

Atsauksmes Protams, atgriezeniskā saite vienmēr ir nepiecieÅ”ama. Ja jÅ«s tikko veicāt apsardzi sānos, ievietojāt to kastē un nevienam neko par to nestāstÄ«jāt, un pēc tam mēneÅ”a beigās izmetāt virkni kļūdu - tas nav pareizi un nav labi.

Integrācija ar kodu pārskatÄ«Å”anas sistēmu

Kādreiz mēs darbojāmies kā tehniskā AppSec lietotāja noklusējuma pārskatÄ«tājs vairākos svarÄ«gos projektos. AtkarÄ«bā no tā, vai jaunajā kodā ir konstatētas kļūdas vai kļūdu nav, recenzents iestata izvilkÅ”anas pieprasÄ«juma statusu uz ā€œpieņemtā€ vai ā€œnepiecieÅ”ams darbsā€ - vai nu viss ir kārtÄ«bā, vai arÄ« saites uz to, kas tieÅ”i ir jāuzlabo. ir jāuzlabo. Integrācijai ar versiju, kas tiek nodota ražoÅ”anā, esam iespējojuÅ”i apvienoÅ”anas aizliegumu, ja informācijas droŔības pārbaude netiek izturēta. Mēs to iekļāvām manuālajā koda pārskatā, un citi procesa dalÄ«bnieki redzēja Ŕī konkrētā procesa droŔības statusus.

Integrācija ar SonarQube

Daudziem ir kvalitatÄ«vi vārti koda kvalitātes ziņā. Å eit ir tas pats ā€” jÅ«s varat izveidot tādus paÅ”us vārtus tikai SAST rÄ«kiem. BÅ«s tas pats interfeiss, tie paÅ”i kvalitātes vārti, tikai tie tiks izsaukti droŔības vārti. Un arÄ«, ja jums ir process, izmantojot SonarQube, varat tur viegli integrēt visu.

Integrācija CI līmenī

Šeit viss ir arī diezgan vienkārŔs:

  • LÄ«dzvērtÄ«gi autotestiem, vienÄ«bu testi.
  • SadalÄ«jums pa attÄ«stÄ«bas posmiem: izstrādātājs, tests, prod. Var tikt iekļauti dažādi noteikumu kopumi vai dažādi kļūmes apstākļi: apturiet montāžu, neapturiet montāžu.
  • Sinhronā/asinhronā palaiÅ”ana. Mēs gaidām droŔības testu beigas vai nē. Tas ir, mēs tos vienkārÅ”i palaidām un virzāmies tālāk, un tad mēs iegÅ«stam statusu, ka viss ir labi vai slikti.

Tas viss ir ideālā rozā pasaulē. Reālajā dzÄ«vē tāda nav, bet mēs cenÅ”amies. DroŔības pārbaužu rezultātiem jābÅ«t lÄ«dzÄ«giem vienÄ«bas pārbaužu rezultātiem.

Piemēram, mēs paņēmām lielu projektu un nolēmām, ka tagad skenēsim to ar SAST - OK. Mēs iespiedām Å”o projektu SAST, tas mums iedeva 20 000 ievainojamÄ«bu un ar stingru lēmumu nolēmām, ka viss ir kārtÄ«bā. 20 000 ievainojamÄ«bu ir mÅ«su tehniskais parāds. Mēs ieliksim parādu kastē, lēnām to notÄ«rÄ«sim un pievienosim kļūdas defektu izsekotājiem. Noalgosim firmu, darÄ«sim visu paÅ”i vai lai mums palÄ«dz droŔības čempioni ā€“ un tehniskie parādi samazināsies.

Un visas jaunās ievainojamÄ«bas jaunajā kodā ir jānovērÅ” tāpat kā kļūdas vienÄ«bā vai automātiskajos testos. RelatÄ«vi runājot, montāža sākās, mēs to paskrējām, divi testi un divi droŔības testi neizdevās. OK - gājām, paskatÄ«jāmies, kas noticis, salabojām vienu lietu, salabojām citu, palaistām nākamreiz - viss bija kārtÄ«bā, nekādas jaunas ievainojamÄ«bas neparādÄ«jās, neviens tests neizdevās. Ja Å”is uzdevums ir dziļāks un jums tas ir labi jāsaprot vai ievainojamÄ«bu novērÅ”ana ietekmē lielus zem pārsega esoŔās lietas slāņus: defektu izsekotājam tika pievienota kļūda, tā tiek noteikta par prioritāti un izlabota. Diemžēl pasaule nav ideāla, un testi dažreiz neizdodas.

DroŔības vārtu piemērs ir kvalitātes vārtu analogs, ņemot vērā koda ievainojamÄ«bu esamÄ«bu un skaitu.

Bailes un riebums no DevSecOpsMēs integrējamies ar SonarQube - spraudnis ir instalēts, viss ir ļoti ērti un forÅ”i.

Integrācija ar attīstības vidi

Integrācijas iespējas:

  • Pirms apstiprināŔanas tiek veikta skenÄ“Å”ana no izstrādes vides.
  • SkatÄ«t rezultātus.
  • Rezultātu analÄ«ze.
  • Sinhronizācija ar serveri.

Šādi izskatās rezultātu saņemÅ”ana no servera.

Bailes un riebums no DevSecOps

MÅ«su attÄ«stÄ«bas vidē Intellij IDEJA vienkārÅ”i parādās papildu vienums, kas informē, ka skenÄ“Å”anas laikā tika atklātas Ŕādas ievainojamÄ«bas. JÅ«s varat nekavējoties rediģēt kodu, apskatÄ«t ieteikumus un PlÅ«smas diagramma. Tas viss atrodas izstrādātāja darba vietā, kas ir ļoti ērti - nav jāseko citām saitēm un jāskatās kaut kas papildu.

Atvērtā koda

Šī ir mana mīļākā tēma. Visi izmanto atvērtā koda bibliotēkas - kāpēc rakstīt kruķu un velosipēdu baru, ja var paņemt gatavu bibliotēku, kurā viss jau ir ieviests?

Bailes un riebums no DevSecOps

Protams, tā ir taisnÄ«ba, taču arÄ« bibliotēkās raksta cilvēki, tajās ir arÄ« noteikti riski un ir arÄ« ievainojamÄ«bas, par kurām periodiski vai pastāvÄ«gi tiek ziņots. Tāpēc ir nākamais solis lietojumprogrammu droŔībā - tā ir atvērtā pirmkoda komponentu analÄ«ze.

Atvērtā pirmkoda analÄ«ze ā€” OSA

Rīks ietver trīs lielus posmus.

IevainojamÄ«bu meklÄ“Å”ana bibliotēkās. Piemēram, rÄ«ks zina, ka mēs izmantojam kādu bibliotēku, un tas atrodas CVE vai ir dažas kļūdu izsekotāju ievainojamÄ«bas, kas saistÄ«tas ar Å”o bibliotēkas versiju. Mēģinot to izmantot, rÄ«ks parādÄ«s brÄ«dinājumu, ka bibliotēka ir ievainojama, un iesaka izmantot citu versiju, kurai nav ievainojamÄ«bu.

Licences tÄ«rÄ«bas analÄ«ze. Pie mums tas vēl nav Ä«paÅ”i populārs, bet, ja strādā ārzemēs, tad tur ik pa laikam var dabÅ«t nodokli par kāda atvērtā koda komponenta izmantoÅ”anu, kuru nevar izmantot vai modificēt. Saskaņā ar licencētās bibliotēkas politiku mēs to nevaram darÄ«t. Vai arÄ«, ja mēs to modificējām un izmantojam, mums vajadzētu publicēt savu kodu. Protams, neviens nevēlas publicēt savu produktu kodu, taču jÅ«s varat arÄ« pasargāt sevi no tā.

RÅ«pnieciskā vidē izmantoto komponentu analÄ«ze. Iedomāsimies hipotētisku situāciju, ka beidzot esam pabeiguÅ”i izstrādi un izlaiduÅ”i mÅ«su mikropakalpojuma jaunāko versiju. ViņŔ tur brÄ«niŔķīgi dzÄ«vo ā€“ nedēļu, mēnesi, gadu. Mēs to nevācam, neveicam droŔības pārbaudes, Ŕķiet, ka viss ir kārtÄ«bā. Taču pēkŔņi, divas nedēļas pēc izlaiÅ”anas, atvērtā pirmkoda komponentā, ko mēs izmantojam Å”ajā konkrētajā bÅ«vniecÄ«bā, industriālajā vidē parādās kritiska ievainojamÄ«ba. Ja mēs nereÄ£istrēsim, ko un kur lietojam, mēs vienkārÅ”i neredzēsim Å”o ievainojamÄ«bu. Dažiem rÄ«kiem ir iespēja pārraudzÄ«t ievainojamÄ«bas bibliotēkās, kuras paÅ”laik tiek izmantotas Å”ajā nozarē. Tas ir ļoti noderÄ«gi.

Funkcijas:

  • Dažādas politikas dažādiem attÄ«stÄ«bas posmiem.
  • Komponentu uzraudzÄ«ba rÅ«pnieciskā vidē.
  • Bibliotēku kontrole organizācijā.
  • Atbalsts dažādām veidoÅ”anas sistēmām un valodām.
  • Docker attēlu analÄ«ze.

Daži nozares līderu piemēri, kuri nodarbojas ar atvērtā pirmkoda analīzi.

Bailes un riebums no DevSecOps
VienÄ«gais bezmaksas ir Å”is AtkarÄ«bas pārbaude no OWASP. Varat to ieslēgt pirmajos posmos, redzēt, kā tas darbojas un ko tas atbalsta. BÅ«tÄ«bā tie visi ir mākoņa produkti vai uz vietas, taču aiz to bāzes tie joprojām tiek nosÅ«tÄ«ti uz internetu. Viņi uz savu serveri sÅ«ta nevis jÅ«su bibliotēkas, bet gan jaucējvērtÄ«bas vai savas vērtÄ«bas, kuras viņi aprēķina, un pirkstu nospiedumus, lai saņemtu informāciju par ievainojamÄ«bu esamÄ«bu.

Procesu integrācija

Bibliotēku perimetra kontrole, kas tiek lejupielādēti no ārējiem avotiem. Mums ir ārējās un iekŔējās krātuves. Piemēram, Event Central darbojas Nexus, un mēs vēlamies nodroÅ”ināt, lai mÅ«su repozitorijā nebÅ«tu ievainojamÄ«bu ar statusu ā€œkritisksā€ vai ā€œaugstsā€. Varat konfigurēt starpniekserveri, izmantojot Nexus Firewall Lifecycle rÄ«ku, lai Ŕādas ievainojamÄ«bas tiktu novērstas un nenonāktu iekŔējā repozitorijā.

Integrācija CI. Vienā lÄ«menÄ« ar autotestiem, vienÄ«bu testiem un sadalÄ«Å”anu izstrādes posmos: dev, test, prod. Katrā posmā varat lejupielādēt jebkuru bibliotēku, izmantot jebko, taču, ja ir kaut kas grÅ«ts ar ā€œkritiskoā€ statusu, iespējams, ir vērts pievērst izstrādātāju uzmanÄ«bu tam jau ražoÅ”anas stadijā.

Integrācija ar artefaktiem: Nexus un JFrog.

Integrācija attÄ«stÄ«bas vidē. Izvēlētajiem rÄ«kiem jābÅ«t integrētiem ar izstrādes vidēm. Izstrādātājam ir jābÅ«t piekļuvei skenÄ“Å”anas rezultātiem no savas darba vietas vai iespējai paÅ”am skenēt un pārbaudÄ«t kodu, vai tajā nav ievainojamÄ«bu, pirms viņŔ pievienojas CVS.

CD integrācija. Å Ä« ir forÅ”a funkcija, kas man ļoti patÄ«k un par kuru jau runāju ā€“ jaunu ievainojamÄ«bu raÅ”anās uzraudzÄ«ba industriālā vidē. Tas darbojas apmēram Ŕādi.

Bailes un riebums no DevSecOps

Mums ir Publiskie komponentu krātuves ā€” daži rÄ«ki ārpusē un mÅ«su iekŔējais repozitorijs. Mēs vēlamies, lai tajā bÅ«tu tikai uzticami komponenti. Pieprasot starpniekserveri, mēs pārbaudām, vai lejupielādētajā bibliotēkā nav ievainojamÄ«bu. Ja uz to attiecas noteiktas politikas, kuras mēs iestatām un obligāti saskaņojam ar izstrādi, mēs to neaugÅ”upielādējam un mums tiek piedāvāts izmantot citu versiju. AttiecÄ«gi, ja bibliotēkā ir kaut kas patieŔām kritisks un slikts, tad izstrādātājs nesaņems bibliotēku instalÄ“Å”anas stadijā - lai viņŔ izmanto augstāku vai zemāku versiju.

  • BÅ«vējot pārbaudām, vai nevienam nav nekas slikts paslÄ«dējis, vai visas sastāvdaļas ir droÅ”as un zibatmiņā neviens nav ienesis neko bÄ«stamu.
  • Mums repozitorijā ir tikai uzticami komponenti.
  • Izvietojot, mēs vēlreiz pārbaudām paÅ”u pakotni: war, jar, DL vai Docker attēlu, lai pārliecinātos, ka tā atbilst politikai.
  • Ieejot nozarē, mēs sekojam lÄ«dzi, kas notiek industriālajā vidē: parādās vai neparādās kritiskās ievainojamÄ«bas.

Dinamiskā analÄ«ze ā€” DAST

Dinamiskās analÄ«zes rÄ«ki bÅ«tiski atŔķiras no visa iepriekÅ” minētā. Å Ä« ir sava veida imitācija lietotāja darbam ar lietojumprogrammu. Ja Ŕī ir tÄ«mekļa lietojumprogramma, mēs nosÅ«tām pieprasÄ«jumus, imitējot klienta darbu, noklikŔķiniet uz priekÅ”pusē esoÅ”ajām pogām, no veidlapas nosÅ«tām mākslÄ«gos datus: pēdiņas, iekavas, rakstzÄ«mes dažādos kodējumos, lai redzētu, kā programma darbojas un apstrādā. ārējie dati.

Tā pati sistēma ļauj pārbaudÄ«t atvērtā pirmkoda veidņu ievainojamÄ«bas. Tā kā DAST nezina, kuru atvērto avotu mēs izmantojam, tas vienkārÅ”i izmet "ļaunprātÄ«gus" modeļus un analizē servera atbildes:

- Jā, Å”eit ir deserializācijas problēma, bet ne Å”eit.

Å eit ir lieli riski, jo, veicot Å”o droŔības pārbaudi uz tā paÅ”a stenda, ar kuru strādā testētāji, var notikt nepatÄ«kamas lietas.

  • Liela slodze lietojumprogrammu serveru tÄ«klā.
  • Nav integrāciju.
  • Iespēja mainÄ«t analizētās lietojumprogrammas iestatÄ«jumus.
  • Nav atbalsta nepiecieÅ”amajām tehnoloÄ£ijām.
  • GrÅ«tÄ«bas ar iestatÄ«Å”anu.

Mums bija situācija, kad beidzot palaižām AppScan: mēs ilgu laiku mēģinājām piekļūt lietojumprogrammai, ieguvām 3 kontus un bijām laimÄ«gi - beidzot visu pārbaudÄ«sim! Mēs sākām skenÄ“Å”anu, un pirmā lieta, ko AppScan izdarÄ«ja, bija ieiet administratora panelÄ«, caurdurt visas pogas, nomainÄ«t pusi datu un pēc tam pilnÄ«bā iznÄ«cināt serveri ar pasta veidlapa- lÅ«gumi. Izstrāde ar testÄ“Å”anu teica:

- PuiÅ”i, jÅ«s jokojat?! Mēs sniedzām jums kontus, un jÅ«s izveidojāt stendu!

Apsveriet iespējamos riskus. Ideālā gadÄ«jumā sagatavojiet atseviŔķu stendu informācijas droŔības testÄ“Å”anai, kas vismaz kaut kā tiks izolēts no pārējās vides un nosacÄ«ti pārbaudiet admin paneli, vēlams manuālā režīmā. Å is ir pentests ā€” tie atlikuÅ”ie piepÅ«les procenti, kurus mēs Å”obrÄ«d neņemam vērā.

Ir vērts uzskatīt, ka varat to izmantot kā slodzes pārbaudes analogu. Pirmajā posmā jūs varat ieslēgt dinamisku skeneri ar 10-15 pavedieniem un redzēt, kas notiek, bet parasti, kā liecina prakse, nekas labs.

Daži resursi, ko mēs parasti izmantojam.

Bailes un riebums no DevSecOps

IzcelÅ”anas vērts Burp Suite ir ā€œÅ veices nazisā€ jebkuram droŔības speciālistam. Visi to izmanto, un tas ir ļoti ērti. Tagad ir izlaista jauna uzņēmuma izdevuma demonstrācijas versija. Ja agrāk tā bija tikai atseviŔķa utilÄ«ta ar spraudņiem, tad tagad izstrādātāji beidzot izgatavo lielu serveri, no kura bÅ«s iespējams pārvaldÄ«t vairākus aÄ£entus. Tas ir forÅ”i, iesaku izmēģināt.

Procesu integrācija

Integrācija notiek diezgan labi un vienkārÅ”i: pēc veiksmÄ«gas instalÄ“Å”anas sāciet skenÄ“Å”anu pieteikumi stendam un skenÄ“Å”ana pēc veiksmÄ«gas integrācijas pārbaudes.

Ja integrācijas nedarbojas vai ir nepilnÄ«bas un izspēles funkcijas, tas ir bezjēdzÄ«gi un bezjēdzÄ«gi ā€” neatkarÄ«gi no tā, kādu modeli mēs nosÅ«tām, serveris joprojām atbildēs tāpat.

  • Ideālā gadÄ«jumā atseviŔķs testÄ“Å”anas stends.
  • Pirms pārbaudes pierakstiet pieteikÅ”anās secÄ«bu.
  • AdministrÄ“Å”anas sistēmas testÄ“Å”ana ir tikai manuāla.

process

Nedaudz vispārināts par procesu kopumā un par katra instrumenta darbÄ«bu konkrēti. Visas lietojumprogrammas ir atŔķirÄ«gas - viena labāk darbojas ar dinamisko analÄ«zi, cita ar statisko analÄ«zi, treŔā ar OpenSource analÄ«zi, pentestiem vai kaut kas cits, piemēram, notikumi ar Waf.

Katram procesam ir nepiecieŔama kontrole.

Lai saprastu, kā process darbojas un kur to var uzlabot, jums ir jāapkopo metrika no visa, kas jums ir pieejams, tostarp ražoŔanas metrika, metrika no rīkiem un defektu izsekotājiem.

Jebkura informācija ir noderīga. Ir jāskatās no dažādiem leņķiem, kur tas vai cits instruments ir labāk lietojams, kur process specifiski nokrīt. Iespējams, ir vērts aplūkot izstrādes reakcijas laikus, lai noskaidrotu, kur uzlabot procesu, pamatojoties uz laiku. Jo vairāk datu, jo vairāk sadaļu var izveidot no augstākā līmeņa līdz katra procesa detaļām.

Bailes un riebums no DevSecOps

Tā kā visiem statiskajiem un dinamiskajiem analizatoriem ir savi API, savas palaiÅ”anas metodes, principi, dažiem ir plānotāji, citiem nav - mēs rakstām rÄ«ku AppSec Orchestrator, kas ļauj no produkta izveidot vienotu ieejas punktu visā procesā un pārvaldÄ«t to no viena punkta.

VadÄ«tājiem, izstrādātājiem un droŔības inženieriem ir viens ieejas punkts, no kura viņi var redzēt, kas darbojas, konfigurēt un palaist skenÄ“Å”anu, saņemt skenÄ“Å”anas rezultātus un iesniegt prasÄ«bas. Mēs cenÅ”amies attālināties no dokumentu kārtoÅ”anas, visu pārvērst cilvēciskā, ko izmanto izstrāde - lapas par Confluence ar statusu un metriku, Jira vai dažādu defektu izsekotāju defektiem vai integrāciju sinhronā/asinhronā procesā CI. /CD.

Atslēgas

Instrumenti nav galvenais. Vispirms pārdomājiet procesu - pēc tam ieviesiet rÄ«kus. RÄ«ki ir labi, bet dārgi, tāpēc varat sākt ar procesu un veidot saziņu un izpratni starp attÄ«stÄ«bu un droŔību. No droŔības viedokļa nevajag visu ā€œapturētā€.No attÄ«stÄ«bas viedokļa, ja ir kaut kas augsts mega superkritisks, tad tas ir jālikvidē, nevis jāver acis uz problēmu.

Produkta kvalitāte - kopÄ«gs mērÄ·is gan droŔībai, gan attÄ«stÄ«bai. Mēs darām vienu lietu, cenÅ”amies nodroÅ”ināt, lai viss darbotos pareizi un nerastos reputācijas riski vai finansiāli zaudējumi. Tāpēc mēs reklamējam DevSecOps, SecDevOps pieeju, lai uzlabotu saziņu un uzlabotu produkta kvalitāti.

Sāciet ar to, kas jums jau ir: prasÄ«bas, arhitektÅ«ra, daļējas pārbaudes, apmācÄ«bas, vadlÄ«nijas. Nav nepiecieÅ”ams nekavējoties piemērot visas prakses visiem projektiem - pārvietoties iteratÄ«vi. Nav vienota standarta - eksperiments un izmēģiniet dažādas pieejas un risinājumus.

Starp informācijas droŔības defektiem un funkcionāliem defektiem ir vienādības zīme.

Automatizējiet visukas kustas. Viss, kas nepārvietojas, pārvietojiet to un automatizējiet. Ja kaut kas tiek darīts ar rokām, tas nav laba procesa daļa. Varbūt ir vērts to pārskatīt un arī automatizēt.

Ja IS komandas lielums ir mazs - izmantojiet droŔības čempionus.

VarbÅ«t tas, par ko es runāju, jums nederēs, un jÅ«s izdomāsit kaut ko savu - un tas ir labi. Bet izvēlieties rÄ«kus, pamatojoties uz jÅ«su procesa prasÄ«bām. Neskatieties, ko saka sabiedrÄ«ba, ka Å”is rÄ«ks ir slikts un Å”is ir labs. Iespējams, jÅ«su produktam bÅ«s pretējais.

Prasības instrumentiem.

  • Zems lÄ«menis Viltus pozitÄ«vs.
  • PienācÄ«gs analÄ«zes laiks.
  • LietoÅ”anas vienkārŔība.
  • Integrāciju pieejamÄ«ba.
  • Izpratne par produktu attÄ«stÄ«bas ceļvedi.
  • Iespēja pielāgot rÄ«kus.

Jurija ziņojums tika izvēlēts kā viens no labākajiem DevOpsConf 2018. Lai iepazÄ«tos ar vēl interesantākām idejām un praktiskiem gadÄ«jumiem, nāc uz Skolkovo 27. un 28. maijā. DevOpsConf ietvaros festivāls RIT++. Vēl labāk, ja esat gatavs dalÄ«ties savā pieredzē, tad pieteikties atskaitei lÄ«dz 21.aprÄ«lim.

Avots: www.habr.com

Pievieno komentāru