Penetrasjonstest: Slik bestiller du riktig
Å bestille en penetrasjonstest betyr å la en sikkerhetsekspert aktivt prøve å bryte seg inn i systemet ditt, i motsetning til en automatisk sårbarhetsskanning. Testeren bør være uavhengig av utviklingsleverandøren for at gjennomgangen skal bli ærlig. Funnene prioriteres etter alvorlighetsgrad og utbedres etter en fornuftig tidsplan, der de farligste hullene tettes først.
Før eller senere kommer spørsmålet: Er systemet vårt faktisk sikkert? En penetrasjonstest er måten å få et ærlig svar på. I stedet for å gjette lar du en sikkerhetsekspert prøve å bryte seg inn, akkurat som en virkelig angriper ville gjort, og rapportere hva vedkommende fant. Men en test er aldri bedre enn bestillingen. Denne guiden går gjennom hva du faktisk kjøper, hvorfor testeren må være uavhengig, og hvordan du håndterer funnene slik at de gjør nytte.
Sårbarhetsskanning eller skikkelig penetrasjonstest
Det første du må avklare, er hva du egentlig ber om, for to ganske ulike ting kalles noen ganger det samme. Forskjellen er stor nok til å påvirke både pris og verdi.
En sårbarhetsskanning er et automatisk verktøy som går gjennom systemet og sammenligner det med en liste over kjente svakheter. Den er rask, billig og god til å fange det åpenbare: utdaterte komponenter, kjente hull, feil innstillinger. Men den er overfladisk. Den kan ikke tenke, kombinere flere små svakheter til én alvorlig eller forstå logiske feil i hvordan nettopp systemet deres fungerer.
En penetrasjonstest er et menneske. En erfaren tester forsøker aktivt å komme seg inn, prøver ut uventede veier, kjeder sammen svakheter og resonnerer som en angriper med et mål. Testen finner det en skanning aldri ser: at en bruker kan nå en annens data ved å manipulere et kall, eller at flere detaljer som hver for seg er harmløse, til sammen åpner en dør. En vanlig feil er å kjøpe en skanning i den tro at man har fått en pentest. Skanningen har sin plass, men den erstatter ikke en skikkelig gjennomgang.
Hvorfor testeren bør være uavhengig
Et avgjørende spørsmål er hvem som utfører testen. Den fristende snarveien er å la utviklingsleverandøren teste det de selv har bygd. De kjenner jo systemet best. Nettopp derfor er det feil vei å gå.
Ingen er god til å finne feil i sitt eget arbeid. Den som har bygd systemet, går gjennom det med de samme antakelsene og blindsonene som preget utviklingen, og har dessuten en ubevisst interesse av at alt skal se bra ut. En uavhengig tester kommer inn uten noe å forsvare og leter fordomsfritt etter det som ikke fungerer. Uavhengigheten er også det som gjør resultatet troverdig utad. For en kunde, en investor eller en IT-revisor betyr en godkjent test fra en ekstern part noe helt annet enn leverandørens eget ord på at alt er sikkert. Å skille mellom den som bygger og den som tester, er et enkelt prinsipp med stor effekt.
Prioriter og utbedre funnene
En penetrasjonstest ender i en rapport, men rapporten er ikke målet. Målet er at svakhetene blir rettet. En rapport som leses én gang og deretter glemmes, har ikke gjort systemet det minste sikrere. Nøkkelen er å omsette funnene til handling, i riktig rekkefølge.
De fleste rapporter graderer funnene etter alvorlighetsgrad, og den graderingen styrer tempoet:
| Alvorlighetsgrad | Fornuftig håndtering |
|---|---|
| Kritisk | Utbedres umiddelbart, helst før systemet settes i produksjon |
| Høy | Rettes snarest etter en tydelig og kort tidsplan |
| Middels | Planlegges inn i det nærmeste utviklingsarbeidet |
| Lav | Utbedres når anledningen byr seg eller ved neste større innsats |
Poenget er å ikke bli lammet av en lang liste. Noen få kritiske og høyt prioriterte funn er det som virkelig betyr noe, og de skal bort først. Resten kan håndteres metodisk over tid. Når de alvorlige svakhetene er rettet, er det klokt å la testeren verifisere at hullene faktisk er tettet. En rettelse som ikke kontrolleres, er bare et håp om at feilen er borte.
Et konkret scenario
En virksomhet skulle lansere en tjeneste som håndterte personopplysninger og betalinger. Utviklingsleverandøren forsikret om at sikkerheten var i orden, men ledelsen ville ha en uavhengig bekreftelse før tjenesten ble satt i produksjon. De engasjerte en ekstern tester til en penetrasjonstest av applikasjonen, med god margin før lanseringsdatoen.
Testen fant to alvorlige svakheter som en automatisk skanning ville ha oversett, begge i logikken for hvordan brukere fikk tilgang til data. Funnene var ubehagelige, men uvurderlige, for de kunne ha blitt en reell datalekkasje etter lansering. Utvikleren rettet de kritiske hullene, testeren verifiserte rettelsene, og funnene med lavere prioritet ble planlagt inn i det løpende arbeidet. Tjenesten ble lansert med en dokumentert, uavhengig sikkerhetsvurdering i ryggen, verdt langt mer enn det testen kostet.
Bestill testen slik at den gjør nytte
En penetrasjonstest gir mest verdi når du vet hva du kjøper, lar en uavhengig part utføre den og faktisk følger opp funnene. Kjøp en skikkelig test snarere enn bare en skanning der det trengs, hold testeren adskilt fra utvikleren, og prioriter tiltakene etter alvorlighetsgrad. Da blir testen ikke et papirprodukt, men et reelt løft for sikkerheten.
Vi i Weapp utvikler med sikkerhet i tankene og ønsker uavhengig gjennomgang av det vi leverer velkommen, som en naturlig del av tjenestene våre. Nærmer lanseringen seg, og vil dere vite at systemet holder? Ta kontakt, så drøfter vi hvordan en test best legges opp for akkurat deres tjeneste.
Ofte stilte spørsmål
Hva er forskjellen på en sårbarhetsskanning og en penetrasjonstest?
En sårbarhetsskanning er et automatisk verktøy som leter etter kjente svakheter og produserer en liste. En penetrasjonstest er et menneske som aktivt prøver å komme seg inn, kombinerer svakheter og tenker som en angriper. Skanningen er bred og billig, men overfladisk. Testen går dypere og finner det verktøy overser, for eksempel logiske feil i hvordan systemet er bygd.
Hvorfor bør testeren være uavhengig av utviklingsleverandøren?
Fordi ingen er best til å finne feil i sitt eget arbeid. Lar man den som har bygd systemet, også teste det, blir koden gjennomgått av de samme øynene som skrev den, med de samme blindsonene. En uavhengig tester har ingenting å forsvare og leter fordomsfritt etter svakheter. Uavhengigheten er det som gjør resultatet troverdig, både for dere selv og for kunder eller IT-revisorer.
Når i prosjektet bør en penetrasjonstest gjøres?
Som regel før lansering, når systemet er ferdig nok til å gjenspeile hvordan det skal kjøres i produksjon, men med margin til å utbedre funnene før produksjonssetting. For tjenester som håndterer sensitive opplysninger, bør testen gjentas jevnlig fordi både systemet og trusselbildet endrer seg. En test er et øyeblikksbilde. Den sier noe om sikkerheten akkurat da, ikke for all fremtid.
Hva gjør man med rapporten fra en penetrasjonstest?
Man prioriterer og utbedrer. Rapporten graderer vanligvis funnene etter alvorlighetsgrad, fra kritiske til mindre. De alvorligste hullene skal tettes raskt, gjerne før lansering, mens funn med lavere prioritet kan planlegges inn over tid. Poenget med testen er ikke rapporten i seg selv, men at svakhetene faktisk blir rettet. En rapport som legges i en skuff, har ikke gjort systemet det minste sikrere.
Hva koster en penetrasjonstest?
Det avhenger av hvor omfattende systemet er og hvor dypt testen skal gå. En avgrenset webapplikasjon er et mindre oppdrag enn en hel plattform med mange deler. Prisen settes som regel ut fra tiden testen krever. For et system som håndterer sensitive opplysninger eller betalinger, er kostnaden liten sammenlignet med hva et reelt innbrudd ville kostet i penger og tillit.