Slik forbereder du deg til en penetrasjonstest

En sjekkliste for kunden: hva som skal avgjøres, hva som skal forberedes, og hvem som skal varsles før testerne starter, slik at de betalte dagene går til testing.

Publisert4 min lesetid

En penetrasjonstest betales per dag. Hver dag testerne bruker på å vente på en konto, gjette hvordan en funksjon skal virke eller bli blokkert av din egen brannmur, er en dag som ikke går til å finne sårbarheter. Det meste av ventetiden kan fjernes før starten.

Avgjør

Hva er spørsmålet? «Er den nye betalingsflyten trygg å lansere» og «hva kan noen på internett gjøre mot oss» fører til ulike tester. Skriv ned spørsmålet i én setning; omfanget følger av det.

Hva er innenfor omfanget, og hva er ikke det? List opp applikasjonene, adressene, miljøene. List også opp unntakene: betalingsleverandøren, morselskapets systemer, den gamle tjenesten som går ned bare noen ser på den.

Hvilket miljø? Et stagingmiljø som speiler produksjon, er å foretrekke: Testerne kan være grundige, og ingenting virkelig står på spill. Hvis det bare finnes et produksjonsmiljø, avtal tidspunktene og teknikkene som ikke er tillatt.

Hvor mye vet testerne? Testing med kontoer og dokumentasjon finner mer per dag enn blindtesting. Blindtesting svarer på ett snevert spørsmål: hva en utenforstående oppnår uten informasjon. Avgjør hva av dette du betaler for.

Forbered

Kontoer. Én for hver rolle, og i to separate leietakere (tenants) hvis produktet har leietakere: Tilgangskontroll mellom kunder kan ikke testes med én kunde. Opprett dem før starten, logg inn med hver av dem én gang, og kontroller at de har realistiske data.

Dokumentasjon. API-spesifikasjoner, et arkitekturdiagram, en beskrivelse av rollene og av de viktigste arbeidsflytene. Mangelfulle dokumenter er bedre enn ingen.

Tilgang. Hvis testmiljøet ligger bak en VPN eller en tilgangsliste, ordne tilgangen på forhånd, og test den. Avgjør om brannmuren for webapplikasjoner (WAF) skal være på. Hvis det er applikasjonen som testes, slipp testerne gjennom brannmuren; hvis det er brannmuren som testes, la den stå på, og si fra om det.

Data. Fyll testmiljøet med data som ligner de virkelige i struktur og ikke i innhold. Ekte personopplysninger i et testmiljø er et funn før testen har begynt.

Sikkerhetskopier. Bekreft at miljøet som testes, kan gjenopprettes. Testere er forsiktige; sikkerhetskopier er for de tilfellene der forsiktighet ikke var nok.

Varsle

Driftsteamet og overvåkingsteamet, med mindre testen skal undersøke nettopp dem. Gi dem kildeadressene til testerne og datoene. Ellers ender den første dagen med at testerne er blokkert og en hendelse er registrert.

Hostingleverandøren eller skyleverandøren, der retningslinjene deres krever det. De store skyleverandørene krever ikke varsel for testing av dine egne ressurser innenfor de publiserte reglene sine; mindre hostingselskaper gjør det ofte.

Leverandører hvis systemer berøres. Samtykket deres må foreligge skriftlig.

Én kontaktperson, som kan nås i testtiden og har myndighet til å ta avgjørelser: forlenge en konto, starte en tjeneste på nytt, stanse testen.

Signer

  • konfidensialitetsavtalen (NDA), før noe av det ovenstående overleveres;
  • avtalen;
  • den skriftlige tillatelsen og reglene for gjennomføring.

Hva hvert av dokumentene er til for, er beskrevet i artikkelen «Hva som gjør en penetrasjonstest lovlig».

Under testen

  • Ikke rull ut endringer i miljøet som testes, uten å si fra til testerne. Et funn som forsvinner over natten, koster en dag med forvirring.
  • Ikke utbedre funn underveis, bortsett fra funn med kritisk alvorlighetsgrad. Hvis du utbedrer et funn, si fra.
  • Svar raskt på spørsmål. En tester som spør hvordan en funksjon skal virke, har som regel funnet noe.
  • Regn med å få hastende funn straks. En kritisk sårbarhet rapporteres når den er bekreftet, ikke i sluttrapporten.

Etter testen

  • Les sammendraget sammen med ledelsen og funnene sammen med ingeniørene. De er skrevet for ulike lesere.
  • Delta på gjennomgangsmøtet. Det er den billigste timen i oppdraget.
  • Planlegg utbedringene etter prioritet, og si fra til testerne når de er satt i drift.
  • Bruk retesten. En utbedring som ikke er verifisert, er en antakelse.
  • Hold rapporten konfidensiell. Til utbedringene er på plass, er den en bruksanvisning for å angripe deg. For kunder og revisorer finnes bekreftelsesbrevet.

Sjekklisten

Før starten Utført
Spørsmål og omfang skrevet ned, med unntak
Miljø valgt, testvinduer avtalt
Kontoer opprettet for hver rolle, i to leietakere hvis produktet har leietakere
Dokumentasjon overlevert
Nettverkstilgang ordnet og testet
Testdata på plass, ingen ekte personopplysninger
Sikkerhetskopier verifisert
Drift, overvåking og leverandører varslet
Kontaktperson utpekt
NDA, avtale, skriftlig tillatelse og regler for gjennomføring signert

Siden for hver tjeneste viser hva akkurat den testen trenger fra deg.

Forespørsel

Fortell oss hva som skal testes

  • Gratis sjekk av nettstedet
  • Svar innen 1 arbeidsdag
  • NDA før tekniske detaljer
  • Fast pris for betalte oppdrag
  • Uforpliktende

Be om en vurdering

Beskriv systemene og målet. En kundeansvarlig svarer innen 1 arbeidsdag med oppklarende spørsmål og neste steg.

Hvem vi skal svare

Vi svarer til denne adressen med mindre du velger en annen kanal.

Driver du et enkeltpersonforetak, skriver du ditt eget navn.

Foretrukket kanal
Hva vi skal vurdere
Aktuelle tjenester

Velg alle som passer.

Gratis sjekk

Vi sjekker nettstedet ditt gratis

Hvis vi ikke finner problemer, får du også rapporten gratis. Du betaler for rapporten bare når vi finner problemer, og prisen avhenger av hvor mange de er og hvor alvorlige de er.

Vilkår for gratis sikkerhetssjekk av nettsted

Applikasjonssikkerhet

Infrastruktur og sky

Angrepssimulering

KI, Web3 og kryptografi

Programmer og kontroll

Applikasjonssikkerhet

Gratis sikkerhetssjekk av nettsted

Vi ser på nettstedet ditt utenfra, slik en angriper gjør, og sjekker om noen kan bryte seg inn i det: svake innstillinger, utdatert programvare, åpent tilgjengelige filer, usikre skjemaer. Sjekken er gratis.

Applikasjonssikkerhet

Penetrasjonstesting av webapplikasjoner

Vi prøver å bryte oss inn i webapplikasjonen din slik en virkelig angriper ville gjort: logge inn på andres kontoer, lese dataene til andre kunder, endre priser eller bestillinger. Du får vite hva som er mulig, før kriminelle gjør det.

Applikasjonssikkerhet

Sikkerhetstesting av API-er

Et API er kanalen som appen din, nettstedet ditt og partnerne dine bruker til å utveksle data med serverne dine. Vi kontrollerer at ingen kan bruke det til å lese eller endre data som tilhører andre.

Applikasjonssikkerhet

Penetrasjonstesting av mobilapper

Vi undersøker iOS- eller Android-appen din og serverne bak den: hva appen lagrer på telefonen, hva som kan hentes ut av den, og om forespørslene den sender, kan manipuleres.

Applikasjonssikkerhet

Sikkerhetsgjennomgang av kildekode

Spesialistene våre leser kildekoden til produktet ditt og finner feilene som fører til et innbrudd, også dem som ikke kan ses utenfra.

Infrastruktur og sky

Sikkerhetsvurdering av sky og Kubernetes

Vi undersøker hvordan skyen din er satt opp (AWS, Azure, Google Cloud, Kubernetes): hvem som har tilgang til hva, hvilke data som er åpne mot internett, og hvor langt en angriper kommer etter den første feilen.

Infrastruktur og sky

Penetrasjonstesting av infrastruktur

Vi tester serverne og kontornettverket ditt utenfra og innenfra: om en angriper kan komme seg inn, og om angriperen derfra kan nå regnskapssystemet, e-posten eller sikkerhetskopiene.

Infrastruktur og sky

Vurdering av ekstern angrepsflate

Vi finner alt selskapet ditt eksponerer mot internett, også det som er glemt: gamle nettsteder, testservere, lekkede passord. Deretter viser vi hva av dette som kan angripes.

Infrastruktur og sky

Sikkerhet i CI/CD og leverandørkjeden

Vi undersøker veien koden din tar fra utvikleren til kunden: byggeservere, biblioteker fra tredjeparter, tilgangsnøkler. Den som kontrollerer denne veien, kontrollerer produktet ditt.

Angrepssimulering

Red Team-operasjoner

En øvelse i full skala. Teamet vårt spiller en virkelig angriper med et mål, for eksempel å få tak i kundedata, og du ser om forsvaret ditt oppdager og stopper angrepet.

Angrepssimulering

Purple Team-øvelser

Angriperne våre og forsvarerne dine arbeider side om side: Vi viser en angrepsteknikk, teamet ditt kontrollerer om det ser den, og hullene i overvåkingen tettes på stedet.

Angrepssimulering

Testing med sosial manipulering

Vi tester mennesker, ikke maskiner: phishing-e-postene, samtalene og meldingene som angripere bruker for å få tak i passord. Du får vite hvor mange ansatte som ville blitt lurt, og hva de trenger opplæring i.

KI, Web3 og kryptografi

Sikkerhetstesting av KI og LLM

Hvis produktet ditt har en chatbot eller en annen KI-modell, undersøker vi om den kan overtales til å avsløre konfidensielle data, bryte sine egne regler eller handle på vegne av noen andre.

KI, Web3 og kryptografi

Revisjon av smartkontrakter

Før en smartkontrakt skal holde penger, leter vi etter feil i koden som ville latt noen ta ut eller fryse midlene. Etter utrulling kan slike feil ikke rettes.

KI, Web3 og kryptografi

Gjennomgang av kryptografi

Vi undersøker hvordan produktet ditt krypterer data og beskytter nøkler: om de riktige algoritmene er valgt, og om de brukes riktig. En feil her gjør krypteringen verdiløs.

Programmer og kontroll

Forvaltning av bug bounty-program

Bug bounty er et program der uavhengige sikkerhetsforskere leter etter sårbarheter i produktet ditt og får betalt for hver av dem de finner. Vi lanserer og driver et slikt program for deg.

Programmer og kontroll

Program for sårbarhetsrapportering (VDP)

En offentlig side og en fremgangsmåte som forteller sikkerhetsforskere hvordan de trygt kan rapportere en sårbarhet til deg. Uten dem blir rapporter borte eller kommer som trusler. Vi setter opp prosessen og håndterer rapportene som kommer inn.

Programmer og kontroll

Kontinuerlig penetrasjonstesting

I stedet for én test i året tester vi hver vesentlige endring i produktet ditt gjennom hele året, slik at en ny sårbarhet ikke venter i månedsvis på å bli funnet.

Programmer og kontroll

Penetrasjonstesting for etterlevelse

En penetrasjonstest lagt opp slik at en revisor, en tilsynsmyndighet eller en stor kunde godtar rapporten: PCI DSS, DORA, NIS2, ISO/IEC 27001, SOC 2.

Aktuelle tjenester

Vet ikke ennå

Velg dette hvis du ikke vet hvilken tjeneste du trenger. Beskriv oppgaven med egne ord, så foreslår en spesialist en tjeneste i svaret.

Domene eller URL til nettstedet eller til hovedsystemet som skal testes, for eksempel app.example.com.

Hva som skal testes, hvorfor nå, og eventuelle frister eller krav til etterlevelse. Ingen passord, nøkler eller detaljer om sårbarheter.

Bekreftelser

Ikke send påloggingsinformasjon, nøkler eller detaljer om en sårbarhet gjennom dette skjemaet. En sikker kanal avtales etter det første svaret.

Automatisk kontroll mot misbruk