Hirm ja vihkamine DevSecOpsis

Meil oli 2 koodianalüsaatorit, 4 dünaamilise testimise tööriista, oma loodud tööriistad ja 250 skripti. Ei ole nii, et see kõik oleks praeguses protsessis vajalik, aga kui DevSecOpsi rakendamine on juba alustatud, siis tuleb minna lõpuni.

Allikas. Isikute autorid: Justin Roiland ja Dan Harmon.

Mis on SecDevOps? Ja DevSecOps? Millised on erinevused? Rakenduse turvalisus - millest see räägib? Miks klassikaline lähenemine enam ei toimi? Kõigile nendele küsimustele teab vastust Yuri Shabalin API-s Swordfish Security. Yuri vastab kõigile küsimustele ja käsitleb klassikalisest rakenduse turvalisuse mudelist DevSecOpsi protsessile ülemineku probleeme: kuidas õigesti läheneda turvalise arendamise protsessi integreerimisele DevOps-i protsessi, et mitte midagi purustada, kuidas läbida põhilised turvatestimise etapid, milliseid tööriistu saab kasutada, milles need erinevad ja kuidas neid õigesti seadistada, et vältida varjatud probleeme.

Esinejast: Yuri Shabalin - peamine turvaarhitekt ettevõttes Swordfish Security. Vastutab SSDL-i rakendamise eest, samuti rakenduste analüüsi tööriistade üldise integreerimise eest arenduse ja testimise ökosüsteemi. 7-aastane kogemus infotehnoloogia valdkonnas. Töötanud Alfa-Bankis, Sberbankis ja Positive Technologies, mis arendab tarkvara ja pakub teenuseid. Esineja rahvusvahelistel konverentsidel ZerONights, PHDays, RISSPA, OWASP.

Rakenduse turvalisus: millest see räägib?

Rakenduse turvalisus on julgeoleku osa, mis vastutab rakenduste turvalisuse eest. See ei seondu infrastruktuuri või võrgu turvalisuse, vaid just sellega, mida me kirjutame ja millega arendajad töötavad - see on rakenduse puudused ja haavatavused.

Suundumus SDL või SDLC — Turvalise arenduse elutsükkel on välja töötatud Microsofti poolt. Skeemil - kanoniline mudel SDLC, mille peamine ülesanne on tagada turvalisuse osalemine arenduse igas etapis, nõuetest kuni väljaandmise ja tootmisse viimiseni. Microsoft mõistis, et tööstuses on liiga palju vigu, nende arv kasvab ja midagi tuleb sellega teha, ning pakkus välja selle lähenemise, mis sai kanoniliseks.

Rakenduse turvalisus ja SSDL ei keskendu haavatavuste avastamisele, nagu sageli arvatakse, vaid nende tekkimise ennetamisele. Aja jooksul on Microsofti kanonilist lähenemist täiustatud, arendatud ja see on saanud sügavamale sisule suunatud lähenemise.

Kanoniline SDLC on detailne mitmes erinevas metodoloogias - OpenSAMM, BSIMM, OWASP. Metodoloogiad erinevad, kuid üldiselt on nad sarnased.

Turvalisuse integreerimise küpsusmodell

Mulle meeldib kõige rohkem BSIMM — Turvalisuse integreerimise küpsusmodell. Metodoloogia aluseks on rakenduse turvalisuse protsessi jagamine neljaks valdkonnaks: juhtimine, intel, SSDL puutepunktid ja juurutamine. Igas valdkonnas on 12 praktikat, mis esitatakse 112 tegevusena.

Igal 112 tegevusel on 3 küpsuse taset: algtaseme, kesktaseme ja arenenud. Kõiki 12 praktikat saab uurida ja jagada osadeks, valida teile olulised asjad, mõista, kuidas neid rakendada ja järk-järgult lisada elemente, nagu staatiline ja dünaamiline koodi analüüs või koodi ülevaatus. Koostate plaani ja töötate selle alusel rahulikult valitud tegevuste rakendamisel.

Miks DevSecOps

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

Alguses DevOps ikutati turvalisuse kontrolli. Praktikas oli turvameeskondade arv palju väiksem kui praegu ning nad ei osalenud protsessis, vaid tegutsesid kontrolli- ja järelevalveorganina, kes esitas nõudeid ja kontrollis toote kvaliteeti väljaande lõpus. See on klassikaline lähenemine, kus turvameeskonnad on arendusest eraldi ja ei osale protsessis.

Peamine probleem ongi see, et infosüsteemide turvalisus on eraldi arendusest. Tavaliselt on see mingi turvalisuse kontuur ja seal on 2-3 suurt ja kallist tööriista. Kord kuue kuu jooksul saabub lähtekood või rakendus, mida tuleb kontrollida, ja kord aastas viiakse läbi pentsest. See kõik toob kaasa pikad toote turuletoomise ajad, samuti paisatakse arendajatele tohutu hulk haavatavusi automatiseeritud tööriistadest. Kõike seda on võimatu mõista ja parandada, kuna eelmine poolaasta ei ole tulemusi veel analüüsitud, samal ajal kui nüüd on kohale jõudnud uus partii.

Oma ettevõtte töö käigus näeme, et turvalisus kõikides valdkondades ja tööstusharudes mõistab, et on aeg edasi liikuda ja arendamisega ühes rütmis töötada - ja Agile. DevSecOps paradigma sobib suurepäraselt paindliku arenduse metodoloogia, rakendamise, toetamise ja iga väljaande ja iteratsiooni osalemise juurde.

Üleminek DevSecOps-ile

Kõige olulisem sõna turvalisuse arenduse elutsüklis on "protsess"Te peate seda mõistma, enne kui mõtlete tööriistade ostmisele.

Lihtsalt tööriistade kaasamine DevOps-protsessi ei piisa - oluline on koostöö ja arusaamine protsessi osaliste vahel.

Olulisemad on inimesed, mitte tööriistad.

Tihti algab ohutu arendamise protsessi planeerimine tööriista valimise ja ostmisega ning lõpeb katsedintegreerimisega olemasolevasse protsessi, mis jääb sageli katseteks. See toob kaasa kurvad tagajärjed, sest igal tööriistal on oma omadused ja piirangud.

Levinud olukord on see, et turvameeskond valib hea, kalli tööriista, millel on laiad võimalused, ja tulevad arendajate juurde - integreerima protsessi. Aga see ei toimi - protsess on üles ehitatud nii, et juba ostetud tööriista piirangud ei sobi olemasolevasse paradigmasse.

Alustage tulemuse kirjeldusega, mida soovite, ja kuidas protsess välja näeb. See aitab mõista tööriista ja turvalisuse rolle protsessis.

Alustage sellest, mida juba kasutatakse.

Enne kallite tööriistade ostmist vaadake, mis teil juba olemas on. Igas ettevõttes on arendusele esitatavad turvanõuded, on kontrolle, penteste - miks mitte muuta see kõik arusaadavaks ja kõigile mugavaks?

Tavaliselt on nõuded paberil, mis seisab riiulis. Oli juhtum, kui tulime ettevõttesse, et vaadata protsesse ja palusime näidata turvanõudeid tarkvara suhtes. Spetsialist, kes sellega tegeles, otsis pikka aega:

— Praegu, kuskil märkmete seas oli tee, kus see dokument asub.

Lõpuks saime dokumendi nädala pärast.

Nõuete, kontrolle ja muud jaoks looge leht, näiteks Confluence — see on kõigile mugav.

Lihtsam on olemasolevat ümber vormistada ja kasutada alustamiseks.

Kasutage Security Champions'i.

Tavaliselt on keskmises ettevõttes 100-200 arendaja kohta üks turvaexpert, kes täidab mitu funktsiooni ja füüsiliselt ei suuda kõike kontrollida. Isegi kui ta pingutab, ei saa ta üksi kontrollida kogu koodi, mida arendamine genereerib. Selliste juhtumite jaoks on välja töötatud kontseptsioon - Security Champions..

Security Champions on isik, kes on arendusmeeskonnas ja kellel on huvi teie toote turvalisuse vastu.

Security Champion on sisene punkt arendusmeeskonda ja turvalisuse evangelist ühes isikus.

Tavaliselt, kui turvakonsultant tuleb arendusmeeskonda ja osutab vea eest koodis, saab ta üllatunud vastuse:

— Kes siis olete? Näen teid esmakordselt. Minul on kõik hästi — mu vanem kolleeg pani koodikontrolli käskluse "rakenda", me liigume edasi!

See on tüüpiline olukord, sest vanemaid või lihtsalt kolleege, kellega arendaja pidevalt tööalaselt koos suhtleb ja koodikontrollis usaldab, usaldatakse oluliselt rohkem. Kui Security Champion osutab veale ja selle tagajärgedele, on tema sõnal rohkem kaalu.

Samuti tunnevad arendajad oma koodi paremini kui ükski turvakonsultant. Inimene, kellel on vähemalt 5 projekti staatilise analüüsi tööriistas, leiab tavaliselt, et on keeruline meeles pidada kõiki nüansse. Security Champions tunnevad oma toodet: mis millega suhtleb ja millele jälgida esmakordselt — nad on tõhusamad.

Nii et mõelge Security Champions'i rakendamisele ja turvameeskonna mõju suurendamisele. Isegi Championile on see kasulik: professionaalne areng uues valdkonnas, tehnilise silmaringi laienemine, tehniliste, juhtimis- ja juhtimisoskuste arendamine, turuväärtuse tõus. See on mingi sotsiaalse inseneeria element, teie "silmad" arendusmeeskonnas.

Testimise etapid

Paradiigma 20 kuni 80 ütleb, et 20% pingutustest toob 80% tulemusi. Need 20% on rakenduste analüüsi praktikad, mida saab ja tuleks automatiseerida. Selliste tegevuste näideteks on staatiline analüüs — SAST, dünaamiline analüüs — DAST, ja Open Source'i kontrollimine. Räägin lähemalt tegevustest ning tööriistadest, millega tavaliselt kokku puutume nende rakendamisel protsessi, ja kuidas seda õigesti teha.

Peamised tööriistade probleemid

Toon välja kõikide tööriistade jaoks olulised probleemid, mis vajavad tähelepanu. Selgitan neid lähemalt, et mitte edaspidi korduda.

Pikaajaline analüüs. Kui kommitamisest kuni tootmisse jõudmiseni kulub kõikide testide ja koostamise jaoks 30 minutit, siis infokaitse kontrolld sobib võtma terve päeva. Keegi ei soovi protsessi pidurdada. Arvestage seda iseärasust ja tehke järeldusi.

Kõrgem False Negative või False Positive tase. Kõik tooted on erinevad, kõik kasutavad erinevaid raamistikku ja kodeerimisstiili. Erinevatel koodibaasidel ja tehnoloogiatel võivad tööriistad näidata erinevat False Negative ja False Positive taset. Seetõttu vaadake, mis täpselt teie ettevõttes ja teie rakendustes toob hea ja usaldusväärse tulemuse.

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

Kohandamise puudumine või liigse keerukuse olemasolu. Kui tööriistal ei ole API-d, siis miks see vajalik on? Kõik, mis on tehtav liideses, peaks olema kergesti ligipääsetav API kaudu. Ideaalis peaks tööriistal olema võimalus kontrolle kohandada.

Toote arendusplaani puudumine. Arendus ei seisa paigal, me kasutame alati uusi raamistikku ja funktsioone, kirjutame vana koodi uute keeltega ümber. Soovime olla kindlad, et tööriist, mille me ostame, toetab uusi raamistikku ja tehnoloogiaid. Seetõttu on oluline teada, et tootel on tegelik ja õige Teekond arendustegevus.

Protsessi eripärad

Lisaks tööriistadele arvestage ka arendusprotsessi eripäradega. Näiteks arenduse segamine on tüüpiline viga. Vaatame, milliseid teisi eripärasid tuleks arvesse võtta ja millele turvameeskond peaks tähelepanu pöörama.

Kuna arenduse ja väljalaskmise tähtaegu ei tohiks rikkuda, looge eraldi reeglid ja erinevad show stoppers — kriteeriumid, mis peatavad koostamisprotsessi, kui avastatakse haavatavusi — erinevates keskkondades. Näiteks, me mõistame, et praegune haru läheb arendajate stendile või UAT-le, mistõttu me ei peata ega ütle:

— Teil on siin haavatavused, te ei saa edasi minna!

Sel etapil on oluline öelda arendajatele, et on turvaprobleeme, millele tuleks tähelepanu pöörata.

Haavat ei ole takistus edasisele testimisele: käsitsi, integreeritud või manuaalselt. Teisalt peame kuidagi toote turvalisust parandama ning et arendajad ei ignoreeriks turbe leidmisi. Seetõttu toimime mõnikord nii: stendil, kui see välja lastakse arenduskeskkonda, teavitame arendust:

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

UAT etapis anname taas hoiatustest teada, ja produktsiooni etapis ütlemme:

— Poisid, oleme mitu korda hoiatatud, te ei teinud midagi — sellega ei lase teid välja.

Kui rääkida koodist ja dünaamikast, siis tuleb näidata ja hoiatada haavatavustest ainult nende funktsioonide ja koodi osas, mis on just selles funktsioonis kirjutatud. Kui arendaja liigutab nuppu 3 pikslit ning me ütleme talle, et tal on seal SQL-injektsioon ja seetõttu peab ta kiirelt parandama — see on vale. Vaadake ainult seda, mis on praegu kirjutatud, ja sellele muudatusele, mis rakendusse tuleb.

Oletame, et meil on mingi funktsionaalne defekt — see, kuidas rakendus ei peaks töötama: raha ei edastata, nuppu klõpsates ei toimu üleminekut järgmisele lehele või kaupa ei laadita. Turvadefektid — need on samasugused defektid, kuid mitte rakenduse töö kontekstis, vaid turvalisuse osas.

Kauem ei ole kõik tarkvarakvaliteedi probleemid turbeprobleemid. Kuid kõik turbeprobleemid on seotud tarkvarakvaliteediga. Sherif Mansour, Expedia.

Kuna kõik haavatavused on samasugused defektid, peaksid nad olema seal, kus on kõik arendusvead. Seetõttu unustage aruanded ja hirmutavad PDF-d, mida keegi ei loe.

Kui töötasin ettevõttes, mis tegeleb arendamisega, sain aruande staatiliste analüüsivahendite kaudu. Avasin selle, ehmatasin ära, keetsin kohvi, sirvisin 350 lehte, sulgesin selle ja läksin edasi tööle. Suured aruanded on surnud aruanded. Üldiselt need ei kao kuhugi, kirjad kustutatakse, unustatakse, kaotatakse või äri ütleb, et võtab riskid.

Mida teha? Tuvastatud vead, mis leiti, muudame lihtsalt arendamiseks sobivaks näiteks, kogudes need backlogs Jira-s. Prioriseerime vead ja lahendame need prioriteedi järjekorras koos funktsionaalsete vigade ja testide vigadega.

Statiline analüüs — SAST

See on koodi analüüs haavatavuste olemasolu osas, kuid see ei ole sama, mis SonarQube. Kontrollime mitte ainult mustrite või stiili järgi. Analüüsi käigus rakendatakse mitmeid lähenemisviise: haavatavuste puu järgi, alusel DataFlow, konfigureerimisfailide analüüsi järgi. See on kõik, mis puudutab otse koodi.

Lähenemise plussid: haavatavuste tuvastamine koodis arenduse varajases etapis, kui pole veel stende ja valmis tööriista ning võimalus inkrementaalseks skaneerimiseks: koodi osa skaneerimine, mis on muutunud, ja ainult seda funktsiooni, mida me praegu teeme, mis vähendab skaneerimise aega.

Miinused — vajalikke keelte toe puudumine.

Vajadusel integreerimised, mida peaks olema tööriistades, minu subjektiivne arvamus:

• Integreerimistööriist: Jenkins, TeamCity ja Gitlab CI.
• Arenduskeskkond: Intellij IDEA, Visual Studio. Arendajal on mugavam mitte liialdada arusaamatu liidese juurde, mida tuleb veel mäletada, vaid näha otse oma arenduskeskkonnas kõiki vajalikke integratsioone ja haavatavusi, mida ta leidis.
• Koodi ülevaatus: SonarQube ja käsitsi ülevaatus.
• Vea jälgimise süsteemid: Jira ja Bugzilla.

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

Olulised ei ole tööriistad, vaid protsess, seetõttu on olemas avatud lähtekoodiga lahendused, mis on samuti head protsessi katsetamiseks.

SAST avatud lähtekoodiga lahendused ei leia suurt hulka haavatavusi või keerulisi DataFlow, kuid protsessi ülesehitamisel saab ja tuleb neid kasutada. Need aitavad mõista, kuidas protsess üles ehitatakse, kes vastutab vigade eest, kes need raporteerib ja kes aru annab. Kui soovite teha esimest sammu oma koodi turvalisuse ülesehitamiseks — kasutage avatud lähtekoodiga lahendusi.

Kuidas seda integreerida, kui olete alguses, teil pole midagi: ei CI, ei Jenkinsit, ei TeamCityt? Vaadakem integratsioone protsessis.

Integratsioon CVS tasemel

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

Sündmuse põhjal — pull request, commit. Te skaneerit koodi ja build'i olekus näitate, kas turvakontroll on läbitud või mitte.

Tagasiside. Ilmselt on tagasiside alati vajalik. Kui te lihtsalt tegite turvapoolel töö ära, panite selle kasti ja ei rääkinud sellest kellelegi, ning siis kuu lõpus tulite välja hulga vigadega — see ei ole õige ega hea.

Integratsioon koodivaatamise süsteemiga

Kord määrasime mitmes olulises projektis vaikimisi ülevaataja tehnilise kasutaja AppSec. Sõltuvalt sellest, kas uues koodis avastatakse vigu või ei, määrab pull request’i ülevaataja staatusena „accept“ või „need work“ — kas kõik on OK või tuleb midagi täiendada ja viidet sellele, mida täpselt täiendada. Integreerimisel versiooniga, mis läheb tootmisse, keelasime me merge'i, kui turvatest ei ole läbitud. Me lülitasime selle sisse käsitsi koodivaatamises ja ülejäänud protsessi osalised nägid turbe staatuseid just selle konkreetse protsessi jaoks.

Integratsioon SonarQube'iga

Paljusid huvitab quality gate koodi kvaliteedi osas. Siin on sama — saab teha samu gates'e ka SAST-ide jaoks. Graafika jääb samaks, sama quality gate, lihtsalt nimeks saab see security gate. Ja sama ka, kui teil on käivitatud protsess SonarQube'iga, saab kõik rahulikult sinna integreerida.

Integreerimine CI tasemel

Siin on kõik piisavalt lihtne:

• Ühes tasemes automaatsete testide, unit-testide.
• Arendusetappide eristamine: dev, test, prod. Võib kaasata erinevaid reegliste komplekte või erinevaid tõrke tingimusi: peatame kogumise, ei peata kogumist.
• Sünkroonne/Asünkroonne kä запуск. Ootame turvatestide kontrollimise lõppu või ei oota. Ehk me lihtsalt käivitame need ja liigume edasi, ning seejärel saame staatuse, et kõik on hästi või halvasti.

See kõik on ideaalses roosilises maailmas. Reaalses elus seda ei juhtu, aga me püüame. Turvakontrollide tulemused peaksid olema sarnased unit-testide tulemustele.

Näiteks, me võtsime suure projekti ja otsustasime, et skaneerime seda SAST’iga — OK. Panime projekti SAST-i, see andis meile 20 000 haavatavust ja me võtsime jõuliselt vastu otsuse, et kõik on hästi. 20 000 haavatavust — see on meie tehniline võlg. Paneme võla karpi, hakkame tasapisi koristama ja loome vead defektide jälgimisse. Kindlasti palkame ettevõtte, teeme kõik ise või aitame Security Champions — ja tehniline võlg hakkab vähenema.

Ja kõik uued haavatavused uues koodis peavad olema kõrvaldatud nagu üldised vead unit või automatiseeritud testides. Ütlemiseks, käivitus kogu koostamine, jooksime, kukkus kaks testi ja kaks testi turvalisuse osas. OK — läksime, vaatasime, mis juhtus, parandasime ühte, parandasime teist, järgmine kord jooksime — kõik on hästi, uusi haavatavusi ei ilmunud, testid ei kukkunud läbi. Kui see ülesanne on sügavam ja vajab head arusaamist või haavatavuste parandamine hõlmab suuri osi mingist, mis asub kapoti all: loome vea defektide jälgimisse, see prioriseeritakse ja parandatakse. Kahjuks maailm ei ole ideaalne ja testid mõnikord kukuvad.

Turvavärava näide — sarnane kvaliteediväravale, seoses ebaõnnestumiste arvu ja olemasoluga koodis.

Integreerime SonarQube'iga — plugin paigaldatakse, kõik on väga mugav ja lahe.

Integreerimine arenduskeskkonnaga

Integreerimise võimalused:

• Külastage skaneerimist arenduskeskkonnast veel enne commit'i.
• Tulemuste ülevaade.
• Tulemuste analüüs.
• Sünkroonimine serveriga.

Nii näeb välja tulemuste saamine serverilt.

Meie arenduskeskkonnas Intellij IDEA ilmub lihtsalt lisateenus, mis teatab, et skaneerimise ajal avastati sellised haavatavused. Saame kohe koodi parandada, vaadata soovitusi ja Protsessikaart. See kõik on arendaja töökohas, mis on väga mugav — ei ole vaja ringi jalutada ja vaadata midagi lisaks.

Open Source

See on minu lemmikteema. Kõik kasutavad Open Source teeke — miks kirjutada hunnik klotse ja jalgrattaid, kui on võimalik võtta valmis teek, kus kõik on juba realiseeritud?

Jah, see on tõsi, kuid raamatukogud on samuti inimeste kirjutatud, need sisaldavad teatud riske ja seal esinevad haavad, millest perioodiliselt või pidevalt teatatakse. Seetõttu on järgmine samm rakendusturbe valdkonnas avatud lähtekoodiga komponentide analüüs.

Avatud lähtekoodiga analüüs – OSA

Tööriist sisaldab kolme suurt etappi.

Haavatavuste ülesleidmine raamatukogudes. Näiteks teab tööriist, et me kasutame mingit raamatukogu ja et CVE või veatöötlusplatvormidel on mingeid haavatavusi, mis puudutavad selle versiooni raamatukogu. Kui proovid seda kasutada, annab tööriist hoiatuse, et raamatukogu on haavatav ning soovitab kasutada teist versiooni, kus haavatavused puuduvad.

Litsentsi puhtuse analüüs. Küsimus pole veel eriti populaarne, kuid kui töötate rahvusvaheliselt, võib seal aeg-ajalt tulla probleem kasutatava avatud lähtekoodiga komponendiga, mida ei tohi kasutada või modifitseerida. Vastavalt raamatukogu litsentsipoliitikale ei tohi me seda teha. Kas kui me oleme seda modifitseerinud ja kasutame, peame oma koodi esitama. Loomulikult ei taha keegi oma toote koodi avalikustada, kuid sellest saab samuti kaitsta.

Komponentide analüüs, mida kasutatakse tööstuslikus keskkonnas. Kujutage ette hüpoteetilist olukorda, kus oleme lõpuks arenduse lõpetanud ja välja lasknud meie mikroteenuse viimase versiooni. See töötab seal suurepäraselt - nädala, kuu, aasta. Me ei kogu selle kohta teavet, turvataset ei kontrolli, kõik tundub hästi. Kuid äkki, kaks nädalat pärast väljaandmist, ilmub tööstuskeskkonnas haavatavus avatud lähtekoodiga komponendis, mida me just selles versioonis kasutame. Kui me ei dokumenteeri, mida ja kus me kasutame, siis ei näe me seda haavatavust. Mõned tööriistad võimaldavad raamatukogude haavatavuste jälgimist, mis praegu tööstuses on kasutusel. See on väga kasulik.

Võimalused:

• Erinevad poliitikad erinevatele arendusetappidele.
• Komponentide jälgimine tööstuslikus keskkonnas.
• Teekide kontroll organisatsiooni raames.
• Erinevate kogumise süsteemide ja keelte tugi.
• Dockeri picturite analüüs.

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

Ainus neist tasuta on Sõltuvuste kontroll OWASP-i poolt. Seda saab esimestel etappidel sisse lülitada, et näha, kuidas see töötab ja mida see toetab. Peamiselt on need kõik pilve tooted või kohapealsed, kuid nende baasil saadetakse need ikkagi internetti. Need saadavad mitte teie raamatukogusid, vaid räsimärke või oma arvutatud väärtusi ning sõrmejälgi oma serverisse, et saada teavet haavatavuste olemasolu kohta.

Integratsioon protsessi

Kontrolli teeki perimeetrisse, mis allalaaditakse välistest allikatest. Meil on väline ja sise repos. Näiteks Event Centralis on Nexus ja me tahame, et meie repos ei oleks haavatavusi, mille staatus on "kriitiline" või "kõrge". Proximist saab seadistada Nexus Firewall Lifecyle'i tööriistaga nii, et sellised haavatavused blokeeritakse ja ei pääse siserepositorisse.

Integratsioon CI-sse. Samal tasemel koos automaatsete testide, üksuste testide ja arendusetappide jagamisega: dev, test, prod. Igal etapil saab alla laadida mis tahes raamatukogusid ja kasutada kõike, kuid kui seal on midagi tõsist, mille staatus on "kriitiline", siis võib-olla tasub sellele arendajate tähelepanu juhtida, kui aga projekteerimisetapis.

Integratsioon artefaktide hoidlatega: Nexus ja JFrog.

Integratsioon arenduskeskkonda. Tööriistad, mida valite, peavad olema integreeritavad arenduskeskkondadega. Arendajal peab olema oma töökohtadelt juurdepääs skaneerimise tulemustele või võimalus ise skaneerida ja kontrollida koodi haavatavuste olemasolu enne CVS-sse commitimist.

Integratsioon CD-sse. See on lahe funktsioon, mis mulle väga meeldib ja millest ma juba rääkinud olen – haavatavuste uute ilmingute jälgimine tööstuskeskkonnas. See töötab umbes nii.

Meil on Avalikud koostisosade hoidlad — mõned tööriistad väljast ja meie sisemine hoidla. Soovime, et seal oleksid ainult usaldusväärsed koostisosad. Küsimuste nõudmisel kontrollime, et allalaaditavas teegis ei esineks haavatavusi. Kui see kuulub teatud poliitikate alla, mille me seame ja peame arendusega kokku leppima, siis ei lae me seda alla ja tuleb teade, et tuleb kasutada teist versiooni. Seega, kui teegis on midagi tõeliselt kriitilist ja halba, ei saa arendaja juba installimise etapis seda teeki — las kasutab kas vanemat või uuemat versiooni.

• Buildimise ajal kontrollime, et keegi ei oleks sisse suunanud midagi halba, et kõik koostisosad on ohutud ja keegi ei tooma ohutust midagi USB-mälupulgal.
• Meie hoidlas on ainult usaldusväärsed koostisosad.
• Deployment'i käigus kontrollime veel kord täpselt paketti: war, jar, DL või Docker-pildid selle üle, et need vastavad poliitikale.
• Tootmisrežiimis jälgime, mis toimub tööstuskeskkonnas: ilmuvad või ei ilmu kriitilised haavatavused.

Dünaamiline analüüs — DAST

Dünaamilise analüüsi tööriistad erinevad radikaalselt kõikidest eelnevalt öeldud asjadest. See on mingi simulatsioon kasutaja tegevusest rakenduse juures. Kui see on veebirakendus, saadame päringud, simuleerides kliendi tööd, vajutame nuppe veebilehe ees, saadame kunstlikke andmeid vormist: jutumärgid, sulud, sümbolid erinevates kodeeringutes, et vaadata, kuidas rakendus töötab ja töötleb väliseid andmeid.

Sama süsteem võimaldab kontrollida mallihäireid avatud lähtekoodis. Kuna DAST ei tea, millist avatud lähtekoodi me kasutame, siis viskab ta lihtsalt "pahalaste" mustrid ja analüüsib serveri vastuseid:

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

Selles on suured riskid, sest kui teete seda turvatesti samal keskkonnal, millega töötavad testijad — võivad juhtuda ebameeldivad asjad.

• Suurekoormus rakenduse serverivõrgus.
• Pole integratsioone.
• Võimalus muuta analüüsitava rakenduse seadeid.
• Ei toetata vajalikke tehnoloogiaid.
• Seadistamise keerukus.

Meil oli olukord, kui saime lõpuks AppScan'i tööle: pidasime kaua ligipääsu taotlema, saime 3 kontot ja olime rõõmsad – lõpuks saame kõik ära kontrollida! Käivitasime skaneerimise ja esimene asi, mida AppScan tegi, oli administratiivpaneelile sisse logimine, kõik nupud üle testa, pool andmeid ümber muuta ja lõpuks tappis serveri. mailform-päringutega. Arendamine koos testimisega ütles:

— Poisid, te teete nalja?! Me andsime teile kontod, aga teie panite püsti katsekeskkonna!

Arvestage võimalikke riske. Ideaalis valmistage ette eraldi katsekeskkond, mis on teistest keskkondadest mingil moel isoleeritud ja administratiivpaneeli kontrollimine peaks olema soovitatavalt käsitsi. See on penetratsioonitest – need viimased protsendid pingutust, mida me praegu ei arvesse võta.

Tasub arvestada, et seda saab kasutada ka koormustestimise analoogina. Esimeses etapis on võimalik aktiveerida dünaamiline skanner 10-15 voogude jaoks ja vaadata, mis juhtub, kuid tavaliselt, nagu praktika näitab, pole tulemused head.

Mõned ressursid, mida tavaliselt kasutame.

Tasub välja tuua Burp Suite — see on "Šveitsi armee nuga" igasugustele turvaekspertidele. Kõik kasutavad seda ja see on väga mugav. Praegu on välja tulnud uus demo versioon ettevõtte väljaandest. Kui varem oli see lihtsalt iseseisev utiliit pluginate kogumiga, siis nüüd teevad arendajad lõpuks suurt serverit, millest saab hallata mitmeid agente. See on äge, soovitan proovida.

Integratsioon protsessi

Integratsioon toimub piisavalt hästi ja lihtsalt: skaneerimise käivitamine peale eduka rakenduse installatsiooni katse keskkonnale ja skaneerimine pärast eduka integreerimise testimise läbiviimist.

Kui integratsioonid ei tööta või seal on vahepealsed ja mock-funktsioonid, on see mõttetu ja kasutu – ükskõik millise mustriga me ka ei saadaks, server vastab ikkagi ühtemoodi.

• Ideaalne – eraldiseisev katse keskkond.
• Enne testimise alustamist taotlege sisselogimise jada.
• Administratiiv süsteemi testimine – ainult manuaalne.

Protsess

Veidi üldiselt protsessi kohta ja iga tööriista kohta eraldi. Kõik rakendused on erinevad – ühel töötab dünaamiline analüüs paremini, teisel staatiline, kolmandal OpenSource analüüs, penetratsioonitestid või tegelikult midagi muud, näiteks sündmused. Waf.

Iga protsess vajab kontrolli.

Et mõista, kuidas protsess töötab ja kus seda saab parandada, tuleb koguda mõõdikud igalt poolt, kuhu käsi ulatub, sealhulgas tootmisnäitajad, instrumentide mõõdikud ja veaparandus süsteemidest.

Iga andmed on kasulikud. Tuleb vaadata erinevates lõikes, kus üks või teine tööriist paremini töötab, kus protsess konkreetselt langeb. Võib-olla tasub vaadata arenduse vastamisaja, et mõista, kus protsessi ajas parandada. Mida rohkem andmeid, seda rohkem lõike saab ehitada alates kõrgematest tasemetest kuni iga protsessi üksikasjadeni.

Kuna kõigil staatilistel ja dünaamilistel analüsaatoritel on oma API-d, käivitamisviisid, põhimõtted, mõnel on ajakavad ja teistel mitte — me kirjutame tööriista AppSec Orkestrator, mis võimaldab luua ühtse sisendi kogu protsessi jooksul ja hallata seda ühest kohast.

Juhtidel, arendajatel ja turbeinseneridel on üks sisend, kust saab vaadata, mis on käivitatud, seada üles ja alustada skaneerimist, saada skaneerimise tulemusi ja esitada nõudeid. Püüame liikuda paberitelt ära ja viia kõik inimkeelde, mida arendus kasutab — lehed Confluence'is staatuste ja mõõdikutega, vead Jira's või erinevates veaparandus süsteemides, või integreerida sünkroonsesse/ asünkroonsesse protsessi CI/CD-s.

Peamised punktid

Tööriistad ei ole peamine. Esmalt mõelge protsess läbi — seejärel leidke tööriistu. Tööriistad on head, kuid kallid, seega võiks alustada protsessist ja seada üles suhtlemise ja arusaamise arendamise ja turvalisuse vahel. Turbe seisukohalt – ei ole vaja "peatada" kõike järjest, arendus seisukohalt – kui midagi on high mega super kriitiline, siis tuleb see kõrvaldada, mitte silma kinni panna probleemile.

Toote kvaliteet — ühine eesmärk nii turvalisuse kui ka arenduse jaoks. Me teeme sama asja, püüdes, et kõik töötaks õigesti ja et mitte tekiks maineohtusid ja rahalisi kaotusi. Just seetõttu propageerime DevSecOps'i, SecDevOps'i lähenemist, et luua suhtlus ja teha toode kvaliteetsemaks.

Alustage sellest, mis juba olemas on: nõudmised, arhitektuur, osalised kontrollid, koolitused, juhised. Ei ole vaja kohe rakendada kõiki praktikaid kõikidele projektidele — liikuge iteratiivselt. Ühtset standardit ei ole — katsetage ja proovige erinevaid lähenemisviise ja lahendusi.

IB defektide ja funktsionaalsete defektide vahel on samamoodi.

Automatiseerige kõik, mis liigub. Kõik, mis ei liigu — liigutage ja automatiseerige. Kui midagi tehakse käsitsi, ei ole see hea protsess. Võib-olla tasuks see üle vaadata ja ka automatiseerida.

Kui IB meeskond on väike — kasutage Security Champions.

Võib-olla ei sobi see, millest ma rääkisin, teile ja te leiutate midagi oma — ja see on hea. Kuid valige tööriistad, lähtuvalt nõudmistest just teie protsessile. Ärge vaadake, mida ütleb kogukond, et see tööriist on halb ja see hea. Võib-olla osutub teie tootel kõik vastupidiseks.

Nõuded tööriistadele.

• Madala vale positiivsete tulemuste tase.
• Mõistlik analüüsi aeg.
• Kasutusmugavus.
• Integratsioonide olemasolu.
• Toote arendusteede mõistmine.
• Tööriistade kohandamise võimalus.

Jüri ettekannet valiti üheks parimaks DevOpsConf 2018. ettekandeks. Et tutvuda veel enam huvitavate ideede ja praktiliste näidetega, tulge 27. ja 28. mail Skolkovo DevOpsConf Raames festivali RIT++. Ja veel parem, kui olete valmis oma kogemust jagama, siis esitage taotlus ettekande jaoks kuni 21. aprillini.

Allikas: habr.com