Frykt og avsky for DevSecOps

Vi hadde 2 kodeanalysatorer, 4 dynamiske testverktøy, vårt eget håndverk og 250 skript. Det er ikke det at alt dette er nødvendig i den nåværende prosessen, men når du begynner å implementere DevSecOps, må du gå til slutten.

Kilde. Karakterskapere: Justin Roiland og Dan Harmon.

Hva er SecDevOps? Hva med DevSecOps? Hva er forskjellene? Applikasjonssikkerhet – hva handler det om? Hvorfor fungerer ikke den klassiske tilnærmingen lenger? Vet svaret på alle disse spørsmålene Yuri Shabalin av Sverdfisksikkerhet. Yuri vil svare på alt i detalj og analysere problemene med overgangen fra den klassiske applikasjonssikkerhetsmodellen til DevSecOps-prosessen: hvordan man på riktig måte nærmer seg integreringen av den sikre utviklingsprosessen i DevOps-prosessen og ikke bryter noe, hvordan går man gjennom hovedstadiene av sikkerhetstesting, hvilke verktøy som kan brukes, og hva de skiller seg fra og hvordan du konfigurerer dem riktig for å unngå fallgruver.

Om foredragsholderen: Yuri Shabalin - Hovedsikkerhetsarkitekt i selskapet Sverdfisksikkerhet. Ansvarlig for implementering av SSDL, for den generelle integreringen av applikasjonsanalyseverktøy i et enhetlig utviklings- og testøkosystem. 7 års erfaring innen informasjonssikkerhet. Jobbet i Alfa-Bank, Sberbank og Positive Technologies, som utvikler programvare og leverer tjenester. Foredragsholder på internasjonale konferanser ZerONights, PHDays, RISSPA, OWASP.

Applikasjonssikkerhet: hva handler det om?

Programvaresikkerhet – Dette er sikkerhetsseksjonen som har ansvar for applikasjonssikkerhet. Dette gjelder ikke infrastruktur eller nettverkssikkerhet, men heller hva vi skriver og hva utviklere jobber med – dette er manglene og sårbarhetene ved selve applikasjonen.

retning SDL eller SDLC - Sikkerhetsutvikling livssyklus - utviklet av Microsoft. Diagrammet viser den kanoniske SDLC-modellen, hvis hovedoppgave er deltakelse av sikkerhet på alle trinn i utviklingen, fra krav til utgivelse og produksjon. Microsoft innså at det var for mange feil i bransjen, det var flere av dem og noe måtte gjøres med det, og de foreslo denne tilnærmingen, som har blitt kanonisk.

Application Security og SSDL er ikke rettet mot å oppdage sårbarheter, slik man vanligvis tror, ​​men på å forhindre at de oppstår. Over tid har Microsofts kanoniske tilnærming blitt forbedret, utviklet og introdusert i et dypere, mer detaljert dykk.

Den kanoniske SDLC er svært detaljert i ulike metoder - OpenSAMM, BSIMM, OWASP. Metodene er forskjellige, men generelt like.

Byggesikkerhet i modenhetsmodell

Jeg liker det best BSIMM - Byggesikkerhet i modenhetsmodell. Grunnlaget for metodikken er inndelingen av Application Security-prosessen i 4 domener: Governance, Intelligence, SSDL Touchpoints og Deployment. Hvert domene har 12 praksiser, som er representert som 112 aktiviteter.

Hver av de 112 aktivitetene har 3 nivåer av modenhet: nybegynner, middels og avansert. Du kan studere alle de 12 praksisene seksjon for seksjon, velge ting som er viktige for deg, finne ut hvordan du implementerer dem og gradvis legge til elementer, for eksempel statisk og dynamisk kodeanalyse eller kodegjennomgang. Du skriver ned en plan og jobber rolig etter den som en del av gjennomføringen av de valgte aktivitetene.

Hvorfor DevSecOps

DevOps er en generell, stor prosess der sikkerhet må tas i betraktning.

Utgangspunktet DevOps involvert sikkerhetskontroller. I praksis var antallet sikkerhetsteam mye mindre enn nå, og de fungerte ikke som deltakere i prosessen, men som et kontroll- og tilsynsorgan som stiller krav til det og kontrollerer kvaliteten på produktet ved slutten av utgivelsen. Dette er en klassisk tilnærming der sikkerhetsteam var bak muren fra utviklingen og ikke deltok i prosessen.

Hovedproblemet er at informasjonssikkerhet er atskilt fra utvikling. Vanligvis er dette en slags informasjonssikkerhetskrets og den inneholder 2-3 store og dyre verktøy. En gang i halvåret kommer kildekoden eller applikasjonen som skal sjekkes, og en gang i året produseres de pentests. Alt dette fører til at utgivelsesdatoen for industrien er forsinket, og utvikleren blir utsatt for et stort antall sårbarheter fra automatiserte verktøy. Det er umulig å demontere og reparere alt dette, fordi resultatene for de foregående seks månedene ikke ble sortert ut, men her er en ny batch.

I løpet av vårt selskaps arbeid ser vi at sikkerhet i alle områder og bransjer forstår at det er på tide å ta igjen og snurre med utviklingen på samme hjul - i Agile. DevSecOps-paradigmet passer perfekt med smidig utviklingsmetodikk, implementering, støtte og deltakelse i hver utgivelse og iterasjon.

Overgang til DevSecOps

Det viktigste ordet i livssyklusen for sikkerhetsutvikling er "prosess". Du må forstå dette før du tenker på å kjøpe verktøy.

Det er ikke nok å inkorporere verktøy i DevOps-prosessen – kommunikasjon og forståelse mellom prosessdeltakere er viktig.

Mennesker er viktigere, ikke verktøy.

Ofte begynner planleggingen av en sikker utviklingsprosess med valg og kjøp av et verktøy, og ender med forsøk på å integrere verktøyet i den nåværende prosessen, som fortsatt er forsøk. Dette fører til uheldige konsekvenser, fordi alle verktøy har sine egne egenskaper og begrensninger.

Et vanlig tilfelle er når sikkerhetsavdelingen valgte et godt, kostbart verktøy med brede muligheter, og kom til utviklerne for å integrere det i prosessen. Men det går ikke - prosessen er strukturert på en slik måte at begrensningene til det allerede kjøpte verktøyet ikke passer inn i det nåværende paradigmet.

Beskriv først hvilket resultat du ønsker og hvordan prosessen vil se ut. Dette vil bidra til å forstå rollene til verktøy og sikkerhet i prosessen.

Start med det som allerede er i bruk

Før du kjøper dyre verktøy, se på hva du allerede har. Hvert selskap har sikkerhetskrav for utvikling, det er kontroller, pentester - hvorfor ikke forvandle alt dette til en form som er forståelig og praktisk for alle?

Vanligvis er kravene en papirtalmud som ligger på en hylle. Det var en sak da vi kom til en bedrift for å se på prosessene og ba om å se sikkerhetskravene til programvaren. Spesialisten som tok seg av dette brukte lang tid på å lete etter:

– Nå, et sted i notatene var det en sti der dette dokumentet ligger.

Som et resultat mottok vi dokumentet en uke senere.

For krav, sjekker og annet, lag en side på f.eks. Confluence - Det er praktisk for alle.

Det er lettere å formatere det du allerede har og bruke det for å komme i gang.

Bruk Security Champions

Vanligvis, i et gjennomsnittlig selskap med 100-200 utviklere, er det én sikkerhetsspesialist som utfører flere funksjoner og ikke fysisk har tid til å sjekke alt. Selv om han prøver sitt beste, vil han alene ikke sjekke all koden som utviklingen genererer. For slike tilfeller er det utviklet et konsept - Sikkerhetsmestere.

Security Champions er personer i utviklingsteamet som er interessert i sikkerheten til produktet ditt.

Security Champion er et inngangspunkt til utviklingsteamet og en sikkerhetsevangelist rullet inn i en.

Vanligvis, når en sikkerhetsspesialist kommer til et utviklingsteam og påpeker en feil i koden, får han et overrasket svar:

- Og hvem er du? Jeg ser deg for første gang. Alt er bra med meg - seniorvennen min ga meg "søk" på kodegjennomgangen, vi går videre!

Dette er en typisk situasjon, fordi det er mye mer tillit til seniorer eller rett og slett lagkamerater som utvikleren hele tiden samhandler med på jobb og i kodegjennomgang. Hvis sikkerhetsmesteren i stedet for sikkerhetsoffiseren påpeker feilen og konsekvensene, vil hans ord ha større vekt.

Dessuten kjenner utviklere koden deres bedre enn noen sikkerhetsspesialist. For en person som har minst 5 prosjekter i et statisk analyseverktøy, er det vanligvis vanskelig å huske alle nyansene. Security Champions kjenner produktet sitt: hva som samhandler med hva og hva de skal se på først – de er mer effektive.

Så vurder å implementere Security Champions og utvide innflytelsen til sikkerhetsteamet ditt. Dette er også nyttig for mesteren selv: faglig utvikling på et nytt felt, utvide hans tekniske horisont, oppgradere tekniske, ledelsesmessige og lederegenskaper, øke markedsverdien. Dette er et element av sosial ingeniørkunst, dine "øyne" i utviklingsteamet.

Teststadier

Paradigme 20 til 80 sier at 20 % av innsatsen gir 80 % av resultatene. Disse 20 % er applikasjonsanalysepraksis som kan og bør automatiseres. Eksempler på slike aktiviteter er statisk analyse - SAST, dynamisk analyse - DAST и Åpen kildekode-kontroll. Jeg vil fortelle deg mer om aktivitetene, så vel som om verktøyene, hvilke funksjoner vi vanligvis møter når vi introduserer dem i prosessen, og hvordan du gjør det riktig.

Hovedproblemer med verktøy

Jeg vil belyse problemer som er relevante for alle virkemidler og krever oppmerksomhet. Jeg vil analysere dem mer detaljert for ikke å gjenta dem ytterligere.

Lang analysetid. Hvis det tar 30 minutter fra forpliktelse til utgivelse for alle tester og montering, vil informasjonssikkerhetssjekkene ta en dag. Så ingen vil bremse prosessen. Ta hensyn til denne funksjonen og trekk konklusjoner.

Høyt nivå Falsk Negativ eller Falsk Positiv. Alle produkter er forskjellige, alle bruker forskjellige rammer og hver sin kodestil. På forskjellige kodebaser og teknologier kan verktøy vise forskjellige nivåer av falsk negativ og falsk positiv. Så se på hva som er i din selskaper og for din applikasjoner vil vise gode og pålitelige resultater.

Ingen integrasjoner med eksisterende verktøy. Se på verktøy når det gjelder integrasjoner med det du allerede bruker. Hvis du for eksempel har Jenkins eller TeamCity, sjekk integreringen av verktøyene med denne programvaren, og ikke med GitLab CI, som du ikke bruker.

Mangel på eller overdreven kompleksitet av tilpasning. Hvis et verktøy ikke har et API, hvorfor er det da nødvendig? Alt som kan gjøres i grensesnittet skal være tilgjengelig gjennom API. Ideelt sett bør verktøyet ha muligheten til å tilpasse sjekker.

Ingen veikart for produktutvikling. Utviklingen står ikke stille, vi bruker alltid nye rammer og funksjoner, og skriver om gammel kode til nye språk. Vi vil være sikre på at verktøyet vi kjøper vil støtte nye rammeverk og teknologier. Derfor er det viktig å vite at produktet har ekte og riktig Roadmap utvikling.

Prosessegenskaper

I tillegg til funksjonene til verktøyene, ta hensyn til funksjonene i utviklingsprosessen. For eksempel er det å hindre utvikling en vanlig feil. La oss se på hvilke andre funksjoner som bør tas i betraktning og hva sikkerhetsteamet bør ta hensyn til.

For ikke å gå glipp av utvikling og utgivelsesfrister, opprette forskjellige regler og annerledes vise stoppere – kriterier for å stoppe byggeprosessen i nærvær av sårbarheter – for ulike miljøer. For eksempel forstår vi at den nåværende grenen går til utviklingsstanden eller UAT, noe som betyr at vi ikke stopper og sier:

«Du har sårbarheter her, du kommer ikke lenger!»

På dette tidspunktet er det viktig å fortelle utviklere at det er sikkerhetsproblemer som trenger oppmerksomhet.

Tilstedeværelsen av sårbarheter er ikke et hinder for videre testing: manuell, integrasjon eller manuell. På den annen side må vi på en eller annen måte øke sikkerheten til produktet, og slik at utviklerne ikke forsømmer det de finner trygt. Derfor gjør vi noen ganger dette: på standen, når den rulles ut til utviklingsmiljøet, varsler vi ganske enkelt utviklingen:

- Gutter, dere har problemer, vær så snill å ta hensyn til dem.

På UAT-stadiet viser vi igjen advarsler om sårbarheter, og på utgivelsesstadiet sier vi:

- Gutter, vi advarte dere flere ganger, dere gjorde ingenting - vi vil ikke slippe dere ut med dette.

Hvis vi snakker om kode og dynamikk, er det nødvendig å vise og advare om sårbarheter bare for de funksjonene og koden som nettopp ble skrevet i denne funksjonen. Hvis en utvikler flytter en knapp med 3 piksler og vi forteller ham at han har en SQL-injeksjon der og derfor må fikses snarest, er dette feil. Se kun på det som er skrevet nå og på endringen som kommer til søknaden.

La oss si at vi har en viss funksjonsfeil - måten applikasjonen ikke skal fungere på: penger overføres ikke, når du klikker på en knapp er det ingen overgang til neste side, eller produktet lastes ikke. Sikkerhetsdefekter - Dette er de samme feilene, men ikke når det gjelder applikasjonsdrift, men når det gjelder sikkerhet.

Ikke alle problemer med programvarekvalitet er sikkerhetsproblemer. Men alle sikkerhetsproblemer er relatert til programvarekvalitet. Sherif Mansour, Expedia.

Siden alle sårbarheter er de samme defektene, bør de ligge på samme sted som alle utviklingsfeil. Så glem rapporter og skumle PDF-er som ingen leser.

Da jeg jobbet i et utviklingsselskap, fikk jeg en rapport fra statiske analyseverktøy. Jeg åpnet den, ble forferdet, kokte kaffe, bladde i 350 sider, lukket den og fortsatte å jobbe. Store rapporter er døde rapporter. Vanligvis går de ingen steder, brevene blir slettet, glemt, tapt, eller bedriften sier at den aksepterer risikoen.

Hva å gjøre? Vi konverterer rett og slett de bekreftede defektene vi fant til en form som er praktisk for utvikling, for eksempel legger vi dem i et etterslep i Jira. Vi prioriterer mangler og eliminerer dem i prioritert rekkefølge, sammen med funksjonsfeil og testfeil.

Statisk analyse - SAST

Dette er en kodeanalyse for sårbarheter., men det er ikke det samme som SonarQube. Vi sjekker ikke bare etter mønstre eller stil. Det benyttes en rekke tilnærminger i analysen: i henhold til sårbarhetstreet, iht Dataflyt, ved å analysere konfigurasjonsfiler. Dette er alt som angår selve koden.

Fordeler med tilnærmingen: identifisere sårbarheter i kode på et tidlig stadium av utviklingennår det ikke finnes stativer eller ferdige verktøy ennå, og inkrementell skanning: skanning av en kodedel som har endret seg, og bare funksjonen vi gjør nå, noe som reduserer skannetiden.

Cons – dette er mangelen på støtte for de nødvendige språkene.

Nødvendige integrasjoner, som bør være i verktøyene, etter min subjektive mening:

• Integreringsverktøy: Jenkins, TeamCity og Gitlab CI.
• Utviklingsmiljø: Intellij IDEA, Visual Studio. Det er mer praktisk for en utvikler å ikke navigere i et uforståelig grensesnitt som fortsatt må huskes, men å se alle nødvendige integrasjoner og sårbarheter som han har funnet rett på arbeidsplassen i sitt eget utviklingsmiljø.
• Kodegjennomgang: SonarQube og manuell gjennomgang.
• Defektsporere: Jira og Bugzilla.

Bildet viser noen av de beste representantene for statisk analyse.

Det er ikke verktøyene som er viktige, men prosessen, så det finnes Open Source-løsninger som også er gode for å teste prosessen.

SAST Open Source vil ikke finne et stort antall sårbarheter eller komplekse DataFlows, men de kan og bør brukes når man bygger en prosess. De hjelper til med å forstå hvordan prosessen skal bygges, hvem som vil svare på feil, hvem som skal rapportere og hvem som skal rapportere. Hvis du vil utføre den innledende fasen av å bygge sikkerheten til koden din, bruk Open Source-løsninger.

Hvordan kan dette integreres hvis du er i begynnelsen av reisen din og ikke har noe: ingen CI, ingen Jenkins, ingen TeamCity? La oss vurdere integrering i prosessen.

Integrasjon på CVS-nivå

Hvis du har Bitbucket eller GitLab, kan du integrere på nivået System for samtidige versjoner.

Etter arrangement - trekke forespørsel, forplikte. Du skanner koden og byggestatusen viser om sikkerhetskontrollen bestod eller mislyktes.

Tilbakemelding. Selvfølgelig er tilbakemelding alltid nødvendig. Hvis du bare gjorde sikkerhet ved siden av, la det i en boks og ikke fortalte noen noe om det, og så på slutten av måneden dumpet en haug med feil - dette er ikke riktig og ikke bra.

Integrasjon med kodegjennomgangssystemet

En gang fungerte vi som standard anmelder for en teknisk AppSec-bruker i en rekke viktige prosjekter. Avhengig av om det er identifisert feil i den nye koden eller om det ikke er noen feil, setter anmelderen statusen på pull-forespørselen til "aksepter" eller "trenger arbeid" - enten er alt OK, eller lenkene til hva som må forbedres må forbedres. For integrasjon med versjonen som skal i produksjon har vi aktivert et sammenslåingsforbud dersom informasjonssikkerhetstesten ikke blir bestått. Vi inkluderte dette i den manuelle kodegjennomgangen, og andre deltakere i prosessen så sikkerhetsstatusene for denne prosessen.

Integrasjon med SonarQube

Mange har kvalitetsport når det gjelder kodekvalitet. Det er det samme her - du kan lage de samme portene bare for SAST-verktøy. Det vil være det samme grensesnittet, den samme kvalitetsporten, bare den vil bli kalt sikkerhetsport. Og også, hvis du har en prosess som bruker SonarQube, kan du enkelt integrere alt der.

Integrasjon på CI-nivå

Alt her er også ganske enkelt:

• På nivå med autotester, enhetstester.
• Inndeling etter utviklingstrinn: dev, test, prod. Ulike sett med regler eller forskjellige feiltilstander kan være inkludert: stopp sammenstillingen, ikke stopp sammenstillingen.
• Synkron/asynkron lansering. Vi venter på slutten av sikkerhetstestene eller ikke. Det vil si at vi bare lanserte dem og går videre, og så får vi status om at alt er bra eller dårlig.

Det hele er i en perfekt rosa verden. Det er ikke noe slikt i det virkelige liv, men vi streber. Resultatet av å kjøre sikkerhetskontroller bør være likt resultatene av enhetstester.

For eksempel tok vi et stort prosjekt og bestemte oss for at nå skal vi skanne det med SAST - OK. Vi presset dette prosjektet inn i SAST, det ga oss 20 000 sårbarheter og ved en viljesterk beslutning bestemte vi oss for at alt var bra. 20 000 sårbarheter er vår tekniske gjeld. Vi legger gjelden i en boks, vi vil sakte rydde opp og legge til feil til defekte sporere. La oss ansette et firma, gjøre alt selv, eller la Security Champions hjelpe oss – og teknisk gjeld vil reduseres.

Og alle nylig oppståtte sårbarheter i den nye koden må elimineres på samme måte som feil i en enhet eller i autotester. Relativt sett startet monteringen, vi kjørte den, to tester og to sikkerhetstester mislyktes. OK - vi gikk, så på hva som skjedde, fikset en ting, fikset en annen, kjørte den neste gang - alt var bra, ingen nye sårbarheter dukket opp, ingen tester mislyktes. Hvis denne oppgaven er dypere og du trenger å forstå den godt, eller å fikse sårbarheter påvirker store lag av det som ligger under panseret: en feil ble lagt til defektsporeren, blir den prioritert og rettet. Dessverre er ikke verden perfekt og tester feiler noen ganger.

Et eksempel på en sikkerhetsport er en analog av en kvalitetsport, når det gjelder tilstedeværelse og antall sårbarheter i koden.

Vi integrerer med SonarQube - plugin er installert, alt er veldig praktisk og kult.

Integrasjon med utviklingsmiljø

Integreringsalternativer:

• Kjøre en skanning fra utviklingsmiljøet før commit.
• Se resultater.
• Analyse av resultatene.
• Synkronisering med serveren.

Slik ser det ut å motta resultater fra serveren.

I vårt utviklingsmiljø Intellekt IDEA et ekstra element vises ganske enkelt som informerer deg om at slike sårbarheter ble oppdaget under skanningen. Du kan umiddelbart redigere koden, se på anbefalinger og Flytgraf. Alt dette ligger på utviklerens arbeidsplass, noe som er veldig praktisk - det er ikke nødvendig å følge andre lenker og se på noe ekstra.

Open Source

Dette er favorittemnet mitt. Alle bruker Open Source-biblioteker - hvorfor skrive en haug med krykker og sykler når du kan ta et ferdig bibliotek der alt allerede er implementert?

Selvfølgelig er dette sant, men biblioteker er også skrevet av mennesker, de inkluderer også visse risikoer og det er også sårbarheter som periodisk, eller konstant, rapporteres. Derfor er det neste trinn i Application Security - dette er analysen av Open Source-komponenter.

Åpen kildekode-analyse - OSA

Verktøyet inkluderer tre store trinn.

Søker etter sårbarheter i biblioteker. For eksempel vet verktøyet at vi bruker et eller annet bibliotek, og at i CVE eller det er noen sårbarheter i feilsporere som er relatert til denne versjonen av biblioteket. Når du prøver å bruke det, vil verktøyet gi en advarsel om at biblioteket er sårbart og råder deg til å bruke en annen versjon som ikke har sårbarheter.

Analyse av lisensrenhet. Dette er ikke spesielt populært her ennå, men hvis du jobber i utlandet, så kan du fra tid til annen få skatt der for å bruke en åpen kildekode-komponent som ikke kan brukes eller endres. I henhold til lisensbibliotekets retningslinjer kan vi ikke gjøre dette. Eller, hvis vi endret den og bruker den, bør vi legge ut koden vår. Selvfølgelig er det ingen som ønsker å publisere koden til produktene sine, men du kan også beskytte deg mot dette.

Analyse av komponenter som brukes i et industrielt miljø. La oss forestille oss en hypotetisk situasjon at vi endelig har fullført utviklingen og lansert den siste utgivelsen av mikrotjenesten vår. Han bor der fantastisk - en uke, en måned, et år. Vi samler det ikke, vi utfører ikke sikkerhetskontroller, alt ser ut til å være i orden. Men plutselig, to uker etter utgivelsen, dukker det opp en kritisk sårbarhet i Open Source-komponenten, som vi bruker i denne spesielle konstruksjonen, i det industrielle miljøet. Hvis vi ikke registrerer hva og hvor vi bruker, vil vi ganske enkelt ikke se denne sårbarheten. Noen verktøy har muligheten til å overvåke sårbarheter i biblioteker som i dag brukes i bransjen. Det er veldig nyttig.

funksjoner:

• Ulike retningslinjer for ulike utviklingsstadier.
• Overvåking av komponenter i et industrielt miljø.
• Kontroll av biblioteker i organisasjonen.
• Støtte for ulike byggesystemer og språk.
• Analyse av Docker-bilder.

Noen få eksempler på industriledere som er engasjert i åpen kildekode-analyse.

Den eneste gratis er denne Avhengighetssjekk fra OWASP. Du kan slå den på i de første stadiene, se hvordan den fungerer og hva den støtter. I utgangspunktet er disse alle skyprodukter, eller on-premise, men bak basen sendes de fortsatt til Internett. De sender ikke bibliotekene dine, men hash eller deres egne verdier, som de beregner, og fingeravtrykk til serveren deres for å motta informasjon om tilstedeværelsen av sårbarheter.

Prosessintegrasjon

Perimeterkontroll av biblioteker, som er lastet ned fra eksterne kilder. Vi har eksterne og interne depoter. For eksempel kjører Event Central Nexus, og vi ønsker å sikre at det ikke er noen sårbarheter i vårt depot med en "kritisk" eller "høy" status. Du kan konfigurere proxying ved å bruke Nexus Firewall Lifecycle-verktøyet slik at slike sårbarheter blir avskåret og ikke havner i det interne depotet.

Integrasjon i CI. På samme nivå med autotester, enhetstester og inndeling i utviklingstrinn: dev, test, prod. På hvert trinn kan du laste ned hvilke som helst biblioteker, bruke hva som helst, men hvis det er noe vanskelig med den "kritiske" statusen, er det kanskje verdt å trekke utviklernes oppmerksomhet til dette på produksjonsstadiet.

Integrasjon med artefakter: Nexus og JFrog.

Integrasjon i utviklingsmiljøet. Verktøyene du velger bør ha integrasjon med utviklingsmiljøer. Utvikleren må ha tilgang til skanneresultatene fra sin arbeidsplass, eller muligheten til å skanne og sjekke koden selv for sårbarheter før han forplikter seg til CVS.

CD-integrasjon. Dette er en kul funksjon som jeg virkelig liker og som jeg allerede har snakket om – overvåking av fremveksten av nye sårbarheter i et industrielt miljø. Det fungerer noe sånt som dette.

Vi har Offentlige komponentlager — noen verktøy utenfor, og vårt interne depot. Vi vil at den kun skal inneholde pålitelige komponenter. Ved fullmakt av en forespørsel kontrollerer vi at det nedlastede biblioteket ikke har sårbarheter. Hvis det faller inn under visse retningslinjer som vi setter og nødvendigvis koordinerer med utviklingen, laster vi det ikke opp og blir bedt om å bruke en annen versjon. Følgelig, hvis det er noe virkelig kritisk og dårlig i biblioteket, vil ikke utvikleren motta biblioteket på installasjonsstadiet - la ham bruke en høyere eller lavere versjon.

• Ved bygging sjekker vi at ingen har sklidd noe dårlig, at alle komponenter er trygge og at ingen har tatt med noe farlig på flash-stasjonen.
• Vi har bare pålitelige komponenter i depotet.
• Når vi distribuerer, sjekker vi nok en gang selve pakken: war, jar, DL eller Docker image for å sikre at den er i samsvar med policyen.
• Når vi går inn i bransjen overvåker vi hva som skjer i industrimiljøet: kritiske sårbarheter vises eller ikke vises.

Dynamisk analyse – DAST

Dynamiske analyseverktøy er fundamentalt forskjellige fra alt som har blitt sagt før. Dette er en slags etterligning av brukerens arbeid med applikasjonen. Hvis dette er en nettapplikasjon, sender vi forespørsler, simulerer arbeidet til klienten, klikker på knappene på forsiden, sender kunstige data fra skjemaet: anførselstegn, parentes, tegn i forskjellige kodinger, for å se hvordan applikasjonen fungerer og behandler eksterne data.

Det samme systemet lar deg sjekke malsårbarheter i åpen kildekode. Siden DAST ikke vet hvilken åpen kildekode vi bruker, kaster den ganske enkelt "ondsinnede" mønstre og analyserer serverens svar:

– Ja, det er et deserialiseringsproblem her, men ikke her.

Det er store risikoer ved dette, for gjennomfører du denne sikkerhetstesten på samme benk som testerne jobber med, kan det skje ubehagelige ting.

• Høy belastning på applikasjonsservernettverket.
• Ingen integrasjoner.
• Evne til å endre innstillingene for den analyserte applikasjonen.
• Det er ingen støtte for de nødvendige teknologiene.
• Vanskeligheter med å sette opp.

Vi hadde en situasjon da vi endelig lanserte AppScan: vi brukte lang tid på å prøve å få tilgang til applikasjonen, fikk 3 kontoer og var fornøyde - vi skal endelig sjekke alt! Vi startet en skanning, og det første AppScan gjorde var å gå inn i administrasjonspanelet, stikke hull på alle knappene, endre halvparten av dataene og deretter drepe serveren fullstendig med sin postskjema-forespørsler. Utvikling med testing sa:

- Gutter, tuller du?! Vi ga deg regnskap, og du satte opp en stand!

Vurder mulige risikoer. Ideelt sett forbereder du et eget stativ for testing av informasjonssikkerhet, som vil være isolert fra resten av miljøet i det minste på en eller annen måte, og kontroller adminpanelet betinget, helst i manuell modus. Dette er en pentest - de gjenværende innsatsprosentene som vi ikke vurderer nå.

Det er verdt å vurdere at du kan bruke dette som en analog av lasttesting. På det første trinnet kan du slå på en dynamisk skanner med 10-15 tråder og se hva som skjer, men vanligvis, som praksis viser, ingenting bra.

Noen få ressurser som vi vanligvis bruker.

Verdt å fremheve Burp-suite er en "sveitsisk kniv" for enhver sikkerhetsekspert. Alle bruker det og det er veldig praktisk. En ny demoversjon av enterprise-utgaven er nå utgitt. Hvis det tidligere bare var et frittstående verktøy med plugins, lager utviklerne nå endelig en stor server som det vil være mulig å administrere flere agenter fra. Dette er kult, jeg anbefaler deg å prøve det.

Prosessintegrasjon

Integrasjon skjer ganske bra og enkelt: start skanningen etter vellykket installasjon søknader om stand og skanning etter vellykket integrasjonstesting.

Hvis integrasjonene ikke fungerer eller det er stubber og mock-funksjoner, er det meningsløst og ubrukelig - uansett hvilket mønster vi sender, vil serveren fortsatt svare på samme måte.

• Ideelt sett et eget teststativ.
• Før du tester, skriv ned påloggingssekvensen.
• Testing av administrasjonssystemet er kun manuell.

prosessen

Litt generalisert om prosessen generelt og om arbeidet til hvert verktøy spesielt. Alle applikasjoner er forskjellige - en fungerer bedre med dynamisk analyse, en annen med statisk analyse, en tredje med OpenSource-analyse, pentests, eller noe helt annet, for eksempel hendelser med waf.

Hver prosess trenger kontroll.

For å forstå hvordan en prosess fungerer og hvor den kan forbedres, må du samle inn beregninger fra alt du kan få tak i, inkludert produksjonsmålinger, beregninger fra verktøy og fra defektsporere.

All informasjon er nyttig. Det er nødvendig å se fra forskjellige vinkler på hvor dette eller det verktøyet er bedre brukt, hvor prosessen spesifikt synker. Det kan være verdt å se på responstider for utvikling for å se hvor du kan forbedre prosessen basert på tid. Jo mer data, jo flere seksjoner kan bygges fra toppnivå til detaljene i hver prosess.

Siden alle statiske og dynamiske analysatorer har sine egne APIer, egne lanseringsmetoder, prinsipper, noen har planleggere, andre ikke - vi skriver et verktøy AppSec Orchestrator, som lar deg opprette et enkelt inngangspunkt i hele prosessen fra produktet og administrere det fra ett punkt.

Ledere, utviklere og sikkerhetsingeniører har ett inngangspunkt der de kan se hva som kjører, konfigurere og kjøre en skanning, motta skanneresultater og sende inn krav. Vi prøver å gå bort fra papirarbeid, å oversette alt til et menneskelig, som brukes av utvikling - sider på Confluence med status og beregninger, defekter i Jira eller i ulike defektsporere, eller integrering i en synkron/asynkron prosess i CI /CD.

Nøkkelfunksjoner

Verktøy er ikke hovedsaken. Tenk først gjennom prosessen – implementer deretter verktøyene. Verktøyene er gode, men dyre, så du kan starte med prosessen og bygge kommunikasjon og forståelse mellom utvikling og sikkerhet. Fra et sikkerhetssynspunkt er det ikke nødvendig å "stoppe" alt. Fra et utviklingssynspunkt, hvis det er noe høyt mega superkritisk, så må det elimineres, og ikke lukke øynene for problemet.

Produktkvalitet - felles mål både sikkerhet og utvikling. Vi gjør én ting, vi prøver å sikre at alt fungerer som det skal og at det ikke er omdømmerisiko eller økonomiske tap. Dette er grunnen til at vi fremmer en DevSecOps, SecDevOps-tilnærming for å forbedre kommunikasjonen og forbedre kvaliteten på produktet.

Start med det du allerede har: krav, arkitektur, delsjekker, opplæring, retningslinjer. Det er ikke nødvendig å umiddelbart bruke all praksis på alle prosjekter - bevege seg iterativt. Det er ingen enkelt standard - eksperiment og prøve forskjellige tilnærminger og løsninger.

Det er et likhetstegn mellom informasjonssikkerhetsfeil og funksjonsfeil.

Automatiser altsom beveger seg. Det som ikke beveger seg, flytt det og automatiser det. Hvis noe gjøres for hånd, er det ikke en god del av prosessen. Kanskje det er verdt å gjennomgå det og automatisere det også.

Hvis størrelsen på IS-teamet er liten - bruk Security Champions.

Kanskje det jeg snakket om ikke vil passe deg, og du vil finne på noe eget - og det er bra. Men velg verktøy basert på kravene til prosessen din. Ikke se på hva samfunnet sier, at dette verktøyet er dårlig og dette er bra. Kanskje vil det motsatte være sant for produktet ditt.

Krav til verktøy.

• Lavt nivå Falsk Positiv.
• Tilstrekkelig analysetid.
• Brukervennligheten.
• Tilgjengelighet av integrasjoner.
• Forstå veikart for produktutvikling.
• Mulighet for å tilpasse verktøy.

Yuris rapport ble kåret til en av de beste på DevOpsConf 2018. For å bli kjent med enda flere interessante ideer og praktiske case, kom til Skolkovo 27. og 28. mai DevOpsConf innenfor festival RIT++. Enda bedre, hvis du er klar til å dele opplevelsen din, da søke om for rapporten frem til 21. april.

Kilde: www.habr.com