Mums bija 2 kodu analītāji, 4 rīki dinamiskai testēšanai, mūsu izstrādājumi un 250 skriptu. Tas nav tas, ka viss tas bija nepieciešams pašreizējā procesā, bet, ja jau sāku ieviest DevSecOps, tad jāiet līdz galam.
. Rakstnieki: Džastins Roilands un Dens Harmons.
Kas ir SecDevOps? Un DevSecOps? Kādas ir atšķirības? Lietojumprogrammu drošība - par ko tas ir? Kāpēc klasiskā pieeja vairs nedarbojas? Uz visiem šiem jautājumiem zina atbildes Jurijs Šabalins no Swordfish Security. Jurijs detalizēti atbildēs uz visiem jautājumiem un analizēs problēmas, kas saistītas ar pāreju no klasiskā modela lietojumprogrammu drošībai uz DevSecOps: kā pareizi pieiet drošas izstrādes procesa iekļaušanai DevOps procesā un nezaudēt neko, kā iziet galvenos drošības testēšanas posmus, kuri rīki ir izmantojami, kādi tie ir atšķirīgi un kā pareizi tos konfigurēt, lai izvairītos no apakšūdens akmeņiem.
Par runātāju: Jurijs Šabalins - Galvenais drošības arhitekts uzņēmumā Swordfish Security. Atbild par SSDL ieviešanu, par vispārēju analīzes rīku integrāciju vienotā izstrādes un testēšanas ekosistēmā. 7 gadu pieredze informācijas drošībā. Strādājis Alfa-Bankā, Sberbankā un Positive Technologies, kas izstrādā programmatūru un piedāvā pakalpojumus. Starptautisko konferenču ZerONights, PHDays, RISSPA, OWASP runātājs.
Lietojumprogrammu drošība: par ko tas ir?
Lietojumprogrammu drošība ir drošības sadaļa, kas atbild par lietojumprogrammu drošību. Tas nav saistīts ar infrastruktūru vai tīkla drošību, bet tieši ar to, ko mēs rakstām un pie kā strādā izstrādātāji - tas ir lietojumprogrammu trūkumi un ievainojamības.
Virziens — Drošības izstrādes cikls izstrādājusi uzņēmums Microsoft. Shēmā - kanoniskā SDLC modeļa, galvenais uzdevums ir nodrošināt drošību katrā izstrādes posmā, sākot no prasībām līdz izlaišanai un nonākšanai ražošanā. Microsoft saprata, ka tirgū ir pārāk daudz kļūdu, to kļūst arvien vairāk, un ar to jādara kaut kas, un piedāvāja šo pieeju, kas kļuva par kanonisku.
Lietojumprogrammu drošība un SSDL mērķis nav atklāt ievainojamības, kā parasti tiek uzskatīts, bet novērst to rašanos. Laika gaitā Microsoft kanoniskā pieeja tika uzlabota, attīstīta, tajā ienāca dziļāka un detalizētāka izpratne.
Kanoniķais SDLC ir detalizēts dažādās metodoloģijās — OpenSAMM, BSIMM, OWASP. Metodoloģijas atšķiras, bet kopumā ir līdzīgas.
Būvējot drošību iekšā nobrieduma modelis
Man visvairāk patīk BSIMM — . Metodoloģijas pamats ir lietojumprogrammu drošības procesa sadalīšana 4 jomās: vadība, izlūkošana, SSDL punkti un izvietošana. Katram jomu ir 12 prakses, kas tiek attēlotas kā 112 aktivitātes.
Katram no 112 aktivitātēm ir 3 nobrieduma līmeņi: sākotnējais, vidējais un progresīvais. Visas 12 prakses var pētīt pa daļām, izvēloties svarīgākās lietas, izprotot, kā tās ieviest un pakāpeniski pievienojot elementus, piemēram, statisko un dinamisko kodu analīzi vai kodu pārskatu. Izstrādājiet plānu un saskaņā ar to mierīgi strādājiet, lai ieviestu izvēlētās aktivitātes.
Kāpēc DevSecOps
DevOps ir kopīgs liels process, kurā ir jāparūpējas par drošību.
Sākotnēji tika paredzētas drošības pārbaudes. Praksē drošības komandu skaits bija ievērojami mazāks nekā tagad, un tās darbojās nevis kā procesa dalībnieki, bet gan kā kontroles un uzraudzības institūcija, kas noraksta prasības un pārbauda produkta kvalitāti tā izlaides beigās. Tas ir klasiskā pieeja, kurā drošības komandas atradās aiz izstrādes sienas un nepiedalījās procesā.
Galvenā problēma ir tā, ka informācijas drošība ir atsevišķi no izstrādes. Parasti tas ir noteikts informācijas drošības ietvars, kurā ir 2-3 lielas un dārgas ierīces. Reizi pusgadā tiek pārbaudīts avota kods vai lietotne, un reizi gadā tiek veikti . Tas viss nov leads pie tā, ka produkta iznākšanas termiņi tiek atlikti, bet izstrādātājiem tiek uzvērsta liela skaitā ievainojamību no automatizētajiem rīkiem. Viss šis process ir nesaprotams un grūti labojams, jo iepriekšējos sešos mēnešos nav izpildīti rezultāti, bet šeit ierodas jauns partij.
Darbojoties mūsu uzņēmumā, mēs redzam, ka drošība visās sfērās un nozarēs saprot, ka ir pienācis laiks piesaistīties un darboties kopā ar izstrādi vienā ritmā — . DevSecOps paradigma lieliski iederas elastīgās izstrādes metodoloģijā, tās ieviešanā, atbalstā un līdzdalībā katrā izlaišanas un iterācijas procesā.
Pāreja uz DevSecOps
Visnozīmīgākais vārds drošības attīstības dzīves ciklā ir «process»Jums tas jāizpro pirms domāt par rīku iegādi.
Vienkārši iekļaut rīkus DevOps procesā nav pietiekami — svarīga ir mijiedarbība un izpratne starp procesa dalībniekiem.
Cilvēki ir svarīgāki par rīkiem
Bieži drošas izstrādes procesa plānošana sākas ar rīka izvēli un iegādi, bet beidzas ar mēģinājumiem integrēt rīku esošajā procesā, kas paliek tikai mēģinājumi. Tas noved pie skumjām sekām, jo katram rīkam ir savas īpatnības un ierobežojumi.
Izplatīts gadījums, kad drošības nodaļa izvēlas labu, dārgu rīku ar plašām iespējām un pieprasa izstrādātājiem iekļaut to procesā. Bet nesanāk — process ir izveidots tā, ka ierobežojumi jau iegādātā rīka neiekļaujas esošajā paradigmas.
Vispirms aprakstiet, kādu rezultātu vēlaties un kā būs izskatīties process. Tas palīdzēs saprast rīku un drošības lomas procesā.
Sāciet ar to, kas jau tiek izmantots
Pirms iegādājaties dārgus rīkus, paskatieties, kas jums jau ir. Katram uzņēmumam ir drošības prasības, kas tiek izvirzītas izstrādei, ir pārbaudes, pen-testēšana — kāpēc gan to visu nepadarīt saprotamu un ērtiem visiem?
Parasti prasības ir papīra dokuments, kas stāv plauktā. Ir bijuši gadījumi, kad mēs ierodamies uzņēmumā, lai apskatītu procesus, un lūdzam parādīt drošības prasības attiecībā uz programmatūru. Speciālists, kurš ar to nodarbojās, ilgi meklēja:
— Tagad, kaut kur piezīmēs bija ceļš, kur atrodas šis dokuments.
Galu galā mēs saņēmām dokumentu pēc nedēļas.
Prasībām, pārbaudēm un citam izveidojiet lapu, piemēram, uz Confluence — tas ir ērti visiem.
Vienkāršāk ir pārformatēt to, kas jau ir, un izmantot kā sākuma punktu.
Izmantojiet Security Champions
Parasti vidējā uzņēmumā uz 100-200 izstrādātājiem strādā viens drošības speciālists, kurš veic vairākas funkcijas un fiziski nespēj visu pārbaudīt. Pat ja viņš cenšas no visas sirds — viens nespēs pārbaudīt visu kodu, ko rada izstrāde. Šādām situācijām ir izstrādāta koncepcija — .
Drošības čempionus - tas ir cilvēks izstrādes komandā, kuram ir interese par jūsu produkta drošību.
Drošības čempions - iekļūšanas punkts izstrādes komandā un drošības evaņģēlists vienā personā.
Parasti, kad izstrādes komandā nāk drošības speciālists un norāda uz kļūdu kodā, tad saņem pārsteigumu izraisošu atbildi:
— Un jūs esat kas? Es jūs redzu pirmo reizi. Man viss ir kārtībā - mans vecākais kolēģis kodu pārskatīšanā ir teicis "pieteikties", mēs turpinām tālāk!
Tā ir tipiska situācija, jo ar augstākajiem vai vienkārši kolēģiem, ar kuriem izstrādātājs nepārtraukti sadarbojas darbā un kodu pārskatīšanā, uzticība ir daudz lielāka. Ja vietā drošības speciālista kļūdu un sekas norādīs drošības čempions, tad viņa vārds būs ar lielāku svaru.
Izstrādātāji arī labāk pārzina savu kodu nekā jebkurš drošības speciālists. Cilvēkam, kam ir vismaz 5 projekti statiskās analīzes rīkā, parasti ir grūti atcerēties visas nianses. Drošības čempioni pārzina savu produktu: kas ar ko sadarbojas un uz ko skatīties pirmajā vietā - viņi ir efektīvāki.
Tātad, padomājiet par drošības čempionu ieviešanu un komandas drošības ietekmes paplašināšanu. Pats čempions arī gūs labumu: profesionāla attīstība jaunā jomā, tehniskā apvāršņa paplašināšana, tehnisko, vadības un līderības prasmju attīstīšana, tirgus vērtības paaugstināšana. Tas ir zināms sociālās inženierijas elements, jūsu "acis" izstrādes komandā.
Testēšanas posmi
apgalvo, ka 20% pūļu dod 80% rezultātu. Šie 20% - tas ir aplikāciju analīzes prakses, kuras var un jāautomatizē. Šādu aktivitāšu piemēri ir statiskā analīze - SAST, dinamiskā analīze - DAST, un atvērto avotu kontrole. Pastāstīšu sīkāk par aktivitātēm, kā arī par rīkiem, ar kādām īpatnībām mēs parasti saskaramies to ieviešanā procesā un kā to darīt pareizi.
Galvenās problēmas rīkos
Izcelšu aktuālās visiem rīkiem problēmas, kurām nepieciešama uzmanība. Izpētīšu tās sīkāk, lai vairs neatkārtotos.
Ilgs analīzes laiks. Ja, jaņem vērā, ka, ja no komitēšanas līdz nonākšanai ražošanā paiet 30 minūtes visiem testi un būvniecībai, tad drošības pārbaudes prasīs dienu. Tā kā vārdus neviens nemainīs. Ņemiet vērā šo īpatnību un izdariet secinājumus.
Augsts False Negative vai False Positive līmenis. Visi produkti ir atšķirīgi, visi izmanto dažādus ietvarus un kodēšanas stilus. Atšķirīgās kodu bāzēs un tehnoloģijās rīki var parādīt atšķirīgu False Negative un False Positive līmeni. Tāpēc skatieties, kas tieši jūsu uzņēmumā un jūsu lietojumprogrammām rādīs labus un ticamus rezultātus.
Nav integrāciju ar esošajiem rīkiem. Apskatiet rīkus, ņemot vērā integrācijas ar to, ko jau izmantojat. Piemēram, ja jums ir Jenkins vai TeamCity - pārbaudiet rīku integrāciju tieši ar šo programmatūru, nevis ar GitLab CI, kuru jūs neizmantojat.
Trūkst vai pārmērīga sarežģītība pielāgošanā. Ja rīkam nav API, tad kādēļ tam būt? Viss, ko var izdarīt saskarnē, jābūt pieejamam caur API. Ideāli, rīkam jābūt iespēju pielāgot pārbaudes.
Nav produktu attīstības plāna. Izstrāde neapstājas, mēs vienmēr izmantojam jaunus ietvarus un funkcijas, pārrakstām veco kodu jaunās valodās. Mēs vēlamies būt pārliecināti, ka rīks, ko mēs iegādāsimies, atbalstīs jaunus ietvarus un tehnoloģijas. Tādēļ ir svarīgi zināt, ka produktam ir reāls un pareizs .
Procesa īpatnības
Papildus rīku īpatnībām ņemiet vērā arī izstrādes procesa īpatnības. Piemēram, traucēt izstrādi ir tipiska kļūda. Apskatīsim, kādas vēl īpatnības jāņem vērā un uz ko jāpievērš uzmanību drošības komandai.
Lai nesabojātu izstrādes un laika grafikus, izveidojiet dažādas noteikumu un dažādus show stoppers — kritērijus, kas aptur procesu, ja ir ievainojamības — atšķirīgām vidēm.Piemēram, mēs saprotam, ka pašreizējais zars ir devējs stendā vai UAT, tādēļ mēs nepieņemam un nesakām:
— Jums šeit ir ievainojamības, jūs tālāk netiksiet!
Šajā posmā ir svarīgi informēt izstrādātājus, ka pastāv drošības problēmas, kurām jāpievērš uzmanība.
Vulnerabilitātes nav šķērslis turpmākai testēšanai: Roku, integrējoša vai manuāla. No otras puses, mums jānāk klāt, lai palielinātu produkta drošību, un lai izstrādātāji nepieļautu, ka drošība tiek ignorēta. Tāpēc dažreiz rīkojamies šādi: kad notiek izlaidums attīstības vidē, vienkārši informējam izstrādātājus:
— Čaļi, jums ir problēmas, lūdzu, pievērsiet tām uzmanību.
UAT posmā vēlreiz rādam brīdinājumus par ievainojamībām, bet izlaides posmā sakām:
— Čaļi, mēs vairākas reizes brīdinājām, jūs neko neizdarījāt — ar to jūs nevarat izlaist.
Ja runājam par kodu un dinamiku, tad ir nepieciešams rādīt un brīdināt par ievainojamībām tikai tajām funkcijām un kodam, kas tikko tika uzrakstīts šajā funkcijā. Ja izstrādātājs ir pārvietojis pogu par 3 pikseļiem un mēs viņam sakām, ka tur ir SQL injekcija un tāpēc vajag steidzami labot - tas ir nepareizi. Skatieties tikai to, kas ir rakstīts tagad, un izmaiņas, kas nāk lietotnē.
Pieņemsim, ka mums ir kāds funkcionāls defekts — kā programma nedrīkstētu darboties: nauda netiek pārskaitīta, klikšķinot uz pogas neveidojas pāreja uz nākamo lapu vai nevar ielādēt preci. Drošības defekti — tas ir tādi paši defekti, bet ne attiecībā uz programmas darbību, bet drošību.
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. Sherif Mansour, Expedia.
Kopš visas ievainojamības ir tādi paši defekti, tie ir jāsakārto tajā pašā vietā, kur visi izstrādes defekti. Tāpēc aizmirstiet par ziņojumiem un biedējošiem PDF, kurus neviens neskatās.
Kad es strādāju uzņēmumā, kas nodarbojās ar izstrādi, man tika nosūtīts ziņojums no statiskās analīzes rīkiem. Es to atvēru, šausmīgi izbrīnījos, pagatavoju kafiju, pārlapu 350 lapas, aizvēru un turpināju strādāt. Lieli ziņojumi ir miruši ziņojumi. Parasti tie nekur nenonāk, e-pasti tiek dzēsti, aizmirsti, pazūd vai bizness saka, ka uzņemas riskus.
Ko darīt? Apstiprinātos defektus, kurus esam atraduši, vienkārši pārveidojam izstrādei vieglākā formā, piemēram, saglabājot backlogā Jira. Defektus prioritizējam un novēršam prioritātes secībā, līdzīgi kā funkcionālos defektus un testu defektus.
Statiskā analīze – SAST
Tas ir koda analīze, lai atklātu ievainojamības., bet tas nav tas pats, kas SonarQube. Mēs pārbaudām ne tikai pēc paraugiem vai stila. Analīzē tiek pielietoti vairāki pieejas: pēc ievainojamību koka, pēc , pēc konfigurācijas failu analīzes. Tas viss attiecas tieši uz kodu.
Pieejas priekšrocības: ievainojamību atklāšana kodā agrīnajā izstrādes posmā, kad vēl nav stendu un gatava rīka, un iespēja inkrementāla skanēšana: skenēt koda daļu, kas ir mainījusies, un tikai to funkciju, kuru pašlaik veidojam, kas samazina skenēšanas laiku.
Mīnusi – tas ir nepieciešamo valodu atbalsta trūkums.
Nepieciešamās integrācijas, kas ir jābūt rīkos, manu subjektīvo viedokli:
- Integrācijas rīks: Jenkins, TeamCity un Gitlab CI.
- Izstrādes vide: Intellij IDEA, Visual Studio. Izstrādātājam ir ērtāk neskarties nesaprotamā saskarnē, kuru vēl jāmācās, bet tieši savā darba vietā savā personīgajā izstrādes vidē redzēt visas nepieciešamās integrācijas un atrastās ievainojamības.
- Koda pārskats: SonarQube un manuālais pārskats.
- Defektu izsekotāji: Jira un Bugzilla.
Attēlā ir daži no labākajiem statiskās analīzes pārstāvjiem.
Svarīgi ir ne instrumenti, bet process, tāpēc ir pieejami Open Source risinājumi, kas ir arī labi, lai izmēģinātu procesu.
SAST Open Source neatklās milzīgu skaitu ievainojamību vai sarežģītu DataFlow, bet procesā to var un vajag lietot. Tie palīdz saprast, kā tiks veidots process, kurš atbildēs par kļūdām, kurš ziņos, kurš atskaņos. Ja vēlaties veikt sākotnējo posmu, lai drošinātu savu kodu – izmantojiet Open Source risinājumus.
Kā to integrēt, ja esat ceļa sākumā, jums nav nekas: ne CI, ne Jenkins, ne TeamCity? Apskatīsim integrācijas procesā.
Integrācija CVS līmenī
Ja jums ir Bitbucket vai GitLab, varat veikt integrāciju .
Pēc notikuma — pull request, commit. Jūs skenējat kodu un build statusā parādāt, vai drošības pārbaude ir izturēta vai nē.
Atsauksmes. Bez šaubām, atsauksmes ir nepieciešamas vienmēr. Ja jūs vienkārši izpildījāt uz drošības pusi, sakrājāt to kastītē un nevienam par to neko neteicāt, bet pēc tam mēneša beigās izbērtu kaudzi kļūdu — tas nav pareizi un nav labi.
Integrācija ar code review sistēmu
Kādreiz mēs nolikām tehniskā lietotāja AppSec par noklusējuma revīziju daudzu svarīgu projektu rindā. Atkarībā no tā, vai jaunajā kodā ir atklātas kļūdas vai nav, pull request revīzents pievieno statusu 'accept' vai 'need work' — vai nu viss ir kārtībā, vai jāpilnveido ar norādēm uz to, kas tieši ir jāuzlabo. Integrācija ar versiju, kas iet ražošanā, bija iekļauta kādas merge aizlieguma prasība, ja testēšana par drošību nav izturēta. Mēs to izmantojām manuālā code review procesā, un pārējie procesa dalībnieki redzēja drošības statusus tieši šim konkrētajam procesam.
Integrācija ar SonarQube
Daudziem ir attiecībā uz koda kvalitāti. Šeit ir tas pats — var izveidot tos pašus gates tikai SAST rīkiem. Tas būs tas pats interfeiss, tas pats quality gate, tikai to sauks security gate. Un tāpat, ja jums ir izveidots process, izmantojot SonarQube, varat droši to visu integrēt.
Integrācija CI līmenī
Te arī viss ir pietiekami vienkārši:
- Vienā līmenī ar automātiskajiem testiem, vienības testiem.
- Attīstības posmu sadalīšana: dev, test, prod. Var tikt iekļauti dažādi noteikumu komplekti vai dažādas kļūdu nosacījumi: apturējam būvniecību, neapturējam būvniecību.
- Sinhronais/asinhronais palaišana. Mēs gaidām drošības testu rezultātu pabeigšanu vai negaidām. Tas nozīmē, ka mēs tos vienkārši palaidām un ejam tālāk, un pēc tam saņemam statusu, ka viss ir labi vai slikti.
Tas viss ir ideālā rozā pasaulē. Reālajā dzīvē tāda nav, bet mēs tiecamies. Drošības pārbaudes rezultātiem jābūt līdzīgiem vienības testu rezultātiem.
Piemēram, mēs uzņēmāmies lielu projektu un nolēmām, ka tagad to skanēsim ar SAST — OK. Mēs ielādējām šo projektu SAST, viņš mums sniedza 20 000 ievainojamību, un, izdarot spēcīgu lēmumu, pieņēmām, ka viss ir kārtībā. 20 000 ievainojamību — tas ir mūsu tehniskais parāds. Parādu liksim kastītē, pakāpeniski risināsim un reģistrēsim kļūdas defektu izsekotājos. Nomašiam uzņēmumu, visu izdarīsim paši vai mūs atbalstīs Security Champions — un tehniskais parāds samazināsies.
Un visām jaunajām ievainojamībām jaunajā kodā jābūt novērstām tāpat kā kļūdām vienības vai automatizētajos testos. Noteikti sakot, sāka veidot, pārbaudījām, divi testi izgāzās un divi drošības testi. OK — gājām, paskatījāmies, kas notika, labojām vienu, labojām otro, nākamreiz pārbaudījām — viss ir kārtībā, jaunas ievainojamības neparādījās, testi netika izgāzti. Ja šī uzdevuma izpēte ir dziļāka vai ievainojumu labošana skar būtiskas lietas, kas atrodas aiz vāka: izveidojām kļūdu defektu izsekotājā, tas tiek prioritizēts un labots. Diemžēl pasaule nav ideāla, un testi dažreiz izgāžas.
Drošības vārti piemērs — analoģija ar kvalitātes vārtiem, ņemot vērā ievainojamību klātbūtni un skaitu kodā.
Integrējam ar SonarQube — spraudnis tiek uzstādīts, viss ir ļoti ērti un lieliski.
Integrācija ar izstrādes vidi
Integrācijas iespējas:
- Skenēšanas palaišana no izstrādes vides vēl pirms commit.
- Rezultātu apskate.
- Rezultātu analīze.
- Sinhronizācija ar serveri.
Apmēram tā izskatās rezultātu iegūšana no servera.
Mūsu izstrādes vidē parādās papildu punkts, kas informē, ka skenēšanas laikā tika atklātas šādas ievainojamības. Var uzreiz labot kodu, skatīties ieteikumus un . Tas viss atrodas izstrādātāja darba vietā, kas ir ļoti ērti — nav nepieciešams iet uz citām saitēm un skatīt kaut ko papildus.
Atvērtā koda
Tas ir mans iecienītākais temats. Visi izmanto atvērtā koda bibliotēkas — kāpēc rakstīt daudz stiegru un velosipēdu, kad var ņemt gatavu bibliotēku, kurā viss jau ir realizēts?
Protams, tā ir, bet bibliotēkas arī raksta cilvēki, un tās ietver noteiktus riskus, kā arī tajās pastāv ievainojamības, par kurām periodiski vai pastāvīgi tiek ziņots. Tāpēc ir nākamais solis lietojumprogrammu drošībā — tas ir Open Source komponentu analīze.
Open Source 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 ka vai bug tracker’os ir kādas ievainojamības, kas attiecas uz šo bibliotēkas versiju. Mēģinot to izmantot, rīks izsniegs brīdinājumu, ka bibliotēka ir ievainojama, un iesaka izmantot citu versiju, kurā nav ievainojamību.
Licencēšanas tīrības analīze. Pie mums tas pagaidām nav pārāk populārs, bet, ja jūs strādājat ar ārzemēm, tur periodiski varat saņemt sodus par atvērtā koda komponentu izmantošanu vai modificēšanu, ko nedrīkst lietot. Saskaņā ar bibliotēkas licencēšanas politiku, to mēs nevaram darīt. Ja mēs to modificējām un izmantojam, mums ir jāpublicē savs kods. Protams, neviens nevēlas publicēt savus produktu kodus, bet no tā arī var pasargāties.
Komponentu analīze, kas tiek izmantoti rūpnieciskajā vidē. Iedomāsimies hipotētisku situāciju, ka mēs beidzot esam pabeiguši izstrādi un laiduši klajā pēdējo versiju mūsu mikropakalpojuma. Tas tur lieliski dzīvo — nedēļu, mēnesi, gadu. Mēs to nesavācam, drošības pārbaudes neveicam, šķiet, viss ir labi. Bet pēkšņi divas nedēļas pēc izlaišanas tiek atklāta kritiska ievainojamība Open Source komponentā, ko mēs izmantojam tieši šajā izlaistajā versijā, rūpnieciskajā vidē. Ja mēs neierakstām, ko un kur mēs izmantojam, tad šo ievainojamību mēs vienkārši nepamanīsim. Dažos rīkos ir iespēja uzraudzīt ievainojamības bibliotēkās, kas šobrīd tiek izmantotas rūpniecībā. Tas ir ļoti noderīgi.
Iespējas:
- Dažādas politikas dažādiem izstrādes posmiem.
- Komponentu uzraudzība rūpnieciskajā vidē.
- Bibliotēku kontrole organizācijas kontūrā.
- Atbalsts dažādām apkopošanas sistēmām un valodām.
- Docker attēlu analīze.
Daži piemēri nozares līderiem, kas nodarbojas ar Open Source analīzēm.
Vienīgais bezmaksas no tiem — tas ir no OWASP. To var iekļaut pirmajās posmās, lai redzētu, kā tas darbojas un ko tas atbalsta. Galvenokārt tie ir visi mākoņa produkti vai on-premise, bet viņu datu bāzes tomēr tiek sūtītas internetā. Tie sūta nevis jūsu bibliotēkas, bet hash vai savas vērtības, kuras tās aprēķina, un pirkstu nospiedumus uz savu serveri, lai saņemtu ziņojumu par esošajām ievainojamībām.
Integrācija procesā
Bibliotēku uzraudzība perimetrā, kas tiek lejupielādētas no ārējiem resursiem. Mums ir ārējie un iekšējie repozitāri. Piemēram, iekšējā Event Central ir Nexus, un mēs vēlamies, lai mūsu repozitārā nebūtu nevienas ievainojamības ar statusu "kritiska" vai "augsta". Var iestatīt starpniekserveri, izmantojot Nexus Firewall Lifecycle, lai šādas ievainojamības tiktu bloķētas un nenonāktu iekšējā repozitārā.
Integrācija CI. Uz viena līmeņa ar automātiskajiem testiem, vienību testiem un sadalījumu pa attīstības posmiem: dev, test, prod. Katrs posms var lejupielādēt jebkuras bibliotēkas, izmantot ko vien vēlas, bet, ja tajā ir kaut kas stingrs ar statusu "kritisks" - iespējams, vērts pievērst uzmanību izstrādātājiem pirms nonākšanas ražošanā.
Integrācija ar artefaktiem: Nexus un JFrog.
Integrācija izstrādes vidē. Rīkiem, kurus izvēlaties, vajadzētu būt integrācijai ar izstrādes vidēm. Izstrādātājam jābūt pieejai skenēšanas rezultātiem no sava darba vietas vai iespēja pašam veikt skenēšanu un pārbaudīt kodu uz ievainojamībām pirms komitēšanas CVS.
Integrācija CD. Tas ir foršs rīks, kas man ļoti patīk un par kuru es jau esmu runājis - jauno ievainojamību monitorings ražošanas vidē. Tas darbojas aptuveni šādi.
Mums ir Publiskie komponentu repozitāri — noteikumi rīkiem no ārienes un mūsu iekšējā repozitorija. Mēs vēlamies, lai tajā būtu tikai uzticami komponenti. Proksējot pieprasījumu, mēs pārbaudām, vai lejupielādētajā bibliotēkā nav drošības ievainojamību. Ja tā atbilst noteiktām politikām, kuras mēs izvirzām un kas obligāti jāapstiprina ar izstrādi, tad to neielādējam, un tiek saņemtas atsauksmes par citu versiju izmantošanu. Tādējādi, ja bibliotēkā ir kaut kas patiesi kritisks un slikts, izstrādātājs vēl instalācijas posmā nesaņems bibliotēku — lai izmantotu augstāku vai zemāku versiju.
- Build procesā mēs pārbaudām, vai neviens nav piegādājis neko sliktu, vai visi komponenti ir droši un neviens nav atnesis neko bīstamu uz USB zibatmiņas.
- Mūsu repozitorijā ir tikai uzticami komponenti.
- Deploy procesā mēs vēlreiz pārbaudām pašu paketi: war, jar, DL vai Docker attēlu, lai pārliecinātos, ka tas atbilst politikai.
- Ietverot ražošanā, mēs uzraugām to, kas notiek ražošanas vidē: vai tiek atklātas vai netiek atklātas kritiskas ievainojamības.
Dinamisks analīze — DAST
Dinamiski analīzes rīki radikāli atšķiras no visām iepriekš minētajām metodēm. Tas ir kaut kas līdzīgs lietotāja darbības imitācijai ar programmu. Ja tā ir tīmekļa programma, mēs nosūtām pieprasījumus, atdarot klienta darbības, nospiežam pogas priekšējā pusē, sūtot mākslīgus datus no formas: pēdiņas, iekavas, simbolus dažādās kodēšanas shēmās, lai noskatītos, kā programma strādā un apstrādā ārējos datus.
Šī pati sistēma ļauj pārbaudīt veidņu ievainojamības atvērtā koda. Tā kā DAST nezina, kuru atvērtā koda mēs izmantojam, tā vienkārši nosūta "ļauno" paraugu un analizē servera atbildes:
— Aha, šeit ir problēma ar deserializāciju, un šeit nav.
Šajā ir lieli riski, jo, ja jūs veicat šo drošības testu uz tā paša stenda, ar kuru strādā testētāji, var notikt nepatīkamas lietas.
- Augsta slodze uz tīkla lietojumprogrammu serveri.
- Nav integrāciju.
- Iespēja mainīt iestatījumus analizējamā lietojumprogrammā.
- Nav nepieciešamo tehnoloģiju atbalsta.
- Iestatīšanas sarežģītība.
Mums bija situācija, kad mēs beidzot palaidām AppScan: ilgi pieprasījām piekļuvi lietotnei, saņēmām 3 kontus un priecājāmies — beidzot visu pārbaudīsim! Palaižot skenēšanu, pirmais, ko AppScan izdarīja, bija iekļūšana admin panelī, visu pogu nospiešana, pusi datu maiņa, un tad tas pat nogalināja serveri ar saviem -pieprasījumiem. Izstrāde ar testēšanu teica:
— Puiši, jūs jokojat?! Mēs jums devām kontus, bet jūs uzstādījāt stendu!
Ņemiet vērā iespējamos riskus. Ideālā gadījumā sagatavojiet atsevišķu stendu informācijas drošības testēšanai, kas būs izolēts no pārējās vides vismaz kaut kā, un, noteikti, vēlams veikt admin testēšanu manuāli. Tas ir pentests — tie atlikušies procenti pūļu, kurus mēs tagad neapsveram.
Jāņem vērā, ka to var izmantot kā analogu slodzes testēšanai. Pirmajā posmā var ieslēgt dinamisko skeneri 10-15 plūsmās un apskatīties, kas notiks, bet, kā rāda prakse, parasti nekas labs.
Daži resursi, kurus parasti izmantojam.
Jāizceļ — tas ir „Šveices nazis” ikvienam drošības speciālistam. To izmanto visi, un tas ir ļoti ērti. Tagad iznākusi jauna demonstrācijas versija enterprise edition. Ja iepriekš tā bija vienkārši stand alone utilīta ar spraudņiem, tad tagad beidzot izstrādātāji veido lielu serveri, no kura varēs pārvaldīt vairākus aģentus. Tas ir lieliski, iesaku izmēģināt.
Integrācija procesā
Integrācija notiek pietiekami labi un vienkārši: skanēšanas palaišana pēc veiksmīgas lietojumprogrammas instalācijas stendā un skanēšana pēc veiksmīgas integrācijas testēšanas.
Ja integrācijas nedarbojas vai tur ir liegumi un mock funkcijas, tas ir bezjēdzīgi un bezjēdzīgi — kādu modeli mēs neizsūtītu, serveris tomēr atbildēs vienādi.
- Ideāli — atsevišķs stends testēšanai.
- Pirms testēšanas uzsākšanas ierakstiet pieteikšanās secību.
- Sistēmas administrācijas testēšana — tikai manuāli.
Process
Nedaudz vispārīgi par procesu kopumā un par katra instrumenta darbu, īpaši. Visas lietojumprogrammas ir atšķirīgas — kādai labāk strādā dinamiskā analīze, kādai statiskā, kādai OpenSource analīze, pentesti vai vispār kaut kas cits, piemēram, notikumu analīze .
Katram procesam nepieciešama uzraudzība.
Lai saprastu, kā darbojas process un kur to var uzlabot, ir jāvāc metriķi no visa, ko varam sasniegt, tostarp ražošanas metriķi, metrikas no rīkiem un no defektu izsekotājiem.
Jebkuri dati ir noderīgi. Jāskatās dažādos griezumos, kur tas vai cits rīks tiek labāk pielietots, kur konkrēti process klibo. Varbūt ir vērts paskatīties uz izstrādes atbildes laiku, lai saprastu, kur uzlabot procesu, pamatojoties uz laiku. Jo vairāk datu, jo vairāk griezumu var izveidot no augsta līmeņa līdz katra procesa detaļām.
Tā kā visiem statiskajiem un dinamiskajiem analīzes rīkiem ir savi API, savi palaišanas veidi, principi, dažiem ir grafiki, citiem nav – mēs rakstām rīku AppSec Orkestrators, kas ļauj izveidot vienotu ieejas punktu visam procesam no produkta un pārvaldīt to no viena punkta.
Menedžeriem, izstrādātājiem un drošības inženieriem ir viens ieejas punkts, no kura var redzēt, kas tika palaists, iestatīt un uzsākt skenēšanu, saņemt skenēšanas rezultātus un izvirzīt prasības. Mēs centāmies izvairīties no papīra, pārvēršot visu saprotamā valodā, ko izmanto izstrāde – lapas Confluence ar statusu un metriķiem, defekti Jira vai dažādos defektu izsekotājos, vai integrēšanās sinhronajā/asinhronajā procesā CI/CD.
Galvenie secinājumi
Rīki nav galvenais. Pirmkārt, jāizdomā process – pēc tam jāievieš rīki. Rīki ir labi, bet dārgi, tāpēc var sākt ar procesu un veidot mijiedarbību un izpratni starp izstrādi un drošību. No drošības viedokļa – nav jāuzver viss pēc kārtas, no izstrādes viedokļa – ja ir kaut kas ļoti svarīgs, tad tas ir jānovērš, nevis jāaizver acis uz problēmu.
Produkta kvalitāte – kopīgs mērķis gan drošībai, gan izstrādei. Mēs darām vienu lietu, cenšoties, lai viss darbotos pareizi un nebūtu reputācijas risku un finansiālu zaudējumu. Tieši tāpēc mēs propagandējam DevSecOps, SecDevOps pieeju, lai uzlabotu komunikāciju un padarītu produktu kvalitatīvāku.
Sāciet ar to, kas jau pastāv: prasības, arhitektūra, daļēja pārbaude, apmācības, vadlīnijas. Nav nepieciešams uzreiz lietot visas prakses visiem projektiem — darbojieties iteratīvi. Nav vienotas standarta — eksperimentējiet un mēģiniet dažādus piegājienus un risinājumus.
Starp IOT defektiem un funkcionālajiem defektiem ir zīme vienādības.
Automatizējiet visu, kas pārvietojas. Viss, kas nepārvietojas — pārvietojiet un automatizējiet. Ja kaut kas tiek darīts ar rokām, tas nav labs procesa posms. Iespējams, to vajadzētu pārskatīt un arī automatizēt.
Ja IOT komanda ir neliela — izmantojiet Security Champions.
Iespējams, ka tas, par ko es runāju, jums nederēs un jūs izdomāsiet kaut ko savu — un tas ir labi. Bet izvēlieties rīkus, pamatojoties uz prasībām tieši jūsu procesam. Neskatieties uz to, ko saka kopiena, ka šis rīks ir slikts, bet tas labs. Iespējams, ka tieši jūsu produktā būs viss tieši pretēji.
Prasības rīkiem.
- Zems viltus pozitīvo līmenis.
- Atbilstošs analīzes laiks.
- Viegla lietošana.
- Integrāciju pieejamība.
- Produkta attīstības ceļa izpratne.
- Rīku pielāgošanas iespējas.
Jūrija ziņojumu izvēlējās par vienu no labākajiem DevOpsConf 2018. Lai iepazītos ar vēl vairāk interesantām idejām un praktiskiem gadījumiem, apmeklējiet 27. un 28. maijā Skolkovo festa ietvaros . Un vēl labāk, ja esat gatavs dalīties ar savu pieredzi, tad ziņojumam līdz 21. aprīlim.
Avots: habr.com
