Hirm ja vihkamine DevSecOps

Meil oli 2 koodi analüsaatorit, 4 dünaamilise testimise tööriista, omatehtud lahendusi ja 250 skripti. Ei, et see kõik oleks praeguses protsessis hädavajalik, kuid kui alustasin DevSecOps'i juurutamist, tuleb minna lõpuni.

AllikasIsiksuste autorid: Justin Roiland ja Dan Harmon.

Mis on SecDevOps? Ja DevSecOps? Milles need erinevad? Mis on rakenduste turvalisus? Miks traditsiooniline lähenemine enam ei toimi? Kõigile nendele küsimustele oskab vastata Juri Šabalin kohast Swordfish Security. Juri vastab kõigile küsimustele ja analüüsib probleeme, mis tulenevad üleminekust traditsioonilisest rakenduste turvalisuse mudelist DevSecOps'i protsessile: kuidas õigesti läheneda turvalise arendamise protsessi integreerimisele DevOps'i protsessis ja kuidas mitte midagi katki teha, millised on peamised turvatestimise etapid, milliseid tööriistu kasutada, kuidas need erinevad ja kuidas neid õigesti seadistada, et vältida takistusi.

Ettekandjast: Juri Šabalin - Chief Security Architect ettevõttes Swordfish Security. Vastutab SSDL rakendamise eest, samuti rakenduste analüüsitööriistade integreerimise eest ühte arenduse ja testimise ökosüsteemi. 7 aastat kogemust infotehnoloogia valdkonnas. Olen töötanud Alfa-Pank, Sberbank ja Positive Technologiesis, mis arendab tarkvara ja pakub teenuseid. Esineja rahvusvahelistel konferentsidel ZerONights, PHDays, RISSPA, OWASP.

Rakenduste turvalisus: millest see räägib?

Rakenduste turvalisus on turvalisuse haru, mis vastutab rakenduste turvalisuse eest. See ei puuduta infrastruktuuri või võrgu turvalisust, vaid seda, mida me kirjutame ja mille kallal arendajad töötavad — need on rakenduse vead ja haavatavused.

Valdkond SDL või SDLC — Turvalisuse arenduse elutsükkel on Microsofti loodud. Skeemil on toodud kanoniline SDLC mudel, mille peamine eesmärk on tagada turvalisus igas arenduse etapis, alates nõuetest kuni väljaandmise ja tootmisse jõudmiseni. Microsoft mõistis, et tööstuses on liiga palju vigu, need muutuvad järjest enamaks ja sellega tuleb midagi ette võtta, ning pakkus välja selle lähenemise, mis sai kanoniliseks.

Rakenduse turvalisus ja SSDL ei ole suunatud haavatavuste tuvastamisele, nagu sageli arvatakse, vaid nende ennetamisele. Aja jooksul on Microsofti kanoniline lähenemine paranenud ja arenenud, pakkudes sügavat detailset sukeldumist.

Kanoniline SDLC on erinevates meetodites, nagu OpenSAMM, BSIMM, OWASP, tugevalt detailsustatud. Meetodid erinevad, kuid üldiselt on nad sarnased.

Security Maturity Model

Mulle meeldib see kõige rohkem BSIMM — Security Maturity Model. Meetodoloogia alus on rakenduse turvalisuse protsessi jagamine neljaks valdkonnaks: juhtimine, teave, SSDL kontaktpunktid ja juurutamine. Igas valdkonnas on 12 praktikat, mis on esitatud 112 tegevusena.

Igal 112 tegevusel on 3 küpsuse taset: algtaseme, kesktaseme ja edasijõudnud. Kõiki 12 praktikat saab uurida osade kaupa, valida teile olulisi asju ning mõista, kuidas neid rakendada ja järk-järgult lisada elemente, näiteks staatilist ja dünaamilist koodi analüüsi või koodi ülevaatust. Koostate plaani ja töötate selle alusel rahulikult valitud tegevuste juurutamise raames.

Miks DevSecOps

DevOps on suur üldine protsess, kus tuleb hoolitseda turvalisuse eest.

Alguses DevOps eeldati turvakontrolle. Praktikas olid turvameeskonnad palju väiksemad kui praegu ning nad ei osalenud protsessis, vaid tegutsesid kontrolli- ja järelevalveorganina, mis seadis nõudeid ja kontrollis toote kvaliteeti väljaandmise lõpus. See on klassikaline lähenemine, mille puhul turvameeskonnad olid arendustegevusest eraldatud ja ei osalenud protsessis.

Peamine probleem ongi see, et infoturbe lahendused on arendusest eraldatud. Tavaliselt on tegemist mingi infoturbe raami ja selles 2–3 suure ja kalliga tööriistaga. Kord aastas saadakse lähtekood või rakendus, mida tuleb kontrollida, ja kord aastas tehakse penetratsioonitestid. See toob kaasa selle, et turule jõudmise tähtajad lükatakse edasi ning arendajatele langeb suur hulk haavatavusi automaatsete tööriistade kaudu. Kõike seda on võimatu analüüsida ja parandada, kuna isegi eelmistel kuudel ei ole tulemusi üle vaadatud, kuid nüüd on juba uus partii.

Meie ettevõtte töös näeme, et turvalisus kõigis valdkondades ja tööstustes mõistab, et on aeg end üles käärida ja arendada koos arendusega ühes rütmis — selles Agile. DevSecOps'i paradigma sobitub suurepäraselt paindliku arenduse metoodikaga, sealhulgas rakendamise, toe ja osalusega igas väljaandes ja iteratsioonis.

Üleminek DevSecOps'ile

Turvalise arenduse elutsükli kõige olulisem sõna on „protsess“. Te peate seda mõistma, enne kui mõtlema hakata tööriistade ostmisele.

Lihtsalt tööriistade lisamine DevOpsi protsessile ei ole piisav — oluline on suhtlemine ja arusaam protsessi osaliste vahel.

Inimesed on olulisemad kui tööriistad

Sageli algab turvalise arenduse protsessi planeerimine tööriista valimise ja ostmisega, kuid lõppeb katsetega integreerida tööriista olemasolevasse protsessi, mis jäetakse katseteks. See toob kaasa kurvad tagajärjed, kuna kõigil tööriistadel on omad eripärad ja piirangud.

Levinud olukord, kus turvaosakond valis hea, kallima tööriista, millel on laiad võimalused, ja tuli arendajate juurde — et seda protsessi integreerida. Aga ei suuda — protsess on üles ehitatud nii, et juba ostetud tööriista piirangud ei sobi praegusesse paradigma.

Alustage kirjeldamisest, millist tulemust soovite ja kuidas protsess välja näeb. See aitab mõista tööriista ja turvalisuse rolle protsessis.

Alustage juba olemasolust

Enne kallite tööriistade ostmist vaadake, mida teil juba on. Igal ettevõttel on arendusele esitatavad turvanõuded, on kontrolle, penteste — miks mitte kõik see tõlkida arusaadavasse ja kõigile mugavasse vormi?

Tavaliselt on nõuded paberil oleva tomes, mis seisab riiulis. Olime kunagi olukorras, kus tulime ettevõttesse protsesside vaatamiseks ja küsisime turvanõuete dokumendi näitamist. Spetsialist, kes sellega tegeles, otsis kaua:

— Noh, kuskil märkmetes oli rada, kuhu see dokument oli pandud.

Lõppkokkuvõttes saime dokumendi alles nädala pärast.

Nõuete, kontrollide ja muu jaoks looge näiteks leht, mis asub Confluence — see on kõigile mugav.

Lihtsam on ümber vormindada seda, mis juba olemas on, ja kasutada seda alustamiseks.

Kasutage Security Champions

Tavaliselt töötab keskmises ettevõttes 100–200 arendaja kohta üks turbeekspert, kes täidab mitmeid ülesandeid ja füüsiliselt ei suuda kõike kontrollida. Isegi kui ta püüab oma parima, ei suuda ta üksi kontrollida kõiki koode, mida arendus genereerib. Selliste juhtude tarvis on välja töötatud kontseptsioon — Security Champions.

Security Champions on inimene arendustiimis, kellel on huvi teie toote turvalisuse vastu.

Security Champion on sissepääs arendustiimi ning turvalisuse evangelist ühes isikus.

Tavaliselt, kui turbeekspert tuleb arendustiimi ja osutab veale koodis, saab ta üllatava vastuse:

— Kes teie olete? Ma näen teid esmakordselt. Mul on kõik hästi — minu vanem koleeg pani code review's 'apply', me läheme edasi!

See on tüüpiline olukord, sest usaldus vanemate või lihtsalt meeskonnakaaslaste vastu, kellega arendaja pidevalt tööalaselt suhtleb ja kes osalevad koodi ülevaatuses, on palju suurem. Kui veateate ja tagajärgede eest vastutab turvamees, siis tema sõna kaalub rohkem.

Arendajad tunnevad oma koodi paremini kui ükski turvamees. Inimesele, kellel on vähemalt 5 projekti staatilisest analüüsist, on tavaliselt keeruline meeles pidada kõiki nüansse. Turvameistrid tunnevad oma toodet: mida miski mõjutab ja millele esmalt tähelepanu pöörata – nad on tõhusamad.

Seega mõelge turvameistrite rakendamisele ja turvameeskonna mõju suurendamisele. Isegi turvameister saab sellest kasu: professionaalne areng uues valdkonnas, tehnilise silmaringi laiendamine, tehniliste, juhtimis- ja liidrioskuste arendamine, turuväärtuse tõstmine. See on teatud element sotsiaalsest inseneriteadusest, teie 'silmad' arendusmeeskonnas.

Testimise etapid

Paradigma 20 80 ütleb, et 20% pingutustest toob 80% tulemustest. Need 20% on rakenduste analüüsi praktikad, mida saab ja tuleb automatiseerida. Selliste tegevuste näideteks on staatiline analüüs — SAST, dünaamiline analüüs — DAST, ja Open Source kontroll. Räägin lähemalt tegevustest ning tööriistadest, millega me tavaliselt silmitsi seisame, kui need protsessi rakendame, ja kuidas seda õigesti teha.

Tööriistade põhiprobleemid

Tõstan esile kõiki tööriistu mõjutavad probleemid, mis vajavad tähelepanu. Uurin neid põhjalikumalt, et hiljem mitte korduda.

Pikaajaline analüüs. Kui kommitamisest tootmisse minekuks kulub 30 minutit kõigile testidele ja kogumisele, siis infoturbe kontrollid võtavad terve päeva. Nii ei saa protsessi pidurdada. Arvestage seda omadust ja tehke järeldusi.

Korke vale negatiivne või vale positiivne määr. Kõik tooted on erinevad, kõik kasutavad erinevaid raamistikke ja oma koodikirjutamise stiili. Erinevad koodibasid ja tehnoloogiad võivad näidata erinevat vale negatiivsete ja vale positiivsete määrasid. Seega vaadake, mis täpselt on teie ettevõttes ja teie rakendused näitavad head ja usaldusväärset tulemust.

Ei ole integratsioone olemasolevate tööriistadega.. Vaadake tööriistu integratsioonide vaatenurgast, mida juba kasutate. Näiteks, kui teil on Jenkins või TeamCity, kontrollige tööriistade integratsiooni just selle tarkvaraga, mitte GitLab CI-ga, mida te ei kasuta.

Kohandamise puudumine või üleliigne keerukus. Kui tööriistal ei ole API-d, siis miks ta vajalik on? Kõik, mida saab teha liideses, peaks olema saadaval ka API kaudu. Ideaalis peaks tööriistal olema kohandamisvõime kontrollide jaoks.

Toote arenduse Roadmap'i puudumine. Arendus ei seisa paigal, me kasutame alati uusi raamistikke ja funktsioone, kirjutame vana koodi uutele keeltele ümber. Soovime olla kindlad, et tööriist, mille ostame, toetab uusi raamistikke ja tehnoloogiaid. Seetõttu on oluline teada, et tootest on olemas tõeline ja korrektne Roadmap arendamiseks.

Protsessi iseärasused

Lisaks tööriistade omadustele tuleb arvesse võtta ka arendusprotsessi eripära. Näiteks arendamise segamine on tüüpiline viga. Vaadakem, milliseid muid omadusi tuleb arvesse võtta ja millele turvameeskond peaks tähelepanu pöörama.

Et mitte rikkuda arendus- ja väljalasketähtaegu, looge erinevad reeglid ja erinevad show stoppers — kriteeriumid, mis peatavad ehitamisprotsessi, kui avastatakse haavatavusi — erinevates keskkondades. Näiteks mõistame, et praegune haru suundub arendajate stendi või UAT-i, seega ei peata me ega ütle:

— Teil on siin haavatavusi, te ei tohi edasi liikuda!

Sellel etapil on oluline öelda arendajatele, et esinevad turvaprobleemid, millele tuleks tähelepanu pöörata.

Haavatavuste olemasolu ei ole takistus edasiseks testimiseks: käsitsi, integreerimis- või manuaalselt. Teiselt poolt peame leidma viisi, kuidas toote turvalisust parandada, et arendajad ei ignoreeriks turvameeskonna leidmisi. Seetõttu käitume mõnikord nii: stendil, kui see viiakse arenduskeskkonda, lihtsalt teavitame arendust:

— Pois, teil on probleeme, palun pöörake neile tähelepanu.

UAT etapis näitame taas haavatavuste hoiatusi, ja kui jõuame tootmisse, ütleme:

— Pois, oleme mitu korda hoiatanud, te ei teinud midagi — sellega teid ei lasta välja.

Kui rääkida koodist ja dünaamikast, tuleb näidata ja hoiatada ainult nende funktsioonide ja koodi eest, mis on just selles funktsioonis kirjutatud. Kui arendaja tõukab nuppu 3 pikslit ja me ütleme talle, et tal on SQL-i süstimisprobleem ja seega peab kiiresti parandama — see pole õige. Vaadake ainult seda, mis on praegu kirjutatud, ja nende muudatuste üle, mis rakendusse tulevad.

Oletame, et meil on mingisugune funktsionaalne defekt — see on see, kuidas rakendus ei tohiks töötada: raha ei kantud üle, nupule klõpsamisel ei toimu üleminekut järgmisele lehele või kaup ei laadita. Turvavead — need on samasugused defektid, kuid mitte rakenduse töö raames, vaid turvalisuse osas.

Kuid kõik tarkvara kvaliteediprobleemid ei ole turvaprobleemid. Aga kõik turvaprobleemid on seotud tarkvara kvaliteediga. Sherif Mansour, Expedia.

Kuna kõik haavatavused on samuti defektid, peavad nad olema seal, kus on kõik arendusdefektid. Seega unustage aruanded ja hirmutavad PDF-dokumendid, mida keegi ei loe.

Kui ma töötasin ettevõttes, mis tegeles arendusega, sain ma aruande staatilisest analüüsist. Avasin selle, šokeerisin, keetsin kohvi, sirvisin 350 lehte, sulgesin selle ja läksin edasi töötama. Suured aruanded on surnud aruanded. Tavaliselt ei lähe need kuhugi, kirjad kustutatakse, unustatakse, kaotatakse või äri ütleb, et nad võtavad riske.

Mida teha? Kinnitatud defektid, mis leiti, muudetakse lihtsalt arendusele mugavaks vormiks, näiteks kogutakse backlog'i Jira-s. Defektid prioriseeritakse ja kõrvaldatakse prioriteedi järjekorras koos funktsionaalsete defektide ja testide defektidega.

Statsionaarne analüüs - SAST

See on koodi analüüs haavatavuste tuvastamiseks, kuid see ei ole sama mis SonarQube. Me ei kontrolli mitte ainult mustrite või stiili järgi. Analüüsis rakendatakse mitmeid lähenemisviise: haavatavuste puu, DataFlow, konfiguratsioonifailide analüüsimine. See kõik puudutab otseselt koodi.

Meetodi eelised: haavatavuste tuvastamine koodi varases arendusetapis, kui veel ei ole stende ega valmis tööriistu, ja võimalus inkrementaalseks skaneerimiseks: skaneerimine koodijupist, mis on muutunud, ja ainult selle funktsiooni puhul, mille kallal me praegu töötame, mis vähendab skaneerimise aega.

Miinused — on vajalikud keelte toetuse puudumine.

Vajalikud integratsioonid, mis peaksid olema tööriistades, minu subjektiivse arvamuse kohaselt:

• Integratsioonitööriist: Jenkins, TeamCity ja Gitlab CI.
• Arenduskeskkond: Intellij IDEA, Visual Studio. Arendajal on mugavam mitte navigeerida arusaamatusse liidesesse, mida tuleb veel meeles pidada, vaid näha oma töö kohas kõiki vajalikke integratsioone ja leitud haavatavusi.
• Koodikontroll: SonarQube ja käsitsi ülevaatus.
• Defektide jälgijad: Jira ja Bugzilla.

Pildil on mõned parimad esindajad staatilisest analüüsist.

Oluline on mitte tööriistad, vaid protsess, seega on olemas avatud lähtekoodiga lahendused, mis sobivad protsessi katsetamiseks.

SAST avatud allikas ei tuvastada tohutul hulgal haavatavusi ega keerulisi andmevooge, kuid nende kasutamine protsessi ülesehitamisel on vajalik. Need aitavad mõista, kuidas protsess kujundatakse, kes vastutab vigade eest, kes raportit koostab, ja kes aru annab. Kui soovite alustada oma koodi turvaprotsessi rajamist, kasutage avatud allika lahendusi.

Kuidas seda integreerida, kui olete teel alguses, ja teil pole midagi: ei CI, ei Jenkins, ei TeamCity? Vaatame integraatioone protsessis.

Integratsioon CVS-i tasemel

Kui teil on Bitbucket või GitLab, siis saate teha integratsiooni tasemel Concurrent Versions System.

Sündmuse põhjal — pull request, commit. Te skaneerite koodi ja build'i staatuse juures näitate, kas turvaskaneerimine on läbitud või mitte.

Tagasiside. Ilmselgelt on tagasiside alati vajalik. Kui lihtsalt teostate turvapoolel ülesande, panete selle kõik karpi ja ei räägi sellest kellelegi ning kuu lõpus viskate välja hulga vigu — see ei ole õige ja ei ole hea.

Integraatsioon koodivaatamise süsteemiga

Kord, kui me seadsime oluliste projektide vahel AppSec tehnilise kasutaja vaikerevisionääriks. Olenemata sellest, kas uues koodis on vigu või mitte, määrab pull request’iga revisjonifond staatuse 'accept' või 'need work' — kas kõik on OK või tuleb midagi täiendada koos linkidega, mida täpselt parandada. Integreerimisel versiooniga, mis läheb tootmisse, oli meil merge’i keelamine, kui turvatest ei olnud läbitud. Seda rakendati käsitsi koodivaatamisel ja teised protsessi osalejad nägid staatuseid, mis olid seotud turvaprotsessiga.

Integreerimine SonarQube'iga

Paljusid huvitab quality gate koodi kvaliteedi osas. Siin on asi sama — saame luua samad gates ainult SAST tööriistade jaoks. Oleme sama liidesega, sama quality gate’iga, lihtsalt selle nimi on security gate. Ja samuti, kui teil on SonarQube’i kasutamise protsess seadistatud, saate kõik sinna rahulikult integreerida.

Integreerimine CI tasemel

Siin on kõik ka üsna lihtne:

• Ühel tasemel automatiseeritud testimisega, unit-testidega.
• Arendusprotsessi etappide jagamine: dev, test, prod. Võib kasutada erinevaid reeglite kogumeid või erinevaid failitingimusi: peatame kogumise, ei peata kogumist.
• Sünkroonne/Asünkroonne käivitamine. Ootame testide turvajuhtimise lõpuleviimist või ei oota. See tähendab, et me lihtsalt käivitasime need ja liigume edasi, seejärel saame statuseni, et kõik on hästi või halvasti.

See kõik on ideaalses roosas maailmas. Reaalses elus nii ei ole, aga me püüame. Turvaskanneerimise tulemuseks peab olema sarnane tulemusele, mis saame üheüksuste testidest.

Näiteks võtsime suure projekti ja otsustasime, et nüüd hakkame selle SAST’iga skanneerima — OK. Panime selle projekti SAST-i, see andis meile 20 000 haavatavust ja me võtsime seejärel otsuse, et kõik on hästi. 20 000 haavatavust on meie tehniline võlg. Paneme võla karpi, hakkame aeglaselt lahendama ja registreerime vead veatöötlejatesse. Palgake ettevõte, teeme kõik ise või aitavad meid Security Champions — ja tehniline võlg hakkab vähenema.

Kuid kõik uued haavatavused uues koodis peavad olema kõrvaldatud samamoodi nagu vead ühik- või automaatkatsetes. Ütleme nii, et koostamine käivitus, testiti, kaks testi kukkus ja kaks testi seonduvalt turvalisusele. OK - läksime vaatasime, mis juhtus, parandasime üht, parandasime teist, järgmine kord testisime - kõik on hästi, uusi haavatavusi ei ilmunud ja testid ei kukkunud läbi. Kui see ülesanne on sügavam ja on vaja sellega head ülevaadet saada, või kui haavatavuste parandused mõjutavad suuri osi, mis on kapoti all: avame vea defekti jälgijasse, see prioriseeritakse ja parandatakse. Kahjuks ei ole maailm ideaalne ja testid kukuvad vahel läbi.

Näide turvaväravast - analoog kvaliteediväravale, kus on olemas ja palju haavatavusi koodis.

Integreerime SonarQube'iga - plugina paigaldamine on väga mugav ja äge.

Integratsioon arenduskeskkonnaga

Integreerimise võimalused:

• Skaneerimise käivitamine arenduskeskkonnas juba enne pühendamist.
• Tulemuste vaatamine.
• Tulemuste analüüs.
• Sünkroniseerimine serveriga.

Nii näeb serverist tulemuste saamine välja.

Meie arenduskeskkonnas Intellij IDEA ilmub ilmub täiendav punkt, mis teatab, et skaneerimise ajal leiti selliseid haavatavusi. Koodiga saab kohe parandada, vaadata soovitusi ja Flow Graph. Kõik see on paigutatud arendaja töökohale, mis on väga mugav — ei pea liikuma teistele linkidele ja vaatama midagi lisaks.

Avatud lähtekood

See on minu lemmikteema. Kõik kasutavad Open Source raamatukogusid — miks kirjutada tohutult toetusi ja jalgrattaid, kui saab võtta valmis raamatukogu, kus kõik on juba rakendatud?

Muidugi, see on nii, kuid raamatukogud kirjutavad ka inimesed, sisaldavad endas teatud riske ja seal on ka haavatavused, millest perioodiliselt või pidevalt teavitatakse. Seetõttu on järgmine samm rakenduse turvalisuses — avatud lähtekoodiga komponentide analüüs.

Avatud lähtekoodiga analüüs — OSA

Tööriist sisaldab kolme suurt etappi.

Haavatavuste leidmine raamatukogudes. Näiteks teab tööriist, et me kasutame mingit raamatukogu, ja et CVE või on bug-trackerites haavatavusi, mis seonduvad selle versiooni raamatukoguga. Katse seda kasutada toob esile hoiatuse, et raamatukogu on haavatav, ning soovitab kasutada teist versiooni, kus haavatavusi pole.

Litsentsipuhastuse analüüs. Meil ei ole see veel eriti populaarne, kuid kui te töötate välismaal, võib seal aeg-ajalt olla tagajärgi avatud lähtekoodiga komponentide kasutamise eest, mida ei saa kasutada või muuta. Vastavalt raamatukogu litsentsipoliitikale ei saa me seda teha. Kui me seda muutsime ja kasutame, peame oma koodi jagama. Loomulikult ei taha keegi oma toodete koodi jagada, kuid ka sellest on võimalik end kaitsta.

Komponentide analüüs, mida kasutatakse tööstuslikus keskkonnas. Kujutame ette hüpoteetilist olukorda, kus oleme lõpuks lõpetanud oma mikroteenuse arendamise ja välja andnud viimase versiooni tootmisse. See elab seal suurepäraselt — nädala, kuu, aasta. Me ei kogu seda, turvakontrolle ei tehta, kõik näib hea. Kuid äkki, kaks nädalat pärast väljalaskmist, ilmub kriitiline haavatavus avatud lähtekoodiga komponendis, mida me kasutame just selles versioonis tootmiskeskkonnas. Kui me ei registreeri, mida ja kus me kasutame, siis me seda haavatavust lihtsalt ei näe. Mõnes tööriistades on võimalus jälgida haavatavusi raamatukogudes, mis on praegu tootmises kasutusel. See on väga kasulik.

Võimalused:

• Erinevad poliitikad erinevate arendusetappide jaoks.
• Komponentide jälgimine tootmiskeskkonnas.
• Raamatukogude kontroll organisatsiooni piirides.
• Erinevate ehitussüsteemide ja keelte toetamine.
• Docker-piltide analüüs.

Mõned näited valdkonna liidritest, kes tegelevad avatud lähtekoodi analüüsiga.

Ainuke tasuta neist on Dependency-Check OWASP-ist. Seda saab esialgu sisselülitada, et näha, kuidas see töötab ja mida see toetab. Peamiselt on need kõik pilveteenused või kohapeal, kuid nende andmebaasidega saadetakse ikkagi andmeid internetti. Nad ei saada teie raamatukogusid, vaid hash'e või omi väärtusi, mida nad arvutavad, ning sõrmejälgi enda serverisse, et saada teavet haavatavuste olemasolu kohta.

Integreerimine protsessi

Teekide kontroll perimeetris, mis on alla laaditud välisest allikast. Meil on väline ja sisemine repositoorium. Näiteks Event Centralis on Nexus ja me soovime, et meie sisemises repositooriumis ei oleks kõrge või kriitilise staatusega haavatavusi. Saame konfigureerida edastusprotsessi, kasutades tööriista Nexus Firewall Lifecycle, nii, et sellised haavatavused kõrvaldatakse ja ei jõua sisemisse repositooriumisse.

Integreerimine CI. Ühtses tasemes automaattestide, ühiktestide ja arendusetappide jagamisega: dev, test, prod. Igal etapil on võimalik alla laadida erinevaid raamatukogusid, kasutada kõike, kuid kui seal on midagi kriitilist, tasub sellele arendajate tähelepanu pöörata etapi ajal, mil tullakse turule.

Integreerimine artefaktide haldustesse: Nexus ja JFrog.

Integreerimine arenduskeskkonda. Valitud tööriistadel peab olema integreerimine arenduskeskkondadega. Arendajal peab olema oma töökohtadel juurdepääs skaneerimistulemustele või võimalus ise oma koodi haavatavuste osas enne CVS-i komiteerimist skaneerida ja kontrollida.

Integreerimine CD-sse. See on lahe funktsioon, mis mulle tõeliselt meeldib ja millest olen juba rääkinud — uute haavatavuste jälgimine tootmiskeskkonnas. See töötab umbes nii.

Meil on Avalikud komponendi hoidlad — mõningad tööriistad väljast ja meie sisemine repos. Soovime, et seal oleksid ainult trusted components. Kliendi päringu proxüümisel kontrollime, et allalaaditaval teegil ei oleks haavatavusi. Kui see vastab teatud poliitikatele, mille me seame ja mille osas me kindlasti arutame arendusega, siis me ei tõmba seda ja tuleb tagasiside teise versiooni kasutamiseks. Seega, kui teegis on midagi tõeliselt kriitilist ja halba, siis arendaja ei saa teegi isegi installimise ajal - las kasutab kõrgemat või madalamat versiooni.

• Build’imise ajal kontrollime, et keegi ei oleks sisse toonud midagi halba, et kõik komponendid on ohutud ja keegi ei tooks mälupulgaga midagi ohtlikku.
• Meie repos on ainult trusted components.
• Deploimisel kontrollime veel kord just paketti: war, jar, DL või Docker-image selle osas, et see vastab poliitikale.
• Tootmisse minekul jälgime, mis toimub tööstuskeskkonnas: kas ilmnevad või ei ilmne kriitilised haavatavused.

Dünaamiline analüüs - DAST

Dünaamilise analüüsi tööriistad erinevad kardinaalselt kõikidest eelnevalt öeldud asjadest. See on teatud tüüpi kasutaja töö simuleerimine rakendusega. Kui see on veebirakendus, saadame päringuid, imiteerides kliendi tegevust, klikkides nuppudel, edastades vormidest kunstlikke andmeid: tsitaate, sulge, sümboleid erinevates kodeeringutes, et näha, kuidas rakendus töötab ja kuidas see välistatud andmeid töötleb.

Sama süsteem võimaldab kontrollida mallivigu avatud lähtekoodides. Kuna DAST ei tea, millist avatud lähtekoodi me kasutame, lihtsalt viskab see "kahjulikke" mustreid ja analüüsib serveri vastuseid:

— Aha, siin on deserialiseerimise probleem, aga siin ei ole.

Selles peituvad suured riskid, kuna kui teete selle turvatesti samal keskkonnas, mille kallal töötavad testijad, võivad juhtuda ebameeldivad asjad.

• Rakenduse serveri kõrge koormus.
• Puuduvad integratsioonid.
• Võimalus muuta analüüsitava rakenduse seadeid.
• Puudub vajalik tehnoloogiate tugi.
• Konfigureerimise keerukus.

Meil oli olukord, kus me lõpuks käivitasime AppScan'i: ligipääsu rakendusele oli keeruline saada, saime 3 kontot ja olime rõõmsad — lõpuks saame kõik üle vaadata! Käivitasime skanneerimise, ja esimene, mida AppScan tegi — läks admin-paneeli, klikkis kõigil nuppudel, muutis poole andmetest ja siis tappis serveri oma mailform-päringutega. Arendus koos testimisega ütlesid:

— Poisid, teete nalja?! Me andsime teile kontod, aga teie hävitasite keskkonna!

Arvestage võimalikke riske. Ideaalis valmistage testimiseks eraldi keskkond, mis oleks vähemalt osaliselt eraldatud ülejäänud keskkonnast, ja soovitatav on administraatori paneeli kontrollimine käsitsi. See on pentest — need viimased protsendid pingutust, mida me praegu ei kaalu.

Tasub arvestada, et seda saab kasutada koormustestimise analoogina. Esimeses etapis võib aktiveerida dünaamilise skaneerija 10-15 voogudega ja vaadata, mis juhtub, kuid tavaliselt, nagu praktika näitab, ei toimu midagi head.

Mõned ressursid, mida tavaliselt kasutame.

Tasub välja tuua Burp Suite — on "Šveitsi nuga" iga turbeprofessionaali jaoks. Seda kasutavad kõik ja see on väga mugav. Hiljuti ilmus uus demoversioon enterprise edition. Kui varem oli see lihtsalt stand-alone utiliit pluginatega, siis nüüd töötavad arendajad lõpuks välja suure serveri, mida saab kasutada mitme agendi haldamiseks. See on suurepärane, soovitan proovida.

Integreerimine protsessi

Integreerimine toimub piisavalt hästi ja lihtsalt: skaneerimise käivitamine pärast edukat installimist rakendustes ja skaneerimine pärast edukat integratsiooni testimist.

Kui integratsioonid ei tööta või seal on vaid pistikprogrammid ja mock-funktsioonid, siis pole sellest lihtsalt kasu — olenemata sellest, mis mustri me saadame, vastab server ikkagi ühtemoodi.

• Ideaalne oleks eraldi testimise keskkond.
• Enne testimise algust märkige üles logimise järjestus.
• Süsteemi haldamise testimine — ainult käsitsi.

Protsess

Üldiselt protsessi ja iga tööriista, sealhulgas, Tööriistad on erinevad – ühel töötab dünaamiline analüüs paremini, teisel staatiline, kolmandal OpenSource analüüs, pentestimine või hoopis midagi muud, näiteks sündmused. Waf.

Iga protsess vajab kontrolli.

Protsessi toimimise mõistmiseks ja selle parendamiseks tuleb koguda mõõdikuid kõigest, mis käeulatuses on, sealhulgas tootmisnäitajaid, tööriistade mõõdikuid ja defektijälgijatest.

Iga andmed on kasulikud. Tuleb vaadata eri aspektidest, kus konkreetset tööriista paremini rakendatakse, kus protsess konkreetselt kipub lagunema. Võib-olla tasub vaadata arenduse reageerimise aega, et mõista, kus protsessi ajas parandada. Mida rohkem andmeid, seda rohkem aspekte saab luua alates kõrgetasemelistest detailideni iga protsessi kohta.

Kuna kõigil staatilistel ja dünaamilistel analüsaatoritel on oma API-d, käivitamise viisid ja põhimõtted; ühel on graafikud, teisel ei ole – me kirjutame tööriista. AppSec Orkestrator, mis võimaldab luua ühtse sisenemise punkti kogu protsessi jaoks ja hallata seda ühest kohast.

Projektijuhtidel, arendajatel ja turbeinseneridel on üks sisenemise punkt, kust saab vaadata, mis on käimas, seadistada ja alustada skannimist, saada skannimise tulemusi ja esitada nõudeid. Püüame vältida pabereid, muutes kõik inimkeelde, mida arendus kasutab - lehed Confluences staatuste ja mõõdikute, defektid Jira-s või erinevates defekti jälgimise tööriistades, või integreerida sünkroonsesse/aasünkroonsesse protsess CI/CD-s.

Peamised järeldused

Tööriistad ei ole peamine. Esmalt tuleks läbi mõelda protsess - siis rakendada tööriistu. Tööriistad on head, kuid kallid, seega võib alustada protsessist ja seadistada koostöö ja arusaamise arenduse ja turva vahel. Turbe seisukohalt - ei pea 'kinni panema' kõike järjest, arenduse seisukohalt - kui midagi on kõrge mega super kriitiline, siis tuleb see kõrvaldada, mitte probleemile silma kinni pigistada.

Toote kvaliteet on ühine eesmärk nii puhul, nii arenduse osas. Me teeme ühte asja, püüdes, et kõik toimiks õigesti ning et ei tekiks mainekaotusi või rahalisi kaotusi. Just seetõttu propageerime DevSecOpsi ja SecDevOpsi lähenemist, et luua suhtlus ja parandada toote kvaliteeti.

Alustage olemasolevast: nõuded, arhitektuur, osalised kontrollid, koolitused, juhendmaterjalid. Ei ole vaja kohe rakendada kõiki praktikaid kõikidel projektidel — liikuge järk-järgult. Ühtegi standardit ei ole — katsetage proovige erinevaid lähenemisviise ja lahendusi.

Infoturbe defektide ja funktsionaalsete defektide vahel on võrdusmärk.

Automatiseerige kõik, mis liigub. Kõik, mis ei liigu — liigutage ja automatiseerige. Kui midagi tehakse käsitsi, siis ei ole see protsessi hea osa. Võib-olla tasub seda üle vaadata ja samuti automatiseerida.

Kui infoturbe meeskonna suurus on väike — kasutage Security Champions.

Võib-olla ei sobi see, millest olen rääkinud, teile ja leiutate midagi enda jaoks — ja see on hea. Kuid valige tööriistad, lähtudes oma protsessi nõudmistest. Ära lase end petta kogukonna arvamustest, et see tööriist on halb ja teine hea. Just teie tootel võib kõik olla vastupidi.

Tööriistade nõuded.

• Madala väärpositiivsete tulemuste tase.
• Mõistlik analüüsiaeg.
• Kasutusmugavus.
• Integratsioonide olemasolu.
• Toote arendusteed mõistmine.
• Tööriistade kohandamise võimalus.

Jüri ettekannet valiti üheks parimaks DevOpsConf 2018-l. Et tutvuda veelgi huvitavate ideede ja praktiliste juhtumitega, tulge 27. ja 28. mail Skolkovo DevOpsConf raames RIT++ festivali. Ja veel parem, kui olete valmis jagama oma kogemusi, siis esitage taotlus ettekande jaoks kuni 21. aprillini.

Allikas: habr.com