Es un hecho que la ciberseguridad de los sistemas de control industrial constituye una de los grandes asuntos del momento. Desde hace algunos años existe una preocupación generalizada acerca de las amenazas que se ciernen sobre estos elementos críticos para el funcionamiento de las sociedades modernas y su capacidad para enfrentarse a ellas. Sin embargo, el progreso es exasperadamente lento y, en términos prácticos, poco parece haberse avanzado. ¿Por qué? ¿Acaso la magnitud del riesgo no justificaría que se adoptasen medidas con la máxima urgencia?

Para descubrir la causa de esta aparente contradicción hay que comenzar por cuestionarse incluso lo que parece evidente. Y para empezar, nada mejor que repasar la primera afirmación de este texto:

¿Es un hecho que la ciberseguridad de los sistemas de control industrial constituye uno de los grandes asuntos del momento? ¿Constituye este asunto una preocupación generalizada?

[Read more…]

Recientemente leí un artículo publicado por Joseph M. Weiss en su blog Unfettered blog. El título reza “The system is still broken. The failure of a cyber-sensitive substation device affecting a nuclear plant” y puede consultarse aquí. El título es bastante elocuente y capta inmediatamente la atención del lector. Y ello, en mi opinión, ocurre por la combinación de tres palabras: failure + cyber + nuclear. Toda época tiene sus miedos y la nuestra, como recuerdo de la guerra fría y la posibilidad cierta de una catástrofe atómica, lo tiene al holocausto nuclear. Este terror es reforzado de tanto en tanto, de forma que nunca deja de estar presente. Tras el fin de la guerra fría vino Chernóbil, y ahora tenemos Fukushima. La bestia atómica ha actuado contra su creador en tres ocasiones: a causa de un acto de guerra en Hiroshima y Nagasaki, a causa de la incompetencia y el mal diseño en Chernóbil y, finalmente, a causa de la Tectónica de placas en Fukushima. ¿Qué será la próxima vez? En la era de las TIC un acto de ciberguerra, ciberterrorismo o ciber-mala suerte se postula como candidato para abrir la puerta del terror nuclear.

Ahora bien, tras captar nuestra atención con semejante título, ¿qué hay en el texto? Pues, básicamente, se describe un incidente reportado en una central nuclear. Según se refiere en el artículo, un cambiador de tomas falló tras estar operando de forma continuada durante un intervalo de tiempo demasiado largo. Este tipo de dispositivos se emplean en los transformadores de potencia para regular automáticamente la tensión en los devanados de salida manteniendo ésta dentro de límites prefijados. Puesto que estos dispositivos tienen capacidad de conectarse y gobernarse de forma remota, se especula con la posibilidad de que haya sido víctima de un ciberataque. Y nada más. ¿Pudo haberlo sido? Quizá sí, quizá no. ¿Cuál fue la afección sobre la central? Pues posiblemente ninguna. Como bien se dice en el texto, estos dispositivos se emplean en muchos puntos de la red eléctrica y no constituyen un componente exclusivo de una central nuclear. De hecho, hay muchos otros lugares donde un fallo de este tipo de dispositivos es, potencialmente, más dañino.

Así pues, la sensación tras leer el artículo es que nos encontramos con la descripción de un caso tipo “alguien ha matado a alguien”. La adición del factor nuclear actúa como multiplicador para dar entidad al caso.

Esto es sólo un ejemplo de cuán automática es la asociación de las palabras “Infraestructuras críticas” y “energía nuclear”. Y esta asociación, por tópica, acaba por diluir el riesgo real ya que, a fin de cuentas, la mayor parte de las infraestructuras críticas no son centrales nucleares y la mayor parte de los ciberataques no buscan (o buscarán) provocar un síndrome de China. Y es que una cosa es provocar la indisponibilidad de una central de generación (de cualquier tipo) y otra cosa es hacer volar un reactor nuclear. ¿Cuál es la diferencia (más allá de un impacto local) de provocar la indisponibilidad de un tipo de planta u otro? A efectos comparativos, la participación en la generación total durante el año 2012 del parque nuclear español fue del 22,1%, mientras que las centrales de carbón produjeron un 19,3% (2). Alguien podría argüir: “de acuerdo, pero Francia sí que tiene gran cantidad de generación nuclear, por lo que, ya que adquirimos gran cantidad de energía de nuestro vecino, la indisponibilidad de sus centrales sí que nos afectaría”. De nuevo hay una falacia aquí. El saldo de energía intercambiada con Francia durante 2012 fue de 1.524 GWh. El consumo total de España de 251.710 GWh (3). Por cierto que este año no fue una excepción: eléctricamente, la península es una isla a causa de la escasa capacidad de intercambio con el resto de Europa.

Hemos de tener cuidado, pues, con estas cosas. Los mensajes catastrofistas suelen ser contraproducentes, ya que la sociedad termina por insensibilizarse.

Especialmente cuando pasa el tiempo y el Juicio Final no parece llegar tal y como se anunció.

NOTA FINAL: la imagen que acompaña este artículo no es de una central nuclear. Pero es curiosa la tendencia de los medios de comunicación a asociar imágenes de torres de refrigeración, no exclusivas de este tipo de centrales, con noticias sobre energía atómica. O con noticias sobre emisión de CO2, pese a que lo que sale por ellas es vapor de agua.

(*) Simpson, Homer J.
(1) Imagen tomada de Wikipedia. Autor: Owen Cliffe.
(2)(3) Informe sobre el sistema eléctrico español. Año 2012. Red Eléctrica de España.

Ha vuelto a ocurrir.

Una canción de John Lennon dice en un punto algo así como: “Life is what happens to you while you are busy making other plans” (“la vida es lo que pasa mientras hacemos otros planes”). Podríamos parafrasearla de la siguiente manera: ‘La protección de infraestructuras críticas es lo que pasa mientras hacemos otros planes’.

¿A qué viene esto? Pues a que no dejo de sorprenderme de la cantidad de información acerca de una infraestructura crítica que la propia Administración ofrece de forma abierta en los Pliegos de contratación de obras, proyectos o servicios. Esta misma semana he podido comprobarlo de nuevo, concretamente con un Pliego destinado a contratar la ejecución de un sistema de gestión de la red de distribución de agua potable nada menos que a los municipios de un consorcio que cubre al 85% de la población de una provincia (y abastece a muchas industrias grandes de verdad). El sistema de gestión previsto debe consistir en un software capaz de integrarse con el SCADA que se emplea para supervisar las infraestructuras del Consorcio y facilitará la operación de forma que se optimice el consumo energético del conjunto del sistema (permítanme que no dé detalles adicionales, a pesar de que la información es accesible de forma pública).

Y para facilitar la elaboración de ofertas se adjunta al Pliego, como anexos, un conjunto de documentación que es muy útil si uno, en lugar de en preparar una Plica, está pensando en interferir de alguna forma en el correcto funcionamiento de la red (por decirlo de forma suave).

Para empezar se ofrece un plano que refleja toda la red: conducciones, depósitos, valvulería, chimeneas de equilibrio y estaciones de bombeo. Y además, con coordenadas UTM, para que no tengamos problema en encontrar cada una de las instalaciones (y gracias a Street View podremos realizar, además, una inspección previa del perímetro de un buen número de ellas sin necesidad de movernos de casa).

A continuación disponemos de un documento que describe con todo lujo de detalles el sistema SCADA: comenzando por la marca del software de supervisión y continuando con detalles de la programación realizada, lógica de operación, codificación gráfica, alarmas, etc.

Y para terminar, en el documento anterior se nos ofrece un amplísimo surtido de capturas de pantalla, incluyendo la configuración de tuberías, válvulas, bombas e instrumentación de estaciones de bombeo, acometidas a depósitos e, incluso, la planta potabilizadora. Por no faltar, no falta ni un esquema de la red de controladores.

A la vista de todo este material mi mente vuela libre elaborando planes (imaginarios, por supuesto) y escenarios de ataque, seleccionando los elementos cuyo fallo podría acarrear consecuencias más dañinas, pensando en cómo implementarlos (yo soy ingeniero industrial y me he dedicado unos cuantos años al tratamiento de aguas y la hidráulica).

Y yo digo: ¿realmente es necesario ofrecer todo este material de forma abierta? Es más, ¿la información aportada es la necesaria o, simplemente, se ha buscado un documento ya existente y se ha añadido como anexo sin tomarse la molestia de purgarlo? Porque esa es la impresión que me da al leerlo.

Son cosas como ésta las que hacen pensar que quizá los árboles de los riesgos tecnológicos nos impiden ver el bosque de los peligros más convencionales que nos rodean y que deberían ser objetivos preferenciales de actuación. A fin de cuentas, un pequeño esfuerzo en el control de la información que se pone a disposición pública puede rendir resultados proporcionalmente más efectivos que invertir mucho dinero en renovar un parque de equipos o modificar configuraciones de red.

Sé que es cierto que, en algunos casos, la propia legislación puede actuar en nuestra contra: por ejemplo al imponer un trámite de información pública en los proyectos de infraestructuras que obliga a exponer al público los proyectos de forma previa a su aprobación. Pero seguro que hay formas de acompasar todos los intereses.

Es necesario, por tanto, evitar que el prefijo ‘ciber-‘ que acompaña a la seguridad de sistemas de control industrial actúe como una mordaza mental que impida ver que existe un camino previo imprescindible en aspectos menos tecnológicos de la protección de nuestras infraestructuras.

Voy a terminar con una cita atribuida a Lenin (sin entrar en valoraciones morales sobre este personaje): ‘Los burgueses nos venderán la cuerda con la que les hemos de ahorcar’. Dejo al lector la trasposición al contexto actual, con el firme deseo de que logremos evitar convertirnos en colaboradores involuntarios del lado oscuro.

Suele decirse que la ignorancia es la felicidad. Del mismo modo, se acepta de forma universal la máxima contrapuesta que dice que el conocimiento es poder. Eventualmente todos hemos de situarnos en algún punto intermedio entre ambos extremos para no perder la estabilidad mental a causa de la ansiedad o sufrir un perjuicio grave a causa de una actitud excesivamente despreocupada. Sin embargo, cuando se trata de ciberseguridad de un sistema de control industrial disponer de conocimiento es algo crítico. En mi opinión, el desconocimiento de los procesos industriales por parte del lado oscuro es el dedo que tapona el agujero en el dique impidiendo que las aguas del mar invadan el terreno que éste protege. Pero, al igual que en la leyenda holandesa, no puede confiarse en que este remedio nos mantenga a salvo indefinidamente.

Es sorprendente cuan arraigado está entre muchos responsables de infraestructuras industriales el mito de la defensa por oscuridad. Este planteamiento, que puede entenderse en técnicos que no han tenido ocasión de recibir información acerca de estas cuestiones, es absolutamente inaceptable una vez que se reciben las primeras alertas acerca de la naturaleza de la amenaza. Todavía está muy extendida la idea de que el niño resistirá indefinidamente taponando el dique con su pequeño dedo.

El conocimiento de los procesos industriales y Stuxnet

Mucho se ha hablado ya de Stuxnet. Su refinamiento ha sido, con razón, causa de asombro generalizado en todo el mundo. Sin embargo, y desde mi desconocimiento de los detalles de ingeniería informática implicados, lo que en mi opinión marca un antes y un después de Stuxnet no es que sea el primer malware identificado diseñado específicamente para atacar un sistema de control industrial, sino el grado de conocimiento de los procesos físicos que lo hace posible.

Stuxnet fue diseñado atacar directamente al proceso de obtención de uranio enriquecido, material empleado como combustible en las centrales nucleares y en la construcción de armas nucleares. El uranio se presenta en la naturaleza como una combinación de dos isótopos, el ²³⁵U (más ligero) y el ²³⁸U (más pesado). La concentración de ²³⁵U es inferior al 1% y para su uso con fines militares es necesario enriquecer la mezcla por encima del 90% (frente al 20% requerido para usos energéticos). Esta tarea se lleva a cabo mediante centrifugadoras, que hacen girar a gran velocidad el uranio en estado gaseoso. En razón de su diferencia de peso el isótopo más pesado experimenta una mayor aceleración centrífuga y se desplaza hacia la periferia del cilindro rotatorio, mientras que la fracción ligera (la útil) queda en las inmediaciones del eje de giro. El gas recogido se procesa secuencialmente en varias centrifugadoras hasta alcanzar el nivel de pureza deseado. Se trata de un proceso muy lento, ya que la diferencia de peso entre ambos isótopos es muy pequeña (en razón de 3 unidades de peso atómico sobre 238), por lo que para alcanzar la masa necesaria para la construcción de un artefacto se requiere mucho tiempo (o mucha inversión para disponer de un gran número de centrifugadoras). Para hacer girar una centrifugadora a la velocidad requerida se emplean variadores de frecuencia como accionamiento de los motores eléctricos.

Una vez conocido el proceso físico los diseñadores de Stuxnet particularizaron su ataque seleccionando adecuadamente el blanco: sistemas de control de SIEMENS (PLC Simatic y SCADA WinCC) que supervisasen una planta en la cual existiesen variadores de frecuencia de marcas concretas (Vacon, finlandesa, y Fararo Paya, iraní) en un número superior a 33 unidades. Más específicamente, se requiere que las consignas de frecuencia de los variadores se encuentren entre 807 Hz y 1.210 Hz, frecuencias empleadas en este proceso.

Una vez seleccionado el blanco, ahora viene mi parte preferida: la elección del mecanismo de ataque. En este caso los creadores de Stuxnet fueron igual de meticulosos que en el resto de detalles. Una vez conseguido el control del sistema, se altera el buen progreso del proceso modificando el régimen de funcionamiento de las centrifugadoras haciendo que la frecuencia (es decir, la velocidad de giro) aumente a 1.410 Hz (por encima del valor máximo de operación normal), luego baje drásticamente a un valor tan pequeño como 2 Hz (casi parada, aunque el valor de velocidad final depende de otros factores), y luego acelere de nuevo a 1.064 Hz antes de regresar a la secuencia normal de operación. Esta operación se repite en ciclos predeterminados que implican, por ejemplo, funcionar 27 días a 1.410 Hz, una buena sacudida bajando a 2 Hz y volviendo a 1.064 Hz (resultando en un buen batido de uranio) durante otros 27 días y así, un ciclo tras otro. Esta mecánica no afecta a todas las centrifugadoras de cada grupo, sino sólo a algunas, imagino que para hacer más difícil la detección del funcionamiento anómalo. El objetivo no es sólo alterar el proceso. El objetivo no es destruir el equipo, borrar el programa o cualquier otra acción aparentemente definitiva pero, en la práctica, fácil de resolver. Estas acciones hubiesen puesto en alerta al operador y su efecto hubiese sido mucho menor. Es mucho más efectivo, sin duda, el mecanismo elegido: producir uranio por debajo de especificaciones de forma constante durante meses sin ninguna causa aparente, algo mucho más difícil de corregir y, por tanto, más dañino. El diseño incluía otras medidas destinadas a borrar su rastro, como no dejar registro de este funcionamiento anómalo en los históricos de variables o alarmas y mecanismos de reinfección de los PLC afectados en caso de que se reinstalase el programa de control original.

¿Qué lecciones podemos extraer de este caso?

Hay mucho provecho que sacar más allá del susto inicial experimentado por aquellos responsables y técnicos que, hasta ese momento, se sentían seguros (si es que alguna vez habían considerado la cuestión). Es útil hacer algunas reflexiones.

Gran parte del escepticismo (auténtico o impostado) de muchos responsables de sistemas de control industrial se basa en su falta de entendimiento de los mecanismos de ataque o de las motivaciones de los atacantes. Para muchos un ciberataque es el equivalente digital de un bombardeo masivo, algo para lo que no encuentran razones (para qué querría hacerme alguien eso a mí). Sin embargo, lo que nos enseña el caso Stuxnet es que es posible, a partir del conocimiento del proceso industrial, causar un daño mucho mayor y más difícil de corregir: vertidos de agua residual que no cumplen la Directiva; un incremento de producto fuera de especificaciones con el coste económico y de imagen ya que puede llevar asociado incumplimiento de plazos o, peor aún, que el producto defectuoso se sirva a clientes sin haber sido detectado en nuestra planta (a fin de cuentas, los muestreos estadísticos de calidad se diseñan conforme a la variabilidad ‘natural’ de nuestro proceso, no de un proceso alterado, por lo que el tamaño de los lotes o la frecuencia podrían ser inadecuados para descubrir la situación). O facturación errónea a causa de alteración en las lecturas de equipos de medida (evidentemente al alza, para desacreditar a la víctima ante su cliente). Y encima, los históricos del sistema nos dicen que todo está marchando bien. Vamos, para volverse locos. Además, seamos sinceros, ¿cuánto tiempo transcurrirá hasta que pase por nuestra cabeza la idea de que quizá nuestro sistema de control ha sufrido un ciberataque? A fin de cuentas, no es un riesgo con el que hayamos contado nunca…

Podría pensarse que este tipo de ataques no se va a dirigir específicamente contra nosotros, que tenemos muchos amigos y no nos metemos con nadie. Pero en un mercado global donde los procesos y maquinaria están cada vez más estandarizados, ¿quién puede asegurar que uno no va ser atacado por un malware dirigido contra un tercero que da la casualidad de compartir equipos o métodos con nosotros? Por ejemplo, las máquinas centrífugas empleadas originalmente en la producción de aceite de oliva han encontrado un ámbito de aplicación nuevo en la deshidratación de fangos de plantas de tratamiento de agua residual o potabilización.

También es habitual escuchar argumentos como que ‘nuestro sistema no está conectado a internet’. Aparte del saludable escepticismo con el que deben acogerse este tipo de afirmaciones hay que recordar que Stuxnet estaba diseñado para poder propagarse, si tenía ocasión, a través del uso de dispositivos portátiles, como memorias USB o el PC empleado para programar los PLC.

Lo que todo ingeniero sabe

Hasta hace un tiempo la información necesaria para diseñar un proceso industrial se basaba en papel y los mecanismos de acceso a la misma eran muy limitados: adquisición de libros, catálogos proporcionados por proveedores en visitas personales, documentación obtenida en cursos específicos: fotocopias, fotocopias, fotocopias. Internet ha cambiado todo eso. Hoy en día disponemos de una cornucopia de documentación altamente detallada y específica desde nuestro PC de trabajo. Recuerdo los tiempos en los que todo ingeniero almacenaba grandes cantidades de información en distintos soportes en los que residía su conocimiento y capacidad de diseño (y su pérdida era un riesgo que no se podría permitir). Hoy en día eso ya no es necesario, internet es el gran archivo: pdf, pdf, pdf.

Es asombrosa la cantidad de cosas que se puede saber acerca del proceso y equipos de una empresa en concreto haciendo una búsqueda bien orientada. Más allá de la documentación técnica en formas de catálogos o fichas técnicas, los proveedores suelen describir sus referencias y casos de éxito, en ocasiones con todo lujo de detalle, en múltiples lugares: sus sitios de internet, en publicaciones del sector en el que trabajan, en jornadas, ferias y congresos. Las propias empresas publican en ocasiones artículos acerca de desarrollos punteros (o simplemente de los que están orgullosos). Las empresas constructoras y sus subcontratas hacen lo propio. En el caso de infraestructuras, la propia Administración pone a disposición de quien sepa encontrarla información en la forma de Pliegos donde se describe con todo lujo de detalle la infraestructura objeto de licitación. Incluso los mismos proyectos de construcción (trámite de información pública) están a disposición de cualquier ciudadano que quiera consultarlos. También hay proyectos de fin de carrera y tesis doctorales, algunas  auspiciadas por empresas catalogadas como operadores críticos: yo mismo he encontrado documentos académicos describiendo los protocolos y redes de comunicación y sistemas de control de subestaciones eléctricas de empresas con nombre y apellidos. Tarde o temprano esta información acaba convertida en un pdf y subida a internet, naturalmente sin intención maliciosa.

A la vista de todo esto: ¿de verdad quiere basar su ciberseguridad en la idea de que nadie conoce su proceso industrial?

Nota. La información específica acerca de Stuxnet y su funcionamiento se ha extraído del informe publicado por Symantec (autores Nicolas Falliere, Liam O’Murchu, y Eric Chien) y puede consultarse aquí.

Seguro que todos hemos esbozado una sonrisa en alguna ocasión al contemplar imágenes o fotografías de extraños artilugios accionados mediante máquinas de vapor o motores de combustión interna enormemente primitivos. Estos artilugios, destinados a todo tipo de propósitos, se quedaron en experimentos fallidos ya que la tecnología empleada era totalmente inapropiada para el fin al que el inventor decidió destinarla. A nuestros ojos constituye una muestra de ingenuidad intentar hacer volar un artefacto provisto de máquinas de vapor como motores.

Sin embargo, aquellos inventores no eran tan tontos como el fracaso de sus ingenios podría hacernos pensar. Era gente inteligente (al menos no menos inteligentes que la media) que trataba de resolver los problemas de su época con la tecnología a su alcance. En el caso de las máquinas de vapor su aparición marca el inicio de la industrialización, del acceso del ser humano a cantidades de energía nunca antes vistas. El descubrimiento de esta tecnología supuso una revolución técnica y cultural sin precedentes que abrió el camino a nuestra sociedad actual. Es natural que, en el ambiente de optimismo colectivo y fe en el progreso, se viese en las máquinas de vapor la solución a todo tipo de problemas de ingeniería inabordables hasta entonces.

[Read more…]

Esta mañana he venido a trabajar en metro, como acostumbro a hacer. Cuando he pasado junto a la fila de máquinas expendedoras de billetes he visto que una de ellas estaba bloqueada y en pantalla aparecía una ventana de error con una imagen fija que identificaba el sistema operativo de la misma: Windows 2000.

Este hecho, tan simple, nos sirve para ilustrar una de las características que diferencian los sistemas TIC de los sistemas de control industrial. Efectivamente, los PC de control y supervisión suelen tener el sistema operativo de uso corriente en el momento en que se implantó el sistema/instalación. Y suele permanecer así para siempre. Es más, en general ni siquiera se instalan las distintas actualizaciones distribuidas periódicamente por el desarrollador.

Esto tiene distintas causas. Algunas de ellas son las siguientes:

Tratar de despertar la conciencia de los riesgos en cuestiones de ciberseguridad en mis compañeros a cargo de instalaciones industriales es una tarea ardua. Hemos hablado en varias ocasiones de ello, poniendo de relevancia cómo el desconocimiento del funcionamiento y procedimientos de trabajo en los entornos TIC hace que los riesgos y mecanismos de ataque sean inconcebibles para estos ingenieros. Digo inconcebibles en el sentido estricto, es decir: no algo con una probabilidad muy baja de ocurrir, sino algo en lo que ni siquiera se puede pensar por carecer de los fundamentos culturales y la experiencia necesarios para ello.

La respuesta más habitual es la negación, articulada en torno a varias falacias que suelen justificar la sensación de seguridad. Una de ellas es la confianza en los mecanismos de protección físicos de las propias instalaciones o equipos: es decir, en los enclavamientos de seguridad implementados mediante sistemas mecánicos o eléctricos que funcionan de forma autónoma, sin requerir de procesamiento o elementos de comunicación y que, por tanto, se suponen invulnerables a un ciberataque. En cierto modo, en el esquema mental de un ingeniero de control (me incluyo), estos sistemas constituyen la última línea de defensa, absolutamente aislada y autónoma de cualquier incidencia en los sistemas basados en procesadores, también cuando esos procesadores son humanos y se emplean para evitar daños por operaciones manuales indebidas.

En mi propia experiencia el diseño de la instalación de control siempre se ha basado en el establecimiento de dos niveles:

• Un nivel superior basado en la instrumentación electrónica y en algoritmos de proceso que, por su propia naturaleza, permiten una regulación más fina y eficiente. Este nivel está basado en procesadores.
• Un nivel inferior basado en relés y actuadores eléctricos y mecánicos que permiten el funcionamiento del sistema en caso de fallo del sistema de control. Este nivel no se basa en procesadores y, además, impide al sistema físico funcionar en condiciones no deseadas. Se construye principalmente con sistemas electromecánicos y de lógica cableada.

Es en este segundo nivel donde reside la confianza en la imposibilidad de que los equipos físicos sufran daños incluso en el caso de que un individuo u organización tomase el control del sistema. Sin embargo, hay dos hechos que cuestionan de forma seria este paradigma de seguridad:

• Últimamente he observado que en muchas instalaciones los enclavamientos de seguridad se implementan a través de lecturas de instrumentación digital, redes de comunicación y los PLC de la red de control. El objetivo es múltiple: por un lado ahorrar costes en cableado y dispositivos que se entienden como redundantes, y por otro, confiar en la mayor precisión y posibilidad de configuración de los sistemas digitales. Conozco algunos casos de fallos con importes que se miden en decenas y cientos de miles de euros a causa de esta práctica.
• Los enclavamientos y sistemas de protección se diseñan para evitar daños en caso de que se den circunstancias de operación fuera del espacio de condiciones de trabajo admisibles. Pero puesto que los sistemas físicos no se explican a base de 1 y 0 (hay decimales) siempre se debe contar con un margen de reserva para evitar que condiciones transitorias debidas a la operación normal del sistema (o los propios márgenes de error de la calibración de los relés) produzcan el disparo intempestivo de las protecciones: bandas muertas de regulación, histéresis, retardos, márgenes de seguridad, etc.

En este segundo caso es posible, en principio, diseñar un ataque que se aproveche de esas bandas de no actuación de las protecciones para imponer condiciones de trabajo que resulten en un daño sobre los sistemas físicos. ¿Muy complicado? ¿Especulaciones sin fundamento? Lamentablemente no. Existe al menos un caso documentado en el cual se empleó esta estrategia con resultados espectaculares: la vulnerabilidad Aurora.

Se trata de una experiencia llevada a cabo en el INL (Idaho National Laboratory) en el año 2007 y, hasta donde he podido comprobar, ha caído en el limbo existente entre los profesionales dedicados a los sistemas de control y aquellos que se dedican a la seguridad de sistemas TIC: a fin de cuentas, entender el mecanismo del ataque exige tener un pie (metafóricamente hablando) en cada mitad del campo, razón por la cual pasó inadvertido para unos y otros más allá de un vídeo difundido por la CNN que, posiblemente a causa de la espectacularidad del mismo, desencadenó la reacción típica de negación en aquellos que podrían resultar directamente afectados por la vulnerabilidad. De hecho se ha cuestionado intensamente la veracidad de lo mostrado en el vídeo, llegándose a proponer que se emplearon dispositivos pirotécnicos para aumentar el efecto visual. Podéis ver el vídeo al final de esta entrada.

¿En qué consiste esta vulnerabilidad? El enunciado es sencillo: causar daños en un generador de energía eléctrica instalado en un sistema con todas las protecciones habituales aprovechando las posibilidades de mando remoto del mismo. ¿El resultado? Un éxito posiblemente inesperado que provocó la destrucción completa de un grupo generador diésel de 400.000 dólares.

De forma muy sencilla, el mecanismo de ataque es el siguiente:

Todos los grupos de generación se protegen frente a la conexión a la red en condiciones de falta de sincronismo, esto es: que la forma de onda que está siendo generada esté desfasada respecto a la existente en la red a la que se va a conectar el generador. A este fin se supervisan tensiones, frecuencia y fase. ¿Por qué? Porque puesto que, en general, la red tendrá una potencia muy superior a la del propio generador, en caso de conexión en condiciones no adecuadas, ésta forzará la sincronización casi instantánea del mismo. Esto resultará en la imposición de un par mecánico extraordinario en el eje del generador, sobreesfuerzo para el que no está diseñado y que, en caso de producirse de forma repetida acabará produciendo el fallo del mismo. Para visualizarlo fácilmente imaginemos a alguien que quiere subir a un tren en marcha: el procedimiento indicado es correr junto al tren a una velocidad similar y entonces saltar al interior. La alternativa es esperar junto a la vía y agarrarse a las escalerillas cuando pasan junto a nosotros. Es fácil intuir que el tirón en nuestro brazo no es algo a lo que nos queramos exponer.

Sin embargo, la actuación del conjunto de protecciones posee holguras que evitan la desconexión prematura del generador en caso de pequeñas (y admisibles) desviaciones de los parámetros supervisados. Esto es, ofrece una ventana de oportunidad para forzar condiciones no deseadas en el generador sin que la protección desconecte el grupo de la red. Se puede consultar un análisis técnico detallado de las condiciones técnicas del ataque y posibles medidas de protección.

Es cierto que para realizar un ataque de este tipo con éxito se deben cumplir un buen número de condiciones: conocimiento del sistema, posibilidad de acceso remoto al mismo, ciertas condiciones de funcionamiento del sistema eléctrico, conocimiento de las protecciones existentes y su configuración… Éstos son los argumentos que serán esgrimidos durante la fase de negación. Pero esa no es la cuestión.

La cuestión es la siguiente: dado el grado de exposición de los sistemas de control industrial a ciberataques por diversas causas (cuestiones culturales y organizativas, cuestiones técnicas, etc.) en realidad a la receta sólo le falta el conocimiento de los sistemas físicos y sus sistemas de control. La vulnerabilidad Aurora es un caso muy específico. Pero debe ser suficiente para demostrar que la confianza en las protecciones físicas de los equipos tiene sus límites y de que sólo hace falta alguien dispuesto a descubrirlos. Confiar en ellas como nuestra única línea de defensa es un riesgo que nadie se debería permitir.

¿No?

El vídeo original de la vulnerabilidad Aurora pueden verlo a continuación:

En ocasiones uno tiene que hacer un esfuerzo para compatibilizar sentimientos contradictorios. Este es el caso desde que trabajo en cuestiones de ciberseguridad industrial. He pasado gran parte de mi vida profesional dedicado a trabajar en el diseño y construcción de infraestructuras públicas, especialmente en el ámbito del tratamiento de aguas. En el desempeño de mis labores como ingeniero estuve al cargo del diseño de procesos industriales y sus sistemas de control, tanto las lógicas de funcionamiento como los esquemas eléctricos de fuerza y control, las arquitecturas de las redes de control y sus componentes, etc. En definitiva, los procesos y los sistemas SCADA asociados. Me gustaría creer que hice un buen trabajo.

He vivido la evolución que ha tenido lugar en los últimos años, que se podrían ejemplificar en algo simbólico: la desaparición del sinóptico tradicional con sus lámparas verdes y rojas y sus indicadores analógicos. Recuerdo perfectamente la primera vez que instalamos, en lugar del citado sinóptico, un monitor de plasma de 42”, algo pasmoso en aquel entonces. Ahora, rodeado de informáticos, me siento como si hubiese escogido la famosa pastilla roja de Matrix. Desde esta nueva perspectiva, repaso todos estos años en los que los ingenieros hemos ido adoptando las nuevas ventajas de la tecnología con una fe en el progreso digna de la era Victoriana. No tengo palabras para expresar el estupor que me causa comprobar cómo, en muchos casos, construimos castillos sobre cimientos de arena. Ahora veo la gravedad de la situación reflejada en la gran cantidad de equipos y sistemas de control expuestos a Internet sin las más mínimas medidas de seguridad. Y no son especulaciones. Los he visto. Es terrorífico comprobar que uno tiene en sus manos la capacidad de detener por completo el proceso de producción de una fábrica sin moverse de su silla (caso real). Pero, ¿puede acusarse de cruzar en rojo a quién nunca ha visto un semáforo?

Sin embargo, ha llegado la hora de despertar. La amenaza sobre miles de sistemas es demasiado grave para buscar excusas. A pesar de todo, en la mayoría de los casos, la primera reacción es la negación o la incredulidad. Es fácil de entender ya que los mecanismos de ataque son, en la mayoría de los casos, imposibles de concebir para los responsables de estas instalaciones. ¿Por dónde empezar, entonces? Aquí van algunas ideas para mis compañeros del ámbito industrial. Pueden ser repetidas como un mantra cada mañana para ayudar a tomar conciencia:

No esperemos a recibir el primer golpe. En palabras de Bob Marley: ‘Wake up, stand up…’

La Asociación Profesional de Peritos Informáticos (ASPEI, www.aspei.es), asociación sin ánimo de lucro cuya actividad se organiza en proyectos de I+D relacionados con la prueba electrónica, el peritaje informático y la informática forense, organizar un Curso de Peritaje Informático e Introducción a la Informática Forenseque tendrá lugar el próximo 14 de diciembre (17h – 21h) y 15 de diciembre (9h – 19h) en Madrid.

Los objetivos del curso es ofrecer los conocimientos mínimos, técnicos, legales y de procedimiento, requeridos para ejercer la profesión de perito informático. Está orientado a informáticos, pero hemos agrupado los temas más generales en el primer día para perfiles como abogados, investigadores privados o similares, que no estén interesados en los aspectos más detallados del segundo día.

Pueden obtener los detalles del programa y el curso a través de este enlace. Plazas limitadas.

Nota: la organización ofrece un descuento de 100 € a los lectores de Security Art Work. Para aprovecharse de éste, los alumnos deberían comunicar, en el momento de solicitar la inscripción, que han conocido el curso a través de este blog.

En anteriores entregas hemos repasado algunos aspectos específicos de la protección de los sistemas de control industrial desde el punto de vista de la ciberseguridad, incluyendo los aspectos culturales y humanos (Seguridad en entornos industriales: el primer paso, Seguridad en entornos industriales: aspectos específicos). Teniendo como premisa de que el planteamiento en este ámbito debe ser global hoy vamos a hablar de la forma en que se ejecutan gran parte de las obras públicas en España (muchas de las cuales serán, probablemente, infraestructuras críticas): se trata del proceso de construcción en tres fases, proyecto, obra y explotación.

En demasiadas ocasiones estas fases constituyen compartimentos estancos con escaso flujo de información. Durante la construcción intervienen la consultora de ingeniería redactora del proyecto, la empresa contratista y sus subcontratas y proveedores, la Administración adjudicataria a través de sus directores de contrato y obra y sus asistencias técnicas. En la gran mayoría de los casos los máximos responsables de las obras son personas con gran formación y experiencia en el ámbito de la obra civil, pero con muy poca en cuestiones industriales y de sistemas de control. Por tanto, las empresas subcontratistas y proveedores poseen en este ámbito una autonomía mucho mayor de la que sería deseable y es posible que decisiones como la arquitectura, conexión a Internet de un sistema de control, contraseñas, configuración de perfiles, etc. se tomen por personas que ni tienen la visión global necesaria ni la conciencia de la importancia de las mismas (hemos visto como se utiliza la posibilidad de conexión a Internet de un sistema de control, totalmente innecesaria por otra parte, como argumento de venta).

[Read more…]

Hace unos días introdujimos un concepto esencial en la seguridad en entornos industriales: la importancia de los aspectos humanos, organizativos y culturales. Como vimos, se trata de un primer paso esencial para garantizar el éxito de una estrategia integral de seguridad.

Hoy vamos a continuar nuestro viaje hacia los sistemas industriales introduciendo algunas características de los mismos que imposibilitan la aplicación directa de las técnicas propias del entorno TIC y cuya comprensión es imprescindible antes de abordar su protección.

La duración del ciclo de vida del equipamiento

La velocidad de la evolución tecnológica en las TIC es vertiginosa. Los equipos quedan obsoletos en un plazo que se mide en unos pocos años (a lo sumo). Ello permite que las innovaciones en cuestiones de seguridad puedan implantarse en un plazo breve, tan pronto como el equipamiento es reemplazado por otro de nueva generación. Por el contrario, el ciclo de vida de la maquinaria industrial y sus sistemas de control se mide incluso en décadas (sí, habéis leído bien). Por tanto hay que enfrentarse a un parque de sistemas heredados diseñados y construidos de espaldas a los requerimientos de seguridad actuales y que van a seguir en funcionamiento durante mucho tiempo.

[Read more…]