Hva som gjør en penetrasjonstest lovlig

De samme handlingene er en tjeneste med tillatelse og et lovbrudd uten. Hvilke dokumenter som gir tillatelsen, hvem som kan signere dem, og hvor hullene vanligvis er.

Publisert4 min lesetid

En penetrasjonstester gjør det samme som en inntrenger: leter etter en vei inn og bruker den. Lovene mot datakriminalitet i de fleste land spør ikke etter hensikter. De spør om det forelå tillatelse til tilgangen. Hele forskjellen mellom en tjeneste og et lovbrudd er et sett dokumenter, signert av riktig person før arbeidet starter.

Denne artikkelen beskriver disse dokumentene. Den er ikke juridisk rådgivning: Loven er forskjellig fra land til land, og advokatene dine avgjør hva som gjelder for deg.

Dokumentene

Avtale

Den kommersielle avtalen: hva som gjøres, innen når, for hvor mye, med hvilket ansvar og hvilken konfidensialitet. Avtalen alene er ikke tillatelsen. Den forplikter partene overfor hverandre; den sier ikke i seg selv hva som kan angripes.

Skriftlig tillatelse

Erklæringen der eieren av systemene tillater testen. Den bør angi:

  • systemene, med adresse, domene eller en annen entydig identifikator;
  • perioden da testing er tillatt;
  • personene eller selskapet som har lov til å teste;
  • den som signerer, og i hvilken egenskap vedkommende signerer.

Testerne har den med seg, bokstavelig eller i overført betydning, gjennom hele oppdraget. Når en hostingleverandør eller en politimyndighet spør hva som foregår, er det dette dokumentet som svarer.

Regler for gjennomføring

De tekniske grensene: hvilke teknikker som er tillatt og hvilke som er utelukket, tidspunktene for testing, forespørselsfrekvensen, hva som skjer når et system blir ustabilt, hvem som skal ringes om natten. NIST SP 800-115 behandler reglene for gjennomføring som en obligatorisk del av planleggingen, og PTES plasserer dem i fasen før oppdraget (pre-engagement) av samme grunn: Spørsmål som ikke er avklart før testen, blir avklart under en sikkerhetshendelse.

Beskrivelse av omfanget

Listen over hva som er innenfor, og hva som er utenfor. Unntakene er like viktige som det som er med: betalingsleverandøren bak kassen, den delte plattformen til hostingselskapet, single sign-on-tjenesten som tilhører morselskapet.

Konfidensialitet og personvern

En konfidensialitetsavtale (NDA), signert før tekniske detaljer utveksles. Der testerne kan komme over personopplysninger, en databehandleravtale. I EU følger dette av artikkel 28 i personvernforordningen (GDPR) når testeren behandler personopplysninger på vegne av kunden.

Hvem som kan signere

Tillatelsen er ikke mer verdt enn myndigheten til den som signerer den.

  • Eieren av systemet, ikke brukeren. Et selskap kan ikke gi tillatelse til testing av et SaaS-produkt det abonnerer på.
  • En person med rett til å forplikte selskapet. En utvikler som bestiller en test av produksjonssystemet til arbeidsgiveren uten at ledelsen vet om det, har ikke gitt tillatelse til noe.
  • Alle eierne, når det er flere. Et system som ett selskap driver på infrastrukturen til et annet, kan kreve tillatelse fra begge.

En grundig leverandør verifiserer dette: slår opp i foretaksregisteret, kontrollerer eierskapet til domenene og bekrefter bestillingen gjennom en offisiell kanal hos selskapet. En leverandør som ikke spør, bør gjøre deg bekymret.

Tredjeparter

Tillatelsen din dekker det som er ditt. Rundt det finnes det vanligvis systemer som ikke er det.

Skyleverandører. De store leverandørene publiserer retningslinjer for testing av ressurser som kundene kjører på plattformene deres. I skrivende stund tillater AWS, Microsoft Azure og Google Cloud kundene å teste sine egne ressurser uten forhåndsgodkjenning, innenfor reglene hver av dem publiserer; AWS angir også hvilke tjenester som kan testes. Alle tre begrenser testing med tjenestenektangrep. Retningslinjene endres, så de kontrolleres før hvert oppdrag og hentes ikke fra hukommelsen etter det forrige.

Hosting og administrerte tjenester. Delt hosting, administrerte databaser og innholdsleveransenettverk (CDN) har egne vilkår. Noen krever varsel, noen forbyr testing helt.

Leverandører og partnere. En integrasjon med en partner utvider ikke tillatelsen din til partnerens side av integrasjonen. Uten skriftlig samtykke fra partneren stopper testingen ved din grense.

De vanlige hullene

  • Testen har startet, den skriftlige tillatelsen er fortsatt «til signering».
  • Omfanget oppgir et domene, og applikasjonen bak det flyttet til en annen adresse forrige måned.
  • Tillatelsen er signert av noen som ikke hadde myndighet til å signere den.
  • Produksjonsmiljøet er innenfor omfanget, og ingen har sagt fra til driftsteamet.
  • Et datterselskap i et annet land testes med tillatelsen fra morselskapet.

Hvert av dem gjør en test med tillatelse til en test uten tillatelse for en del av arbeidet, og ingen av dem er synlige fra den tekniske siden.

Bug bounty er også en tillatelse

Et bug bounty-program er en tillatelse gitt offentlig: Retningslinjene for programmet sier hva som kan testes og hvordan, og den som følger dem, handler med tillatelse fra eieren. En safe harbour-klausul legger til eierens forpliktelse til ikke å rettsforfølge sikkerhetsforskere som holder seg innenfor retningslinjene. Den binder bare eieren. Den endrer ikke strafferetten og binder ikke tredjeparter, og derfor må retningslinjene følges nøyaktig, og derfor er et system uten program ikke et mål.

Kort oppsummert

Før den første pakken sendes, bør det foreligge en avtale, en skriftlig tillatelse signert av noen som har rett til å signere den, regler for gjennomføring, et omfang med unntakene og samtykke fra hver tredjepart hvis systemer berøres. Hvordan vi håndterer dette i detalj, står på siden «Gangen i et oppdrag».

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