Main differences between IT & OT Cybersecurity

In February, I had the opportunity to give a conference about the key differences between OT and IT Cybersecurity, at IndusSec 2018 Industrial Cybersecurity Congress. It is reasonable that IT security professionals want to introduce in OT cybersecurity, but in my opinion, there are a lot of differences between both. So, in this case, I will translate onto English the main ideas to reach English speakers.

The first one is related to the objectives and priorities. I am sure that when we do not know how to do something, we ask somebody who knows or can give us some valuable information. OT cybersecurity is newer in comparison with IT cybersecurity, so it is reasonable to focus on IT cybersecurity standards and best practices to secure industrial environments. However, it cannot be a right decision. I do not want to say that we cannot apply them. We can, but do not apply them in the same way. Why? Because the objectives and priorities are different. In IT environments, the objective is to protect the “Data” but in OT environment is the “Process”. In order to prioritize, in IT is the “confidentiality” instead of “availability” of an OT environment. So, if both have different objectives and priorities, we must use standards according to each one. IEC 624443 and NIST 800-82r2 instead of ISO 27000.

CIA vs IACSecondly, IT technologies use either Ethernet or TCP/IP to communicate to other systems. It is something that nobody discusses. Nevertheless, in OT environments the presence of protocols based on serial communications is very high, such as Profibus or Interbus. Beside this, migrate to Ethernet technology requires changing the cabling, something that cannot be done if the facilities work 24×7, new communication modules, industrial network design, and so on.

Other key factor, is the latency. In IT networks, we can assume up to 150ms for traffic in real time, but in Industrial Ethernet based networks it is not acceptable. For example, for Real Time (RT) Communications this value is under 10ms and for Isochronous Real Time (IRT) is 1ms. According to this, when we deploy firewalls to filter traffic we have to consider them because each one introduces latency more or less depending on the controls applied. This is, L4 filtering, antivirus, application control and IDS/IPS policies, operation mode (flow or proxy), CPU load, memory use, and so on. Consequently, in some environments, we cannot deploy firewalls as the standards recommend. We do not forget that there are protocols which are able to work in Layer 2, so they cannot be reachable from/to other subnets.

Thirdly, there are the patches. In OT, the equipment lifecycle is bigger in comparison to IT, so it is more likely that we will have either legacy or end of support systems without patches available. So, how can we patch these systems? But if we can get them from the vendor, we will have to decide when we will apply them. Not always can be possible because they can be linked to a reboot, stop or maintenance mode. And of course, affecting to the availability, something that we must ensure.

Patches and Updates

Fourthly, we want to talk about antivirus. In the same way of the previous paragraph we must keep in mind that one thing is the operating system and other is the software installed. If the operating system is too old, probably there will not be capable software for it, such as Microsoft Windows 2000 or XP. But in the best case, when we have compatibility and can use them on our HMI, maybe this solution cannot give us the protection that we are looking for. The antivirus are firm based tools, and if the malware is specific to ICS probably the signature cannot exist. This is, what happened with Irongate, malware discovered by FireEye security company. As they said, this malware was not identified by any of the Antivirus software available on Virustotal website. This invites to keep in mind that even though we have an antivirus on our industrial PC, probably, it cannot be as efficient as we need because they are not prepared for industrial threats.


Finally, I would like to mention a key aspect, and it is not related to technical features. I will refer to human factor. Until now, the auditors, consultants, networks and system administrators, integrators and other IT technicians talked the same language. If one of them talked about virtualization, databases, software and particular in security devices such as firewalls, intrusion detection/prevention systems, everybody understands each other. But since a few years ago this has been changing because there is other environment to protect, OT.

It has other kind of profiles such us maintenance technicians, process engineers and production managers. We should join them to our work groups, committees and meetings to share with us their knowledge, experience, priorities and needs and vice versa. Until now, IT teams did not know about PLCs, HMIs, RTUs, industrial communication latencies… and OT teams did not know about Endpoint software, next generation firewalls, deep packet inspection, communication ports… Everybody knows about what they have to manage or control. This is, IT teams know about, operating systems, software, routing, switching, and OT teams about, automation, pneumatic, hydraulic, sensors, actuators, etc.

So, if we want to ensure the availability on shop floors, plants, or critical infrastructures, we must know all related to facilities, ICS, systems. The industrial cybersecurity is not a task of either IT or OT people.  It is a shared responsibility, where it joins the best of two worlds, Information and Operation Technologies.

So we have to change from this point of view:

IT and OT Teams_01


IT and OT TEams_02

In my opinion, the obvious conclusion is that we cannot evaluate with same criteria both environments. As I said, if we have different priorities, different objectives, we must apply different approaches to reach our goals. This is, protect the industrial environments. In addition, even though we talk about the same technologies in both scenarios, the characteristics, features or deployment can be very different too. The latencies can be unacceptable, ineffective, require a change of point of view or the risk that we introduce is higher in comparison with that one we want to mitigate.

It will not be easy, because we will have some difficulties and barriers that have to overcome.

See you in the next post, thanks for your time.

Best regards.


Question last slide



Virtual Library, UPDATED!

Hello everyone!

This time I want to announce the update of the “Virtual Library”. As you know, this webpage is a collection of publications, articles and papers related to Industrial Cybersecurity; protection of Industrial and Automation Control Systems; Industry 4.0; and similar topics.

In this case, I have re ordered the webpage. Now, you can find two tabs named “Empresas” and “Organizaciones, Instituciones”. In the first case, “Empresas” you will find mainly publications and articles written by Cybersecurity Companies, Consultancy firms, and others. In the second tab “Organismos, Instituciones” you will find similar documents divulged by Gubernamental Institutions, non-profit organisations, National Agencies, and so on.

I hope you find them interesting and useful!

See you!


Publicaciones CERTSI e INCIBE sobre Ciberseguridad Industrial, actualizado 11/04/18.

Tanto INCIBE (Instituto Nacional de Ciberseguridad de España) como CERTSI (CERT de Seguridad e Industria) publican a menudo en sus respectivas Webs noticias, guías y artículos sobre distintas temáticas teniendo como telón de fondo la seguridad. Para esta ocasión he ordenado las referentes a Ciberseguriad Industrial, que recopilan un buen número de investigaciones, incidentes, análisis, e informes, sobre distintas temáticas.  Sin duda constituye un conjunto de referencias para el aprendizaje de todo profesional que esté o quiera desempeñarse en securización de estos entornos. Espero que os guste y sobre todo os resulte útil.

Un saludo!


  1. Despliegue de un IDS/IPS y gestión centralizada de alertas.
  2. Protocolos y Seguridad en SCI.
  3. Identificación y reporte de incidentes de seguridad para operadores estratégicos: Guía básica de protección de Infraestructuras Críticas.
  4. El Puesto del Operador: Guía básica de protección de Infraestructuras Críticas.
  5. Guía de Seguridad de Protocolos Industriales – Smart Grid


  1. Automatización de bajo conste.
  2. El valor de los indicadores de compromiso en la industria.
  3. Gestión de parches en Sistemas de Control.
  4. Introducción a los sistemas embebidos.
  5. Seguridad Industrial 2017 en cifras.
  6. Convergencia TI-TO.
  7. Retos y riesgos de ciberseguridad y privacidad en IoT.
  8. Iniciativas y y mejores prácticas de seguridad en IoT.
  9. 46 métricas para mejorar la ciberresiliencia en un servicio esencial.
  10. Diseño y configuración de IPS, IDS y SIEM en Sistemas de Control Industrial.
  11. Cómo evaluar mi nivel de capacidades en Ciberseguridad según C4V.
  12. Los conocimientos del personal de seguridad industrial.
  13. Ciberseguridad en las comunicaciones inalámbricas en Entornos Industriales
  14. SNMP, ¿es tan simple como el nombre indica?
  15. Cortafuegos transparentes, ladrillos de cristal.
  16. PRP y HSR: Protocolos redundantes.
  17. Robots y drones en la Industria 4.0.
  18. Hardware Hacking en Sistemas de Control Industrial.
  19. CrashOverride: El malware para SCI ataca de nuevo.
  20. Analizando la seguridad sin riesgos: laboratorios de pruebas.
  21. Asegurando la virtualización de tus sistema de control.
  22. Gestión de credenciales en sistemas de control.
  23. Prevención de intrusos y gestión de eventos para sistemas de control.
  24. Insider, las dos caras del empleado.
  25. Amenazas emergentes en entornos industriales.
  26. Honeypots Industriales.
  27. Gestionar el riesgo de los proveedores como propio.
  28. Seguridad en protocolos industriales – Smart Grid
  29. Criptografía para reforzar la ciberseguridad en entornos industriales.
  30. Características y seguridad en PROFINET.
  31. Analizadores de red en Sistemas de Control.
  32. Seguridad Industrial 2016 en cifras.
  33. ¿Nuevo ciberataque a la red eléctrica de Ucrania?
  34. Inventario de activos y gestión de la seguridad SCI.
  35. Líneas de actuación del Esquema Nacional de Seguridad Industrial.
  36. Protocolos Industriales: Herramientas de Seguridad.
  37. ¿Tu empresa es segura? Medir es el primer paso para conseguirlo.
  38. Atrapando sombras en la industria.
  39. Cyber Kill Chain en Sistemas de Control Industrial.
  40. DDOS de actualidad: IoT y los DNS de Dyn.
  41. Seguridad en BlueTooth: Fortalezas y debilidades.
  42. ZigBee en el laboratorio.
  43. Thinking in Big (Data) y la seguridad industrial.
  44. Seguridad desde abajo: dispositivos finales a escena.
  45. Familia de malware en la industria.
  46. Protegiéndose de BlackEnergy: Detectando anomalías.
  47. Seguridad en Comunicaciones ZigBee.
  48. BlackEnergy y los Sistemas Críticos.
  49. Desmontando Modbus.
  50. Safety y security: juntos pero no revueltos.
  51. BMS: Edificios inteligentes, ¿y seguros?
  52. Seguridad industrial 2015 en cifras.
  53. Un SCADA en la ciudad.
  54. Aplicando seguridad en WirelessHart.
  55. Sistemas de control de software libre.
  56. Arquitecturas de seguridad en la nube para la industria.
  57. Las aplicaciones de control se hacen mayores.
  58. Mi SCADA en las nubes.
  59. Evolucionando la comunicación en la industria.
  60. La Ciberseguridad en la Industria 4.0.
  61. Divide y vencerás: Segmentación al rescate.
  62. Monitorización de amenazas en SCADA.
  63. Evolucionando la infraestructura de red en SCI.
  64. Bug Bounties en SCI: Vulnerabilidades en busca y captura.
  65. El consumo eléctrico bajo control.
  66. Buenas prácticas de configuración en la red inteligente.
  67. Disciplina militar en Control Industrial: OPSEC.
  68. Auditorias en sistemas de control.
  69. Amenazas en los Sistemas de Control Industrial.
  70. Certificaciones de seguridad en sistemas de control.
  71. La evolución de los dispositivos en los sistemas de control industrial.
  72. Estándares de ciberseguridad en las redes inteligentes.
  73. BYOD en entornos industriales.
  74. IEC 62443: Evolución de la ISA 99.
  75. La seguridad de los coches inteligentes a examen.
  76. La ciberseguridad en las subestaciones y el estándar IEC 61850.
  77. Herramientas TI que evolucionan para TO.
  78. La evolución del software en los sistemas de control industrial.
  79. Diferencias entre TI y TO.
  80. Normativas de seguridad en sistemas de control.
  81. Identificación de sistemas de control industrial.
  82. Problemática de los antivirus en entornos industriales.
  83. Seguridad en Protocolos de Sistemas de Control Industrial.
  84. Del Air Gap a la Segmentación en ICS.
  85. Guía de seguridad de Sistemas de Control Industrial.
  86. La problemática de la ciberseguridad para los profesionales de los sistemas de control industrial.
  87. Protegiendo Infraestructuras Críticas: no es suficiente con medidas IT.
  88. Hacia una evaluación eficaz de la seguridad en ICS.

Otras Guías de interés:

  1. Guía de Pentest: Recolección de información (Information Gathering).
  2. Guía sobre análisis de tráfico con Wireshark.
  3. Guia de Seguridad en servicios DNS
  4. Ciber-Resiliencia: Aproximación a un marco de medición.
  5. Detección de APTs.


Seguridad en BACnet para control de edificios

El pasado día seis de enero publicaba un artículo en el que hablaba de la aplicación y fundamentos sobre BACnet para la gestión y control de edificios. Ahora bien,  hoy hablaremos de Seguridad en BACnet que, a diferencia de otros protocolos, sí dispone de medidas nativas aunque su implementación es opcional. Sí, opcional, con lo que todos sabemos lo que puede llegar a suceder… que no se aplica.

El propósito de la arquitectura es proporcionar autenticación entre dispositivos, origen de los datos y operador, además de confidencialidad e integridad de información.

La seguridad es añadida en forma de mensajes en la capa de red. Por definición, no hay una “capa de seguridad” como tal, pero se refieren a ella de una manera separada de tal manera que pueda ser entendida más fácilmente. Por ello, es que todos los menajes referidos a seguridad son tratados de forma separada, aunque en realidad forman parte de los mensajes a nivel de capa de red del propio protocolo.

BACnet delega en el uso de claves compartidas. Para la autenticación de dispositivos y usuarios, se utilizan tanto mensajes firmados como claves para firma; mientas que para la confidencialidad de datos, claves de cifrado y protección de payload. Se definen un total de 6 tipo de claves, como son:

  1. General-Network-Access, empleados para mensajes de broadcast, túneles de cifrado y  dispositivos con interfaces de usuario que no pueden autenticarlos.
  2. User-Authenticated, al contrario que el anterior, empleado por dispositivos cliente que sí pueden validar usuarios.
  3. Application-Specific, empleada para limitar a ciertos dispositivos intercambiar información de una aplicación concreta.
  4. Installation, usadas para dar acceso a dispotivos de la red BACnet de forma temporal para aquellos usuarios que así lo requieran.
  5. Distribution, para la distribución las claves como, General-Network-Acess, User-Authenticated, Application-Specific e Installation.
  6. Device-Master, Empleada únicamente para la distribución de la clave de Distribución. Es única para cada dispositivo.

El uso de claves para introducir distintos niveles de seguridad, lleva aparejado unas tareas de gestión, mantenimiento y recursos que pueden llegar a ser más o menos complejos dependiendo de cómo queramos proteger los dispositivos, la información y las instalaciones. Esto es, si el nivel de seguridad no es muy alto, o contamos con otros equipos que pueden introducirla de manera externa, la asignación de claves puede hacerse en el momento de la instalación de equipo y luego no cambiar. Pero si esto último es necesario, el protocolo dispone de mecanismos para cambiarlas con mayor o menor frecuencia.

Documento Seguridad en BACnet

En ese sentido, las claves pueden ser distribuidas a todos los dispositivos por un servidor de claves denominado “BACnet Key Server”. Las relativas a “General-Network-Access”, “User-Authenticated”, “Application-Specific” e “Installation” son reunidas y enviadas de forma conjunta a los distintos dispositivos junto con lo que se denomina “revisión number” por medio de la “Distribution-Key”. Cada dispositivo BACnet dispone de fábrica (o debería) de una clave maestra de dispositivo llamada “Device-Master” o contar con un proceso de asignación de una. Luego, el servidor de claves empleará ésta para crear la de distribución, “Distribution-Key”, y a partir de ahí hacer llegar el resto. El tratamiento de esta clave es distinto de las otras ya que se considera que cambia con menos frecuencia.

Cuando un dispositivo necesita mandar información de forma segura, se genera un nuevo tipo de mensaje en el que se introduce la información original dentro del payload “seguro”. El nivel más básico que se le da es la firma mediante HMAC (keyed-hash message authentication algorithm) mediante MD5 o SHA-256. Aparte, se indican tanto el origen y destino de las instancias de los dispositivos, identificador de mensaje y una marca horaria.

En otro orden, BACnet define dos tipos de redes red dependiendo de las medidas de seguridad aplicadas. Las define como “Trusted” donde se aplica seguridad física o mediante el uso de firmas o cifrado; o “Non-Trusted” en la que no se aplica ninguna de las anteriores.

Aquellos mensajes que no poseen ninguna medida de seguridad, se definen como “plain”, por tanto, podemos decir que pueden darse cuatro posibles tipos de estrategia o políticas de seguridad dentro de una red BACnet.

  1. Plain-trusted, seguridad física pero no se utiliza ningún protcolo.
  2. Signed-trusted, no se require seguridad física pero ésta se aplica mediante la firma de mensajes.
  3. Encrypted-trusted, no se requiere seguridad física, pero se consigue mediante el cifrado de mensajes.
  4. Plain-non-trusted, ninguna de las anteriores, ni física, ni firma ni cifrado de menajes.

Además de lo anterior, existe la posibilidad de determinar seguridad a nivel de dispositivo. Por ejemplo, aquellos equipos ubicados en redes “Plain-non-trusted” (no seguras). Al hablar de política a nivel de red, todos los dispositivos incluidos en ella deben ser configurados de la misma manera. Todos los dispositivos son configurados con una política de seguridad base que determina el nivel mínimo de seguridad para el envío y recibo de mensajes. Esta política podría ser mayor que la definida para la red BACNet, pero no menor.

También se permite establecer túneles cifrados entre dispotivos capaces de llevar a cabo esta tarea.

Con la integración de sistemas de Control y Automatización en redes tanto Ethernet como IP aparecen múltiples beneficios, pero también ciertas obligaciones. Los equipos comienzan a estar expuestos y por tanto, resulta necesario implementar ciertas medidas de seguridad. Cobra especial importancia cuando este protocolo es utilizado para los usos referidos al principio, esto es, sistemas de refrigeración, antincendios, elevadores, cámaras de circuito cerrado, entre otras. Algo que no es exclusivo de edificios de viviendas, también en fábricas o instalaciones industriales. No hablo sólo de las oficinas en ellas ubicadas sino en la propia planta. Por ejemplo, montacargas para trasladar maquinaria, piezas o cualquier otro elemento; sistemas de climatización para mantener temperaturas constantes; sistemas de ventilación para la extracción de gases; equipos contra incendios; etc.

BACnet aporta ciertas medidas para mitigar o reducir el riego de sufrir un incidente pero, aparte de ser configuradas, revisadas y actualizadas; deben ser implementadas. Pero aún y así pueden no ser efectivas contra ciertos ataques, ya que el tipo de instalaciones donde se emplea este protocolo, es necesario apoyarse en otras como pueden la seguridad física o el acceso remoto por medio de VPNs.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Un saludo, nos vemos en la próxima.

BACnet, fundamentos de un protocolo para la gestión de edificios

A menudo nos centramos en materia de Ciberseguridad haciendo referencia a aquellos equipos y sistemas que intervienen en los procesos productivos o entornos de control y automatización. Sin embargo, las fábricas no sólo son PLCs, HMIs, Workstations, sensores u actuadores. Dependiendo de la actividad y el tamaño, cuentan con otros elementos que también contribuyen a que se garantice la disponibilidad de la que tanto hemos hablado. Me refiero a sistemas de refrigeración, extinción de fuegos, climatización, montacargas, etc. los cuales pueden ser gestionados por medio del protocolo BACnet.

Habitualmente los vemos referenciados en los denominados “Edificios Inteligentes”, sin embargo, su uso ni es exclusivo de ellos ni es algo relativamente nuevo. La gestión de edificios viene dada por las siglas BMS, Building Management System debiéndose distinguir, entre edificios de viviendas o edificios industriales. En general, los sistemas BMS integran un conjunto de subsistemas encargados de los sistemas de control de iluminación, antincendios, alarmas, elevadores, ventilación, temperatura, etc. Si bien muchos de ellos son comunes a ambos entornos no podemos decir que son similares ya que las aplicaciones y alcance son distintos.

Ahora bien, al igual que PLCs, HMIs, y demás dispositivos, estos sistemas han de comunicarse entre sí para su propio funcionamiento y gestión. En este sentido, uno de los protocolos empleados es BACnet, Buiding Automation Control Network. Desarrollado en 1987, ha sido un ANSI e ISO estándar desde 1995 y 2003, respectivamente. Aunque su mantenimiento es continuo, el propósito de BACnet es proporcionar interoperabilidad entre sistemas y dispositivos en aplicaciones de control y automatización de edificios, mediante un protocolo de comunicaciones estándar.

Al igual que muchos otros, cada dispositivo BACNet es una combinación de hardware y software, encontrándolo como norma general en forma de controlador, pasarela o interfaz de usuario. Cada uno de ellos dispone de un identificador o número de instancia único que lo identifica y diferencia de los existentes en la red aparte de otros con información relativa a las entradas y salidas que  monitoriza y controla.

Dentro de BACnet podemos encontrar 3 conceptos claramente diferenciados, Objetos, Propiedades y Servicios.

Toda la información contenida dentro de un dispositivo BACnet es ordenada como objetos, el cual le convierte en un protocolo orientado justamente a esto mismo, a objetos. Cada Objeto” representa un componente del propio dispositivo o un conjunto de información que puede ser solicitada por otro a través de medios como Ethernet, IP, RS-485, etc.

El protocolo define un total de 54 tipos de objetos para los usos más comunes cubriendo así la mayoría de las necesidades. Sin embargo, da la posibilidad de crear otros nuevos para no interferir sobre aquellos usos más concretos o aplicaciones propietarias.

La imagen muestra la arquitectura e interoperabilidad entre los distintos elementos que definen el funcionamiento del protocolo para la gestión y automatización de edificios BACnet.

Arquitectura e inteoperabilidad en BACnet


Cada objeto tiene un identificador de 32 bits el cual contiene un código para el tipo de objeto y el número de instancia de dicho objeto.

Con independencia del propósito o función, cada “Objeto” posee un conjunto de “Propiedades”. Cada una de ellas contendrá dos partes, un identificador y un valor. El identificador son números que la definen de forma única en el ámbito del tipo de objeto; y el valor, la magnitud del mismo. Luego, dicha información podrá ser tanto de lectura como de y escritura.

Si unificamos ambos conceptos, podemos decir que cada “Objeto” incluyen “Propiedades” que determinan sus capacidades, operación e información asociada.

Como hemos dicho anteriormente los dispositivos interactúan entre sí para su operación. Cuando un equipo se comunica con otro para llevar a cabo una determinada acción, lo hace a través de los denominados “Servicios”. Los servicios son agrupados en 5 categorías según su funcionalidad:

  1. Object access (lectura, escritura, creación, borrado)
  2. Device management (descubrimiento, sincronización horaria, inicialización, copia de respaldo y restauración)
  3. Alarm and event (alarmas y cambios de estado)
  4. File transfer (Tendencia de datos y cambio de programa)
  5. Virtual terminal (interfaz hombre-máquina por medio de menús o similar)

Cada dispositivo envía las peticiones empleando mensajes convenientemente estructurados tanto en la pregunta como en la respuesta. Los mensajes son codificados en un stream numérico definiendo las funciones que deben llevarse a cabo.

Para que dichos mensajes puedan enviarse y recibirse, se establecen varios medios de transporte, los cuales se citan a continuación:

  1. BACnet/IP
  2. BACnet ISO 802-3 (Ethernet)
  3. BACnet MS/TP (Master-Slave/Token Passing)
  4. BACnet over ARCNET
  5. BACnet Point-to-Point (EIA-232 and Telephone)
  6. BACnet over LonTalk Foreign Frames
  7. BACnet over ZigBee

Cada uno de ellos son una combinación de capas Físicas y Enlace de Datos. Sin embargo, el mensaje BACnet es independiente del medio empleado pudiendo existir a su vez pasarelas referenciadas como “Routers” que puedan combinar cada uno de los medios. No obstante, serán los dos primeros los que reclaman más nuestra atención ya que proporcionan integración con redes tradicionales.

BACnet/IP proporciona conectividad a nivel de capa 3 pudiendo ser los equipos accesibles desde distintas redes IP. Cuando este medio es empleado con múltiples subredes, es necesario el uso de una funcionalidad especial denominada BBMD, Broadcast (Management Devices), equipo empleado para administrar los mensajes broadcast entre subredes. Éste recoge dichos mensajes y los redistribuye a otro BBMD ubicado en otra red mediante mensajes unicast.

Mientras que, BACnet ISO 802.3, similar al anterior, pero limitando las comunicaciones a nivel de capa 2.

Ahora bien, teniendo en cuenta los conceptos acerca de dispositivos, objetos propiedades, servicios y la forma en la que transmitir los mensajes, BACnet proporciona capacidades funcionales las cuales son denominadas como “Interoperability Areas”.  Existen un total de 5:

  1. Data Sharing, intercambio de información entre dispositivos. Lo mensajes pueden ser priorizados en función de su propiedad, además de ser de lectura o lectura/escritura.
  2. Trending, visualización de los valores recogidos y graficados para determinar tendencias.
  3. Scheduling, programación de tareas a ejecutar en momentos o intervalos concretos.
  4. Alarm & Event Management, intercambio de información relativo a alarmas o eventos.
  5. Device & Network Management, permite el descubrimiento de dispositivos, objetos dentro de ellos, establecimiento y reconexión en caso de caída de comunicación, sincronización horaria y reinicio.

Estas áreas están definidas dentro de BACnet como BIBB, “BACnet Interoperability Blocks”.

Puesto que BACnet es un estándar, los distintos fabricantes de equipos deben garantizar que sus productos soportan ciertos requisitos para poder operar unos con otros. Para ello, deben cumplir con lo definido en lo que se denomina “Protocol and Implementation and Conformance Statement”, PICS; una ficha técnica con distinta información y entre ella, los distintos BIBB soportados para que puedan ser comparados y garantizar su funcionamiento.

Es importarte resaltar que los mensajes pueden ser dotados de una “Prioridad” dependiendo el tipo de mensaje y la información que transporta. Se definen un total de 16, siendo las dos primeras relativas a cuestiones de “Safety”, “Manual Life-Safety” y “Automatic Life-Safety”.

Hasta aquí la presentación de los conceptos básicos de BACnet. Un protocolo con unas características específicas para entornos concretos. Como decía, es importante remarcar que su uso puede no estar necesariamente asociado a edificios de viviendas sino también a entornos industriales. Éstos también disponen de sistemas de refrigeración, sensores de humos, montacargas, etc. dependiendo, claro está, del tamaño y la actividad. Podrán almacenar productos químicos que deban ser almacenados bajo unas condiciones de temperatura determinada; entornos donde la calidad del aire deba ser única debiendo accionarse los sistemas de ventilación bajo unas circunstancias concretas; controlar la iluminación de un pabellón en distintas franjas horarias, entre otras muchas. ¿Alguien se imagina los efectos que pudiera tener si algo o alguien, pudiese alterar a las dos de la madrugada la iluminación de parte o toda una nave de producción y los operarios no pudiesen trabajar? Y peor aún, cómo o porqué se genera esa situación si no se puede acotar la causa que lo origina. No estamos hablando de un hecho con unas consecuencias graves, pero sí con impacto sobre la actividad de la propia empresa.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Triton/Trisis/Hatman; un malware para SIS.

Hace pocos días atrás saltaba la noticia acerca de la aparición de un nuevo malware para Sistemas de Control Industrial bajo el nombre TRITON, TRISIS o HATMAN. Un malware que a diferencia de otros como Stuxnet, Havex, Blackenergy2, CrashOverride tiene como objetivo sistemas SIS.

Los sistemas SIS (Safety Instrumented Systems) son los encargados de mantener bajo condiciones “seguras” instalaciones, procesos y equipos en caso de producirse alguna anomalía o mal funcionamiento. Así como en inglés podemos diferenciar entre “Security” y “Safety”, en español, empleamos únicamente la palabra “Seguridad” introduciendo cierta confusión. Es por ello es que muchas veces debamos especificar el ámbito al que hacemos referencia. Esto es, “Security”, seguridad de la información y “Safety”, seguridad de personas o instalaciones.

Estos sistemas operan al margen del propio proceso productivo, monitorizándolo y siendo independientes de los equipos que participan en él. No obstante, pueden estar integrados dentro de éstos. Aunque, en general, el equipamiento industrial es robusto y confiable, los SIS lo son aún más incorporando técnicas de corrección de errores, autodiagnóstico, componentes redundantes, aparte de una implementación específica acorde a la instalación o infraestructura de la que van a formar parte. Los requisitos están regulados según el estándar bajo el estándar IEC-61508, habiendo otros como el IEC-61511 que lo complementa en cuanto a uso de los mismos.

Cuando un sistema SIS detecta una condición que supera, o va en contra, de lo programado, actúa llevando el proceso a un estado seguro o deteniendo la actividad. Por ejemplo, son los encargados de parar el brazo de un robot en caso de que la puerta de la jaula donde se ubique, se abra evitando que éste pueda golpear a un técnico o dañar las instalaciones. O bien, parar una cadena de montaje si alguno de los sensores infrarrojos que delimitan su perímetro, detectan la presencia de una persona mientras está en movimiento evitando algún tipo de golpe, lesión o atrapamiento.

Como decía al principio, en esta ocasión, el malware detectado no afecta a sistemas de control tradicionales sino SIS, lo que supone un cambio a lo que podríamos estar acostumbrados y una evolución en los ataques a elementos OT.

TRITON/TRISIS/HATMAN, según sea la fuente en la que nos basemos, permite realizar cambios en los controladores SIS del fabricante Schneider Electric modelo Triconex. Entre sus características destacamos la capacidad para leer programas, lectura y escritura de funciones, consultas del estado del controlador y otras adicionales que pueden ser implementadas por medio de payloads específicos.

Durante el incidente que supuso la posterior investigación y detección de este malware, algunos controladores entraron en un estado de “seguridad” provocado por un supuesto fallo y que automáticamente pararon el proceso.

El malware se compone de dos piezas fundamentales. Por un lado, un componente que reside en un equipo tipo PC que posee el software legítimo para la comunicación de los controladores y por otro, dos binarios que se descargan en el propio controlador para actuar sobre él.

Todo comienza con el compromiso de la estación de trabajo encargada de la comunicación contra estos controladores SIS y que emplea sistema operativo Windows. El malware es nombrado como si fuera la aplicación Triconex Trilog, cuya función es el análisis de logs de las estaciones Triconex y que se encuentra dentro de la suite TriStation. El malware es distribuido dentro de un ejecutable denominado “trilog.exe”. Se trata de un script escrito en Python empleando el compilador “py2exe”, el cual es entregado junto con un fichero “”. Éste, contiene las librerías necesarias para poder operar así como dos binarios necesarios “inject.bin” (código de función maliciosa) e “imain.bin” (control lógico malicioso) que serán enviadas al controlador para la interacción con él. FireEye lo resume así en la siguiente imagen:

Triton Trisis Hatman

Una vez iniciado “trilog.exe” se crea una instancia que comprueba el estado del controlador mediante al protocolo TriStation empleado por el software legítimo TriStation TS1131 para la configuración de los mismo a través del puerto UDP 1502. Si éste se encuentra operativo, conecta con él y pasa los binarios “inject.bin” e “imain.bin” a las librerías de comunicación para enviarlas y almacenarlas en la memoria del controlador.

Una vez allí, el script realiza comprobaciones periódicas para conocer el estado del controlador. Si éste presenta algún error intenta resetearlo a un estado previo mediante el protocolo TriStation. Si esto fracasa, intenta escribir datos falsos en esa misma memoria para borrar cualquier rastro y obstaculizar cualquier tarea forense para determina la causa que ha provocado el fallo.

Dicho protocolo, que no implementa medidas de autenticación y cifrado aunque pueden configurarse ACLs en los equipos que lo dispongan, no está documentado públicamente,. Por tanto hace entender que el autor debió realizar labores de ingeniería inversa para poder llevar a su implementación. El descubrimiento de controladores SIS puede ser realizado mediante el envío de paquetes broadcast usando UDP 1502.

Es importante señalar que los controladores Triconex disponen de un “switch” físico que permite conmutar entre los distintos estados en los que puede operar el equipo. Las configuraciones y cambios deben realizarse en modo “Program”, posición bajo la que podría actuar TRISIS. Sin embargo, si lo está en modo “Run” o “Remote” las modificaciones no están permitidas, con lo que reduciríamos la probabilidad de que pueda ser comprometido.

Así pues, se presentan, a priori, distintos escenarios con las consecuencias que podrían tener sus efectos. Estos podrían ser:

  1. Parada del proceso. Se provocan distintos cambios no autorizados que hagan que los equipos detengan su funcionamiento en previsión de consecuencias mayores.
  2. Programación errónea de dispositivos SIS. Introducir variables o parámetros que permitiesen la operación de las instalaciones bajo condiciones que entrañen peligro para personas y elementos físicos.
  3. Parada o alteración de planta. Dependiendo del impacto afectar a la actividad de la compañía.
  4. Daños físicos. Sin la capacidad de regularizar o parar la actividad en caso necesario, la maquinaria o sistemas no interrumpirían su funcionamiento y por consiguiente el correspondiente daño.

Al parecer, se tiene constancia de que al menos existe una víctima localizada en la zona de Oriente Medio, no trascendiendo su identidad. Dada la naturaleza, propósito, grado de conocimiento tanto tecnológico como de proceso que se requiere, hace pensar que una nación pudiera estar detrás de la autoría. No se aprecian objetivos ni intereses económicos lo que se podría descartar delincuencia organizada.

Sin bien debemos ser conscientes de este nuevo y preocupante escenario, hemos de contextualizar y valorar todas las pruebas existentes, evitando sensacionalismos y alarmas innecesarias. La Ciberseguridad Industrial es un tema álgido dentro de los profesionales del sector, por lo que debemos analizar las circunstancias, condiciones, requerimientos y tecnologías para que estos ataques tengan efecto. Algunos de ellos podrían ser:

  1. Aplica a equipos concretos de un determinado fabricante, no a todos.
  2. Debe darse la condición de que un conmutador físico debe estar en cierta posición.
  3. Alto conocimiento de esta tecnología.
  4. Conocimiento del proceso que se gestiona para poder actuar de forma dirigida y provocar el mayor daño o impacto posible.
  5. No seguir las principales recomendaciones o estándares en materia de Ciberseguridad Industrial. Dependiendo del tipo de compañía, infraestructura o sector esto pudiera ser más o menos probable. No podemos considerar una empresa del sector petroquímico que una manufacturera del sector automoción.

Por último, mencionar algunas recomendaciones que pueden evitar tanto la infección, como la propagación y posterior ejecución.

  1. Establecer una red físicamente independiente para los sistemas SIS.
  2. Implementar NGFW que filtren el tráfico de gestión hacia ellos.
  3. Aplicar Control de Aplicación, Antivirus e IDS/IPS a nivel de red en NGFW.
  4. Sobre la Workstation para sistemas SIS aplicar soluciones de Control de acceso, usuarios con permisos específicos, integración a posible Directorio Activo; Whitelisting de Aplicación [1], [2]; Control de dispositivos USB [1]
  5. Aplicar controles de acceso físico a dichos sistemas; cabinas, armarios, etc.
  6. Registro de logs o envío de eventos cada vez que se lleve a cabo alguna intervención sobre SIS.
  7. Verificar la posición correcta de conmutadores físicos, en este caso, modo “Run” o “Remote”.

Así pues, por esta y otras, amenazas, vectores de ataque e intereses de distinto tipo, resulta necesario tomar medidas y controles sobre nuestros entornos OT. Obviamente, cada infraestructura, organización o compañía será objeto de unas u otras dependiendo de la importancia estratégica, criticidad o actividad, despertando los intereses de agencias, gobiernos, competencia o delincuencia. No podemos tratar a todos por igual. Hemos de contextualizar y analizar de la manera que merece, con la inteligencia que requiere.

Un saludo, nos vemos en la próxima.


Más información: