Seguridad en redes de abastecimiento de agua

publicado en: Seguridad | 0

Como parte del curso La seguridad en redes industriales e infraestructuras críticas, organizado por la UNED de Las Islas Baleares, realicé un análisis elemental de las redes de abastecimiento de agua. Comparto a continuación dicho examen.

Introducción

Las redes de distribución o abastecimiento de agua cumplen el cometido de transportar el agua potable a la población. Abarcan desde el punto en el que se produce (estaciones de tratamiento -ETAP-, desaladoras, o directamente pozos o manantiales en poblaciones pequeñas) hasta los edificios o lugares de consumo. Están formadas por estaciones relativamente deslocalizadas (bombeos, depósitos, derivaciones, reductoras de presión, etc.), razón por la cual un sistema de comunicaciones fiable es imprescindible para su funcionamiento correcto. Estas estaciones suelen poseer una terminal remota (RTU) o controlador (PLC) que recoge información y puede actuar sobre algunos equipos, como válvulas o dosificadoras. Dicha información debe compartirse entre las estaciones para un funcionamiento coordinado, y con un centro de control, donde un SCADA permite la visualización de la red y la adopción de acciones en función de demanda, previsión, estado de equipos, etc.
Obviamente, este tipo de instalación es una infraestructura crítica. Soporta un servicio esencial para la sociedad. Un mal funcionamiento afecta a un gran número de personas, además de conllevar un fuerte impacto económico y público. Las consecuencias de un ataque malintencionado pueden ser severas: pérdida del suministro, daño de las instalaciones, e incluso envenenamiento masivo por un exceso de cloración. Por tanto, de acuerdo a la Ley 8/2011 requieren una especial protección, de la que se debe encargar el Sistema de Protección de las Infraestructuras Críticas.

Riesgos

Aunque el curso se centra en las comunicaciones TCP/IP, por la rápida adopción que están teniendo debido a su potencial y las posibilidades de integración, el principal problema de las redes de abastecimiento de agua potable en España es que el grado de implantación de estos estándares no es suficientemente elevado. Abundan las comunicaciones por radio sin protocolos cifrados, como Modbus. Eso significa que son extremadamente vulnerables, puesto que la información se transmite de forma abierta. Cualquier persona, con herramientas tan accesibles como un portátil y un radiomodem, puede conocer las transmisiones, dificultarlas o impedirlas emitiendo en la misma frecuencia y, peor, introducir tramas (ataque de tipo man in the middle).
Estas redes, aunque con retraso, se están reemplazando por otras más de mayor ancho de banda, usualmente TCP/IP: WiMax, GSM, 3G, etc. Sobre esta capa se puede cifrar la comunicación, lo que resolvería el problema antedicho. No obstante, al abordar la sustitución del controlador, no se suele optar por otro con esta capacidad. Lo usual es reemplazarlo por un equipo del mismo fabricante, por ser económicamente más rentable la migración, y con mucha frecuencia no se dispone de equipos con capacidad de encriptación, o su coste es elevado. Por tanto, en el mejor de los casos, lo usual es que esta tarea se descargue sobre el router, que se conecta a un servidor VPN en el centro de control.
A esta configuración aplican los riesgos propios de cualquier red de este tipo. Brevemente, un atacante puede aprovechar vulnerabilidades para obtener información, producir denegaciones de servicio, inyectar paquetes, modificar consignas, programación, destruir equipos, etc. Entre estas vulnerabilidades se puede mencionar:

  • Agujeros de seguridad de los equipos. Puede ser el firmware del controlador o de los router, que no se suele actualizar con frecuencia, u obsolescencia del software de los ordenadores existentes en el centro de control: sistemas operativos, drivers, SCADA, otras aplicaciones o herramientas que se usen…
  • Mala elección de cifrado de la red privada virtual, o de las contraseñas, que pueden permitir al atacante introducirse en ellas.
  • Mal diseño de la infraestructura. Parte de la información recogida por el SCADA debe usarse con propósitos de gestión, y no siempre existe un firewall bien configurado entre ambas redes. Cuando las comunicaciones con las estaciones remotas se hace vía 3G o similar, el centro de control accede a ellas gracias Internet. Si no se aísla adecuadamente el equipo donde corre el SCADA, éste quedará a merced de cualquier ataque que proceda de esta vía.
  • Por lo que toca a las estaciones, es muy difícil protegerlas de sabotaje debido a su deslocalización. El coste de una plantilla continua de vigilancia no es asumible, y si un atacante logra acceso físico al interior de una estación, es posible que encuentre, como se ha comentado, comunicaciones Ethernet desprotegidas. No sólo se compromete dicha estación, sino toda la red, al disponer de fácil acceso a cualquier punto.
  • Muchos PLC o RTU no disponen de mecanismos de protección, o no se hace uso correcto de ellos. No sólo me refiero a no admitir comunicaciones cifradas, sino que cualquier persona, sin mediar contraseña, tenga acceso de lectura y escritura de todos sus datos y código.
  • A las vulnerabilidades puramente tecnológicas hay que sumarles las derivadas de una mala concienciación o desconocimiento del personal. Un atacante podría hacerse pasar por una empresa de servicios para acceder a las instalaciones, o utilizar ingeniería social para obtener claves, acceso a la red, etc. Hay precedentes muy conocidos de uso de memorias USB como vectores de transmisión de software malicioso. Tampoco se puede descartar un ataque desde dentro, por malestar del propio personal.

Por poner un ejemplo de ciberamenaza, Verizon describe en el Data Breach Digest de marzo el ataque a la red de distribución de la Kemuri Water Company (Australia). El atacante accedió al SCADA a través de la aplicación de pago online de la compañía, y alteró las configuraciones de la instalación. Por tanto, aprovechó vulnerabilidades del servidor web, de la arquitectura (ya que pudo alcanzar la aplicación de control) y por último de la mala protección de ésta.

Soluciones

Los riesgos descritos son comunes a muchas instalaciones existentes actualmente. Debido a su criticidad, es urgente acometer las reformas necesarias para corregir sus vulnerabilidades. Incluirían los siguientes pasos.

  • Renovación de las instalaciones obsoletas. Con carácter perentorio, acometer todas aquellas que utilizan comunicaciones por radio abiertas. Idealmente, se debería usar comunicaciones cifradas punto a punto. Ello implica que los controladores deben posibilitarlo. En su defecto, adoptar medidas para que el acceso no permitido a una estación no posibilite poner en compromiso la infraestructura completa; se puede por ejemplo utilizar cortafuegos de tercera generación, con filtrado a nivel de aplicación.
  • Protección adecuada de los equipos. Se debe asegurar configuraciones y contraseñas seguras en controladores, enrutadores, ordenadores, etc.
  • Actualización continua de software (incluido firmware) a últimas versiones libres de vulnerabilidades. Los ordenadores deben contar con antivirus actualizado.
  • Los equipos de control no deben poseer más aplicaciones que las imprescindibles, para minimizar los posibles riesgos.
  • Los usuarios deben estar correctamente definidos en cuanto a número y privilegios, y su acceso debe ser validado por contraseña o método similar. Debe hacerse registro de todas las acciones que se llevan a cabo.
  • Se deben bloquear los posibles focos de infección: puertos USB, medios con autoarranque, acceso a Internet o correo electrónico en el equipo de control, etc.
  • Si la red de control no está aislada de otras, deben limitarte adecuadamente mediante firewalls las comunicaciones que tengan lugar, no permitiendo intercambiar más información que la imprescindible y en la forma en que se haya definido.
  • Para prevenir ataques mediante ingeniería social, es necesaria formación y concienciación del personal en temas de seguridad. Esta formación debe renovarse contemplando la evolución de las tecnologías.
  • Todas estas medidas deben de estar enmarcadas en una política que vele por la seguridad de las infraestructuras. Se deben hacer auditorías periódicas, análisis de intentos de acceso no permitidos, revisión del estado de los equipos, etc.

Este tipo de medidas requieren la implicación de la Administración a todos los niveles (desde estatal a ayuntamientos, con un fuerte papel de consorcios locales o diputaciones), empresas de gestión de agua y otros agentes que contempla el Sistema de Protección de las Infraestructuras Críticas, que deberían actuar de forma coordinada para asegurar las instalaciones.

RISI

publicado en: Seguridad | 0

Hace unos años se creó el Repository of Industrial Security Incidents (RISI) con objeto de recoger los fallos de seguridad, muchas veces ataques, que se van detectando en en ámbito industrial o que afectan a infraestructuras críticas, tal y como la distribución de energía, agua, sistema financiero, etc. Se trata de una base de datos de acceso público cuya información se obtiene por diversas vías. La principal es de forma directa por parte de los agentes afectados. Entre ellos se encuentran profesionales de la automatización, ingenieros o vendedores que directamente reportan las incidencias de las que tienen constancia. Pero también bebe de otras fuentes, como bases de datos legales, grupos de noticias o intercambio de información con organizaciones similares.
La base del datos del RISI está lejos de ser completa, de hecho es bastante escasa, y se actualiza con lentitud. Las razones son varias. En primer lugar, este tipo de incidentes con mucha frecuencia no salen a la luz, por políticas de las empresas u organismos que los sufren. Esta ocultación no es beneficiosa para la adopción de respuestas comunes, y para minimizar este escollo RISI oculta información sobre las entidades afectadas a petición de éstas, centrando la descripción en los mecanismos del ataque y las vulnerabilidades que lo facilitaron. En segundo lugar, se investiga cada uno de los sucesos, y sólo se encuentran en primera página aquéllos que están confirmados. Por último, las indagaciones de este tipo de sucesos son a veces difíciles y, en contra de lo que sucede con los ataques, demasiado lentas.

RISI
RISI

Por irnos a un ejemplo, podemos buscar el clásico ataque de Stuxnet, que se produjo en 2010 contra los centros iranís de enriquecimiento de uranio. Como podemos leer, el incidente está confirmado, si bien todavía se encuentra bajo investigación. Se comenta brevemente la historia del caso: fue descubierto por una empresa de seguridad bielorrusa y detuvo instalaciones en Natanz durante una semana. El malware se propaga como gusano aprovechando una vulnerabilidad de Windows, busca en la máquina infectada una instalación de WinCC y usa la contraseña por defecto de Microsoft SQL, tras lo que accede al sistema de control. RISI no entra a debatir el que fuera un ataque dirigido, pero podemos encontrar un daño colateral que se produjo el mismo año en molinos de harina iranís.
Respecto a España, sólo se registra un caso confirmado. Insisto en que, aunque el número de incidentes es elevado, no es habitual que los afectados compartan esta información. Se refiere al accidente del vuelo 5022 de Spanair el 20 de agosto de 2008, en que murieron 154 personas en Barajas a consecuencia de la infección de un troyano, que impidió que el sistema de control alertase de las alarmas.

Proyecto UWS (7)

publicado en: Base de datos, Programación, SCADA | 0

Esta entrada es continuación de Proyecto UWS (6).

Entrada de datos
Entrada de datos

Mi proyecto personal de entorno de desarrollo SCADA ha tomado nuevos derroteros. Tenía pendientes bastantes temas (usuarios, otros drivers, más controles para la interfaz…) pero se ha apropiado de él una necesidad que ha orientado la nueva versión. Pongo en situación: quiero almacenar una serie de valores históricos que se van a recoger manualmente, para poder analizarlos con posterioridad: sacar tendencias, exportar tablas, hacer cálculos… Podría recurrir a una hoja de cálculo, pero no es lo ideal si la tienen que manejar varias manos y el volumen de información es grande. Lo adecuado es una base de datos, pero hay que proporcionar un método de entrada sencillo, como una página web. Y aquí es donde he pensado añadir un nuevo controlador a UWS. Puede parecer forzar algo el sentido original del SCADA, pero bien pensado, ¿qué diferencia hay entre intercambiar información con un servidor físico a hacerlo con una base de datos?
El nuevo módulo, DBPLCModule hace de driver para este tipo de comunicación. La clase derivada de PLC controla la conexión, y parece natural que una tabla se amolde a una clase Memory y cada variable Tag represente una columna. La reinterpretación de los métodos existentes es también directa. ¿Qué devuelve get()? El valor más reciente. Para eso, hay que poder ordenarlos temporalmente, y eso requiere una columna en cada tabla de tipo datetime. Es consistente con la necesidad de almacenar valores históricos. ¿Qué almacena set()? El valor actual. O uno antiguo, aprovechando el polimorfismo. ¿Qué hace el método connect() del PLC? Conectarse a la base de datos y actualizar en el motor el valor de las variables de acuerdo a su contenido. También se añade un escaneo periódico, porque otra aplicación podría estar actualizando por su cuenta la información. Aquí he añadido una funcionalidad interesante: cuando llamamos a este método, DBPLC tiene ya toda la información necesaria sobre la base de datos, tablas y columnas, así que, ¿por qué no crear la estructura si no existe previamente? Hecho, ni siquiera debemos molestarnos en levantar todo este andamiaje, basta con la clásica llamada a ensemble.deploy() para tenerlo todo funcionando.

Hasta aquí lo directo, pero sigue siendo insuficiente para responder a las necesidades iniciales. Para ello es necesario añadir algunas funciones extra:

  • Datapicker
    Datapicker

    Tenemos que insertar nuevos datos. Y no nos vale Tag.set(), porque debemos poder agregar un registro completo. Se resuelve con el método Memory.set_row(), al que se le pasa como argumento un diccionario con los valores de las columnas y, opcionalmente, la fecha y hora de registro. Esta función clama a gritos un nuevo control en la interfaz, que tiene que ser un formulario. He adoptado el mismo criterio de simplicidad que otras veces: el atributo data-table lo liga a nuestro control, y nos podemos olvidar de código extra.
    El código en j.js busca todas las variables (atributo data-dir) en su interior, actualiza los valores iniciales y añade los eventos necesarios. El campo con atributo data-datetime es opcional, y se convertirá en un calendario para seleccionar fecha y hora de inserción. Para quien se lo pregunte, no necesitamos hacer referencia a la tabla, ya que está implícita en la memoria a la que pertenecen las variables.

  • Es necesario también un método para reclamar los valores de una variable entre dos fechas. Éste es Tag.get_data(), al que se le pasan los instantes de inicio y el de fin, y devuelve un listado de pares [tiempo,valor]. Esto va a ser útil para, por ejemplo, trazar una tendencia. También va a ser sencillo para el desarrollador, basta incluir un div con las variables dentro del atributo data-trend, y UWS lo transformará en una gráfica.

    Tendencia
    Tendencia

    En este caso va a ser importante añadir un id, para en el futuro discriminar acciones sobre diferentes tendencias. Para este elemento he recurrido a la estupenda librería Flot. De momento, las tendencias de UWS están en una fase muy inicial, y necesitan controles extra para moverse, añadir y eliminar variables, ampliar y reducir, usar varias escalas, etc.

Faltan todavía más cosas. Es necesario poder exportar datos, consultar valores en una fecha determinada, quizás editar la información… Además de la gestión de usuarios. Será en próximas entregas.
Recursos asociados:
SCADA UWS (versión 1.4) y código de ejemplo.

Corrosión galvánica

publicado en: General | 0
Corrosión
Corrosión

En la fotografía de la izquierda se muestra un sensor de proximidad que no funcionaba adecuadamente. He partido la cubierta, sellada herméticamente, para poder mostrar los contactos. Como se observa, están atacados por la corrosión. También la tarjeta, aunque en su caso es fácil de entender, ya que no se encuentra tan bien protegida; pertenece a un equipo que ha sufrido durante años condiciones duras, a la intemperie y sometido a altas temperaturas. Pero volvamos al sensor de proximidad. ¿Cómo puede afectar la corrosión a un equipo perfectamente sellado? Una ayuda: las pistas de la tarjeta son de cobre, los cables del sensor, de aluminio, y el contacto, aunque no puede verse, posiblemente sea cobre recubierto de plata.
La corrosión es una reacción química redox, en la que un elemento (ánodo) cede electrones a otro (cátodo). El primero se oxida y el segundo se reduce. Por ejemplo, en el caso clásico del hierro, un átomo pierde dos electrones y se los aporta al oxígeno. Para ser precisos, esto es sólo una primera oxidación a Fe2+; para ser precisos, el oxígeno se une a dos protones (procedentes de ácido carbónico, por ejemplo) y produce agua. Pero no quiero desviarme con los detalles. Molecularmente se produce tanto esta reacción como su contraria, pero tiene más preferencia la que libera más energía, como en todo proceso termodinámico. Así que se puede determinar cómo y en qué grado va a tener lugar este proceso contabilizando energías absorbidas o liberadas por los iones. A estas energías se las llama potenciales de reducción. Volvamos al ejemplo del hierro: el potencial con que el átomo cede dos electrones es de 0’44V; el de reducir el oxígeno para llevarlo a agua, 1’23V; la suma (1’67V) es positiva y elevada, por lo que la oxidación se produce rápidamente. Obviamente, para que la corrosión tenga lugar, es necesario que el medio permita el movimiento de cargas. El agua de mar, por ejemplo, es un electrolito fenomenal, y por esta razón las instalaciones en ambientes costeros sufren un deterioro más rápido. Otros factores, como una temperatura alta o gran superficie de contacto, también aceleran la reacción.
Cuando se pone en contacto dos metales se puede sufrir un caso particular de corrosión, denominada galvánica. La causa es idéntica: el que tiene menor potencial de reducción cede electrones al otro, y se oxida. Para determinar cómo resultan afectados los metales en un electrolito se usan series galvánicas (tablas de potenciales) o el índice anódico (diferencia de potencial con el oro, que sirve de referencia). Los elementos mejor situados se dice que son más nobles. Significa que tienen tienen prevalencia para recibir electrones, luego actúan como cátodo (se reducen) frente a su pareja, que se oxida. Si se pone en contacto cinc con cobre, por ejemplo, el primero cede electrones al segundo mientras se oxida. Esta corriente eléctrica puede aprovecharse, como se hace en una pila o celda galvánica. Si los metales son plata y cobre, en este caso será el cobre, menos noble (con menor potencial) el que se oxide. Si los índices de los dos metales son muy similares, como sucede con el acero y el aluminio, la corrosión es tan lenta que prácticamente no tiene lugar.

Índice anódico
Índice anódico

Por tanto, cuando en una instalación se ponen en contacto dos metales diferentes hay que contar con que puede producirse corrosión galvánica. El más noble oxidará al que lo es menos. Más aún, si el primero está sometido a otro tipo de corrosión, atmosférica por ejemplo, su oxidación se traslada al otro metal, aunque no esté expuesto, debido a la libertad de desplazamiento de los electrones . Esto se puede aprovechar en nuestro beneficio: si se quiere proteger, por ejemplo, una tubería de cobre, se le puede conectar en un extremo una masa de cinc. Como se ha dicho, el cinc tiene menor potencial electroquímico, y va a aportar al cobre los electrones que perdería. Así, quien sufre la corrosión es el cinc, a pesar de no estar en contacto directo con el ambiente que lo está deteriorando.
El Reglamento de Baja Tensión establece como conductores permitidos en las instalaciones el cobre y el aluminio. Sin embargo, la combinación de ambos es mala en lo que toca a corrosión galvánica, debido a la gran diferencia de potencial. Por eso es importante evitar su unión o, si no es posible, limitar los efectos electroquímicos. El elemento perjudicado es el aluminio y, como se ha dicho, no basta proteger el punto donde se lleva a cabo la conexión, ya que la corrosión del cobre se desplaza hacia él. En la imagen que encabeza la entrada, la corrosión ya está afectando al cobre, como se aprecia por las manchas verdes de la tarjeta. Pero ya antes, el bimetal del contacto, a pesar de lo aislado que se encuentra, estaba deteriorado hasta el punto de no funcionar.

Novedades 20160118

Los fabricantes de controladores cada vez se toman más en serio la conectividad de sus equipos, y no me refiero a nivel de campo. Las instalaciones de control aisladas renuncian al enorme potencial de la integración con el resto de la organización. Si hace poco hablaba de la librería TCP File Server de Siemens, Omron ha dado un paso más allá. Los NJ501 y NJ101 comunican directamente con bases de datos, sin intermediarios. Ellos lo enfocan a control numérico, se puede pensar en el IoT… pero la clave está en la gestión unificada de la producción.
La Agencia Europea de Seguridad de las Redes y de la Información (ENISA) ha publicado un estudio sobre el grado de madurez de la seguridad en los sistemas SCADA e ICS, orientado a las actividades de los estados miembros, sus legislaciones y estrategias. España destaca en la formación, debido a los cursos del INCIBE y la Universidad de León. El estudio también propone una serie de recomendaciones: alinear esfuerzos, buenas prácticas, estandarización, alertas, sensibilización, formación e investigación.
Omron dispone de una plataforma de formación online gratuita en la que se pueden encontrar cursos de diversas materias: sistemas de automatización, control, motores, fuentes, relés, interruptores, componentes de seguridad, sensores, visión, ahorro energético… Los textos son muy claros, en español, y no requieren un nivel elevado, de modo que constituyen un material muy interesante para quien quiera iniciarse por su cuenta.
Keith Blodorn, de ProSoft Technology, ha descrito recientemente en un artículo las características fundamentales de la Industria 4.0. Se centra en remarcar la evolución frente a la integración de sistemas tradicional, que en realidad es bastante gradual: lo que supone en cuanto a supervisión remota, movilidad e interoperatividad. Y precisamente debido a que es una evolución, más que revolución, la adaptación es sencilla, teniendo presente aspectos como escalabilidad, migración de red y ciberseguridad.
Telefónica ha publicado su libro blanco sobre las smart cities, una buena visión del estado del arte. A mi modo de ver, lo más interesante está en la cuarta parte. Tras esbozar una hoja de ruta, se ahonda en las relaciones que se deben establecer entre actores (ciudadanos, universidad, empresas, administración), el marco legal, la financiación y los modelos. De manera demasiado breve también se presenta algún caso práctico, como el de Rivas Vaciamadrid. Por último, el libro propone un decálogo para las las futuras ciudades inteligentes.