En god bestilling av penetrasjonstest beskriver hva som skal undersøkes, hvilke handlinger som er tillatt og hvordan funn skal følges opp. Uten en tydelig avgrensning kan rapporten bli vanskelig å bruke, eller undersøkelsen påvirke systemer som ikke var ment å inngå. Begynn derfor med sikkerhetsspørsmålene dere trenger svar på og de tjenestene dere faktisk har myndighet til å teste.
NIST SP 800-115, publisert i 2008, gir et metodisk grunnlag for planlegging, tekniske undersøkelser og oppfølging. Det er ikke en oppdatert katalog over alle sårbarheter eller en norsk regel om fast testfrekvens. Artikkel 32 i GDPR krever blant annet regelmessig prøving og vurdering av relevante sikkerhetstiltaks effektivitet, tilpasset risikoen. Hvilken undersøkelse virksomheten trenger, må vurderes konkret.
Formuler spørsmålet testen skal besvare
Beskriv om dere vil undersøke offentlig eksponering, tilgang mellom roller, en ny applikasjon eller en bestemt endring. Et generelt mål om å teste hele sikkerheten blir ofte for vidt. Velg spørsmål som kan undersøkes og besvares innenfor et kjent omfang, og avklar hva resultatet ikke vil si noe om.
Skill penetrasjonstest fra automatisk sårbarhetsskanning og dokumentgjennomgang. Metodene kan støtte hverandre, men undersøker forskjellige forhold og gir forskjellige begrensninger. Be leverandøren forklare hvilke deler som utføres manuelt, hvilke som bruker verktøy og hvordan faktiske konsekvenser verifiseres uten unødvendig påvirkning.
Kartlegg systemer, eiere og avhengigheter
Bruk systemoversikten til å identifisere miljøer, integrasjoner og ansvarlige parter. Et domenenavn kan peke til infrastruktur som drives av andre. En applikasjon kan bruke betalingsløsning, identitet og eksterne tjenester som ikke automatisk omfattes av kundens fullmakt.
Avklar tillatelse for alle relevante deler før gjennomføring. Registrer hvilke miljøer som er kundeeide, hvilke som er delt med andre og hvilke leverandørvilkår som må følges. Endring i teknisk adresse eller driftspartner kan gjøre en tidligere avgrensning utdatert. Bestillingen må beskrive den faktiske situasjonen på testtidspunktet.
Velg kunnskapsnivå og tilgang bevisst
En undersøkelse kan gjennomføres med ulik informasjon og tilgang til systemet. Avklar om testeren får dokumentasjon, kildekode, brukerkontoer eller administratorinnsikt. Valget bør følge spørsmålet dere vil besvare. Lite forhåndsinformasjon er ikke automatisk mer realistisk eller mer nyttig for alle typer svakheter.
Hvis tilgang mellom brukerroller er viktig, trenger testeren gjerne kontrollerte kontoer som representerer disse rollene. Beskriv hvilke handlinger hver konto skal kunne utføre og hvilket innhold som kan brukes. Kontoene bør ha eier, begrenset levetid og et tydelig avslutningspunkt, slik at testtilgangen ikke blir stående etter oppdraget.
Avtal regler for gjennomføring og stans
Bestem tidsrom, kontaktpunkter, tillatte metoder og handlinger som krever særskilt avklaring. Angi hvem som kan stanse undersøkelsen og hvordan testeren når driftsansvarlig. Vurder påvirkning på tilgjengelighet, dataintegritet og andre kunder i delte miljøer. Fullmakten bør være forståelig for både oppdragsgiver og dem som utfører arbeidet.
Avklar hva som skjer hvis testeren finner en kritisk svakhet, oppdager en pågående hendelse eller når utenfor avtalt omfang. En rapport levert ved slutten av oppdraget kan være for sent for et alvorlig funn. Beskriv derfor en kanal for rask varsling med nødvendig informasjon og begrenset deling.
Utfylt eksempel på et avgrenset oppdrag
| Punkt | Eksempel for en tenkt kundeportal |
|---|---|
| Mål | Undersøke om vanlige kunder kan få tilgang til andre kunders saker |
| Miljø | Avtalt testmiljø med samme relevante tilgangslogikk som produksjon |
| Tilgang | To kontrollerte kundekontoer og én avgrenset saksbehandlerkonto |
| Data | Syntetiske saker og dokumenter som er laget for undersøkelsen |
| Tillatt arbeid | Avtalte kontroller av applikasjonens funksjoner og tilgangsgrenser |
| Utenfor omfang | Belastningsangrep, sosial manipulering og andre leverandørers systemer |
| Stans | Navngitt driftsrolle kan stoppe arbeidet ved uventet påvirkning |
| Leveranse | Reproduserbart funn, konsekvens, anbefalt retting og kontroll etter retting |
Eksemplet er et bestillingsutkast, ikke en fullmakt til å teste en virkelig tjeneste. Den faktiske avtalen må identifisere systemene og tillatelsene presist. Hvis testmiljøet avviker fra produksjon, må rapporten forklare hvilken betydning forskjellen har for konklusjonene.
Begrens personopplysninger i undersøkelsen
Bruk syntetiske eller andre egnede kontrolldata der de kan besvare spørsmålet. Hvis reelle opplysninger er nødvendige, må behov, tilgang, rolle og sikker håndtering vurderes konkret. En sårbarhet kan ofte dokumenteres uten å hente ut store datamengder. Bestillingen bør definere hvordan testeren begrenser bevisinnsamlingen.
Knytt dette til dataminimering. Avklar også arbeidskopier, skjermbilder, logger og rapportvedlegg. En rapport med detaljer om faktiske personer kan ha et større delingsbehov og høyere risiko enn nødvendig. Beskriv sikker overføring og håndtering ved avslutning av oppdraget.
Be om funn som kan brukes til retting
Et funn bør angi hvilket system og hvilken funksjon som er berørt, hvilke forutsetninger som kreves og hvilken konsekvens som er dokumentert. Beskriv forskjellen mellom en bekreftet svakhet og en mulig risiko som ikke er fullt undersøkt. Prioriteringen bør ha en forståelig begrunnelse knyttet til virksomhetens situasjon.
Be om tilstrekkelige reproduksjonsopplysninger for autoriserte utviklere, men begrens hvem som får tilgang til detaljene. Ledelsen kan trenge en oppsummering av konsekvens og tiltak uten alle tekniske fremgangsmåter. Rapporteringsformatet bør gjøre det mulig å fordele arbeid og bekrefte lukking uten at funnet må tolkes på nytt av hver mottaker.
Knytt funnene til eksisterende sikkerhetsarbeid
Sammenhold rapporten med grunnleggende IT-sikkerhet. Hvis testen finner gamle kontoer, manglende oppdateringer eller svake driftsrutiner, kan årsaken være en prosess som berører flere systemer. Rettingen bør derfor omfatte både det konkrete funnet og en vurdering av lignende svakheter andre steder.
Bruk herdingsprofilen og sikkerhetsvedlegget til å oppdatere måltilstanden der det er relevant. En enkelt kodeendring løser ikke nødvendigvis et problem med hvordan tilganger godkjennes eller systemer settes opp. Dokumenter hvilke tiltak som er tekniske og hvilke som krever organisatorisk endring.
Skill retting fra verifisert lukking
Når et funn er rettet, bør en egnet kontroll bekrefte at den relevante svakheten er borte og at endringen ikke har skapt en ny feil. Avklar om leverandørens oppdrag inkluderer slik kontroll, hvilke funn den omfatter og hvilket tidsrom som gjelder. En utviklers beskjed om at koden er endret, er ikke alltid nok til å konkludere om det faktiske miljøet.
Bevar referanse til funn, endring og kontrollresultat. Hvis bare deler av problemet er løst, bør resten stå åpent med ansvar og begrunnelse. En samlet status «testen er bestått» kan skjule at rapporten inneholder funn som aldri er fulgt opp. Bruk presise statuser som beskriver hva som er undersøkt og bekreftet.
Undersøk leverandørens metode og kompetanse
Be leverandøren forklare erfaring med den aktuelle teknologien og hvordan kvaliteten på funn sikres. Vurder en redigert eksempelrapport, metodebeskrivelse og gjennomføringsplan. En sertifisering kan være relevant informasjon, men dokumenterer ikke alene at oppdragets omfang og leveranse er egnet.
Sammenlign tilbud på samme grunnlag: systemer, roller, metode, rapport, oppfølging og håndtering av data. Ulike pristilbud kan dekke helt forskjellige oppgaver. Denne veiledningen oppgir ingen markedspris eller universell nødvendig varighet; et forsvarlig estimat krever et konkret omfang og avklarte forutsetninger.
Håndter hendelser under testen
Hvis undersøkelsen avdekker et mulig personvernbrudd eller en aktiv kompromittering, må virksomheten ha en prosess for å vurdere dette separat fra testfunnene. Bruk avviksrutinen til ansvar, sikring av relevante opplysninger og nødvendig videre håndtering. At en hendelse oppdages under en planlagt test, avgjør ikke i seg selv dens rettslige betydning.
Avklar også hvordan egne sikkerhetsvarsler skal tolkes mens testen pågår. Drift må kunne skille autorisert aktivitet fra andre hendelser uten å slå av all overvåking. Registrer avtalte kjennetegn og kontaktpunkter, men behold muligheten til å stoppe og undersøke noe som ikke passer med planen.
Avslutt oppdraget og planlegg neste kontroll
Steng testkontoer, trekk tilbake midlertidige tilganger og håndter arbeidskopier etter avtalen. Bekreft at dokumentasjonen er levert til riktig mottaker og har passende tilgang. Et oppdrag bør ikke etterlate aktive nøkler eller detaljerte rapporter i åpne prosjektrom.
Velg videre kontroll ut fra risiko, endringer og tidligere funn. En større endring i tilgangslogikk kan gi behov for ny undersøkelse selv om en kalenderbasert test nylig er gjennomført. Den ferdige bestillingen og rapporten bør gi virksomheten svar på definerte spørsmål og et konkret grunnlag for forbedring av de faktiske sikkerhetstiltakene.