Una visión global de la ciberseguridad de los sistemas de control (II)

(N.d.E. Este artículo fue publicado en el número 106 de la revista SIC, correspondiente a Septiembre de 2013. Sus autores son Óscar Navarro Carrasco, Responsable de ciberseguridad industrial, y Antonio Villalón Huerta, Director de seguridad. Ambos trabajan en S2 Grupo y pueden ser contactados vía onavarro en s2grupo.es y avillalon en s2grupo.es)

La semana pasada finalizábamos el artículo haciendo al lector una pregunta ¿tiene en cuenta el enfoque actual de la ciberseguridad industrial este contexto?

Y la respuesta, en nuestra opinión, es que NO.

En primer lugar, y siempre en términos generales, los elegidos dentro de las empresas para gestionar la ciberseguridad industrial y todo lo referente a la LPIC son, como no debe ser de otra forma, los departamentos de seguridad, en el mejor de los casos, o los responsables de seguridad tecnológica; incluso si no existen estos roles, es directamente el departamento TI quien pasa a hacerse cargo de cualquier cosa que tenga el prefijo “ciber”. Esta elección puede parecer obvia en ciertas ocasiones, pero como ya indicamos al principio, saber conducir no es equivalente a conocer la ruta.

Estas personas tienen que librar una batalla con departamentos en ocasiones más antiguos, con directivos ‘pata negra’ que han trabajado en el núcleo del negocio –o eso creen- toda la vida (posiblemente en el sentido estricto), que perciben la seguridad como un simple gasto y cualquier cosa tecnológica como algo recién llegado que carece de una importancia real y que llega a invadir su territorio, su reino. Y lo que es peor, es muy posible que en las reuniones quede patente que, efectivamente algunos departamentos de seguridad –o de tecnologías- no conocen ni siquiera este lenguaje, al igual que esos “expertos” en negocio no entienden ni una palabra del riesgo tecnológico. El resultado de las confrontaciones las debe resolver un superior jerárquico que posiblemente proceda, igualmente, del ‘núcleo duro’ y que entiende lo que dice una parte, pero por desgracia posiblemente no lo que dice la otra. Y es muy difícil convencer a alguien cuando el único argumento que queda es el de la amenaza, especialmente si ésta no se percibe como tal. Otras amenazas, como las consecuencias de un fallo en el sistema de control a causa de una intervención incorrecta (medible en repercusión social y lucro cesante) son mucho más fácilmente asimilables, ya que suponen la preocupación diaria de estos directivos.

Es poco realista fijar objetivos a largo plazo considerando como tal el horizonte 2017-2018, como se propone en el Mapa de ruta de ciberseguridad industrial en España. Guste o no, en un sector donde algunos PLC todavía usan sistemas operativos y protocolos de más de 20 años de antigüedad, 5 años constituye un plazo, a lo sumo, medio, al menos de momento. Es a consecuencia de todo ello que se llega a una situación de bloqueo como la actual, lo que tiene como resultado que los plazos previstos en la LPIC y en el Reglamento que la desarrolla se estén incumpliendo.

Es posible, incluso, que los responsables de los sistemas de control industrial intenten adoptar medidas en este ámbito, siempre bajo su supervisión. El problema de esta aproximación es que ni la formación ni la cultura facultan al personal de este departamento para trabajar en esta cuestión, siempre hablando en términos generales. Incluso puede que estas medidas no tengan más objeto que justificar que se están ‘haciendo cosas’, una razón más para apartar de la cuestión al departamento de seguridad o al departamento TI y proseguir con esa lucha entre reinos que tanto suele preocupar a esos directivos “pata negra” y tan poco preocupa a la sociedad.

Certificaciones polémicas

Es fácil caer en la tentación de trasladar directamente las estrategias y experiencias que han dado buen resultado en el ámbito TI al ámbito industrial. Recuérdese el dicho: “cuando todo lo que tenga sea un martillo, todo lo que vea le parecerá un clavo”. Sólo un ejemplo, existe ya una certificación expedida por el IACRB denominada CSSA (Certified SCADA Security Architect). En primer lugar, en el campo profesional industrial un pie de firma repleto de acrónimos correspondientes a certificaciones resulta, cuando menos, extravagante —al igual que a muchos nos parece ridículo en el ámbito tecnológico—. La pregunta es: ¿Cuántos sistemas SCADA o procesos industriales han diseñado los poseedores de tal acreditación? ¿Es necesaria experiencia previa en sistemas SCADA para obtenerla? Más aún, los profesionales que se dedican, por ejemplo, a programar PLC ¿poseen la base necesaria para alcanzar la certificación? Antes de responder afirmativamente, rogamos al lector que se pregunte con cuántos programadores de PLC ha hablado. La realidad es que tal certificación está en posesión, al menos en España, de profesionales del ámbito TIC. Es fácil y obvio imaginar la escasa disposición de un responsable de un sistema de control a aceptar recomendaciones de un CSSA sin experiencia en diseño, operación o mantenimiento de sistemas SCADA.

fotoOtro error consiste en pretender que el sector industrial y de infraestructuras adopte cambios o acometa acciones radicales a la velocidad a que suele ocurrir o es posible en las TIC. En este caso hay que buscar un término medio entre pretender lo imposible y retrasar lo inevitable, dos caminos que conducen al desastre. En este sentido es, en nuestra opinión, poco realista fijar objetivos a largo plazo considerando como tal el horizonte 2017-2018, como se propone en la recientemente publicado Mapa de ruta de ciberseguridad industrial en España del Centro de Ciberseguridad Industrial. Guste o no, en un sector donde algunos PLC todavía utilizan sistemas operativos y protocolos de comunicaciones de más de 20 años de antigüedad (un éxito, sin duda, de sus creadores), 5 años constituye un plazo, a lo sumo, medio, al menos de momento. Es a consecuencia de todo ello que se llega a una situación de bloqueo como la actual, lo que tiene como resultado que los plazos previstos en la LPIC y en el Reglamento que la desarrolla se estén incumpliendo.

Lo dicho anteriormente no se basa en especulaciones sin fundamento. Es el resultado de nuestra experiencia al respecto, tanto de S2 Grupo como la nuestra en particular. Uno de los autores es Ingeniero Industrial y hasta su incorporación a S2 Grupo había desarrollado su carrera en el ámbito de la ingeniería y construcción; nunca había trabajado con ingenieros informáticos. Por el contrario, otro de los autores es Ingeniero Informático, especializado en seguridad, por lo que para él hablar de meses o años para corregir una vulnerabilidad, o utilizar sistemas operativos de hace lustros es, sencillamente, algo no asumible. Tanto uno como otro llegan a afirmar que la relación con los otros profesionales es comparable a la del contacto con alienígenas y sólo cuando han desarrollado un lenguaje común y tenido una noción del trabajo llevado a cabo por la otra parte ha sido posible iniciar una relación fructífera. A la vista de todo lo expuesto, cabe cuestionar si el enfoque actual de la ciberseguridad industrial es el adecuado o si los que trabajamos en seguridad desde hace tiempo estamos pensando que la situación —y la solución— es sólo cosa nuestra. Se dice que no por mucho madrugar amanece más temprano y lo urgente de la cuestión no justifica adoptar medidas precipitadas, más aún cuando éstas pueden resultar contraproducentes.

Se ha hablado mucho de la falta de formación en ciberseguridad de los profesionales del ámbito industrial, asi como de concienciación. Sin duda, son aspectos en los que se debe trabajar. Pero hay dos cuestiones en las que no se suele reparar y que son de la mayor importancia: la inercia/conservadurismo y el corporativismo.

En nuestra opinión, el trabajo de mejora de la ciberseguridad industrial no puede realizarse de espaldas a los profesionales que han diseñado, construido y mantienen en explotación las infraestructuras que se deben proteger, igual que esos profesionales no pueden vivir ni un minuto más sin concienciarse –siempre es el primer paso- de la importancia de la seguridad. Es evidente que ambas partes tienen mucho que aportar y su participación es imprescindible. Los expertos en seguridad tecnológica poseen la experiencia y las herramientas técnicas, mientras que los profesionales en procesos y sistemas de control industrial deben aportar su conocimiento de los sectores productivos, los procesos controlados y las limitaciones que el contexto impone a las soluciones específicas.

Por ejemplo, hay cuestiones que el sector tecnológico ha resuelto de forma excelente y que deben incorporarse, con las consideraciones específicas oportunas, al ámbito de los sistemas de control. En primer lugar, el empleo de técnicas de correlación compleja para la identificación y caracterización de incidentes de seguridad. Ello es tanto más importante por cuanto los ataques a estos sistemas están adoptando la forma de APT y son, por tanto, bastante más complejos que una simple orden de ‘shutdown’. En segundo lugar, el modo en que se gestionan los incidentes en el ámbito tecnológico; los sistemas industriales están diseñados para hacer que el fallo sea algo extremadamente raro (tanto más raro cuanto más peligroso resulte). Su gestión está poco regulada y depende altamente de las personas y su experiencia y conocimiento de la instalación controlada. En cambio, en las TIC se ha aprendido a convivir con el fallo, razón por la cual se han desarrollado herramientas, sistemas y procedimientos de gestión que permiten tratar eficazmente las consecuencias, por ejemplo, de un ciberataque. A modo de ejemplo y en esta línea en S2 Grupo disponemos de un iSOC (industrial Security Operation Center) destinado a tratar estas incidencias con un enfoque mixto.

En definitiva, creemos que la estrategia actual en ciberseguridad industrial ha descuidado, hasta el momento, algunos aspectos cruciales. Como consecuencia, el progreso ha sido más lento de lo esperado a pesar de las exigencias legislativas. Para corregir esta situación hay que incidir en cuestiones que hasta el momento no han recibido la atención necesaria:

1. Tener en cuenta que el sector industrial es muy heterogéneo, por lo que no existen soluciones generales. Es imprescindible conocer las particularidades de cada uno de ellos para realizar un enfoque adecuado. Este trabajo sólo pueden hacerlo profesionales de los sectores implicados.
2. Recordar que un sistema SCADA no es sólo el software de supervisión, el servidor SCADA o la red de comunicaciones (elementos familiares para un profesional TI). Se trata de un sistema complejo en el que también hay elementos físicos (como, por ejemplo, instrumentación y actuadores). En este sentido, posibles soluciones para problemas específicos irresolubles a nivel TI pueden pasar por volver a recuperar cosas como la lógica cableada y los enclavamientos físicos y eléctricos, viejos conocidos de los profesionales industriales.
3. Tener en cuenta el ritmo a que se asimilan los cambios en el sector industrial para no fijar horizontes no realistas.
4. Prestar la máxima atención al factor humano, evitando que se den situaciones de enfrentamiento tipo Nosotros vs. Ellos que acaben en posiciones ultradefensivas o de bloqueo.
5. Desarrollar aproximaciones sucesivas teniendo en cuenta las largas vidas útiles de equipos e instalaciones.
6. Las Administraciones y otras entidades licitadoras de infraestructuras deben incluir en los pliegos exigencias concretas relativas a la ciberseguridad industrial de las instalaciones proyectadas, de forma que estas condiciones pasen a formar parte del proceso proyecto-construcción.
7. Es imprescindible la formación de equipos interdisciplinares lo que debe alcanzar también a la interlocución con los responsables de la gestión de las infraestructuras críticas. De esta forma, éstos podrán comunicarse, además de con expertos en ciberseguridad, con personas de formación y experiencia afines, lo que ayudará a salvar los obstáculos culturales (especialmente a un nivel intermedio).
8. Se hace mucho énfasis en la formación, especialmente en la forma de másteres específicos. Pero no debe olvidarse que, en muchas ocasiones, los propios programadores disponen de gran autonomía en la toma de decisiones técnicas específicas en el diseño de los sistemas, por lo que no se debe descuidar ningún nivel educativo o profesional.
9. Siguiendo con la formación, creemos que debe evitarse extender el modelo basado en certificaciones específicas, tan habitual entre los profesionales TIC, a los especialistas en sistemas de control industrial.
10. Se deben desarrollar instalaciones dotadas de sistemas de control, industrial suficientemente realistas como para permitir adquirir experiencia en ciberseguridad (tanto en estrategias de ataque como de defensa o gestión de incidentes). Estas instalaciones son el ámbito idóneo para los equipos mixtos que deben trabajar en ellos desde el momento mismo del diseño. Además, constituyen un medio de demostración importantísimo para el personal no formado en ciberseguridad.
11. A modo de resumen final: evitar trasladar tal cual la experiencia y procedimientos de ciberseguridad en el ámbito TI al ámbito industrial. Una nueva cultura común debe surgir del trabajo conjunto de todos.

Pueden descargar el artículo original desde este enlace: Una visión global de la ciberseguridad de los sistemas de control. Revista SIC, número 106, Septiembre 2013.

Comments

  1. Como bien dices los plazos que se manejan no son razonables y el entendimiento por parte de las esferas superiores de la problemática brilla por su ausencia.

    El primer punto que comentas me parece importante: es un sector heterogéneo. Se pretenden implantar soluciones comunes a problemas dispares.

    Los puntos 6 y 7 también son capitales, se necesitan equipos interdisciplinares como bien comentas y que papá Estado tome la batuta para apretar las tuercas a esos directivos tacaños.

  2. Hola. Soy ingeniero informático trabajando en el área industrial (industrial IT, me gusta llamarlo). Hace algunos meses tuve la ocasión de participar en una evaluación de seguridad de una importante industria. La pasaron perfectamente, lo que estaba perfectamente esperado.
    Lo que me llamó la atención de la situación es que en la entrevista y evaluación no participó nadie de IT (esa gente de administración, decía el jefe de planta). Y para mejorar la situación supimos que la «zona de planta» de la red era considerada tan peligrosa como la «zona internet». Esto es, se habían instalado las mismas medidas de seguridad (firewalls, routers inteligentes, reglas de conectividad, etc.) para conectar la red de la zona de administración con la red de la planta que las que disponían para conectar con el mundo exterior.
    ¿Curioso no?