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”

USB_POLICY_01

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

USB_POLICY_02

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

USB_POLICY_03

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.

USB_POLICY_04

In this case our device appears as follow:

USB_POLICY_05

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

USB_POLICY_06

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

USB_POLICY_07

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.

USB_POLICY_08

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!

Edorta

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.

BCSC

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.

Fortinet-01

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.

Coordinadores

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.

Referencias:

Firewalls Virtuales, por qué no en redes industriales?

Como hemos hablado en otras ocasiones la primera medida técnica para securizar las redes industriales es separar nuestros entornos de Oficinas y de Control mediante un NGFW. Con ello, conseguimos independizarlos y ceñir a cada uno de ellos el tráfico necesario. Luego, ya dentro del segundo es necesario segmentarlo en áreas funcionales más pequeñas de tal modo que si se produjese algún incidente, intencionado o no, no se propague al resto evitando así un daño mayor. Todo esto y más lo comentaba en un artículo de abril de 2016. Os dejo el enlace, pinchar aquí.

En él citaba que las mismas podrían ser física o lógica, utilizándose enlaces dedicados o configuraciones en la electrónica de red como pueden ser las tan conocidas VLAN. Sin embargo, el uso de tecnología “virtual” no es exclusivo de los switches o servidores. También la podemos emplear en Firewalls. Sí, los mismos que nos separan y segmentan dichos entornos.

En mi caso voy a tomar como ejemplo el uso que hace de esta tecnología el fabricante Fortinet.

Fortinet lo denomina como “VDOMs”, Virtual Domains. Con ella podremos crear dos o más Firewalls “lógicos” dentro de uno físico siendo cada uno de ellos totalmente independiente uno del otro. Tendrán sus propias reglas de filtrado, sus propios perfiles de seguridad, sus propios administradores, etc.

Tal es así que, aparte de los que se configuren, se creará otro de forma automática denominado “root”. Cuando todos los VDOMs son deshabilitados en cualquier unidad FortiGate, hay un VDOM que sigue activo, el “root”. Esto es así ya que debe existir un VDOM de administración entre otros aspectos, para la gestión de tráfico. Por ejemplo, cuando habilitamos la funcionalidad de VDOM toda la configuración se conserva en el VDOM “root”. A partir de ahí iremos creando otros en consecuencia. Todas las configuraciones que sean necesarias fuera de los VDOM, se realizan desde el apartado “Global”. Hablamos de las que afectan a la unidad Fortigate como dispositivo físico, esto es, la asignación de interfaces, Alta Disponibilidad, mantenimiento, etc.

Aquí os dejo un video donde se muestra tanto el concepto como una configuración básica:

Como es evidente, cada unidad FortiGate tiene recursos hardware limitados como CPU, memoria y almacenamiento. Cuando no empleamos VDOMs, este límite no supone un problema ya que todas las sesiones, usuarios y otros procesos comparten todos los recursos de forma equitativa. Sin embargo, cuando hacemos uso de ellos, podremos asignar a cada VDOM distinta cantidad, mínima y máxima, según sea necesario. Por defecto, cada VDOM no tendrá límites, con lo que un solo VDOM podría en un momento dado emplear todos los recursos en detrimento de otros VDOM.

Por ello es conveniente definir límites a este respecto. Veamos porqué.

Si bien la electrónica ha mejorado, cada vez que instalamos un equipo de seguridad perimetral introducimos una latencia, que puede aumentar tanto en cuanto se habilitan más características con el fin de mejorar la seguridad en las comunicaciones. Me refiero a servicios antivirus, IDS/IPS, Control de Aplicación, VPNs, etc. Las comunicaciones industriales no requieren unos anchos de banda como las que puede haber en entornos IT, sin embargo, las latencias experimentadas pueden ser inasumibles. Cuando hablamos en comunicaciones en tiempo real como voz o video sobre IP, podemos aceptar tiempos de hasta 150 ms. Sin embargo, en comunicaciones industriales tipo RT (Real Time) podemos hablar de hasta 10 ms o incluso en IRT (Isochronous Real Time) entre 0.25 y 1 ms. A la hora de instalar dispositivos de seguridad perimetral físicos como virtualizados, debemos tener esto presente. Más aún, en el caso de estos últimos donde compartimos recursos hardware. Si no realizamos un correcto dimensionamiento o asignación, podríamos enfrentarnos a que un Firewall virtual del entorno IT donde los anchos de banda sean mayores y exista una mayor cantidad de tráfico, requiera  recursos hardware y penalice al virtualizado en el entorno OT, donde si bien la cantidad de tráfico es menor, las latencias asumibles son mucho menores o críticas.

Como decía dentro de la Ciberseguridad Industrial, nuestro primer paso será la separación de entornos y la segmentación del de Control. Esta tecnología puede sernos de gran utilidad ya  que además de lo anterior es compatible con entornos de Alta Disponibilidad. Dos nodos físicos pueden albergar VDOMs, de tal manera que, si un Firewall cae, el otro podrá dar servicio en los VDOMs alojados en el contrario.

En la imagen que se muestra a continuación se puede ver cómo a partir de un equipo físico se han definido 3 VDOMs. Uno denominado “VDOM IT” donde tendremos nuestro Firewall Virtual encargado del filtrado de las comunicaciones entre todos los segmentos del entorno de “Oficinas”. El puerto “WAN 1”, red de servidores y del 1 al 3, subredes de clientes. Luego, el “VDOM OT”, y de forma homónima, “WAN 2”, servidores SCADA, Historians, etc. y del 4 al 6 los equipos finales como PLCs, Robots, SIS, etc. Finalmente, el “VDOM Root” el que emplearemos para la administración del equipo.

Al igual que ocurre con los Firewalls físicos podremos necesitar permitir cierto tráfico de un entorno a otro. Puesto que los Firewalls virtuales son independientes, es necesario establecer los denominados “VDOM Links”, que no son otra cosa que interfaces virtuales que comunican VDOMs. Cada “VDOM Link” posee su propio direccionamiento punto a punto, debiendo cada extremo ser asociado a uno de los VDOMs. Estas interfaces virtuales son más rápidas que las físicas, aunque dependerá tanto de la CPU como de la carga que ésta tenga fruto de las funcionalidades, perfiles, sesiones, funciones criptográficas, análisis de tráfico, etc.

En la siguiente guía podréis encontrar más información al respecto.

La idea mostrada aquí es que, si necesitamos aislar y segmentar ambos entornos, no tenemos por qué hacerlo necesariamente con equipos físicos como muestran muchos modelos y recomendaciones. No tiene por qué ser así. De igual manera que lo hacemos de forma lógica en switches con la definición de VLANs, lo podemos hacer con los Firewall, si éstos lo soportan; obviamente. Haciendo uso de esta capacidad podremos no sólo cumplir con nuestras necesidades y estrategias sino también, optimizar recursos hardware, reducir el número de equipos físicos, minimizar el espacio en nuestras instalaciones, escalabilidad, etc. Tal vez requiera de una planificación mayor, no sólo en cuanto a configuración en sí sino la administración futura.

Nuevamente las tecnologías nos ofrecen alternativas y soluciones más apropiadas, sólo tenemos que ver cuál se ajusta mejor a las necesidades de nuestros clientes para reducir los riesgos y garantizar la disponibilidad de las instalaciones. Eso si, previo estudio y planificación.

Un saludo, nos vemos en la próxima.

Edorta