{"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 DevSecOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Meil oli 2 koodi anal\u00fcsaatorit, 4 d\u00fcnaamilise testimise t\u00f6\u00f6riista, omatehtud lahendusi ja 250 skripti. Ei, et see k\u00f5ik oleks praeguses protsessis h\u00e4davajalik, kuid kui alustasin DevSecOps'i juurutamist, tuleb minna l\u00f5puni.<\/p>\n

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

Mis on SecDevOps? Ja DevSecOps? Milles need erinevad? Mis on rakenduste turvalisus? Miks traditsiooniline l\u00e4henemine enam ei toimi? K\u00f5igile nendele k\u00fcsimustele oskab vastata Juri \u0160abalin<\/b> kohast\u00a0Swordfish Security. <\/b>Juri vastab k\u00f5igile k\u00fcsimustele ja anal\u00fc\u00fcsib probleeme, mis tulenevad \u00fcleminekust traditsioonilisest rakenduste turvalisuse mudelist DevSecOps'i protsessile: kuidas \u00f5igesti l\u00e4heneda turvalise arendamise protsessi integreerimisele DevOps'i protsessis ja kuidas mitte midagi katki teha, millised on peamised turvatestimise etapid, milliseid t\u00f6\u00f6riistu kasutada, kuidas need erinevad ja kuidas neid \u00f5igesti seadistada, et v\u00e4ltida takistusi.
\n<\/a><\/noindex>
\n

\r\n \"Vaata\r\n
<\/div>\r\n <\/div><\/center>
\nEttekandjast:<\/b> Juri \u0160abalin - <\/b>Chief Security Architect ettev\u00f5ttes Swordfish Security<\/b>. Vastutab SSDL rakendamise eest, samuti rakenduste anal\u00fc\u00fcsit\u00f6\u00f6riistade integreerimise eest \u00fchte arenduse ja testimise \u00f6kos\u00fcsteemi. 7 aastat kogemust infotehnoloogia valdkonnas. Olen t\u00f6\u00f6tanud Alfa-Pank, Sberbank ja Positive Technologiesis, mis arendab tarkvara ja pakub teenuseid. Esineja rahvusvahelistel konferentsidel ZerONights, PHDays, RISSPA, OWASP.<\/p>\n

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

\nRakenduste turvalisus<\/b>\u00a0on turvalisuse haru, mis vastutab rakenduste turvalisuse eest. See ei puuduta infrastruktuuri v\u00f5i v\u00f5rgu turvalisust, vaid seda, mida me kirjutame ja mille kallal arendajad t\u00f6\u00f6tavad \u2014 need on rakenduse vead ja haavatavused.<\/p>\n

Valdkond SDL v\u00f5i SDLC<\/a><\/noindex>\u00a0\u2014 Turvalisuse arenduse eluts\u00fckkel<\/b>\u00a0on Microsofti loodud. Skeemil on toodud kanoniline SDLC mudel, mille peamine eesm\u00e4rk on tagada turvalisus igas arenduse etapis, alates n\u00f5uetest kuni v\u00e4ljaandmise ja tootmisse j\u00f5udmiseni. Microsoft m\u00f5istis, et t\u00f6\u00f6stuses on liiga palju vigu, need muutuvad j\u00e4rjest enamaks ja sellega tuleb midagi ette v\u00f5tta, ning pakkus v\u00e4lja selle l\u00e4henemise, mis sai kanoniliseks.<\/p>\n

\"Hirm
\n
\nRakenduse turvalisus ja SSDL ei ole suunatud haavatavuste tuvastamisele, nagu sageli arvatakse, vaid nende ennetamisele. Aja jooksul on Microsofti kanoniline l\u00e4henemine paranenud ja arenenud, pakkudes s\u00fcgavat detailset sukeldumist.<\/p>\n

\"Hirm
\n
\nKanoniline SDLC on erinevates meetodites, nagu OpenSAMM, BSIMM, OWASP, tugevalt detailsustatud. Meetodid erinevad, kuid \u00fcldiselt on nad sarnased.<\/p>\n

Security Maturity Model<\/h3>\n

\nMulle meeldib see k\u00f5ige rohkem BSIMM<\/b>\u00a0\u2014 Security Maturity Model<\/a><\/noindex>. 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.<\/p>\n

\"Hirm
\n
\nIgal 112 tegevusel on 3 k\u00fcpsuse taset<\/b>: algtaseme, kesktaseme ja edasij\u00f5udnud. K\u00f5iki 12 praktikat saab uurida osade kaupa, valida teile olulisi asju ning m\u00f5ista, kuidas neid rakendada ja j\u00e4rk-j\u00e4rgult lisada elemente, n\u00e4iteks staatilist ja d\u00fcnaamilist koodi anal\u00fc\u00fcsi v\u00f5i koodi \u00fclevaatust. Koostate plaani ja t\u00f6\u00f6tate selle alusel rahulikult valitud tegevuste juurutamise raames.<\/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> eeldati turvakontrolle. Praktikas olid turvameeskonnad palju v\u00e4iksemad kui praegu ning nad ei osalenud protsessis, vaid tegutsesid kontrolli- ja j\u00e4relevalveorganina, mis seadis n\u00f5udeid ja kontrollis toote kvaliteeti v\u00e4ljaandmise l\u00f5pus. See on klassikaline l\u00e4henemine, mille puhul turvameeskonnad olid arendustegevusest eraldatud ja ei osalenud protsessis.<\/p>\n

\"Hirm
\n
\nPeamine probleem ongi see, et infoturbe lahendused on arendusest eraldatud. Tavaliselt on tegemist mingi infoturbe raami ja selles 2\u20133 suure ja kalliga t\u00f6\u00f6riistaga. Kord aastas saadakse l\u00e4htekood v\u00f5i rakendus, mida tuleb kontrollida, ja kord aastas tehakse penetratsioonitestid<\/a><\/noindex>. See toob kaasa selle, et turule j\u00f5udmise t\u00e4htajad l\u00fckatakse edasi ning arendajatele langeb suur hulk haavatavusi automaatsete t\u00f6\u00f6riistade kaudu. K\u00f5ike seda on v\u00f5imatu anal\u00fc\u00fcsida ja parandada, kuna isegi eelmistel kuudel ei ole tulemusi \u00fcle vaadatud, kuid n\u00fc\u00fcd on juba uus partii.<\/p>\n

Meie ettev\u00f5tte t\u00f6\u00f6s n\u00e4eme, et turvalisus k\u00f5igis valdkondades ja t\u00f6\u00f6stustes m\u00f5istab, et on aeg end \u00fcles k\u00e4\u00e4rida ja arendada koos arendusega \u00fches r\u00fctmis \u2014 selles\u00a0Agile<\/b><\/a><\/noindex>. DevSecOps'i paradigma sobitub suurep\u00e4raselt paindliku arenduse metoodikaga, sealhulgas rakendamise, toe ja osalusega igas v\u00e4ljaandes ja iteratsioonis.<\/p>\n

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

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

\nTurvalise arenduse eluts\u00fckli k\u00f5ige olulisem s\u00f5na on \u201eprotsess\u201c<\/b>. Te peate seda m\u00f5istma, enne kui m\u00f5tlema hakata t\u00f6\u00f6riistade ostmisele.<\/p>\n

Lihtsalt t\u00f6\u00f6riistade lisamine DevOpsi protsessile ei ole piisav \u2014 oluline on suhtlemine ja arusaam protsessi osaliste vahel.<\/p><\/blockquote>\n

<\/p>\n

Inimesed on olulisemad kui t\u00f6\u00f6riistad<\/h3>\n

\nSageli algab turvalise arenduse protsessi planeerimine t\u00f6\u00f6riista valimise ja ostmisega, kuid l\u00f5ppeb katsetega integreerida t\u00f6\u00f6riista olemasolevasse protsessi, mis j\u00e4etakse katseteks. See toob kaasa kurvad tagaj\u00e4rjed, kuna k\u00f5igil t\u00f6\u00f6riistadel on omad erip\u00e4rad ja piirangud.<\/p>\n

Levinud olukord, kus turvaosakond valis hea, kallima t\u00f6\u00f6riista, millel on laiad v\u00f5imalused, ja tuli arendajate juurde \u2014 et seda protsessi integreerida. Aga ei suuda \u2014 protsess on \u00fcles ehitatud nii, et juba ostetud t\u00f6\u00f6riista piirangud ei sobi praegusesse paradigma.<\/p>\n

Alustage kirjeldamisest, millist tulemust 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 juba olemasolust<\/h3>\n

\nEnne kallite t\u00f6\u00f6riistade ostmist vaadake, mida teil juba on. Igal ettev\u00f5ttel on arendusele esitatavad turvan\u00f5uded, on kontrolle, penteste \u2014 miks mitte k\u00f5ik see t\u00f5lkida arusaadavasse ja k\u00f5igile mugavasse vormi?<\/p>\n

Tavaliselt on n\u00f5uded paberil oleva tomes, mis seisab riiulis. Olime kunagi olukorras, kus tulime ettev\u00f5ttesse protsesside vaatamiseks ja k\u00fcsisime turvan\u00f5uete dokumendi n\u00e4itamist. Spetsialist, kes sellega tegeles, otsis kaua:<\/p>\n

\u2014 Noh, kuskil m\u00e4rkmetes oli rada, kuhu see dokument oli pandud.<\/i><\/p>\n

L\u00f5ppkokkuv\u00f5ttes saime dokumendi alles n\u00e4dala p\u00e4rast.<\/p>\n

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

Lihtsam on \u00fcmber vormindada seda, mis juba olemas on, ja kasutada seda alustamiseks.<\/p><\/blockquote>\n

<\/p>\n

Kasutage Security Champions <\/h3>\n

\nTavaliselt t\u00f6\u00f6tab keskmises ettev\u00f5ttes 100\u2013200 arendaja kohta \u00fcks turbeekspert, kes t\u00e4idab mitmeid \u00fclesandeid ja f\u00fc\u00fcsiliselt ei suuda k\u00f5ike kontrollida. Isegi kui ta p\u00fc\u00fcab oma parima, ei suuda ta \u00fcksi kontrollida k\u00f5iki koode, mida arendus genereerib. Selliste juhtude tarvis on v\u00e4lja t\u00f6\u00f6tatud kontseptsioon \u2014 Security Champions<\/b><\/a><\/noindex>.<\/p>\n

Security Champions on inimene arendustiimis, kellel on huvi teie toote turvalisuse vastu.<\/p><\/blockquote>\n

\"Hirm
\n
\nSecurity Champion on sissep\u00e4\u00e4s arendustiimi ning turvalisuse evangelist \u00fches isikus.<\/p>\n

Tavaliselt, kui turbeekspert tuleb arendustiimi ja osutab veale koodis, saab ta \u00fcllatava vastuse:<\/p>\n

\u2014 Kes teie olete? Ma n\u00e4en teid esmakordselt. Mul on k\u00f5ik h\u00e4sti \u2014 minu vanem koleeg pani code review's 'apply', me l\u00e4heme edasi!<\/i><\/p>\n

See on t\u00fc\u00fcpiline olukord, sest usaldus vanemate v\u00f5i lihtsalt meeskonnakaaslaste vastu, kellega arendaja pidevalt t\u00f6\u00f6alaselt suhtleb ja kes osalevad koodi \u00fclevaatuses, on palju suurem. Kui veateate ja tagaj\u00e4rgede eest vastutab turvamees, siis tema s\u00f5na kaalub rohkem.<\/p>\n

Arendajad tunnevad oma koodi paremini kui \u00fckski turvamees. Inimesele, kellel on v\u00e4hemalt 5 projekti staatilisest anal\u00fc\u00fcsist, on tavaliselt keeruline meeles pidada k\u00f5iki n\u00fcansse. Turvameistrid tunnevad oma toodet: mida miski m\u00f5jutab ja millele esmalt t\u00e4helepanu p\u00f6\u00f6rata \u2013 nad on t\u00f5husamad.<\/p>\n

Seega m\u00f5elge turvameistrite rakendamisele ja turvameeskonna m\u00f5ju suurendamisele. Isegi turvameister saab sellest kasu: professionaalne areng uues valdkonnas, tehnilise silmaringi laiendamine, tehniliste, juhtimis- ja liidrioskuste arendamine, turuv\u00e4\u00e4rtuse t\u00f5stmine. See on teatud element sotsiaalsest inseneriteadusest, teie 'silmad' arendusmeeskonnas.<\/p>\n

Testimise etapid<\/h2>\n

\nParadigma 20 80<\/a><\/noindex>\u00a0\u00fctleb, et 20% pingutustest toob 80% tulemustest. Need 20% on rakenduste anal\u00fc\u00fcsi praktikad, mida saab ja tuleb automatiseerida. Selliste tegevuste n\u00e4ideteks on staatiline anal\u00fc\u00fcs \u2014 SAST<\/b>, d\u00fcnaamiline anal\u00fc\u00fcs \u2014 DAST,<\/b> ja\u00a0Open Source kontroll<\/b>. R\u00e4\u00e4gin l\u00e4hemalt tegevustest ning t\u00f6\u00f6riistadest, millega me tavaliselt silmitsi seisame, kui need protsessi rakendame, ja kuidas seda \u00f5igesti teha.<\/p>\n

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

T\u00f6\u00f6riistade p\u00f5hiprobleemid<\/h3>\n

\nT\u00f5stan esile k\u00f5iki t\u00f6\u00f6riistu m\u00f5jutavad probleemid, mis vajavad t\u00e4helepanu. Uurin neid p\u00f5hjalikumalt, et hiljem mitte korduda.<\/p>\n

Pikaajaline anal\u00fc\u00fcs. <\/b>Kui kommitamisest tootmisse minekuks kulub 30 minutit k\u00f5igile testidele ja kogumisele, siis infoturbe kontrollid v\u00f5tavad terve p\u00e4eva. Nii ei saa protsessi pidurdada. Arvestage seda omadust ja tehke j\u00e4reldusi.<\/p>\n

Korke vale negatiivne v\u00f5i vale positiivne m\u00e4\u00e4r. <\/b>K\u00f5ik tooted on erinevad, k\u00f5ik kasutavad erinevaid raamistikke ja oma koodikirjutamise stiili. Erinevad koodibasid ja tehnoloogiad v\u00f5ivad n\u00e4idata erinevat vale negatiivsete ja vale positiivsete m\u00e4\u00e4rasid. Seega vaadake, mis t\u00e4pselt on\u00a0teie<\/b> ettev\u00f5ttes ja teie<\/b> rakendused n\u00e4itavad head ja usaldusv\u00e4\u00e4rset tulemust.<\/p>\n

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

Kohandamise puudumine v\u00f5i \u00fcleliigne keerukus. <\/b>Kui t\u00f6\u00f6riistal ei ole API-d, siis miks ta vajalik on? K\u00f5ik, mida saab teha liideses, peaks olema saadaval ka API kaudu. Ideaalis peaks t\u00f6\u00f6riistal olema kohandamisv\u00f5ime kontrollide jaoks.<\/p>\n

Toote arenduse Roadmap'i puudumine. <\/b>Arendus ei seisa paigal, me kasutame alati uusi raamistikke ja funktsioone, kirjutame vana koodi uutele keeltele \u00fcmber. Soovime olla kindlad, et t\u00f6\u00f6riist, mille ostame, toetab uusi raamistikke ja tehnoloogiaid. Seet\u00f5ttu on oluline teada, et tootest on olemas t\u00f5eline ja korrektne Roadmap<\/a><\/noindex> arendamiseks.<\/p>\n

Protsessi ise\u00e4rasused<\/h3>\n

\nLisaks t\u00f6\u00f6riistade omadustele tuleb arvesse v\u00f5tta ka arendusprotsessi erip\u00e4ra. N\u00e4iteks arendamise segamine on t\u00fc\u00fcpiline viga. Vaadakem, milliseid muid omadusi tuleb arvesse v\u00f5tta ja millele turvameeskond peaks t\u00e4helepanu p\u00f6\u00f6rama.<\/p>\n

Et mitte rikkuda arendus- ja v\u00e4ljalasket\u00e4htaegu, looge erinevad reeglid<\/b> ja erinevad show stoppers\u00a0<\/b>\u2014 kriteeriumid, mis peatavad ehitamisprotsessi, kui avastatakse haavatavusi \u2014 erinevates keskkondades<\/b>. N\u00e4iteks m\u00f5istame, et praegune haru suundub arendajate stendi v\u00f5i UAT-i, seega ei peata me ega \u00fctle:<\/p>\n

\u2014 Teil on siin haavatavusi, te ei tohi edasi liikuda!<\/i><\/p>\n

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

Haavatavuste olemasolu ei ole takistus edasiseks testimiseks<\/b>: k\u00e4sitsi, integreerimis- v\u00f5i manuaalselt. Teiselt poolt peame leidma viisi, kuidas toote turvalisust parandada, et arendajad ei ignoreeriks turvameeskonna leidmisi. Seet\u00f5ttu k\u00e4itume m\u00f5nikord nii: stendil, kui see viiakse arenduskeskkonda, lihtsalt teavitame arendust:<\/p>\n

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

UAT etapis n\u00e4itame taas haavatavuste hoiatusi, ja kui j\u00f5uame tootmisse, \u00fctleme:<\/p>\n

\u2014 Pois, oleme mitu korda hoiatanud, te ei teinud midagi \u2014 sellega teid ei lasta v\u00e4lja.<\/i><\/p>\n

Kui r\u00e4\u00e4kida koodist ja d\u00fcnaamikast, tuleb n\u00e4idata ja hoiatada ainult nende funktsioonide ja koodi eest, mis on just selles funktsioonis kirjutatud. Kui arendaja t\u00f5ukab nuppu 3 pikslit ja me \u00fctleme talle, et tal on SQL-i s\u00fcstimisprobleem ja seega peab kiiresti parandama \u2014 see pole \u00f5ige. Vaadake ainult seda, mis on praegu kirjutatud, ja nende muudatuste \u00fcle, mis rakendusse tulevad.<\/p>\n

Oletame, et meil on mingisugune funktsionaalne defekt \u2014 see on see, kuidas rakendus ei tohiks t\u00f6\u00f6tada: raha ei kantud \u00fcle, nupule kl\u00f5psamisel ei toimu \u00fcleminekut j\u00e4rgmisele lehele v\u00f5i kaup ei laadita. Turvavead<\/b>\u00a0\u2014 need on samasugused defektid, kuid mitte rakenduse t\u00f6\u00f6 raames, vaid turvalisuse osas. <\/p>\n

Kuid k\u00f5ik tarkvara kvaliteediprobleemid ei ole turvaprobleemid. Aga k\u00f5ik turvaprobleemid on seotud tarkvara kvaliteediga. Sherif Mansour, Expedia.<\/p><\/blockquote>\n

\nKuna k\u00f5ik haavatavused on samuti defektid, peavad nad olema seal, kus on k\u00f5ik arendusdefektid. Seega unustage aruanded ja hirmutavad PDF-dokumendid, mida keegi ei loe.<\/p>\n

\"Hirm
\n
\nKui ma t\u00f6\u00f6tasin ettev\u00f5ttes, mis tegeles arendusega, sain ma aruande staatilisest anal\u00fc\u00fcsist. Avasin selle, \u0161okeerisin, keetsin kohvi, sirvisin 350 lehte, sulgesin selle ja l\u00e4ksin edasi t\u00f6\u00f6tama. Suured aruanded on surnud aruanded<\/b>. Tavaliselt ei l\u00e4he need kuhugi, kirjad kustutatakse, unustatakse, kaotatakse v\u00f5i \u00e4ri \u00fctleb, et nad v\u00f5tavad riske.<\/p>\n

Mida teha? Kinnitatud defektid, mis leiti, muudetakse lihtsalt arendusele mugavaks vormiks, n\u00e4iteks kogutakse backlog'i Jira-s. Defektid prioriseeritakse ja k\u00f5rvaldatakse prioriteedi j\u00e4rjekorras koos funktsionaalsete defektide ja testide defektidega.<\/p>\n

Statsionaarne anal\u00fc\u00fcs - SAST<\/h2>\n

\nSee on koodi anal\u00fc\u00fcs haavatavuste tuvastamiseks<\/b>, kuid see ei ole sama mis SonarQube. Me ei kontrolli mitte ainult mustrite v\u00f5i stiili j\u00e4rgi. Anal\u00fc\u00fcsis rakendatakse mitmeid l\u00e4henemisviise: haavatavuste puu,\u00a0DataFlow<\/a><\/noindex>, konfiguratsioonifailide anal\u00fc\u00fcsimine. See k\u00f5ik puudutab otseselt koodi.<\/p>\n

Meetodi eelised<\/b>: haavatavuste tuvastamine koodi varases arendusetapis<\/b>, kui veel ei ole stende ega valmis t\u00f6\u00f6riistu, ja\u00a0v\u00f5imalus inkrementaalseks skaneerimiseks<\/b>: skaneerimine koodijupist, mis on muutunud, ja ainult selle funktsiooni puhul, mille kallal me praegu t\u00f6\u00f6tame, mis v\u00e4hendab skaneerimise aega.<\/p>\n

Miinused<\/b>\u00a0\u2014 on vajalikud keelte toetuse puudumine.<\/p>\n

Vajalikud integratsioonid, <\/b>mis peaksid olema t\u00f6\u00f6riistades, minu subjektiivse arvamuse kohaselt:<\/p>\n