Við vorum með 2 kóðagreiningartæki, 4 kraftmikil prófunartæki, okkar eigin handverk og 250 forskriftir. Það er ekki það að allt þetta sé nauðsynlegt í núverandi ferli, en þegar þú byrjar að innleiða DevSecOps þarftu að fara til enda.
. Persónuhöfundar: Justin Roiland og Dan Harmon.
Hvað er SecDevOps? Hvað með DevSecOps? Hver er munurinn? Umsóknaröryggi - um hvað snýst það? Af hverju virkar klassíska nálgunin ekki lengur? Veit svarið við öllum þessum spurningum Yuri Shabalin á Sverðfiskaöryggi. Yuri mun svara öllu í smáatriðum og greina vandamálin við umskipti frá klassísku umsóknaröryggislíkani til DevSecOps ferlisins: hvernig á að nálgast samþættingu öruggs þróunarferlis í DevOps ferlinu á réttan hátt og ekki brjóta neitt, hvernig á að fara í gegnum helstu stigin öryggisprófa, hvaða verkfæri er hægt að nota og hvað þau eru mismunandi og hvernig á að stilla þau rétt til að forðast gildrur.
Um ræðumanninn: Yuri Shabalin - Yfiröryggisarkitekt í fyrirtækinu Sverðfiskaöryggi. Ber ábyrgð á innleiðingu SSDL, fyrir heildarsamþættingu forritagreiningartækja í sameinað þróunar- og prófunarvistkerfi. 7 ára reynsla af upplýsingaöryggi. Starfaði hjá Alfa-Bank, Sberbank og Positive Technologies sem þróar hugbúnað og veitir þjónustu. Fyrirlesari á alþjóðlegum ráðstefnum ZerONights, PHDays, RISSPA, OWASP.
Umsóknaröryggi: um hvað snýst það?
Umsókn Öryggi - Þetta er öryggishlutinn sem ber ábyrgð á öryggi forrita. Þetta á ekki við um innviði eða netöryggi, heldur frekar það sem við skrifum og það sem þróunaraðilar vinna við - þetta eru gallar og veikleikar forritsins sjálfs.
Direction - Lífsferill öryggisþróunar - þróað af Microsoft. Skýringarmyndin sýnir kanóníska SDLC líkanið, aðalverkefni þess er þátttaka öryggis á hverju stigi þróunar, frá kröfum til útgáfu og framleiðslu. Microsoft áttaði sig á því að það voru of margar villur í greininni, þær voru fleiri og eitthvað varð að gera í því og þeir lögðu til þessa nálgun sem er orðin kanónísk.
Umsóknaöryggi og SSDL miða ekki að því að greina veikleika, eins og almennt er talið, heldur að koma í veg fyrir að þeir komi upp. Með tímanum hefur kanónísk nálgun Microsoft verið endurbætt, þróuð og kynnt í dýpri og ítarlegri köfun.
Hið kanóníska SDLC er mjög ítarlegt í ýmsum aðferðum - OpenSAMM, BSIMM, OWASP. Aðferðafræðin er ólík, en yfirleitt svipuð.
Building Security In Maturity Model
Mér líkar það mest BSIMM - . Grunnur aðferðafræðinnar er skipting umsóknaröryggisferlisins í 4 svið: Stjórnunarhættir, upplýsingaöflun, SSDL snertipunktar og dreifing. Hvert lén hefur 12 starfshætti, sem eru táknuð sem 112 starfsemi.
Hver af 112 starfseminni hefur 3 þroskaþrep: byrjendur, miðlungs og lengra komnir. Þú getur rannsakað allar 12 starfshætti hluta fyrir hluta, valið hluti sem eru mikilvægir fyrir þig, fundið út hvernig á að útfæra þá og smám saman bætt við þáttum, til dæmis kyrrstöðu og kraftmikilli kóðagreiningu eða endurskoðun kóða. Þú skrifar niður áætlun og vinnur eftir henni í rólegheitum sem hluti af framkvæmd valinna aðgerða.
Hvers vegna DevSecOps
DevOps er almennt stórt ferli þar sem taka þarf tillit til öryggis.
Upphaflega fól í sér öryggiseftirlit. Í reynd var fjöldi öryggisteyma mun færri en nú og virkuðu þeir ekki sem þátttakendur í ferlinu heldur sem eftirlits- og eftirlitsaðili sem setur kröfur á það og athugar gæði vörunnar í lok útgáfunnar. Þetta er klassísk nálgun þar sem öryggisteymi voru á bak við vegg frá þróun og tóku ekki þátt í ferlinu.
Helsta vandamálið er að upplýsingaöryggi er aðskilið frá þróun. Yfirleitt er þetta einhvers konar upplýsingaöryggisrás og í henni eru 2-3 stór og dýr verkfæri. Einu sinni á sex mánaða fresti kemur frumkóði eða forrit sem þarf að athuga og einu sinni á ári eru þeir framleiddir . Allt þetta leiðir til þess að útgáfudegi fyrir greinina er seinkað og verktaki verður fyrir miklum fjölda veikleika frá sjálfvirkum verkfærum. Það er ómögulegt að taka þetta í sundur og gera við, vegna þess að niðurstöðurnar fyrir sex mánuðina á undan voru ekki flokkaðar, en hér er ný lota.
Í starfi fyrirtækisins sjáum við að öryggi á öllum sviðum og atvinnugreinum skilur að það er kominn tími til að ná og snúast með þróun á sama hjóli - í . DevSecOps hugmyndafræðin passar fullkomlega við lipur þróunaraðferðafræði, innleiðingu, stuðning og þátttöku í hverri útgáfu og endurtekningu.
Umskipti yfir í DevSecOps
Mikilvægasta orðið í lífsferli öryggisþróunar er "ferli". Þú verður að skilja þetta áður en þú hugsar um að kaupa verkfæri.
Það er ekki nóg að setja verkfæri inn í DevOps ferlið einfaldlega - samskipti og skilningur á milli þátttakenda ferlisins er mikilvægur.
Fólk er mikilvægara, ekki verkfæri.
Oft byrjar áætlanagerð um öruggt þróunarferli með því að velja og kaupa tól og endar með tilraunum til að samþætta tólið í núverandi ferli, sem eru enn tilraunir. Þetta leiðir til óheppilegra afleiðinga, því öll verkfæri hafa sín sérkenni og takmarkanir.
Algengt tilvik er þegar öryggisdeildin valdi gott, dýrt tól með víðtæka möguleika og kom til þróunaraðila til að samþætta það inn í ferlið. En það gengur ekki upp - ferlið er byggt upp á þann hátt að takmarkanir á þegar keyptu tækinu passa ekki inn í núverandi hugmyndafræði.
Fyrst skaltu lýsa hvaða niðurstöðu þú vilt og hvernig ferlið mun líta út. Þetta mun hjálpa til við að skilja hlutverk verkfæra og öryggis í ferlinu.
Byrjaðu á því sem þegar er í notkun
Áður en þú kaupir dýr verkfæri skaltu skoða það sem þú hefur nú þegar. Sérhvert fyrirtæki hefur öryggiskröfur fyrir þróun, það eru athuganir, pentests - hvers vegna ekki að breyta þessu öllu í form sem er skiljanlegt og þægilegt fyrir alla?
Venjulega eru kröfurnar pappírs Talmud sem liggur á hillu. Það var tilfelli þegar við komum til fyrirtækis til að skoða ferlana og báðum um að sjá öryggiskröfur fyrir hugbúnaðinn. Sérfræðingurinn sem fékkst við þetta var lengi að leita að:
- Nú, einhvers staðar í athugasemdunum var leið þar sem þetta skjal liggur.
Fyrir vikið fengum við skjalið viku síðar.
Fyrir kröfur, ávísanir og annað, búðu til síðu á t.d. Traust - það er þægilegt fyrir alla.
Það er auðveldara að endursníða það sem þú hefur þegar og nota það til að byrja.
Notaðu Security Champions
Venjulega, í meðalfyrirtæki með 100-200 forritara, er einn öryggissérfræðingur sem sinnir nokkrum aðgerðum og hefur ekki líkamlega tíma til að athuga allt. Jafnvel þótt hann reyni sitt besta mun hann einn ekki athuga allan kóðann sem þróunin býr til. Fyrir slík tilvik hefur verið þróað hugtak - .
Öryggismeistarar eru fólk innan þróunarteymisins sem hefur áhuga á öryggi vörunnar þinnar.
Öryggismeistari er inngöngustaður í þróunarteymið og öryggisguðspjallamaður settur í einn.
Venjulega, þegar öryggissérfræðingur kemur að þróunarteymi og bendir á villu í kóðanum, fær hann undrandi svar:
- Og hver ert þú? Ég sé þig í fyrsta skipti. Allt er í lagi með mig - eldri vinur minn gaf mér "sækja um" á kóða endurskoðun, við höldum áfram!
Þetta er dæmigert ástand vegna þess að það er miklu meira traust til eldri borgara eða einfaldlega liðsfélaga sem verktaki hefur stöðugt samskipti við í vinnunni og við endurskoðun kóðans. Ef Öryggismeistarinn bendir á mistökin og afleiðingarnar í stað öryggisfulltrúans, þá mun orð hans hafa meira vægi.
Einnig þekkja verktaki kóðann sinn betur en nokkur öryggissérfræðingur. Fyrir einstakling sem hefur að minnsta kosti 5 verkefni í kyrrstöðugreiningartæki er venjulega erfitt að muna öll blæbrigðin. Öryggismeistarar þekkja vöru sína: hvað hefur samskipti við hvað og hvað á að skoða fyrst - þeir eru skilvirkari.
Íhugaðu því að innleiða Security Champions og auka áhrif öryggisteymisins þíns. Þetta er líka gagnlegt fyrir meistarann sjálfan: faglega þróun á nýju sviði, víkka út tæknilegan sjóndeildarhring hans, uppfæra tækni-, stjórnunar- og leiðtogahæfileika, auka markaðsvirði. Þetta er einhver þáttur í félagsverkfræði, „augu“ þín í þróunarteymi.
Prófunarstig
segir að 20% af átaki skili 80% af árangri. Þessi 20% eru aðferðir við greiningar á forritum sem geta og ætti að vera sjálfvirkar. Dæmi um slíka starfsemi eru kyrrstöðugreining - SAST, kraftmikil greining - DAST и Open Source stjórnun. Ég mun segja þér meira um starfsemina, sem og um verkfærin, hvaða eiginleika við lendum venjulega í þegar við kynnum þau inn í ferlið og hvernig á að gera það rétt.
Helstu vandamál verkfæra
Ég mun draga fram vandamál sem skipta máli fyrir öll tæki og krefjast athygli. Ég mun greina þær nánar til að endurtaka þær ekki frekar.
Langur greiningartími. Ef frá skuldbindingu til útgáfu tekur 30 mínútur fyrir allar prófanir og samsetningu, þá mun upplýsingaöryggiseftirlit taka einn dag. Þannig að enginn mun hægja á ferlinu. Taktu tillit til þessa eiginleika og dragðu ályktanir.
Hátt stig rangt neikvætt eða rangt jákvætt. Allar vörur eru mismunandi, allar nota mismunandi ramma og sinn eigin kóðunarstíl. Á mismunandi kóðagrunnum og tækni, geta verkfæri sýnt mismunandi stig af fölsku neikvæðu og fölsku jákvætt. Svo líttu á hvað nákvæmlega er í þinn fyrirtæki og fyrir þinn umsóknir munu sýna góðan og áreiðanlegan árangur.
Engar samþættingar við núverandi verkfæri. Horfðu á verkfæri hvað varðar samþættingu við það sem þú notar nú þegar. Til dæmis, ef þú ert með Jenkins eða TeamCity, athugaðu samþættingu verkfæra við þennan hugbúnað, en ekki með GitLab CI, sem þú notar ekki.
Skortur eða óhófleg flókin sérsniðin. Ef tól er ekki með API, hvers vegna er það þá nauðsynlegt? Allt sem hægt er að gera í viðmótinu ætti að vera tiltækt í gegnum API. Helst ætti tólið að hafa getu til að sérsníða ávísanir.
Enginn vegvísir fyrir vöruþróun. Þróun stendur ekki í stað, við erum alltaf að nota nýja ramma og aðgerðir, endurskrifa gamlan kóða yfir á ný tungumál. Við viljum vera viss um að tækið sem við kaupum muni styðja við nýja umgjörð og tækni. Þess vegna er mikilvægt að vita að varan sé raunveruleg og rétt þróun.
Aðferðareiginleikar
Til viðbótar við eiginleika verkfæranna skaltu taka tillit til eiginleika þróunarferlisins. Til dæmis eru algeng mistök að hindra þróun. Við skulum skoða hvaða aðra eiginleika ætti að taka tillit til og hverju öryggisteymi ætti að borga eftirtekt til.
Til þess að missa ekki af þróun og útgáfu fresti, búðu til mismunandi reglur og öðruvísi sýna tappa — viðmið til að stöðva byggingarferlið ef veikleikar eru til staðar — fyrir mismunandi umhverfi. Til dæmis skiljum við að núverandi útibú fer í þróunarstand eða UAT, sem þýðir að við stoppum ekki og segjum:
„Þú ert með veikleika hérna, þú munt ekki fara lengra!
Á þessum tímapunkti er mikilvægt að segja forriturum að það séu öryggisvandamál sem þarfnast athygli.
Tilvist veikleika er ekki hindrun fyrir frekari prófunum: handbók, samþætting eða handbók. Á hinn bóginn þurfum við einhvern veginn að auka öryggi vörunnar og svo að verktaki vanræki ekki það sem þeim finnst öruggt. Þess vegna gerum við stundum þetta: á básnum, þegar það er rúllað út í þróunarumhverfið, tilkynnum við einfaldlega þróunina:
- Krakkar, þið eigið í vandræðum, vinsamlega takið eftir þeim.
Á UAT stigi sýnum við aftur viðvaranir um varnarleysi og á útgáfustigi segjum við:
- Krakkar, við vöruðum ykkur við nokkrum sinnum, þið gerðir ekki neitt - við munum ekki hleypa ykkur út með þetta.
Ef við tölum um kóða og gangverki, þá er nauðsynlegt að sýna og vara við veikleikum aðeins þessara eiginleika og kóða sem var nýlega skrifaður í þessum eiginleika. Ef forritari færir hnapp um 3 pixla og við segjum honum að hann sé með SQL innspýtingu þar og því þurfi að laga hann sem fyrst, þá er þetta rangt. Horfðu aðeins á það sem er skrifað núna og á breytinguna sem kemur á umsókninni.
Segjum að við séum með ákveðinn virknigalla - hvernig forritið ætti ekki að virka: peningar eru ekki fluttir, þegar þú smellir á hnapp er engin umskipti á næstu síðu eða varan hleðst ekki. Öryggisgalla - þetta eru sömu gallarnir, en ekki hvað varðar notkun forritsins, heldur í öryggi.
Ekki eru öll hugbúnaðargæðavandamál öryggisvandamál. En öll öryggisvandamál tengjast gæðum hugbúnaðar. Sherif Mansour, Expedia.
Þar sem allir veikleikar eru sömu gallarnir ættu þeir að vera staðsettir á sama stað og allir þróunargallar. Svo gleymdu skýrslum og skelfilegum PDF-skjölum sem enginn les.
Þegar ég var að vinna hjá þróunarfyrirtæki fékk ég skýrslu frá kyrrstöðugreiningartækjum. Ég opnaði hann, varð skelfingu lostinn, bjó til kaffi, fletti 350 blaðsíðum, lokaði og hélt áfram að vinna. Stórar skýrslur eru dauðar skýrslur. Venjulega fara þeir hvergi, bréfunum er eytt, þeim gleymt, týnt eða fyrirtækið segist taka áhættuna.
Hvað skal gera? Við breytum einfaldlega staðfestum göllum sem við fundum í form sem hentar fyrir þróun, til dæmis setjum við þá í backlog í Jira. Við forgangsraðum göllum og útrýmum þeim í forgangsröð ásamt virknigöllum og prófgöllum.
Static Analysis - SAST
Þetta er kóðagreining fyrir veikleika., en það er ekki það sama og SonarQube. Við athugum ekki bara eftir mynstrum eða stíl. Nokkrar nálganir eru notaðar við greininguna: samkvæmt viðkvæmnitrénu, skv , með því að greina stillingarskrár. Þetta er allt sem varðar kóðann sjálfan.
Kostir nálgunarinnar: greina veikleika í kóða á frumstigi þróunarþegar engir standa eða tilbúin verkfæri eru enn til, og stigvaxandi skönnunarmöguleika: að skanna hluta af kóða sem hefur breyst, og aðeins eiginleikann sem við erum að gera núna, sem dregur úr skönnunartíma.
Gallar - þetta er skortur á stuðningi við nauðsynleg tungumál.
Nauðsynlegar samþættingar, sem ætti að vera í verkfærunum, að mínu huglægu mati:
- Samþættingartæki: Jenkins, TeamCity og Gitlab CI.
- Þróunarumhverfi: Intellij IDEA, Visual Studio. Það er þægilegra fyrir þróunaraðila að flakka ekki um óskiljanlegt viðmót sem enn þarf að leggja á minnið, heldur sjá allar nauðsynlegar samþættingar og veikleika sem hann hefur fundið á vinnustaðnum í sínu eigin þróunarumhverfi.
- Kóðaskoðun: SonarQube og handvirk skoðun.
- Galla rekja spor einhvers: Jira og Bugzilla.
Myndin sýnir nokkra af bestu fulltrúa truflanagreiningar.
Það eru ekki verkfærin sem eru mikilvæg, heldur ferlið, svo það eru til Open Source lausnir sem eru líka góðar til að prófa ferlið.
SAST Open Source mun ekki finna mikinn fjölda veikleika eða flókin DataFlows, en þau geta og ætti að vera notuð við að byggja upp ferli. Þeir hjálpa til við að skilja hvernig ferlið verður byggt upp, hver mun bregðast við villum, hver mun tilkynna og hver mun tilkynna. Ef þú vilt framkvæma fyrsta stigið við að byggja upp öryggi kóðans þíns skaltu nota Open Source lausnir.
Hvernig er hægt að samþætta þetta ef þú ert við upphaf ferðar þinnar og hefur ekkert: ekkert CI, ekkert Jenkins, ekkert TeamCity? Við skulum íhuga samþættingu inn í ferlið.
CVS stig samþætting
Ef þú ert með Bitbucket eða GitLab geturðu samþætt á stigi .
Eftir atburði - draga beiðni, skuldbinda. Þú skannar kóðann og byggingarstaðan sýnir hvort öryggisathugunin stóðst eða mistókst.
Viðbrögð. Auðvitað er alltaf þörf á endurgjöf. Ef þú gerðir bara öryggi á hliðinni, settir það í kassa og sagðir engum neitt um það, og síðan í lok mánaðarins hent helling af pöddum - þetta er ekki rétt og ekki gott.
Samþætting við kóða endurskoðunarkerfið
Einu sinni virkuðum við sem sjálfgefinn gagnrýnandi fyrir tæknilegan AppSec notanda í ýmsum mikilvægum verkefnum. Það fer eftir því hvort villur eru auðkenndar í nýja kóðanum eða það eru engar villur, gagnrýnandi setur stöðuna á dráttarbeiðninni á "samþykkja" eða "þarfa vinnu" - annað hvort er allt í lagi, eða tenglar á það sem nákvæmlega þarf að bæta þarf að bæta. Fyrir samþættingu við útgáfuna sem er að fara í framleiðslu höfum við virkjað samrunabann ef upplýsingaöryggisprófið er ekki staðist. Við tókum þetta inn í handvirka yfirferð kóðans og aðrir þátttakendur í ferlinu sáu öryggisstöðuna fyrir þetta tiltekna ferli.
Samþætting við SonarQube
Margir hafa hvað varðar gæði kóða. Það er það sama hér - þú getur búið til sömu hlið aðeins fyrir SAST verkfæri. Það verður sama viðmótið, sama gæðahliðið, aðeins það verður kallað öryggishlið. Og líka, ef þú ert með ferli sem notar SonarQube, geturðu auðveldlega samþætt allt þar.
Samþætting á CI stigi
Allt hér er líka frekar einfalt:
- Á pari við sjálfvirkar prófanir, einingapróf.
- Skipting eftir þróunarstigum: dev, próf, framleiðsla. Mismunandi sett af reglum eða mismunandi bilunarskilyrði geta verið innifalin: stöðva samsetningu, ekki stöðva samsetningu.
- Samstillt/ósamstillt ræsing. Við erum að bíða eftir því að öryggisprófunum lýkur eða ekki. Það er að segja, við settum þá bara af stað og höldum áfram og þá fáum við stöðuna að allt sé gott eða slæmt.
Þetta er allt í fullkomnum bleikum heimi. Það er ekkert slíkt í raunveruleikanum, en við reynum. Niðurstaða öryggisathugunar ætti að vera svipuð og niðurstöður einingaprófa.
Til dæmis tókum við stórt verkefni og ákváðum að nú munum við skanna það með SAST - OK. Við ýttum þessu verkefni inn í SAST, það gaf okkur 20 veikleika og með viljasterkri ákvörðun ákváðum við að allt væri í lagi. 000 veikleikar eru tækniskuldir okkar. Við setjum skuldina í kassa, við hreinsum hana hægt og rólega upp og bætum villum við gallaða rekja spor einhvers. Ráðum fyrirtæki, gerum allt sjálf eða látum Security Champions hjálpa okkur - og tæknilegar skuldir munu minnka.
Og alla nýlega uppkomna veikleika í nýja kóðanum verður að útrýma á sama hátt og villur í einingu eða í sjálfvirkum prófunum. Tiltölulega séð byrjaði samkoman, við keyrðum hana, tvö próf og tvö öryggispróf féllu. OK - við fórum, skoðuðum hvað gerðist, laguðum eitt, laguðum annað, keyrðum það næst - allt var í lagi, engir nýir veikleikar komu fram, engin próf mistókst. Ef þetta verkefni er dýpra og þú þarft að skilja það vel, eða lagfæring á veikleikum hefur áhrif á stór lög af því sem liggur undir húddinu: villu var bætt við gallasporið, er það forgangsraðað og leiðrétt. Því miður er heimurinn ekki fullkominn og próf misheppnast stundum.
Dæmi um öryggishlið er hliðstæða gæðahliðs, hvað varðar tilvist og fjölda veikleika í kóðanum.
Við samþættum við SonarQube - viðbótin er uppsett, allt er mjög þægilegt og flott.
Samþætting við þróunarumhverfi
Samþættingarvalkostir:
- Að keyra skönnun úr þróunarumhverfinu fyrir skuldbindingu.
- Skoða niðurstöður.
- Greining á niðurstöðum.
- Samstilling við netþjóninn.
Svona lítur það út að fá niðurstöður frá þjóninum.
Í þróunarumhverfi okkar aukaatriði birtist einfaldlega sem upplýsir þig um að slíkar veikleikar hafi fundist við skönnunina. Þú getur strax breytt kóðanum, skoðað tillögur og . Þetta er allt staðsett á vinnustað þróunaraðilans, sem er mjög þægilegt - það er engin þörf á að fylgja öðrum tenglum og skoða eitthvað til viðbótar.
Open Source
Þetta er uppáhalds umræðuefnið mitt. Allir nota Open Source bókasöfn - af hverju að skrifa fullt af hækjum og hjólum þegar þú getur tekið tilbúið bókasafn þar sem allt er þegar útfært?
Auðvitað er þetta rétt, en bókasöfn eru líka skrifuð af fólki, þau fela líka í sér ákveðnar áhættur og það eru líka veikleikar sem eru reglulega, eða stöðugt, tilkynntir. Þess vegna er næsta skref í Application Security - þetta er greining á opnum uppspretta hlutum.
Open Source Analysis - OSA
Verkfærið inniheldur þrjú stór stig.
Leitað að veikleikum í bókasöfnum. Til dæmis veit tólið að við erum að nota eitthvað bókasafn og það í eða það eru einhverjir veikleikar í villurakningum sem tengjast þessari útgáfu af bókasafninu. Þegar þú reynir að nota það mun tólið gefa út viðvörun um að bókasafnið sé viðkvæmt og ráðleggur þér að nota aðra útgáfu sem er ekki með veikleika.
Greining á hreinleika leyfis. Þetta er ekkert sérstaklega vinsælt hér ennþá, en ef þú vinnur erlendis þá geturðu af og til fengið skatt þar fyrir að nota opinn hugbúnað sem ekki er hægt að nota eða breyta. Samkvæmt stefnu leyfisbókasafnsins getum við ekki gert þetta. Eða, ef við breyttum því og notum það, ættum við að senda kóðann okkar. Auðvitað vill enginn birta kóðann á vörum sínum, en þú getur líka varið þig fyrir þessu.
Greining á íhlutum sem eru notaðir í iðnaðarumhverfi. Við skulum ímynda okkur ímyndaða stöðu að við höfum loksins lokið þróun og gefið út nýjustu útgáfuna af örþjónustu okkar. Hann býr þarna frábærlega - viku, mánuð, ár. Við söfnum því ekki, við gerum ekki öryggiseftirlit, allt virðist vera í lagi. En skyndilega, tveimur vikum eftir útgáfu, birtist mikilvægur varnarleysi í Open Source íhlutnum, sem við notum í þessari tilteknu byggingu, í iðnaðarumhverfinu. Ef við skráum ekki hvað og hvar við notum, þá munum við einfaldlega ekki sjá þennan varnarleysi. Sum verkfæri hafa getu til að fylgjast með veikleikum í bókasöfnum sem nú eru notuð í greininni. Það er mjög gagnlegt.
Lögun:
- Mismunandi stefnur fyrir mismunandi þróunarstig.
- Vöktun á íhlutum í iðnaðarumhverfi.
- Eftirlit með bókasöfnum innan stofnunarinnar.
- Stuðningur við ýmis byggingarkerfi og tungumál.
- Greining á Docker myndum.
Nokkur dæmi um leiðtoga iðnaðarins sem stunda Open Source greiningu.
Eina ókeypis er þetta frá OWASP. Þú getur kveikt á því á fyrstu stigum, séð hvernig það virkar og hvað það styður. Í grundvallaratriðum eru þetta allt skýjavörur, eða á staðnum, en á bak við grunninn þeirra eru þær samt sendar á internetið. Þeir senda ekki bókasöfnin þín, heldur kjötkássa eða eigin gildi, sem þeir reikna út, og fingraför á netþjóninn sinn til að fá upplýsingar um tilvist veikleika.
Samþætting ferli
Jaðareftirlit bókasafna, sem er hlaðið niður frá utanaðkomandi aðilum. Við erum með ytri og innri geymslur. Til dæmis keyrir Event Central Nexus og við viljum tryggja að það séu engir veikleikar í geymslunni okkar með „mikilvæga“ eða „háa“ stöðu. Þú getur stillt umboð með því að nota Nexus Firewall Lifecycle tólið þannig að slíkar veikleikar séu fjarlægðir og lendi ekki í innri geymslunni.
Samþætting í CI. Á sama stigi með sjálfvirkum prófunum, einingaprófum og skiptingu í þróunarstig: dev, test, prod. Á hverju stigi geturðu hlaðið niður hvaða bókasöfnum sem er, notað hvað sem er, en ef það er eitthvað erfitt með „mikilvæga“ stöðuna, þá er kannski þess virði að vekja athygli þróunaraðila á þessu á útgáfustigi í framleiðslu.
Samþætting við gripi: Nexus og JFrog.
Aðlögun að þróunarumhverfi. Verkfærin sem þú velur ættu að vera samþætt við þróunarumhverfi. Framkvæmdaraðilinn verður að hafa aðgang að skönnunarniðurstöðum frá vinnustað sínum, eða getu til að skanna og athuga kóðann sjálfur með tilliti til veikleika áður en hann skuldbindur sig til CVS.
Samþætting geisladiska. Þetta er flottur eiginleiki sem ég er mjög hrifinn af og sem ég hef þegar talað um - að fylgjast með tilkomu nýrra veikleika í iðnaðarumhverfi. Það virkar eitthvað á þessa leið.
Við höfum Opinber íhlutageymslur - nokkur verkfæri fyrir utan og innri geymslan okkar. Við viljum að það innihaldi aðeins trausta hluti. Þegar við sendum umboðsbeiðni athugum við að hlaðið bókasafn sé ekki með veikleika. Ef það fellur undir ákveðnar stefnur sem við setjum og samræmum endilega við þróunina, þá hleðum við því ekki upp og erum beðin um að nota aðra útgáfu. Samkvæmt því, ef það er eitthvað mjög mikilvægt og slæmt á bókasafninu, þá mun verktaki ekki fá bókasafnið á uppsetningarstigi - láttu hann nota hærri eða lægri útgáfu.
- Við smíði athugum við að enginn hafi runnið neitt slæmt, að allir íhlutir séu öruggir og enginn hafi komið með neitt hættulegt á flash-drifið.
- Við höfum aðeins trausta hluti í geymslunni.
- Við uppsetningu athugum við aftur pakkann sjálfan: war, jar, DL eða Docker mynd til að tryggja að hann sé í samræmi við stefnuna.
- Þegar við förum inn í iðnaðinn fylgjumst við með því sem er að gerast í iðnaðarumhverfinu: mikilvægar veikleikar birtast eða birtast ekki.
Dynamic Analysis - DAST
Kvik greiningartól eru í grundvallaratriðum frábrugðin öllu því sem áður hefur verið sagt. Þetta er eins konar eftirlíking af vinnu notandans með forritinu. Ef þetta er vefforrit sendum við beiðnir, líkjum eftir vinnu viðskiptavinarins, smellum á hnappana að framan, sendum gervigögn úr eyðublaðinu: tilvitnanir, sviga, stafir í mismunandi kóðun, til að sjá hvernig forritið virkar og fer úr ytri gögn.
Sama kerfi gerir þér kleift að athuga veikleika sniðmáts í Open Source. Þar sem DAST veit ekki hvaða Open Source við erum að nota, kastar það einfaldlega „illgjarn“ mynstri og greinir svör netþjónsins:
- Já, það er vandamál með afrásarvæðingu hér, en ekki hér.
Það eru miklar áhættur í þessu, því ef þú framkvæmir þetta öryggispróf á sama bekk og prófunarmennirnir vinna með geta óþægilegir hlutir gerst.
- Mikið álag á netkerfi forritaþjónsins.
- Engar samþættingar.
- Geta til að breyta stillingum greindu forritsins.
- Það er enginn stuðningur við nauðsynlega tækni.
- Erfiðleikar við að setja upp.
Við lentum í aðstæðum þegar við loksins ræstum AppScan: við eyddum langan tíma í að reyna að fá aðgang að forritinu, fengum 3 reikninga og vorum ánægð - við munum loksins athuga allt! Við settum af stað skönnun og það fyrsta sem AppScan gerði var að fara inn á stjórnborðið, gata alla hnappa, breyta helmingnum af gögnunum og drepa svo netþjóninn algjörlega með -beiðnir. Þróun með prófun sagði:
- Krakkar, ertu að grínast?! Við gáfum þér reikninga og þú settir upp bás!
Íhuga hugsanlega áhættu. Helst skaltu undirbúa sérstakan stand til að prófa upplýsingaöryggi, sem verður einangraður frá restinni af umhverfinu að minnsta kosti einhvern veginn, og athugaðu stjórnborðið með skilyrðum, helst í handvirkri stillingu. Þetta er pentest - þær prósentur sem eftir eru af fyrirhöfn sem við erum ekki að íhuga núna.
Það er þess virði að íhuga að þú getur notað þetta sem hliðstæðu við álagsprófun. Á fyrsta stigi er hægt að kveikja á kraftmiklum skanna með 10-15 þráðum og sjá hvað gerist, en venjulega, eins og æfingin sýnir, ekkert gott.
Nokkur úrræði sem við notum venjulega.
Þess virði að undirstrika er „svissneskur hnífur“ fyrir hvaða öryggissérfræðing sem er. Það nota það allir og það er mjög þægilegt. Ný kynningarútgáfa af framtaksútgáfunni hefur nú verið gefin út. Ef það var áður bara sjálfstætt tól með viðbætur, nú eru verktaki loksins að búa til stóran netþjón þar sem hægt verður að stjórna nokkrum umboðsmönnum. Þetta er flott, mæli með að þú prófir það.
Samþætting ferli
Samþætting gerist nokkuð vel og einfaldlega: byrjaðu að skanna eftir vel heppnaða uppsetningu umsóknir um standinn og skönnun eftir árangursríka samþættingarprófun.
Ef samþættingarnar virka ekki eða það eru stubbar og spottaraðgerðir, þá er það tilgangslaust og gagnslaust - sama hvaða mynstur við sendum, þjónninn mun samt bregðast við á sama hátt.
- Helst, sérstakt prófunarstand.
- Áður en þú prófar skaltu skrifa niður innskráningarröðina.
- Prófun á stjórnunarkerfinu er eingöngu handvirk.
ferlið
Smá alhæft um ferlið almennt og um vinnu hvers verkfæris sérstaklega. Öll forrit eru mismunandi - eitt virkar betur með kraftmikilli greiningu, annað með kyrrstöðugreiningu, þriðja með OpenSource greiningu, pentests eða eitthvað allt annað, til dæmis viðburði með .
Hvert ferli þarfnast stjórnunar.
Til að skilja hvernig ferli virkar og hvar hægt er að bæta það þarftu að safna mælingum úr öllu sem þú getur fengið í hendurnar, þar á meðal framleiðslumælingar, mælikvarða úr verkfærum og frá gallamælum.
Allar upplýsingar eru gagnlegar. Nauðsynlegt er að skoða frá mismunandi sjónarhornum hvar þetta eða hitt tækið er betur notað, þar sem ferlið dregur sérstaklega. Það gæti verið þess virði að skoða viðbragðstíma þróunar til að sjá hvar hægt er að bæta ferlið miðað við tíma. Því fleiri gögn, því fleiri hluta er hægt að byggja frá efstu stigi til smáatriði hvers ferlis.
Þar sem allir kyrrstæðir og kraftmiklir greiningartæki hafa sín eigin API, eigin ræsingaraðferðir, meginreglur, sumir eru með tímaáætlun, aðrir ekki - við erum að skrifa verkfæri AppSec hljómsveitarstjóri, sem gerir þér kleift að búa til einn aðgangsstað inn í allt ferlið úr vörunni og stjórna því frá einum stað.
Stjórnendur, þróunaraðilar og öryggisverkfræðingar hafa einn aðgangsstað þar sem þeir geta séð hvað er í gangi, stillt og keyrt skönnun, fengið skannaniðurstöður og lagt fram kröfur. Við erum að reyna að hverfa frá pappírsvinnu, að þýða allt yfir í mannlegt, sem er notað af þróun - síður á Confluence með stöðu og mæligildi, galla í Jira eða í ýmsum gallasporum, eða samþætting í samstillt/ósamstillt ferli í CI /CD.
Lykilatriði
Verkfæri eru ekki aðalatriðið. Hugsaðu fyrst í gegnum ferlið - settu síðan verkfærin í framkvæmd. Verkfærin eru góð en dýr, svo þú getur byrjað á ferlinu og byggt upp samskipti og skilning á milli þróunar og öryggis. Frá öryggissjónarmiði er engin þörf á að "stöðva" allt. Frá þróunarsjónarmiði, ef það er eitthvað mikið mega ofur gagnrýnið, þá þarf að útrýma því og ekki loka augunum fyrir vandamálinu.
Vörugæði - sameiginlegt markmið bæði öryggi og þróun. Við gerum eitt, við reynum að tryggja að allt virki rétt og það sé engin orðsporsáhætta eða fjárhagslegt tap. Þess vegna kynnum við DevSecOps, SecDevOps nálgun til að bæta samskipti og bæta gæði vörunnar.
Byrjaðu á því sem þú hefur nú þegar: kröfur, byggingarlist, hlutapróf, þjálfun, leiðbeiningar. Það er engin þörf á að beita öllum starfsháttum strax við öll verkefni - hreyfa sig ítrekað. Það er enginn einn staðall - tilraun og prófa mismunandi aðferðir og lausnir.
Það er jafnmerki á milli upplýsingaöryggisgalla og virknigalla.
Gerðu allt sjálfvirktsem hreyfist. Hvað sem hreyfist ekki, hreyfðu það og gerðu það sjálfvirkt. Ef eitthvað er gert í höndunum er það ekki góður hluti af ferlinu. Kannski er þess virði að endurskoða það og gera það sjálfvirkt líka.
Ef stærð IS liðsins er lítil - nota Security Champions.
Kannski mun það sem ég talaði um ekki henta þér og þú munt koma með eitthvað þitt eigið - og það er gott. En veldu verkfæri út frá kröfum fyrir ferlið þitt. Ekki horfa á það sem samfélagið segir, að þetta tæki sé slæmt og þetta sé gott. Kannski er hið gagnstæða satt fyrir vöruna þína.
Kröfur um verkfæri.
- Lágt stig rangt jákvætt.
- Fullnægjandi greiningartími.
- The þægindi af notkun.
- Framboð á samþættingum.
- Skilningur á vöruþróunarleiðinni.
- Möguleiki á að sérsníða verkfæri.
Skýrsla Yuri var valin ein sú besta á DevOpsConf 2018. Til að kynnast enn áhugaverðari hugmyndum og hagnýtum tilfellum, komdu til Skolkovo 27. og 28. maí innan . Enn betra, ef þú ert tilbúinn til að deila reynslu þinni, þá fyrir skýrsluna til 21. apríl.
Heimild: www.habr.com