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 apagar el sistema que controla las bombas de infusión para aplicar un parche en plena cirugía. Una planta de tratamiento de agua no puede reiniciar su sistema SCADA durante las horas punta. Pero “no puedo aplicar el parche” no puede ser sinónimo de “no hago nada”. Esta guía trata sobre esa tercera opción.
Qué es un control compensatorio (y qué no es)
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 un “simplemente supervisaremos más y daremos el asunto por zanjado”. Es una capa deliberada diseñada para hacer que la explotación sea difícil, detectable o de bajo impacto, a pesar de que el error subyacente siga ahí.
Ejemplo concreto: tienes un sistema heredado con una vulnerabilidad de deserialización insegura conocida (un CVE con un exploit público) y no puedes actualizar la biblioteca porque rompe la compatibilidad con hardware industrial de 15 años de antigüedad. El parche no es viable esta semana. El control compensatorio sí lo es.
Paso 1 — Clasificar por qué no se puede parchear
No todas las situaciones de “imposibilidad de parchear” son iguales, y la estrategia de control depende de la causa:
- Tiempo de inactividad inaceptable (sistemas de misión crítica 24/7) → enfóquese en los controles de red y la detección.
- Incompatibilidad técnica (el parche rompe otra dependencia) → centrarse en el aislamiento y la validación de entradas.
- El proveedor ya no lo admite (Fin de vida útil, sin actualizaciones) → centrarse en la segmentación completa y la sustitución planificada con una fecha firme.
- Certificación reglamentaria (recertificar el sistema después del cambio lleva meses) → centrarse en controles temporales con una fecha de caducidad explícita.
Paso 2 — Las cuatro familias de controles compensatorios
- Aislamiento y segmentación
- VLAN dedicada sin acceso directo a internet.
- Cortafuegos con reglas estrictas de lista blanca (no de lista negra) 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
- Servidor de salto / bastión obligatorio para cualquier acceso administrativo.
- MFA en el punto de entrada, incluso si el propio sistema heredado no lo admite de forma nativa.
- Grabación de la sesión para auditoría posterior.
- Filtrado y parcheo virtual
- IPS/WAF con una firma específica para la vulnerabilidad explotada conocida (parcheo virtual): bloquea el patrón del ataque sin tocar el sistema.
- Proxy inverso que desinfecta la entrada antes de que llegue al sistema vulnerable.
- Detección y respuesta aceleradas
- Monitoreo específico de indicadores de explotación para ese CVE en particular (no monitoreo genérico).
- Guía de respuesta con tiempos de reacción más agresivos que los estándar, dado que no hay un parche como red de seguridad.
Paso 3: Verifica, no supongas
Este es el paso que la mayoría de los equipos se salta, y el que la carta exige explícitamente (“aplicar y verificar“). Un control compensatorio sin verificación es una promesa, no una defensa:
- Prueba de penetración dirigidaintentar explotar la vulnerabilidad original a través de el control compensatorio. Si tu equipo rojo pasa de todos modos, el control no funciona.
- Bypass de simulación¿Qué pasa si el atacante ya tiene acceso a la VLAN aislada a través de otra ruta (por ejemplo, un dispositivo comprometido dentro del segmento)? El control debe sobrevivir también a ese escenario.
- Revisión periódicaun control compensatorio no es de “configurar y olvidar”. Revíselo siempre que el entorno cambie (nuevo dispositivo en la red, cambio de firmware, etc.).
Paso 4: Documento con fecha de caducidad
Un error grave y común: los controles compensatorios se vuelven permanentes por defecto 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, el control compensatorio de hoy se convertirá en la deuda técnica de mañana, que es precisamente lo que se analizará en la entrada #1 de esta serie, dentro de tres años.
Lista de verificación
- ☐ Clasificar la causa raíz de por qué el sistema no se puede actualizar
- ☐ Seleccione la(s) familia(s) de controles en función de esa causa
- ☐ Implementar el aislamiento/la segmentación como una línea base mínima
- ☐ Añadir parcheo virtual si hay un IPS/WAF disponible
- ☐ Ejecutar una prueba de penetración dirigida contra el control implementado
- ☐ Documento con fecha de caducidad y plan de sustitución
- ☐ Programar una revisión periódica (no dejarlo abierto)
Parte de una serie sobre cómo poner en práctica los principios de Carta abierta de OpenAI sobre la defensa cibernética colectiva (Agosto de 2026). Volver a la guía completa.
