Qué es VAPT: evaluación de vulnerabilidades y pentesting

En la India, “VAPT” es el término habitual para referirse a las pruebas de seguridad. Clientes, socios, auditores y contrapartes reguladas suelen solicitar un “informe VAPT” antes de firmar un contrato, conectar una integración o aprobar un lanzamiento. El término combina dos actividades: la evaluación de vulnerabilidades, que busca de forma amplia debilidades conocidas, y la prueba de penetración, que examina en profundidad si esas debilidades pueden aprovecharse. Esta guía explica qué suele abarcar un proyecto VAPT, cómo definir su alcance de forma sensata y qué comprobar antes de compartir el resultado.

Lo que es

La parte de evaluación de vulnerabilidades (VA) es amplia. Combina el escaneo automatizado con la revisión para identificar parches faltantes, componentes desactualizados, servicios expuestos, configuraciones débiles y problemas web comunes en los activos acordados. La parte de prueba de penetración (PT) es profunda. Un evaluador trabaja manualmente sobre objetivos seleccionados, normalmente aplicaciones web, API y aplicaciones móviles, validando hallazgos y probando la autenticación, la gestión de sesiones, el control de acceso entre roles, la exposición de datos y la lógica de negocio. En conjunto, la VA aporta cobertura y la PT aporta confianza sobre lo que es realmente explotable. Un proyecto VAPT debe concluir con un informe escrito que recoja el alcance, el método, los hallazgos clasificados por severidad con evidencia, la orientación de remediación y, cuando se acuerde, el resultado de una nueva prueba tras las correcciones. A veces las solicitudes hacen referencia a marcos como el OWASP Top 10 o la guía OWASP Mobile Application Security; son puntos de referencia útiles sobre lo que examinan los evaluadores.

Para quién es

VAPT suele ser solicitado por o para:

Equipos de SaaS, fintech y comercio electrónico cuyos clientes corporativos piden un informe VAPT reciente durante el proceso de compra
Empresas que se conectan con un socio, banco o proveedor de pagos que exige evidencia de pruebas de seguridad antes de la integración
Equipos de producto que preparan el lanzamiento público de una aplicación web o móvil
Organizaciones que han cambiado su alojamiento, su autenticación o sus flujos de pago y quieren una verificación independiente

Qué ayuda a aclarar

Un VAPT con un alcance bien definido ayuda a aclarar:

Qué aplicaciones, API y entornos espera realmente el solicitante que se prueben
Si el requisito menciona un tipo concreto de auditor o acreditación que debe confirmarse antes de elegir un proveedor
Qué hallazgos son riesgos validados y cuáles son observaciones del escáner
Qué remediación debe realizarse antes de poder compartir un informe con confianza

Qué se incluye

Obtenga por escrito el requisito exacto del solicitante: activos, profundidad, formato del informe y cualquier criterio sobre el proveedor
Enumere los objetivos: dominios, URL de las aplicaciones, rutas base de las API, compilaciones de las aplicaciones móviles y entornos (preproducción o producción)
Prepare cuentas de prueba para cada rol de usuario, de modo que las pruebas de control de acceso sean significativas
Confirme la autorización por escrito, la ventana de prueba, los contactos designados y las condiciones de detención
Informe a los proveedores de alojamiento, CDN o WAF si sus condiciones lo exigen
Acuerde las clasificaciones de severidad, el formato del informe y cómo se compartirá la evidencia
Reserve tiempo para corregir los hallazgos y solicite una nueva prueba de los problemas acordados

Qué no se incluye

Una declaración de que un VAPT hace que una aplicación sea segura o cumpla la normativa
Afirmar que un proveedor cumple un requisito concreto de acreditación o de inclusión en un panel sin contrastarlo con ese requisito
Pruebas de sistemas de terceros sin el permiso de su propietario
Asesoramiento legal o regulatorio sobre lo que exige una norma concreta

Cuándo elegirlo

Encargue un VAPT cuando una contraparte concreta lo solicite, antes de un lanzamiento significativo o después de cambios importantes en la forma en que los usuarios inician sesión, pagan o acceden a los datos. Si la solicitud proviene de una relación regulada, lea el requisito con atención: algunos especifican un auditor acreditado o incluido en un panel (en la India, algunos reguladores y contrapartes hacen referencia a auditores incluidos en el panel de CERT-In), un alcance concreto o un ciclo de pruebas fijo. Confirme primero esos detalles con el solicitante, ya que un informe que no se ajuste al requisito puede tener que repetirse. Este artículo es información general, no asesoramiento legal ni regulatorio.

Nuestro enfoque

Tome la lista de verificación del solicitante como punto de partida y añada después los sistemas que concentran más riesgo para su negocio, aunque nadie haya preguntado por ellos. Realice las pruebas en un entorno de preproducción que refleje la producción siempre que sea posible, y acuerde de antemano cómo se gestionarán las pruebas en producción si fueran necesarias. Nuestro servicio Application Security Review abarca pruebas de aplicaciones web y API con hallazgos escritos clasificados por severidad y orientación de remediación; los alcances más amplios, con varios entornos o de red, se gestionan mediante nuestro servicio Penetration Testing. En ambos casos, el alcance, la autorización y el informe se confirman por escrito antes de comenzar el trabajo. Tras la entrega, corrija primero los hallazgos de severidad alta y crítica, registre las decisiones sobre los riesgos aceptados y solicite una nueva prueba. Después, comparta un resumen ejecutivo o una carta sobre el estado de la remediación en lugar del informe técnico completo, salvo que el solicitante necesite específicamente ese nivel de detalle y disponga de un medio seguro para recibirlo.

Application Security Review

Ver la página del servicio Application Security Review