Frykt og hat DevSecOps

Vi hadde 2 kodeanalysatorer, 4 verktøy for dynamisk testing, egne kreasjoner og 250 skript. Ikke at alt dette var nødvendig i den nåværende prosessen, men siden jeg begynte å implementere DevSecOps, må jeg gå hele veien.

Kilde. Karakterforfattere: Justin Roiland og Dan Harmon.

Hva er SecDevOps? Og DevSecOps? Hva er forskjellene? Applikasjonssikkerhet – hva handler det om? Hvorfor fungerer ikke den klassiske tilnærmingen lenger? På alle disse spørsmålene har vi svar Juri Shabalin fra Swordfish Security. 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 å ødelegge noe, hvordan man passerer de viktigste testtrinnene for sikkerhet, hvilke verktøy som kan brukes, hvordan de skiller seg fra hverandre og hvordan de skal konfigureres for å unngå fallgruver.

Om taleren: Juri Shabalin – Chief Security Architect i selskapet Swordfish Security. Ansvarlig for implementering av SSDL, for generell integrering av applikasjonsanalyseverktøy i et samlet utviklings- og testøkosystem. 7 års erfaring innen informasjonssikkerhet. Har jobbet i Alfa-Bank, Sberbank og i Positive Technologies, som utvikler programvare og tilbyr tjenester. Taler på internasjonale konferanser som ZerONights, PHDays, RISSPA, OWASP.

Applikasjonssikkerhet: hva handler det om?

Applikasjonssikkerhet er et område innen sikkerhet som fokuserer på sikkerheten til applikasjoner. Det handler ikke om infrastruktur eller nettverkssikkerhet, men om det vi skriver og det utviklerne jobber med – det gjelder svakheter og sårbarheter i selve applikasjonen.

Retning SDL eller SDLC — Sikkerhetsutviklingslivssyklus ble utviklet av Microsoft. I diagrammet – den kanoniske modellen for SDLC, hvis hovedoppgave er å inkludere sikkerhet i hver fase av utviklingen, fra krav til utgivelse og produksjon. Microsoft innså at det var for mange feil i produksjon, de ble flere, og noe måtte gjøres, og foreslo denne tilnærmingen, som har blitt kanonisk.

Applikasjonssikkerhet og SSDL er ikke rettet mot å oppdage sårbarheter, som det ofte antas, men mot å forhindre deres oppkomst. Over tid har den kanoniske tilnærmingen fra Microsoft blitt forbedret og utviklet, med en dypere detaljinnsikt.

Den kanoniske SDLC er sterkt detaljert i forskjellige metodologier - OpenSAMM, BSIMM, OWASP. Metodologiene er forskjellige, men generelt liknande.

Bygge sikkerhet inn modningsmodellen

Jeg liker best BSIMM — Bygge sikkerhet inn modningsmodellen. 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.

Hver av de 112 aktivitetene har 3 modenhetsnivåer: grunnleggende, mellomliggende og avansert. Alle 12 praksiser kan læres 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.

Hvorfor DevSecOps

DevOps er en stor felles prosess der man må ta hensyn til sikkerhet.

Opprinnelig DevOps 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å produktet ved slutten av utgivelsen. Dette er en klassisk tilnærming, der sikkerhetsteamene var adskilt fra utviklingen og ikke deltok i prosessen.

Hovedproblemet er nettopp at sikkerheten står adskilt fra utviklingen. Vanligvis er det en slags sikkerhetssirkel med 2-3 store og dyre verktøy. Hver sjette måned kommer kildekoden eller applikasjonen som må sjekkes, og en gang i året utføres penetrasjonstester. Alt dette fører til at lanseringstidene blir utsatt, og utvikleren får akutt behov for å håndtere et stort antall sårbarheter fra automatiserte verktøy. Alt dette er umulig å sortere og fikse, fordi resultatene fra de siste seks månedene ikke er sortert, og nå kommer det en ny bølge.

I løpet av vårt arbeid i selskapet ser vi at sikkerhet i alle felt og industrier innser at det er på tide å komme ajour og samarbeide med utviklingen i ett hjul - i Agile. DevSecOps-paradigmet passer utmerket inn i metodikken for smidig utvikling, med implementering, støtte og deltakelse i hver utgivelse og iterasjon.

Overgangen til DevSecOps

Det viktigste ordet i Security Development Lifecycle er "prosessen"Du må forstå dette før du tenker på å kjøpe verktøy.

Det er ikke nok å bare inkludere verktøyene i DevOps-prosessen — interaksjon og forståelse mellom deltakerne i prosessen er viktig.

Menneskene er viktigere enn verktøyene

Planlegging av en sikker utviklingsprosess begynner ofte med valg og kjøp av verktøy, men ender med forsøk på å integrere verktøyet i den nåværende prosessen, som forblir nettopp det — forsøk. Dette fører til triste konsekvenser, fordi hvert verktøy har sine egne funksjoner og begrensninger.

Et vanlig tilfelle er når sikkerhetsavdelingen velger et godt, dyrt verktøy med mange muligheter, og presenterer det for utviklerne — å integere det i prosessen. Men det lar seg ikke gjøre — prosessen er bygget slik at begrensningene til det allerede kjøpte verktøyet ikke passer inn i den nåværende paradygmen.

Først beskriv hvilket resultat du ønsker og hvordan prosessen vil se ut. Dette vil hjelpe til med å forstå rollene til verktøyet og sikkerhet i prosessen.

Begynn med det som allerede brukes

Før du kjøper dyre verktøy, se på hva du allerede har. Hver bedrift har sikkerhetskrav som stilles til utviklingen, det er sjekker, pentester — hvorfor ikke transformere alt dette til en forståelig og brukervennlig form?

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

— Nå, et sted i notatene var det en sti til dette dokumentet.

Til slutt fikk vi dokumentet etter en uke.

For krav, sjekker og annet, lag en side, for eksempel på Confluence — det er praktisk for alle.

Det er enklere å omformatere det som allerede finnes og bruke det som utgangspunkt.

Bruk Security Champions

Vanligvis, i et middels stort selskap med 100-200 utviklere, jobber det en sikkerhetsekspert som utfører flere funksjoner, og har ikke fysisk mulighet til å sjekke alt. Selv om han gjør sitt beste — kan han ikke sjekke all koden som utviklingen genererer alene. For slike tilfeller er konseptet utviklet — Security Champions.

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

Security Champion er inngangspunktet til utviklingsteamet og en sikkerhetsevangelsist i én og samme person.

Som regel, når en sikkerhetsrepresentant kommer inn i utviklingsteamet og påpeker en feil i koden, får de et overrasket svar:

— Hvem er du? Jeg ser deg for første gang. Alt er i orden for meg — min senior kollega la inn "apply" på code review, så vi går videre!

Dette er en typisk situasjon fordi det er mye større tillit til seniorer eller bare kolleger i teamet som utvikleren jobber tett med og har code review med. Hvis en Security Champion påpeker en feil og konsekvenser i stedet for sikkerhetsrepresentanten, vil deres ord ha mer vekst.

Utviklere kjenner også koden sin bedre enn noen sikkerhetsrepresentant. For en person som har minst 5 prosjekter i statisk analyseverktøy, er det vanligvis vanskelig å huske alle nyansene. Security Champions kjenner produktet sitt: hva som interagerer med hva og hva man skal se på først — de er mer effektive.

Så vurder å implementere Security Champions og utvide sikkerhetsteamets innflytelse. For selve mesteren er dette også nyttig: profesjonell utvikling på et nytt område, utvidelse av teknisk horisont, forbedring av tekniske, ledelsesmessige og lederferdigheter, og økning av markedsverdi. Dette er et element av sosial ingeniørkunst, dine "øyne" i utviklingsteamet.

Testtrinn

Paradigmet 20 av 80 sier at 20 % av innsatsen gir 80 % av resultatene. Disse 20 % er praksiser for applikasjonsanalyse som kan og bør automatiseres. Eksempler på slike aktiviteter er statisk analyse — SAST, dynamisk analyse — DAST, og kontroll av Open Source. Jeg vil fortelle mer om aktivitetene og hvilke verktøy, samt hvilke særtrekk vi vanligvis støter på når vi implementerer dem i prosessen, og hvordan man gjør det riktig.

Hovedproblemer med verktøyene

Jeg vil fremheve aktuelle problemer som berører alle verktøyene, som krever oppmerksomhet. Jeg vil gå mer i dybden på dem for ikke å gjenta meg selv senere.

Lang tid for analyse. 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.

Høyt nivå av False Negative eller False Positive. Alle produkter er forskjellige, alle bruker forskjellige rammeverk og har sin egen stil for koding. På forskjellige kodebaser og teknologier kan verktøyene vise varierende nivå av False Negative og False Positive. Så se på hva som gjelder for dere og for deres applikasjoner som vil gi gode og pålitelige resultater.

Ingen integrasjoner med eksisterende verktøy. Se på verktøyene fra vinkelen av integrasjoner med det dere allerede bruker. For eksempel, hvis dere har Jenkins eller TeamCity, sjekk integrasjonen av verktøyene med denne programvaren, og ikke med GitLab CI som dere ikke bruker.

Manglende eller overdreven kompleksitet i tilpasning. Hvis verktøyet ikke har API, hvorfor trenger man det? Alt som kan gjøres i grensesnittet skal være tilgjengelig gjennom API. Ideelt sett bør verktøyet ha mulighet for tilpasning av sjekker.

Ingen utviklings-roadmap. Utviklingen står ikke stille, vi bruker alltid nye rammeverk og funksjoner, og omskriver gammel kode til nye språk. Vi ønsker å 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 en reell og korrekt roadmap for utvikling.

Prosessens særegenheter

Utover egenskapene til verktøyene, ta også hensyn til egenskapene ved utviklingsprosessen. For eksempel er det en typisk feil å forstyrre utviklingen. La oss se hvilke andre særegenheter vi bør vurdere og hva sikkerhetsteamet bør være oppmerksom på.

For å unngå å forsinke utviklings- og lanseringsfrister, lag ulike regler og forskjellige show stoppers — kriterier for å stoppe byggeprosessen ved tilstedeværelse av sårbarheter — for forskjellige miljøer. For eksempel forstår vi at den nåværende grenen går til utviklingsmiljøet eller UAT, så vi stopper ikke og sier:

— Dere har sårbarheter her, dere kan ikke gå videre!

På dette stadiet er det viktig å informere utviklerne om sikkerhetsproblemer som de bør være oppmerksomme på.

Tilgjengeligheten av sårbarheter er ikke en hindring for videre testing.: manuell, integrering eller manual. På den annen side trenger vi å forbedre sikkerheten til produktet, så utviklerne må være oppmerksomme på hva sikkerhetsanalysene finner. Derfor noen ganger handler vi slik: når vi distribuerer på utviklingsmiljøet, varsler vi utviklingen:

— Hei, dere har problemer, vær så snill og ta hensyn til dem.

I UAT-fasen viser vi igjen varsler om sårbarheter, og i produksjonsfasen sier vi:

— Hei, vi har advart flere ganger, dere har ikke gjort noe - vi kan ikke slippe dere ut med dette.

Når det gjelder koden og dynamikken, må vi vise og varsle om sårbarheter 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å rettes opp umiddelbart - det er feil. Se kun på det som er skrevet nå, og på den endringen som kommer inn i applikasjonen.

La oss si at vi har en funksjonell feil - hvordan applikasjonen ikke skal fungere: penger overføres ikke, klikker man på knappen, er det ingen overgang til neste side, eller varer lastes ikke opp. Sikkerhetsdefekter — det er også defekter, men ikke med hensyn til applikasjonens arbeid, men i forhold til sikkerhet.

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

Siden alle sårbarheter er slike defekter, bør de finnes der hvor alle utviklingsfeil er. Så glem rapportene og de skremmende PDF-ene som ingen leser.

Da jeg jobbet for et selskap som drev med utvikling, fikk jeg tilsendt en rapport fra statiske analyseverktøy. Jeg åpnet den, ble forskrekket, lagde meg kaffe, bladde gjennom 350 sider, lukket den og fortsatte med arbeidet mitt. Store rapporter er døde rapporter. De går vanligvis ingen steder, e-poster slettes, glemmes, mistes, eller forretningen sier at de aksepterer risikoer.

Hva gjør 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ølge etter prioritet, på lik linje med funksjonelle feil og testfeil.

Statisk analyse - SAST

Dette er en kodeanalyse for sårbarheter, men dette er ikke det samme som SonarQube. Vi sjekker ikke bare ut ifra mønstre eller stil. I analysen brukes en rekke tilnærminger: ved hjelp av sårbarhetstreet, ved DataFlow, ved analyse av konfigurasjonsfiler. Dette er alt som gjelder koden direkte.

Fordeler med tilnærmingen: avdekking av sårbarheter i koden tidlig i utviklingsprosessen, når det fortsatt ikke finnes miljøer og verktøy er klare, og mulighet for inkrementell skanning: skanning av den delen av koden som har blitt endret, og bare av den funksjonaliteten vi jobber med nå, noe som reduserer skanningstiden.

Ulemper — er fraværet av støtte for nødvendige språk.

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

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

Bildet viser noen av de beste representantene for statisk analyse.

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

SAST Open Source vil ikke finne et stort antall sårbarheter eller komplekse DataFlow, men når prosessen bygges, kan og bør de brukes. De hjelper til med å forstå hvordan prosessen skal bygges, hvem som skal svare på feilene, hvem som skal rapportere og hvem som skal rapportere tilbake. Hvis du ønsker å gjennomføre det første steget i oppbyggingen av sikkerheten til koden din - bruk Open Source-løsninger.

Hvordan kan dette integreres hvis du er i starten av reisen, hvis du ikke har noe: hverken CI, Jenkins eller TeamCity? La oss se på integrasjoner i prosessen.

Integrasjon på CVS-nivå

Hvis du har Bitbucket eller GitLab, kan du gjøre integrasjon på nivået Concurrent Versions System.

Ved hendelse — pull request, commit. Du skanner koden og viser i statusen til byggingen om sikkerhetskontrollen har bestått eller ikke.

Tilbakemelding. Uten tvil er tilbakemelding alltid nødvendig. Hvis du bare har utført oppgaven på sikkerhetssiden, pakket det inn i en boks og fortalt ingen om det, og deretter på slutten av måneden kommer med en haug med feil - det er ikke riktig og ikke bra.

Integrasjon med systemet for kodegjennomgang

En gang hadde vi en teknisk bruker fra AppSec som standardgjennomgjører for viktige prosjekter. Avhengig av om det ble funnet feil i den nye koden eller ei, tildeler gjennomgangeren statusen til pull request som «akseptert» eller «trenger arbeid» - enten alt er OK, eller det er behov for videre arbeid med linker til hva som må forbedres. For integreringen med versjonen som går til produksjon, hadde vi aktivert forbud mot fletning hvis testen for informasjonssikkerhet ikke bestod. Vi inkluderte dette i manuell kodegjennomgang, og de andre deltakerne i prosessen så sikkerhetsstatusene for nettopp denne spesifikke prosessen.

Integrasjon med SonarQube

Mange har quality gate for kodekvalitet. Her er det det samme - man kan lage de samme gates bare for SAST-verktøy. Det vil være det samme grensesnittet, den samme quality gate, men den vil bli kalt security gate. Og på samme måte, hvis du har satt opp prosessen med SonarQube, kan du enkelt integrere alt dit.

Integrasjon på CI-nivå

Her er det også ganske enkelt:

• På samme nivå som automatiserte tester, enhetstester.
• Oppdeling etter utviklingsfaser: dev, test, prod. Ulike sett med regler kan aktiveres, eller forskjellige feilkriterier: stoppe byggingen, ikke stoppe byggingen.
• Synkron/asin.kron oppstart. Vi venter på å få vite om sikkerhetstestene er ferdige eller ikke. Det vil si at vi bare startet dem og går videre, og deretter kommer statusen til oss om at alt er bra eller dårlig.

Dette er alt i en ideell verden. I det virkelige liv finnes ikke dette, men vi streber etter det. Resultatet av sikkerhetskontrollene bør være likt resultatene fra enhetstestene.

For example, we took on a large project and decided that we would now scan it with SAST — OK. We fed this project into SAST, which reported 20,000 vulnerabilities, and by force of will, we accepted that everything was fine. 20,000 vulnerabilities — that’s our technical debt. We'll box up the debt, gradually tackle it, and log bugs in the defect trackers. We’ll hire a company, do everything ourselves, or be assisted by Security Champions — and the technical debt will decrease.

All newly appeared vulnerabilities in the new code must be resolved just like errors in unit or automated tests. Conditionally speaking, a build was launched, ran the tests, two tests fell and two security tests failed. OK — we checked what happened, fixed one issue, fixed the other, ran the tests next time — all good, no new vulnerabilities appeared, tests were not failed. If this task is deeper and needs a thorough investigation, or fixing vulnerabilities affects large parts of what lies beneath: a bug was logged in the defect tracker, it gets prioritized and fixed. Unfortunately, the world is not perfect, and tests sometimes fail.

An example of a security gate — analogous to a quality gate, based on the presence and number of vulnerabilities in the code.

We integrate with SonarQube — the plugin is installed, everything is very convenient and cool.

Integration with the development environment

Integration capabilities:

• Running scans from the development environment even before a commit.
• Viewing results.
• Analyzing results.
• Synchronization with the server.

This is what obtaining results from the server looks like.

In our development environment Intellij IDEA there simply appears an additional item that informs that vulnerabilities were found during the scan. You can immediately fix the code, check recommendations and Flow Graph. Everything is located at the developer's workstation, which is very convenient — no need to navigate through additional links to check something else.

Open Source

This is my favorite topic. Everyone uses Open Source libraries — why write a bunch of workarounds and wheel reinventions when you can use a ready-made library where everything is already implemented?

Selvfølgelig, det er slik, men biblioteker skrives også av mennesker, og de medfører også bestemte risikoer og inneholder også sårbarheter som av og til eller stadig rapporteres. Derfor er det neste trinnet i Application Security – analyse av Open Source-komponenter.

Analyse av Open Source – OSA

Verktøyet inkluderer tre store faser.

Søke etter sårbarheter i bibliotekene. For eksempel vet verktøyet at vi bruker et bibliotek, og at i CVE eller i bug-trackere finnes det sårbarheter som angår denne versjonen av biblioteket. Når man prøver å bruke det, vil verktøyet gi en advarsel om at biblioteket er sårbart, og anbefale å bruke en annen versjon hvor sårbarhetene ikke finnes.

Analyse av lisensrenhet. Dette er ennå ikke spesielt populært her, men hvis du jobber med utenlandske prosjekter, kan du noen ganger få problemer for å bruke en Open Source-komponent som ikke kan brukes eller modifiseres. I henhold til lisenspolitikken til biblioteket, kan vi ikke gjøre dette. Hvis vi har modifisert det og bruker det, må vi legge ut koden vår. Selvfølgelig ønsker ingen å publisere koden til sine produkter, men det finnes måter å beskytte seg mot dette.

Analyse av komponenter som brukes i industrien. La oss anta en hypotetisk situasjon hvor vi endelig har fullført utviklingen og utgitt den siste versjonen av mikrotjenesten vår. Den lever der fantastisk – en uke, en måned, et år. Vi samler den ikke inn, gjennomfører ikke sikkerhetssjekker, alt virker bra. Men plutselig, to uker etter utgivelsen, avdekkes en kritisk sårbarhet i Open Source-komponenten vi bruker nettopp i denne utgitt versjonen, i produksjonsmiljøet. Hvis vi ikke registrerer hva og hvor vi bruker, vil vi bare ikke få med oss denne sårbarheten. I enkelte verktøy er det muligheter for å overvåke sårbarheter i bibliotekene som nå brukes i produksjon. Dette er veldig nyttig.

Muligheter:

• Ulike retningslinjer for forskjellige faser av utviklingen.
• Overvåking av komponenter i produksjonsmiljøet.
• Kontroll av bibliotekene innenfor organisasjonens rammer.
• Støtte for ulike byggesystemer og språk.
• Analyse av Docker-bilder.

Noen eksempler på ledere innen området som jobber med analyse av Open Source.

Den eneste gratis av dem er Dependency-Check fra OWASP. Det kan aktiveres i de tidlige fasene for å se hvordan det fungerer og hva det støtter. Hovedsakelig er dette alle skyprodukter eller on-premise, men til tross for dette blir de fortsatt sendt til internett. De sender ikke dine biblioteker, men snarere hasher eller sine egne verdier som de beregner, og fingeravtrykk til sine servere for å få varsler om sårbarheter.

Integrasjon i prosessen

Bokholderkontroll i perimetern, som lastes ned fra eksterne kilder. Vi har både eksterne og interne depot. For eksempel, inne i Event Central har vi Nexus, og vi ønsker at det ikke skal være noen sårbarheter med status "kritisk" eller "høy" i vårt interne depot. Det er mulig å konfigurere proxy med verktøyet Nexus Firewall Lifecycle for å stenge slike sårbarheter ute fra det interne depot.

Integrasjon i CI. På samme nivå som autotester, enhetstester og oppdeling etter utviklingsfaser: dev, test, prod. I hver fase kan du laste ned alle bibliotekene, bruke hva som helst, men hvis det er noe alvorlig med status 'kritisk', vil kanskje utviklerne være enige i at det er noe de bør være oppmerksomme på før produksjon.

Integrasjon med artefaktlagre: Nexus og JFrog.

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

Integrasjon i CD. Dette er en fantastisk funksjon som jeg liker veldig godt og som jeg allerede har snakket om – overvåking av nye sårbarheter i produksjonsmiljøet. Det fungerer omtrent slik.

Vi har Offentlige komponentdepoter — noen verktøy utenfor, og vårt interne lager. Vi vil at det kun skal være trusted components der. Når vi proxier en forespørsel, kontrollerer vi at det nedlastede biblioteket ikke har sårbarheter. Hvis det faller under spesifikke retningslinjer som vi setter og som nødvendigvis må godkjennes av utviklingen, laster vi det ikke opp, og det kommer et avslag om å bruke en annen versjon. Dermed, hvis det er noe virkelig kritisk og dårlig i biblioteket, vil utvikleren ikke få biblioteket på installasjonsstadiet—han må bruke en høyere eller lavere versjon.

• Ved bygging sjekker vi at ingen har forsøkt å lure inn noe dårlig, at alle komponentene er sikre, og at ingen har ført inn noe farlig på en USB-enhet.
• I lageret vårt har vi kun trusted components.
• Ved distribusjon sjekker vi igjen selve pakken: war, jar, DL eller Docker-bilde for å se at det er i samsvar med retningslinjene.
• Når vi går ut i produksjon overvåker vi hva som skjer i det industrielle miljøet: dukker det opp kritiske sårbarheter eller ikke.

Dynamisk analyse – DAST

Verktøyene for dynamisk analyse skiller seg radikalt fra alt som er sagt før. Dette er en form for simulering av brukerens interaksjon med applikasjonen. Hvis det er en webapplikasjon, sender vi forespørslene som imiterer klientens arbeid, trykker på knapper på fronten, sender kunstige data fra skjemaet: anførselstegn, parenteser, tegn i forskjellige koderinger, for å se hvordan applikasjonen fungerer og behandler eksterne data.

Det samme systemet lar oss sjekke mal-sårbarheter i Open Source. Siden DAST ikke vet hvilken Open Source vi bruker, sender det bare «ondsinnede» mønstre og analyserer serverens svar:

— Aha, her er det et deserialiseringsproblem, og her er det ikke.

Det medfører store risikoer, fordi hvis du gjennomfører denne sikkerhetstesten på den samme plattformen som testerne arbeider med—kan det skje ubehagelige ting.

• Høy belastning på nettverksserveren for applikasjonen.
• Ingen integrasjoner.
• Mulighet for å endre innstillingene for den analyserte applikasjonen.
• Ingen støtte for nødvendige teknologier.
• Vanskeligheter med oppsett.

Vi hadde en situasjon der vi endelig startet AppScan: vi fikk i lang tid tilgang til applikasjonen, fikk tre kontoer og ble glade – endelig skulle vi sjekke alt! Vi startet skanningen, og det første AppScan gjorde var å gå inn i administrasjonspanelet, trykke på alle knapper, endre halvparten av dataene, og så drepte den til og med serveren sin. mailform-forespørslene. Utviklingen med testing sa:

– Folkens, er dere seriøse?! Vi ga dere kontoene, og dere la ned testmiljøet!

Vær oppmerksom på mulige risikoer. Ideelt sett bør du forberede et eget miljø for testing av informasjonssikkerhet som er isolert fra resten av omgivelsene, og det anbefales å sjekke administrasjonspanelet i manuell modus. Dette er en pentest – de gjenværende prosentene av innsatsen som vi ikke vurderer nå.

Det er verdt å merke seg at dette kan brukes som en analog til belastningstesting. I den første fasen kan du aktivere en dynamisk skanner med 10-15 tråder og se hva som skjer, men som regel, som praksis viser, er resultatene ikke gode.

Noen ressurser som vi vanligvis bruker.

Det er verdt å fremheve Burp Suite – dette er «sveitsisk armékniv» for enhver sikkerhetsspesialist. Alle bruker det, og det er veldig praktisk. Nå har det kommet en ny demoversjon av enterprise edition. Tidligere var dette bare et stand-alone verktøy med plugins, men nå lager utviklerne endelig en stor server som gjør det mulig å administrere flere agenter. Dette er flott, jeg anbefaler å prøve det.

Integrasjon i prosessen

Integrasjonen skjer ganske bra og enkelt: start skanningen etter vellykket installasjon av applikasjonen på miljøet og skanning etter vellykket gjennomføring av integrasjonstesting..

Hvis integrasjonene ikke fungerer eller det er dummy-funksjoner og mock-funksjoner, er det meningsløst og nytteløst – uansett hvilket mønster vi sender, vil serveren svare likt.

• Ideelt sett – et eget miljø for testing.
• Før testingen, skriv ned innloggingssekvensen.
• Testing av administrasjonssystemet – bare manuelt.

Prosessen

Litt generelt om prosessen generelt og om arbeidet til hvert enkelt verktøy. Alle applikasjoner er forskjellige – én fungerer bedre med dynamisk analyse, en annen med statisk, en tredje med OpenSource-analyse, pentester eller noe helt annet, for eksempel hendelser med Waf.

Hver prosess trenger kontroll.

For å forstå hvordan prosessen fungerer og hvor den kan forbedres, må man samle inn metrikker fra alt man har tilgang til, inkludert produksjonsmetrikker, metrikker fra verktøy og fra feilsporere.

Alle data er nyttige. Man må se på forskjellige perspektiver for å forstå hvor et verktøy er best anvendt, og hvor prosessen spesifikt svikter. Kanskje man bør se på utviklernes responstid for å finne ut hvor forbedringer kan gjøres basert på tid. Jo flere data man har, jo flere perspektiver kan man bygge fra overordnede til detaljerte prosessnivåer.

Siden alle statiske og dynamiske analyseverktøy har sine egne API-er, måter å kjøre på, prinsipper, noen har planleggere, andre har ikke – vi utvikler et verktøy AppSec Orkestrator, som gir en enkelt tilgangspunkt til hele prosessen fra produktet og lar deg styre det fra ett punkt.

For ledere, utviklere og sikkerhetsingeniører er det ett tilgangspunkt hvor man kan se hva som er igangsatt, konfigurere og starte skanning, få resultatene fra skanningen og stille krav. Vi prøver å unngå papirer og oversette alt til et menneskelig format som er i bruk av utviklere – sider på Confluence med status og metrikker, feil i Jira eller forskjellige feilsporere, eller integrere i synkron / asynkron prosess i CI/CD.

Hovedpunkter

Verktøyene er ikke det viktigste. Først må man tenke gjennom prosessen – deretter implementere verktøy. Verktøyene er gode, men dyre, så man kan begynne med prosessen og etablere samarbeid og forståelse mellom utvikling og sikkerhet. Fra et sikkerhetssynspunkt – man må ikke "stoppe" alt som kommer forbi, fra et utviklingssynspunkt – hvis noe er high mega super kritisk, må det utbedres i stedet for å lukke øynene for problemet.

Produktkvalitet – et felles mål for både sikkerhet og utvikling. Vi gjør det samme, prøver å sikre at alt fungerer riktig og at det ikke er noen omdømmerisikoer eller økonomiske tap. Derfor fremmer vi tilnærmingen til DevSecOps, SecDevOps, for å etablere kommunikasjon og gjøre produktet bedre.

Begynn med det som allerede finnes.: krav, arkitektur, delvise kontroller, treninger, retningslinjer. Du trenger ikke å implementere alle praksiser på alle prosjekter med én gang — gå iterativt. Det finnes ingen enhetlig standard — eksperimenter og prøv ulike tilnærminger og løsninger.

Mellom sikkerhetsfeil og funksjonalitetsfeil er det likhetstegn.

Automatiser alt, som beveger seg. Alt som ikke beveger seg — beveg det og automatiser det. Hvis noe gjøres manuelt, er ikke det en god del av prosessen. Det kan være lurt å revurdere det og også automatisere.

Hvis størrelsen på sikkerhetsteamet er liten — bruk Security Champions.

Kanskje det jeg har snakket om ikke passer for deg, og du finner på noe eget — og det er bra. Men velg verktøy basert på kravene til din egen prosess. Ikke se på hva communityen sier, at dette verktøyet er dårlig, og dette er bra. Kanskje alt viser seg å være motsatt for ditt produkt.

Krav til verktøyene.

• Lavt nivå av falske positiver.
• Rimelig analysetid.
• Brukervennlighet.
• Tilgjengelighet av integrasjoner.
• Forståelse av produktets utviklingsroadmap.
• Mulighet for tilpasning av verktøyene.

Yuris presentasjon ble valgt som en av de beste på DevOpsConf 2018. For å bli kjent med enda flere interessante ideer og praktiske saker, kom til Skolkovo 27. og 28. mai på DevOpsConf som en del av RIT++ festivalen. Og enda bedre, hvis du er villig til å dele din erfaring, så send inn en søknad til presentasjonen innen 21. april.

Kilde: habr.com