{"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\/da\/blog\/administrirovanie\/strah-i-nenavist-devsecops","title":{"rendered":"Frygt og had i DevSecOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Vi havde 2 kodeanalysev\u00e6rkt\u00f8jer, 4 v\u00e6rkt\u00f8jer til dynamisk testning, vores egne kreationer og 250 scripts. Ikke at alt dette var n\u00f8dvendigt i den nuv\u00e6rende proces, men da jeg begyndte at implementere DevSecOps, skal man g\u00f8re det ordentligt.<\/p>\n

\"Frygt
\n
\nKilde<\/a><\/noindex>. Karakterforfattere: Justin Roiland og Dan Harmon.<\/i><\/p>\n

Hvad er SecDevOps? Og DevSecOps? Hvad er forskellene? Applikationssikkerhed - hvad handler det om? Hvorfor virker den klassiske tilgang ikke l\u00e6ngere? Alle disse sp\u00f8rgsm\u00e5l har svar. Yuri Shabalin<\/b> af\u00a0Swordfish Security. <\/b>Yuri vil grundigt besvare alle sp\u00f8rgsm\u00e5l og gennemg\u00e5 problemerne ved overgangen fra den klassiske model for applikationssikkerhed til DevSecOps-processen: hvordan man korrekt integrerer sikre udviklingsprocesser ind i DevOps, uden at \u00f8del\u00e6gge noget, hvordan man gennemg\u00e5r de vigtigste sikkerhedstesttrin, hvilke v\u00e6rkt\u00f8jer man kan anvende, hvordan disse adskiller sig, og hvordan de kan konfigureres korrekt for at undg\u00e5 faldgruber.
\n<\/a><\/noindex>
\n

\r\n \"Afspil\r\n
<\/div>\r\n <\/div><\/center>
\nOm opl\u00e6gsholderen:<\/b> Yuri Shabalin - <\/b>Chief Security Architect i virksomheden Swordfish Security<\/b>. Han er ansvarlig for implementeringen af SSDL, for den samlede integration af applikationsanalysev\u00e6rkt\u00f8jer i et samlet udviklings- og test\u00f8kosystem. 7 \u00e5rs erfaring inden for informationssikkerhed. Har arbejdet for Alfa-Bank, Sberbank og i Positive Technologies, som udvikler software og tilbyder tjenester. Opl\u00e6gsholder ved internationale konferencer s\u00e5som ZerONights, PHDays, RISSPA, OWASP.<\/p>\n

Applikationssikkerhed: hvad handler det om?<\/h2>\n

\nApplikationssikkerhed<\/b>\u00a0er en gren af sikkerhed, der beskytter applikationer. Dette relaterer sig ikke til infrastruktur eller netv\u00e6rkssikkerhed, men netop til det, vi skriver og udviklere arbejder p\u00e5 - det handler om mangler og s\u00e5rbarheder i selve applikationen.<\/p>\n

Retning SDL eller SDLC<\/a><\/noindex>\u00a0\u2014 Security Development Lifecycle<\/b>\u00a0er udviklet af Microsoft. P\u00e5 diagrammet ses den kanoniske model for SDLC, som har som hovedopgave at inddrage sikkerheden i hver fase af udviklingen, fra krav til udgivelse og lancering i produktion. Microsoft inds\u00e5, at der i produktionen er for mange fejl, og at de bliver flere, og at noget m\u00e5tte g\u00f8res, og de foreslog denne tilgang, som blev kanonisk.<\/p>\n

\"Frygt
\n
\nApplikationssikkerhed og SSDL fokuserer ikke p\u00e5 at opdage s\u00e5rbarheder, som mange tror, men p\u00e5 at forhindre, at de opst\u00e5r. Gennem tiden er den kanoniske tilgang fra Microsoft blevet forbedret og udviklet, med en dybere og mere detaljeret tilgang.<\/p>\n

\"Frygt
\n
\nDen kanoniske SDLC er st\u00e6rkt detaljeret i forskellige metoder - OpenSAMM, BSIMM, OWASP. Metoderne adskiller sig, men generelt er de ens.<\/p>\n

Building Security In Maturity Model<\/h3>\n

\nJeg kan bedst lide BSIMM<\/b>\u00a0\u2014 Building Security In Maturity Model<\/a><\/noindex>. Grundlaget for metoden er opdelingen af Application Security processen i 4 dom\u00e6ner: Governance, Intelligence, SSDL Touchpoints og Deployment. I hvert dom\u00e6ne er der 12 praksisser, der pr\u00e6senteres i form af 112 aktiviteter.<\/p>\n

\"Frygt
\n
\nHver af de 112 aktiviteter har 3 modenhedsniveauer<\/b>: grundl\u00e6ggende, mellem og avanceret. Alle 12 praksisser kan studeres efter sektioner, udv\u00e6lge vigtige for dig og forst\u00e5, hvordan man implementerer dem og gradvist tilf\u00f8je elementer, s\u00e5som statisk og dynamisk kodeanalyse eller code review. Du laver en plan og arbejder roligt inden for rammerne af implementeringen af de valgte aktiviteter.<\/p>\n

Hvorfor DevSecOps<\/h2>\n

<\/p>\n

DevOps er en samlet stor proces, hvor det er n\u00f8dvendigt at tage sig af sikkerheden.<\/p><\/blockquote>\n

\nOprindeligt DevOps<\/b><\/a><\/noindex> forudsatte sikkerhedstjek. I praksis var antallet af sikkerhedsteams meget mindre end nu, og de fungerede ikke som deltagere i processen, men som en kontrol- og tilsynsmyndighed, der stiller krav til den og kontrollerer produktets kvalitet ved slutningen af udgivelsen. Dette er den klassiske tilgang, hvor sikkerhedsteams var adskilt fra udviklingen og ikke deltog i processen.<\/p>\n

\"Frygt
\n
\nDet st\u00f8rste problem er netop, at informationssikkerhed er adskilt fra udvikling. Normalt er det en slags informationssikkerhedsdom\u00e6ne, der rummer 2-3 store og dyre v\u00e6rkt\u00f8jer. Hver sjette m\u00e5ned modtager vi kildekoden eller en applikation, der skal tjekkes, og \u00e9n gang om \u00e5ret udf\u00f8res der penetrationstests<\/a><\/noindex>. Alt dette f\u00f8rer til, at deadlines for produktlancering uds\u00e6ttes, og udviklerne f\u00e5r et enormt antal s\u00e5rbarheder fra automatiserede v\u00e6rkt\u00f8jer. Det hele er umuligt at sortere og reparere, fordi resultaterne fra de sidste seks m\u00e5neder ikke engang er blevet analyseret, og nu er der en ny bunke.<\/p>\n

I vores virksomheds arbejdsproces ser vi, at sikkerhed i alle sektorer og industrier indser, at det er tid til at samarbejde med udviklingen - i\u00a0Agile<\/b><\/a><\/noindex>. DevSecOps-paradigmet passer perfekt ind i metoden for agil udvikling, til implementering, st\u00f8tte og deltagelse i hver udgivelse og iteration.<\/p>\n

\"Frygt
\n<\/p>\n

Overgangen til DevSecOps<\/h2>\n

\nDet vigtigste ord i Security Development Lifecycle er \"processen\"<\/b>Du skal forst\u00e5 dette, f\u00f8r du t\u00e6nker p\u00e5 at k\u00f8be v\u00e6rkt\u00f8jer.<\/p>\n

At inkludere v\u00e6rkt\u00f8jerne i DevOps-processen er ikke nok \u2013 det er vigtigt med interaktion og forst\u00e5else mellem deltagerne i processen.<\/p><\/blockquote>\n

<\/p>\n

Mennesker er vigtigere end v\u00e6rkt\u00f8jer.<\/h3>\n

\nPlanl\u00e6gningen af en sikker udviklingsproces begynder ofte med at v\u00e6lge og k\u00f8be et v\u00e6rkt\u00f8j, og slutter med at fors\u00f8ge at integrere v\u00e6rkt\u00f8jet i den nuv\u00e6rende proces, hvilket ofte kun bliver fors\u00f8g. Dette f\u00f8rer til triste konsekvenser, da hvert v\u00e6rkt\u00f8j har sine egne egenskaber og begr\u00e6nsninger.<\/p>\n

Et almindeligt tilf\u00e6lde er, n\u00e5r sikkerhedsafdelingen v\u00e6lger et godt, dyrt v\u00e6rkt\u00f8j med mange funktioner og henvender sig til udviklerne for at integrere det i processen. Men det fungerer ikke \u2013 processen er bygget p\u00e5 en m\u00e5de, hvor begr\u00e6nsningerne af det allerede k\u00f8bte v\u00e6rkt\u00f8j ikke passer ind i den nuv\u00e6rende paradigm.<\/p>\n

Start med at beskrive, hvilket resultat du \u00f8nsker, og hvordan processen vil se ud. Dette hj\u00e6lper med at forst\u00e5 v\u00e6rkt\u00f8jets og sikkerhedens roller i processen.<\/p><\/blockquote>\n

<\/p>\n

Begynd med det, der allerede bruges.<\/h3>\n

\nF\u00f8r du k\u00f8ber dyre v\u00e6rkt\u00f8jer, skal du se p\u00e5, hvad du allerede har. Hver virksomhed har sikkerhedskrav, der stilles til udviklingen, der er gennemgange og pentests \u2013 hvorfor ikke omdanne alt dette til en forst\u00e5elig og brugervenlig form?<\/p>\n

Normalt er kravene en papirforklaring, der ligger p\u00e5 hylden. Der var engang, vi kom ind i en virksomhed for at se p\u00e5 processerne og bad om at f\u00e5 vist sikkerhedskravene til softwaren. Den specialist, der arbejdede med det, ledte i lang tid:<\/p>\n

\u2014 Nu, et eller andet sted i noter, var der en vej til, hvor dette dokument l\u00e5.<\/i><\/p>\n

Til sidst fik vi dokumentet efter en uge.<\/p>\n

For krav, gennemgange og alt andet, opret en side, f.eks. p\u00e5\u00a0Confluence<\/b>\u00a0\u2014 det er praktisk for alle.<\/p>\n

Det er nemmere at omformatere det, der allerede findes, og bruge det som start.<\/p><\/blockquote>\n

<\/p>\n

Brug Security Champions. <\/h3>\n

\nNormalt arbejder der en sikkerhedsekspert i en gennemsnitlig virksomhed med 100-200 udviklere, som udf\u00f8rer flere funktioner og fysisk ikke kan n\u00e5 at kontrollere alt. Selv hvis han g\u00f8r sit bedste \u2013 kan han ikke kontrollere al den kode, der genereres af udviklingen alene. For s\u00e5danne tilf\u00e6lde er konceptet udviklet \u2013 Security Champions.<\/b><\/a><\/noindex>.<\/p>\n

Security Champions er en person inden for udviklingsteamet, der er interesseret i sikkerheden af dit produkt.<\/p><\/blockquote>\n

\"Frygt
\n
\nSecurity Champion er b\u00e5de indgangen til udviklingsteamet og sikkerhedsevangelisten i \u00e9n person.<\/p>\n

Normalt, n\u00e5r en sikkerhedsekspert kommer ind i udviklingsteamet og p\u00e5peger en fejl i koden, f\u00e5r de et overrasket svar:<\/p>\n

\u2014 Hvem er du? Jeg ser dig for f\u00f8rste gang. Jeg har det godt\u2014min senior kollega gav mig 'apply' p\u00e5 review, s\u00e5 lad os komme videre!<\/i><\/p>\n

Dette er en typisk situation, fordi der er meget mere tillid til seniorer eller blot kolleger inden for teamet, som udvikleren interagerer konstant med i arbejdet og code reviews. Hvis Security Champion p\u00e5peger en fejl og dens konsekvenser, vil deres ord have mere v\u00e6gt.<\/p>\n

Udviklere kender ogs\u00e5 deres kode bedre end nogen sikkerhedsekspert. For en person, der har mindst 5 projekter i statisk analysev\u00e6rkt\u00f8jet, er det normalt sv\u00e6rt at huske alle nuancer. Security Champions kender deres produkt: hvad interagerer hvad med, og hvad skal man se p\u00e5 f\u00f8rst \u2013 de er mere effektive.<\/p>\n

S\u00e5 overvej at implementere Security Champions og udvide sikkerhedsteamets indflydelse. For selve championen er dette ogs\u00e5 gavnligt: professionel udvikling i et nyt omr\u00e5de, udvidelse af teknisk viden, forbedring af tekniske, ledelses- og lederskabskompetencer, \u00f8get markedsv\u00e6rdi. Dette er et element af social engineering, dine '\u00f8jne' i udviklingsteamet.<\/p>\n

Testningsfaser<\/h2>\n

\nParadigmet 20 til 80<\/a><\/noindex>\u00a0siger, at 20% af indsatsen giver 80% af resultatet. Disse 20% er de praksisser for applikationsanalyse, som kan og b\u00f8r automatiseres. Eksempler p\u00e5 s\u00e5danne aktiviteter er statisk analyse\u2014 SAST<\/b>, dynamisk analyse\u2014 DAST,<\/b> og\u00a0kontrol af Open Source<\/b>. Jeg vil fort\u00e6lle mere om aktiviteterne samt v\u00e6rkt\u00f8jerne og hvilke s\u00e6rlige udfordringer vi typisk st\u00f8der p\u00e5 ved implementering i processen, og hvordan man g\u00f8r det korrekt.<\/p>\n

\"Frygt
\n<\/p>\n

De prim\u00e6re udfordringer med v\u00e6rkt\u00f8jerne<\/h3>\n

\nJeg vil fremh\u00e6ve de relevante udfordringer, der g\u00e6lder for alle v\u00e6rkt\u00f8jer, som kr\u00e6ver opm\u00e6rksomhed. Jeg vil gennemg\u00e5 dem mere detaljeret for ikke at gentage mig selv senere.<\/p>\n

Lang analyseperiode. <\/b>Hvis der g\u00e5r 30 minutter fra commit til produktion for alle tests og bygninger, vil sikkerhedskontroller tage en hel dag. Ingen vil bremse processen. Tag denne egenskab i betragtning og drag konklusioner.<\/p>\n

H\u00f8jt niveau af False Negative eller False Positive. <\/b>Alle produkter er forskellige, de bruger forskellige frameworks og har deres egen stil til at skrive kode. P\u00e5 forskellige kodebaser og teknologier kan v\u00e6rkt\u00f8jer vise forskellige niveauer af False Negative og False Positive. S\u00e5 se p\u00e5, hvad der pr\u00e6cist er i\u00a0dit<\/b> firma og for dine<\/b> applikationer, der vil vise gode og p\u00e5lidelige resultater.<\/p>\n

Ingen integrationer med eksisterende v\u00e6rkt\u00f8jer<\/b>. Se p\u00e5 v\u00e6rkt\u00f8jerne med fokus p\u00e5 integrationer, med hvad du allerede bruger. For eksempel, hvis du har Jenkins eller TeamCity \u2013 tjek integrationen af v\u00e6rkt\u00f8jerne med dette software, og ikke med GitLab CI, som du ikke bruger.<\/p>\n

Mangel p\u00e5 eller overdreven kompleksitet af tilpasning. <\/b>Hvis v\u00e6rkt\u00f8jet ikke har et API, hvorfor har man s\u00e5 brug for det? Alt, hvad der kan g\u00f8res i gr\u00e6nsefladen, skal v\u00e6re tilg\u00e6ngeligt gennem API'et. Ideelt set b\u00f8r v\u00e6rkt\u00f8jet have mulighed for at tilpasse kontroller.<\/p>\n

Ingen udviklings Roadmap for produktet. <\/b>Udviklingen st\u00e5r ikke stille; vi bruger altid nye frameworks og funktioner, genkoder gammelt kode til nye sprog. Vi \u00f8nsker at v\u00e6re sikre p\u00e5, at v\u00e6rkt\u00f8jet, vi k\u00f8ber, vil underst\u00f8tte nye frameworks og teknologier. Derfor er det vigtigt at vide, at produktet har en reel og korrekt Roadmap<\/a><\/noindex> for udvikling.<\/p>\n

Processens egenskaber<\/h3>\n

\nUdover v\u00e6rkt\u00f8jernes egenskaber, skal du ogs\u00e5 tage h\u00f8jde for udviklingsprocessens s\u00e6regenheder. At forstyrre udviklingen er en typisk fejl. Lad os se p\u00e5, hvilke andre aspekter der b\u00f8r overvejes, og hvad sikkerhedsteamet skal fokusere p\u00e5.<\/p>\n

For ikke at forsinke udviklings- og udgivelsestidspunkter, skal du oprette forskellige regler<\/b> og forskellige show stoppers\u00a0<\/b>\u2014 kriterier for at stoppe byggeprocessen, n\u00e5r der findes s\u00e5rbarheder \u2014 for forskellige milj\u00f8er<\/b>. For eksempel, vi forst\u00e5r, at den nuv\u00e6rende gren g\u00e5r til udviklingsstand eller UAT, s\u00e5 vi stopper ikke op og siger:<\/p>\n

\u2014 Der er s\u00e5rbarheder her, I kan ikke g\u00e5 videre!<\/i><\/p>\n

P\u00e5 dette stadium er det vigtigt at informere udviklerne om, at der er sikkerhedsproblemer, som det er v\u00e6rd at v\u00e6re opm\u00e6rksom p\u00e5.<\/p>\n

Forekomster af s\u00e5rbarheder er ikke en hindring for fortsat testning<\/b>: manuel, integrations- eller manuel. P\u00e5 den anden side er vi n\u00f8dt til at \u00f8ge sikkerheden af produktet, og s\u00e5 udviklerne ikke overser, hvad sikkerheden opdager. Derfor g\u00f8r vi nogle gange s\u00e5dan: p\u00e5 standen, n\u00e5r det udrulles til udviklingsmilj\u00f8et, informerer vi blot udviklingen:<\/p>\n

\u2014 Herre, I har nogle problemer, v\u00e6r venlig at l\u00e6gge m\u00e6rke til dem.<\/i><\/p>\n

P\u00e5 UAT-fasen viser vi igen advarsler om s\u00e5rbarheder, og ved overgang til produktion siger vi:<\/p>\n

\u2014 Herre, vi har advaret flere gange, og I har ikke gjort noget\u2014 vi vil ikke frigive det med dette.<\/i><\/p>\n

N\u00e5r vi taler om koden og dynamikken, er det n\u00f8dvendigt kun at vise og advare om s\u00e5rbarhederne for de funktioner og koder, der lige er blevet skrevet i denne funktion. Hvis udvikleren har rykket en knap 3 pixels, og vi fort\u00e6ller ham, at han har en SQL-injektion, og at han derfor hurtigt skal rette det\u2014 det er forkert. Se kun p\u00e5 det, der er skrevet nu, og de \u00e6ndringer, der kommer ind i applikationen.<\/p>\n

Lad os sige, at vi har en eller anden funktionel fejl\u2014 det, hvordan applikationen ikke skal fungere: penge overf\u00f8res ikke, ved klik p\u00e5 knappen er der ikke overgang til den n\u00e6ste side, eller produktet indl\u00e6ses ikke. Sikkerhedsdefekter<\/b>\u00a0\u2014 det er de samme defekter, men ikke i forhold til, hvordan applikationen fungerer, men til sikkerhed. <\/p>\n

Ikke alle softwarekvalitetsproblemer er sikkerhedsproblemer. Men alle sikkerhedsproblemer er relateret til softwarekvalitet. Sherif Mansour, Expedia.<\/p><\/blockquote>\n

\nDa alle s\u00e5rbarheder er de samme defekter, b\u00f8r de befinde sig de samme steder som alle udviklingsdefekter. S\u00e5 glem rapporter og skr\u00e6mmende PDF-filer, som ingen l\u00e6ser.<\/p>\n

\"Frygt
\n
\nDa jeg arbejdede i et firma, der besk\u00e6ftigede sig med udvikling, modtog jeg en rapport fra statisk analysev\u00e6rkt\u00f8jer. Jeg \u00e5bnede den, blev chokeret, lavede mig en kop kaffe, bladrede igennem 350 sider, lukkede den og gik tilbage til arbejdet. Store rapporter er d\u00f8de rapporter<\/b>. Normalt g\u00e5r de ingen steder, e-mails slettes, glemmes, tabes, eller virksomheden siger, at den accepterer risici.<\/p>\n

Hvad skal man g\u00f8re? De bekr\u00e6ftede fejl, vi har fundet, omdanner vi simpelthen til en udviklingsvenlig form, for eksempel ved at l\u00e6gge dem i backlog i Jira. Vi prioriterer fejl og retter dem i r\u00e6kkef\u00f8lge efter prioritet sammen med funktionelle fejl og testfejl.<\/p>\n

Statisk analyse - SAST<\/h2>\n

\nDet er en analyse af koden for s\u00e5rbarheder.<\/b>, men det er ikke det samme som SonarQube. Vi tjekker ikke kun efter m\u00f8nstre eller stil. Under analysen anvendes en r\u00e6kke tilgange: efter svaghedstr\u00e6et, efter\u00a0DataFlow<\/a><\/noindex>, efter analyse af konfigurationsfiler. Det er alt, hvad der har med selve koden at g\u00f8re.<\/p>\n

Fordele ved tilgangen<\/b>: identifikation af s\u00e5rbarheder i koden p\u00e5 et tidligt udviklingstrin<\/b>, n\u00e5r der ikke endnu er oprettet testmilj\u00f8er eller f\u00e6rdige v\u00e6rkt\u00f8jer, og\u00a0mulighed for inkrementel scanning<\/b>: scanning af den del af koden, som er \u00e6ndret, og kun den funktionalitet, vi arbejder p\u00e5 nu, hvilket reducerer scannings tiden.<\/p>\n

Ulemper<\/b>\u00a0\u2014 det er manglende support for n\u00f8dvendige sprog.<\/p>\n

N\u00f8dvendige integrationer, <\/b>som skal v\u00e6re i v\u00e6rkt\u00f8jerne, efter min subjektive mening:<\/p>\n