En agosto de 2026, más de 150 organizaciones —Anthropic, Microsoft, Google, AWS, Cisco, bancos, gobiernos y empresas de ciberseguridad de todo el mundo, incluido nuestro propio equipo en Faraday — firmado una carta abierta impulsada por OpenAI eso resuelve un dilema que todos los equipos de seguridad de infraestructuras críticas conocen bien:
“Cuando un sistema no se puede parchear sin interrumpir servicios esenciales, aplique y verifique controles compensatorios.”
Un hospital no puede bajar el sistema que controla bombas de infusión para aplicar un parche a mitad de una cirugía. Una planta de agua no puede reiniciar su SCADA en horario pico. Pero "no puedo parchear" no puede ser sinónimo de "no hago nada". Esta guía es sobre esa tercera opción.
Qué es (y qué no es) un control compensatorio
Un control compensatorio es una medida que reduce el riesgo de una vulnerabilidad sin eliminar la vulnerabilidad misma. No es un parche disfrazado. No es "vamos a monitorear más y ya está". Es una capa deliberada diseñada para hacer que la explotación sea difícil, detectable, o de bajo impacto aunque el bug siga presente.
Ejemplo concreto: tenés un sistema legacy con una vulnerabilidad de deserialización insegura conocida (tipo CVE con exploit público) y no podés actualizar la librería porque rompe compatibilidad con hardware industrial de 15 años. El parche no es viable esta semana. El control compensatorio sí.
Paso 1: Clasificar por qué no se puede parchear
No todos los "no se puede parchear" son iguales, y la estrategia de control depende de la causa:
- Downtime inaceptable (sistemas 24/7 de misión crítica) → foco en controles de red y detección.
- Incompatibilidad técnica (el parche rompe otra dependencia) → foco en aislamiento y validación de input.
- Vendor no da soporte (EOL, sin actualizaciones) → foco en segmentación total y reemplazo planificado con fecha.
- Certificación regulatoria (recertificar el sistema tras el cambio toma meses) → foco en controles temporales con fecha de expiración explícita.
Paso 2: Las cuatro familias de controles compensatorios
- Aislamiento y segmentación
- VLAN dedicada sin acceso directo a internet.
- Firewall con reglas de allowlist estrictas (no denylist) entre el sistema vulnerable y el resto de la red.
- Diodo de datos si el sistema solo necesita enviar datos, nunca recibirlos.
- Control de acceso reforzado
- Jump host / bastion obligatorio para cualquier acceso administrativo.
- MFA en el punto de entrada, aunque el sistema legacy en sí no lo soporte nativamente.
- Sesiones grabadas (session recording) para auditoría posterior.
- Filtrado y virtual patching
- IPS/WAF con firma específica para el exploit conocido (virtual patching) — bloquea el patrón de ataque sin tocar el sistema.
- Proxy inverso que sanitiza el input antes de que llegue al sistema vulnerable.
- Detección y respuesta aceleradas
- Monitoreo específico de indicadores de explotación de esa CVE puntual (no monitoreo genérico).
- Runbook de respuesta con tiempos de reacción más agresivos que el estándar, dado que no hay parche de respaldo.
Paso 3: Verificar, no asumir
Este es el paso que la mayoría se salta y el que la carta explícitamente pide ("apply and verify"). Un control compensatorio sin verificación es una promesa, no una defensa:
- Test de penetración dirigido:intentar explotar la vulnerabilidad original a través de el control compensatorio. Si tu red team pasa de todos modos, el control no funciona.
- Simulación de bypass:¿Qué pasa si el atacante ya tiene acceso a la VLAN aislada por otro medio (ej. dispositivo comprometido dentro del segmento)? El control debe sobrevivir ese escenario también.
- Revisión periódica:un control compensatorio no es "configurar y olvidar". Revisalo cada vez que cambie el entorno (nuevo dispositivo en la red, cambio de firmware, etc.).
Paso 4: Documentar con fecha de expiración
Un error grave y común: los controles compensatorios se vuelven permanentes por default porque nadie les puso fecha. Cada control debe registrar:
- La vulnerabilidad que compensa (CVE o descripción).
- Fecha de implementación y responsable.
- Fecha de revisión obligatoria (como máximo cada 6 meses para infraestructuras críticas).
- Un plan de reemplazo real (cuando el sistema sea realmente parcheable o migrable).
Sin esto, tu control compensatorio de hoy es la deuda técnica que otro equipo va a auditar en el post #1 de esta serie, dentro de tres años.
Checklist
- ☐ Clasificar la causa raíz de por qué no se puede parchear
- ☐ Elegir familia(s) de control según esa causa
- ☐ Implementar aislamiento/segmentación como base mínima
- ☐ Agregar virtual patching si hay IPS/WAF disponible
- ☐ Ejecutar test de penetración dirigido contra el control implementado
- ☐ Documentar con fecha de expiración y plan de reemplazo
- ☐ Agendar revisión periódica (no dejarlo indefinido)
Parte de una serie sobre cómo poner en práctica los principios de Carta abierta de OpenAI sobre la defensa colectiva en ciberseguridad (Agosto de 2026). Volver a la guía completa.
