Press

Quedó claro que los sistemas instrumentados de seguridad también son blancos de ataque con motivo de causar y provocar severos daños a infraestructuras industriales con graves consecuencias.

El pasado mes de agosto de 2017 un ataque cibernético fue dirigido a los Sistemas Instrumentados de Seguridad en una instalación de petróleo y gas localizada en algún lugar del Medio Oriente.

Un nuevo malware identificado como TRITON (Bautizado por Fireeye), TRISIS (Bautizado por Dragos) o también conocido como HatMan, fue desarrollado para actuar sobre las funciones de seguridad de los sistemas TRICONEX con la finalidad de interferir en las protecciones de los sistemas poniendo en riesgo la planta de producción y la vida de las personas provocando daños en gran escala.

El malware fue desarrollado específicamente para actuar sobre los sistemas TRICONEX y TRICON fabricados por la empresa Schneider Electric (Originalmente Foxboro/Invensys). Sin embargo, el vector de ataque utilizado no sería exclusivo de esta marca ya que podría ser utilizado o modificado para actuar sobre otros fabricantes de sistemas instrumentados de seguridad.

El ataque a los Sistemas Instrumentados de Seguridad tuvo como resultado final, en esta ocasión, la parada de la planta. Sin embargo, los investigadores hallaron que los responsables buscaban modificar las funciones de seguridad configuradas y así provocar un incidente de mucha mayor magnitud. Un error en la intervención del sistema por parte de los responsables termina por provocar que el sistema entre en falla y por consiguiente automáticamente desencadena una parada segura de la planta.

De haber sido exitosos en el objetivo final seguramente hoy hubiésemos sido testigos de un incidente de magnitudes mayúsculas.

La empresa Schneider Electric luego de una rápida investigación puso a disposición del mercado un informe para advertir al mercado mundial y principalmente a otros usuarios, sobre dicho malware recomendando medidas inmediatas de seguridad para evitar que otras compañías sean víctimas del mismo tipo de ataque quizá con daños mucho más graves que el actual incidente. Los funcionarios de Schneider Electric anunciaron en su comunicado oficial que se trató de un incidente aislado. Sin embargo, recomendaron enfáticamente a todos los usuarios, que tomen medidas de seguridad al respecto.

Durante los últimos meses se han dado a conocer varias vulnerabilidades atribuidas a los microprocesadores que ponen en evidencia la importancia de disponer de sistemas con CiberSeguridad interna. Este tipo de vulnerabilidades nos están alertando de los potenciales riesgos cibernéticos en las tecnologías emergentes basadas en IoT e IIoT. Hace un tiempo difundimos un artículo muy interesante de MAXIM INTEGRATED sobre cripto-procesadores que se puede acceder desde aquí.

SPECTRE y MELTDOWN son dos vulnerabilidades recientemente descubiertas que afectan el hardware que se ejecuta en la mayoría de los dispositivos del mundo. Lo más probable es que cada usuario tenga un dispositivo afectado en su proximidad.

Casi todas las máquinas con un procesador moderno se ven afectadas, desde estaciones de trabajo hasta, sistemas de control, servidores, teléfonos y tabletas.

Esto incluye Microsoft Windows, Linux, Android, Google ChromeOS, macOS de Apple en procesadores Intel, ARM y sistemas embebidos. La mayoría de los chips INTEL fabricados después de 2010 son vulnerables, mientras que muchos chips AMD, ARM y otros también se ven afectados.

SPECTRE y MELTDOWN son vulnerabilidades diferentes, pero relacionadas. SPECTRE comprende dos vulnerabilidades: CVE-2017-5753: circunvalación de verificación de límites y CVE-2017-5715: inyección de blanco de ramificación, mientras que MELTDOWN consta de uno: CVE-2017-5754: carga de caché con datos falsos.

Estas vulnerabilidades hacen que los sistemas sean susceptibles a los llamados ataques de “canal lateral”, que se basan en la implementación de hardware físico y no atacan directamente la lógica o el código. Estos tipos de ataques generalmente incluyen a acciones tales como rastrear la radiación electromagnética (es decir TEMPEST), monitorear el consumo de energía, analizar luces intermitentes, análisis de caché, etc.

Dado que los dispositivos IT, IoT y IIoT son muy frecuentes y se actualizan con poca frecuencia, la presencia de dispositivos vulnerables puede permanecer en entornos de producción por varias generaciones venideras.

Si una de estas vulnerabilidades se utiliza para comprometer un dispositivo, esto podría dar a un atacante acceso a datos privilegiados en el sistema. Las vulnerabilidades no otorgan acceso al sistema; solo permiten a los atacantes leer datos que, de lo contrario, deberían restringirse. En otras palabras, un atacante aún necesita ingresar al sistema para ejecutar el ataque.

Mientras que esto puede sonar “alentador”, en realidad es una preocupación crítica en sistemas con múltiples usuarios, donde los datos de un espacio de memoria perteneciente a un usuario aún deben estar aislados de los demás.

En pocas palabras, en entornos compartidos o multi-tenant, como un entorno virtual, en la nube o cualquier otro entorno multiusuario, deben existir barreras estrictas entre los usuarios. De lo contrario, cualquier cliente en la nube podría acceder a los datos que pertenecen a otros clientes que comparten la misma CPU.

La misma compartimentación se produce dentro de las aplicaciones, que deben aislarse unas de otras. Por ejemplo, un navegador web no debe tener acceso directo a los datos que usa el sistema operativo Windows para almacenar contraseñas u otra información confidencial.

Todos los sistemas operativos implementan múltiples niveles de seguridad para evitar que ocurra este comportamiento, incluidos Windows UAC, SELinux y más. Por esa razón, resulta que las vulnerabilidades de SPECTRE y MELTDOWN pueden no ser tan malas como se las ha reportado, especialmente si no eres un usuario de la nube.

En los dos videos siguientes se explican las vulnerabilidades de SPECTRE y MELTDOWN de forma simple pero muy clara y concreta. La noticia es que mientras los parches están siendo desarrollados y publicados en los sistemas operativos para evitar este problema, estos provocan demoras en los sistemas. La vulnerabilidad aprovecha una técnica creada en los microprocesadores modernos que les permite adelantar parte del trabajo para mejorar su rendimiento.

En caso de que estos cálculos anticipados no sean necesarios el sistema los descarta y elimina dejándolos en zonas de memoria desprotegidas al alcance de otras aplicaciones y/o usuarios no autorizados.

Imaginemos, por un momento, que ha sido recientemente galardonado con: Spectre Meltdown Mindreading Capability

Para simplificar, vamos a llamarlo SMMC. SMMC le da el ‘poder’ para leer la mente de otra persona, siempre y cuando ambos estén en la misma habitación.

Su SMMC puede funcionar en casi cualquier persona, en cualquier lugar: el centro comercial, el teatro e incluso las mesas de póquer en Las Vegas. Independientemente de su ubicación, puede leer la mente de los demás, siempre y cuando esté en la misma habitación que ellos. Ahora tiene acceso a datos que deben ser privados, como secretos, información confidencial o crítica, y más.

SMMC no funciona de forma remota; debe estar cerca de la otra persona y en la misma habitación. Además, debe tener permiso para ingresar a esta sala (es decir, en Las Vegas, debe tener al menos 21 años para ingresar a ciertos casinos).

Ahora, imaginemos un escenario diferente: usted está en su propia habitación, usted mismo, y usa SMMC para obtener acceso a sus propios datos. Además del potencial estallido del reflejo mental, ¿qué sentido tiene ejecutar un ataque en tu propia mente? Ya tiene acceso a los datos, y puede recuperarlos a voluntad.

En pocas palabras, esa es la idea detrás de SPECTRE y MELTDOWN. Son efectivos en una sala de múltiples inquilinos donde los secretos de más de una persona deben mantenerse en privado.

Sin embargo, no tiene sentido ejecutar un ataque en una habitación con un solo propietario, ya que, técnicamente, no hay secretos. Mientras seas la única persona que alguna vez ocupe la habitación, tus datos estarán seguros, aunque sigas siendo vulnerable al ataque.

Una explicación técnica bien detallada requiere conocimientos de programación en microprocesadores. En este LINK tendrá acceso a información relevante publicada por los descubridores de estas dos vulnerabilidades que afecta a todos los microprocesadores modernos del mercado, salvo aquellos que sean cripto-procesadores.

SPECTRE y MELTDOWN han generado cobertura en los medios convencionales debido a la gran cantidad de sistemas que han impactado. Casi todos poseen un dispositivo que es vulnerable al ataque.

Sin embargo, ser vulnerable no significa necesariamente que este le afectará en sus sistemas de la planta. A veces, como en el caso del parche de Microsoft, la cura causa el dolor, no el ataque en sí mismo. Como se sugiere en la norma ANSI/ISA99/IEC-62443 las acciones de mitigación deben ser el resultado de una evaluación de riesgos cibernéticos en OT y un análisis de criticidad además de un cuidadoso proceso de instalación y de gestión de cambios.

Un claro ejemplo es el impacto del parche MELTDOWN/SPECTRE en Rockwell Factory Talk, que provocó interrupciones en los servidores FactoryTalk.  A partir de ahora, el parche aún no ha sido probado por Rockwell, y actualmente no está aprobado para su uso en ningún sistema FactoryTalk (puede que no sea por un tiempo …). En el caso de Wonderware el parche afectó al tradicional histórico de planta. La actualización de Microsoft “KB4056896” a generado consecuencias inesperadas para el líder de software SCADA provocando inestabilidad en el sistema y bloqueo del acceso a los servidores de datos.

Las mitigación es todavía un tema de considerable debate. Algunos han tenido un impacto negativo en el rendimiento, inutilizando los sistemas y creando otros problemas que aún están siendo resueltos por varios proveedores y comunidades de usuarios. Algunos parches ya no están disponibles para el público y aún no se han vuelto a emitir.

Los ataques a los sistemas industriales son cada vez más sofisticados capaces de causar cada vez más daños. Al inicio los ataques se concentraban en las capas más altas de las redes industriales y tecnologías comerciales de IT, mientras que en los últimos años los ataques han golpeado sobre las redes más bajas y propietarias de los sistemas de control y tecnologías de OT. Los daños provocados por año, ante la misma cantidad de incidentes, se han incrementado en 10 veces!

Los entornos industriales poseen una gran variedad de equipos, de los cuales algunos de ellos suelen incluir a los siguientes:

• Estaciones de Operacipon.
• Estaciones de Ingeniería.
• Servidores sobre Windows (DNS, AD, etc.)
• Servidores sobre Linux (historiadores, firewalls, sistemas de automatización)
• PLCs de varios fabricantes
• DCSs de varios fabricantes
• Sistemas Instrumentados de Seguridad
• Sistemas de Control de Motores CCM
• HMI de varios fabricantes
• Interruptores en estaciones eléctricas
• y muchos otros dispositivos con sistemas embebidos

Casi todas las redes de ICS son vulnerables al ataque. Que un dispositivo específico esté o no en riesgo depende de múltiples factores, como el conjunto de chips, el nivel de firmware, etc. No está demás decir que podemos esperar una investigación sustancial y parches en el futuro cercano.

Muchos HMI, paneles y pantallas utilizan los microprocesadores afectados. La gran mayorías de los fabricantes sistemas industriales todavía están evaluando la amenaza. Muchos sistemas que admiten controladores industriales como sistemas de automatización, sistemas de control de lotes, servidores de control de producción, impresoras, sistemas OPC, sistemas SCADA, dispositivos periféricos y dispositivos IIoT, incluidas cámaras, sensores, etc., son los más vulnerables.

Se trate de sistemas nuevos que serán incorporados en las plantas industriales y que luego deberán ser soportados por décadas, o bien se trate de sistemas industriales existentes tendremos que tomar una decisión para mitigar los riesgos asociadas a este tipo de amenazas. Lo mismo que sucede con otras amenazas.

En el ámbito industrial existen tantos dispositivos inteligentes distribuidos en la planta que no podemos tratar a todos por igual. Una evaluación de riesgos cibernéticos para ámbitos industriales es de un valor sustancial para determinar las acciones correctas. Esta evaluación nos proveerá de los elementos necesarios para tomar decisiones y determinar los requerimientos de seguridad cibernética para satisfacer el nivel de riesgo tolerable por la organización. Una buena evaluación de riesgos dará los elementos necesarios para no gastar de más ni invertir de menos.

La segmentación de los sistemas industriales en Zonas y Conductos nos permitirá crear sistemas industriales seguros por diseño. Existen muchos tipos de vulnerabilidades en todas las etapas del ciclo de vida de los sistemas, desde el diseño y concepción, pasado por las etapas de construcción, configuración, instalación, puesta en marcha, la operación y el mantenimiento. Muchas personas creen que la tecnología tiene todas las respuestas a la seguridad cuando en realidad esto es completamente falso. La metodología de ISA99 registrada ANSI/IEC-62443 nos garantiza una seguridad óptima por diseño que satisface las necesidades de la organización a la medida de cada Zona y cada Conducto.

La forma más práctica consiste en incorporar sistemas industriales con Seguridad Cibernética intrínsecamente embebida dentro del equipo (BUILT-IN, por su definición del inglés) evitando la necesidad de tener que incorporar Seguridad Cibernética Agregada. Los sistemas con tecnologías de Seguridad Cibernética embebida proveen de varias ventajas para los usuarios finales e integradores. Estas ventajas se resumen en (a) menor costo de propiedad del sistema. (b) menor coste de la seguridad, (c) mayor confiabilidad del sistema – menor tasa de fallas, (d) mayor vida útil, (e) mayores de nivel de seguridad cibernética para satisfacer los más elevados requerimientos.

Un claro ejemplo de este tipo de soluciones los podemos encontrar en los sistemas de BEDROCK AUTOMATION. Para sistemas nuevos la mejor forma y más segura consiste en la implementación de sistemas industriales con CiberSeguridad embebida como la de BEDROCK. Estos sistemas de BEDROCK han sido concebidos con Cripto-Procesadores haciendo que este tipo de vulnerabilidades sean virtualmente imposibles. La tecnología de BEDROCK permite a los usuarios crear una Red de Confianza (ROOT OF TRUST) que se puede extender al respecto de la organización.

Los vectores de ataque a los sistemas industriales son cada vez más sofisticados. El exponencial crecimiento del mercado negro en el descubrimiento y el notable interés por utilizar estos métodos cada vez más sofisticados hacen pensar que las tecnologías de los sistemas sin Ciber-Seguridad embebida serán un juego de niños para los chicos malos en apenas unos pocos años. Mucho antes de que estos sistemas piensen en ser reemplazados.

Para los sistemas ya instalados en primer lugar, ser consciente de lo que existe en su entorno industrial es fundamental para asegurarlo con éxito. No podrá proteger lo que no conoce. A su vez, tener un inventario de activos automatizado en su caja de herramientas es esencial para entender qué equipo está en riesgo y requiere atención.

Tener visibilidad en profundidad de su inventario de activos es vital. Sin esto, se queda con una lista de dispositivos industriales que deben examinarse manualmente para determinar si su módulo de hardware específico se ve afectado.

Un inventario de activos automatizado es clave para identificar activos vulnerables y seguir los esfuerzos de su mantenimiento. Una solución de CiberSeguridad industrial como la de INDEGY recopila automáticamente esta información de dispositivos industriales y la pone a disposición en su Inventario de activos.

Finalmente, para explotar estas vulnerabilidades, un atacante necesita acceso a la red. Esto enfatiza la importancia de tener un sistema de monitoreo de red, que le permita identificar a cualquier persona que se conecte a la red, comunicándose con o modificando activos clave.

Los sistemas de aplicación de parches en entornos industriales de ningún modo son un proceso trivial, ya que a menudo se requieren estos sistemas para garantizar la seguridad y la estabilidad de los procesos industriales.

Podemos ayudar a las organizaciones con el proceso de parches de dos maneras:

• Para la supervisión del progreso de parchado INDEGY le permite ver qué sistemas se han parcheado y cuáles son aún vulnerables. Si un sistema no está parcheado por error, el sistema de INDEGY le informará sobre esto.
• Para el monitoreo de personal y sistemas involucrados en la aplicación de parches existe la posibilidad de que varias personas implementen varias mitigaciones, parches, actualizaciones de firmware, etc. en una variedad de plataformas, desde estaciones de trabajo hasta servidores, PLC, HMI y dispositivos IIoT. Esto puede dar como resultado que varias personas, en una variedad de funciones, de diferentes organizaciones entren potencialmente en su entorno de producción. ¿Cómo sabrá en qué está trabajando cada persona? ¿Puede alguna de sus actividades causar interrupciones en sus procesos industriales? ¿Qué pasa con el uso de portátiles de terceros no administrados que pueden verse comprometidos? ¿O casos en los que se abren conexiones remotas para habilitar el trabajo necesario? Todos estos pueden exponer sus sistemas industriales a amenazas no deseadas.

Con la plataforma de INDEGY, se puede monitorear los sistemas industriales de forma segura a medida que los empleados y contratistas externos entran y salen de la planta, o cuando se conectan y desconectan de su red. La plataforma le permite realizar un seguimiento de todas sus actividades y recibir alertas en tiempo real sobre cualquier actividad no autorizada o sospechosa.

Indegy le permite confirmar que sus sistemas de control industrial de misión crítica no han sido tocados por usuarios no autorizados, y que no se cometieron errores al intentar actualizar sus sistemas. Póngase en contacto con nosotros si desea obtener más información sobre cómo proteger a los sistemas de control industrial.

San José, California, Estados Unidos — 12 de octubre de 2017 — Bedrock Automation ha ganado el premio Vaaler de la revista Chemical Processing por el sistema de automatización Abierto y Seguro (OSA, Open Secure Automation), el primer sistema de control industrial universal que se diseñó con seguridad cibernética intrínseca. Bedrock es uno de los dos únicos ganadores del prestigioso premio, que se ofrece sólo una vez cada dos años.

“Establecimos los premios Vaaler en 1964 para reconocer productos que prometen una mejoría significativa en las operaciones de las plantas químicas y la economía. Nuestro panel de jueces imparciales seleccionó el sistema de control Bedrock porque aborda las cuestiones operacionales y económicas ofreciendo un sistema de seguridad cibernética incorporado a su electrónica. Felicitamos a todo el equipo de Bedrock”, dijo Mark Rosenzweig, redactor jefe de Chemical Processing.

El premio rinde homenaje a John C. Vaaler, Presidente del Consejo editorial de Chemical Processing desde 1961 hasta su muerte el 1963. Los jueces de este año representaron a expertos en ingeniería, seguridad y sostenibilidad de algunas de las principales compañías químicas del mundo. Seleccionaron el sistema de automatización segura, basado en su significado técnico, su singularidad y amplitud de aplicabilidad.

A diferencia de los principales diseñadores de control de automatización, cuyos sistemas se basan en arquitecturas fundamentales implementadas antes de que la seguridad cibernética fuera un problema, los diseñadores de Bedrock comenzaron su solución de seguridad cibernética con una hoja de papel en blanco con nuevas y mejores requerimientos fundamentales. El control resultante y la arquitectura de E/S ofrece una placa de electromagnética sin Pines, seguridad cibernética profundamente incrustada y potencia computacional que sobrepasa los sistemas convencionales de PLC, RTU o DCS.

“Estamos muy honrados de haber sido reconocidos por nuestros esfuerzos para llevar un sistema de control muy necesario, simple, escalable y seguro para el mercado. Nos complace especialmente haber sido seleccionados por un panel de jueces que representan a algunas de las compañías químicas más respetadas del mundo “, dijo el fundador y CEO de Bedrock, Albert Rooyakkers.

Publicación Original por Bedrock Automation Aquí

WisePlant HQ – A WiseGroup Company – firmó un contrato para el patrocinio de la seccion de ISA Sección San Pablo confirmando la confianza en sus actividades. Ambas entidades están seguras de que esta asociación será muy exitosa!

ISA Sao Paulo es una de las secciones más desarrolladas en Sudamérica que organiza eventos, cursos de capacitación, congresos, libros técnicos con la finalidad de difundiar las mejores prácticas en intrumentación y control y facilitar la vinculación de los profesionales de la comunidad con nuevas oportunidades para el aprendizaje, el desarrollo continuo y nuevas oportunidades de crecimiento.

WisePlant fue fundada en 2012 por un grupo de profesionales y empresarios que decidieron su creación para proporcionar soluciones innovadoras con productos y sistemas de tecnologías seguras para la infraestructura industrial crítica y el desarrollo de ciudades digitales seguras. Nuestras áreas de experiencia, soluciones y servicios incluyen la instrumentación, automatización, control, ingeniería, software, redes de OT, la ciberseguridad industrial, consultoría y servicios profesionales con muchos años de experiencia consolidando un equipo de trabajo multidisciplinario y orientado a proporcionar soluciones tecnológicas de la más alta calidad.

Junto con los integradores de sistemas especializados, ayudamos a seleccionar la tecnología a utilizar y proporcionar servicios específicos para implementar las soluciones de acuerdo con las mejores prácticas y metodología probada proyectos de implementación tanto requeridos para cada proyecto y para el suministro de productos.

Nuestro equipo de técnicos e ingenieros han trabajado en grandes proyectos para empresas internacionales en América Latina. Nuestro conocimiento y tecnología se aplican en diversas industrias tales como petróleo y gas, química, petroquímica, minería, metales, alimentos, bebidas, automotriz, farmacéutica y otras.

Para obtener más información sobre las actividades que desarrolla ISA Sección Sao Paulo, visite www.isasp.org.br 

¡Prepárese! ¡Ya está aquí! El Programa para Partners e Integradores de Sistemas de WiseGroup, que lanzamos especialmente diseñado para el mercado sudamericano. Acumulamos más de 20 años de experiencia habiendo trabajado con canales en la región, en un nuevo extraordinario programa.

No tenemos ninguna duda que este será el programa del canal más destacado del sector. Un programa Simple, Predecible, y Rentable. Un programa para destacar. Un programa para superar.

Cuando dimos a conocer el programa para partners de WiseGroup, anunciamos los tipos de niveles: Agente, Registrado, Certificado y Premier.

1. Desde que se haya registrado en nuestro programa recibirá diversos cursos de entrenamiento para sus profesionales sobre todos los productos y sistemas distribuidos por WisePlant. Más de 10 Cursos de capacitación disponibles además de todas las herramientas necesarias para que el Integrador adquiera una buena autonomía y confianza.
2. Sabemos que la mejor forma para ser exitosos es que todos estamos comprometidos. Por eso que no somos amigos de las relaciones oportunistas. Los leads que recibamos de clientes interesados serán canalizados a través de integradores Certificados. Nosotros no realizamos integración de sistemas y es por esto motivo que el 100% de los proyectos deben ser ejecutados por Integradores de Sistemas capacitados.
3. Indendientemente de que el Integrador de Sistemas Certificado adquiera una gran cantidad de conocinientos y autonomía, tanto comercial como técnica, siempre estaremos acompañando y soportando sus actividades para el éxito.

Nuestro compromiso es de ser transparentes y mantenerlo informado durante el proceso de desarrollo. Hoy, nos complace compartir nuestra estrategia para integradores y sus niveles, en una metodología adecuada a su organización con el apoyo de los fabricantes representados por WiseGroup.

El pasado 20 de Diciembre, 2016 – La revista Processing nombra a la Fuente de Energía SPS.500 de Bedrock Automation como un Producto Innovador del 2016. Processing reconoce al producto por su diseño único, que une CiberSeguridad y conexión Ethernet en una fuente de energía para sistemas de críticos, de alta resistencia y alto rendimiento.

El editor en jefe de la revista Processing, Lito Ditoro, dijo: “Las fuentes de energía están entre los componentes de un sistema de control de procesos con mayor tendencia a fallar, y de los más vulnerables a los ataques cibernéticos. La SPS.500 de Bedrock nos impresiona, no solo por su diseño, sino porque también parece ser el único producto que aborda este problema.”

Bedrock Automation diseñó la fuente de energía SPS.500 independiente para ser la más segura, inteligente y duradera disponible al dia de hoy. Hace de la fuente de energía, una participe viable de la industria del internet de las cosas, al proveer las siguientes características, poco comunes en fuentes de energía actuales:

• Protección de ciberseguridad intrínseca.
• Comunicaciones de Ethernet y OPC/UA, permitiendo monitoreo local y remoto de la salud de la fuente de energía.
• Un poderoso microprocesador ciber seguro, y memoria incorporada para diagnósticos y funcionalidad definida para el software.
• Un módulo de redundancia integrado que simplifica la instalación y aumenta la fiabilidad.
• Dos relays de contacto tipo C incorporados, configurables por software, para el estado operativo y de diagnóstico.

El fundador, CTO y vicepresidente de ingeniería de Bedrock, Albert Rooyakkers dijo: “Cuando nos propusimos a diseñar nuestro sistema de control, empezamos con una hoja de papel en blanco, y lo construimos con simplicidad, escalabilidad y seguridad desde el principio. Extendimos este principio más allá del controlador, llevándolo al ambiente de ingeniería, a las entradas y salidas, y a la fuente de energía. Nuestros equipos de ingeniería se dedican a entregar la CiberSeguridad más completa posible, y el reconocimiento de este esfuerzo por la revista Processing es realmente gratificante para todos nosotros.”

Para ver información del Sistema de Energía SPS.500 de Bedrock siga AQUI

Para hablar de Convergencia entre los ambientes de IT y de OT deberíamos antes aclarar que este no es un tema nuevo. Desde hace décadas que se viene desarrollando la convergencia. Se han ido incorporando las tecnologías de IT en los ámbitos industriales y con importantes beneficios. Resulta difícil encontrar en el mercado un criterio común al respecto de este tema ya que la palabra convergencia es empleada de muchas formas y con diferentes objetivos. En los últimos años con la nueva tendencia de CiberRiesgos en los Sistemas Industriales, habituales en el ambiente de IT, vuelve a agitarse el tema.

Históricamente, la tecnología de la información y la tecnología operacional se han desarrollado por caminos independientes, con diferentes objetivos y responsabilidades, operando en ambientes muy distintos. Sin embargo, hubo y aún hay mucho que ganar, alineando e integrando el trabajo entre ambos. La tecnología de OT involucra a numerosos sectores e industrias, donde cada uno tiene sus propias normas, tecnologías, requerimientos, etc. Con la creciente sofisticación y aplicación de tecnologías de redes inteligentes en la industria, aplicaciones de TI trabajan en sincronismo con aplicaciones de OT para aumentar el rendimiento, mejorar la eficiencia operacional con la eliminación de los silos de información, la mejora de los procesos, reducción de costos, incremento de la seguridad, entre otros beneficios.

La gran mayoría de las industrias han desarrollado y gestionado OT e IT como dos dominios diferentes (que de hecho lo son), donde cada uno mantiene tecnología, protocolos, estándares, modelos de gobernanza y unidades organizativas. Durante las últimas dos décadas, OT ha ido adoptando progresivamente tecnologías de IT, como IP (Internet Protocol), que ha ganado aceptación como un protocolo de red común, y Microsoft Windows que es más frecuente en una amplia gama de sistemas. En la actualidad se requiere de una gestión de gobernanza más integrada, que no es lo mismo que decir “comunes”, ya que las mismas reglas no son válidas en ambos dominios, y disponer de equipos de trabajo con profesionales de ambos dominios.

La integración o convergencia entre IT y OT se viene desarrollando desde hace por lo menos dos décadas, habiendo tomado un muy fuerte impulso la incorporación de redes industriales y el uso de protocolos industriales basados en TCP/IP, como así también en la incorporación de sistemas operativos comerciales, tales como Microsoft Windows, en una gran cantidad de sistemas.

Para una descripción más comprensiva de IT y de OT, debemos hacer referencia a una de las normas de ISA, conocida como ISA95, que define un modelo para el intercambio de información entre los ambientes de IT y de OT. ISA es una organización sin fines de lucro que desarrolla estándares aceptados globalmente en todos los sectores industriales y de todas partes del mundo. ISA95 se compone de modelos y terminología que puede utilizarse para determinar la información a ser intercambiada entre sistemas comerciales (por ejemplo, finanzas y logística), sistemas de producción, mantenimiento y calidad. La información se estructura modelando los procesos, que también sirven como base para el desarrollo de interfaces entre sistemas de IT y OT. Existen en la norma mecanismos y procesos específicos para realizar dichos intercambios con validaciones y confirmaciones. Es muy buena práctica emplear una Zona de Intercambio de Información denominada como Nivel 3,5 estableciendo una Zona Demilitarizada o DMZ.

Históricamente, el diseño de sistemas de OT tuvo que cumplir con requisitos específicos incluyendo la disponibilidad en tiempo real y la introducción de datos técnicos, como temperatura y presión, así como resistencia a condiciones ambientales de trabajo muy agresivas, como la humedad, corrosión, interferencias electromagnéticas severas y la vibración. En el pasado, las comunicaciones Ethernet y TCP/IP no eran consideradas una opción para OT debido a su fragilidad y otras limitaciones técnicas. Desde entonces, y con el aumento de las velocidades, esto ha cambiado dramáticamente. Dispositivos recientes que soportan TCP/IP y otras formas de conexión Wi-Fi (IEEE 802.11) de red pueden cumplir la mayoría de requisitos de OT. Si bien es cierto que las Redes Industriales basadas en tecnologías de IT se han ido incorporando de forma progresiva, al momento de analizar la totalidad de las Redes del tipo industriales, estas no llegan a cubrir la cuarta parte. Es decir que, a pesar de la gran aceptación tres cuartos de las redes Industriales no son TCP/IP. Además de ello el hecho de que sean basadas en TCP/IP las compañías y proveedores de automatización han agregado funciones específicas, poco comunes para los ambientes de IT, aun basados en TCP/IP. Las redes industriales requieren de un comportamiento determinístico. Por lo tanto, los fabricantes agregan funcionalidades para construir protocolos con un comportamiento cercano al “determinístico” aun basadas en TCP/IP. El diseño de estas Redes industriales, tienen requerimientos específicos que resultan inusuales en los ámbitos de IT.

Otro importante alineamiento se refiere a los sistemas operativos (OSs). Tradicionalmente, una elección necesaria entre tiempo compartido (IT) y sistemas operativos en tiempo real (OT). Con el aumento de capacidad de sistemas embebidos y el despliegue de arquitectura dirigida por eventos (‘RT-SOA’ o en tiempo real Service Oriented Architecture), un creciente uso del tradicional OS (Unix-like o Windows MSFT) fue siendo integrado en el entorno de OT. Este tipo de restricciones tecnológicas históricas condujo al desarrollo de un conjunto completo de normas específicas de OT, que cubren las áreas de comunicaciones, seguridad industrial, automatización, mediciones, y muchas otras hasta los procesos de integración IT/OT. La mayoría de estas normas son ahora de facto y promovidas por grandes fabricantes de OT, como Siemens, Rockwell, Emerson, ABB, Yokogawa, GE, Schneider y tantos otros.

La incorporación de DOS, Windows NT, Windows 32, la creación de OPC (OLE for Process Control), y así sucesivamente en los ambientes industriales vienen siendo una clara demostración de esta convergencia. La creación de innumerables protocolos industriales basados en tecnologías Ethernet TCP/IP. La propia creación de la norma ISA95, como muchas otras normas, son también una clara evidencia de la necesidad y conveniencia por la convergencia.

OPC Foundation, en la actualidad una organización mundial soportada por un gran número de compañías de todas partes del mundo, fue creada en el año 1995 por 5 empresas innovadoras líderes con una clara visión de futuro. Estas empresas fueron: Microsoft, Intellution, Opto22, Camstar, y SAP. Si bien OPC es un protocolo industrial basado en TCP/IP este contiene características y funciones inusuales para los ambientes de IT.

En la industria de OT como en IT, hemos sido testigos del famoso Y2K, donde muchos “expertos” nos decían que los sistemas fallarían, si no hacíamos un up-grade, por un problema de la cantidad de dígitos en el manejo de las fechas por los dispositivos. Las consecuencias que esto ocasionaría podrían provocar daños de alcances impredecibles.

La incorporación de los Buses de Campo Industriales basados en la comunicación inalámbrica, como los protocolos industriales Wireless HART e ISA100, también son una clara evidencia de la incorporación de las tecnologías inalámbricas en el ámbito industrial. En un principio empleados únicamente para la lectura de datos y progresivamente cada vez más utilizados para funciones de control.

Podemos seguir enumerando ejemplos de que la Integración y Convergencia de IT/OT se inició hace ya mucho tiempo y ha ido creciendo de forma constante. No hay duda de ello. La cuestión es, cómo continuará este proceso de integración y convergencia hacia adelante.

La falta de conocimiento y de investigación, también genera inversiones erradas y la implementación de soluciones ineficientes. Cuántos profesionales hablan de las normas y las tecnologías como si las conocieran de toda la vida, y nunca han leído ni una sola página de ellas. Repiten lo que alguien dijo sin conocer adecuadamente el origen ni sus fundamentos. La mejor forma de combatir esta realidad inevitable es por medio de la Capacitación.

Muchos creen que los incidentes a la CiberSeguridad Industrial provienen del ambiente de IT y más aún, estos son una consecuencia de haber aceptado las tecnologías comerciales de IT en el ámbito industrial. Lo cual es falso. En la actualidad las tecnologías y los sistemas industriales son mucho más vulnerables que los sistemas industriales basados en las tecnologías de IT. Lo que sucede es que ahora hay interés por aprovechar estas vulnerabilidades para causar daño u obtener algún tipo de beneficio. Antes esto no era una preocupación como si lo es en la actualidad.

Industrial Internet of Things (IIoT) o bien Industry 4.0 como también se vienen desarrollando son otra clara evidencia de este avance constante de la convergencia entre los ámbitos de IT y de OT. Esta es una tendencia irreversible y sería una necedad negarla.

Si bien existen definiciones de IT y OT como en el caso de las normas de ISA, OT se asocia típicamente con dispositivos de campo conectados a los procesos y la infraestructura para la vigilancia y control de los procesos industriales. Esto incluye sistemas DCS (Distributed Control Systems), SIS (Safety Instrumented Systems), ESD (Emergency Shut Down Systems), PLC (Programmable Logic Controllers), Control de supervisión y adquisición de datos SCADA (Scan, Control And Data Acquisition Systems), sistemas de gestión de distribución DMS (Distribution Management Systems), Sistema de detección de pérdidas en ductos LDS (Leak Detection Systems), AMS (Assets Management Systems), y muchos otros. La mayoría de estos sistemas están ejecutando acciones del tipo dispositivo-a-dispositivo, o dispositivo-a-sistemas de forma automática con muy poca interacción humana.

IT se asocia tradicionalmente con sistemas de información back office usados para la realización de transacciones de tipo de negocio, como costo impuestos contabilidad, facturación y recaudación de ingresos, seguimiento de activos y depreciación, registros de recursos humanos y tiempo y registros de clientes. Entrada manual de datos a menudo está implicado, y los recursos informáticos han tendido a centrarse en oficinas, salas de servidores y data centers corporativos.

Desde los ámbitos de IT existe una generalización por denominar a los sistemas industriales, como si todos fuesen sistemas SCADA, lo cual es incorrecto y un claro desacierto. Los sistemas SCADA tienen un uso muy específico en las industrias y representan solamente una porción pequeña de los sistemas industriales. También existe la idea de que la protección de los sistemas industriales debe ser realizada sobre las redes TCP/IP y sobre los Sistemas que utilizan Sistemas Operativos Windows. Lo cual también es otro gran desacierto. Las estadísticas de los incidentes industriales suministrados por organizaciones dedicadas a la CiberSeguridad Industrial, reflejan que menos del 5% son generados en las tecnologías de IT. Por otro lado, los acercamientos propuestos por muchas organizaciones con amplia experiencia en la Seguridad de la Información proponen un acercamiento errado al momento de abordar la CiberSeguridad Industrial. Es más, en algunos casos hemos visto que las medidas propuestas por sectores de seguridad de IT se vuelven en una verdadera amenaza para la Seguridad Industrial.

El incidente ocurrido en Ukrania el pasado 23 de diciembre de 2015, pone en evidencia la ineficiencia en las implementaciones de protecciones parciales sobre las redes industriales. Ukrania, uno de los países, supuestamente mejor preparados en materia de CiberSeguridad, CiberGuerra y/o CiberDefensa, fue prácticamente puesto en ridículo al resultar víctimas de un CiberAtaque en sus redes de distribución eléctrica en la zona Oeste del país, además de las pérdidas económicas enormes. Se puede acceder al Caso de Estudio en el link al final de la nota.

Cada sector industrial tiene su propia característica, y típicamente en cada tipo de industria vamos a encontrar protocolos, tecnologías y normas específicas para cada uno de estos segmentos, tales como, petróleo & gas, farmacéutico, energía eléctrica, alimentos, aguas, etc. Cada uno con sus particularidades y muchas especificidades.

Solamente por comentar uno de ellos, los sistemas de distribución eléctrica se han constituido con un alto grado de inteligencia de OT por mucho tiempo, en el desarrollo de los reguladores de voltaje, LTCs (cambiadores de carga), Bancos de interruptores, reconectadores, seccionadores, interruptores de ruptura de carga y relés electromecánicos con inteligencia local. Se están convirtiendo en sistemas cada vez más sofisticados y el nivel de datos OT para las organizaciones de distribución eléctrica sigue aumentando con muchos más dispositivos inteligentes en comunicación que se añaden a las redes casi de forma constante.

El amplio desarrollo tecnológico en ambos dominios de IT y OT en organizaciones industriales reclama una mejora organizacional integral que incorpore a la CiberSeguridad Industrial. Los silos de información entre los ambientes de IT y OT no son un problema, ya que las redes de IT y OT están interconectadas en la amplia mayoría de las industrias. Surge la urgente necesidad de crear políticas y medidas para la protección de la CiberSeguridad Industrial, y esta debe ser encarada como un trabajo conjunto entre ambos dominios de IT y de OT. Esto es un desafío tanto para los profesionales de IT que desconocen el dominio industrial como para los profesionales de OT que son normalmente más renuentes a ser usados como conejillos de indias en la implementación de nuevas tecnologías.

La CiberSeguridad Industrial o mejor dicho los riesgos a la Seguridad en la industria como consecuencia de las vulnerabilidades tecnológicas de los sistemas, está agitando nuevamente el debate sobre la convergencia entre IT/OT.

En la actualidad, no termina de salir y madurar una tecnología que ya está saliendo otra nueva superadora de la anterior. ¿Cómo se puede superar a una tecnología inmadura con una nueva tecnología aún más inmadura? Cuando en el ámbito de IT existe una tendencia a seguir la ola e incorporar las nuevas tecnologías con avidez en los ámbitos industriales, se requiere que estas pasen antes por un proceso de maduración mayor, y con más razón, antes de incorporarlas en los ambientes críticos.

Podemos llegar a decir que estos temas han sido el disparador que trae nuevamente sobre la mesa la mayor cantidad de discusiones respecto de la convergencia. Para comprenderla debemos volver a las bases. Cuando hablamos de CiberSeguridad Industrial, en OT la prioridad está enfocada en la Disponibilidad, mientras que en el ámbito corporativo la prioridad está enfocada en la Confidencialidad de la información. Fiel a cada Dominio cada ambiente continuará manteniendo su esencia. La principal diferencia que existe en el ámbito industrial es que los sistemas de control tienen un impacto sobre el mundo físico y por lo tanto la seguridad física es lo primordial. Solo por mencionar una de las muchas diferencias. Por mucho que se fuerce la convergencia No va a cambiar las características esenciales de ambos ambientes.

La CiberSeguridad Industrial representa un desafío para las organizaciones de cualquier industria, lo mismo que para una nación preocupada por la seguridad de su infraestructura crítica y de su población. No importa que los profesionales provengan de los ámbitos de IT o de OT, la CiberSeguridad Industrial será altamente desafiante para ambos perfiles de profesionales.

Es un error pensar a la CiberSeguridad Industrial o de OT como un anexo o extensión de la CiberSeguridad para IT. Como así también es un error pensar que los sistemas de OT no presentan riesgos y que estas son solo creadas en los ambientes y tecnologías IT. Puesto que estos dos enfoques son incorrecto y falso.

Las vulnerabilidades en los Sistemas Industriales están en todos los niveles. No solamente en las redes industriales basadas en TCP/IP, también están en los PLCs, en los protocolos industriales seriales, en los protocolos de las redes de control, en las redes inalámbricas, en los sistemas de cableado, etc.

La Matriz de CiberSeguridad de OT, solamente en América existen más de 30 normas, guías y marcos de referencia, destinadas a la CiberSeguridad Industrial e infraestructuras Críticas. En la mayoría de los artículos y notas que observamos, muchos suelen llamarles a todas ellas como normas, cuando en realidad no lo son, y son todas diferentes. Comprender las diferencias entre ellas no es una tarea menor. Para proteger a las redes industriales de forma efectiva y eficiente se requiere de un enfoque metodológico con un Sistema de CiberDefensa o CiberSeguridad Comprensivo. De lo contrario, lamentablemente para muchos, será como no hacer nada. Basta con revisar nuevamente el caso de Ukrania como tantos otros casos similares. No se puede proteger a una casa solamente colocando protecciones en la puerta de servicio. También hay ventanas, puerta principal, cochera, entrada del perro y del gato, etc. La CiberSeguridad Industrial debe ser encarada de forma comprensiva y ejecutado de forma correcta.

De forma más amplia, la responsabilidad por la CiberSeguridad Industrial es, como mínimo, de todos aquellos que participan en la cadena de valor. La capacitación y certificación de profesionales dedicados a la CiberSeguridad Industrial es uno de los primeros pasos razonables por dar, al igual que acceder a un esquema de calificación y certificación de proveedores de sistemas de automatización y control industrial.

Usuarios Finales: deberán como primera medida definir políticas, procedimientos, especificaciones, etc. como parte de un buen programa de CiberSeguridad Industrial. Incluyendo:

1. Efectuar un relevamiento de todo lo que tienen instalado en sus procesos, clasificar a su infraestructura según su criticidad, efectuar análisis detallado de los riesgos, identificar las vulnerabilidades de los sistemas actuales en todos los Niveles 0, 1, 2, y 3; definir los niveles de aceptación de riesgos, construir e implementar medidas de protección adecuadas entre muchas otras actividades.
2. Será necesario generar nuevas especificaciones técnicas al momento de adquirir nuevos sistemas, además de realizar las pruebas adecuadas y controles adecuados antes de su instalación en la planta. Esto requiere un buen involucramiento del sector de Ingeniería para la adecuada especificación, compra y recepción de los nuevos sistemas industriales.
3. Evaluar y clasificar a los integradores, proveedores y fabricantes. Los usuarios finales exigirán que los integradores de sistemas demuestren buenas prácticas de ingeniería, además de los sistemas configurados y probados para la CiberSeguridad,
4. Al igual que el item anterior, que los Sistemas y Productos tengan certificaciones demostrables de CiberSeguridad.

Integradores de Sistemas: Es necesario que los integradores de sistemas puedan comprender las especificaciones y requerimientos de los proveedores relativos a la CiberSeguridad Industrial. Suministrar soluciones de Ingeniería, con su documentación, realizar pruebas con sus demostrativos, de la misma forma. Además de realizar los diseños y configuración de los Sistemas Industriales. Implementar las mejores prácticas y técnicas de diseño, configuración y desarrollo del sistema de acuerdo con los nuevos requerimientos. Los integradores, deberán conocer las cuestiones técnicas como las cuestiones metodológicas y las mejores prácticas de Ingeniería para los sistemas que ellos ensamblan y proveen.

Proveedores de Sistemas Industriales: Los proveedores de sistemas deberán suministrar y mantener sistemas libres de vulnerabilidades, que satisfagan las necesidades actuales de Seguridad. Durante muchos años los sistemas fueron desarrollados sin considerar los riesgos a la ciberseguridad Industrial. Los fabricantes, deberán además de asegurar que el Software de sus sistemas es segurizado. Arquitecturas recomendadas, software y hardware homologado, compatible con los sistemas tal que permita cumplir con los nuevos requerimientos de seguridad del mercado. La mayoría de las empresas proveedores de Sistemas de Control ya han tomado iniciativa en este tema, y la gran mayoría ya tienen soluciones y recomendaciones de Seguridad Agregada, a pesar de que aún muchos no tienen sus productos homologados ni certificados. Aquí es donde surge uno de los más importantes progresos en la CiberSeguridad de los Sistemas de Control, “La CiberSeguridad Embebida por diseño vs. La CiberSeguridad Agregada”.

Los Fabricantes de Productos Industriales: muchos fabricantes de productos que luego son utilizados como partes de los sistemas de control también deberán producir partes que sean lo suficientemente seguras y puedan soportar los más persistentes ataques a la seguridad digital.  Los fabricantes ya comenzaron a construir sistemas con CiberSeguridad embebida, en vez de la CiberSeguridad construida o desarrollada por fuera. Un claro ejemplo de esto es el caso del sistema de Bedrock Automation.

1. Programa de Capacitación y Certificación Profesional. LINK
2. Sistema Bedrock Automation Platforms. LINK
3. OPC Foundation. (opcfoundation.org)
4. ISA International Society of Automation. (isa.org)
5. ISA Secure (isasecure.org)
6. Caso de Estudio de Ataque al Sistema Interconectado Eléctrico de Ukrania. LINK

Sin lugar dudas este ha sido un Incidente que llamó mucho la atención en todo el mundo. Dentro de la comunidad de aquellos que nos dedicamos a la CiberSeguridad Industrial sabemos que en Ukrania dedican gran cantidad de recursos a la protección de la Infraestructura Crítica, y especialmente en el sector de Energía, quizas porque ya han sido noticia en otros episodios del pasado. Desde el mes de diciembre del año pasado, habrían sido sorprendidos en un gran incidente. Todos nos preguntamos ¿Qué paso? ¿Cómo pudo haber sucedido cosa semejante en un pais en el cual se dedica una gran cantidad de recursos a la protección de la infraestructura Crítica?

Las estadísticas de incidencias y ataques a los Sistemas de Control (IACS, Industrial Automation Control Systems) van aumentando año tras año, y en todas partes del mundo, como en América, Europa, Asia, etc. Tanto en su cantidad, como en la técnica de penetración y el daño que estos incidentes van ocasionando a sus víctimas. Esto solo será motivo de análisis en uno de nuestros próximos artículos.

En general los ataques a la Infraestructura Crítica generados en las Redes de IT o más bien redes TCP/IP, muy dificilmente ocasionen daños significativos o tengan consecuencias sobre el mundo físico y sobre la población. El pasado 23 de diciembre de 2015, en la Zona oeste de Ukrania incluyendo la ciudad capital de Ivano-Frankivsk, más de 700.00 residentes y 200.000 industrias, sufrieron un prologado corte de energía como consecuencia de un CiberAtaque.

El análisis de este caso es especialmente valioso, para comprender cuál fue el impacto de este incidente que involucró a los Sistemas de Control y a la CiberSeguridad Industrial en su conjunto. La zona Oeste de Ukrania es operada por varias empresas privadas de transporte y distribución de energía. En este territorio las fuentes de Energía provienen principalmente de Centrales de Generación Térmica. Ukrania también tiene Centrales Nucleares pero no en esta región del pais. Hasta quizás se podría pensar que el golpe vino por el lado menos esperado.

El sistema interconectado eléctrico de uno de los países, con supuestamente la infraestructura crítica bien protegida, fue seriamente afectado.

El pasado 23 de diciembre de 2015, un día normal de trabajo en el crudo invierno, a las 16:00 hs una gran cantidad de usuarios e industrias ya no contaban con el suministro de energía eléctrica. La situación se comenzó a recuperar desde las 19:00 hs. Sabemos que esto es mucho tiempo, especialmente para los habitantes e industriales. No solamente por la cantidad de horas pero también por la inmensa cantidad de usuarios y una amplia región afectada. Los daños económicos fueron enormes. Sin embargo desde el punto de vista del tiempo de respuesta, y debido a la magnitud del incidente, el equipo de respuesta respondió de forma rápida. La mayoría de las compañías de energía en todas partes del mundo no habrían estado en condiciones de responder de la misma forma en tan poco tiempo. Cuando la gran mayoría se habría quedado totalmente  desconcertada, el equipo de respuesta supo cómo manejar la situación con efectividad.

La noticia del incidente comenzó a propagarse en todos los medios del mundo. Antes de fin de año ya era el incidente de CiberSeguridad Industrial más resonante del año. Las agencias de investigación de CiberSeguridad Industrial se mostraron sorprendidas y al a vez interesadas en colaborar con la investigación. ¿Qué sucedió? y ¿Cómo sucedió? Mientras el análisis y las pericias continuan, aún al día de hoy, varias cuestiones ya están muy claras.

1. BlackEnergy malware infectó varias computadoras de la Red de IT.

BlackEnergy (también conocido como DarkEnergy) es un malware que existe desde el año 2008 y cada uno de sus módulos ha ido mutando con el tiempo. En este incidente, la tercera variante de BlackEnergy fue utilizada como vector de ataque y ha brindado a los atacantes acceso a las computadoras de las empresas de distribución de energía, y la habilidad para comunicarse de forma remota a ellas. No se ha detectado que este malware haya llegado a las estaciones de operación de los Sistemas de Control. Sin embargo si es seguro que los intrusos han conseguido obtener y robar información del Sistema Interconectado Eléctrico. Uno de los módulos de BlackEnergy, conocido como KillDisk, fue utilizado para denegar el acceso de las computadoras corporativas como una de varias medidas de distracción y demora el mismo día del incidente. Informes previos, revelaron, que en el mes de Marzo se habrían detectado intentos de ingresos a las compañías eléctricas con la segunda versión de BlackEnergy. En el mes de Julio habría sesado el alerta de estos ataques. El mismo debió haber sido tomado como una advertencia y no como una acción que ya estaba controlada.

2. Un ataque afectó al mismo tiempo al sistema de Telefonía de varias de las empresas.

Otro ataque en simultáneo afectó al sistema de comunicaciones y telefonía de varias empresas de energía, posiblemente una denegación de servicio (DoS), evitó que la mesa de ayuda de las empresas de transporte de energía pudieran recibir los reclamos de los usuarios afectados. Esta situación ya está dando una clara evidencia que el Incidente fue absolutamente planeado. Los cortes de energía comenzaron bastante tiempo antes de que las empresas tomaran conciencia de lo que estaba sucediendo realmente. Una de las prestadoras llegó a colocar mensajes en sus paginas Web informado a sus visitantes que la empresa estaba teniendo problemas con el suministro de energía en varias localidades, pero no podrían precisar una hora de restablecimiento. La situación era crítica y No sabían lo que estaba sucediendo. Los golpes venian por todos lados.

3. Varios de los Sistemas de Control de las Sub-estaciones fueron comprometidos.

Cuando los equipos de respuesta fueron a re-establecer los sistemas de control de cada una de las sub-estaciones de energía tomaron cuenta que los Sistemas de Control en campo, PLCs y RTUs, también habían sido comprometidos. Con posterioridad se encontró que el firmware de los dispositivos estaban corruptos o modificados, y sus configuraciones habían sido alteradas. Los sistemas de control de 16 sub-estaciones se encontraron en estas condiciones. Otra clara evidencia que el incidente ocurrido No fue ninguna casualidad. Las empresas de distribución de energía eléctrica del oeste de Ukrania habían sido víctimas de un ataque intencionado, con una alta motivación y conocimiento técnico avanzado de los Sistemas de Control.

4. Las Estaciones de Operación de algunos Sistemas SCADA fueron accedidas de forma remota.

Un operador, minutos antes de realizar su cambio de turno, relató como repentinamente una fantasma tomó control de sus estación de trabajo, y comenzó a actuar sobre las sub-estaciones. En apenas unos pocos segundos fue testigo cómo el supuesto fantasma acabada de dejar sin energía a una gran cantidad de usuarios e industrias. Este fantasma fue capaz de sortear procesos de verificación y confirmación de las acciones del operador. El Operador No tuvo tiempo ni posibilidad de hacer nada para evitarlo. No se trataba de un fatasma! Los accesos remotos a través de los enlaces VPN, habían sido vulnerados. Estaban operando el SCADA desde el exteriory los Hackers tenían el control del sistema. Los operados ya No podían ver lo que estaba sucediendo. Sus Claves de acceso No funcionaban. Las mismas medidas de seguridad del propio sistema habían bloqueado a los Operadores de poder acceder.

Un operador del Sistema de Control ubicado en Prykarpattyaoblenergo, mientras estaba realizando su papeleo para finalizar su turno de trabajo, observó repentinamente como el cursor de su Estación de Operación del sistema, se desplazo repentinamente hacia una esquina de la pantalla. Rápidamente el cursor comenzó a realizar una serie de acciones sobre la pantalla y maniobras en las sub-estaciones. El operador fatasma seleccionó una subestación, fue directamente a ella sin perder tiempo, sabiendo exactamente dónde debía picar, seleccionó la subestación, dio la orden de apagar. El Sistema SCADA tiene una secuencia de confirmación, como es típico para los sistemas SCADA del tipo Eléctricos (Select Before Operate, y otras), dio la orden de apagar, confirmó la secuencia, como todo un experto y asi sucesivamente con las 30 sub-estaciones de esa operadora. Los diagramas unifilares y diferentes pantallas No son fáciles de comprender, y se debe tener un conocimiento de las Redes Eléctricas. El operador intentó detener este proceso, pero nada pudo hacer. Lo peor ya había comenzado, inclusive antes de este incidente. Cantidades de usuarios estaban sufriendo las consecuencias de los cortes de energía aún antes del incidente del operador. Esto no fue todo. Al mismo tiempo incidentes similares estaban sucediendo en otros centros de control de otras empresas de energía. La cantidad de Sub-estaciones que estaban siendo puestas fuera de servicio se multiplicaban rápidamente.

A poco más de tres meses de ocurrido el incidente y luego de conocer solamente algunos de los resultados de las investigaciones que se fueron conociendo, a través de las diferentes agencias de investigación, no cabe ninguna duda que se trató de un CiberAtaque … planeado, elaborado y ejecutado con una gran efectividad. Quizás los responsables pensarían que el daño que ocasionarían seria mucho mayor. La eficiente respuesta en el Recupero del Incidente por parte del equipo de Respuesta hizo que las pérdidas No fueran aún muchísimo mayores. ¿Qué habría sucedido si el incidente continuaba durante toda la noche?

Los responsables no fueron oportunistas. Sabían perfectamente lo que estaban haciendo y lo tenían absolutamente premeditado. Fueron estratégicos, detallistas y lo estuvieron planeado durante meses. Múltiples ataques orquestrados con sincronismo como una auténtica coreografía. Cuando la mayoría de las personas responsabilizan al malware, está claro que detrás de este incidente existió una importante logística y motivación. Ante estos hechos el malware pudo haber sido una distracción para ocultar los vectores reales del ataque. De hecho no fue encontrado ningún malware en los sistemas de control ni en las Estaciones de Operación de SCADA. Las protecciones instaladas en los sistemas para evitar el ingreso desde la red corporativa han demostrado ser efectivos. No obstante el grupo activista ante esta situación No se rindió y buscaron otras formas de ingresar a los sistemas de control.

Las diferentes perspectivas de los ataques. Cuando algunos creen que todos estos daños fueron causado por un hacker o un grupo de hackers desde las Redes de IT, sabemos que llegar al nivel bajo del control, esto No es posible. Los cambios de firmware y en la configuración y programación de los Sistemas de Control no es posible de realizar simplemente accediendo a las Sala de operación del SCADA Room, como relató uno de los operadores, o a través del BlackEnergy Malware encontrado en las Redes de IT. Especialmente en un SCADA Eléctrico con redes de varios años, donde para acceder al firmware de los dispositivos de campo, realizar modificaciones sin que esto despierte sospechas sin generar eventos, No es posible. Es indudable que hubo una tarea de inteligencia, hubo una planificación, y más aún, hubo un conocimiento No solamente de la Red Eléctrica de la región sino también del SCADA, PLCs, RTUs, comunicaciones y de sus vulnerabilidades. Se sabe además que la pérdida del sistema SCADA, en un sistema bien concebido, no genera la caída del suministro de la energía. Para ello se debería llegar a los PLCs y RTUs.

Si bien es técnicamente factible en condiciones de laboratorio, es muy improbable por no decir imposible que los sistemas de control en las subestaciones hayan sido alterados por el uso del BlackEnergy Malware. Para realizar los cambios encontrados en los PLCs y RTUs de campo en las Sub-estaciones se requiere de acceso directo y en muchos casos de un conocimiento muy específico, y software específico. Más aún estos cambios No son posibles de realizar en pocos minutos, se requiere de muchas horas para conseguir alterar los Sistemas de Control de forma semejante y más aún pasar inadvertido. Cambios en el firmware y en la configuración no es igual a realizar cambios en el nivel de supervision y de operación del SCADA que en el nivel del Control.

Creemos que otros incidentes y eventos aún No revelados tuvieron lugar. Es razonable que se genere la confusión por falta de conocimiento de la comunidad global. De hecho en la mayoría de los incidentes que han causado daños reales a las infraestructura física se ha subestimado la capacidad de los atacantes, como fue el caso de la Siderurgia Alemana, suponiendo que el acceso se realizó desde la Red Corporativa o desde Internet, lo cual ha sido falso en el 90% de los incidentes, o simplemente desde un acceso VPN. La intervención en el Sistema de Telefonía tampoco fue la causante de los apagones masivos. Esto sirvió para demorar al equipo de respuesta en detectar y tomar conocimiento del problema. Esto fue también una distracción.

Un informe del Energy Industry Research Center, describe a los sistemas SCADA de Ukrania como desactualizados tecnológicamente y que estos deberían ser renovados. Por lo tanto que se consiga tener acceso remoto de los PLCs y RTUs lo hacen todavía más improbable, por no decir imposible. Más aún cuando No fueron encontradas evidencias de BlackEnergy 3 en los sistemas de Control. Si fue el caso de Shamoon y Dragonfly en otros incidentes que sucedieron en el pasado. Sin embargo en esta oportunidad estamos frente a un hecho único. Se ingresó a los PLCs y RTUs y se realizaron modificaciones en ellos. Hasta inclusive cambios de firmware.

¿Cómo es posible que una “potencia” en CiberSeguridad sea victima de semejante ataque? ¿Cómo es posible que haya sido tan vulnerable? ¿Qué han estado haciendo durante todo este tiempo para proteger sus sistemas de control? Desde Ukrania rápidamente señalaron a los Rusos como responsables por el ataque. Sin embargo por el tipo y nivel de sofisticación de los trabajos realizados, el incidente debió ser causado por varios actores y/o participantes. Inclusive pudieron haber conseguido la colaborzación de partes completamente desconectadas o desinteresadas que por unos dólares son capaces de hacer cualquier cosa, sin medir las consecuencias. Desde Estados Unidos de América se reconoce que los Sistemas de Control de Ukrania son más seguros que los propios. Sin embargo para los atacantes pareció un trabajo fácil. Fallas en las medidas de seguridad. El acceso remoto VPN de los Sistemas SCADA tenía una único factor de autenticación, cuando debería tener un mínimo de dos.

El apagón llevó un total de 6 horas. Sin embargo aún después de tres meses de lo sucedido los sistemas de control no están totalmente operativos. Varias de las sub-estaciones continúan siendo operadas manualmente. Restablecer los sistemas de control donde ya nada se puede subestimar no es sencillo. Es necesario recuperar, probar y verificar el sistema en un nivel de detalle lleva semanas. Ni siquiera pueden confiar en las copias de respaldo. Aún así No pueden volver a dejar a los sistemas tal y como estaban antes del incidente. Se quiere modificar todo!!! De lo contrario, lo mismo volverá a suceder.

Primera Fase: Durante los relevamientos no fueron encontradas evidencias de que el Malware BlackEnergy3 haya alcanzado los sistemas de control. Por el contrario todo parece indicar que las medidas de protección para evitar intrusiones desde el área corporativa hacia los sistemas de control fueron efectivos. Los ataques habrían comenzado varios meses antes en las Redes de IT. Los atacantes No se dieron por vencidos y buscaron otras vias de ingreso a los sistemas de control. Estos ataques en las áreas de IT fueron ejecutados a través del envío de correos electrónicos, con documentos de Word que pedían permiso para ejecutar macros. Estas macros tendrían el malware. Aún ganando acceso a las computadoras de los perfiles de administrador, no consiguieron llegar a los sistemas de control. Los diferentes cortafuegos y logs evidenciaron que todos los intentos de ingreso fueron bloqueados. Lo que si faltó fue un análisis adecuado a tiempo. Los atacantes tenían dos opciones. Buscar vulnerabilidades en los cortafuegos y barreras de ingreso a los sistemas de control desde la redes de IT, o buscar vias alternativas de ingreso. Los atacantes finalmente optaron por la segunda opción. Deberían conseguir uno o más accesos directos a los sistemas de control de las múltiples empresas de distribución de energía.

Segunda Fase: Los atacantes comenzaron a buscar formas de ingreso alternativas. Consiguieron ingresar al servidor de dominio y robaron las credenciales de ingreso a través de las VPN de varios SCADA. Una vez que consiguieron ingresar a la Red del Sistema SCADA comenzaron a tejer su estrategia. Reconfiguraron las UPS en dos de los Sistemas de Control. Además de dejar sin energía a los habitantes consiguieron dejar ciegos a los operadores, pero No consiguieron realizar esta movida en los demás sistemas. En algunos sistemas simplemente consiguieron freezar las pantallas de los operadores. Fue suficiente para que no pudieron ver lo que pasaba en campo. Las diferencias tecnológicas de los diferentes sistemas de control, fue brindando diferentes oportunidades de ingreso. Las compañías utilizaban diferentes DMS (Distribution Management Systems). Consiguieron modificar el firmware en diversos equipos y dispositivos de comunicaciones de red. Además llegaron a cambiar el firmware en varios Sistemas de Control, por lo menos en un mínimo de 16 sub-estaciones. Es la primera vez que se detecta un caso semejante, donde los actores consiguen realizar un cambio de firmware en los Sistemas de Control. Desde la perspectiva de un ataque fue toda una ingeniería. Una vez conseguidos todos estos cambios, ya estaban listos para ejecutar su ataque.

Tercera Fase: una vez desplegadas una suficiente cantidad de vectores de ataques, y caballos de troya, lo que debían de hacer para que el ataque sea efectivo y tuviera un gran impacto, fue actuar de forma coordinada. Y así lo hicieron.

El servicio de suministro de energía eléctrica fue restituido casi en su totalidad de forma manual. El equipo de respuesta observó que era la única forma que tenían para recuperar el servicio de energía. (No se sabía lo que estaba pasando hasta después de varias semanas y meses de analizar los sistemas.) Debían hacerlo de forma manual sin contar con la ayuda de los sistemas de control. En este caso fue posible, sin embargo, en las redes eléctricas más modernas esto no sería posible y para restablecer el servicio deberían recuperar a los sistemas de control primero.

Sabemos que en Ukrania invierten una gran cantidad de recursos para proteger su infraestructura Crítica. No obstante aún siendo un pais preparado en materia de CiberSeguridad han sido víctimas de uno de los ataques más temidos. Esto también pone en evidencia que la estrategia de defensa debe ser implementada en múltiples capas. No basta con proteger una sola entrada. Esto es como pretender proteger a nuestro hogar vigilando únicamente la puerta de servicio. Para que un sistema de CiberDefensa Industrial sea efectivo, se debe implementar tanto una Detección Comprensiva como una Protección Comprensiva. Se deben vigilar y proteger todas las puertas, todas las ventanas, hasta la entrada del perro o del gato, la chimenea y la cochera. No basta con proteger las Redes de Datos TCP/IP, como se está realizando en la mayoría de los casos. Se debe implementar un sistema de CiberDefensa que sea comprensivo. De lo contrario todo el esfuerzo puede ser en vano.

Estemos alertas en la medida que más informaciones va siendo revelada. Al igual que con el caso de Stuxnet llevó un bien tiempo conocer todo lo que sucedió realmente. Esta no sera una excepción.

Lección #1: Los atacantes precisaron de un mínmo de 6 meses de reconocimiento, investigación y orquestración para perpetrar su ataque. Con las herramientas adecuadas, y las hay de uso libre, las actividades de este grupo habrían sido detectadas.

Lección #2: Las conexiones remotas de los Sistemas SCADA y/o Sistemas de Control deben tener por lo menos dos factores de autenticación.

Lección #3: Las Fuentes de Alimentación y UPS de los Sistemas de Control son tan críticas como el propio Sistema de Control. Estas deben ser seguras y confiables.

Lección #4: Las Actualizaciones de firmware de los Sistemas de Control también son un vector de ataque válido y muy crítico, que la mayoría de los actores de la comunidad aún no lo tienen tran presente.

Lección #5: Se debe implementar un Sistema de Detección Comprensiva como así también de Protección Comprensiva. No basta con proteger solamente algunos de los puntos de ingreso.

Lección #6: Se debe conducir un estudio comprensivo de identificación de vulnerabilidades y evaluación de riesgos a la CiberSeguridad Industrial antes de implementar las medidas de protección. Al no hacerlo se corre un alto riesgo de subestimar a los atacantes. Ya sean intencionados o no intencionados.

Lección #7: Toda la información, documentación y detalles que describen el funcionamiento de la Red Eléctrica como de la arquitectura de los Sistemas de Control debe ser asegurada. Esta puede brindar a los interesados atacantes la información necesaria para identificar las vulnerabilidades en los Sistemas de Control.

¿Cuándo fue la última vez que Ud. efectuó en su compañía una revisión de su Plan de Respuesta a Incidentes en su planta o procesos? ¿Acaso tiene un plan de respuesta? ¿Está su gente mental y psicológica preparada para responder a este tipo de incidentes? ¿O le agarrarían totalmente por sorpresa con los pantalones bajos? ¿Podría su organización responder ante algo similar? ¿Tiene Ud. realizada una Evaluación de Riesgos a la CiberSeguridad Industrial? ¿Está al tanto de lo que puede llegar a pasar en sus procesos? ¿Cuál es el estado actual de sus CiberDefensas? ¿Está siguiendo alguna metodología? ¿Cuál? ¿Es la correcta?

En resumen, aún si Ud. no está en la industria eléctrica, este incidente es una muy buena oportunidad para observar, aprender y analizar cuál es su situación actual. Para todos aquellos proveedores de Sistemas y Servicios de procesos críticos, es vital aprender de estos casos.

¿Le gustaría dejar sus opiniones y comentarios acá abajo en este lugar? Escríbanos a support@wiseplant.com