Ons het 2 kode-ontleders, 4 dinamiese toetsinstrumente, ons eie handwerk en 250 skrifte gehad. Nie dat dit alles in die huidige proses nodig was nie, maar sodra jy DevSecOps begin implementeer het, moet jy tot die einde toe gaan.
. Karakters geskep deur Justin Roiland en Dan Harmon.
Wat is SecDevOps? Wat van DevSecOps? Wat is die verskille? Toepassingsekuriteit - waaroor gaan dit? Hoekom werk die klassieke benadering nie meer nie? Al hierdie vrae ken die antwoord Yuri Shabalin van Swaardvissekuriteit. Yuriy sal alles in detail beantwoord en die probleme van die oorgang van die klassieke toepassingsekuriteitsmodel na die DevSecOps-proses ontleed: hoe om die integrasie van die veilige ontwikkelingsproses in die DevOps-proses behoorlik te benader en niks te breek nie, hoe om deur die hoofstadia te gaan van sekuriteitstoetsing, watter gereedskap gebruik kan word, hoe om dit te verskil en hoe om dit behoorlik op te stel om slaggate te vermy.
Oor spreker: Yuri Shabalin - Hoofsekuriteitsargitek in die maatskappy Swaardvissekuriteit. Verantwoordelik vir die implementering van SSDL, vir die algehele integrasie van toepassingsanalise-instrumente in 'n enkele ontwikkeling- en toetsekosisteem. 7 jaar ondervinding in inligtingsekuriteit. Werk by Alfa-Bank, Sberbank en Positive Technologies, wat sagteware ontwikkel en dienste verskaf. Spreker van internasionale konferensies ZerONights, PHDays, RISSPA, OWASP.
Toepassingsekuriteit: waaroor gaan dit?
Aansoek Sekuriteit is die sekuriteitsafdeling wat verantwoordelik is vir toepassingsekuriteit. Dit gaan nie oor infrastruktuur of netwerksekuriteit nie, maar oor wat ons skryf en waaraan ontwikkelaars werk – dit is die foute en kwesbaarhede van die toepassing self.
rigting - Sekuriteitsontwikkeling lewensiklus - Ontwikkel deur Microsoft. Die diagram toon die kanonieke SDLC-model, waarvan die hooftaak die deelname van sekuriteit in elke stadium van ontwikkeling is, van vereistes tot vrystelling en vrystelling tot produksie. Microsoft het besef dat daar te veel foute in die prom is, daar is meer van hulle en iets moet daaraan gedoen word, en hulle het hierdie benadering voorgestel, wat kanoniek geword het.
Toepassingsekuriteit en SSDL is nie daarop gemik om kwesbaarhede op te spoor nie, soos algemeen geglo word, maar om hul voorkoms te voorkom. Met verloop van tyd is die kanonieke benadering van Microsoft verbeter, ontwikkel, dit het 'n dieper gedetailleerde onderdompeling.
Die kanonieke SDLC is baie gedetailleerd in verskeie metodologieë - OpenSAMM, BSIMM, OWASP. Die metodologieë verskil, maar is oor die algemeen soortgelyk.
Bou sekuriteit in volwassenheidsmodel
Ek hou die meeste daarvan BSIMM - . Die basis van die metodologie is die verdeling van die Toepassingsekuriteitsproses in 4 domeine: Bestuur, Intelligensie, SSDL raakpunte en Ontplooiing. Elke domein het 12 praktyke, wat as 112 aktiwiteite voorgestel word.
Elk van die 112 aktiwiteite het 3 volwassenheidsvlakke: beginner, intermediêr en gevorderd. Jy kan al 12 praktyke in afdelings bestudeer, dinge kies wat vir jou belangrik is, uitvind hoe om dit te implementeer en geleidelik elemente byvoeg, byvoorbeeld statiese en dinamiese kode-analise of kode-hersiening. Jy stel 'n plan op en werk rustig daarvolgens as deel van die implementering van die geselekteerde aktiwiteite.
Hoekom DevSecOps
DevOps is 'n algehele groot proses waarin daar na sekuriteit omgesien moet word.
aanvanklik sekuriteitsondersoeke behels. In die praktyk was die aantal sekuriteitspanne baie kleiner as nou, en hulle het nie as deelnemers aan die proses opgetree nie, maar as 'n beheer- en oorsigliggaam wat eise daaraan stel en die kwaliteit van die produk nagaan aan die einde van die vrystelling. Dit is 'n klassieke benadering waarin sekuriteitspanne agter 'n muur van ontwikkeling was en nie aan die proses deelgeneem het nie.
Die hoofprobleem is dat inligtingsekuriteit apart van ontwikkeling is. Gewoonlik is dit 'n soort IB-stroombaan en dit bevat 2-3 groot en duur gereedskap. Een keer elke ses maande kom die bronkode of toepassing om getoets te word, en een keer per jaar . Dit alles lei daartoe dat die vrystellingdatums vir die bedryf uitgestel word, en 'n groot aantal kwesbaarhede van outomatiese gereedskap val op die ontwikkelaar. Dit is onmoontlik om dit alles uitmekaar te haal en te herstel, want selfs in die vorige ses maande is die resultate nie uitmekaar gehaal nie, en hier is 'n nuwe bondel.
In die loop van ons maatskappy se werk sien ons dat sekuriteit in alle gebiede en industrieë verstaan dat dit tyd is om die ontwikkeling in een wiel in te haal en te draai - in . Die DevSecOps-paradigma pas perfek by ratse ontwikkelingsmetodologie, implementering, ondersteuning en deelname aan elke vrystelling en herhaling.
Oorgang na DevSecOps
Die belangrikste woord in die Sekuriteitsontwikkelingslewensiklus is "proses". U moet dit verstaan voordat u daaraan dink om gereedskap te koop.
Om net gereedskap by die DevOps-proses in te sluit is nie genoeg nie – kommunikasie en begrip tussen prosesdeelnemers is belangrik.
Mense is belangriker as gereedskap
Dikwels begin die beplanning van 'n veilige ontwikkelingsproses met die keuse en aankoop van 'n instrument, en eindig met pogings om die instrument in die huidige proses te integreer, wat pogings bly. Dit lei tot hartseer gevolge, want alle gereedskap het hul eie kenmerke en beperkings.
'n Algemene geval is wanneer die sekuriteitsafdeling 'n goeie, duur instrument met 'n wye verskeidenheid kenmerke gekies het en na die ontwikkelaars gekom het om dit in die proses in te bou. Maar dit werk nie uit nie - die proses is so ontwerp dat die beperkings van 'n reeds aangekoopte instrument nie by die huidige paradigma pas nie.
Beskryf eers watter resultaat jy wil hê en hoe die proses sal lyk. Dit sal help om die rolle van die instrument en sekuriteit in die proses te verstaan.
Begin met wat reeds in gebruik is
Voordat jy duur gereedskap koop, kyk na wat jy reeds het. Elke maatskappy het sekuriteitsvereistes wat van toepassing is op ontwikkeling, daar is tjeks, pentests - hoekom verander dit nie alles in 'n verstaanbare en gerieflike vorm vir almal nie?
Gewoonlik is die vereistes 'n papier Talmoed wat op 'n rak lê. Daar was 'n geval toe ons na die maatskappy kom om na die prosesse te kyk en hulle te vra om die sekuriteitsvereistes vir die sagteware te wys. Die spesialis wat dit gedoen het, het lank gesoek:
- Nou, iewers in die notas was daar 'n pad waar hierdie dokument lê.
Gevolglik het ons die dokument 'n week later ontvang.
Vir vereistes, tjeks en meer, skep 'n bladsy, byvoorbeeld by Samevloeiing - dit is gerieflik vir almal.
Dit is makliker om te herformateer wat reeds daar is en dit te gebruik om te begin.
Gebruik Security Champions
Gewoonlik, in 'n gemiddelde maatskappy vir 100-200 ontwikkelaars, is daar een sekuriteitsbeampte wat verskeie funksies verrig en nie fisies tyd het om alles na te gaan nie. Selfs as hy sy bes probeer, sal hy alleen nie al die kode wat die ontwikkeling genereer, nagaan nie. Vir sulke gevalle is 'n konsep ontwikkel - .
Security Champions is 'n persoon binne die ontwikkelingspan wat belangstel in die sekuriteit van jou produk.
Sekuriteitskampioen is 'n toegangspunt vir die ontwikkelingspan en 'n sekuriteitsevangelis het almal saamgerol.
Gewoonlik, wanneer 'n sekuriteitsbeampte na die ontwikkelingspan kom en 'n fout in die kode uitwys, kry hy 'n verbaasde antwoord:
- En wie is jy? Ek sien jou vir die eerste keer. Alles is goed met my - my senior vriend het "apply" op die kode hersiening gesit, ons gaan aan!
Dit is 'n tipiese situasie, want daar is baie meer vertroue in seniors of net spanmaats met wie die ontwikkelaar voortdurend interaksie het by die werk en in kode-hersiening. As die Sekuriteitskampioen in plaas van 'n veiligheidswag die fout en die gevolge uitwys, sal sy woord meer gewig hê.
Ook, ontwikkelaars ken hul kode beter as enige sekuriteitsman. Vir 'n persoon wat ten minste 5 projekte in 'n statiese analise-instrument het, is dit gewoonlik moeilik om al die nuanses te onthou. Sekuriteitskampioene ken hul produk: wat in wisselwerking is met wat en waarna om in die eerste plek te kyk - hulle is meer doeltreffend.
Oorweeg dit dus om Security Champions te implementeer en die invloed van die sekuriteitspan uit te brei. Vir die kampioen self is dit ook nuttig: professionele ontwikkeling in 'n nuwe veld, die uitbreiding van die tegniese horisonne, die pomp van tegniese, bestuurs- en leierskapsvaardighede, die verhoging van markwaarde. Dit is een of ander element van sosiale ingenieurswese, jou "oë" in die ontwikkelingspan.
Toets stadiums
sê dat 20% van die pogings 80% van die resultate gee. Hierdie 20% is toepassingsontledingspraktyke wat geoutomatiseer kan en behoort te word. Voorbeelde van sulke aktiwiteite is statiese analise − SAST, dinamiese analise - DAST и oopbronbeheer. Ek sal jou meer vertel oor aktiwiteite, sowel as oor gereedskap, watter kenmerke ons gewoonlik teëkom wanneer dit in die proses bekendgestel word, en hoe om dit korrek te doen.
Hoof gereedskap probleme
Ek sal die probleme uitlig wat relevant is vir alle instrumente wat aandag verg. Ek sal hulle in meer besonderhede ontleed om nie verder te herhaal nie.
Lang analise tyd. As dit 30 minute neem vanaf die toewyding tot die vrystelling vir alle toetse en samestelling, dan sal die inligtingsekuriteitskontroles 'n dag neem. Niemand sal dus die proses vertraag nie. Oorweeg hierdie kenmerk en maak gevolgtrekkings.
Hoog Vals Negatief of Vals Positief. Alle produkte is anders, almal gebruik verskillende raamwerke en hul eie koderingstyl. Op verskillende kodebasisse en tegnologieë kan gereedskap verskillende vlakke van Vals Negatief en Vals Positief wys. So kyk wat is in van jou maatskappye en vir jou toepassings sal 'n goeie en betroubare resultaat toon.
Geen integrasies met bestaande gereedskap nie. Kyk na die gereedskap in terme van integrasies met wat jy reeds gebruik. Byvoorbeeld, as jy Jenkins of TeamCity het, gaan die integrasie van gereedskap met hierdie sagteware na, en nie met GitLab CI, wat jy nie gebruik nie.
Gebrek aan of oormatige kompleksiteit van aanpassing. As die instrument nie 'n API het nie, hoekom is dit dan nodig? Alles wat in die koppelvlak gedoen kan word, moet deur die API beskikbaar wees. Ideaal gesproke moet die instrument die vermoë hê om tjeks aan te pas.
Geen produk ontwikkeling padkaart. Ontwikkeling staan nie stil nie, ons gebruik altyd nuwe raamwerke en funksies, herskryf ou kode in nuwe tale. Ons wil seker maak dat die instrument wat ons koop nuwe raamwerke en tegnologieë sal ondersteun. Daarom is dit belangrik om te weet dat die produk 'n ware en korrekte het ontwikkeling.
Proseskenmerke
Benewens die kenmerke van die gereedskap, oorweeg die kenmerke van die ontwikkelingsproses. Byvoorbeeld, inmenging met ontwikkeling is 'n tipiese fout. Kom ons kyk watter ander kenmerke oorweeg moet word en waaraan die sekuriteitspan moet aandag gee.
Om nie die ontwikkeling te ontwrig en spertye vry te stel nie, skep verskillende reëls en anders wys stoppers - kriteria om die bouproses te stop in die teenwoordigheid van kwesbaarhede - vir verskillende omgewings. Ons verstaan byvoorbeeld dat die huidige tak na 'n ontwikkelingstand of UAT gaan, so ons stop nie en sê nie:
- Jy het kwesbaarhede hier, jy sal nêrens verder gaan nie!
Op hierdie stadium is dit belangrik om ontwikkelaars te vertel dat daar sekuriteitskwessies is om na uit te kyk.
Die teenwoordigheid van kwesbaarhede is nie 'n hindernis vir verdere toetsing nie: handleiding, integrasie of handleiding. Aan die ander kant moet ons op een of ander manier die sekuriteit van die produk verbeter, en sodat die ontwikkelaars nie punte kry op wat die sekuriteit vind nie. Daarom doen ons dit soms: by die staanplek, wanneer dit na die ontwikkelingsomgewing uitrol, stel ons bloot die ontwikkeling in kennis:
- Ouens, julle het probleme, let asseblief daarop.
Op die UAT-stadium wys ons weer waarskuwings oor kwesbaarhede, en by die uitgangstadium in die prom sê ons:
“Manne, ons het julle verskeie kere gewaarsku, julle het niks gedoen nie – ons sal julle nie hiermee uitlaat nie.
As ons praat oor kode en dinamika, dan is dit nodig om slegs die kwesbaarhede van die kenmerke en kode wat pas in hierdie kenmerk geskryf is, te wys en te waarsku. As die ontwikkelaar die knoppie met 3 pixels geskuif het en ons sê vir hom dat hy 'n SQL-inspuiting daar het en daarom dringend reggemaak moet word, is dit verkeerd. Kyk net na wat nou geskryf is, en na die verandering wat by die aansoek kom.
Kom ons sê ons het 'n funksionele gebrek - die manier waarop die toepassing nie behoort te werk nie: geld word nie oorgedra nie, wanneer jy op die knoppie klik, is daar geen oorgang na die volgende bladsy nie, of die produk laai nie. Sekuriteitsgebreke - dit is dieselfde gebreke, maar nie in die konteks van die aansoek nie, maar sekuriteit.
Nie alle sagtewarekwaliteitkwessies is sekuriteitskwessies nie. Maar alle sekuriteitsprobleme hou verband met die kwaliteit van die sagteware. Sherif Mansour, Expedia.
Aangesien alle kwesbaarhede dieselfde defekte is, moet hulle op dieselfde plek as alle ontwikkelingsdefekte geleë wees. Vergeet dus van verslae en skrikwekkende PDF's wat niemand lees nie.
Toe ek vir 'n ontwikkelingsmaatskappy gewerk het, het ek 'n verslag van statiese analise-instrumente ontvang. Ek het dit oopgemaak, geskrik, koffie gemaak, 350 bladsye deurgeblaai, dit toegemaak en aan die werk gegaan. Groot verslae is dooie verslae. Gewoonlik gaan hulle nêrens heen nie, e-posse word uitgevee, vergeet, verlore, of die besigheid sê dit neem risiko's.
Wat om te doen? Ons skakel eenvoudig die bevestigde defekte wat ons gevind het om in 'n vorm wat gerieflik is vir ontwikkeling, voeg dit byvoorbeeld by die agterstand in Jira. Defekte word geprioritiseer en uitgeskakel in volgorde van prioriteit saam met funksionele defekte en toetsdefekte.
Statiese analise - SAST
Dit is kode-analise vir kwesbaarhede., maar dit is nie dieselfde as SonarQube nie. Ons kyk nie net vir patrone of styl nie. Die ontleding gebruik 'n aantal benaderings: volgens kwesbaarheidsboom, deur , deur konfigurasielêers te ontleed. Dit is al vir die kode self.
Voordele van die benadering: die identifisering van kwesbaarhede in kode op 'n vroeë stadium van ontwikkelingwanneer daar geen staanders en gereedgemaakte gereedskap is nie, en inkrementele skandering vermoë: skandeer 'n kodegedeelte wat verander het, en slegs die kenmerk wat ons tans doen, wat die skanderingstyd verminder.
Nadele is die gebrek aan ondersteuning vir die vereiste tale.
Vereiste integrasies, wat volgens my subjektiewe mening in die gereedskap moet wees:
- Integrasie-instrument: Jenkins, TeamCity en Gitlab CI.
- Ontwikkelingsomgewing: Intellij IDEA, Visual Studio. Dit is geriefliker vir 'n ontwikkelaar om nie in 'n onverstaanbare koppelvlak te klim wat nog onthou moet word nie, maar om al die nodige integrasies en kwesbaarhede wat hy reg by die werkplek in sy eie ontwikkelingsomgewing gevind het, te sien.
- Kode hersiening: SonarQube en handleiding hersiening.
- Defek-spoorsnyers: Jira en Bugzilla.
Die prent toon sommige van die beste verteenwoordigers van statiese analise.
Dit is nie die gereedskap wat saak maak nie, maar die proses, so daar is oopbronoplossings wat ook goed is om die proses uit te voer.
SAST Open Source sal nie 'n groot aantal kwesbaarhede of komplekse DataFlow vind nie, maar dit kan en moet gebruik word wanneer 'n proses gebou word. Hulle help om te verstaan hoe die proses gebou sal word, wie sal reageer op foute, wie sal rapporteer, wie sal rapporteer. As jy die eerste fase van die bou van die sekuriteit van jou kode wil uitvoer, gebruik Open Source-oplossings.
Hoe kan dit geïntegreer word as jy aan die begin van die reis is, jy het niks: nóg CI, nóg Jenkins, nóg TeamCity? Oorweeg proses-integrasie.
Integrasie op CVS-vlak
As jy Bitbucket of GitLab het, kan jy integrasie op die vlak doen .
Per gebeurtenis trek versoek, pleeg. Jy skandeer die kode en wys in die boustatus dat die sekuriteitskontrole geslaag of misluk het.
Terugvoer. Natuurlik is terugvoer altyd nodig. As jy dit net aan die sekuriteitskant gedoen het, dit in 'n boks gesit het en vir niemand iets daarvan vertel het nie, en dan 'n klomp goggas aan die einde van die maand gegooi het, is dit nie reg nie en nie goed nie.
Integrasie met kode hersiening stelsel
Een keer het ons die AppSec-tegniese gebruiker as die verstekbeoordelaar in 'n aantal belangrike projekte gestel. Afhangende van of foute in die nuwe kode gevind is of daar geen foute is nie, plaas die beoordelaar die status op die trekversoek om te "aanvaar" of "werk nodig" - óf alles is in orde, óf jy moet finaliseer en skakel na wat presies te finaliseer. Vir integrasie met die weergawe wat vrygestel word, het ons samesmelting gedeaktiveer as die IS-toets nie geslaag is nie. Ons het dit by die handmatige kode-hersiening ingesluit, en die res van die prosesdeelnemers het die sekuriteitstatusse vir hierdie spesifieke proses gesien.
Integrasie met SonarQube
Baie het in terme van kode kwaliteit. Dit is dieselfde hier - jy kan dieselfde hekke net vir SAST-instrumente maak. Daar sal dieselfde koppelvlak wees, dieselfde kwaliteit hek, net dit sal genoem word veiligheidshek. En ook, as jy 'n proses het wat met SonarQube opgestel is, kan jy alles maklik daar integreer.
Integrasie op GI-vlak
Ook hier is alles redelik eenvoudig:
- Op gelyke voet met outotoetse, eenheidstoetse.
- Indeling volgens ontwikkelingstadia: dev, toets, prod. Verskillende stelle reëls kan ingesluit word, of verskillende mislukkingstoestande: ons stop die byeenkoms, ons stop nie die byeenkoms nie.
- Sinchroniese/Asinchrone hardloop. Ons wag vir die einde van die sekuriteitstoetse of ons wag nie. Dit wil sê, ons het hulle net geloods en aanbeweeg, en dan kry ons 'n status dat alles goed of sleg is.
Dit is alles in 'n perfekte pienk wêreld. In die werklike lewe is dit nie die geval nie, maar ons streef. Die resultaat van die uitvoer van sekuriteitskontroles moet soortgelyk wees aan die resultate van eenheidstoetse.
Ons het byvoorbeeld 'n groot projek geneem en besluit dat ons dit nou sal skandeer met SAST - OK. Ons het hierdie projek in SAST ingeskuif, dit het ons 20 000 kwesbaarhede gegee, en ons het 'n sterk besluit geneem dat alles in orde is. 20 000 kwesbaarhede is ons tegniese skuld. Ons sal die skuld in 'n boks sit, ons sal dit stadig op hark en foute in defekspoorders begin. Huur 'n maatskappy, doen alles self, of laat Security Champions ons help, en tegniese skuld sal afneem.
En alle nuwe kwesbaarhede wat in die nuwe kode verskyn, moet op dieselfde manier uitgeskakel word as foute in 'n eenheid of in outotoetse. Relatief gesproke het die byeenkoms begin, weggery, twee toetse en twee sekuriteitstoetse het geval. OK - ons het gegaan, gekyk wat gebeur het, een reggemaak, die tweede reggemaak, die volgende keer gery - alles is reg, geen nuwe kwesbaarhede het verskyn nie, die toetse het nie misluk nie. As hierdie taak dieper is en jy moet dit goed verstaan, of die herstel van kwesbaarhede beïnvloed groot lae van wat onder die kap lê: 'n fout word in die defekspoorder ingebring, dit word geprioritiseer en reggemaak. Ongelukkig is die wêreld nie perfek nie en toetse misluk soms.
'n Voorbeeld van 'n sekuriteitshek is 'n analoog van 'n kwaliteithek, in terme van die teenwoordigheid en aantal kwesbaarhede in die kode.
Ons integreer met SonarQube - die inprop is geïnstalleer, alles is baie gerieflik en cool.
Ontwikkelingsomgewing-integrasie
Integrasie opsies:
- Begin 'n skandering vanaf die ontwikkelingsomgewing selfs voor die commit.
- Bekyk resultate.
- Ontleding van resultate.
- Sinchronisasie met die bediener.
Dit is hoe dit lyk om resultate vanaf die bediener te kry.
In ons ontwikkelingsomgewing dit verskyn net 'n bykomende item wat sê dat sulke kwesbaarhede tydens die skandering gevind is. U kan die kode onmiddellik wysig, aanbevelings sien en . Dit alles is by die ontwikkelaar se werkplek geleë, wat baie gerieflik is - jy hoef nie die res van die skakels te volg en iets ekstra te kyk nie.
Open Source
Dit is my gunsteling onderwerp. Almal gebruik Open Source biblioteke - hoekom skryf jy 'n klomp krukke en fietse as jy 'n klaargemaakte biblioteek kan vat waarin alles reeds geïmplementeer is?
Natuurlik is dit waar, maar biblioteke word ook deur mense geskryf, sluit ook sekere risiko's in, en daar is ook kwesbaarhede wat periodiek, of voortdurend, aangemeld word. Daarom is daar 'n volgende stap in toepassingsekuriteit - dit is die ontleding van oopbronkomponente.
Oopbronanalise - OSA
Die instrument sluit drie hoofstappe in.
Vind kwesbaarhede in biblioteke. Byvoorbeeld, die instrument weet dat ons 'n soort biblioteek gebruik, en dit in of in foutopsporers is daar 'n paar kwesbaarhede wat verband hou met hierdie weergawe van die biblioteek. As jy probeer om dit te gebruik, sal die instrument jou waarsku dat die biblioteek kwesbaar is en jou aanraai om 'n ander weergawe te gebruik waar daar geen kwesbaarhede is nie.
Ontleding van lisensie suiwerheid. Dit is nog nie baie gewild by ons nie, maar as jy met 'n vreemde land werk, dan kan jy daar periodiek 'n aanval kry vir die gebruik van 'n oopbron-komponent wat nie gebruik of gewysig kan word nie. Volgens die beleid van die gelisensieerde biblioteek kan ons dit nie doen nie. Of, as ons dit gewysig het en dit gebruik, moet ons ons kode plaas. Natuurlik wil niemand die kode van hul produkte plaas nie, maar jy kan jouself ook hierteen beskerm.
Analise van komponente wat in 'n industriële omgewing gebruik word. Stel jou 'n hipotetiese situasie voor dat ons uiteindelik die ontwikkeling voltooi het en die jongste vrystelling van ons mikrodiens aan die bedryf vrygestel het. Hy woon heerlik daar – 'n week, 'n maand, 'n jaar. Ons haal dit nie af nie, ons doen nie sekuriteitskontroles nie, dit lyk of alles in orde is. Maar skielik, twee weke na die vrystelling, kom 'n kritieke kwesbaarheid in die Open Source-komponent uit, wat ons in hierdie spesifieke samestelling in die industriële omgewing gebruik. As ons nie aanteken wat en waar ons gebruik nie, sal hierdie kwesbaarheid eenvoudig nie gesien word nie. Sommige instrumente het die vermoë om kwesbaarhede te monitor in biblioteke wat tans in prom gebruik word. Dit is baie nuttig.
kenmerke:
- Verskillende beleide vir verskillende stadiums van ontwikkeling.
- Monitor komponente in 'n industriële omgewing.
- Beheer van biblioteke in die kontoer van die organisasie.
- Ondersteuning vir verskeie boustelsels en tale.
- Ontleding van Docker-beelde.
'n Paar voorbeelde van leiers in die veld wat betrokke is by die ontleding van Oopbron.
Die enigste gratis een is van OWASP. Jy kan dit in die eerste stadiums aanskakel, sien hoe dit werk en wat dit ondersteun. Basies is dit alles wolkprodukte, of op die perseel, maar agter hul basis gaan hulle steeds na die internet. Hulle stuur nie jou biblioteke nie, maar hashes of hul waardes wat hulle bereken, en vingerafdrukke na hul bediener om nuus van die teenwoordigheid van kwesbaarhede te ontvang.
Proses-integrasie
Omtrek biblioteek beheerwat van eksterne bronne afgelaai word. Ons het eksterne en interne bewaarplekke. Ons het byvoorbeeld Nexus binne Event Central, en ons wil seker maak dat daar geen kwesbaarhede met 'n "kritieke" of "hoë" status in ons bewaarplek is nie. Jy kan instaanbediener opstel met die Nexus Firewall Lifecycle-nutsding sodat sulke kwesbaarhede afgesny word en nie by die interne bewaarplek ingesluit word nie.
CI integrasie. Op dieselfde vlak met outotoetse, eenheidstoetse en verdeling in ontwikkelingstadia: dev, toets, prod. In elke stadium kan jy enige biblioteke aflaai, enigiets gebruik, maar as daar iets moeilik is met die "kritieke" status, moet jy waarskynlik die aandag van ontwikkelaars hierop vestig op die stadium van die aanvang van die prom.
Artefak-integrasie: Nexus en JFrog.
Integrasie in die ontwikkelingsomgewing. Die gereedskap wat u kies, moet integrasie met ontwikkelingsomgewings hê. Die ontwikkelaar moet toegang tot die skanderingsresultate vanaf sy werkplek hê, of die vermoë hê om die kode vir kwesbaarhede te skandeer en na te gaan voordat dit in CVS gepleeg word.
CD-integrasie. Dit is 'n oulike kenmerk waarvan ek baie hou en waaroor ek reeds gepraat het - die monitering van die opkoms van nuwe kwesbaarhede in 'n industriële omgewing. Dit werk so.
Ons het Openbare komponentbewaarplekke - 'n paar gereedskap buite, en ons interne bewaarplek. Ons wil hê dat slegs betroubare komponente daarin moet wees. Wanneer 'n versoek volmag word, kontroleer ons dat die afgelaaide biblioteek geen kwesbaarhede het nie. As dit onder sekere beleide val wat ons stel en noodwendig met die ontwikkeling koördineer, dan laai ons dit nie op nie en kry ons 'n afwysing om 'n ander weergawe te gebruik. Gevolglik, as daar iets regtig krities en sleg in die biblioteek is, sal die ontwikkelaar nie die biblioteek ontvang nie, selfs in die installasiestadium - laat hom 'n weergawe hoër of laer gebruik.
- Wanneer ons bou, kyk ons dat niemand iets sleg gegly het nie, dat alle komponente veilig is en dat niemand iets gevaarliks op die flash drive gebring het nie.
- Ons het slegs betroubare komponente in die bewaarplek.
- Wanneer ons ontplooi, kyk ons weer na die pakket self: oorlog, jar, DL of Docker-beeld vir die feit dat dit aan die beleid voldoen.
- Wanneer ons die industriële omgewing betree, monitor ons wat in die industriële omgewing gebeur: kritieke kwesbaarhede verskyn of verskyn nie.
Dinamiese analise - DAST
Dinamiese analise-instrumente verskil fundamenteel van alles wat voorheen gesê is. Dit is 'n soort nabootsing van die gebruiker se werk met die toepassing. As dit 'n webtoepassing is, stuur ons versoeke wat die werk van die kliënt naboots, klik op die knoppies aan die voorkant, stuur kunsmatige data vanaf die vorm: aanhalings, hakies, karakters in verskillende enkoderings om te kyk hoe die toepassing werk en ekstern verwerk. data.
Dieselfde stelsel laat jou toe om te kyk vir sjabloonkwesbaarhede in Open Source. Aangesien DAST nie weet watter oopbron ons gebruik nie, gooi dit eenvoudig "kwaadwillige" patrone en ontleed die bediener se antwoorde:
- Ja, daar is 'n deserialiseringsprobleem hier, maar nie hier nie.
Daar is groot risiko's hierin, want as jy hierdie sekuriteitstoets op dieselfde staander doen waarmee die toetsers werk, kan onaangename dinge gebeur.
- Hoë las op die toepassingsbedienernetwerk.
- Geen integrasies nie.
- Die vermoë om die instellings van die geanaliseerde toepassing te verander.
- Daar is geen ondersteuning vir die nodige tegnologieë nie.
- Moeilikheid om te stel.
Ons het 'n situasie gehad toe ons uiteindelik AppScan bekendgestel het: ons het toegang tot die toepassing vir 'n lang tyd uitgeskakel, 3 rekeninge ontvang en was verheug - uiteindelik sal ons alles nagaan! Ons het 'n skandering van stapel gestuur, en die eerste ding wat AppScan gedoen het, was om in die administrasiepaneel te kom, al die knoppies deur te steek, die helfte van die data te verander en dan die bediener heeltemal dood te maak met sy eie -versoeke. Ontwikkeling met toetsing het gesê:
“Kêrels, maak julle ’n grap?! Ons het jou rekeninge gegee, en jy het die stand gesit!
Oorweeg moontlike risiko's. Ideaal gesproke, berei 'n aparte staanplek voor vir die toets van inligtingsekuriteit, wat ten minste op een of ander manier van die res van die omgewing geïsoleer sal wees, en kontroleer voorwaardelik die administrasiepaneel, verkieslik in die handmodus. Dit is 'n pentest - daardie oorblywende persentasies pogings wat ons nie nou oorweeg nie.
Dit is die moeite werd om te oorweeg dat u dit as 'n analoog van lastoetsing kan gebruik. In die eerste stadium kan jy die dinamiese skandeerder in 10-15 drade aanskakel en kyk wat gebeur, maar gewoonlik, soos die praktyk toon, niks goed nie.
'n Paar hulpbronne wat ons gewoonlik gebruik.
Die moeite werd om uit te lig is die "Switserse mes" vir enige sekuriteitspersoon. Almal gebruik dit en dit is baie gerieflik. 'n Nuwe demo-weergawe van die ondernemingsuitgawe is nou vrygestel. As dit vroeër net 'n alleenstaande hulpprogram met inproppe was, maak ontwikkelaars nou uiteindelik 'n groot bediener vanwaar dit moontlik sal wees om verskeie agente te bestuur. Dit is gaaf, ek beveel aan dat jy dit probeer.
Proses-integrasie
Die integrasie is redelik goed en eenvoudig: begin skandering na suksesvolle installasie toepassings op die staanplek en skandering na suksesvolle integrasietoetsing.
As die integrasies nie werk nie of daar stompe en skynfunksies is, is dit betekenisloos en nutteloos - maak nie saak watter patroon ons stuur nie, die bediener sal steeds op dieselfde manier reageer.
- Ideaal gesproke 'n aparte toetsbank.
- Voordat u toets, skryf die aanmeldvolgorde neer.
- Toetsing van die administrasiestelsel is slegs handmatig.
proses
'n Bietjie veralgemeen oor die proses in die algemeen en oor die werk van elke instrument, in die besonder. Alle toepassings verskil - een werk beter met dinamiese analise, 'n ander met statiese analise, die derde met OpenSource analise, pentests, of iets anders in die algemeen, byvoorbeeld gebeurtenisse met .
Elke proses moet beheer word.
Om te verstaan hoe die proses werk en waar dit verbeter kan word, moet jy metrieke insamel van alles wat jy in die hande kan kry, insluitend produksiestatistieke, metrieke van gereedskap en defekspoorders.
Enige inligting is nuttig. Dit is nodig om in verskeie afdelings te kyk waar hierdie of daardie hulpmiddel beter gebruik word, waar die proses spesifiek sak. Dit kan die moeite werd wees om na ontwikkelingsreaksietyd te kyk om te sien waar die proses op grond van tyd verbeter kan word. Hoe meer data, hoe meer snitte kan gebou word vanaf die boonste vlak tot by die besonderhede van elke proses.
Aangesien alle statiese en dinamiese ontleders hul eie API's, hul eie bekendstellingsmetodes, beginsels het, sommige het skeduleers, ander nie - ons skryf 'n instrument AppSec Orchestrator, wat jou toelaat om 'n enkele toegangspunt tot die hele proses vanaf die produk te maak en dit vanaf een punt te bestuur.
Bestuurders, ontwikkelaars en sekuriteitsingenieurs het een toegangspunt vanwaar hulle kan sien wat loop, skanderings opstel en laat loop, skanderingsresultate kry en vereistes indien. Ons probeer wegbeweeg van stukkies papier, vertaal alles in 'n menslike een wat ontwikkeling gebruik - bladsye oor Samevloeiing met status en maatstawwe, defekte in Jira of in verskeie defekspoorders, of inbedding in 'n sinchrone / asinchroniese proses in CI / CD.
Belangrike take
Die gereedskap maak nie saak nie. Dink eers oor die proses en implementeer dan die gereedskap. Die gereedskap is goed, maar duur, so jy kan met die proses begin en die interaksie en begrip tussen ontwikkeling en sekuriteit verfyn. Uit die oogpunt van sekuriteit is dit nie nodig om alles in 'n ry te "stop" nie. Uit die oogpunt van ontwikkeling, as daar iets hoogs mega super krities is, dan moet dit uitgeskakel word, en nie gesluit word vir die probleem .
Produk kwaliteit - gemeenskaplike doel beide sekuriteit en ontwikkeling. Ons doen een ding, ons probeer verseker dat alles reg werk en dat daar geen reputasierisiko's en finansiële verliese is nie. Daarom bevorder ons die benadering tot DevSecOps, SecDevOps om kommunikasie te vestig en die produk beter te maak.
Begin met wat reeds daar is: vereistes, argitektuur, gedeeltelike kontrole, opleidings, riglyne. Dit is nie nodig om alle praktyke onmiddellik op alle projekte toe te pas nie - beweeg iteratief. Daar is geen enkele standaard nie eksperimenteer en probeer verskillende benaderings en oplossings.
Gelyke teken tussen IS-defekte en funksionele defekte.
Outomatiseer alleswat beweeg. Enigiets wat nie beweeg, beweeg en outomatiseer nie. As iets met die hand gedoen word, is dit nie 'n goeie deel van die proses nie. Miskien is dit die moeite werd om dit ook te heroorweeg en te outomatiseer.
As die grootte van die IB-span klein is - gebruik Security Champions.
Miskien sal dit waaroor ek gepraat het jou nie pas nie en sal jy met iets van jou eie vorendag kom – en dit is goed. Maar kies gereedskap gebaseer op die vereistes van jou proses. Moenie kyk na wat die gemeenskap sê dat hierdie instrument sleg is en hierdie een goed is nie. Miskien sal dit andersom op jou produk wees.
Gereedskap vereistes.
- Laag Vals Positief.
- Voldoende ontledingstyd.
- Gemak van gebruik.
- Beskikbaarheid van integrasies.
- Begrip van die produkontwikkelingspadkaart.
- Vermoë om gereedskap aan te pas.
Yuriy se verslag is gekies as een van die bestes by DevOpsConf 2018. Om kennis te maak met nog meer interessante idees en praktiese gevalle, kom na Skolkovo op 27 en 28 Mei binne . Selfs beter, as jy bereid is om jou ervaring te deel, dan Dien jou verslag teen 21 April in.
Bron: will.com