Slik forbereder du deg til en penetrasjonstest: Komplett sjekkliste
Du har bestilt en penetrasjonstest — flott beslutning. Men hva må egentlig være på plass fra din side før testingen starter? God forberedelse er forskjellen mellom en test som avdekker reelle sårbarheter og en som bruker mesteparten av tiden på å kartlegge miljøet.
I denne guiden går vi gjennom alt du bør ha klart, fra det helt nødvendige til det som gjør testen ekstra verdifull. Bruk den som en sjekkliste i ukene før oppdraget starter.
Det viktigste du trenger er et testmiljø. Penetrasjonstesting bør aldri gjøres direkte mot produksjon. Testmiljøet bør speile produksjonsmiljøet så nøyaktig som mulig — samme kodebase, samme konfigurasjoner, samme integrasjoner. Forskjellene bør bare være at testdata brukes i stedet for reelle kundedata, og at miljøet er isolert slik at testing ikke påvirker ekte brukere.
Hvorfor er dette så viktig? Penetrasjonstesting involverer aktiv testing som kan påvirke ytelse, utløse sikkerhetssperrer eller i verste fall forårsake nedetid. I et isolert testmiljø kan testerne jobbe fritt uten å bekymre seg for konsekvenser for faktiske brukere eller data.
Hvis du ikke har et dedikert testmiljø, snakk med oss om det tidlig. Vi kan hjelpe deg med å definere minimumskravene for et tilstrekkelig testmiljø basert på din infrastruktur.
Du trenger en teknisk kontaktperson som er tilgjengelig under testperioden. Denne personen trenger ikke å sitte klar hele tiden, men bør kunne svare på spørsmål innen rimelig tid — gjerne samme dag. Typiske ting testerne kan trenge hjelp med er tilbakestilling av testkontoer som har blitt låst, avklaring av om en funksjon er tilsiktet eller en feil, og tilgang til logger for å verifisere funn.
Idealelt sett bør kontaktpersonen ha god kjennskap til applikasjonens arkitektur og forretningslogikk. En utvikler eller teknisk leder er ofte best egnet.
For autentisert testing — som er det vanligste — trenger testerne testbrukere med ulike roller. Har applikasjonen din for eksempel vanlige brukere, administratorer og super-administratorer, bør det opprettes testkontoer for hver rolle. Dette lar testerne verifisere at tilgangskontrollene faktisk fungerer og at en vanlig bruker ikke kan eskalere sine rettigheter.
Opprett dedikerte testkontoer for penetrasjonstestingen — ikke gjenbruk eksisterende kontoer. Bruk testdata, ikke ekte personopplysninger. Sørg for at kontoene har tilgang til alle funksjoner som den aktuelle rollen normalt har tilgang til.
Det er viktig å definere et klart scope sammen med leverandøren. Hva skal testes, og minst like viktig — hva skal ikke testes? Scope bør inkludere hvilke applikasjoner og URL-er som er inkludert, hvilke funksjoner og moduler som skal fokuseres på, om tredjepartsintegrasjoner er inkludert eller ekskludert, og om det finnes funksjoner som er spesielt kritiske.
Et godt definert scope beskytter begge parter. Testerne vet nøyaktig hva de skal fokusere på, og du unngår overraskelser.
Testvinduet — perioden testing skal gjennomføres i — må avtales og kommuniseres internt. Sørg for at relevante team vet at testing pågår. IT-drift bør vite slik at de ikke blokkerer testtrafikk eller tolker det som et angrep. Utviklingsteamet bør unngå å pushe store endringer til testmiljøet under testperioden, da dette kan påvirke resultatene.
Ta en gjennomgang av loggingen i testmiljøet. Testerne kan trenge tilgang til applikasjonslogger, webserverlogger eller WAF-logger for å verifisere funn. Sørg for at relevant logging er aktivert og at loggene er tilgjengelige for kontaktpersonen.
Dokumentasjon gjør testen mer effektiv. Du trenger ikke levere en komplett arkitekturbeskrivelse, men følgende er nyttig: en overordnet beskrivelse av applikasjonen og dens formål, informasjon om teknologi-stacken (rammeverk, database, autentiseringsmekanisme), API-dokumentasjon hvis API-er er del av scopet, og eventuelle kjente begrensninger eller områder du er spesielt bekymret for.
Hos Awareness Security starter vi alltid med en strukturert onboarding gjennom vår Human-in-Control-prosess. I Gate 0 definerer vi scope sammen, du signerer autorisasjon digitalt, og testvinduet godkjennes. Dette sikrer at alt er på plass og at begge parter er enige om rammene før en eneste test kjøres.
Noe mange glemmer er å avklare juridiske og kontraktsmessige forhold. Sørg for at du har autorisasjon til å teste. Hvis applikasjonen hoster data for andre organisasjoner, eller hvis den kjører på en tredjepartplattform, kan det kreves tillatelse fra flere parter. Avklar dette i god tid.
Sjekk om din organisasjon har forsikringer som dekker sikkerhetstesting, og at leverandøren har ansvarsforsikring. Hos Awareness Security har vi profesjonell ansvarsforsikring og tar fullt ansvar for eventuelle skader under autorisert testing.
Her er en rask sjekkliste du kan bruke:
Nødvendig: Testmiljø adskilt fra produksjon. Testbrukere med relevante roller. Klart definert scope. Avtalt testvindu. Teknisk kontaktperson. Signert autorisasjon.
Anbefalt: API-dokumentasjon. Overordnet arkitekturbeskrivelse. Aktivert logging i testmiljøet. Intern kommunikasjon til IT-drift og utviklingsteam. Avklarte juridiske forhold.
Nice-to-have: Kjente bekymringsområder eller nylige endringer. Tidligere testrapporter. Informasjon om security headers og WAF-konfigurasjon.
Med god forberedelse sikrer du at testerne bruker tiden sin på å finne reelle sårbarheter — ikke på å vente på tilganger eller feilsøke testmiljøet. Det gir deg en bedre rapport, mer verdi for pengene, og konkrete tiltak du kan handle på.
Klar for å komme i gang? Ta kontakt med oss for en uforpliktende samtale om dine behov, så hjelper vi deg gjennom hele prosessen.