VAPT forklart: sårbarhetsvurdering og penetrasjonstesting

I India er «VAPT» det vanlige begrepet for sikkerhetstesting. Kunder, partnere, revisorer og regulerte motparter ber ofte om en «VAPT-rapport» før de signerer en kontrakt, kobler til en integrasjon eller godkjenner en lansering. Begrepet kombinerer to aktiviteter: sårbarhetsvurdering, som bredt ser etter kjente svakheter, og penetrasjonstesting, som i dybden undersøker om disse svakhetene kan utnyttes. Denne guiden forklarer hva et VAPT-oppdrag vanligvis dekker, hvordan omfanget kan settes fornuftig, og hva dere bør kontrollere før dere deler resultatet.

Hva det er

Delen for sårbarhetsvurdering (VA) er bred. Den kombinerer automatisert skanning med gjennomgang for å identifisere manglende oppdateringer, utdaterte komponenter, eksponerte tjenester, svak konfigurasjon og vanlige webproblemer på tvers av avtalte eiendeler. Delen for penetrasjonstesting (PT) går i dybden. En tester arbeider manuelt med utvalgte mål, typisk nettapplikasjoner, API-er og mobilapper, validerer funn og tester autentisering, sesjonshåndtering, tilgangskontroll mellom roller, eksponering av data og forretningslogikk. Til sammen gir VA dekning og PT trygghet for hva som faktisk kan utnyttes. Et VAPT-oppdrag bør avsluttes med en skriftlig rapport som dokumenterer omfang, metode, funn gradert etter alvorlighet med bevis, veiledning om utbedring og, der det er avtalt, resultatet av en ny test etter rettelser. Forespørsler viser noen ganger til rammeverk som OWASP Top 10 eller OWASP-veiledningen for sikkerhet i mobilapplikasjoner (Mobile Application Security); dette er nyttige referansepunkter for hva testere ser på.

Hvem det er for

VAPT etterspørres ofte av eller for:

SaaS-, fintech- og netthandelsteam der bedriftskunder ber om en nylig VAPT-rapport under innkjøp
Selskaper som kobler seg til en partner, bank eller betalingsleverandør som krever bevis på sikkerhetstesting før integrasjon
Produktteam som forbereder offentlig lansering av en nett- eller mobilapplikasjon
Organisasjoner som har endret drift, autentisering eller betalingsflyt og ønsker en uavhengig kontroll

Hva det hjelper med å klarlegge

En VAPT med godt definert omfang bidrar til å avklare:

Hvilke applikasjoner, API-er og miljøer den som spør faktisk forventer å se testet
Om kravet nevner en bestemt type revisor eller akkreditering som må bekreftes før en leverandør velges
Hvilke funn som er validerte risikoer, og hvilke som er observasjoner fra skanner
Hvilken utbedring som må gjøres før en rapport kan deles med trygghet

Hva er inkludert

Få det nøyaktige kravet skriftlig fra den som spør: eiendeler, dybde, rapportformat og eventuelle kriterier for leverandøren
List opp mål: domener, applikasjons-URL-er, basestier for API, versjoner av mobilappen og miljøer (staging eller produksjon)
Klargjør testkontoer for hver brukerrolle slik at testing av tilgangskontroll blir meningsfull
Bekreft skriftlig autorisasjon, testvindu, navngitte kontaktpersoner og stoppbetingelser
Informer drifts-, CDN- eller WAF-leverandører dersom vilkårene deres krever det
Avtal alvorlighetsgradering, rapportformat og hvordan bevis skal deles
Sett av tid til å rette funn, og be om ny test av avtalte problemer

Hva er ikke inkludert

En erklæring om at en VAPT gjør en applikasjon sikker eller i samsvar med krav
En påstand om at en leverandør oppfyller et bestemt krav til akkreditering eller godkjenning uten at det er kontrollert mot kravet
Testing av tredjepartssystemer uten eierens tillatelse
Juridisk eller regulatorisk rådgivning om hva en bestemt regel krever

Når skal den velges

Bestill en VAPT når en navngitt motpart ber om det, før en betydelig lansering, eller etter store endringer i hvordan brukere logger inn, betaler eller får tilgang til data. Hvis forespørselen kommer fra et regulert forhold, les kravet nøye: noen angir en akkreditert eller godkjent revisor (i India viser enkelte tilsynsmyndigheter og motparter til revisorer godkjent av CERT-In), et bestemt omfang eller en fast testsyklus. Bekreft disse detaljene med den som spør først, fordi en rapport som ikke samsvarer med kravet, kan måtte gjøres på nytt. Denne artikkelen er generell informasjon, ikke juridisk eller regulatorisk rådgivning.

Vår tilnærming

Bruk sjekklisten fra den som spør som utgangspunkt, og legg deretter til systemene som har høyest risiko for virksomheten, selv om ingen har spurt om dem. Test i et staging-miljø som speiler produksjon der det er mulig, og avtal på forhånd hvordan testing i produksjon skal håndteres dersom det kreves. Tjenesten vår Application Security Review dekker testing av nettapplikasjoner og API-er med skriftlige funn gradert etter alvorlighet og veiledning om utbedring; bredere omfang med flere miljøer eller nettverk håndteres gjennom tjenesten vår Penetration Testing. I begge tilfeller bekreftes omfang, autorisasjon og rapportering skriftlig før arbeidet starter. Etter levering, rett funnene med høy og kritisk alvorlighet først, dokumenter beslutninger om aksepterte risikoer, og be om ny test. Del deretter et ledersammendrag eller et brev om utbedringsstatus i stedet for hele den tekniske rapporten, med mindre den som spør spesifikt trenger det detaljnivået og har en sikker måte å motta det på.

Application Security Review

Se tjenestesiden for Application Security Review