La entrada de hoy corre a cargo de Xavi Morant, coordinador técnico de CSIRT-CV. Xavi es Licenciado en Informática por la Universidad Politécnica de Valencia y ha desarrollado su carrera profesional dentro de la Generalitat Valenciana, tanto en el ámbito de la administración de Sistemas como en el de la Seguridad; desde 2007 ocupa el puesto de coordinador técnico del CSIRT-CV, el centro de seguridad TIC de la Comunitat Valenciana.

Ya se ha hablado en este blog en distintos artículos sobre los temas relacionados con sistemas SCADA y no es un tema que se pueda obviar fácilmente tratando de seguridad puesto que tanto a nivel internacional como a nivel nacional se han iniciado diversas acciones legislativas para proteger las infraestructuras críticas (IC) asociadas a este tipo de sistemas.

Los sistemas SCADA (Supervisory Control and Data Acquisition) se utilizan en redes de control de equipamiento en procesos industriales para monitorizar y controlar infraestructuras importantes tales como plantas de generación de energía, redes de transmisión eléctrica, control de aguas, refinerías, oleoductos o gaseoductos, además de sistemas de transporte y comunicaciones. Basta con echar un vistazo a la lista anterior para darnos cuenta de la importancia que pueden tener.

[Read more…]

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í.

La conexión masiva de los últimos años de todo tipo de equipamiento a Internet ha configurado un nuevo mundo digital donde la información, los individuos y las máquinas se comunican entre sí a todos los niveles.

Empezamos esta revolución del ciberespacio con la incorporación masiva de la información, seguimos incorporándonos nosotros, con el fenómeno de las redes sociales, y, en paralelo, estamos incorporando paulatinamente a las máquinas. Poco más nos queda. Estamos todos. Empieza el espectáculo.

A principios de 2012 CISCO estimaba que en el mundo existían 14.000 millones de dispositivos conectados a Internet sobre una población del orden de 7.000 millones de personas y un total de direcciones IP en torno a 4.300 millones. La misma compañía estimaba, según el ritmo de crecimiento previsto, que en 2020 esa cifra llegaría a 50.000 millones. Evidentemente hablamos de todo tipo de dispositivos smartphones, laptops, PLCs, ordenadores, sistemas de control y un largo etcétera.

Ya tenemos aquí esa cibersociedad montada sobre el ciberespacio bautizado por William Gibson en su novela Johnny Mnemonic (1981) y popularizado en su novela de ciencia ficción Neuromante(1984), con miles de millones de “individuos digitales” comunicándose entre sí. Lógicamente necesitamos trabajar para que esa cibersociedad sea cibersegura. Ahora bien, para avanzar en la seguridad de la cibersociedad debemos analizar con detalle la seguridad de las partes que lo componen.

El sector de la seguridad conoce bien los Sistemas de Información Corporativa y trabaja en su seguridad desde hace bastante tiempo. Los Sistemas de Control Industrial son otra cosa. Nuevos sistemas y nuevos escenarios que requieren nuevas soluciones. Es necesario caracterizar el nuevo escenario para diseñar las soluciones que requiere. Una buena forma de hacerlo es compararlo con lo que ya conocemos.

Por este motivo quería centrarme en este post en analizar algunas de las diferencias fundamentales entre dos grandes sistemas con los que tradicionalmente hemos convivido. Uno de ellos es un gran conocido para todos nosotros: Los Sistemas de Información Corporativa (SIC). Quien más y quien menos, directa o indirectamente, se habrá topado con uno de ellos cara a cara. Ya sea en su propio trabajo, en la oficina del banco o con la banca online, en el supermercado cuando la cajera hace la cuenta de lo comprado o en la compañía telefónica cuando se consulta el tiempo de permanencia que nos queda antes de que podamos cambiar de compañía sin coste para nuestro bolsillo. Detrás de todas estas operaciones hay sistemas de información de las compañías en las que trabajamos o nos dan servicio. Tal vez no sea tan evidente la existencia del otro gran tipo de sistemas: Los Sistemas de Control Industrial (SCI) que, aunque muchos de nosotros no nos topemos cara a cara diariamente con ellos, si sentimos su presencia. Hablamos de los sistemas que controlan las líneas de producción, los sistemas que controlan el suministro de bienes esenciales como la luz, el agua o el gas, los sistemas que gestionan la seguridad de locales de pública concurrencia y un largo etcétera.

Ambos llevan mucho tiempo con nosotros. Incluso los Sistemas de Control Industrial, aunque no lo parezca, llevan mucho más tiempo con nosotros que los Sistemas de Información Corporativa. Tal vez no tan sofisticados, y desde luego no tan “conectados”, pero sin duda más antiguos. A pesar de ser más “jóvenes”, los Sistemas de Información Corporativa se incorporaron mucho antes al ciberespacio y, por tanto, llevan ya un largo camino recorrido en lo que tiene que ver con la ciberseguridad.

Aunque son sistemas totalmente diferentes, no solo por su función sino también por su diseño y concepción, hoy por hoy comparten ya en muchos casos las tecnologías y los medios por los que se comunican. En gran medida ambos tipos de sistemas forman parte de la cibersociedad que comentábamos antes, son piezas de lo que llamamos el “Internet de las cosas” (IoT) y están todos en el ciberespacio.

Una de las principales diferencias entre ambos tipos de sistemas es el tipo de profesionales que los gestiona. Por su propia naturaleza, los Sistemas de Información Corporativa están gestionados tradicionalmente por Ingenieros Informáticos e Ingenieros de Telecomunicaciones, mientras que los Sistemas de Control Industrial han estado gestionados por Ingenieros Industriales, de Caminos, Aeronáuticos, Agrónomos, Químicos, etc… Ambos perfiles tienen grandes diferencias en todas sus facetas profesionales. Los primeros nacidos en la era de las TIC. Los segundos formados teniendo a las TIC como un medio y no como un fin y prestándole, años atrás, poca atención a lo que las TIC implicaban para los sistemas que gestionaban. Lenguajes diferentes para describir una misma realidad. Esta diferencia supone, sin duda alguna, un obstáculo a la hora de abordar el problema de la incorporación segura de los Sistemas de Control Industrial al ciberespacio.

Otra gran diferencia la encontramos en el significado del concepto de “tiempo real” en los dos mundos. Me gusta mucho la diferenciación que en algunos textos se hace del “right time” para los Sistemas de Información Corporativa frente al “real time” para los Sistemas de Control Industrial. Creo que este juego de palabras identifica muy bien las necesidades, en este sentido, de cada tipo de sistema.

Es también importante, a la hora de establecer las peculiaridades de cada sistema, contemplar la imposibilidad de apagar y encender un equipo como medida preventiva o correctiva en un Sistema de Control Industrial y, por tanto, la necesidad imperiosa de mantener la disponibilidad de este tipo de sistemas, frente a la necesidad de vigilar la confidencialidad e integridad de la información en los Sistemas de Información Corporativa. Por este motivo en los Sistemas de Información Corporativa se diseña la estrategia de la seguridad para la defensa de la información, mientras que en los Sistemas de Control Industrial se diseña una estrategia de defensa donde el TOP (Target of Protection) es, en este caso, el equipo en sí mismo.

En los Sistemas de Control Industrial la tolerancia a fallos es un parámetro vital de diseño. En los Sistemas de Información Corporativa, en general, se valora, pero puede no ser imprescindible en muchos casos y, desde luego, no siempre es un parámetro de diseño. Otro aspecto en el que se marcan distancias.

En la informática corporativa estamos acostumbrados a que la actualización de las aplicaciones a través de la distribución de parches sea frecuente y, en términos generales, sencilla. En la informática industrial las actualizaciones son complejas y requieren períodos de estudio y planes de contingencia y marcha atrás en el caso de que sea necesaria su aplicación. Esto, en sí mismo, al conectarse los equipos a Internet es un problema que se agrava si pensamos en el hecho que si bien el equipamiento que da servicio a los Sistemas de Información Corporativa se diseña con vidas útiles entre los 3 y los 5 años, el equipamiento que da servicio a los Sistemas de Control Industrial se diseñan para una vida útil entre 15 y 20 años, lo que hace más necesaria, si cabe, su actualización.

Para terminar, creo que es importante analizar el hecho de que hasta hace algunos años los Sistemas de Control Industrial estaban completamente aislados del mundo y no solo porque no estuviesen conectados al ciberespacio sino también porque utilizaban protocolos propietarios. Esta es otra gran diferencia en su origen y concepción. Los Sistemas de Información Corporativos manejan protocolos estándares desde hace mucho tiempo para lo bueno y para lo malo. Los Sistemas de Control Industrial se encuentran actualmente en un punto intermedio. Existen protocolos estándares conviviendo con soluciones propietarias pero conectadas cada vez más al ciberespacio. A este respecto he de decir que la seguridad por oscuridad no es una buena estrategia y que lo que debemos conseguir como sociedad es manejar estándares seguros, no desconocidos.

Aunque las diferencias entre ambos tipos de sistemas son muchas más, hemos contemplado las que en mi opinión resultan más relevantes. El análisis pausado de estas diferencias entre ambos tipos de sistemas nos ha llevado, de hecho, a contemplar la necesidad de crear un Centro de Seguridad con características específicas para abordar la Ciberseguridad de los Sistemas de Control Industrial: el iSOC (Industrial Security Operation Center), manteniendo el tradicional SOC (Security Operation Center) como Centro de Operaciones de Seguridad para Sistemas de Información Corporativa y contemplando, en cada caso, las características principales de los sistemas a los que se orienta.

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…]

Al hablar de protección de infraestructuras críticas, tal vez por deformación profesional, tendemos a asociarlo con ciberataques, compromiso de sistemas SCADA, o grandes explosiones de película en centrales eléctricas, pero tal como nos mostró el jueves la prensa, estos ataques también pueden ser rudimentarios a la vez que efectivos. Hablamos de que el miércoles en Egipto se detuvo a 3 submarinistas intentando cortar un importante cable submarino de telecomunicaciones.

Todos sabemos que nuestra dependencia de estos cables es enorme. Precisamente Microsiervos nos lo recordó la semana pasada con un video divulgativo dirigido al gran público que nos da una idea en tono desenfadado de su importancia.

Como vemos en el vídeo, muchos pueden ser los orígenes de las roturas de cables, pero no se menciona que el peligro de sabotaje puede ser uno de los más devastadores. Ya en 2008 hubo una serie de cortes relativamente sincronizados en distintos puntos del planeta que ocasionaron importantes pérdidas de comunicaciones a nivel mundial lo que llevó a pensar que se trataba de un sabotaje a gran escala.

Paralelamente, al desconectar parte de Asia de Internet se redujeron significativamente los niveles mundiales de Spam, lo cual nos da una idea de la globalidad de Internet y hasta qué punto un corte en un cable a miles de kilómetros nos puede afectar.

Ante una avería fortuita podemos enfrentarnos a pérdidas importantes del servicio de telecomunicaciones, pero ¿qué sucede si estos cortes son sabotajes preparados con el fin de producir un mal mayor? ¿Qué pasaría si antes de un ataque militar se ataca a sus infraestructuras de comunicaciones? ¿Es descabellado que ante un rescate financiero alguien pudiese sacar provecho de una situación de caos dejando a parte de la población sin Internet? ¿Y ante una la salida a bolsa de alguna gran empresa? Algunas de estas situaciones pueden parecer muy peliculeras, pero solo hay que conseguir que la ecuación coste/beneficio sea propicia para el atacante y tendremos el escenario perfecto para un ataque de estas características (sin hablar de ataques reivindicativos, extremistas o simplemente destructivos por que sí).

De momento no se ha cuantificado el precio económico del corte del miércoles pero en el siguiente gráfico publicado en Twitter se puede apreciar cómo ha afectado a la disponibilidad de las redes según países, llegando en casos como Egypto o Uganda a perder entre un tercio y la mitad de sus conexiones.

Aparentemente un ataque de estas características no debe ser excesivamente sencillo de perpetrar ya que como se puede ver en los vídeos relacionados, estos cables se protegen durante los primeros kilómetros cerca de la costa, generalmente enterrándolos, con zanjas, bloques de hormigón, o grandes surcos,  pero algo ha fallado cuando 3 individuos han podido causar un corte de telecomunicaciones de estas características.

No creo que se publiquen más detalles al respecto que arrojen algo de luz sobre los motivos del sabotaje, pero independientemente de ello queda claro que no siempre se valora el riesgo como se debe.

Videos relacionados:

Ya que el tema nos resulta interesante a muchos, aprovechamos la ocasión para enlazar algunos videos interesantes al respecto de los cables submarinos:

• ¿Cómo se protegen los cables?
• Reparación de cables submarinos
• Estableciendo comunicaciones con cables submarinos

(Fuente de la imagen: Renesys Corporation, @renesys. Enlace a la imagen)

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.