Rapporten er den delen av en penetrasjonstest som varer. Testingen foregår over noen dager eller uker; rapporten er det utviklerne retter feil ut fra, det ledelsen leser, og det dere eventuelt deler med en kunde eller partner. En svak rapport kan få en grundig test til å se tynn ut, mens en tydelig rapport gjør funn om til beslutninger. Denne guiden forklarer hva en profesjonell rapport fra penetrasjonstest vanligvis inneholder, hvordan den bør leses, og hva dere bør be om før et oppdrag starter.
Hva det er
En rapport fra penetrasjonstest er en skriftlig oversikt over hva som ble testet, hvordan, under hvilke betingelser, og hva som ble funnet. Den bør kunne leses av to målgrupper. Ikke-tekniske interessenter trenger et kort sammendrag av samlet risiko, de viktigste problemene og anbefalte prioriteringer. Tekniske team trenger nok detaljer om hvert funn til å forstå det, gjenskape det i et trygt miljø og rette det. En god rapport dokumenterer også sine egne begrensninger: hva som var utenfor omfanget, hva som ikke kunne testes, og eventuelle forhold som påvirket dekningen, som manglende testkontoer eller et forkortet testvindu. Uten disse begrensningene kan leserne anta at rapporten dekker mer enn den gjør.
Hvem det er for
Denne guiden er nyttig for:
- Innkjøpere som sammenligner tilbud og vil vite hvilken leveranse de faktisk får
- Tekniske ledere som skal motta funn og må planlegge utbedring
- Ledere som må dele et sammendrag med en kunde, partner, revisor eller et styre uten å overdrive resultatet
- Team som har mottatt en tidligere rapport og syntes den var vanskelig å handle ut fra
Hva det hjelper med å klarlegge
Når dere kjenner den forventede strukturen, kan dere kontrollere:
- Om omfanget og testreglene i rapporten samsvarer med det som ble avtalt
- Om hvert funn har bevis, en tydelig gradering av alvorlighet og praktisk veiledning om utbedring
- Hvilke problemer som krever umiddelbar handling, og hvilke som kan planlegges inn i vanlige utviklingssykluser
- Hvilke utsagn som trygt kan deles eksternt, og hvilke som bare hører hjemme hos teknisk personell
Hva er inkludert
- Ledersammendrag: helhetsbilde, de viktigste funnene og anbefalte prioriteringer i et klart språk
- Omfang og testregler: mål, miljøer, brukerroller, datoer, testvindu og unntak
- Sammendrag av metodikk: tilnærmingen og referanserammeverkene som ble brukt, for eksempel OWASP-veiledning for nettapplikasjoner
- Funnregister: hvert problem med tittel, alvorlighetsgrad, berørt eiendel, beskrivelse, bevisreferanse og forretningsmessig konsekvens
- Tekniske detaljer: trinn teamet kan bruke for å forstå og gjenskape problemet på en trygg måte
- Veiledning om utbedring: praktiske rettelser og, der det er nyttig, kortsiktige tiltak for å redusere risiko
- Begrensninger: hva som ikke kunne testes, og hvorfor
- Del for ny test: status for avtalte funn etter at teamet har rettet dem, der ny test er inkludert
Hva er ikke inkludert
- En erklæring om at systemet er sikkert eller ikke har gjenværende sårbarheter etter testingen
- Funn utenfor det avtalte omfanget presentert som om de var testet
- Sertifisering, godkjenning av etterlevelse eller en formell revisjonsuttalelse
- Implementering av rettelser, med mindre det er avtalt separat
Når skal den velges
Les denne guiden før dere signerer et testtilbud, slik at dere kan be om en eksempelrapport og bekrefte strukturen. Den er også nyttig når rapporten kommer: bruk delene over som en sjekkliste for å se om noe mangler. Hvis en interessent har bedt dere om å «sende pentest-rapporten», avgjør på forhånd om de trenger hele det tekniske dokumentet eller et ledersammendrag og et brev om utbedringsstatus. Å dele alle tekniske detaljer bredt øker risikoen, fordi de beskriver svakheter i systemene deres.
Vår tilnærming
Be om klarhet rundt alvorlighetsgradering før testingen starter. Mange leverandører bruker en skala basert på sannsynlighet og konsekvens, noen ganger med henvisning til CVSS; det viktige er at den er konsistent og forklart. Avtal hvordan bevis skal lagres og deles, og hvem som er navngitte kontaktpersoner. Når rapporten kommer, sett opp en gjennomgang slik at utviklerne kan stille spørsmål mens konteksten er fersk. Gjør funnregisteret om til saker med eiere og måldatoer, og rett de mest alvorlige problemene først. Be deretter om ny test av de avtalte funnene, slik at rapporten kan dokumentere hva som ble løst. Tjenesten vår Penetration Testing leverer et ledersammendrag, et sammendrag av omfang og testregler, et funnregister gradert etter alvorlighet med bevisreferanser, tekniske detaljer for hvert funn, en prioritert plan for utbedring og resultatet av ny test der ny test er inkludert. Uansett hvilken leverandør dere velger, ta vare på hver rapportversjon, noter hvilke funn som ble akseptert som risiko i stedet for å bli rettet, og hvem som tok den beslutningen. Den oversikten er ofte like verdifull som selve testen neste gang noen spør om sikkerhetsnivået deres.
Ofte stilte spørsmål
Beslektede artikler
Kom i gang
Vil dere ha en rapport teamet faktisk kan handle ut fra?
Fortell oss hvilke systemer som skal testes, og hvem som skal lese resultatene. Vi bekrefter omfang, testregler og rapportstruktur skriftlig.
Be om et skriftlig omfang