La única forma fiable de saber si una defensa aguanta es atacarla. Las pruebas de seguridad ofensivas —pentesting y red teaming— hacen exactamente eso: contratan a profesionales para que vulneren los sistemas de una organización con su permiso, antes de que lo haga un adversario real sin él. Aunque a menudo se usan como sinónimos, son disciplinas distintas con objetivos, alcance y profundidad diferentes. Este artículo aclara esa diferencia, recorre las fases de un test de intrusión, repasa las metodologías estándar y aborda el marco legal que separa una prueba autorizada de un delito informático.
Pentesting frente a red teaming: dos objetivos distintos
Un test de intrusión (pentest) busca encontrar y demostrar la mayor cantidad posible de vulnerabilidades en un alcance acotado —una aplicación web, un rango de red, una API— dentro de una ventana de tiempo definida. Su métrica de éxito es la cobertura: cuantos más hallazgos válidos y bien documentados, mejor. El equipo defensor (blue team) normalmente sabe que la prueba se está realizando.
Un ejercicio de red teaming, en cambio, no busca cobertura sino realismo. Simula a un adversario concreto con un objetivo concreto —por ejemplo, exfiltrar la base de datos de clientes o comprometer el dominio de Active Directory— y mide la capacidad real de detección y respuesta de la organización. El sigilo es esencial: el blue team suele desconocer el ejercicio, lo que permite evaluar de verdad sus controles. La diferencia se resume así: el pentest pregunta «¿qué fallos tengo?»; el red team pregunta «¿me daría cuenta si me atacaran?».
| Criterio | Pentest | Red Team |
|---|---|---|
| Objetivo | Máxima cobertura de vulnerabilidades | Cumplir un objetivo concreto como un adversario |
| Alcance | Acotado y conocido | Amplio, a menudo toda la organización |
| Conocimiento del blue team | Habitualmente informado | No informado (sigilo) |
| Duración | Días a semanas | Semanas a meses |
| Mide | Superficie de vulnerabilidad | Capacidad de detección y respuesta |
Existe además el purple teaming, donde rojo y azul colaboran en tiempo real para que cada técnica ofensiva mejore inmediatamente una capacidad defensiva.
Las fases de un test de intrusión
Las metodologías reconocidas —el OWASP Web Security Testing Guide, el PTES (Penetration Testing Execution Standard) y el marco de pruebas técnicas del NIST SP 800-115— coinciden en una secuencia esencial:
- Reconocimiento: recopilación de información sobre el objetivo, pasiva (OSINT, registros públicos, DNS) y activa (escaneo de puertos con Nmap, fingerprinting de servicios).
- Análisis de vulnerabilidades: identificación de debilidades mediante escáneres automáticos y verificación manual. El escáner genera hipótesis; el analista confirma cuáles son reales.
- Explotación: aprovechar una vulnerabilidad para obtener acceso. Aquí se demuestra el impacto real, no solo el potencial.
- Post-explotación: escalada de privilegios, movimiento lateral y persistencia. Responde a la pregunta «una vez dentro, ¿hasta dónde llego?».
- Reporte: la fase más importante y la más descuidada. Sin un informe accionable, todo lo anterior no sirve.
Clasificación del riesgo y herramientas
Cada hallazgo debe puntuarse con un criterio objetivo. El estándar de facto es CVSS (Common Vulnerability Scoring System), que asigna una puntuación de 0 a 10 según vectores de explotabilidad e impacto, traducible a categorías de crítico a bajo. Las vulnerabilidades conocidas se identifican por su CVE (Common Vulnerabilities and Exposures), y las clases de debilidad por su CWE. Para priorizar qué corregir primero, el catálogo de vulnerabilidades explotadas activamente (KEV) de la agencia estadounidense CISA indica cuáles se están usando en ataques reales, lo que pesa más que la puntuación teórica.
El instrumental habitual incluye Nmap para el descubrimiento de red, Burp Suite para pruebas de aplicaciones web, Metasploit como marco de explotación, y Cobalt Strike o Sliver para simulación de adversarios en ejercicios de red team. Las tácticas observadas se mapean contra MITRE ATT&CK, el catálogo de comportamientos de atacantes que sirve de lenguaje común entre ofensiva y defensa.
Las vulnerabilidades que más aparecen
Aunque cada entorno es distinto, ciertas clases de debilidad reaparecen en la mayoría de las pruebas de aplicaciones web. El OWASP Top Ten las ordena por prevalencia e impacto, y conviene conocerlas porque son el primer lugar donde mira tanto un evaluador como un atacante real:
- Control de acceso roto: usuarios que acceden a recursos o funciones que no les corresponden, por ejemplo cambiando un identificador en la URL para ver datos de otro cliente (referencia directa insegura a objetos). Es la categoría más extendida.
- Fallos criptográficos: datos sensibles transmitidos o almacenados sin cifrado adecuado, o con algoritmos obsoletos.
- Inyección: SQL, comandos del sistema operativo o LDAP, donde entrada no validada se ejecuta como código. Sigue presente décadas después de su descubrimiento.
- Diseño inseguro: fallos que nacen de decisiones de arquitectura, no de errores de implementación, y que ninguna corrección puntual resuelve.
- Configuración de seguridad incorrecta: servicios con credenciales por defecto, permisos excesivos o mensajes de error que revelan información interna.
Una observación recurrente en los informes serios es que las vulnerabilidades de lógica de negocio —flujos que permiten, por ejemplo, aplicar un descuento dos veces o saltarse un paso de validación de pago— son las más valiosas y las que ninguna herramienta automática detecta, porque requieren entender qué debería hacer la aplicación, no solo qué hace. Ahí reside la diferencia entre un escaneo y un test de intrusión real ejecutado por un profesional.
El informe: donde reside el valor
Un buen informe se estructura en dos planos. El resumen ejecutivo, sin jerga, comunica el riesgo de negocio a la dirección: qué podría perder la organización y con qué probabilidad. El detalle técnico documenta cada hallazgo con su descripción, evidencia reproducible (capturas, peticiones, pasos exactos), puntuación CVSS, impacto y, sobre todo, una recomendación de remediación concreta. Un hallazgo sin pasos de reproducción ni guía de corrección es ruido. La calidad de un pentest se juzga por la utilidad de su informe, no por el número de vulnerabilidades listadas.
Errores comunes
El primero es confiar solo en el escáner automático: las herramientas generan falsos positivos abundantes y, peor aún, falsos negativos en lógica de negocio que ninguna máquina detecta. El segundo es no definir el alcance por escrito, lo que deriva en pruebas sobre activos no autorizados —un problema legal serio—. El tercero es entregar un volcado del escáner como informe, sin priorización ni contexto de negocio. El cuarto es tratar el pentest como un trámite anual de cumplimiento en lugar de integrarlo en el ciclo de desarrollo; un test puntual fotografía un instante, mientras que las amenazas son continuas. El quinto, en red team, es romper el sigilo por descuido y contaminar la evaluación de detección.
Marco legal: la autorización lo es todo
La frontera entre una prueba de seguridad legítima y un delito es un único documento: la autorización escrita. En España, el acceso no consentido a sistemas informáticos está tipificado en el Código Penal (artículo 197 bis y concordantes), de modo que sin un contrato que defina alcance, ventana temporal, activos incluidos y excluidos, y una cláusula de «get out of jail» que ampare al evaluador, cualquier prueba ofensiva es ilegal. Las reglas de enganche (Rules of Engagement) deben fijar qué técnicas están prohibidas —típicamente la denegación de servicio y la ingeniería social agresiva salvo pacto explícito— y a quién avisar si se detecta un compromiso preexistente. Cuando las pruebas tocan datos personales, se aplica además el RGPD, y conviene alinear el proceso con normas de gestión de seguridad como las de ISO/IEC 27001, que contempla las pruebas técnicas como un control de verificación.
Preguntas frecuentes
¿Con qué frecuencia debo hacer un pentest?
Como mínimo anualmente y tras cualquier cambio significativo en la arquitectura o en una aplicación crítica. Muchos marcos de cumplimiento lo exigen, pero la lógica de seguridad pide integrarlo de forma continua, no solo una vez al año.
¿Un pentest garantiza que mi sistema es seguro?
No. Demuestra que ciertas vulnerabilidades existen, no que no existan otras. La ausencia de hallazgos en un alcance acotado no equivale a seguridad absoluta.
¿Caja negra, gris o blanca?
En caja negra el evaluador no recibe información previa (simula a un externo); en caja blanca tiene acceso completo al código y la arquitectura (maximiza cobertura); la caja gris es un punto intermedio. Para la mayoría de aplicaciones, la caja gris ofrece el mejor equilibrio entre realismo y eficiencia.
¿Puedo hacer pentesting de servicios en la nube?
Sí, pero los grandes proveedores tienen políticas específicas sobre qué se permite probar y qué requiere notificación previa. Revisar esas reglas es obligatorio antes de empezar.
Conclusión
Pentesting y red teaming no son la misma herramienta con dos nombres: el primero inventaría tus debilidades, el segundo pone a prueba si te enterarías de un ataque real. Elegir mal entre ambos desperdicia presupuesto —un red team para una aplicación recién lanzada es excesivo, y un pentest acotado no revela si tu SOC detecta una intrusión sigilosa—. El valor de cualquiera de los dos no está en la fase de explotación espectacular, sino en un informe que la dirección entiende y que el equipo técnico puede ejecutar, y en una autorización escrita que mantiene todo el ejercicio dentro de la legalidad. En Summum Sistemas planteamos las pruebas ofensivas como parte de un ciclo continuo de mejora, con reglas de enganche claras y entregables accionables, porque una vulnerabilidad encontrada por nosotros es una crisis que tu organización no vivirá.