La publicación del blog de hoy presenta un resumen del reciente documento de asesoría de CISA titulado "Barreras para la Comunicación OT Segura: Por qué Johnny No Puede Autenticar. Este documento se puede descargar desde este enlace.

No importa cómo lo veas, esto es más que solo otro aviso de CISA. En cambio, es un cambio fundamental en cómo el gobierno federal ve el "elemento humano" de la ciberseguridad. Durante años, la narrativa de la industria ha sido "Johnny solo necesita más entrenamiento". El informe de CISA de febrero de 2026, "Barreras para la Comunicación OT Segura: Por qué Johnny No Puede Autenticar," esencialmente cambia el guion y trae a primer plano más aspectos que deben incorporarse a un plan general de comunicaciones seguras.

El informe articula que Johnny (el operador) no está fallando al sistema. En cambio, parece que el sistema está fallando a Johnny. Al enfocarse en la naturaleza "inutilizable" de las implementaciones actuales de seguridad en Tecnología Operacional (OT), CISA ha proporcionado una hoja de ruta para pasar de la seguridad teórica a la resiliencia funcional.

Antes de avanzar, no olvides revisar nuestra publicación anterior en el blog sobre “Cómo un trabajo paralelo paralizó el oleoducto nacional de Rumania” aquí.

El problema central de "Johnny": Un legado de fallos de usabilidad

Algunos de nosotros podemos recordar este título y su contexto. El título es una referencia inconfundible al documento seminal de 1999 "Por qué Johnny No Puede Cifrar", que demostró que si las herramientas de seguridad son demasiado difíciles de usar, la gente simplemente no las usará. En el contexto de 2026, CISA aplica la misma lógica a los técnicos e ingenieros que manejan nuestras redes eléctricas, plantas de tratamiento de agua y líneas de producción.

Todos sabemos que en un entorno OT, el objetivo principal es la disponibilidad y la seguridad. Si una puerta de autenticación retrasa un comando a una bomba de enfriamiento por solo unos milisegundos, o lo bloquea completamente debido a un certificado expirado, el resultado no es solo un registro de "acceso denegado"; es una catástrofe física. Este es un escenario fácil de imaginar para todos los operadores de OT.

Más allá del texto plano

Durante mucho tiempo, los profesionales de seguridad centrados en TI han menospreciado a los operadores OT por usar protocolos en texto plano como Modbus o DNP3. El informe de CISA valida la perspectiva del operador. La inseguridad es a menudo una elección consciente hecha para garantizar la fiabilidad.

Barreras técnicas: El impuesto de CPU y memoria

La criptografía moderna es bastante "costosa" en términos de poder de cómputo. El documento de CISA detalla una cruda realidad: muchos de los dispositivos que controlan actualmente la infraestructura crítica se construyeron antes de que muchos de nosotros comenzáramos nuestras carreras o aún estuviéramos obteniendo nuestros títulos. 

• La brecha de recursos: Implementar Seguridad de la Capa de Transporte (TLS) o incluso algo tan simple como Códigos de Autenticación de Mensajes (MACs) requiere ciclos de CPU y memoria que los PLCs (Controladores Lógicos Programables) antiguos simplemente no pueden permitirse.

• El desafío de la latencia: En procesos de alta velocidad (como la protección de la red eléctrica), el tiempo que toma realizar un "apretón de manos" para autenticar un mensaje puede exceder el tiempo permitido para que el comando se ejecute.

• El problema "Sin cabeza": Muchos dispositivos OT no vienen con una pantalla o un teclado. Configurar una contraseña compleja de 20 caracteres o un token de autenticación multifactorial (MFA) es, por lo tanto, físicamente imposible en un dispositivo que vive dentro de un gabinete de riel DIN en una subestación remota.

La pesadilla de la gestión de certificados

Si hay un "villano" en este informe, es el estado actual de la Infraestructura de Clave Pública (PKI) en el campo. CISA enfatiza que gestionar identidades para miles de dispositivos remotos, a menudo desconectados, es la mayor barrera operativa para la seguridad.

La trampa de "fallar cerrado" u algo similar

En TI, si un certificado expira, tu navegador bloquea el sitio. Eso es "fallar cerrado", y es seguro. En OT, si un certificado expira en un controlador de válvula, y ese controlador "falla cerrado" al negarse a recibir comandos, la tubería podría romperse.

• El resultado: Los operadores frecuentemente desactivan la verificación de certificados por completo para evitar tiempos de inactividad auto infligidos, haciendo inútil toda la capa de cifrado.

La brecha de conectividad

Muchos entornos OT están "aislados" o tienen conectividad limitada. ¿Cómo verificas una Lista de Revocación de Certificados (CRL) o accedes a un respondedor del Protocolo de Estado de Certificado en Línea (OCSP) si no se te permite conectarte a internet? El informe destaca que carecemos de una manera "estandarizada, amigable offline" para gestionar la confianza a escala.

La paradoja de visibilidad: Seguridad vs. observabilidad

CISA introduce un conflicto crítico: El cifrado ciega a los defensores.

La seguridad OT moderna depende en gran medida de herramientas de Detección y Respuesta de Red (NDR) que "olfatean" el tráfico para encontrar anomalías. Cuando cifras ese tráfico (por ejemplo, usando OPC UA seguro o SIP), esas herramientas ya no pueden ver qué hay dentro del paquete.

La Recomendación de CISA: El informe se inclina fuertemente hacia Firmado de Mensajes (Integridad) sobre Cifrado (Privacidad).

"A menudo es más importante para un operador saber que un comando definitivamente vino del controlador autorizado (Integridad) que esconder el comando de un escucha pasivo (Privacidad)."

Al firmar mensajes, aseguramos autenticidad sin perder la capacidad de monitorear la red para la seguridad.

Barreras económicas y fallo del mercado

¿Por qué el mercado no ha resuelto esto? CISA señala un "fallo del mercado" en el ecosistema de proveedores de OT:

• Seguridad como un extra: Muchos proveedores tratan las funciones de seguridad (como el registro o protocolos cifrados) como licencias añadidas en lugar de características básicas de seguridad.

• Fuertes ciclos de vida: Una empresa de servicios de agua podría reemplazar sus bombas una vez cada 25 años. Esto significa que actualmente vivimos con las decisiones de seguridad tomadas en 2005.

• Bloqueo de proveedor: Si la versión "segura" del protocolo de Proveedor A no se comunica con la puerta de enlace "segura" del Proveedor B, el operador queda atrapado con el denominador común más bajo: el protocolo heredado inseguro.

El mandato de "Seguridad por Diseño"

CISA concluye que la carga de la autenticación debe cambiar del usuario al fabricante. Este es el núcleo de su iniciativa "Seguridad por Diseño" de 2026.

• No más contraseñas por defecto: Los dispositivos deben enviarse con credenciales únicas o requerir un cambio al primer arranque.

• Confianza basada en hardware: Los fabricantes deben incluir Elementos Seguros (TPMs) en el hardware para que la identidad esté integrada en el silicio, no gestionada en una hoja de cálculo por un técnico estresado.

• Interoperabilidad: Los métodos de autenticación deben estandarizarse entre proveedores, para que "Johnny" solo tenga que aprender (y ser competente en) un solo sistema, no cinco.

La lista de verificación de "Seguridad de Johnny" completa

Esta lista de verificación está diseñada para que los gerentes de OT y CISOs evalúen su postura actual frente a las barreras identificadas en el informe de CISA de 2026.

Estratégico y adquisiciones

• [ ] Inventario de limitaciones heredadas: ¿Has identificado qué dispositivos carecen de CPU/RAM para manejar el cifrado moderno?

• [ ] RFP de Seguridad por Diseño: ¿Tus contratos de adquisiciones exigen contraseñas iniciales únicas y soporte para protocolos firmados?

• [ ] Alineación seguridad-seguridad: ¿Has definido qué sistemas deben "fallar abierto" (priorizar tiempo de actividad) frente a "fallar cerrado" (priorizar seguridad)?

• [ ] Auditoría de licencias: ¿Te están cobrando extra por registros de seguridad o versiones de protocolos cifrados? (Exige que se incluyan como características de seguridad).

Autenticación operativa

• [ ] Unicidad de credenciales: ¿Todavía hay cuentas compartidas "admin/admin" u "operador/operador" en uso en el piso de producción?

• [ ] MFA para acceso: ¿Se requiere MFA para el humano que accede al HMI, incluso si las comunicaciones de dispositivo a dispositivo todavía son en texto plano?

• [ ] Plan de rotación de claves: ¿Tienes un plan documentado para la rotación de certificados que no requiere conexión a internet?

• [ ] Seguridad física: Dado que "Johnny" no siempre puede autenticar digitalmente, ¿los puertos físicos de tus PLC están bloqueados o son a prueba de manipulaciones?

Técnico y monitoreo

• [ ] Integridad vs. Privacidad: ¿Has explorado usar modos "Solo Firmado" para protocolos para mantener la visibilidad de tus herramientas IDS/NDR?

• [ ] Referencias de latencia: ¿Has medido el retraso en milisegundos añadido por tu pila de seguridad para asegurarte de que no rompa los bucles de control?

• [ ] Centralización de registros: ¿Tus dispositivos OT envían registros a un repositorio central, inmutable, o se sobrescriben cada 24 horas?

• [ ] Zoning de red: ¿Los dispositivos "Johnny" inseguros están aislados en una zona restringida (estilo ISA/IEC 62443) con un firewall con estado?

El informe de CISA es una admisión contundente de que no podemos "parchear" nuestra salida de la crisis de seguridad OT. Las autenticaciones fallan porque se tratan como una adición técnica en lugar de una necesidad operativa. Para ayudar a "Johnny", debemos dejar de pedirle que sea un experto en seguridad y comenzar a darle herramientas que sean seguras por defecto, resilientes por diseño y, sobre todo, utilizables en medio de una crisis.

Más sobre nuestros servicios de cumplimiento NIS2.

Aprende un poco más sobre los servicios de respuesta a incidentes de Shieldworkz

Habla con un experto en seguridad de vacaciones (sí, tenemos un profesional de seguridad dedicado que sabe más sobre cómo afinar tus medidas de seguridad durante tiempos difíciles).

Prueba nuestra plataforma de seguridad OT aquí.

Recursos descargables:

Lista de verificación de ciberseguridad OT para mantenimiento en sitio

Lista de verificación de protección contra amenazas internas

Lista de verificación de gestión de riesgo cibernético  

Lista de verificación estratégica IEC 62443 para proteger tus operaciones IACS

Informe sobre el estado de la seguridad OT