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

Meil oli 2 koodianal\u00fcsaatorit, 4 d\u00fcnaamilise testimise t\u00f6\u00f6riista, oma loodud t\u00f6\u00f6riistad ja 250 skripti. Ei ole nii, et see k\u00f5ik oleks praeguses protsessis vajalik, aga kui DevSecOpsi rakendamine on juba alustatud, siis tuleb minna l\u00f5puni.<\/p>\n

\"Hirm
\n
\nAllikas<\/a><\/noindex>. Isikute autorid: Justin Roiland ja Dan Harmon.<\/i><\/p>\n

Mis on SecDevOps? Ja DevSecOps? Millised on erinevused? Rakenduse turvalisus - millest see r\u00e4\u00e4gib? Miks klassikaline l\u00e4henemine enam ei toimi? K\u00f5igile nendele k\u00fcsimustele teab vastust Yuri Shabalin<\/b> API-s\u00a0Swordfish Security. <\/b>Yuri vastab k\u00f5igile k\u00fcsimustele ja k\u00e4sitleb klassikalisest rakenduse turvalisuse mudelist DevSecOpsi protsessile \u00fclemineku probleeme: kuidas \u00f5igesti l\u00e4heneda turvalise arendamise protsessi integreerimisele DevOps-i protsessi, et mitte midagi purustada, kuidas l\u00e4bida p\u00f5hilised turvatestimise etapid, milliseid t\u00f6\u00f6riistu saab kasutada, milles need erinevad ja kuidas neid \u00f5igesti seadistada, et v\u00e4ltida varjatud probleeme.
\n<\/a><\/noindex>
\n

\r\n \"M\u00e4ngi\r\n
<\/div>\r\n <\/div><\/center>
\nEsinejast:<\/b> Yuri Shabalin - <\/b>peamine turvaarhitekt ettev\u00f5ttes Swordfish Security<\/b>. Vastutab SSDL-i rakendamise eest, samuti rakenduste anal\u00fc\u00fcsi t\u00f6\u00f6riistade \u00fcldise integreerimise eest arenduse ja testimise \u00f6kos\u00fcsteemi. 7-aastane kogemus infotehnoloogia valdkonnas. T\u00f6\u00f6tanud Alfa-Bankis, Sberbankis ja Positive Technologies, mis arendab tarkvara ja pakub teenuseid. Esineja rahvusvahelistel konverentsidel ZerONights, PHDays, RISSPA, OWASP.<\/p>\n

Rakenduse turvalisus: millest see r\u00e4\u00e4gib?<\/h2>\n

\nRakenduse turvalisus<\/b>\u00a0on julgeoleku osa, mis vastutab rakenduste turvalisuse eest. See ei seondu infrastruktuuri v\u00f5i v\u00f5rgu turvalisuse, vaid just sellega, mida me kirjutame ja millega arendajad t\u00f6\u00f6tavad - see on rakenduse puudused ja haavatavused.<\/p>\n

Suundumus SDL v\u00f5i SDLC<\/a><\/noindex>\u00a0\u2014 Turvalise arenduse eluts\u00fckkel<\/b>\u00a0on v\u00e4lja t\u00f6\u00f6tatud Microsofti poolt. Skeemil - kanoniline mudel SDLC, mille peamine \u00fclesanne on tagada turvalisuse osalemine arenduse igas etapis, n\u00f5uetest kuni v\u00e4ljaandmise ja tootmisse viimiseni. Microsoft m\u00f5istis, et t\u00f6\u00f6stuses on liiga palju vigu, nende arv kasvab ja midagi tuleb sellega teha, ning pakkus v\u00e4lja selle l\u00e4henemise, mis sai kanoniliseks.<\/p>\n

\"Hirm
\n
\nRakenduse turvalisus ja SSDL ei keskendu haavatavuste avastamisele, nagu sageli arvatakse, vaid nende tekkimise ennetamisele. Aja jooksul on Microsofti kanonilist l\u00e4henemist t\u00e4iustatud, arendatud ja see on saanud s\u00fcgavamale sisule suunatud l\u00e4henemise.<\/p>\n

\"Hirm
\n
\nKanoniline SDLC on detailne mitmes erinevas metodoloogias - OpenSAMM, BSIMM, OWASP. Metodoloogiad erinevad, kuid \u00fcldiselt on nad sarnased.<\/p>\n

Turvalisuse integreerimise k\u00fcpsusmodell<\/h3>\n

\nMulle meeldib k\u00f5ige rohkem BSIMM<\/b>\u00a0\u2014 Turvalisuse integreerimise k\u00fcpsusmodell<\/a><\/noindex>. Metodoloogia aluseks on rakenduse turvalisuse protsessi jagamine neljaks valdkonnaks: juhtimine, intel, SSDL puutepunktid ja juurutamine. Igas valdkonnas on 12 praktikat, mis esitatakse 112 tegevusena.<\/p>\n

\"Hirm
\n
\nIgal 112 tegevusel on 3 k\u00fcpsuse taset<\/b>: algtaseme, kesktaseme ja arenenud. K\u00f5iki 12 praktikat saab uurida ja jagada osadeks, valida teile olulised asjad, m\u00f5ista, kuidas neid rakendada ja j\u00e4rk-j\u00e4rgult lisada elemente, nagu staatiline ja d\u00fcnaamiline koodi anal\u00fc\u00fcs v\u00f5i koodi \u00fclevaatus. Koostate plaani ja t\u00f6\u00f6tate selle alusel rahulikult valitud tegevuste rakendamisel.<\/p>\n

Miks DevSecOps<\/h2>\n

<\/p>\n

DevOps on suur \u00fcldine protsess, kus tuleb hoolitseda turvalisuse eest.<\/p><\/blockquote>\n

\nAlguses DevOps<\/b><\/a><\/noindex> ikutati turvalisuse kontrolli. Praktikas oli turvameeskondade arv palju v\u00e4iksem kui praegu ning nad ei osalenud protsessis, vaid tegutsesid kontrolli- ja j\u00e4relevalveorganina, kes esitas n\u00f5udeid ja kontrollis toote kvaliteeti v\u00e4ljaande l\u00f5pus. See on klassikaline l\u00e4henemine, kus turvameeskonnad on arendusest eraldi ja ei osale protsessis.<\/p>\n

\"Hirm
\n
\nPeamine probleem ongi see, et infos\u00fcsteemide turvalisus on eraldi arendusest. Tavaliselt on see mingi turvalisuse kontuur ja seal on 2-3 suurt ja kallist t\u00f6\u00f6riista. Kord kuue kuu jooksul saabub l\u00e4htekood v\u00f5i rakendus, mida tuleb kontrollida, ja kord aastas viiakse l\u00e4bi pentsest<\/a><\/noindex>. See k\u00f5ik toob kaasa pikad toote turuletoomise ajad, samuti paisatakse arendajatele tohutu hulk haavatavusi automatiseeritud t\u00f6\u00f6riistadest. K\u00f5ike seda on v\u00f5imatu m\u00f5ista ja parandada, kuna eelmine poolaasta ei ole tulemusi veel anal\u00fc\u00fcsitud, samal ajal kui n\u00fc\u00fcd on kohale j\u00f5udnud uus partii.<\/p>\n

Oma ettev\u00f5tte t\u00f6\u00f6 k\u00e4igus n\u00e4eme, et turvalisus k\u00f5ikides valdkondades ja t\u00f6\u00f6stusharudes m\u00f5istab, et on aeg edasi liikuda ja arendamisega \u00fches r\u00fctmis t\u00f6\u00f6tada - ja\u00a0Agile<\/b><\/a><\/noindex>. DevSecOps paradigma sobib suurep\u00e4raselt paindliku arenduse metodoloogia, rakendamise, toetamise ja iga v\u00e4ljaande ja iteratsiooni osalemise juurde.<\/p>\n

\"Hirm
\n<\/p>\n

\u00dcleminek DevSecOps-ile<\/h2>\n

\nK\u00f5ige olulisem s\u00f5na turvalisuse arenduse eluts\u00fcklis on \"protsess\"<\/b>Te peate seda m\u00f5istma, enne kui m\u00f5tlete t\u00f6\u00f6riistade ostmisele.<\/p>\n

Lihtsalt t\u00f6\u00f6riistade kaasamine DevOps-protsessi ei piisa - oluline on koost\u00f6\u00f6 ja arusaamine protsessi osaliste vahel.<\/p><\/blockquote>\n

<\/p>\n

Olulisemad on inimesed, mitte t\u00f6\u00f6riistad.<\/h3>\n

\nTihti algab ohutu arendamise protsessi planeerimine t\u00f6\u00f6riista valimise ja ostmisega ning l\u00f5peb katsedintegreerimisega olemasolevasse protsessi, mis j\u00e4\u00e4b sageli katseteks. See toob kaasa kurvad tagaj\u00e4rjed, sest igal t\u00f6\u00f6riistal on oma omadused ja piirangud.<\/p>\n

Levinud olukord on see, et turvameeskond valib hea, kalli t\u00f6\u00f6riista, millel on laiad v\u00f5imalused, ja tulevad arendajate juurde - integreerima protsessi. Aga see ei toimi - protsess on \u00fcles ehitatud nii, et juba ostetud t\u00f6\u00f6riista piirangud ei sobi olemasolevasse paradigmasse.<\/p>\n

Alustage tulemuse kirjeldusega, mida soovite, ja kuidas protsess v\u00e4lja n\u00e4eb. See aitab m\u00f5ista t\u00f6\u00f6riista ja turvalisuse rolle protsessis.<\/p><\/blockquote>\n

<\/p>\n

Alustage sellest, mida juba kasutatakse.<\/h3>\n

\nEnne kallite t\u00f6\u00f6riistade ostmist vaadake, mis teil juba olemas on. Igas ettev\u00f5ttes on arendusele esitatavad turvan\u00f5uded, on kontrolle, penteste - miks mitte muuta see k\u00f5ik arusaadavaks ja k\u00f5igile mugavaks?<\/p>\n

Tavaliselt on n\u00f5uded paberil, mis seisab riiulis. Oli juhtum, kui tulime ettev\u00f5ttesse, et vaadata protsesse ja palusime n\u00e4idata turvan\u00f5udeid tarkvara suhtes. Spetsialist, kes sellega tegeles, otsis pikka aega:<\/p>\n

\u2014 Praegu, kuskil m\u00e4rkmete seas oli tee, kus see dokument asub.<\/i><\/p>\n

L\u00f5puks saime dokumendi n\u00e4dala p\u00e4rast.<\/p>\n

N\u00f5uete, kontrolle ja muud jaoks looge leht, n\u00e4iteks\u00a0Confluence<\/b>\u00a0\u2014 see on k\u00f5igile mugav.<\/p>\n

Lihtsam on olemasolevat \u00fcmber vormistada ja kasutada alustamiseks.<\/p><\/blockquote>\n

<\/p>\n

Kasutage Security Champions'i. <\/h3>\n

\nTavaliselt on keskmises ettev\u00f5ttes 100-200 arendaja kohta \u00fcks turvaexpert, kes t\u00e4idab mitu funktsiooni ja f\u00fc\u00fcsiliselt ei suuda k\u00f5ike kontrollida. Isegi kui ta pingutab, ei saa ta \u00fcksi kontrollida kogu koodi, mida arendamine genereerib. Selliste juhtumite jaoks on v\u00e4lja t\u00f6\u00f6tatud kontseptsioon - Security Champions.<\/b><\/a><\/noindex>.<\/p>\n

Security Champions on isik, kes on arendusmeeskonnas ja kellel on huvi teie toote turvalisuse vastu.<\/p><\/blockquote>\n

\"Hirm
\n
\nSecurity Champion on sisene punkt arendusmeeskonda ja turvalisuse evangelist \u00fches isikus.<\/p>\n

Tavaliselt, kui turvakonsultant tuleb arendusmeeskonda ja osutab vea eest koodis, saab ta \u00fcllatunud vastuse:<\/p>\n

\u2014 Kes siis olete? N\u00e4en teid esmakordselt. Minul on k\u00f5ik h\u00e4sti \u2014 mu vanem kolleeg pani koodikontrolli k\u00e4skluse \"rakenda\", me liigume edasi!<\/i><\/p>\n

See on t\u00fc\u00fcpiline olukord, sest vanemaid v\u00f5i lihtsalt kolleege, kellega arendaja pidevalt t\u00f6\u00f6alaselt koos suhtleb ja koodikontrollis usaldab, usaldatakse oluliselt rohkem. Kui Security Champion osutab veale ja selle tagaj\u00e4rgedele, on tema s\u00f5nal rohkem kaalu.<\/p>\n

Samuti tunnevad arendajad oma koodi paremini kui \u00fckski turvakonsultant. Inimene, kellel on v\u00e4hemalt 5 projekti staatilise anal\u00fc\u00fcsi t\u00f6\u00f6riistas, leiab tavaliselt, et on keeruline meeles pidada k\u00f5iki n\u00fcansse. Security Champions tunnevad oma toodet: mis millega suhtleb ja millele j\u00e4lgida esmakordselt \u2014 nad on t\u00f5husamad.<\/p>\n

Nii et m\u00f5elge Security Champions'i rakendamisele ja turvameeskonna m\u00f5ju suurendamisele. Isegi Championile on see kasulik: professionaalne areng uues valdkonnas, tehnilise silmaringi laienemine, tehniliste, juhtimis- ja juhtimisoskuste arendamine, turuv\u00e4\u00e4rtuse t\u00f5us. See on mingi sotsiaalse inseneeria element, teie \"silmad\" arendusmeeskonnas.<\/p>\n

Testimise etapid<\/h2>\n

\nParadiigma 20 kuni 80<\/a><\/noindex>\u00a0\u00fctleb, et 20% pingutustest toob 80% tulemusi. Need 20% on rakenduste anal\u00fc\u00fcsi praktikad, mida saab ja tuleks automatiseerida. Selliste tegevuste n\u00e4ideteks on staatiline anal\u00fc\u00fcs \u2014 SAST<\/b>, d\u00fcnaamiline anal\u00fc\u00fcs \u2014 DAST,<\/b> ja\u00a0Open Source'i kontrollimine<\/b>. R\u00e4\u00e4gin l\u00e4hemalt tegevustest ning t\u00f6\u00f6riistadest, millega tavaliselt kokku puutume nende rakendamisel protsessi, ja kuidas seda \u00f5igesti teha.<\/p>\n

\"Hirm
\n<\/p>\n

Peamised t\u00f6\u00f6riistade probleemid<\/h3>\n

\nToon v\u00e4lja k\u00f5ikide t\u00f6\u00f6riistade jaoks olulised probleemid, mis vajavad t\u00e4helepanu. Selgitan neid l\u00e4hemalt, et mitte edaspidi korduda.<\/p>\n

Pikaajaline anal\u00fc\u00fcs. <\/b>Kui kommitamisest kuni tootmisse j\u00f5udmiseni kulub k\u00f5ikide testide ja koostamise jaoks 30 minutit, siis infokaitse kontrolld sobib v\u00f5tma terve p\u00e4eva. Keegi ei soovi protsessi pidurdada. Arvestage seda ise\u00e4rasust ja tehke j\u00e4reldusi.<\/p>\n

K\u00f5rgem False Negative v\u00f5i False Positive tase. <\/b>K\u00f5ik tooted on erinevad, k\u00f5ik kasutavad erinevaid raamistikku ja kodeerimisstiili. Erinevatel koodibaasidel ja tehnoloogiatel v\u00f5ivad t\u00f6\u00f6riistad n\u00e4idata erinevat False Negative ja False Positive taset. Seet\u00f5ttu vaadake, mis t\u00e4pselt\u00a0teie<\/b> ettev\u00f5ttes ja teie<\/b> rakendustes toob hea ja usaldusv\u00e4\u00e4rse tulemuse.<\/p>\n

Integratsioonid olemasolevate t\u00f6\u00f6riistadega puuduvad<\/b>. Vaadake t\u00f6\u00f6riistu integratsioonide seisukohast, milliseid te juba kasutate. N\u00e4iteks, kui teil on Jenkins v\u00f5i TeamCity, kontrollige nende t\u00f6\u00f6riistade integratsiooni just selle tarkvaraga, mitte GitLab CI-ga, mida te ei kasuta.<\/p>\n

Kohandamise puudumine v\u00f5i liigse keerukuse olemasolu. <\/b>Kui t\u00f6\u00f6riistal ei ole API-d, siis miks see vajalik on? K\u00f5ik, mis on tehtav liideses, peaks olema kergesti ligip\u00e4\u00e4setav API kaudu. Ideaalis peaks t\u00f6\u00f6riistal olema v\u00f5imalus kontrolle kohandada.<\/p>\n

Toote arendusplaani puudumine. <\/b>Arendus ei seisa paigal, me kasutame alati uusi raamistikku ja funktsioone, kirjutame vana koodi uute keeltega \u00fcmber. Soovime olla kindlad, et t\u00f6\u00f6riist, mille me ostame, toetab uusi raamistikku ja tehnoloogiaid. Seet\u00f5ttu on oluline teada, et tootel on tegelik ja \u00f5ige Teekond<\/a><\/noindex> arendustegevus.<\/p>\n

Protsessi erip\u00e4rad<\/h3>\n

\nLisaks t\u00f6\u00f6riistadele arvestage ka arendusprotsessi erip\u00e4radega. N\u00e4iteks arenduse segamine on t\u00fc\u00fcpiline viga. Vaatame, milliseid teisi erip\u00e4rasid tuleks arvesse v\u00f5tta ja millele turvameeskond peaks t\u00e4helepanu p\u00f6\u00f6rama.<\/p>\n

Kuna arenduse ja v\u00e4ljalaskmise t\u00e4htaegu ei tohiks rikkuda, looge eraldi reeglid<\/b> ja erinevad show stoppers\u00a0<\/b>\u2014 kriteeriumid, mis peatavad koostamisprotsessi, kui avastatakse haavatavusi \u2014 erinevates keskkondades<\/b>. N\u00e4iteks, me m\u00f5istame, et praegune haru l\u00e4heb arendajate stendile v\u00f5i UAT-le, mist\u00f5ttu me ei peata ega \u00fctle:<\/p>\n

\u2014 Teil on siin haavatavused, te ei saa edasi minna!<\/i><\/p>\n

Sel etapil on oluline \u00f6elda arendajatele, et on turvaprobleeme, millele tuleks t\u00e4helepanu p\u00f6\u00f6rata.<\/p>\n

Haavat ei ole takistus edasisele testimisele<\/b>: k\u00e4sitsi, integreeritud v\u00f5i manuaalselt. Teisalt peame kuidagi toote turvalisust parandama ning et arendajad ei ignoreeriks turbe leidmisi. Seet\u00f5ttu toimime m\u00f5nikord nii: stendil, kui see v\u00e4lja lastakse arenduskeskkonda, teavitame arendust:<\/p>\n

\u2014 Poisid, teil on probleeme, palun p\u00f6\u00f6rake neile t\u00e4helepanu.<\/i><\/p>\n

UAT etapis anname taas hoiatustest teada, ja produktsiooni etapis \u00fctlemme:<\/p>\n

\u2014 Poisid, oleme mitu korda hoiatatud, te ei teinud midagi \u2014 sellega ei lase teid v\u00e4lja.<\/i><\/p>\n

Kui r\u00e4\u00e4kida koodist ja d\u00fcnaamikast, siis tuleb n\u00e4idata ja hoiatada haavatavustest ainult nende funktsioonide ja koodi osas, mis on just selles funktsioonis kirjutatud. Kui arendaja liigutab nuppu 3 pikslit ning me \u00fctleme talle, et tal on seal SQL-injektsioon ja seet\u00f5ttu peab ta kiirelt parandama \u2014 see on vale. Vaadake ainult seda, mis on praegu kirjutatud, ja sellele muudatusele, mis rakendusse tuleb.<\/p>\n

Oletame, et meil on mingi funktsionaalne defekt \u2014 see, kuidas rakendus ei peaks t\u00f6\u00f6tama: raha ei edastata, nuppu kl\u00f5psates ei toimu \u00fcleminekut j\u00e4rgmisele lehele v\u00f5i kaupa ei laadita. Turvadefektid<\/b>\u00a0\u2014 need on samasugused defektid, kuid mitte rakenduse t\u00f6\u00f6 kontekstis, vaid turvalisuse osas. <\/p>\n

Kauem ei ole k\u00f5ik tarkvarakvaliteedi probleemid turbeprobleemid. Kuid k\u00f5ik turbeprobleemid on seotud tarkvarakvaliteediga. Sherif Mansour, Expedia.<\/p><\/blockquote>\n

\nKuna k\u00f5ik haavatavused on samasugused defektid, peaksid nad olema seal, kus on k\u00f5ik arendusvead. Seet\u00f5ttu unustage aruanded ja hirmutavad PDF-d, mida keegi ei loe.<\/p>\n

\"Hirm
\n
\nKui t\u00f6\u00f6tasin ettev\u00f5ttes, mis tegeleb arendamisega, sain aruande staatiliste anal\u00fc\u00fcsivahendite kaudu. Avasin selle, ehmatasin \u00e4ra, keetsin kohvi, sirvisin 350 lehte, sulgesin selle ja l\u00e4ksin edasi t\u00f6\u00f6le. Suured aruanded on surnud aruanded<\/b>. \u00dcldiselt need ei kao kuhugi, kirjad kustutatakse, unustatakse, kaotatakse v\u00f5i \u00e4ri \u00fctleb, et v\u00f5tab riskid.<\/p>\n

Mida teha? Tuvastatud vead, mis leiti, muudame lihtsalt arendamiseks sobivaks n\u00e4iteks, kogudes need backlogs Jira-s. Prioriseerime vead ja lahendame need prioriteedi j\u00e4rjekorras koos funktsionaalsete vigade ja testide vigadega.<\/p>\n

Statiline anal\u00fc\u00fcs \u2014 SAST<\/h2>\n

\nSee on koodi anal\u00fc\u00fcs haavatavuste olemasolu osas<\/b>, kuid see ei ole sama, mis SonarQube. Kontrollime mitte ainult mustrite v\u00f5i stiili j\u00e4rgi. Anal\u00fc\u00fcsi k\u00e4igus rakendatakse mitmeid l\u00e4henemisviise: haavatavuste puu j\u00e4rgi, alusel\u00a0DataFlow<\/a><\/noindex>, konfigureerimisfailide anal\u00fc\u00fcsi j\u00e4rgi. See on k\u00f5ik, mis puudutab otse koodi.<\/p>\n

L\u00e4henemise plussid<\/b>: haavatavuste tuvastamine koodis arenduse varajases etapis<\/b>, kui pole veel stende ja valmis t\u00f6\u00f6riista ning\u00a0v\u00f5imalus inkrementaalseks skaneerimiseks<\/b>: koodi osa skaneerimine, mis on muutunud, ja ainult seda funktsiooni, mida me praegu teeme, mis v\u00e4hendab skaneerimise aega.<\/p>\n

Miinused<\/b>\u00a0\u2014 vajalikke keelte toe puudumine.<\/p>\n

Vajadusel integreerimised, <\/b>mida peaks olema t\u00f6\u00f6riistades, minu subjektiivne arvamus:<\/p>\n