VAPT forklaret: sårbarhedsvurdering og penetrationstest

I Indien er „VAPT“ hverdagsbetegnelsen for sikkerhedstest. Kunder, partnere, revisorer og regulerede modparter beder ofte om en „VAPT-rapport“, før de underskriver en kontrakt, tilslutter en integration eller godkender en lancering. Betegnelsen kombinerer to aktiviteter: sårbarhedsvurdering, der bredt leder efter kendte svagheder, og penetrationstest, der i dybden undersøger, om disse svagheder kan udnyttes. Denne vejledning forklarer, hvad et VAPT-forløb normalt omfatter, hvordan det afgrænses fornuftigt, og hvad I bør kontrollere, før I deler resultatet.

Hvad det er

Sårbarhedsvurderingen (VA) er bred. Den kombinerer automatiseret scanning med gennemgang for at identificere manglende patches, forældede komponenter, eksponerede tjenester, svag konfiguration og almindelige webproblemer på tværs af aftalte aktiver. Penetrationstesten (PT) går i dybden. En tester arbejder manuelt på udvalgte mål, typisk webapplikationer, API’er og mobilapps, validerer fund og tester autentifikation, sessionshåndtering, adgangskontrol mellem roller, dataeksponering og forretningslogik. Sammen giver VA dækning, og PT giver sikkerhed for, hvad der reelt kan udnyttes. Et VAPT-forløb bør afsluttes med en skriftlig rapport, der registrerer omfang, metode, fund vurderet efter alvorlighed med beviser, vejledning i afhjælpning og, hvor det er aftalt, resultatet af en gentest efter rettelser. Anmodninger henviser undertiden til rammer som OWASP Top 10 eller OWASP Mobile Application Security-vejledningen; de er nyttige referencepunkter for, hvad testere ser på.

Hvem er det for?

VAPT efterspørges ofte af eller for:

SaaS-, fintech- og e-handelsteams, hvis erhvervskunder beder om en nylig VAPT-rapport i forbindelse med indkøb
Virksomheder, der forbinder sig til en partner, bank eller betalingsudbyder, som kræver dokumentation for sikkerhedstest før integration
Produktteams, der forbereder en offentlig lancering af en web- eller mobilapplikation
Organisationer, der har ændret hosting, autentifikation eller betalingsflows og ønsker en uafhængig kontrol

Hvad det hjælper med at afklare

En velafgrænset VAPT hjælper med at afklare:

Hvilke applikationer, API’er og miljøer den, der stiller kravet, faktisk forventer at se testet
Om kravet nævner en bestemt type revisor eller akkreditering, der skal bekræftes, før en udbyder vælges
Hvilke fund der er validerede risici, og hvilke der er scannerobservationer
Hvilken afhjælpning der skal ske, før en rapport kan deles med tillid

Hvad er inkluderet

Få det præcise krav skriftligt fra den, der stiller det: aktiver, dybde, rapportformat og eventuelle kriterier for udbyderen
Oplist mål: domæner, applikations-URL’er, API-basestier, builds af mobilapps og miljøer (staging eller produktion)
Forbered testkonti for hver brugerrolle, så test af adgangskontrol bliver meningsfuld
Bekræft skriftlig autorisation, testvindue, navngivne kontaktpersoner og stopbetingelser
Informér hosting-, CDN- eller WAF-udbydere, hvis deres vilkår kræver det
Aftal vurdering af alvorlighed, rapportformat, og hvordan beviser skal deles
Afsæt tid til at rette fund, og bed om en gentest af aftalte problemer

Hvad er ikke inkluderet?

En erklæring om, at en VAPT gør en applikation sikker eller compliant
En påstand om, at en udbyder opfylder et bestemt krav om akkreditering eller optagelse på en godkendt liste, uden at det er kontrolleret mod det pågældende krav
Test af tredjepartssystemer uden ejerens tilladelse
Juridisk eller regulatorisk rådgivning om, hvad en bestemt regel kræver

Hvornår du skal vælge det

Bestil en VAPT, når en navngiven modpart beder om en, før en betydelig lancering eller efter større ændringer i, hvordan brugere logger ind, betaler eller får adgang til data. Hvis anmodningen kommer fra et reguleret forhold, så læs kravet omhyggeligt: nogle angiver en akkrediteret eller godkendt (empanelled) revisor (i Indien henviser nogle tilsynsmyndigheder og modparter til CERT-In-godkendte revisorer), et bestemt omfang eller en fast testcyklus. Bekræft disse detaljer med den, der stiller kravet, først, fordi en rapport, der ikke matcher kravet, kan blive nødt til at blive lavet om. Denne artikel er generel information, ikke juridisk eller regulatorisk rådgivning.

Vores tilgang

Brug tjeklisten fra den, der stiller kravet, som udgangspunkt, og tilføj derefter de systemer, der bærer størst risiko for jeres forretning, selv om ingen har spurgt til dem. Test så vidt muligt i et staging-miljø, der afspejler produktion, og aftal på forhånd, hvordan test i produktion håndteres, hvis det er påkrævet. Vores tjeneste Application Security Review omfatter test af webapplikationer og API’er med skriftlige fund graderet efter alvorlighed og vejledning i afhjælpning; bredere omfang med flere miljøer eller netværk håndteres gennem vores tjeneste Penetration Testing. I begge tilfælde bekræftes omfang, autorisation og rapportering skriftligt, før arbejdet begynder. Efter leveringen bør I rette de høje og kritiske fund først, registrere beslutninger om eventuelle accepterede risici og bede om en gentest. Del derefter et ledelsesresumé eller et brev om afhjælpningsstatus i stedet for den fulde tekniske rapport, medmindre den, der stiller kravet, specifikt har brug for det detaljeniveau og har en sikker måde at modtage den på.

Application Security Review

Se siden for tjenesten Application Security Review