Gå til hovedinnhold
BilgeQor

Sikkerhetstjenester

Penetrasjonstest vs sårbarhetsskanning: viktige forskjeller

5 min lesing

Innkjøpere hører ofte «penetrasjonstest» og «sårbarhetsskanning» brukt som om de betydde det samme. Det gjør de ikke. En sårbarhetsskanning er en automatisert kontroll som sammenligner systemer med en database over kjente svakheter. En penetrasjonstest er en avgrenset, menneskeledet øvelse der en tester undersøker om svakheter faktisk kan utnyttes mot et avtalt mål, og dokumenterer bevisene. Begge er nyttige. Riktig valg avhenger av hvilket spørsmål dere trenger svar på, hvor modent miljøet er, og hvem som skal lese resultatene.

Hva det er

En sårbarhetsskanning kjører et verktøy mot verter, nettsteder eller applikasjoner og rapporterer problemer det kan gjenkjenne: manglende oppdateringer, utdaterte programvareversjoner, eksponerte tjenester, svake TLS-innstillinger eller vanlige feilkonfigurasjoner. Skanninger er raske og kan gjentas, noe som gjør dem godt egnet for løpende sikkerhetshygiene. Begrensningene er velkjente. Skannere gir falske positiver, overser problemer som avhenger av forretningslogikk, og kan ikke si om et lavt rangert funn blir alvorlig i kombinasjon med et annet. En penetrasjonstest tar utgangspunkt i et skriftlig omfang og avtalte testregler. Testeren bruker verktøy, også skannere, men arbeider deretter manuelt: validerer funn, tester autentisering og autorisasjon, kontrollerer hvordan roller og leietakere er adskilt, og følger realistiske veier en angriper kunne forsøke. Resultatet er en rapport med bevis, alvorlighetsgrad og veiledning om utbedring, ikke en rå liste med verktøyutdata. Kort sagt: en skanning forteller hva som kan være galt; en penetrasjonstest forteller hva som påviselig er galt innenfor det avtalte omfanget, og hvorfor det betyr noe.

Hvem det er for

Denne sammenligningen er nyttig for team som:

  • Har fått en forespørsel fra en kunde, partner eller et forsikringsselskap om «sikkerhetstesting» og må forstå hva det faktisk spørres om
  • Allerede kjører regelmessige skanninger og vil vite om en manuell test vil gi meningsfull innsikt
  • Lanserer en ny nettapplikasjon, et API eller en mobilapp og må avgjøre hvor grundig testingen før lansering bør være
  • Må forklare ledelsen hvorfor to tilbud på «testing» ser svært forskjellige ut i innsats og resultat

Hva det hjelper med å klarlegge

Når de to leses side om side, blir det tydeligere:

  • Om spørsmålet gjelder hygiene rundt kjente problemer (skanning) eller utnyttbar risiko i et bestemt system (penetrasjonstest)
  • Hvilke funn i en eksisterende skannerapport som trolig er støy, og hvilke som fortjener manuell validering
  • Hvordan forretningslogikk, tilgangskontroll og angrepsveier i flere trinn ligger utenfor det automatiserte verktøy vanligvis oppdager
  • Hvilke bevis en interessent vil forvente å se i en sluttrapport

Hva er inkludert

  • Sjekkliste for skanning: definer listen over eiendeler, planlegg regelmessige skanninger, utpek en eier som vurderer resultatene, og følg opp utbedringen over tid
  • Sjekkliste for penetrasjonstest: avtal skriftlig mål, miljøer, testvindu, tilgangsmetode, navngitte kontaktpersoner og stoppbetingelser før arbeidet starter
  • Bekreft skriftlig autorisasjon fra systemeieren og fra eventuelle driftsleverandører eller leverandører som drifter systemer innenfor omfanget
  • Avgjør om autentisert testing er nødvendig (testkontoer for hver rolle), slik at problemer med tilgangskontroll kan undersøkes
  • Avtal hvordan funn skal graderes, og hvordan bevis skal deles sikkert med navngitte kontaktpersoner
  • Planlegg et vindu for ny test, slik at utbedrede funn kan bekreftes etter utbedring

Hva er ikke inkludert

  • En påstand om at en skanning alene viser at en applikasjon er sikker
  • En påstand om at en penetrasjonstest finner alle svakheter; den undersøker et avtalt omfang innenfor en avtalt tid
  • Instruksjoner for utnyttelse eller testing av systemer dere ikke eier eller ikke har tillatelse til å teste
  • Sertifisering, godkjenning av etterlevelse eller en formell revisjonsuttalelse

Når skal den velges

Velg skanning når dere trenger regelmessig, bred oversikt over mange eiendeler og har en prosess for å vurdere og rette det som rapporteres. Velg en penetrasjonstest når et bestemt system er viktig for virksomheten, når en kunde eller partner ber om bevis på manuell testing, før en betydelig lansering eller etter store endringer i autentisering, betalinger eller datahåndtering. Mange organisasjoner bruker begge: planlagte skanninger for å holde hygienen stabil og en periodisk penetrasjonstest for å undersøke systemene med høyest risiko. Hvis dere ennå ikke kan liste opp eiendeler eller eiere, kan en bredere baseline-gjennomgang være et mer nyttig første steg enn noen av dem.

Vår tilnærming

Start med beslutningen dere må ta. Hvis et kundespørreskjema ber om en årlig penetrasjonstest, vil en skannerapport vanligvis ikke være tilstrekkelig. Hvis dere bare trenger å vite om internetteksponerte servere er oppdatert, kan en full manuell test være mer enn dere trenger. Bekreft deretter omfanget: hvilke applikasjoner, API-er, miljøer og brukerroller som er inkludert, og hvilke som er uttrykkelig utelatt. Avtal testvinduet og hvem som kan sette arbeidet på pause. Tjenesten vår Penetration Testing følger dette mønsteret: omfang, skriftlig autorisasjon, testing innenfor de avtalte testreglene, en skriftlig rapport med funn og prioritert veiledning om utbedring, en gjennomgang av resultatene og, der det er inkludert, ny test av avtalte funn. Uansett hvilken leverandør dere bruker, be om å få se en eksempelrapport før dere forplikter dere, og kontroller at den skiller validerte funn fra informative observasjoner. Sett til slutt av tid til utbedring. En test som gir funn ingen har tid til å rette, tilfører lite verdi, så tilpass testdatoen til teamets kapasitet til å følge opp resultatene.

Penetration Testing

Se tjenestesiden for Penetration Testing

Ofte stilte spørsmål

Beslektede artikler

Kom i gang

Vil dere ha hjelp til å velge mellom en skanning og en penetrasjonstest?

Fortell oss hvilke systemer det gjelder, hvem som ber om testing, og hvilken beslutning dere må ta. Vi hjelper dere med å definere et forholdsmessig omfang.

Be om et skriftlig omfang