4.10 Pruebas de penetración y red team

Visión general y motivación

Puede desplegar cada control que exige su modelo de amenazas y seguir sin saber si funcionan de verdad. La documentación afirma que el cortafuegos bloquea ese puerto, la revisión de código dice que las entradas se validan, la política establece que se aplica el principio de mínimo privilegio. La seguridad ofensiva es la forma de averiguar si alguna de esas afirmaciones resiste cuando un atacante motivado empuja con fuerza. Este capítulo trata de atacar deliberadamente los propios sistemas, con autorización, para descubrir las brechas antes de que lo haga un adversario real.

La disciplina se extiende a lo largo de un espectro. En el extremo más ligero se sitúa el escaneo de vulnerabilidades: herramientas automatizadas que buscan fallos y configuraciones erróneas conocidas. En el punto intermedio se ubica la prueba de penetración: un profesional cualificado que encadena debilidades para demostrar la explotabilidad frente a un objetivo definido. En el extremo más extremo se sitúa el red team: una campaña orientada a objetivos que emula a un adversario real a través de personas, procesos y tecnología, y que pone a prueba la capacidad de detección y respuesta, no solo la de prevención. Cada nivel responde a una pregunta distinta, y confundirlos es la forma más habitual en que las organizaciones desperdician presupuesto y se dan una falsa sensación de seguridad.

Este capítulo se sitúa a propósito al margen de sus vecinos. El capítulo 4.4 aborda las operaciones de seguridad: la vertiente defensiva y de monitoreo que vigila amenazas y responde a ellas. Este capítulo es el contrapunto ofensivo que verifica si esa defensa funciona en la práctica. El capítulo 4.9 cubre el ciclo de vida de desarrollo de software seguro, donde la seguridad se integra en el diseño y la entrega del código; la prueba ofensiva valida el producto de ese ciclo desde el exterior. Asimismo, se apoya en los fundamentos y la cultura del capítulo 4.1 y en las prácticas de seguridad de aplicaciones del capítulo 4.2.

En grandes empresas, la prueba ofensiva es a la vez una herramienta de reducción de riesgos y una obligación regulatoria. Los procesadores de pagos, los bancos y los proveedores de atención sanitaria están sujetos a requisitos explícitos de prueba. En el sector público, lo que está en juego alcanza la seguridad nacional y la confianza ciudadana: los adversarios son naciones con recursos ilimitados, y los sistemas que atacan sostienen elecciones, prestaciones y infraestructura crítica. En ambos contextos, el valor no reside en el informe, sino en lo que se remedia y en cuánto más rápido se aprende a detectar la próxima intrusión.

Principios fundamentales

Adaptar el ejercicio a la pregunta: el escaneo, la prueba de penetración y el red team responden a cosas distintas.
Obtener autorización por escrito y unas reglas de intervención claras antes de que nadie toque un sistema.
Los hallazgos no valen nada hasta que se remedian y se reprueban; hay que gestionarlos como cualquier otra tarea.
El red team existe para fortalecer al equipo azul, no para ganar.
Emular a adversarios reales y sus técnicas, no seguir plantillas genéricas.
Medir la detección y la respuesta, no solo el número de vulnerabilidades halladas.
Cuidado con la teatralidad: un ejercicio acotado para «aparecer bien» impresiona pero no demuestra nada.

Recomendaciones

Comprender el espectro de la seguridad ofensiva

Para empezar, hay que nombrar con precisión qué se está contratando. El escaneo de vulnerabilidades es amplio, automatizado y económico; debe ejecutarse de forma continua sobre todo el patrimonio tecnológico para detectar Vulnerabilidades y Exposiciones Comunes (CVE) y configuraciones erróneas. Genera volumen y falsos positivos, y no puede decir si un fallo es realmente explotable en contexto. La prueba de penetración pone a un profesional cualificado frente a un objetivo definido durante una ventana temporal acotada, encadenando debilidades para demostrar el impacto real: ese hallazgo del escáner, combinado con ese permiso excesivo, otorga privilegios de administrador de dominio. Responde a la pregunta «¿se puede romper este elemento concreto, y con qué gravedad?».

El red team responde a una pregunta más amplia: «si un adversario determinado nos tomara como objetivo, ¿lo notaríamos y podríamos detenerlo?». Es orientado a objetivos (exfiltrar este conjunto de datos, acceder a este sistema de control), abarca toda la superficie de ataque, incluidos las personas y el acceso físico, y suele ejecutarse sin avisar a los defensores. El purple team derriba el muro: rojo y azul trabajan juntos en la misma sala, el atacante ejecuta una técnica y el defensor observa si sus herramientas la captan, ajustando las detecciones en tiempo real. El purple team suele ofrecer más mejora defensiva por euro invertido que un red team encubierto, porque cada acción se convierte en una oportunidad de aprendizaje.

Elegir entre caja negra, gris o blanca con deliberación

La cantidad de información que se facilita al tester condiciona lo que se va a aprender. La prueba de caja negra no le entrega nada salvo un objetivo, simula a un atacante externo sin conocimiento interno; es realista pero lenta, y el tester puede gastarse todo el presupuesto en reconocimiento que un adversario real tardaría meses en completar. La prueba de caja blanca le entrega código fuente, diagramas de arquitectura y credenciales, lo que permite al tester profundizar y cubrir mucho terreno en el tiempo disponible. La caja gris se sitúa entre ambas: cierta información, algunas credenciales, simula a un atacante que ha hecho los deberes o a un insider malintencionado.

Para la mayoría de las pruebas de aplicaciones, la caja gris o la caja blanca ofrecen mejor rendimiento, porque se está pagando por profundidad de análisis, no por que el tester redescubra la topología de la red. Reservar la caja negra para cuando el realismo de la fase de descubrimiento sea en sí mismo lo que se quiere medir, como evaluar cuánto puede aprender un externo de la huella pública de la organización. Hay que ser explícito sobre lo que se encarga, ya que un informe de caja negra que revela poco puede significar que la organización está a salvo o que al tester se le acabó el tiempo en la periferia.

Delimitar el alcance y redactar las reglas de intervención

El alcance es donde los ejercicios triunfan o fracasan. Un documento de reglas de intervención define qué está permitido y qué no, qué técnicas se autorizan, la ventana de prueba, los sistemas y redes cubiertos, los requisitos de manejo de datos y los contactos de emergencia de ambos bandos. Nombra los sistemas en producción que están fuera de límites o requieren precauciones especiales, establece una norma para detener la actividad si el tester descubre algo peligrosamente activo, y define qué sucede si topa con actividad de un atacante real o con datos verdaderamente sensibles.

Hay que documentar las vías de escalado y una carta de «salvación»: la autorización que el tester puede exhibir si el personal de seguridad o las fuerzas de orden público lo cuestionan a mitad del ejercicio. Debe acordarse con antelación cómo se almacenan y transmiten los hallazgos, pues un informe de prueba de penetración es un mapa de cómo vulnerar la organización y debe protegerse como tal. Un alcance reducido produce hallazgos profundos en una superficie pequeña; un alcance amplio produce cobertura superficial en una superficie grande. Elegir con intención y nunca permitir que el alcance se amplíe por cuenta propia a mitad de ejercicio sin una reautorización.

Considerar la autorización como la línea entre la prueba y el delito

El único acto que separa a un tester de penetración de un delincuente es la autorización. Acceder a sistemas sin autorización es un delito bajo leyes como el Computer Fraud and Abuse Act en Estados Unidos y sus equivalentes en otros países, y las buenas intenciones no son defensa. La autorización debe llegar por escrito de alguien con la competencia real para otorgarla, cubrir exactamente los sistemas y técnicas en alcance y estar firmada antes de que comience el trabajo.

Los sistemas de terceros complican el asunto. El proveedor de nube, los proveedores SaaS y cualquier infraestructura compartida pueden tener sus propias políticas de prueba, y no se puede autorizar un ataque contra activos que no se poseen. Revisar las normas del proveedor, solicitar permiso donde sea necesario y mantener la prueba dentro de la propia tenencia. El ingeniería social dirigido a empleados plantea cuestiones éticas y legales sobre el consentimiento y el daño psicológico que hay que reflexionar con anticipación. Ante cualquier duda, involucrar al asesor legal: el coste de una conversación es trivial comparado con el coste de un incidente de acceso no autorizado.

Poner en balanza a los equipos internos frente a los testers externos

Un equipo rojo interno conoce el entorno, construye relaciones con los defensores y puede probar de forma continua en lugar de en oleadas anuales. Esa familiaridad es también una limitación: comparte los puntos ciegos y los supuestos organizativos de la propia empresa, y su independencia se cuestiona cuando rinde cuentas ante el mismo liderazgo que los sistemas que prueba. Las firmas externas aportan una mirada fresca, habilidades especializadas y la independencia que auditores y reguladores exigen a menudo, pero se incorporan con lentitud, cuestan más por ejercicio y se van cuando se entrega el informe.

Los programas más maduros usan ambos. Los equipos internos se ocupan de la emulación continua de adversarios, el ajuste de detecciones y el conocimiento profundo del entorno que hace productivo el purple team. Las firmas externas proporcionan una validación periódica e independiente, cumplen los requisitos de independencia de estándares como PCI DSS y exploran las zonas que la propia gente ha dejado de ver. Cualquiera que se elija, hay que exigir que los testers estén cualificados: certificaciones como OSCP (Offensive Security Certified Professional) y experiencia demostrada pesan más que una presentación impecable.

Implementar programas de recompensas y divulgación coordinada

Un programa de recompensas por vulnerabilidades invita a investigadores externos a descubrir y reportar vulnerabilidades a cambio de reconocimiento y pago. Ofrece una prueba continua y diversificada con un abanico de habilidades que nunca se podría contratar por completo, y solo se paga por hallazgos reales. No sustituye a la prueba de penetración estructurada, ya que los investigadores persiguen lo que paga y pueden ignorar categorías enteras, pero es un complemento potente que pone de manifiesto ataques creativos.

Antes de poner en marcha un programa de recompensas, se necesita una política de divulgación coordinada de vulnerabilidades: una forma publicada y fácil de encontrar para que cualquiera pueda reportar un problema de seguridad de manera segura, un compromiso de no perseguir legalmente a los investigadores de buena fe, plazos de respuesta definidos y un proceso interno para triar y remediar lo que llega. Un archivo security.txt y una dirección de reporte clara son el mínimo. Los organismos públicos exigen cada vez más políticas de divulgación de vulnerabilidades en sistemas públicos, y no tener un canal no impide que los investigadores encuentren bugs; solo impide que los comuniquen de forma segura.

Aplicar la brecha asumida y la emulación de adversarios

Probar solo el perímetro supone que el atacante parte del exterior, pero las brechas reales suelen comenzar con una credencial obtenga por phishing o un portátil comprometido que ya está dentro. Un ejercicio de brecha asumida empieza con el tester ya con un punto de entrada, como el acceso de un empleado estándar, y pregunta hasta dónde puede llegar desde ahí. Esto pone a prueba directamente la segmentación interna, la detección y los controles de radio de impacto, en lugar de apostar todo a un perímetro que al fin y al cabo se cruzará. Suele ser un mejor uso del tiempo de un red team que verles fregar un borde endurecido.

Anclar la campaña en el comportamiento real de los adversarios mediante MITRE ATT&CK, una base de conocimiento pública de las tácticas y técnicas que los atacantes emplean de verdad, organizada desde el acceso inicial hasta la exfiltración. La emulación de adversarios elige un actor de amenazas conocido por atacar el sector, reproduce sus técnicas documentadas y verifica si cada paso se detecta y detiene. Esto es mucho más útil que un ataque genérico, porque enfrenta las defensas a los adversarios concretos que la organización enfrenta y genera hallazgos que la inteligencia de amenazas puede priorizar.

Enviar los hallazgos al equipo azul y a la ingeniería de detección

El punto de la ofensiva es una mejor defensa. Cada acción del red team es una oportunidad para preguntar: ¿nuestras herramientas generaron una señal, ¿alguien la vio, y respondieron correctamente? Hay que ejecutar los ejercicios de modo que cada técnica se corresponda con una detección que ya se tiene, que hay que construir o que hay que ajustar. Esto es ingeniería de detección: convertir el comportamiento del atacante en alertas fiables, y es donde el valor del red team se multiplica. Un hallazgo que dice «no nos detectaron durante el movimiento lateral» debe convertirse en una nueva regla de detección, verificada volviendo a ejecutar la técnica.

Los ejercicios de mesa amplían esto a la toma de decisiones. Reunir a las personas que responderían ante un incidente real y recorrer un escenario realista sobre el papel: quién declara el incidente, quién habla con legal, quién decide desconectar un sistema. Los ejercicios de mesa son económicos, revelan lagunas en roles y comunicación que las pruebas técnicas no captan, y preparan a las personas que importan de verdad cuando el capítulo 9.3 de gestión de incidentes pasa a acción. Acoplar el red team técnico con ejercicios de mesa periódicos para que tanto las herramientas como las personas se pongan a prueba.

Trazar la remediación y repruebar

Un informe de vulnerabilidades que nadie ejecuta es un pasivo, porque ahora se ejecuta con conocimiento de causa un fallo que un auditor puede señalar. Cada hallazgo debe integrarse en el sistema de seguimiento de trabajo habitual con un responsable, una severidad y un plazo vinculado al riesgo. Los hallazgos críticos requieren tratamiento de emergencia; los de menor prioridad entran en la lista de pendientes con una prioridad honesta. La métrica que importa es el tiempo de remediación, no el tiempo de informe.

La reprueba cierra el ciclo. Después de que una corrección se despliega, el tester (o una verificación automatizada) confirma que la vulnerabilidad ha desaparecido de verdad y que la corrección no ha abierto un nuevo agujero. Sin reprueba, «remediado» es un deseo, no un hecho, y muchos hallazgos se repiten porque una corrección fue incompleta o una regresión los reintrodujo. Estándares como PCI DSS exigen este ciclo explícitamente. Incluir la reprueba en el contrato del ejercicio para que no sea un postre olvidado.

Compromisos: ventajas e inconvenientes

Enfoque	Ideal para	Ventajas	Inconvenientes
Escaneo de vulnerabilidades	Cobertura continua de fallos conocidos	Barato, amplio, automatizado, frecuente	Ruidoso; no puede probar la explotabilidad
Prueba de penetración	Demostrar el impacto en un objetivo definido	Análisis profundo y humano; cadenas de explotación reales	Puntual; alcance acotado; costosa
Red team	Probar detección y respuesta	Realista; pone a prueba personas y procesos	Costoso; lento; necesita un equipo azul maduro
Purple team	Mejorar detecciones con rapidez	Alto aprendizaje por euro invertido; colaborativo	Menos realista; requiere disponibilidad de ambos equipos
Recompensas por vulnerabilidades	Descubrimiento continuo y diversificado	Pago por hallazgo; habilidades variadas	Cobertura desigual; carga de triaje; necesita proceso

La tensión central es entre realismo y velocidad de aprendizaje. Un red team encubierto es la prueba más realista que existe, pero sus lecciones llegan despacio y solo al término de una campaña completa, y un equipo azul inmaduro aprende poco al ser derrotado en silencio. El purple team sacrifica la sorpresa para maximizar la velocidad con la que los defensores mejoran. Una segunda tensión es entre amplitud y profundidad: el escaneo cubre todo en superficie, mientras que una prueba de penetración cubre una fracción en profundidad. Los programas maduros superponen estos niveles en lugar de elegir uno, ejecutando escaneo continuo bajo pruebas profundas periódicas y campañas ocasionales de red team a pleno alcance. El error es contratar una única prueba de penetración anual, archivar el informe y dar el problema por resuelto.

Cuestiones para debatir con el equipo

Cuando se contrata una prueba ofensiva, ¿está claro qué pregunta se está formulando realmente, y el ejercicio responde a ella? Muchas organizaciones contratan una «prueba de penetración» y reciben un escaneo de vulnerabilidades con un resumen redactado por un humano, y creen haber probado sus defensas cuando solo han revisado fallos conocidos. Otras encargan un red team cuando su capacidad de detección es tan inmadura que el ejercicio solo confirma lo que todos ya sabían. Reunir los tres últimos alcances de ejercicio y los informes resultantes, y preguntar si cada uno respondió a la pregunta que necesitaba responderse: cobertura de vulnerabilidades conocidas, explotabilidad de un objetivo concreto, o capacidad de detectar y responder a una intrusión. La respuesta debe guiar una combinación deliberada de escaneo, prueba de penetración y red o purple team adaptada al nivel de madurez.
¿Qué ocurre con un hallazgo después de que llega el informe, y cómo se demostraría que fue corregido? El valor de la seguridad ofensiva reside enteramente en la remediación, y sin embargo muchos programas miden el éxito por el tamaño del informe en lugar de la reducción del riesgo. Rastrear un hallazgo real del último ejercicio: quién fue el responsable, cómo se priorizó frente al trabajo de desarrollo, cuándo se corrigió y si alguien confirmó que la corrección funcionó. Si no se puede producir ese rastro, la prueba está generando conocimiento que no se está ejecutando, lo cual es peor que no saber, porque ahora se está expuesto con pleno conocimiento. El resultado de esta discusión debe ser un flujo de trabajo de remediación trazable con responsables, plazos basados en el riesgo y reprueba obligatoria en cada contrato.
¿El red team está fortaleciendo al equipo azul o simplemente está haciendo la cuenta? Un equipo rojo que celebra victorias sin detección y guarda sus técnicas bajo llave es entretenido e inútil. La relación debe ser colaborativa bajo la superficie adversarial: cada técnica que pase sin detectarse debe convertirse en una nueva regla de detección, cada camino exitoso debe informar la segmentación, y ambos equipos deben hacer balance conjunto. Preguntar a los defensores qué aprendieron del último ejercicio con el red team y si algún control o detección cambió como resultado. Si la respuesta honesta es nada, se está pagando por teatralidad, y conviene orientarse hacia el purple team y la emulación de adversarios atada explícitamente a la ingeniería de detección.
Antes del próximo ejercicio, ¿hay autorización por escrito para cada activo en alcance, incluidos los que no son propiedad de la organización? La autorización es la línea entre una prueba de penetración y un incidente de ciberdelito, y en una organización grande los sistemas a los que el tester va a tocar rara vez caben dentro de un único ámbito de propiedad: abarcan tenencias en la nube, plataformas SaaS, redes gestionadas e infraestructura compartida que un socio o proveedor controla. La presión contraria es la velocidad, porque perseguir permisos firmados y políticas de prueba del proveedor es lento y resulta tentador saltarse cuando se acerca un plazo. Traer el borrador de las reglas de intervención, el inventario de activos con un responsable asignado a cada sistema, las políticas de prueba relevantes de la nube y los proveedores, y la carta de autorización firmada que el tester puede exhibir si lo cuestionan a mitad de ejercicio. En entornos de empresa y sector público la exposición es aguda: una sonda no autorizada contra una plataforma compartida puede incumplir contratos, activar notificaciones regulatorias o, para un organismo público, convertirse en un titular sobre el gobierno atacando sistemas que no tenía derecho a tocar, de modo que el asesor legal debe avalar antes de que nadie comience.
¿Se está invirtiendo en un red team interno, en firmas externas o en ambos, y esa distribución se ajusta a lo que se necesita de verdad? Es una decisión de construir o contratar con consecuencias reales en dinero y a varios años: un equipo interno cuesta salarios y herramientas y ofrece emulación continua de adversarios y conocimiento profundo del entorno, mientras que las firmas externas cuestan más por ejercicio pero traen una mirada fresca, habilidades especializadas y la independencia que auditores y reguladores exigen. La tensión es que cada uno cubre el punto ciego del otro, de modo que tratarlos como sustitutos en lugar de complementos suele dejar un vacío. Traer el gasto actual en cada uno, las certificaciones y el historial demostrable de las personas que hacen el trabajo, la cadencia de los ejercicios y los requisitos de independencia que los estándares imponen. En una empresa regulada, PCI DSS y regímenes similares pueden exigir pruebas externas e independientes independientemente de lo bueno que sea el equipo interno; en el sector público, las normas de contratación y la necesidad de mostrar una evaluación a distancia antes de una autorización de operación suelen hacer que un tercero acreditado sea obligatorio, no opcional.
¿Existe un canal seguro para que los investigadores externos reporten vulnerabilidades, y hay preparación para gestionar lo que llega? Una organización grande y con presencia pública ya está siendo explorada por investigadores se lo invite o no, y la única pregunta es si pueden comunicárselo de forma segura o si se ven obligados a publicar o vender lo que encuentran. La consideración contraria es la preparación: abrir una política de divulgación coordinada o un programa de recompensas genera informes entrantes y una carga de triaje, y un programa que paga por hallazgos que nunca remedia es peor que no tener ninguno. Traer el archivo security.txt y la dirección de reporte que exista, el proceso de recepción y triaje, los plazos de respuesta que se pueden cumplir con honestidad y la capacidad de backlog para remediar lo que llegue. Para los organismos públicos, una política de divulgación de vulnerabilidades en sistemas públicos es cada vez más una directriz que una cortesía, y para las empresas un programa de recompensas bien gestionado es a la vez una fuente de hallazgos creativos y una muestra de madurez durante la diligencia debida de los clientes, de modo que la decisión es menos si se tiene un canal que si hay personal para honrarlo.

Perspectiva sectorial

Startup. No se puede costear un red team interno, así que hay que superponer coberturas económicas. Integrar el escaneo de vulnerabilidades en el pipeline de despliegue para captar fallos de dependencias conocidas en cada compilación, publicar un archivo security.txt y una política simple de divulgación coordinada para que los investigadores puedan llegar, y encargar una única prueba de penetración en caja gris a una firma reputada antes del primer acuerdo empresarial, rastreando cada hallazgo hasta su cierre. La velocidad importa más que un programa amplio: elegir la prueba que desbloquea una venta o cierra el mayor riesgo y postergar el resto hasta crecer.

Pyme. Sin especialista en seguridad en plantilla y con un presupuesto ajustado, hay que contratar en lugar de construir. Usar un servicio de escaneo gestionado y contratar a una firma externa de pruebas de penetración con una cadencia modesta en lugar de montar ninguna capacidad propia, y asegurarse de que el contrato incluye la reprueba para que «arreglado» se demuestre y no se suponga. La medida de mayor valor y menor coste es publicar una forma de que cualquiera reporte un fallo y aplicar la disciplina de parchear con rapidez, ya que la mayoría de las compromisos reales de una empresa de ese tamaño ocurren a través de vulnerabilidades conocidas y sin parchear.

Gran empresa. A gran escala, el reto es gobernar a través de muchos equipos. Ejecutar escaneo continuo bajo pruebas de penetración externas independientes periódicas que satisfagan estándares como PCI DSS, mantener un red team interno para la emulación continua de adversarios y el purple team, y gestionar la remediación como un portfolio trazable con responsables, plazos basados en el riesgo y reprueba obligatoria. Enviar cada técnica sin detectar a la ingeniería de detección, y producir la evidencia de auditoría, la cobertura, los plazos y las tasas de cierre que la cumplimiento y el consejo de administración esperan.

Sector público. Las reglas de contratación, la transparencia y la rendición de cuentas pública condicionan todo el programa. Mantener una política de divulgación de vulnerabilidades en todos los sistemas públicos, como las directrices cada vez más exigen, dando a los investigadores un canal seguro para reportar fallos. Emplear evaluadores independientes acreditados para las pruebas de penetración que condicionan la autorización de operación de un sistema, y el monitoreo continuo incluye escaneo permanente. Ejecutar emulación de adversarios modelada en los grupos de amenazas concretos que sus socios de inteligencia señalan, y realizar ejercicios de mesa periódicos que ensayen la respuesta a incidentes y la coordinación legal que una brecha real exigiría. Los hallazgos alimentan un programa de remediación formal con plazos obligatorios, y la reprueba es un requisito previo para mantener la autorización de operación de cualquier sistema.

Ejemplos

Startup. Un fintech de veinte personas no puede costear un red team interno, así que superpone lo que puede. El escaneo automatizado de vulnerabilidades se ejecuta en cada despliegue a través de su pipeline, capturando fallos de dependencias conocidas de forma temprana. Publica un archivo security.txt y una política simple de divulgación coordinada, y una vez que el producto se estabiliza, abre un programa de recompensas modesto en una plataforma pública, pagando a investigadores reales por bugs reales. Antes de firmar su primer cliente empresarial, encarga una prueba de penetración en caja gris de la aplicación a una firma reputada, rastrea cada hallazgo hasta su cierre en su rastreador de incidencias habitual y paga una reprueba para confirmar las correcciones. Este enfoque superpuesto ofrece una cobertura de seguridad creíble a un coste que la startup puede sostener, y el informe de prueba de penetración se convierte en una evidencia que puede compartir durante la diligencia debida de los clientes.

Gran empresa. Una cadena de distribución internacional que procesa pagos con tarjeta debe cumplir PCI DSS, que exige tanto pruebas de penetración internas como externas al menos una vez al año y tras cambios significativos, además de pruebas de segmentación para demostrar que el entorno de datos del titular está aislado. Ejecuta escaneo continuo sobre miles de activos, encarga pruebas de penetración externas independientes para satisfacer el estándar, y mantiene un red team interno que realiza ejercicios de brecha asumida anclados en MITRE ATT&CK frente a actores de amenazas conocidos por atacar al sector retail. El red team trabaja estrechamente con la función de operaciones de seguridad del capítulo 4.4: cada técnica sin detectar se convierte en un ticket de ingeniería de detección, y sesiones trimestrales de purple team ajustan las alertas. La remediación se rastrea con plazos basados en el riesgo, y todo el programa produce la evidencia de auditoría que el capítulo 4.6 de cumplimiento requiere.

Sector público. Un organismo nacional que gestiona sistemas de prestaciones ciudadanas enfrenta a adversarios estatales y un mandato público de proteger datos personales sensibles. Mantiene una política de divulgación de vulnerabilidades en todos los sistemas públicos, como las directrices gubernamentales cada vez más exigen, dando a los investigadores un canal seguro para reportar fallos. Evaluadores independientes de terceros realizan pruebas de penetración como parte del proceso de autorización antes de que cualquier sistema entre en servicio, y el monitoreo continuo incluye escaneo permanente. El organismo ejecuta emulación de adversarios modelada en los grupos de amenazas concretos que sus socios de inteligencia señalan, y ejercicios de mesa periódicos ensayan la respuesta a incidentes y la coordinación legal que una brecha real exigiría. Los hallazgos alimentan un programa formal de remediación con plazos obligatorios, y la reprueba es un requisito previo para mantener la autorización de operación de un sistema.

Argumento de negocio: motivaciones, retorno de inversión y coste total de propiedad

El retorno de la seguridad ofensiva es la brecha que no se sufrió. Una brecha de datos grave cuesta millones en respuesta directa, multas regulatorias, responsabilidad legal, fuga de clientes y daño reputacional, y el factor más costoso de todos es cuánto tiempo pasa una intrusión sin detectarse. El red team y el purple team atacan esa cifra directamente reduciendo la distancia entre la compromisión y la detección. Una prueba de penetración que descubre un camino explotable hacia la base de datos de clientes y se corrige antes de que un atacante lo encuentre, financia todo el programa muchas veces en un solo incidente evitado.

Hay además impulsos concretos. PCI DSS exige pruebas de penetración a cualquiera que maneje datos de tarjetas. Marcos y regímenes de autorización del sector público exigen evaluación independiente antes y durante la operación. Los clientes corporativos exigen informes de prueba de penetración recientes como condición de los contratos. En estos casos la prueba no es opcional, y la pregunta es solo si se extrae valor de seguridad real del dinero que de todos modos se debe gastar.

El coste total de propiedad incluye más que la tarifa del ejercicio. Presupuestar la herramienta y el personal de un equipo interno si se construye uno, la carga de triaje de un programa de recompensas y, sobre todo, el trabajo de remediación que los hallazgos generan, que es donde realmente cae el gasto. Un programa que encarga pruebas pero infradotacion de correcciones es lo peor de ambos mundos: paga por la mala noticia y luego paga de nuevo cuando el hallazgo ignorado es explotado. Para presentar el caso a la dirección, conectar la prueba con métricas que ellos siguen: tiempo medio de detección, tiempo medio de remediación, hallazgos de auditoría cerrados y la reducción de riesgo en los activos más críticos.

Antipatrones y trampas

Rebautizar el escaneo: vender un escaneo de vulnerabilidades como prueba de penetración, entregando la salida de una herramienta sin validación humana ni encadenamiento de explotación.
Informe y olvido: tratar el entregable como el objetivo, archivar los hallazgos y no rastrear remediación ni reprueba.
Acotar para pasar: estrechar el ejercicio de modo que los sistemas con mayor probabilidad de fallar estén convenientemente fuera de alcance, produciendo un informe limpio que no significa nada.
Red team como marcador: un equipo adversario que guarda técnicas y celebra victorias en lugar de mejorar a los defensores.
Probar un equipo azul inmaduro a la oculta: ejecutar un red team encubierto antes de tener cualquier capacidad de detección, de modo que el ejercicio solo confirma lo que ya se sabía.
Sin autorización o alcance vago: iniciar el trabajo sin permiso por escrito o dejar que el alcance se infiltre en sistemas que no son propios, buscando un desastre legal.
Obsesión con el perímetro: probar solo el borde externo e ignorar la realidad de la brecha asumida de que los atacantes empiezan por dentro.
Ignorar el canal de divulgación: no tener una forma segura de que los investigadores externos reporten bugs, de modo que los publiquen abiertamente o los vendan.
Métricas de teatralidad: contar vulnerabilidades halladas en lugar de riesgo reducido, detección mejorada y tiempo de remediación acortado.

Modelo de madurez

Nivel 1, Iniciar: La prueba es ocasional y reactiva, a menudo una única prueba de penetración anual para marcar una casilla, o desencadenada solo tras un incidente. Los informes se archivan con poca seguimiento, la remediación no se rastrea, no hay canal de divulgación y la detección de una intrusión real no se ha probado y probablemente es inexistente.
Nivel 2, Desarrollar: El escaneo de vulnerabilidades y las pruebas de penetración existen pero son inconsistentes entre equipos, con algunos grupos escaneando de forma continua y otros nada. Los hallazgos se recogen en algún sitio, aunque los responsables y plazos son irregulares, la reprueba es esporádica y un canal de divulgación coordinada puede existir para algunos sistemas pero no para todo el patrimonio.
Nivel 3, Estandarizar: La prueba ofensiva es un programa documentado y aplicado en toda la organización, no un evento. El escaneo se ejecuta de forma continua bajo pruebas de penetración programadas con una cadencia definida y tras cambios importantes, las reglas de intervención y la autorización son práctica estándar, cada hallazgo se rastrea hasta su cierre con un responsable y un plazo basado en el riesgo, la reprueba es obligatoria y una política de divulgación coordinada cubre todos los sistemas públicos.
Nivel 4, Gestionar: El programa se mide y controla contra líneas de base. Se rastrea el tiempo medio de detección y el tiempo medio de remediación, el porcentaje de técnicas del red team que generaron una señal, la cobertura de detección frente a las técnicas de MITRE ATT&CK relevantes para el sector, las tasas de recurrencia de hallazgos y los tiempos de respuesta ante la divulgación, y cada métrica se sostiene frente a una meta y se actúa cuando se desvía. Los ejercicios de brecha asumida y la emulación de adversarios son habituales, un red team opera de forma continua, los hallazgos alimentan la ingeniería de detección y las decisiones de continuidad se basan en evidencia, no en opinión.
Nivel 5, Orquestar: El red team y el purple team están integrados en toda la organización y son adaptativos. Cada técnica se corresponde con una detección probada, la emulación de adversarios sigue a los actores de amenazas que actualmente atacan el sector a medida que la inteligencia cambia, y el programa refina continuamente su alcance, sus técnicas y sus métricas a medida que aprende. La prueba ofensiva, las operaciones de seguridad, la ingeniería de detección y la respuesta a incidentes operan como un único bucle que reduce de forma medible la brecha entre la compromisión y la detección con el tiempo.

Propuestas de debate

Si un atacante real obtuviera un punto de acceso como empleado estándar hoy, ¿hasta dónde podría llegar antes de que alguien lo notara, y cómo se lo sabría?
¿Cuáles de los últimos ejercicios fueron genuinamente realistas y cuáles se acotaron de modo que los fallos probables quedaban convenientemente fuera de alcance?
¿Cuántos hallazgos de la prueba anterior siguen abiertos, y qué dice eso sobre si el cuello de botella es la prueba o la remediación?
¿Tienen los investigadores externos una forma segura y evidente de reportar una vulnerabilidad, y qué ocurre cuando un informe llega?
¿Cuándo hicieron los respondedores a incidentes el último ejercicio de mesa ante una brecha, y reveló lagunas que las pruebas técnicas no captaron?
¿Se están midiendo vulnerabilidades halladas, o se están midiendo la detección mejorada y el riesgo reducido?

Ideas clave

La seguridad ofensiva es un espectro: el escaneo detecta fallos conocidos, la prueba de penetración demuestra la explotabilidad y el red team pone a prueba la detección y la respuesta. Adaptar el ejercicio a la pregunta.
La autorización por escrito y las reglas de intervención claras son la línea entre la prueba de seguridad y el delito; nunca saltárselas, sobre todo en sistemas que no se poseen por completo.
El valor está en la remediación y la reprueba, no en el informe. Rastrear cada hallazgo con un responsable, un plazo basado en el riesgo y una corrección confirmada.
El red team existe para fortalecer al equipo azul. Enviar los hallazgos a la ingeniería de detección, priorizar el purple team y los ejercicios de brecha asumida, y anclar las campañas en técnicas reales de adversarios mediante MITRE ATT&CK.
Medir la detección y la respuesta, no solo los conteos de vulnerabilidades, y desconfiar de los ejercicios acotados para pasar, que producen comodidad sin seguridad.

Referencias y lectura complementaria

Georgia Weidman, Penetration Testing: A Hands-On Introduction to Hacking
Peter Kim, The Hacker Playbook 3: Practical Guide to Penetration Testing
Jim O’Gorman, Devon Kearns y Mati Aharoni, Metasploit: The Penetration Tester’s Guide
Joe Vest y James Tubberville, Red Team Development and Operations: A Practical Guide
MITRE, marco y base de conocimiento MITRE ATT&CK
Payment Card Industry Security Standards Council, PCI DSS Requirements and Testing Procedures y Penetration Testing Guidance
National Institute of Standards and Technology, NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
Dafydd Stuttard y Marcus Pinto, The Web Application Hacker’s Handbook