📚 1️⃣ EXPLICACIÓN EN PROFUNDIDAD

Imagina que estás en una fortaleza mágica que tiene puertas de seguridad automatizadas que se abren o se cierran según lo que ocurra en su sistema interno. Estas puertas pueden fallar si hay un apagón, un cortocircuito, un hechizo mal lanzado (😉), o incluso un ataque cibernético.

Ese fallo puede hacer que el sistema decida:

• Abrirse (Fail-Open): priorizando que la gente siga entrando y saliendo.

• Cerrar todo (Fail-Close): priorizando que nadie más entre, ni siquiera los buenos.

🔓 ¿Qué es Fail-Open?

Fail-Open significa que si el dispositivo falla, entonces se abre el flujo de datos. En otras palabras:

• Si el firewall, proxy o sistema de autenticación deja de funcionar, permite todo el tráfico sin filtrado.

• Prioriza la disponibilidad del servicio o red.

• Se usa en situaciones donde cortar el servicio sería más dañino que dejarlo expuesto.

🔸 Ejemplo real: Un hospital. Si un firewall que filtra el acceso a los historiales médicos falla, en modo fail-open los doctores aún pueden acceder, aunque sin filtrado.
🛑 Pero también un atacante podría aprovechar ese fallo para entrar sin ser bloqueado.

🔒 ¿Qué es Fail-Close?

Fail-Close significa que si el sistema falla, bloquea todo:

• Corta la red.

• Detiene el tráfico.

• Interrumpe el servicio.

⚔️ Esto protege la confidencialidad y la integridad, aunque interrumpa operaciones.

🔸 Ejemplo real: Una base militar o banco. Si hay una sospecha de fallo o sabotaje, el sistema se cierra para que nada entre ni salga.

🎯 2️⃣ EJEMPLOS PRÁCTICOS

Escenario > Fail-Open > Fail-Close
🔬 Laboratorio de investigación médica > Los dispositivos siguen enviando datos si el proxy falla. > Se bloquean las máquinas conectadas, protegiendo la IP científica.
🏥 Hospital > Acceso a historiales sigue disponible. > Se corta el acceso: posible peligro para el paciente.
🏦 Banco > El sistema de transferencias permite operaciones sin verificar usuarios. > Se detienen todas las operaciones para evitar fraudes.

🛠 3️⃣ APLICACIONES Y HERRAMIENTAS REALES

Tipo de Dispositivo > Comportamiento en Fallo Configurable
🔥 Firewalls (p.ej. Palo Alto, FortiGate) Generalmente fail-close por defecto. Sí.
🧠 Proxies de autenticación (Squid, Zscaler) A menudo fail-open para no cortar acceso a Internet. Sí.
🔍 IDS/IPS (Snort, Suricata) Pueden configurarse. SPAN: fail-open, en línea: configurable.
💻 Endpoint AV/EDR (CrowdStrike, SentinelOne) Normalmente fail-close: si falla, bloquea procesos. A veces sí.

🔐 4️⃣ VISIÓN DE RED, BLUE Y PURPLE TEAM

👾 RED TEAM

• Ataca sistemas diseñados en modo fail-open provocando errores o sobrecargas para desactivar el control.

• Usa técnicas como DoS a dispositivos de seguridad para forzar una apertura.

• Ejemplo: lanzar un ataque al proxy para que se "abra" y permita tráfico malicioso.

🛡️ BLUE TEAM

• Audita qué dispositivos están en modo fail-open y evalúa los riesgos.

• Define políticas: ¿qué es más importante, disponibilidad o seguridad?

• Aplica monitorización y alertas si un dispositivo cambia a modo abierto.

• Usa backup routing para evitar cierres totales si se rompe un nodo.

🧬 PURPLE TEAM

• Simula fallos y valida si los dispositivos fallan de forma segura.

• Hace pruebas de resiliencia: ¿qué pasa si un firewall se apaga?

• Alinea con el negocio: "¿Podemos permitirnos fallar abiertos aquí?"

• Aplica soluciones mixtas: fail-close con rutas alternativas de emergencia.

✍️ 6️⃣ RESUMEN PRÁCTICO

En arquitectura de seguridad, los dispositivos pueden fallar de dos maneras:
Fail-Open permite el paso del tráfico cuando hay una falla, priorizando la disponibilidad, pero comprometiendo la seguridad.
Fail-Close bloquea todo en caso de error, priorizando confidencialidad e integridad, pero puede causar interrupciones.
Un verdadero Purple Team evalúa qué tipo de fallo es aceptable en cada contexto.
En hospitales, puede que falle en abierto. En bancos o infraestructuras críticas, mejor que falle cerrado.
El equilibrio entre seguridad y disponibilidad se define estratégicamente según el impacto del fallo.

EJERCICIO 1: Centro Hospitalario en Medio de un Ataque DDoS

Situación:
Estás en un hospital donde se utiliza un firewall perimetral configurado en modo fail-close. Durante una noche, el hospital sufre un ataque DDoS masivo que satura el firewall y provoca su fallo.

🔴 Red Team

• Objetivo: Simular un DDoS dirigido al firewall para provocar su caída y ver si el hospital queda incomunicado.

• Herramientas: LOIC, HOIC, MHDDoS, Hping3.

🔵 Blue Team

• Respuesta esperada:

  • Detecta el tráfico anómalo antes del fallo.

  • Aplica rutas de respaldo o un balanceador con failover.

  • Evalúa si el firewall debe operar en fail-open o mantener el cierre.

  • Implementa una política que permita tráfico solo de sistemas críticos en caso de fallo.

🟣 Purple Team

• Validación:

  • ¿Qué pasó con el tráfico vital (UCI, historiales, RX) durante el fallo?

  • ¿Se podría haber diseñado mejor el failover?

  • ¿Se documentó correctamente el comportamiento real del sistema?

  • ¿Se activaron alertas y el equipo respondió según el playbook?

🧪 EJERCICIO 2: Banco con Transferencias en Línea

Situación:
Una entidad financiera tiene un proxy de autenticación configurado en fail-open. Durante una actualización, el proxy falla. A pesar de esto, el sistema permite operaciones bancarias sin autenticación multifactor.

🔴 Red Team

• Explotación:

  • Espera el fallo programado.

  • Inicia sesión con credenciales robadas (sin MFA).

  • Realiza transferencias y movimientos ilegítimos.

  • Deja rastros falsos para enmascarar su actividad.

🔵 Blue Team

• Respuesta esperada:

  • Detecta que el sistema no solicitó MFA en logs.

  • Cierra el acceso remoto hasta verificar el fallo.

  • Aplica un control compensatorio (p. ej., bloqueo por geolocalización).

  • Documenta y parchea el flujo de autenticación.

🟣 Purple Team

• Lecciones aprendidas:

  • ¿Por qué el proxy no tenía fallback?

  • ¿Qué usuarios accedieron durante el fallo?

  • ¿Se hizo una simulación de este tipo previamente?

  • ¿Se actualizó la arquitectura para evitar este fallo de diseño?

🧪 EJERCICIO 3: Planta Industrial con ICS/SCADA

Situación:
Una fábrica tiene sensores y sistemas ICS (controladores PLC) que dependen de un switch gestionado. El switch tiene un puerto SPAN configurado para monitorear el tráfico, y su IDS está en modo fail-open. Un atacante lanza un malware que desactiva temporalmente el IDS.

🔴 Red Team

• Táctica:

  • Identifica el IDS en modo pasivo.

  • Usa una herramienta como Metasploit o Cobalt Strike para enviar payloads ocultos durante el apagón del IDS.

  • Consigue acceso persistente a los PLC.

🔵 Blue Team

• Defensa:

  • Configura alertas para la caída de visibilidad en IDS.

  • Despliega un segundo sensor redundante (red dual).

  • Aplica segmentación de red y firewall en capa 2/3 para reducir el alcance del ataque.

🟣 Purple Team

• Análisis:

  • ¿Cuánto tiempo pasó desde la caída del IDS hasta que se recuperó?

  • ¿Qué tráfico pasó inadvertido?

  • ¿Cómo se prueba el comportamiento del sistema durante los fallos?

  • ¿El modo fail-open era realmente necesario en este entorno OT?