VAPT förklarat: sårbarhetsbedömning och penetrationstest

I Indien är ”VAPT” det vardagliga begreppet för säkerhetstestning. Kunder, partner, revisorer och reglerade motparter begär ofta en ”VAPT-rapport” innan de skriver kontrakt, kopplar upp en integration eller godkänner en lansering. Begreppet kombinerar två aktiviteter: sårbarhetsbedömning, som brett letar efter kända svagheter, och penetrationstest, som på djupet undersöker om dessa svagheter kan utnyttjas. Den här guiden förklarar vad ett VAPT-uppdrag vanligtvis omfattar, hur omfattningen kan sättas på ett rimligt sätt och vad ni bör kontrollera innan ni delar resultatet.

Vad det är

Delen för sårbarhetsbedömning (VA) är bred. Den kombinerar automatiserad skanning med granskning för att identifiera saknade uppdateringar, föråldrade komponenter, exponerade tjänster, svag konfiguration och vanliga webbproblem i överenskomna tillgångar. Delen för penetrationstest (PT) är djup. En testare arbetar manuellt med utvalda mål, vanligtvis webbapplikationer, API:er och mobilappar, validerar fynd och testar autentisering, sessionshantering, åtkomstkontroll mellan roller, exponering av data och affärslogik. Tillsammans ger VA täckning och PT säkerhet om vad som verkligen kan utnyttjas. Ett VAPT-uppdrag bör avslutas med en skriftlig rapport som redovisar omfattning, metod, fynd klassade efter allvarlighetsgrad med belägg, vägledning för åtgärder och, där det avtalats, resultatet av ett omtest efter åtgärder. Förfrågningar hänvisar ibland till ramverk som OWASP Top 10 eller OWASP:s vägledning för säkerhet i mobilapplikationer (Mobile Application Security); dessa är användbara referenspunkter för vad testare tittar på.

Vem det är för

VAPT efterfrågas ofta av eller för:

SaaS-, fintech- och e-handelsteam vars företagskunder begär en aktuell VAPT-rapport vid upphandling
Företag som ansluter till en partner, bank eller betalleverantör som kräver belägg för säkerhetstestning före integration
Produktteam som förbereder en offentlig lansering av en webb- eller mobilapplikation
Organisationer som har ändrat hosting, autentisering eller betalflöden och vill ha en oberoende kontroll

Vad det hjälper till att klargöra

En VAPT med väl definierad omfattning hjälper till att klargöra:

Vilka applikationer, API:er och miljöer som beställaren faktiskt förväntar sig ska testas
Om kravet anger en viss typ av revisor eller ackreditering som måste bekräftas innan en leverantör väljs
Vilka fynd som är validerade risker och vilka som är iakttagelser från skannrar
Vilka åtgärder som måste göras innan en rapport kan delas med trygghet

Vad ingår

Få det exakta kravet skriftligt från beställaren: tillgångar, djup, rapportformat och eventuella kriterier för leverantören
Lista mål: domäner, applikations-URL:er, bassökvägar för API:er, byggen av mobilappar och miljöer (staging eller produktion)
Förbered testkonton för varje användarroll så att testningen av åtkomstkontroll blir meningsfull
Bekräfta skriftlig auktorisering, testfönster, namngivna kontaktpersoner och stoppvillkor
Informera hosting-, CDN- eller WAF-leverantörer om deras villkor kräver det
Kom överens om klassning av allvarlighetsgrad, rapportformat och hur belägg ska delas
Avsätt tid för att åtgärda fynd och begär omtest av överenskomna problem

Vad som inte ingår

Ett uttalande om att en VAPT gör en applikation säker eller förenlig med krav
Ett påstående om att en leverantör uppfyller ett specifikt krav på ackreditering eller godkännande utan att det har kontrollerats mot kravet
Testning av tredjepartssystem utan ägarens tillstånd
Juridisk eller regulatorisk rådgivning om vad en viss regel kräver

När det passar att välja den

Beställ en VAPT när en namngiven motpart begär det, före en betydande lansering eller efter större förändringar i hur användare loggar in, betalar eller får åtkomst till data. Om förfrågan kommer från en reglerad relation, läs kravet noga: vissa anger en ackrediterad eller godkänd revisor (i Indien hänvisar vissa tillsynsmyndigheter och motparter till revisorer godkända av CERT-In), en viss omfattning eller en fast testcykel. Bekräfta dessa detaljer med beställaren först, eftersom en rapport som inte motsvarar kravet kan behöva göras om. Den här artikeln är allmän information, inte juridisk eller regulatorisk rådgivning.

Vår strategi

Använd beställarens checklista som utgångspunkt och lägg sedan till de system som bär störst risk för verksamheten, även om ingen har frågat om dem. Testa i en staging-miljö som speglar produktion där det är möjligt, och kom i förväg överens om hur testning i produktion ska hanteras om det krävs. Vår tjänst Application Security Review omfattar testning av webbapplikationer och API:er med skriftliga fynd klassade efter allvarlighetsgrad och vägledning för åtgärder; bredare omfattningar med flera miljöer eller nätverk hanteras genom vår tjänst Penetration Testing. I båda fallen bekräftas omfattning, auktorisering och rapportering skriftligt innan arbetet börjar. Efter leverans, åtgärda fynd med hög och kritisk allvarlighetsgrad först, dokumentera beslut om accepterade risker och begär omtest. Dela sedan en ledningssammanfattning eller ett brev om åtgärdsstatus i stället för hela den tekniska rapporten, om inte beställaren specifikt behöver den detaljnivån och har ett säkert sätt att ta emot den.

Application Security Review

Visa tjänstesidan för Application Security Review