Tilgang mellom kunder
Tilgang til enkeltobjekter og isolasjon mellom kunder: kan en bruker lese eller endre en annen kundes informasjon?
02 / AI-drevet pen-test
AI-drevet testing.
Forstå risikoene.
AI-drevet pen-test av webapplikasjoner og API-er. AI hjelper oss å undersøke mulige angrepsveier innenfor det avtalte testomfanget. Spesialistene våre styrer testene, validerer funn og vurderer konsekvensene.
01Webapplikasjoner og API-er
02Avtalte mål og testregler
03Validering og dokumentert påvirkning
Dette gjennomgår vi
Angrepsveier som
betyr noe for dere.
Vi starter med viktige data og funksjoner og velger kontroller som passer systemet og målene for oppdraget.
Roller og administrasjon
Kan en vanlig bruker nå funksjoner som skal kreve høyere rettigheter?
Innlogging og økter
Hvordan innlogging, tilgangstokener og økter fungerer, fra innlogging til utlogging og utløpt gyldighet.
Forretningslogikk og dataflyt
Flyter der et teknisk gyldig kall kan omgå en regel, røpe informasjon eller forårsake utilsiktet påvirkning.
Inndata og API-kall
Relevante tester av hvordan kall, parametere, filer og eksterne referanser behandles.
Eksponering og konfigurasjon
Innstillinger som kan kontrolleres utenfra, feilmeldinger og tilgjengelige grensesnitt. Infrastrukturtester legges til når de uttrykkelig inngår.
Aktive tester krever godkjent omfang og regler for testingen. Skrivetester, belastningstester, eksterne tjenester for å registrere tilbakekall og produksjonspåvirkning inngår bare når de er uttrykkelig avtalt.
Deres leveranse
Resultater dere kan
handle på.
Et testresultat skal forklare hva som faktisk ble vist, hvorfor det betyr noe og hva som gjenstår. En navngitt vurderer står for vurderingen.
- Vurdering for tekniske team og ledelsePrioriterte funn og et sammendrag av konsekvensene testene har vist.
- Testtrinn som kan gjentasRelevante testtrinn og bevis for validerte funn, med hensyn til sensitiv informasjon.
- Tydelig redegjørelse for testomfangetHva som ble testet, hvilke kontroller som ikke ga et entydig resultat og hva som lå utenfor oppdraget.
- Tiltak og kriterier for retestAnbefalinger og et tydelig forventet resultat når samme svakhet kontrolleres på nytt.
EKSEMPEL / OBJEKTTILGANGSamme objekt.
Samme objekt.
To ulike identiteter.
Eier → 200 · forventet tilgang
Annen kunde → 200 · objektet returneres
Anonym → 401 · nektet tilgang
Annen kunde → 200 · objektet returneres
Anonym → 401 · nektet tilgang
VALIDERINGKontroller hvem objektet tilhører og hvem som skal få lese det. En HTTP-status er ikke bevis i seg selv.
VERIFISERES UTBEDRET NÅRAnnen kunde nektes objektet, mens eieren fortsatt får tiltenkt tilgang.
SYNTETISK EKSEMPEL · IKKE ET KUNDERESULTAT
Slik foregår det
Fra sikkerhetsspørsmål til verifisert resultat.
Mål og tillatelse
Vi dokumenterer systemer, miljøer, testkontoer, tillatte aktiviteter og kontaktveier.
Test i runder
Vi gjennomfører kontroller og prøver utvalgte angrepsveier. Resultatene styrer hva vi undersøker videre.
Verifiser og vurder
Vi kontrollerer tilgangsregler, underlag og konsekvenser og skiller bekreftede svakheter fra mistenkte svakheter.
Lever og følg opp
Resultatet gjennomgås. Etter tiltak kan en avgrenset retest bestilles.
Greit å vite
Før deres
første oppdrag.
Trenger dere tilgang til kildekoden?
En pen-test kan gjennomføres uten kildekode. Kodetilgang kan gi ytterligere forståelse når det inngår; en separat kodegjennomgang kan også kombineres med testingen.
Kan dere teste i produksjon?
Testmiljø velges sammen. Produksjon krever uttrykkelig enighet om aktiviteter, risikoer, tidspunkter og regler for å avbryte testingen.
Er testen en engangsinnsats eller løpende?
Begge opplegg kan avtales. En avgrenset gjennomgang passer før lansering. Styrken i arbeidsmåten vår er imidlertid løpende testing: bekreftede funn blir gjenkjørbare kontroller som kan kjøres ved hver release, slik at en endring som gjeninnfører en svakhet oppdages tidlig og dere ser en trend over tid.
Inngår en retest?
Omfang og pris for retest skal fremgå av tilbudet. Retesten prøver effekten av tiltakene mot dokumenterte kriterier; det er ingen garanti for at hele systemet er sikkert.
Støtter testingen DORA og andre krav?
Ja. Vurderingen, bevisunderlaget og retest-sporet blir en del av underlaget dere trenger for f.eks. DORA (IKT-risiko og operasjonell motstandsdyktighet), NIS2 og ISO 27001. En navngitt vurderer står for resultatet; det er underlag og vurdering, ikke en formell sertifisering.
Ta neste steg
Hvilke angrep må
systemet deres tåle?
Fortell om systemet, de viktigste verdiene og tidsplanen deres.