Specialised products, FortiSwitch Rugged 112-D PoE

As I said several times, the industrial communications trend to Ethernet Technology for the advantages that it provides. However, this is not similar to affirm that everything will can communicate by frames or packets. There are many scenarios where serial protocols are being used because is not possible to update to Ethernet. For example, migrate to it requires to change cabling, reconfigure devices, deploy new networking equipment, programming changes, and many other measures. But if we can, we must deploy networking devices according to these harsh environments. Today, I will show one that can be used for its capabilities, Fortinet FortiSwitch Ruuged 112D-PoE.

It has 8 GE RJ-45 ports and 4 more GE SFP slots. It can be necessary for those situations when you need to connect devices by optical fiber. It is widespread used because permits more than 100 meters, or less, and does not affect electromagnetic interferences in comparison with unshielded twisted pair Ethernet cabling. It supports fiber single mode, multimode and long haul single mode with LC connector

FortiSwitch Rugged 112D-PoE

This switch can be used to connect PLCs, HMIs, or other device that communicates by industrial based Ethernet Protocols such as PROFINET, Ethernet/IP, Modbus/TCP, and so on. It has redundant power input terminals in the range from 44 to 57V DC to give service for PoE ports if needed.

FortiSwitch Rugged 112D-PoE

There are not any fans to cool itself to prevent damages. It is so important for those dusty places where can affect the operation stopping them if it is excessive. The switch can work in a temperature range from -40 to 75º C (-40 – 167º F) and can be mounted in DIN rail or wall depending your rack or facility. Related to the atmosphere, it tolerates up to 5-95% of non-condensing humidity.

FortiSwitch Rugged 112D-PoE

As you know, the lifecycle of industrial components and systems are higher in comparison with IT world. In this way, Fortinet affirm this switch has a mean time between failures (MTBF) more than 25 years. For this, it is capable to work in OT scenarios.

When you connect to its web interface you can see the dashboard where you can identify different information.

FortiSwitch Rugged 112D-PoE Menu

As you can see on the left, you will find a menu from where you can configure different features. For example, authenticate user to a LDAP server, port mirror ports, syslog server, and so on.

FortiSwitch Rugged 112D-PoE Authenticatio

FortiSwitch Rugged 112D-PoE Port Mirror

FortiSwitch Rugged 112D-PoE Logs

It operates at Layer 2 but you can get more Layer 3 capabilities if you connect it to a Fortinet Fortigate unit. Furthermore, you can manage your Fortiswitch from Fortigate console by FortiLink protocol. You will not find all the features, but you can configure VLAN interfaces, switch on and switch off ports, enable or disable PoE, and others.

FortiSwitch Rugged 112D-PoE and Fortigate Rugged 90D

Even though Ethernet technology give us a lot of improvements not always we will be able to implement them in own facilities in particular when they are working for 24 hours a day, 7 days a week, 365 days a year. It requires a very big effort in time, knowledge and obviously, budget .

Depending the activity, availability, probably, we will only get time on Christmas, Easter Week or summer Holidays, to do everything we need. In addition to that, be sure that you meet with others employees such as maintenance technicians that they have to do tasks relative to keep on good state of operation of our infrastructures. And as you know, they have more priority.

In spite of this, either it is possible to update or deploy a new facility we need to know which are the devices available that meet the requirements that we need. In the same way, industrial and automation control system vendors have been working to deploy new products for Cybersecurity purposes; the Cybersecurity product manufactures have developed industrial networking equipment. One of them, is Fortinet FortiSwitch Rugged 112D-PoE that I have shown. All features can be found by clicking here.

Other choice to find the best solution for our needs.

See you next time!



Device Whitelisting

Today I would like to start by apologizing because this is my first post in English. English is not my mother tongue so be sure that I can make some grammar, vocabulary or expression mistakes. Last year I finished with more than 52000 visitors and I decided for this 2018 try to write some articles in this language, in particular to come to English-speaking people. Having said this, let’s make a start!

A lot has been written about if USB ports have to be turned on in industrial environments and the threat that they might suppose for them. In particular, pen drives and other storage devices. Obviously, this is true and somebody may think “Ok, block them and the problem will disappear”. Yes, but depending on the scenarios it cannot be possible to do. The theory crashes with the reality, once again. Why? Few questions…

  1. How do you access to data stored in systems located on isolated facilities?
  2. What do you do if recover a system without network connection is needed?
  3. How do you install a new software version if the network is not routed and cannot access to other like DMZ?
  4. What happens if the software requires a license USB device?
  5. If you have a backup system, what do you do if you have to recover a system and the network connection is not available? And if this is possible, are you going to download several gigabytes from that server across the OT network?
  6. If you have a software distribution system, how do you deploy software that cannot be packetized?
  7. Are you going to trust totally on these backup systems and do not have an Emergency Plan to storage configurations, programs, software or firmware in an external USB Hard Disc Drive?

For these and further questions are that the USB devices have, can and must be used at industrial environments with multiple purposes. However, we must take measures to prevent any incorrect use and be the source of incidents by negligence, spread up malware, steal information, infect a system, and so on. In consequence, the USB port in the majority of cases have to be switched on.

Obviously, the first step should be raise awareness to all the personnel involved, or related, with OT tasks, but everybody knows that this is not enough. We need technical tools.

Consequently, as we must live with our “enemy” because we need him, we have to decide how to control him, and reduce the risk that somebody, or something, cause damages in our facilities.

One measure is to decide which USB device we will use for maintenance, operational, recovery or any other justified reason to be plugged on to own systems. For example, HMI, engineering workstations, programming laptops, etc. Others, or any similar as mobile phones, pen drives, are forbidden. Then, either via software or endpoint security solution, permit or deny mount them on these systems.

Today I will talk about how to do this using Symantec Embeeded Security : Critical System Solution” in 7.1 version. In other posts, I mentioned how USB Control and Application Whitelisting works.

On this occasion I have created the following scenario.

USB Whitelisting Scenario v1

As you can see, we have “Management Console” installed on a PC with Windows XP OS. From there, we connect to the SES:CSP Server to set up Application Whitelistng Policies. Finally, a Programming Laptop used to connect to PLCs and other devices located in OT environments.

We connect to the server from XP PC and open the selected policy named “AUTH_USB_win_whitelisting_sbp v7.1.0 r136 – Whitelisitng”


Open “Device Control Rules” we are able to block, or not.


If we check “Block USB devices” a new window is opened.


From there we can “whitelist” the devices. Clicking on “Add” we can choose between those we have connected or if we want to specify them manually.


In this case our device appears as follow:


Now we are ready to save changes and apply onto the programming station.


As you can see the device can be mounted and the files be accessed in function on the application policies.


But if other USB stored devices are plugged, they will not be mounted and visible on the explorer. A log will be created as follow.


The green “information” logs are related to the right device.

The use of USB devices as pen or hard disc drives sometimes are not only useful, are necessary. All depends on the activity, the context or the criticality of the systems. They give us the flexibility to transfer files, configurations or any information, especially in those moments when we cannot do it across the network. For example, have a second repository to storage a copy of everything we need to recover an equipment, something important in the context of Emergency or Disaster Recovery Plans. Furthermore, the data transfer using USB can be higher than network interface cards, probably 10/100 Mbps, so we can do our tasks faster than if we wait to download everything from a server.

In any case, we must control the USB ports because they can be our allied or our enemy. We must do not forget that in case of unauthorized USB is plugged, the execution, read or write can be submitted to application whitelist policies.

That´s all, Thanks a lot, see you again!


CCI presente en la Ciberseguridad Industrial Vasca

Una de las cosas que puede apreciarse, sin duda alguna, dentro del amplio tejido empresarial de la Comunidad Autónoma Vasca es la fuerte presencia industrial que existe en cualquiera de los tres territorios históricos. Automoción, máquina herramienta, metalurgia, centros de investigación, aeronáutica, fabricantes de componentes para el tratamiento de fluidos, metal, y parques tecnológicos, están presentes, entre muchos otros sectores y actividades, a lo largo y ancho de esta geografía. Coincide además, las distintas iniciativas por parte de Gobierno Vasco y Diputación Foral de Guipúzkoa no sólo en materia de Industria 4.0 sino en Ciberseguridad, siendo reflejo de ello la puesta en marcha del Centro Vasco de Ciberseguridad y el Centro Avanzado de Ciberseguridad Industrial.

El Centro de Ciberseguridad Industrial , primero de estas características nacido en marzo de 2013, sin subvenciones, independiente,  sin ánimo de lucro, y cuya misión es impulsar y contribuir a la mejora de la Ciberseguridad Industrial, ha querido comenzar este 2018 llevando a cabo sus actividades en Euskadi no sólo por aquellas propias sino además como invitado en alguna otra.

Por orden cronológico, el día seis de marzo, estaré presente como Coordinador del País Vasco en el congreso “IndusSec: Ciberseguridad para la Industria”  dando una ponencia titulada “Aspectos diferenciales de la seguridad OT  respecto a la seguridad IT”. En ella abordaré las divergencias existentes entre las distintas aproximaciones y porqué han de ser abordadas bajo estrategias propias. El registro es gratuito y aforo limitado. Un auténtico placer ya que el año pasado acudimos como espectadores y en esta edición estaremos compartiendo las experiencias profesionales adquiridas a lo largo de estos años.


Ya dentro del programa de actividades propias para este 2018, el día 21 de marzo en horario de 08:00 a 14:00, se celebrará en Bilbao el encuentro “La Voz de la Industria Vasca” donde se presentarán los resultados preliminares del estudio sobre la ciberseguridad en la industria vasca, contando con la presencia del Director del Basque Cybersecurity Centre, Javier Diéguez. Luego empresas y colaboradores darán ponencias sobre temáticas diversas a todo los presentes. Más información aquí.

Coincidiendo con el evento anterior, además, se llevará a cabo un curso práctico dirigido a “Responsables de Ciberseguridad en Infraestructuras Críticas Industriales”. El mismo se celebrará el mismo día 21 en horario de 16:00 a 18:30 y el 22 de 08:30 a 17:40. Dentro del temario a impartir se abordarán temas como consecuencias de los riesgos tecnológicos, ciberseguridad industrial y protección de infraestructuras críticas, definiciones de estrategia, protección, entre otros. En esta ocasión será nuestro Director, José Valiente y Responsable de Gobierno Corporativo y Estrategia, Miguel García-Menéndez los encargados de impartir cada uno de los módulos.

Pero además de lo anterior no podía dejar pasar de citar la creación de la primera “Escuela Profesional de Ciberseguridad Industrial”, la cual nace con el doble objetivo de proporcionar una formación profesional de calidad con un enfoque práctico y la flexibilidad que necesitan los profesionales y sus organizaciones. Para mí es un orgullo, igualmente, formar parte del equipo de profesorado y sumarme a este excelente proyecto junto compañeros de profesión y amigos. Podéis encontrar toda la información aquí.

Escuela CCI+

Así pues, tanto si residís en esta estupenda tierra como es Euskadi como si decidís venir a descubrirla, no os podéis perder alguno de los eventos en el mes de marzo se llevarán a cabo en materia de Ciberseguridad. ¡Os esperamos!

¡Un saludo!

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 .

Terminamos 2017, empezamos 2018

Por estas fechas, hace un año, veía cómo las expectativas acerca del número a visitas para 2016 se había superado con creces. Había alcanzado las 32.379. Como era lógico para este 2017 el planteamiento era aumentar esa cifra lo que supondría haber llegado a una mayor cantidad de público. Decidí invertir algo de dinero en mejorar el plan de hosting e incluir mejoras que repercutieran en el posicionamiento, plantillas editables para un aspecto más atractivo, nuevos apartados, entre otros. Aparte claro está, la publicación de nuevo contenido.

El 2017 ha llegado a su fin y toca mirar los números finales para ver cuáles han sido los resultados. Si bien, ya veía que iban a ser buenos por el seguimiento semanal, no han podido ser mejores. Cuesta creerlo, la verdad, pero hemos alcanzado….

 ¡¡¡ 52.169 !!!

Cuando empecé 5 años atrás no pensé que esto pudiera suceder. Pero sí, ha sucedido. El sitio parece que tiene el suficiente interés tanto para ser visitado como referenciado Y claro, como no podía ser de otra manera, me llena de orgullo. Sólo hay que ver la tendencia anual.

Captura de pantalla 2018-01-01 a las 11.51.59

En este camino quisiera agradecer a todos los que han accedido, encontrado o leído algunos de los artículos y dedicarle parte de su tiempo. Sin ellos, estas cifras no serían posibles. También, dar las gracias a las personas y empresas que han colaborado y ayudado de una forma u otra.

Por un lado, a Fortinet España por tener acceso a sus productos y descubrir las funcionalidades que ofrecen para OT,  pudiéndose hacer frente desde un solo fabricante las muchas de las necesidades que tanto entornos industriales como infraestructuras críticas requieren sea el que sea su sector. Sin olvidarnos, además, de su integración con otros distintos de terceros para aportar unos mejores niveles de seguridad sobre distintos escenarios. A Jose Luis Laguna y Antonio Navarrete, muchas gracias.


Al Centro de Ciberseguridad Industrial, por no sólo darme la oportunidad y confianza de ser su Coordinador del País Vasco, sino de incluirme en muchos de sus boletines semanales haciendo referencia a los artículos publicados. A José Valiente, Miguel García-Menéndez y Susana Asensio, muchas gracias.


XI Jornadas CCN-CERT, de derecha a izquierda, Oscar Bou (Coordinador Valencia), J. Valiente (Director CCI); M. Pulpillo (Coordinador Andalucía); J. Figueras (Coordinador Cataluña) y yo, Edorta Echave (Coordinador País Vasco)

A mis compañeros de profesión, de trabajo, y amigos por darme su opinión sincera sobre su visión tanto del blog, del contenido, ideas o recomendaciones en redes sociales. Saber de sus comentarios, ayuda a mejorar, seguir en la misma línea o corregir errores. A Jon Bueno, Unai Gomez, Borja Lanseros, Jose Luis Flores, Aaron Flecha, Jose Luis Jimenez, Ana González, Joan Figueras, Guido Nahuel Ygounet, Belén Pérez Rodriguez, David Marco Freire, Enrique Dominguez, Jose Manuel Sacristán, Edgard Capdevielle, Luis Ochoa, Carlos Navares, Walter Heffel, Elyoenai Egozcue, David Imizcoz, Mikel Diaz de Arcaya, Diego Gil, Alvaro Rivas ZuazoAdriel Regueira, entre muchos otros más. Disculparme si alguno no está en la lista.

Con todo ello, ponemos rumbo a 2018. Con nuevas ideas, con nuevos propósitos. Lo malo va a ser que el día sólo seguirá teniendo 24 horas… pero creo que esto es algo que los que estamos metidos en muchos “fregaos”, “historias”, “compromisos” y otras tantas responsabilidades. Y es que ¡hay que ver lo fácil que nos liamos… 😉

Espero pues en los próximos 365 días que se nos presentan pueda seguir manteniendo este blog los suficientemente interesante como para que dentro de unos meses pueda deciros de nuevo que hemos superado los objetivos.

Un abrazo!

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 “library.zip”. É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: