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

Vi hadde 2 kodeanalysatorer, 4 verkt\u00f8y for dynamisk testing, egne kreasjoner og 250 skript. Ikke at alt dette var n\u00f8dvendig i den n\u00e5v\u00e6rende prosessen, men siden jeg begynte \u00e5 implementere DevSecOps, m\u00e5 jeg g\u00e5 hele veien.<\/p>\n

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

Hva er SecDevOps? Og DevSecOps? Hva er forskjellene? Applikasjonssikkerhet \u2013 hva handler det om? Hvorfor fungerer ikke den klassiske tiln\u00e6rmingen lenger? P\u00e5 alle disse sp\u00f8rsm\u00e5lene har vi svar Juri Shabalin<\/b> fra\u00a0Swordfish Security. <\/b>Juri vil gi detaljerte svar og belyse problemene med overgangen fra den klassiske modellen for applikasjonssikkerhet til DevSecOps-prosessen: hvordan man riktig integrerer prosessen for trygg utvikling i DevOps-prosessen uten \u00e5 \u00f8delegge noe, hvordan man passerer de viktigste testtrinnene for sikkerhet, hvilke verkt\u00f8y som kan brukes, hvordan de skiller seg fra hverandre og hvordan de skal konfigureres for \u00e5 unng\u00e5 fallgruver.
\n<\/a><\/noindex>
\n

\r\n \"Spill\r\n
<\/div>\r\n <\/div><\/center>
\nOm taleren:<\/b> Juri Shabalin \u2013 <\/b>Chief Security Architect i selskapet Swordfish Security<\/b>. Ansvarlig for implementering av SSDL, for generell integrering av applikasjonsanalyseverkt\u00f8y i et samlet utviklings- og test\u00f8kosystem. 7 \u00e5rs erfaring innen informasjonssikkerhet. Har jobbet i Alfa-Bank, Sberbank og i Positive Technologies, som utvikler programvare og tilbyr tjenester. Taler p\u00e5 internasjonale konferanser som ZerONights, PHDays, RISSPA, OWASP.<\/p>\n

Applikasjonssikkerhet: hva handler det om?<\/h2>\n

\nApplikasjonssikkerhet<\/b>\u00a0er et omr\u00e5de innen sikkerhet som fokuserer p\u00e5 sikkerheten til applikasjoner. Det handler ikke om infrastruktur eller nettverkssikkerhet, men om det vi skriver og det utviklerne jobber med \u2013 det gjelder svakheter og s\u00e5rbarheter i selve applikasjonen.<\/p>\n

Retning SDL eller SDLC<\/a><\/noindex>\u00a0\u2014 Sikkerhetsutviklingslivssyklus<\/b>\u00a0ble utviklet av Microsoft. I diagrammet \u2013 den kanoniske modellen for SDLC, hvis hovedoppgave er \u00e5 inkludere sikkerhet i hver fase av utviklingen, fra krav til utgivelse og produksjon. Microsoft inns\u00e5 at det var for mange feil i produksjon, de ble flere, og noe m\u00e5tte gj\u00f8res, og foreslo denne tiln\u00e6rmingen, som har blitt kanonisk.<\/p>\n

\"Frykt
\n
\nApplikasjonssikkerhet og SSDL er ikke rettet mot \u00e5 oppdage s\u00e5rbarheter, som det ofte antas, men mot \u00e5 forhindre deres oppkomst. Over tid har den kanoniske tiln\u00e6rmingen fra Microsoft blitt forbedret og utviklet, med en dypere detaljinnsikt.<\/p>\n

\"Frykt
\n
\nDen kanoniske SDLC er sterkt detaljert i forskjellige metodologier - OpenSAMM, BSIMM, OWASP. Metodologiene er forskjellige, men generelt liknande.<\/p>\n

Bygge sikkerhet inn modningsmodellen<\/h3>\n

\nJeg liker best BSIMM<\/b>\u00a0\u2014 Bygge sikkerhet inn modningsmodellen<\/a><\/noindex>. Grunnlaget for metodologien er delingen av prosessen for applikasjonssikkerhet i 4 domener: Governance, Intelligence, SSDL Touchpoints og Deployment. I hvert domene er det 12 praksiser, som presenteres i form av 112 aktiviteter.<\/p>\n

\"Frykt
\n
\nHver av de 112 aktivitetene har 3 modenhetsniv\u00e5er<\/b>: grunnleggende, mellomliggende og avansert. Alle 12 praksiser kan l\u00e6res avsnittsvis, plukk ut viktige ting for deg, finn ut hvordan du implementerer dem, og gradvis legge til elementer som statisk og dynamisk kodeanalyse eller kodegjennomgang. Du lager en plan og jobber rolig innenfor rammene av implementeringen av valgte aktiviteter.<\/p>\n

Hvorfor DevSecOps<\/h2>\n

<\/p>\n

DevOps er en stor felles prosess der man m\u00e5 ta hensyn til sikkerhet.<\/p><\/blockquote>\n

\nOpprinnelig DevOps<\/b><\/a><\/noindex> forutsatte sikkerhetskontroller. I praksis var antallet sikkerhetsteam mye mindre enn i dag, og de fungerte ikke som deltakere i prosessen, men som et kontroll- og tilsynsorgan som stiller krav til prosessen og vurderer kvaliteten p\u00e5 produktet ved slutten av utgivelsen. Dette er en klassisk tiln\u00e6rming, der sikkerhetsteamene var adskilt fra utviklingen og ikke deltok i prosessen.<\/p>\n

\"Frykt
\n
\nHovedproblemet er nettopp at sikkerheten st\u00e5r adskilt fra utviklingen. Vanligvis er det en slags sikkerhetssirkel med 2-3 store og dyre verkt\u00f8y. Hver sjette m\u00e5ned kommer kildekoden eller applikasjonen som m\u00e5 sjekkes, og en gang i \u00e5ret utf\u00f8res penetrasjonstester<\/a><\/noindex>. Alt dette f\u00f8rer til at lanseringstidene blir utsatt, og utvikleren f\u00e5r akutt behov for \u00e5 h\u00e5ndtere et stort antall s\u00e5rbarheter fra automatiserte verkt\u00f8y. Alt dette er umulig \u00e5 sortere og fikse, fordi resultatene fra de siste seks m\u00e5nedene ikke er sortert, og n\u00e5 kommer det en ny b\u00f8lge.<\/p>\n

I l\u00f8pet av v\u00e5rt arbeid i selskapet ser vi at sikkerhet i alle felt og industrier innser at det er p\u00e5 tide \u00e5 komme ajour og samarbeide med utviklingen i ett hjul - i\u00a0Agile<\/b><\/a><\/noindex>. DevSecOps-paradigmet passer utmerket inn i metodikken for smidig utvikling, med implementering, st\u00f8tte og deltakelse i hver utgivelse og iterasjon.<\/p>\n

\"Frykt
\n<\/p>\n

Overgangen til DevSecOps<\/h2>\n

\nDet viktigste ordet i Security Development Lifecycle er \"prosessen\"<\/b>Du m\u00e5 forst\u00e5 dette f\u00f8r du tenker p\u00e5 \u00e5 kj\u00f8pe verkt\u00f8y.<\/p>\n

Det er ikke nok \u00e5 bare inkludere verkt\u00f8yene i DevOps-prosessen \u2014 interaksjon og forst\u00e5else mellom deltakerne i prosessen er viktig.<\/p><\/blockquote>\n

<\/p>\n

Menneskene er viktigere enn verkt\u00f8yene<\/h3>\n

\nPlanlegging av en sikker utviklingsprosess begynner ofte med valg og kj\u00f8p av verkt\u00f8y, men ender med fors\u00f8k p\u00e5 \u00e5 integrere verkt\u00f8yet i den n\u00e5v\u00e6rende prosessen, som forblir nettopp det \u2014 fors\u00f8k. Dette f\u00f8rer til triste konsekvenser, fordi hvert verkt\u00f8y har sine egne funksjoner og begrensninger.<\/p>\n

Et vanlig tilfelle er n\u00e5r sikkerhetsavdelingen velger et godt, dyrt verkt\u00f8y med mange muligheter, og presenterer det for utviklerne \u2014 \u00e5 integere det i prosessen. Men det lar seg ikke gj\u00f8re \u2014 prosessen er bygget slik at begrensningene til det allerede kj\u00f8pte verkt\u00f8yet ikke passer inn i den n\u00e5v\u00e6rende paradygmen.<\/p>\n

F\u00f8rst beskriv hvilket resultat du \u00f8nsker og hvordan prosessen vil se ut. Dette vil hjelpe til med \u00e5 forst\u00e5 rollene til verkt\u00f8yet og sikkerhet i prosessen.<\/p><\/blockquote>\n

<\/p>\n

Begynn med det som allerede brukes<\/h3>\n

\nF\u00f8r du kj\u00f8per dyre verkt\u00f8y, se p\u00e5 hva du allerede har. Hver bedrift har sikkerhetskrav som stilles til utviklingen, det er sjekker, pentester \u2014 hvorfor ikke transformere alt dette til en forst\u00e5elig og brukervennlig form?<\/p>\n

Som regel er kravene et papirhefte som ligger p\u00e5 hyllen. Det var en gang vi kom til et selskap for \u00e5 se p\u00e5 prosessene og ba om \u00e5 f\u00e5 se sikkerhetskravene til programvaren. Spesialisten som jobbet med dette, lette lenge:<\/p>\n

\u2014 N\u00e5, et sted i notatene var det en sti til dette dokumentet.<\/i><\/p>\n

Til slutt fikk vi dokumentet etter en uke.<\/p>\n

For krav, sjekker og annet, lag en side, for eksempel p\u00e5\u00a0Confluence<\/b>\u00a0\u2014 det er praktisk for alle.<\/p>\n

Det er enklere \u00e5 omformatere det som allerede finnes og bruke det som utgangspunkt.<\/p><\/blockquote>\n

<\/p>\n

Bruk Security Champions <\/h3>\n

\nVanligvis, i et middels stort selskap med 100-200 utviklere, jobber det en sikkerhetsekspert som utf\u00f8rer flere funksjoner, og har ikke fysisk mulighet til \u00e5 sjekke alt. Selv om han gj\u00f8r sitt beste \u2014 kan han ikke sjekke all koden som utviklingen genererer alene. For slike tilfeller er konseptet utviklet \u2014 Security Champions<\/b><\/a><\/noindex>.<\/p>\n

Security Champions er en person i utviklingsteamet som er interessert i sikkerheten til produktet ditt.<\/p><\/blockquote>\n

\"Frykt
\n
\nSecurity Champion er inngangspunktet til utviklingsteamet og en sikkerhetsevangelsist i \u00e9n og samme person.<\/p>\n

Som regel, n\u00e5r en sikkerhetsrepresentant kommer inn i utviklingsteamet og p\u00e5peker en feil i koden, f\u00e5r de et overrasket svar:<\/p>\n

\u2014 Hvem er du? Jeg ser deg for f\u00f8rste gang. Alt er i orden for meg \u2014 min senior kollega la inn \"apply\" p\u00e5 code review, s\u00e5 vi g\u00e5r videre!<\/i><\/p>\n

Dette er en typisk situasjon fordi det er mye st\u00f8rre tillit til seniorer eller bare kolleger i teamet som utvikleren jobber tett med og har code review med. Hvis en Security Champion p\u00e5peker en feil og konsekvenser i stedet for sikkerhetsrepresentanten, vil deres ord ha mer vekst.<\/p>\n

Utviklere kjenner ogs\u00e5 koden sin bedre enn noen sikkerhetsrepresentant. For en person som har minst 5 prosjekter i statisk analyseverkt\u00f8y, er det vanligvis vanskelig \u00e5 huske alle nyansene. Security Champions kjenner produktet sitt: hva som interagerer med hva og hva man skal se p\u00e5 f\u00f8rst \u2014 de er mer effektive.<\/p>\n

S\u00e5 vurder \u00e5 implementere Security Champions og utvide sikkerhetsteamets innflytelse. For selve mesteren er dette ogs\u00e5 nyttig: profesjonell utvikling p\u00e5 et nytt omr\u00e5de, utvidelse av teknisk horisont, forbedring av tekniske, ledelsesmessige og lederferdigheter, og \u00f8kning av markedsverdi. Dette er et element av sosial ingeni\u00f8rkunst, dine \"\u00f8yne\" i utviklingsteamet.<\/p>\n

Testtrinn<\/h2>\n

\nParadigmet 20 av 80<\/a><\/noindex>\u00a0sier at 20 % av innsatsen gir 80 % av resultatene. Disse 20 % er praksiser for applikasjonsanalyse som kan og b\u00f8r automatiseres. Eksempler p\u00e5 slike aktiviteter er statisk analyse \u2014 SAST<\/b>, dynamisk analyse \u2014 DAST,<\/b> og\u00a0kontroll av Open Source<\/b>. Jeg vil fortelle mer om aktivitetene og hvilke verkt\u00f8y, samt hvilke s\u00e6rtrekk vi vanligvis st\u00f8ter p\u00e5 n\u00e5r vi implementerer dem i prosessen, og hvordan man gj\u00f8r det riktig.<\/p>\n

\"Frykt
\n<\/p>\n

Hovedproblemer med verkt\u00f8yene<\/h3>\n

\nJeg vil fremheve aktuelle problemer som ber\u00f8rer alle verkt\u00f8yene, som krever oppmerksomhet. Jeg vil g\u00e5 mer i dybden p\u00e5 dem for ikke \u00e5 gjenta meg selv senere.<\/p>\n

Lang tid for analyse. <\/b>Hvis det tar 30 minutter fra commit til produksjon for alle tester og bygging, vil sjekker for informasjonssikkerhet ta en hel dag. Ingen vil bremse prosessen. Ta hensyn til denne egenskapen og dra konklusjoner.<\/p>\n

H\u00f8yt niv\u00e5 av False Negative eller False Positive. <\/b>Alle produkter er forskjellige, alle bruker forskjellige rammeverk og har sin egen stil for koding. P\u00e5 forskjellige kodebaser og teknologier kan verkt\u00f8yene vise varierende niv\u00e5 av False Negative og False Positive. S\u00e5 se p\u00e5 hva som gjelder for\u00a0dere<\/b> og for deres<\/b> applikasjoner som vil gi gode og p\u00e5litelige resultater.<\/p>\n

Ingen integrasjoner med eksisterende verkt\u00f8y<\/b>. Se p\u00e5 verkt\u00f8yene fra vinkelen av integrasjoner med det dere allerede bruker. For eksempel, hvis dere har Jenkins eller TeamCity, sjekk integrasjonen av verkt\u00f8yene med denne programvaren, og ikke med GitLab CI som dere ikke bruker.<\/p>\n

Manglende eller overdreven kompleksitet i tilpasning. <\/b>Hvis verkt\u00f8yet ikke har API, hvorfor trenger man det? Alt som kan gj\u00f8res i grensesnittet skal v\u00e6re tilgjengelig gjennom API. Ideelt sett b\u00f8r verkt\u00f8yet ha mulighet for tilpasning av sjekker.<\/p>\n

Ingen utviklings-roadmap. <\/b>Utviklingen st\u00e5r ikke stille, vi bruker alltid nye rammeverk og funksjoner, og omskriver gammel kode til nye spr\u00e5k. Vi \u00f8nsker \u00e5 v\u00e6re sikre p\u00e5 at verkt\u00f8yet vi kj\u00f8per vil st\u00f8tte nye rammeverk og teknologier. Derfor er det viktig \u00e5 vite at produktet har en reell og korrekt roadmap<\/a><\/noindex> for utvikling.<\/p>\n

Prosessens s\u00e6regenheter<\/h3>\n

\nUtover egenskapene til verkt\u00f8yene, ta ogs\u00e5 hensyn til egenskapene ved utviklingsprosessen. For eksempel er det en typisk feil \u00e5 forstyrre utviklingen. La oss se hvilke andre s\u00e6regenheter vi b\u00f8r vurdere og hva sikkerhetsteamet b\u00f8r v\u00e6re oppmerksom p\u00e5.<\/p>\n

For \u00e5 unng\u00e5 \u00e5 forsinke utviklings- og lanseringsfrister, lag ulike regler<\/b> og forskjellige show stoppers\u00a0<\/b>\u2014 kriterier for \u00e5 stoppe byggeprosessen ved tilstedev\u00e6relse av s\u00e5rbarheter \u2014 for forskjellige milj\u00f8er<\/b>. For eksempel forst\u00e5r vi at den n\u00e5v\u00e6rende grenen g\u00e5r til utviklingsmilj\u00f8et eller UAT, s\u00e5 vi stopper ikke og sier:<\/p>\n

\u2014 Dere har s\u00e5rbarheter her, dere kan ikke g\u00e5 videre!<\/i><\/p>\n

P\u00e5 dette stadiet er det viktig \u00e5 informere utviklerne om sikkerhetsproblemer som de b\u00f8r v\u00e6re oppmerksomme p\u00e5.<\/p>\n

Tilgjengeligheten av s\u00e5rbarheter er ikke en hindring for videre testing.<\/b>: manuell, integrering eller manual. P\u00e5 den annen side trenger vi \u00e5 forbedre sikkerheten til produktet, s\u00e5 utviklerne m\u00e5 v\u00e6re oppmerksomme p\u00e5 hva sikkerhetsanalysene finner. Derfor noen ganger handler vi slik: n\u00e5r vi distribuerer p\u00e5 utviklingsmilj\u00f8et, varsler vi utviklingen:<\/p>\n

\u2014 Hei, dere har problemer, v\u00e6r s\u00e5 snill og ta hensyn til dem.<\/i><\/p>\n

I UAT-fasen viser vi igjen varsler om s\u00e5rbarheter, og i produksjonsfasen sier vi:<\/p>\n

\u2014 Hei, vi har advart flere ganger, dere har ikke gjort noe - vi kan ikke slippe dere ut med dette.<\/i><\/p>\n

N\u00e5r det gjelder koden og dynamikken, m\u00e5 vi vise og varsle om s\u00e5rbarheter bare i de funksjonene og koden som nettopp har blitt skrevet i denne funksjonen. Hvis utvikleren har flyttet en knapp med 3 piksler og vi sier til vedkommende at det er en SQL-injeksjon der som m\u00e5 rettes opp umiddelbart - det er feil. Se kun p\u00e5 det som er skrevet n\u00e5, og p\u00e5 den endringen som kommer inn i applikasjonen.<\/p>\n

La oss si at vi har en funksjonell feil - hvordan applikasjonen ikke skal fungere: penger overf\u00f8res ikke, klikker man p\u00e5 knappen, er det ingen overgang til neste side, eller varer lastes ikke opp. Sikkerhetsdefekter<\/b>\u00a0\u2014 det er ogs\u00e5 defekter, men ikke med hensyn til applikasjonens arbeid, men i forhold til sikkerhet. <\/p>\n

Ikke alle programvarekvalitetsproblemer er sikkerhetsproblemer. Men alle sikkerhetsproblemer er relatert til programvarekvalitet. Sherif Mansour, Expedia.<\/p><\/blockquote>\n

\nSiden alle s\u00e5rbarheter er slike defekter, b\u00f8r de finnes der hvor alle utviklingsfeil er. S\u00e5 glem rapportene og de skremmende PDF-ene som ingen leser.<\/p>\n

\"Frykt
\n
\nDa jeg jobbet for et selskap som drev med utvikling, fikk jeg tilsendt en rapport fra statiske analyseverkt\u00f8y. Jeg \u00e5pnet den, ble forskrekket, lagde meg kaffe, bladde gjennom 350 sider, lukket den og fortsatte med arbeidet mitt. Store rapporter er d\u00f8de rapporter<\/b>. De g\u00e5r vanligvis ingen steder, e-poster slettes, glemmes, mistes, eller forretningen sier at de aksepterer risikoer.<\/p>\n

Hva gj\u00f8r man? Bekreftede feil som er funnet, blir enkelt omgjort til en utviklingsvennlig format, for eksempel lagret i backlog i Jira. Vi prioriterer feil og retter dem i rekkef\u00f8lge etter prioritet, p\u00e5 lik linje med funksjonelle feil og testfeil.<\/p>\n

Statisk analyse - SAST<\/h2>\n

\nDette er en kodeanalyse for s\u00e5rbarheter<\/b>, men dette er ikke det samme som SonarQube. Vi sjekker ikke bare ut ifra m\u00f8nstre eller stil. I analysen brukes en rekke tiln\u00e6rminger: ved hjelp av s\u00e5rbarhetstreet, ved\u00a0DataFlow<\/a><\/noindex>, ved analyse av konfigurasjonsfiler. Dette er alt som gjelder koden direkte.<\/p>\n

Fordeler med tiln\u00e6rmingen<\/b>: avdekking av s\u00e5rbarheter i koden tidlig i utviklingsprosessen<\/b>, n\u00e5r det fortsatt ikke finnes milj\u00f8er og verkt\u00f8y er klare, og\u00a0mulighet for inkrementell skanning<\/b>: skanning av den delen av koden som har blitt endret, og bare av den funksjonaliteten vi jobber med n\u00e5, noe som reduserer skanningstiden.<\/p>\n

Ulemper<\/b>\u00a0\u2014 er frav\u00e6ret av st\u00f8tte for n\u00f8dvendige spr\u00e5k.<\/p>\n

N\u00f8dvendige integrasjoner, <\/b>som m\u00e5 v\u00e6re i verkt\u00f8yene, etter min subjektive mening:<\/p>\n