Som en del av deres profesjonelle aktiviteter må utviklere, pentestere og sikkerhetseksperter håndtere prosesser som Vulnerability Management (VM), (Secure) SDLC.
Under disse frasene er forskjellige sett med praksis og verktøy som brukes som er sammenvevd, selv om brukerne deres er forskjellige.
Den teknologiske utviklingen har ennå ikke nådd det punktet hvor ett verktøy kan erstatte en person for å analysere sikkerheten til infrastruktur og programvare.
Det er interessant å forstå hvorfor det er slik, og hvilke problemer man må møte.
prosesser
Sårbarhetsadministrasjonsprosessen er designet for å kontinuerlig overvåke infrastruktursikkerhet og patchadministrasjon.
Secure SDLC-prosessen ("sikker utviklingssyklus") er designet for å opprettholde applikasjonssikkerhet under utvikling og drift.
En lignende del av disse prosessene er Vulnerability Assessment-prosessen – sårbarhetsvurdering, sårbarhetsskanning.
Hovedforskjellen mellom skanning innenfor VM og SDLC er at i det første tilfellet er målet å finne kjente sårbarheter i tredjepartsprogramvare eller i en konfigurasjon. For eksempel en utdatert versjon av Windows eller standard fellesskapsstreng for SNMP.
I det andre tilfellet er målet å oppdage sårbarheter ikke bare i tredjepartskomponenter (avhengigheter), men først og fremst i koden til det nye produktet.
Dette gir opphav til forskjeller i verktøy og tilnærminger. Etter min mening er oppgaven med å finne nye sårbarheter i en applikasjon mye mer interessant, siden det ikke kommer ned til versjonsfingeravtrykk, bannerinnsamling, passord brute force, etc.
Automatisk skanning av høy kvalitet av applikasjonssårbarheter krever algoritmer som tar hensyn til applikasjonens semantikk, dens formål og spesifikke trusler.
Infrastrukturskanneren kan ofte erstattes med en timer, som . Poenget er at rent statistisk kan du vurdere infrastrukturen din som sårbar hvis du ikke har oppdatert den på for eksempel en måned.
Verktøy
Skanning, samt sikkerhetsanalyse, kan utføres som en svart boks eller en hvit boks.
Black Box
Med blackbox-skanning må verktøyet kunne jobbe med tjenesten gjennom de samme grensesnittene som brukere arbeider med den.
Infrastrukturskannere (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, etc.) leter etter åpne nettverksporter, samler inn «bannere», identifiserer installerte programvareversjoner og søker i kunnskapsbasen deres etter informasjon om sårbarheter i disse versjonene. De prøver også å oppdage konfigurasjonsfeil som standard passord eller offentlig tilgang til data, svake SSL-chiffer osv.
Nettapplikasjonsskannere (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, etc.) kan også oppdage kjente komponenter og deres versjoner (f.eks. CMS, rammeverk, JS-biblioteker). De viktigste krypningstrinnene er krypning og fuzzing.
Under gjennomsøking samler søkeroboten inn informasjon om eksisterende applikasjonsgrensesnitt og HTTP-parametere. Under fuzzing blir alle oppdagede parametere erstattet med muterte eller genererte data for å provosere frem en feil og oppdage en sårbarhet.
Slike applikasjonsskannere tilhører DAST- og IAST-klassene - henholdsvis Dynamic og Interactive Application Security Testing.
white Box
Med whitebox-skanning er det flere forskjeller.
Som en del av VM-prosessen får skannere (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, etc.) ofte tilgang til systemer ved å utføre en autentisert skanning. Dermed kan skanneren laste ned installerte pakkeversjoner og konfigurasjonsparametere direkte fra systemet, uten å gjette dem fra nettverkstjenestebannere.
Skanningen er mer nøyaktig og fullstendig.
Hvis vi snakker om whitebox-skanning (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, etc.) av applikasjoner, så snakker vi vanligvis om statisk kodeanalyse og bruk av de tilsvarende SAST-klasseverktøyene - Static Application Security Testing.
Problemer
Det er mange problemer med skanning! Jeg må forholde meg til de fleste personlig som en del av levering av en tjeneste for bygging av skanning og sikre utviklingsprosesser, samt når jeg utfører sikkerhetsanalysearbeid.
Jeg vil trekke frem 3 hovedgrupper av problemer, som også bekreftes av samtaler med ingeniører og ledere for informasjonssikkerhetstjenester i ulike virksomheter.
Problemer med skanning av nettapplikasjoner
- Vanskeligheter med gjennomføring. Skannere må distribueres, konfigureres, tilpasses for hver applikasjon, tildeles et testmiljø for skanninger og implementeres i CI/CD-prosessen for å være effektive. Ellers vil det være en ubrukelig formell prosedyre, som bare gir ut falske positiver
- Skanningsvarighet. Skannere, selv i 2019, gjør en dårlig jobb med å deduplisere grensesnitt og kan skanne tusen sider med 10 parametere hver i dager, med tanke på at de er forskjellige, selv om den samme koden er ansvarlig for dem. Samtidig må beslutningen om å distribuere til produksjon innenfor utviklingssyklusen tas raskt.
- Dårlige anbefalinger. Skannere gir ganske generelle anbefalinger, og det er ikke alltid mulig for en utvikler å raskt forstå fra dem hvordan man kan redusere risikonivået, og viktigst av alt, om det må gjøres akkurat nå, eller det ikke er skummelt ennå
- Destruktiv innvirkning på applikasjonen. Skannere kan enkelt utføre et DoS-angrep på en applikasjon, og de kan også opprette et stort antall enheter eller endre eksisterende (for eksempel lage titusenvis av kommentarer på en blogg), så du bør ikke tankeløst kjøre en skanning i en produkt.
- Dårlig kvalitet på sårbarhetsdeteksjon. Skannere bruker vanligvis en fast rekke nyttelaster og kan lett gå glipp av en sårbarhet som ikke passer inn i deres kjente applikasjonsatferd.
- Skanneren forstår ikke funksjonene til programmet. Skannere selv vet ikke hva en "internettbank", "betaling", "kommentar" er. For dem er det bare koblinger og parametere, så et stort lag av mulige forretningslogikksårbarheter forblir fullstendig avdekket, de vil ikke gjette på å foreta en dobbel avskrivning, kikke på andres data etter ID eller avvikle balansen gjennom avrunding
- Misforståelse av sidesemantikk av skanneren. Skannere kan ikke lese FAQ, kan ikke gjenkjenne captchaer, de vil ikke selv gjette hvordan de registrerer seg og deretter logger inn på nytt, at du ikke kan klikke på "logg ut", og hvordan du signerer forespørsler når du endrer parameterverdier. Som et resultat kan det meste av applikasjonen forbli uskannet i det hele tatt.
Problemer med kildekodeskanning
- Falske positive. Statisk analyse er en kompleks oppgave som involverer mange kompromisser. Ofte må du ofre nøyaktighet, og til og med dyre bedriftsskannere gir ut et stort antall falske positiver.
- Vanskeligheter med gjennomføring. For å øke nøyaktigheten og fullstendigheten til statisk analyse, er det nødvendig å avgrense skannereglene, og å skrive disse reglene kan være for tidkrevende. Noen ganger er det lettere å finne alle stedene i koden med en slags feil og fikse dem enn å skrive en regel for å oppdage slike tilfeller.
- Mangel på avhengighetsstøtte. Store prosjekter er avhengige av et stort antall biblioteker og rammeverk som utvider funksjonaliteten til programmeringsspråket. Hvis det ikke finnes informasjon om farlige steder ("synker") i disse rammeverkene i kunnskapsbasen til skanneren, vil dette bli en blindsone, og skanneren vil rett og slett ikke engang forstå koden.
- Skanningsvarighet. Å finne sårbarheter i kode er også en vanskelig oppgave når det gjelder algoritmer. Derfor kan prosessen godt bli forsinket og kreve betydelige dataressurser.
- Lav dekning. Til tross for ressursforbruk og skanningsvarighet, må utviklere av SAST-verktøy fortsatt ty til kompromisser og analysere ikke alle tilstander et program kan være i.
- Finne reproduserbarhet. Å peke på den spesifikke linjen og anropsstakken som fører til en sårbarhet er flott, men faktisk gir skanneren ofte ikke nok informasjon til å se etter en ekstern sårbarhet. Tross alt kan feilen også ligge i den døde koden, som er uoppnåelig for angriperen.
Problemer med infrastrukturskanning
- Utilstrekkelig inventar. I store infrastrukturer, spesielt geografisk adskilte, er det ofte det vanskeligste å finne ut hvilke verter som skal skannes. Oppgaven med skanning er med andre ord nært knyttet til oppgaven med forvaltning av kapital
- Dårlig prioritering. Nettverksskannere gir ofte mange resultater med feil som ikke kan utnyttes i praksis, men formelt sett er risikonivået høyt. Forbrukeren får en rapport som er vanskelig å tolke, og det er ikke klart hva som må rettes først
- Dårlige anbefalinger. Skannerens kunnskapsbase inneholder ofte bare veldig generell informasjon om sårbarheten og hvordan de kan fikse den, så administratorer må bevæpne seg med Google. Situasjonen er litt bedre med whitebox-skannere, som kan gi en spesifikk kommando for å fikse
- Håndlaget. Infrastrukturer kan ha mange noder, noe som betyr at det er potensielt mange feil, rapporter som må analyseres og analyseres manuelt ved hver iterasjon
- Dårlig dekning. Kvaliteten på infrastrukturskanning avhenger direkte av størrelsen på kunnskapsbasen om sårbarheter og programvareversjoner. hvori, , selv markedslederne har ikke en omfattende kunnskapsbase, og det er mye informasjon i databasene med gratisløsninger som lederne ikke har.
- Problemer med patching. Oftest er oppdatering av infrastruktursårbarheter å oppdatere en pakke eller endre en konfigurasjonsfil. Det store problemet her er at systemet, spesielt det eldre, kan oppføre seg uforutsigbart som følge av en oppdatering. Faktisk må du gjennomføre integrasjonstester på en levende infrastruktur i produksjon.
Tilnærminger
Hvordan kan det ha seg?
Jeg vil gå mer i detalj om eksempler og hvordan du skal håndtere mange av disse problemene i de følgende delene, men foreløpig vil jeg angi hovedområdene du kan jobbe med:
- Aggregering av ulike skanneverktøy. Med riktig bruk av flere skannere kan en betydelig økning i kunnskapsbasen og kvaliteten på deteksjonen oppnås. Du kan finne enda flere sårbarheter enn summen av alle skannere som kjøres individuelt, samtidig som du kan vurdere risikonivået mer nøyaktig og gi flere anbefalinger
- SAST og DAST integrasjon. Det er mulig å øke DAST-dekningen og SAST-nøyaktigheten ved å dele informasjon mellom dem. Fra kilden kan du få informasjon om eksisterende ruter, og ved hjelp av DAST kan du sjekke om sårbarheten er synlig fra utsiden
- Machine Learning™. I 2015 (og ) om å bruke statistikk for å gi skannere en hackers intuisjon og få fart på dem. Dette er definitivt mat for utviklingen av automatisert sikkerhetsanalyse i fremtiden.
- IAST-integrasjon med autotester og OpenAPI. Innenfor CI/CD-pipelinen er det mulig å lage en skanneprosess basert på verktøy som fungerer som HTTP-proxyer og funksjonstester som fungerer over HTTP. OpenAPI/Swagger-tester og kontrakter vil gi skanneren den manglende informasjonen om datastrømmer, gjøre det mulig å skanne applikasjonen i forskjellige tilstander
- Riktig konfigurasjon. For hver applikasjon og infrastruktur må du opprette en passende skanneprofil, som tar hensyn til antallet og arten av grensesnitt, teknologiene som brukes
- Skannertilpasning. Ofte kan en applikasjon ikke skannes uten å endre skanneren. Et eksempel er en betalingsgateway hvor hver forespørsel må signeres. Uten å skrive en kobling til gatewayprotokollen, vil skannere tankeløst hakke på forespørsler med feil signatur. Det er også nødvendig å skrive spesialiserte skannere for en bestemt type feil, som f.eks
- Risikostyring. Bruk av ulike skannere og integrasjon med eksterne systemer som Asset Management og Threat Management vil gjøre det mulig å bruke flere parametere for å vurdere risikonivået, slik at ledelsen kan få et tilstrekkelig bilde av den nåværende sikkerhetstilstanden til utviklingen eller infrastrukturen.
Følg med og la oss forstyrre sårbarhetsskanningen!
Kilde: www.habr.com