Enti\u00e9ndase sistemas propietarios aislados<\/strong>, como sistemas f\u00edsicamente desconectados de otras redes y propietarios ya que sus protocolos y tecnolog\u00edas eran desarrollados espec\u00edficamente por el fabricante, no estaban p\u00fablicamente documentados ni eran compatibles con otras marcas; esto creaba “seguridad por oscuridad”, un atacante necesitaba conocimiento muy especializado sobre ese sistema espec\u00edfico.<\/p>\n\n\n\n Imagine una central el\u00e9ctrica construida en los a\u00f1os 90. En ese entonces, sus sistemas de control estaban completamente aislados<\/strong> del mundo exterior, la seguridad resid\u00eda en la desconexi\u00f3n f\u00edsica<\/strong>, no hab\u00eda acceso a internet, ni redes corporativas conectadas ni acceso remoto. El \u00fanico camino para atacar estos sistemas era entrar f\u00edsicamente a la instalaci\u00f3n. Los protocolos de comunicaci\u00f3n eran propietarios, conocidos solo por ingenieros especializados, y el software no se actualizaba porque simplemente no hab\u00eda necesidad, pues el sistema funcionaba bien.<\/p>\n\n\n\n Avancemos 30 a\u00f1os. Esa misma central ahora necesita enviar datos de producci\u00f3n en tiempo real <\/strong>a ejecutivos para toma de decisiones estrat\u00e9gicas. Los operadores requieren acceso remoto<\/strong> para responder r\u00e1pidamente a emergencias. Los vendors (proveedores) necesitan conectarse para diagn\u00f3sticos predictivos y mantenimiento. La integraci\u00f3n con sistemas empresariales es esencial para optimizar operaciones.<\/p>\n\n\n\n Como resultado cada vulnerabilidad descubierta en sistemas IT est\u00e1ndar, cada t\u00e9cnica de hacking publicada, cada herramienta de pentesting disponible p\u00fablicamente, ahora podr\u00edan ser aplicable a esa central el\u00e9ctrica que alguna vez estuvo aislada.<\/p>\n\n\n\n Este art\u00edculo identifica 9 vulnerabilidades cr\u00edticas en entornos de Tecnolog\u00eda Operacional (OT) bas\u00e1ndose en material de la Cybersecurity and Infrastructure Security Agency (CISA), <\/strong>agencia federal de Estados Unidos cuya misi\u00f3n principal es proteger la infraestructura cr\u00edtica f\u00edsica y cibern\u00e9tica de la naci\u00f3n. Cada vulnerabilidad identificada representa un riesgo tangible para operaciones cr\u00edticas de infraestructura que sostienen la energ\u00eda el\u00e9ctrica, el agua potable, as\u00ed como para empresas con \u00e1reas de OT <\/strong>en sectores como la manufactura y otros servicios esenciales en nuestra sociedad.<\/p>\n\n\n\n La seguridad por oscuridad<\/strong> fue durante d\u00e9cadas una estrategia de protecci\u00f3n impl\u00edcita en entornos OT. Los protocolos propietarios <\/strong>eran conocidos \u00fanicamente por quienes los dise\u00f1aron o por personal con entrenamiento altamente especializado. Sin embargo, la adopci\u00f3n de protocolos de comunicaci\u00f3n est\u00e1ndar y abiertos<\/strong> (como Ethernet, TCP\/IP y Modbus TCP) cambi\u00f3 completamente este panorama.<\/p>\n\n\n\n Estos protocolos modernos est\u00e1n exhaustivamente documentados<\/strong>, lo cual es excelente para la interoperabilidad entre diferentes fabricantes y sistemas, pero elimina por completo la protecci\u00f3n que ofrec\u00eda la oscuridad. Las vulnerabilidades de estos protocolos est\u00e1n bien conocidas, ampliamente documentadas y son objeto de constante investigaci\u00f3n por la comunidad de seguridad. Lo que antes era una cerradura \u00fanica y compleja, ahora es una cerradura est\u00e1ndar que cualquier experto en seguridad puede estudiar, analizar e intentar forzar.<\/p>\n\n\n\n Todo hardware o software que procese, almacene o transmita informaci\u00f3n digitalmente es vulnerable a ciberataques<\/strong>. La diferencia cr\u00edtica radica en si esa vulnerabilidad es explotable. En otras palabras, cualquier sistema puede ser atacado, pero no todo ataque ser\u00e1 exitoso. En entornos de control industrial, se reconocen al menos ocho tipos de activos digitales que se han convertido en objetivos principales para adversarios cibern\u00e9ticos:<\/p>\n\n\n\n Incluso los sistemas de seguridad integrados (SIS Safety Instrumented Systems<\/strong>) est\u00e1n en riesgo si se conectan directamente a la red del sistema de control. Estos son sistemas dise\u00f1ados para proteger vidas humanas en caso de fallos operacionales, y su compromiso podr\u00eda tener consecuencias catastr\u00f3ficas.<\/p>\n\n\n\n La realidad es que existen m\u00faltiples v\u00edas para comunicarse con una red ICS y sus componentes. En un sistema mal configurado cualquier persona con conocimientos en equipos de proceso, redes, sistemas operativos y aplicaciones de software puede potencialmente ganar acceso. La superficie de ataque se ha expandido exponencialmente con las revoluciones tecnol\u00f3gicas que estamos viviendo.<\/p>\n\n\n\n Bas\u00e1ndonos en los recursos digitales compartidos al p\u00fablico por CISA (Cybersecurity and Infrastructure Security Agency)<\/strong>, se identificaron nueve categor\u00edas de vulnerabilidades que sistem\u00e1ticamente ponen en riesgo la seguridad de sistemas OT. Cada una representa no solo una debilidad t\u00e9cnica, sino una brecha en la defensa de infraestructura.<\/p>\n\n\n\n Una de las causas primarias de vulnerabilidades de seguridad en software y firmware de sistemas de control es el uso de t\u00e9cnicas de programaci\u00f3n deficientes. La mayor\u00eda de los desarrolladores no escriben c\u00f3digo con fallas de seguridad intencionalmente. El problema muchas veces radica en las prioridades de dise\u00f1o, imagine a un ingeniero que debe construir un puente, \u00e9ste se centra exclusivamente en que no se caiga bajo el peso del tr\u00e1fico, en que los materiales sean adecuados, que no entre en resonancia con el viento, que los veh\u00edculos tengan correctas contenciones de seguridad, esto suena bien, pero el ingeniero nunca consider\u00f3 que alguien podr\u00eda escalarlo desde cierta columna para colocar explosivos en un punto cr\u00edtico y derribarlo. El puente cumple perfectamente su funci\u00f3n operacional y contempla una gran cantidad de factores, sin embargo es completamente vulnerable a amenazas que nunca se consideraron durante su dise\u00f1o<\/strong>.<\/p>\n\n\n\n Los sistemas ICS se desarrollan con un enfoque absoluto en disponibilidad<\/strong> y resiliencia<\/strong>. Cuando el requisito de alta disponibilidad es la prioridad n\u00famero uno, la seguridad frecuentemente no se considera durante el ciclo de vida de desarrollo. Esto no era un problema cuando los sistemas operaban aislados. Se convirti\u00f3 en un problema cr\u00edtico cuando se conectaron al mundo.<\/p>\n\n\n\n El problema se exacerba dram\u00e1ticamente en sistemas de control que pueden tener d\u00e9cadas de antig\u00fcedad, ejecutando c\u00f3digo que no ha sido actualizado desde su instalaci\u00f3n original. Cambiar las pr\u00e1cticas de codificaci\u00f3n o reescribir el c\u00f3digo fuente de un producto emblem\u00e1tico puede ser extraordinariamente costoso tanto para vendors como para clientes. Aplicar parches en un entorno operacional es frecuentemente dif\u00edcil o imposible sin tiempo de inactividad planificado, algo que muchas operaciones cr\u00edticas simplemente no pueden permitirse.<\/p>\n\n\n\n Los atacantes explotan funciones y caracter\u00edsticas del c\u00f3digo que son potencialmente peligrosas en arquitecturas modernas y fueron incluidas en aplicaciones ICS propietarias para facilitar operaciones pensadas para otros contextos: <\/p>\n\n\n\n Los propietarios de ICS deben exigir que los vendors certifiquen que sus desarrolladores est\u00e1n entrenados en pr\u00e1cticas de codificaci\u00f3n segura como parte integral de su proceso de control de calidad. Tambi\u00e9n deben crear canales de comunicaci\u00f3n efectivos para aprender r\u00e1pidamente de problemas de seguridad basados en c\u00f3digo y recibir y desplegar parches de manera eficiente. Aumentar la conciencia de ciberseguridad en el ciclo de vida de desarrollo de sistemas y software ayuda a propietarios de activos y vendors a entender la necesidad de construir seguridad proactivamente en el sistema desde el dise\u00f1o, lo cual incrementar\u00e1 significativamente la seguridad de productos ICS.<\/p>\n\n\n\n Es como instalar una puerta trasera s\u00faper conveniente en una b\u00f3veda bancaria para que los empleados puedan entrar r\u00e1pidamente cuando olvidan algo. La puerta es incre\u00edblemente \u00fatil para operaciones diarias, pero tambi\u00e9n es incre\u00edblemente \u00fatil para un ladr\u00f3n que descubra su existencia.<\/p>\n\n\n\n Servicios web embebidos, herramientas de diagn\u00f3stico remoto, caracter\u00edsticas de reporteo y otras capacidades de valor agregado tradicionalmente no usadas en soluciones de sistemas de control est\u00e1n siendo cada vez m\u00e1s implementadas en campo, mientras que los servicios basados en web y remotos permiten a los operadores ICS gestionar, monitorear y controlar sistemas de manera m\u00e1s eficiente, este enfoque puede introducir vulnerabilidades de seguridad significativas en la arquitectura del sistema de control.<\/p>\n\n\n\n Muchos proveedores de sistemas de control satisfacen las demandas de sus clientes integrando interfaces f\u00e1ciles de usar para gestionar equipos<\/strong>. Un ejemplo es incorporar servicios web simples y econ\u00f3micos directamente en sus dispositivos de campo. Esto permite a los operadores controlar y administrar equipos cr\u00edticos desde cualquier lugar a trav\u00e9s de un navegador web o de Internet.<\/p>\n\n\n\n El problema es que sin un an\u00e1lisis de seguridad adecuado de esa interfaz web<\/strong>, puede ser usada como un vector de ataque directo hacia equipos de campo. Lo que era una caracter\u00edstica conveniente se convierte en una vulnerabilidad explotable.<\/p>\n\n\n\n Muchos dispositivos industriales<\/strong> (PLCs, variadores, medidores inteligentes) traen servidores web integrados habilitados por defecto que los ingenieros a veces ni siquiera saben que est\u00e1n ah\u00ed.<\/p>\n\n\n\n Las vulnerabilidades \u00fanicas de servicios remotos ahora est\u00e1n integradas en muchas soluciones de vendors de sistemas de control. Si se explotan, estas vulnerabilidades pueden revelar informaci\u00f3n significativa a un atacante o proporcionarles acceso al dispositivo mismo:<\/p>\n\n\n\n Enti\u00e9ndase como autenticaci\u00f3n deficiente<\/strong> al uso de credenciales por defecto, d\u00e9biles o inexistentes; Directory Traversal<\/strong> como la caracter\u00edstica que permite el acceso indebido a archivos de un sistema; acceso no autenticado<\/strong> a la exposici\u00f3n de p\u00e1ginas administrativas sin protecci\u00f3n; e inyecci\u00f3n SQL<\/strong> como la vulnerabilidad que permite la manipulaci\u00f3n directa de bases de datos.<\/p>\n\n\n\n Todos los servicios web y remotos deben pasar por un an\u00e1lisis de seguridad riguroso antes de ser desplegados en entornos de producci\u00f3n. Esto incluye pruebas de penetraci\u00f3n, revisi\u00f3n de c\u00f3digo y evaluaci\u00f3n de arquitectura de seguridad.<\/p>\n\n\n\n Imagine un sistema de mensajer\u00eda corporativa donde los mensajes viajan sin sobres, cualquiera puede leerlos, nadie verifica la identidad del remitente, y no hay forma de confirmar que el mensaje no fue alterado en tr\u00e1nsito. Ese es esencialmente el estado de muchos protocolos de red en ICS.<\/p>\n\n\n\n La mayor\u00eda de los nuevos sistemas de control han migrado de usar comunicaciones basadas en serial hacia tecnolog\u00eda de redes basada en Ethernet para proporcionar una infraestructura de comunicaciones m\u00e1s \u00e1gil. El uso de TCP\/IP (Transmission Control Protocol\/Internet Protocol) ha demostrado ser beneficioso tanto para vendors como para propietarios de activos en t\u00e9rminos de gesti\u00f3n de red.<\/p>\n\n\n\n Sin embargo, esta migraci\u00f3n trajo consigo vulnerabilidades fundamentales del protocolo TCP\/IP que nunca fueron dise\u00f1adas considerando entornos adversariales.<\/p>\n\n\n\n La falta de validaci\u00f3n de entrada<\/strong> resulta en buffer overflow y f<\/strong>alta de verificaci\u00f3n de l\u00edmites en servicios de control del sistema, permitiendo a atacantes ejecutar c\u00f3digo arbitrario. La autenticaci\u00f3n d\u00e9bil o inexistente<\/strong> significa que muchos protocolos de control no autentican comunicaciones, por lo que cualquiera que pueda enviar paquetes correctamente formateados es considerado “confiable”. Los protocolos de control usando verificaciones de integridad d\u00e9biles<\/strong> permiten modificaci\u00f3n de comandos en tr\u00e1nsito sin detecci\u00f3n. Y los productos ICS dependiendo de protocolos IT est\u00e1ndar con cifrado d\u00e9bil o mal implementado, o implementaciones propietarias de cifrado que han sido p\u00fablicamente vulneradas, completan el panorama de riesgo.<\/p>\n\n\n\n La capacidad de hacer spoofing de paquetes<\/strong> IP (t\u00e9cnica de enga\u00f1o donde un atacante falsifica su direcci\u00f3n de identidad<\/strong> para hacerse pasar por un dispositivo autorizado) y el hecho de que IPv4 no verifica la validez de la direcci\u00f3n de origen ni el puerto de origen en los encabezados de paquetes es una de las vulnerabilidades primarias en la suite de protocolos TCP\/IP. A medida que m\u00e1s ICS usan protocolos de comunicaci\u00f3n est\u00e1ndar, el potencial para un compromiso basado en IP se escala dram\u00e1ticamente. Un atacante con acceso a la red puede suplantar (spoofing<\/strong>) comunicaciones leg\u00edtimas, inyectar comandos maliciosos que parecen venir de fuentes confiables, interceptar y modificar comunicaciones en tr\u00e1nsito (man-in-the-middle<\/strong>), y causar fallos mediante paquetes malformados (buffer overflows<\/strong>).<\/p>\n\n\n\n Implementar validaci\u00f3n rigurosa de entrada, autenticar todas las comunicaciones de control, y utilizar protocolos con verificaci\u00f3n de integridad robusta. Donde sea posible, migrar a versiones seguras de protocolos (por ejemplo, de Modbus a Modbus\/TCP con TLS).<\/p>\n\n\n\n Es como operar una flota de veh\u00edculos corporativos ignorando todos los llamados de revisi\u00f3n (recalls<\/em>) de seguridad del fabricante porque llevar los veh\u00edculos al taller interrumpir\u00eda las entregas<\/strong>. Los veh\u00edculos siguen funcionando hasta que un defecto cr\u00edtico causa un accidente fatal que pudo haberse prevenido.<\/p>\n\n\n\n La gesti\u00f3n de parches en entornos OT es fundamentalmente diferente y m\u00e1s compleja que en entornos IT tradicionales. Mientras que un servidor IT puede ser parchado y reiniciado con relativa facilidad, un sistema de control que opera una planta de manufactura 24\/7 no puede simplemente “reiniciarse” para aplicar actualizaciones.<\/p>\n\n\n\n El ransomware WannaCry<\/strong> en 2017 explot\u00f3 la vulnerabilidad EternalBlue<\/strong> en Windows, afectando sistemas de salud, manufactura y otros sectores cr\u00edticos globalmente. Muchos sistemas ICS fueron impactados no porque la vulnerabilidad fuera desconocida (Microsoft hab\u00eda lanzado un parche meses antes<\/strong>), sino porque los sistemas no pudieron ser parchados a tiempo.<\/p>\n\n\n\n Desarrollar una estrategia de gesti\u00f3n de parches espec\u00edfica para OT que incluya inventario completo de activos y versiones de software, proceso de evaluaci\u00f3n de riesgo para cada parche, entornos de prueba cuando sea posible, ventanas de mantenimiento planificadas, y controles compensatorios cuando el parcheo no sea posible (segmentaci\u00f3n, IDS\/IPS, listas blancas<\/strong>).<\/p>\n\n\n\n La gesti\u00f3n de contrase\u00f1as<\/strong> es un componente fundamental de cualquier programa de seguridad. Sin embargo, pocos operadores ICS han provisionado sus sistemas con contrase\u00f1as \u00fanicas soportadas por pol\u00edticas de seguridad robustas, tales como cambios rutinarios de contrase\u00f1as, especialmente contrase\u00f1as predeterminadas (default passwords). Porque los ICS est\u00e1n siempre encendidos<\/strong> (always-on), la mayor\u00eda de propietarios de activos ICS usan una contrase\u00f1a f\u00e1cil de recordar y compartida para todos los operadores, o las contrase\u00f1as predeterminadas<\/strong> nunca se cambian despu\u00e9s de la instalaci\u00f3n. El razonamiento operacional tiene sentido: esto asegura que los operadores puedan acceder r\u00e1pidamente al sistema en situaciones de emergencia. El problema: tambi\u00e9n hace f\u00e1cil para un atacante hacer exactamente lo mismo.<\/p>\n\n\n\n Algunos vendors han dise\u00f1ado sus sistemas con contrase\u00f1as codificadas internamente (hard-coded)<\/strong> o no modificables (unchangeable)<\/strong>. Estas contrase\u00f1as son usadas internamente por programas ICS que necesitan autorizaci\u00f3n para comunicarse con otros recursos computacionales, como bases de datos, o para simplificar instalaciones de software y configuraciones de programas. Es trivial descubrir la mayor\u00eda de contrase\u00f1as codificadas. Se pasan en texto plano a trav\u00e9s de la red, capturables con herramientas como Wireshark. Est\u00e1n abiertamente publicadas en manuales de equipo disponibles en sitios web de vendors o documentadas en foros t\u00e9cnicos y blogs.<\/p>\n\n\n\n Malware avanzado ha sido desarrollado espec\u00edficamente para explotar contrase\u00f1as codificadas en conjunto con otras vulnerabilidades, dejando sistemas que las usan en riesgo significativo. Un atacante puede escanear la red en busca de servicios ICS, intentar credenciales predeterminadas conocidas, capturar credenciales en texto plano del tr\u00e1fico de red, consultar manuales p\u00fablicamente disponibles, y ganar acceso administrativo completo al sistema.<\/p>\n\n\n\n Cambiar todas las contrase\u00f1as predeterminadas antes de poner sistemas en producci\u00f3n, implementar pol\u00edticas de contrase\u00f1as robustas (complejidad, rotaci\u00f3n), utilizar autenticaci\u00f3n multifactor (MFA) donde sea t\u00e9cnicamente posible, eliminar o reemplazar sistemas con contrase\u00f1as codificadas no modificables, y cifrar todas las credenciales en tr\u00e1nsito y en reposo.<\/p>\n\n\n\n Fallar en este punto es como darle a cada empleado de su organizaci\u00f3n, desde el cocinero de la cafeter\u00eda hasta el CEO, acceso completo a todas las b\u00f3vedas, todas las cuentas bancarias, y todos los secretos comerciales. T\u00e9cnicamente conveniente, operacionalmente eficiente, y absolutamente un peligro desde una perspectiva de seguridad. El principio de m\u00ednimos privilegios establece que cualquier usuario, programa o proceso debe tener solo los privilegios m\u00ednimos necesarios para realizar su funci\u00f3n. En entornos ICS, este principio es frecuentemente violado <\/strong>de manera sistem\u00e1tica.<\/p>\n\n\n\n La justificaci\u00f3n hist\u00f3rica era simple, los operadores requer\u00edan control completo del sistema. En entornos aislados donde todos los usuarios eran confiables <\/strong>(empleados autorizados f\u00edsicamente presentes), otorgar privilegios amplios no representaba un riesgo significativo. El enfoque era maximizar la capacidad operacional, no limitar el acceso<\/strong>.<\/p>\n\n\n\n Un atacante que compromete una cuenta de usuario o aplicaci\u00f3n con privilegios excesivos<\/strong> puede escalar privilegios<\/strong> r\u00e1pidamente sin necesidad de exploits adicionales complejos, moverse lateralmente accediendo a otros sistemas usando los privilegios heredados<\/strong>, modificar configuraciones cr\u00edticas cambiando par\u00e1metros operacionales, instalar persistencia creando backdoors con privilegios administrativos, y borrar evidencia modificando o eliminando logs de auditor\u00eda.<\/p>\n\n\n\n Implementar el principio de m\u00ednimos privilegios mediante control de acceso basado en roles <\/strong>(RBAC) con permisos agrupados por funci\u00f3n laboral, separaci\u00f3n de deberes con diferentes personas para operaci\u00f3n, configuraci\u00f3n y auditor\u00eda, just-in-time access<\/em> proporcionando privilegios elevados solo cuando y donde se necesitan, auditor\u00eda continua con revisi\u00f3n regular de qui\u00e9n tiene acceso a qu\u00e9, y principio de “need-to-know<\/em>” dando acceso solo a informaci\u00f3n necesaria para la funci\u00f3n.<\/p>\n\n\n\n Los protocolos en texto plano<\/strong> son comunes en sistemas de control. Esta no fue una decisi\u00f3n de seguridad deficiente en su contexto original, fue una decisi\u00f3n de dise\u00f1o optimizada<\/strong> para el entorno de despliegue previsto. No hab\u00eda necesidad de defender contra robo de datos porque no hab\u00eda acceso externo<\/strong>. El texto plano hace m\u00e1s f\u00e1cil integrar sistemas dispares, con propietarios, vendors e integradores presionando por interoperabilidad<\/strong>, por lo que el tr\u00e1fico en texto plano sigue siendo com\u00fan. Y los protocolos en texto plano son m\u00e1s simples y r\u00e1pidos de diagnosticar que protocolos encriptados, un ingeniero con Wireshark puede ver exactamente qu\u00e9 est\u00e1 sucediendo, mientras que el cifrado agregar\u00eda complejidad a la resoluci\u00f3n de problemas<\/strong>.<\/p>\n\n\n\n Hay comunicaci\u00f3n de protocolos de control industrial sin cifrar<\/strong> (Modbus, DNP3, Profibus en texto plano) y comunicaci\u00f3n de protocolos de control como HTTP, FTP, Telnet. Servicios sin cifrar comunes en sistemas IT como Telnet en lugar de SSH, HTTP en lugar de HTTPS, y FTP en lugar de SFTP\/FTPS. Recursos compartidos de red abiertos en hosts de control del sistema<\/strong>, como shares de Windows sin autenticaci\u00f3n y servidores NFS configurados inseguramente, permitiendo acceso de lectura\/escritura sin credenciales. Protecci\u00f3n d\u00e9bil de credenciales de usuario<\/strong>, con contrase\u00f1as almacenadas en texto plano en archivos de configuraci\u00f3n, credenciales embebidas en scripts visibles, y tokens de autenticaci\u00f3n sin protecci\u00f3n adecuada. Y fuga de informaci\u00f3n a trav\u00e9s de servicios no asegurados<\/strong>, incluyendo banners de servicio revelando versiones exactas de software, mensajes de error con informaci\u00f3n del sistema, y p\u00e1ginas de diagn\u00f3stico accesibles sin autenticaci\u00f3n.<\/p>\n\n\n\n Con acceso a redes de sistemas de control, un adversario puede realizaran\u00e1lisis de tr\u00e1fico en tiempo real<\/strong>, monitoreando comunicaciones operacionales, entendiendo la l\u00f3gica del proceso, e identificando comandos cr\u00edticos. Puede capturar tr\u00e1fico de red para an\u00e1lisis offline, recolectando tr\u00e1fico para estudio detallado, realizando ingenier\u00eda inversa de protocolos propietarios, e identificando patrones y vulnerabilidades. Puede explotar relaciones de confianza capturando contrase\u00f1as en texto plano, suplantando activos cibern\u00e9ticos confiables como consolas de operador o servidores, inyectando datos maliciosos en el flujo de datos, y causando eventos operacionales no deseados.<\/p>\n\n\n\n El acceso a tr\u00e1fico de control en texto plano permite a un actor de amenaza ejecutar numerosos ataques, incluyendo denegaci\u00f3n de servicio inundando con tr\u00e1fico malicioso, man-in-the-middle interceptando y modificando comunicaciones, session hijacking tomando control de sesiones leg\u00edtimas, y otros ataques basados en red, impactando en \u00faltima instancia la integridad y disponibilidad del sistema.<\/p>\n\n\n\n Implementar cifrado para todas las comunicaciones sensibles<\/strong> (TLS\/SSL), utilizar VPNs para tr\u00e1fico remoto, segmentar red para limitar alcance de captura de tr\u00e1fico, implementar detecci\u00f3n de intrusiones (IDS) para identificar an\u00e1lisis de tr\u00e1fico, y migrar protocolos legacy a versiones seguras donde sea posible.<\/p>\n\n\n\n Algunas arquitecturas de red ICS usan redes planas sin zonas, sin seguridad de puertos, y aplicaci\u00f3n d\u00e9bil de pol\u00edticas de acceso remoto. Para agravar este problema, las redes ICS pueden estar conectadas directamente a entornos corporativos sin firewalls y zonas, o permitir conexiones directas a Internet<\/strong>. Con el tiempo, brechas de seguridad pueden haber sido introducidas inadvertidamente. Sin remediaci\u00f3n, estas brechas introducen vulnerabilidades en el ICS.<\/p>\n\n\n\n Conectar redes ICS directamente a redes corporativas<\/strong> sin segmentaci\u00f3n apropiada significa que un ataque de phishing exitoso en IT puede propagarse directamente a OT. Malware que infecta laptops corporativas puede saltar a sistemas de control. Una brecha en sistemas de negocio se convierte autom\u00e1ticamente en brecha en sistemas operacionales.<\/p>\n\n\n\n Un atacante que compromete un solo punto en una red plana puede moverse lateralmente sin restricci\u00f3n, acceder a cualquier sistema en la red, escanear la red completa identificando todos los activos y vulnerabilidades, escalar privilegios f\u00e1cilmente atacando sistemas m\u00e1s cr\u00edticos desde el punto de entrada inicial, y establecer persistencia en m\u00faltiples puntos asegurando que no puedan ser expulsados f\u00e1cilmente<\/p>\n\n\n\n Implementar arquitectura de red basada en zonas y conductos (ISA\/IEC 62443<\/strong>), segmentaci\u00f3n de red dividiendo la red en zonas de seguridad basadas en funci\u00f3n y criticidad, firewalls entre zonas controlando tr\u00e1fico permitido entre zonas, principio de m\u00ednimo acceso de red permitiendo solo comunicaciones expl\u00edcitamente necesarias, DMZ <\/strong>entre IT y OT como zona intermedia para integraci\u00f3n segura, Modelo Purdue<\/strong> implementando separaci\u00f3n de niveles (Level 0-5), y Network Access Control (NAC) verificando dispositivos antes de permitir conexi\u00f3n.<\/p>\n\n\n\n Es como tener las puertas m\u00e1s sofisticadas y costosas del mercado instaladas en su edificio corporativo, pero dejarlas permanentemente abiertas porque alguien olvid\u00f3 configurar los mecanismos de cierre autom\u00e1tico. La tecnolog\u00eda de seguridad est\u00e1 presente, pero est\u00e1 mal configurada y por lo tanto in\u00fatil.<\/p>\n\n\n\n El acceso a puertos espec\u00edficos en host no est\u00e1 restringido a direcciones IP requeridas, servicios cr\u00edticos (HMI, ingenier\u00eda) son accesibles desde cualquier direcci\u00f3n IP, sin listas de control de acceso (ACLs) implementadas, y reglas de firewall configuradas en modo “permitir todo”. La seguridad de puertos no est\u00e1 implementada en equipos de red, port security<\/em> est\u00e1 deshabilitado, sin limitaci\u00f3n de direcciones MAC, sin segmentaci\u00f3n VLAN, y todo el tr\u00e1fico en una sola VLAN.<\/p>\n\n\n\n Los servicios de gesti\u00f3n est\u00e1n expuestos<\/strong>, interfaces de administraci\u00f3n de switches\/routers son accesibles desde redes de producci\u00f3n<\/strong>. SNMP (Simple Network Management Protocol<\/em>) est\u00e1 configurado con community strings<\/em> predeterminadas<\/strong> (“public”, “private”). Los servicios de gesti\u00f3n no tienen cifrado<\/strong> (Telnet en lugar de SSH).<\/p>\n\n\n\n Las configuraciones predeterminadas no han sido modificadas, credenciales de administraci\u00f3n predeterminadas no han sido cambiadas, configuraciones de f\u00e1brica nunca han sido endurecidas (hardened), y servicios innecesarios est\u00e1n habilitados por defecto.<\/p>\n\n\n\n El logging y el monitoreo es inadecuado, los logs de seguridad est\u00e1n deshabilitados, no hay correlaci\u00f3n de eventos, y las alertas de seguridad no est\u00e1n configuradas.<\/p>\n\n\n\n Un atacante se beneficia enormemente de configuraciones inseguras. El escaneo de puertos revela servicios expuestos, identificaci\u00f3n r\u00e1pida de puntos de entrada. Las credenciales predeterminadas proporcionan acceso administrativo, control completo de infraestructura. La falta de segmentaci\u00f3n permite movimiento lateral<\/strong>, una vez dentro, acceso a todo. La ausencia de logs oculta actividad maliciosa, ataques que no dejan evidencia.<\/p>\n\n\n\n Desarrollar y aplicar est\u00e1ndares de configuraci\u00f3n segura<\/strong> (hardening guides<\/em>) para todos los equipos de red, implementar gesti\u00f3n de configuraci\u00f3n<\/strong> con herramientas que detecten desviaciones de configuraciones aprobadas, realizar auditor\u00edas regulares <\/strong>de configuraci\u00f3n con revisiones trimestrales de configuraciones de seguridad, aplicar principio de m\u00ednimo acceso<\/strong> bloqueando todo por defecto y permitiendo solo lo expl\u00edcitamente necesario, separar redes de gesti\u00f3n con management plane<\/em> en red separada de data plane<\/em>, e implementar logging centralizado<\/strong> enviando todos los logs a SIEM<\/strong> para an\u00e1lisis de seguridad.<\/p>\n\n\n\n Las nueve vulnerabilidades que hemos analizado no aparecieron de la nada. Son manifestaciones de causas ra\u00edz profundas y sist\u00e9micas que CISA identifica como contribuyentes fundamentales a la inseguridad de sistemas de control industrial<\/strong>. As\u00ed como un \u00e1rbol, las vulnerabilidades visibles en la superficie tienen ra\u00edces profundas que las alimentan. Hemos visto en parte que muchas de estas vulnerabilidades tienen “justificaciones hist\u00f3ricas<\/strong>” pero adem\u00e1s de esto intervienen m\u00e1s factores, los cuales se abordar\u00e1n en posteriores art\u00edculos en este mismo blog Hacking ONESEC<\/strong>.<\/p>\n\n\n\n Por \u00faltimo quisiera compartirle algunas de las preguntas que la CISA sugiere hacer a los provedores o vendors:<\/p>\n\n\n\n Estas preguntas espec\u00edficas pueden ser referenciadas en documentos de CISA como “Cybersecurity Procurement Language for Control Systems<\/strong>” y “Questions to Ask Your Vendor<\/strong>” (Dentro del material 210W-07 ICS Cybersecurity Vulnerabilities).<\/p>\n\n\n\n Las nueve vulnerabilidades cr\u00edticas que hemos analizado no son fallas de seguridad aisladas que pueden ser parcheadas individualmente. Son manifestaciones sist\u00e9micas de decisiones de dise\u00f1o hist\u00f3ricas que ten\u00edan sentido en contextos aislados, pero que se han convertido en riesgos existenciales en el mundo hiperconectado actual. Sus causas ra\u00edz son profundas: sistemas heredados dise\u00f1ados para diferentes entornos de amenaza, arquitecturas de red optimizadas para disponibilidad sobre seguridad, presiones operacionales y financieras que priorizan la producci\u00f3n, y una cultura organizacional que todav\u00eda est\u00e1 aprendiendo a integrar ciberseguridad en operaciones.<\/p>\n\n\n\n El conocimiento de estas vulnerabilidades es el primer paso hacia la resiliencia. Los programas de CISA, los est\u00e1ndares de la industria como IEC 62443, y las mejores pr\u00e1cticas documentadas proporcionan una hoja de ruta clara. La tecnolog\u00eda para asegurar sistemas OT existe. El conocimiento de c\u00f3mo implementarla est\u00e1 disponible. Lo que frecuentemente falta es la voluntad organizacional de priorizar la seguridad al mismo nivel que producci\u00f3n, y el compromiso de invertir los recursos necesarios.<\/p>\n\n\n\n La pregunta para cada organizaci\u00f3n que opera infraestructura no es si pueden ser atacadas, sino cu\u00e1ndo. Y cuando ese momento llegue, la diferencia entre una interrupci\u00f3n menor y una cat\u00e1strofe operacional estar\u00e1 determinada por las acciones tomadas hoy para remediar estas vulnerabilidades conocidas.<\/p>\n\n\n\n La responsabilidad de proteger infraestructura cr\u00edtica es compartida, entre propietarios de activos, vendors, reguladores y la comunidad de ciberseguridad. Pero en \u00faltima instancia, cada organizaci\u00f3n debe tomar la decisi\u00f3n de actuar. El costo de la inacci\u00f3n, medido en t\u00e9rminos de riesgo operacional, impacto financiero, y potencial de da\u00f1o a la seguridad p\u00fablica, es simplemente demasiado alto para ser ignorado.<\/p>\n\n\n\n CISA Cybersecurity and Infrastructure Security Agency, Department of Homeland Security (CISA) – 210W-07 ICS Cybersecurity Vulnerabilities<\/a>. Recuperado el 7 de enero de 2026.<\/p>\n\n\n\n CISA Cybersecurity and Infrastructure Security Agency, Department of Homeland Security (CISA) – Cybersecurity Procurement Language for Control Systems<\/a>. Recuperado el 12 de enero de 2026.<\/p>\n\n\n\n![\"Comparativa](\"https:\/\/hacking.onesec.mx\/wp-content\/uploads\/2026\/01\/image.png\")
<\/figure>\n\n\n\nContexto y causas de vulnerabilidades en OT<\/h2>\n\n\n\n
El fin de la seguridad por oscuridad<\/h4>\n\n\n\n
Los activos en la mira<\/h4>\n\n\n\n
Activo<\/th> Breve descripci\u00f3n de funci\u00f3n<\/th><\/tr><\/thead> Dispositivos de red (switches, routers)<\/td> Gestionan el tr\u00e1fico, enrutamiento y segmentaci\u00f3n de la red.<\/td><\/tr> Controladores L\u00f3gicos Programables (PLCs)<\/td> Permite controlar dispositivos electromec\u00e1nicos y automatizar procesos industriales. <\/td><\/tr> Unidades Terminales Remotas (RTUs)<\/td> Conecta objetos del mundo f\u00edsico con un sistema central para su monitoreo y control remoto.<\/td><\/tr> Estaciones de Interfaz Humano-M\u00e1quina (HMI)<\/td> Panel o pantalla que conecta al operador con la m\u00e1quina para ver datos y controlarla.<\/td><\/tr> Servidores de adquisici\u00f3n de datos y Data Historians<\/td> Servidores que capturan variables de proceso y las almacenan cronol\u00f3gicamente para mantener un registro hist\u00f3rico y analizar el rendimiento de la planta.<\/td><\/tr> Estaciones de ingenier\u00eda<\/td> Donde se programa y configura el sistema.<\/td><\/tr> Dispositivos de acceso remoto<\/td> La puerta de entrada desde el exterior.<\/td><\/tr> Servidores de autenticaci\u00f3n y autorizaci\u00f3n<\/td> Controlan qui\u00e9n puede hacer qu\u00e9.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Listado de los 9 tipos de vulnerabilidades:<\/h2>\n\n\n\n
1. Calidad de c\u00f3digo Deficiente (Poor Code Quality)<\/h3>\n\n\n\n
\u00bfC\u00f3mo se explotan?<\/h5>\n\n\n\n
\n
Contramedidas clave:<\/h5>\n\n\n\n
2. Servicios Web Vulnerables (Vulnerable Web Services)<\/h3>\n\n\n\n
El ejemplo cr\u00edtico<\/h5>\n\n\n\n
Vulnerabilidades Comunes en Servicios Web ICS<\/h5>\n\n\n\n
![\"Gr\u00e1fico](\"https:\/\/hacking.onesec.mx\/wp-content\/uploads\/2026\/01\/Diagrama-de-vulnerabilidades-comunes-en-Servicios-Web-ICS-1024x576.jpg\")
<\/figure>\n\n\n\nContramedidas clave:<\/h5>\n\n\n\n
3. Implementaci\u00f3n Deficiente de Protocolos de Red (Poor Network Protocol Implementations)<\/h3>\n\n\n\n
![\"Representaci\u00f3n](\"https:\/\/hacking.onesec.mx\/wp-content\/uploads\/2026\/01\/Implementacion-deficiente-de-protocolos-de-red-1024x576.jpg\")
<\/figure>\n\n\n\nVulnerabilidades Cr\u00edticas en Implementaciones de Protocolos<\/h5>\n\n\n\n
\u00bfC\u00f3mo se explotan?<\/h5>\n\n\n\n
Contramedidas clave:<\/h5>\n\n\n\n
4. Gesti\u00f3n Deficiente de Parches (Poor Patch Management)<\/h3>\n\n\n\n
![\"Cami\u00f3n](\"https:\/\/hacking.onesec.mx\/wp-content\/uploads\/2026\/01\/Mala-gestion-de-parches--1024x576.jpg\")
<\/figure>\n\n\n\nCaso real<\/h5>\n\n\n\n
Contramedidas clave:<\/h5>\n\n\n\n
5. Autenticaci\u00f3n D\u00e9bil (Weak Authentication)<\/h3>\n\n\n\n
\u00bfC\u00f3mo se explotan?<\/h5>\n\n\n\n
Contramedidas clave:<\/h5>\n\n\n\n
6. Violaci\u00f3n del Principio de M\u00ednimos Privilegios (Least User Privileges Violation)<\/h3>\n\n\n\n
![\"Se](\"https:\/\/hacking.onesec.mx\/wp-content\/uploads\/2026\/01\/Violacion-del-principio-de-minimos-privilegios-1-1024x576.jpg\")
<\/figure>\n\n\n\n\u00bfPor Qu\u00e9 Se Viola Este Principio en OT?<\/h5>\n\n\n\n
\u00bfC\u00f3mo se explotan?<\/h5>\n\n\n\n
Contramedida clave:<\/h5>\n\n\n\n
7. Divulgaci\u00f3n de Informaci\u00f3n (Information Disclosure)<\/h3>\n\n\n\n
Tipos de Informaci\u00f3n Divulgada<\/h5>\n\n\n\n
\u00bfQu\u00e9 puede hacer un atacante?<\/h5>\n\n\n\n
Contramedidas clave:<\/h5>\n\n\n\n
8. Dise\u00f1o de Red Inadecuado (Network Design)<\/h3>\n\n\n\n
\u00bfC\u00f3mo se explota?<\/h5>\n\n\n\n
Contramedidas clave:<\/h5>\n\n\n\n
9. Configuraciones Inseguras de Componentes de Red (Network Component Configurations)<\/h3>\n\n\n\n
![\"Puerta](\"https:\/\/hacking.onesec.mx\/wp-content\/uploads\/2026\/01\/Configuraciones-inseguras-de-dispositivos-de-red--1024x576.jpg\")
<\/figure>\n\n\n\nConfiguraciones Inseguras Comunes<\/h5>\n\n\n\n
\u00bfC\u00f3mo se explota?<\/h5>\n\n\n\n
Contramedidas clave:<\/h5>\n\n\n\n
Pr\u00f3ximo tema – Causas ra\u00edz<\/h2>\n\n\n\n
![\"\"](\"https:\/\/hacking.onesec.mx\/wp-content\/uploads\/2026\/01\/image-2-1024x431.png\")
Preguntas para hacer a tu proveedor<\/h2>\n\n\n\n
\n
Conclusiones<\/h2>\n\n\n\n
Referencias<\/h2>\n\n\n\n