Slik brukes pentestbevis i ISO 27001-arbeidet

Forsidebildet er en AI-generert redaksjonell illustrasjon. Skjermer og dokumenter er illustrerte konsepter.

En pentest er ett av flere bevis i et ISO 27001-arbeid. Rapporten får verdi når virksomheten kan forklare hva som ble testet, hvorfor omfanget er relevant, og hvordan funnene ble fulgt opp.

ISO/IEC 27001 stiller krav til et styringssystem for informasjonssikkerhet. Standarden sertifiserer ikke et bestemt testprodukt. Om en test er egnet, avhenger av risiko, valgte kontroller og andre forpliktelser.

Begynn med applikasjonene og tilgangsgrensene

Lag en oversikt over applikasjonene innenfor styringssystemets omfang, eierne og dataene de håndterer. Avklar hvilke grenser testen skal undersøke: skillet mellom kunder, administratorfunksjoner, autentisering, API-er og integrasjoner.

Avtal tillatelse, testmiljø, kontoer, tillatte handlinger og stoppkriterier. Tredjepartssystemer krever tillatelse fra eieren. Tilgang til en SaaS-konto gir ikke automatisk rett til å teste leverandørens plattform.

Dokumenter hva som er utelatt. Revisor og kunder må kunne forstå begrensningene i rapporten.

La risiko og endringer styre tidspunktet

Sett en frekvens som passer risikoen, og planlegg nye tester ved vesentlige endringer. Et nytt kunde-API eller omskrevet tilgangsstyring kan gi behov for en ny vurdering. Retesting av ett rettet funn dekker ikke nødvendigvis disse endringene.

FMs pentesttilbud for applikasjoner bruker Aikido, med rapportering fra FM. Aikido beskriver validering gjennom utnyttelse og retesting av rettelser som funksjoner i tjenesten. Avklar avtalt omfang og tilgjengelig automatisering før dere lover testing ved hver utrulling.

Hold dokumentasjonen samlet

Behold følgende for hver vurdering:

• Godkjent omfang, testdatoer og applikasjonsversjon.
• Rapport med funn og begrensninger i dekningen.
• Oppgaver for utbedring, med eiere og beslutninger om gjenværende risiko.
• Retest som viser om de aktuelle feilene er rettet.

Beskytt rapportene. Detaljer om sårbare endepunkter og hvordan feil kan utnyttes, kan være sensitive.

Knytt dokumentasjonen til relevante kontroller i anvendelighetserklæringen, ofte kalt SoA. Sikkerhetstesting under utvikling og akseptanse er relevant for kontroll 8.29 i vedlegg A. Sårbarhetshåndtering og utkontraktert utvikling kan også være relevant, men en testrapport oppfyller ikke alle disse oppgavene alene.

Avklar forventningene før revisjonen

Spør sertifiseringsorganet hvilke bevis det trenger for å vurdere kontrollene. Sjekk også om kundekontrakter stiller konkrete krav til testmetoden. En automatisert rapport kan inngå i dokumentasjonen, men produktnavnet eller betegnelsen «revisjonsklar» garanterer ikke aksept.

Det viktigste er samsvar mellom plan og praksis: Virksomheten følger testplanen, og dokumentasjonen viser hvordan funnene ble brukt til å forbedre applikasjonen.