“Ya nos hicieron una auditoría de seguridad el año pasado.” Cuando pedimos ver el resultado, muchas veces lo que encontramos es el informe automático de una herramienta de escaneo: cien páginas de avisos sin priorizar que nadie llegó a leer entero.
Eso no es un pentest. Y la diferencia importa, porque cada cosa responde a una pregunta distinta.
Escaneo de vulnerabilidades vs. test de intrusión
- El escaneo de vulnerabilidades es un proceso automático que compara tus sistemas con una base de datos de fallos conocidos. Es rápido, barato y útil para hacerlo con frecuencia, pero genera falsos positivos y no sabe decirte qué es realmente explotable en tu caso.
- El test de intrusión o pentest lo realiza una persona que piensa como un atacante. Parte de lo que encuentran las herramientas, pero va más allá: encadena fallos menores, prueba la lógica de negocio de tus aplicaciones e intenta llegar hasta donde llegaría un atacante real.
El escaneo responde a “¿qué fallos conocidos tengo?”. El pentest responde a “¿qué podría conseguir alguien que quisiera entrar?”. No son excluyentes: lo razonable es escanear a menudo y hacer pentests de forma periódica.
Tipos de pentest
Según la información de partida que se le da al equipo:
- Caja negra: sin información previa, como un atacante externo. Es el escenario más realista, pero también el menos eficiente en tiempo.
- Caja gris: con información parcial, por ejemplo un usuario estándar. Permite comprobar qué podría hacer un empleado descontento o un cliente con una cuenta comprometida.
- Caja blanca: con acceso a documentación, arquitectura e incluso código fuente. Es el que más fallos encuentra por hora invertida.
Y según el objetivo:
- Infraestructura externa: lo que tu empresa expone a Internet (webs, VPN, correo, servicios en la nube).
- Infraestructura interna: qué puede hacer alguien que ya está dentro de la red, por ejemplo tras un phishing con éxito.
- Aplicaciones web y APIs: tu tienda online, tu área de clientes o tu software a medida. El estándar de referencia aquí es OWASP.
- Ingeniería social: campañas de phishing simulado para medir la respuesta de la plantilla.
Qué debe incluir un buen informe
El informe es el producto real de un pentest. Exige como mínimo:
- Un resumen ejecutivo que alguien sin perfil técnico pueda entender: qué riesgo real hay para el negocio.
- Hallazgos priorizados por criticidad, no una lista plana. No es lo mismo una cabecera HTTP que falta que un acceso a la base de datos de clientes.
- Evidencias y pasos para reproducir cada fallo, para que tu equipo técnico pueda verificarlo.
- Recomendaciones concretas de corrección, adaptadas a tu entorno.
- Una nueva comprobación (retest) tras aplicar las correcciones. Un pentest sin retest deja la pregunta más importante sin responder: ¿está arreglado?
Cuándo tiene sentido hacerlo
- De forma periódica, habitualmente una vez al año para los sistemas críticos.
- Antes de lanzar una aplicación nueva o un cambio importante de arquitectura.
- Tras una migración de infraestructura, por ejemplo al cloud.
- Cuando lo exige un cliente o una normativa. Marcos como el ENS o la ISO 27001 piden evaluar de forma periódica la seguridad técnica, y cada vez más contratos B2B incluyen esta exigencia.
Lo que hay que dejar claro antes de empezar
Un pentest serio comienza con un documento de alcance y autorización firmado: qué sistemas se van a probar, en qué horario, qué técnicas están permitidas y a quién avisar si algo se degrada. Atacar sistemas sin autorización expresa es un delito, también cuando la intención es buena, así que desconfía de cualquier proveedor que no te pida este paso.
Conviene además avisar a tu proveedor de hosting o cloud si sus condiciones lo requieren, y tener copias de seguridad recientes antes de empezar.
Si tu infraestructura está en la nube
En AWS, Google Cloud u OVHcloud cambian dos cosas.
La primera, el permiso. AWS permite hacer pruebas de seguridad sobre una lista de sus servicios sin pedir autorización previa, siempre que respetes su política de pruebas. Google Cloud no exige avisarle, pero las pruebas deben cumplir su política de uso aceptable y afectar solo a tus propios recursos. En OVHcloud, revisa sus condiciones antes de empezar. En los tres casos, lo que nunca se puede atacar es la infraestructura del propio proveedor.
La segunda, dónde suelen estar los fallos. En la nube, muchos de los problemas graves no son vulnerabilidades de software, sino errores de configuración: un almacenamiento abierto a internet, un usuario con más permisos de los que necesita, claves de acceso olvidadas en un repositorio o puertos de administración expuestos. Eso no lo encuentra un escaneo externo: aparece al revisar la propia cuenta desde dentro.
El pentest no es el primer paso
Si tu empresa todavía no tiene autenticación multifactor, sistemas actualizados ni copias fiables, un pentest va a confirmar lo que ya sabes. Es más rentable resolver primero lo básico y usar el test de intrusión para encontrar lo que no se ve a simple vista.
Este es un artículo informativo: en Alenia Systems no realizamos pentesting. Lo que sí hacemos, si tu infraestructura está en AWS, Google Cloud u OVHcloud, es una revisión de seguridad de tu cuenta cloud (accesos, exposición a internet, copias, registros y alertas). Si quieres saber por dónde empezar, pide una revisión gratuita.