Hasta hace unos años, los mundos OT (Tecnologías de la Operación, como sensores, actuadores, etc) e IT (Tecnologías de la Información, como microcontroladores, ordenadores, redes, etc), eran mundos completamente separados, sin embargo, se está produciendo un enorme incremento en la digitalización de Sistemas OT, proceso que se denomina convergencia IT/OT.

Si estos procesos no se realizan adecuadamente se pueden producir problemas, con un alcance y unas consecuencias difíciles de determinar. Es frecuente encontrar noticias relacionadas con problemas en sistemas IT/OT, que en ocasiones, tienen como resultado la retirada temporal, o permanente, de productos del mercado, o la necesidad de realizar costosas modificaciones para que estos productos puedan seguir en el mercado con las debidas funcionalidades y garantías de seguridad. Pero en casos extremos, estos problemas también pueden afectar a la seguridad o a la privacidad de las personas, y si no se detectan y corrigen a tiempo, pueden acabar en un desastre.

Los principales motores de esta imparable convergencia IT/OT, en un mundo en el que lo analógico ha desaparecido casi por completo, son el intento de que los sistemas OT sean más inteligentes, eficaces o eficientes, o la intención de añadir a los sistemas OT funcionalidades del mundo IT, que usamos en nuestra vida cotidiana.

Un ejemplo muy evidente de esta convergencia IT/OT, lo podemos ver en los vehículos conectados. Esa convergencia IT/OT nos permite acceder en nuestro vehículo a funcionalidades propias de los smartphones, como acceso a música en streaming, navegación avanzada con avisos en tiempo real e información del tráfico, precio del combustible en gasolineras de la ruta, control por voz, información meteorológica, localización y estado de ocupación de puntos de recarga eléctrico, búsqueda avanzada de destinos de navegación, información de estado del vehículo, pantallas táctiles, tableros digitales, etc.

A lo largo del artículo usaré algunos ejemplos basados en el mercado de la automoción. No por el hecho de que los fabricantes de vehículos lo estén haciendo mal, sino por ser el coche un elemento muy cercano a los lectores y estár sometido a un fuerte proceso de digitalización en estos momentos.

También hay que destacar, que los problemas de convergencia IT/OT son muy complejos y que por lo tanto, en los ejemplos del artículo, que han sido muy simplificados, no se han tenido en cuenta todos los factores que pueden intervenir en un proceso de convergencia IT/OT, como el acceso a la tecnología, “know how”, patentes, acuerdos comerciales, evolución tecnológica, logística, inteligencia competitiva y tecnológica, etc. Los ejemplos, que como hemos dicho son muy simples, intentan exponer casos prácticos para ilustrar algunos problemas relacionados con la gestión del ciclo de vida de los sistemas IT/OT.

En realidad, mucho de lo comento en este artículo es fruto de mi experiencia en la detección y gestión de la obsolescencia en sistemas de armas y plataformas aéreas, pero son experiencias que se puede extrapolar a los procesos de digitalización en los que se produzca una convergencia IT/OT. Estamos hablando de sistemas de control industrial, sistemas de gestión de energía, sistemas médicos, sistemas de automoción, sistemas navales, sistemas de seguridad física integrados con sistemas de seguridad lógica (según establece la Directiva NIS), ciudades inteligentes, casas inteligentes, etc.

Hay que aclarar, que cuando un sistema OT lo conectamos a Internet, tenemos un sistema IoT, lo que ya implica un entorno no amigable desde el punto de vista de la seguridad lógica (ciberseguridad), por lo que en todo sistema IoT se debería considerar la necesidad de cibeseguridad por diseño y por defecto. Pero si somos consecuentes con la situación tecnológica actual, esta seguridad por diseño y por defecto, se debería aplicar a todos los sistemas IT/OT aunque no se conecten a Internet. Ningún sistema IT/OT está aislado aunque no tenga conexión a Internet, siempre hay alguna conexión para proceder a la actualización de software o datos.

Por ejemplo, si consideramos un vehículo digitalizado pero sin conexión a Internet, se podría utilizar un dispositivo USB para actualizar el firmware del módulo Bluetooth y hacerlo compatible con un nuevo Smartphone, o para actualizar la base de datos de navegación del GPS. En ambos casos se produce una conexión a Internet de forma indirecta a través de un dispositivo USB y ese dispositivo puede estar infectado por malware. Por ello, hay que tener en cuenta todas las amenazas y todos vectores de infección que puedan afectar a un sistema IT/OT en base a su operativa específica y las interfaces utilizadas, considerando siempre que el entorno de trabajo puede ser hostil desde el punto de vista de la ciberseguridad.

Tras analizar las causas más frecuentes de los problemas de convergencia IT/OT que han provocado la retirada de productos del mercado, ya sea de forma temporal o permanente, o la modificación de los mismos, destacan las siguientes:

a) Funcionalidades obtenidas mediante los sistemas IT/OT que afectan directa o indirectamente a la privacidad o la seguridad de los usuarios. Muchas veces, estos problemas se producen por considerar que el entorno de funcionamiento del sistema es demasiado “amigable” desde el punto de vista de la ciberseguridad, por no tener en cuenta que la información que genera o procesa el dispositivo puede tener usos distintos a los considerados inicialmente por el fabricante, o por no contemplar que la información que procesa el dispositivo puede ser manipulada por terceros en determinadas condiciones.

Por ejemplo, una pulsera de actividad física puede filtrar datos de la vida privada de un usuario (actividad sexual, estado de salud, ubicaciones, etc), además de proporcionar los datos deseados sobre su actividad física y estado físico del usuario, que es para lo que fue diseñada.

Asimismo, podemos considerar un medidor de glucosa conectado a Internet, para facilitar a los médicos un conocimiento preciso del índice glucémico de sus pacientes a lo largo del día. Si la ciberseguridad del dispositivo no se diseña adecuadamente, podría sufrir un ataque “hombre en medio” (MitM) y el atacante podría modificar los datos engañando al médico, con lo que el paciente podría recibir dosis de insulina erróneas y que incluso podrían producir su fallecimiento por un coma diabético.

b) Problemas de interoperabilidad a lo largo del ciclo de vida del producto, que provocan que el sistema no pueda funcionar adecuadamente en un nuevo entorno tecnológico.

Por ejemplo, pensemos en un vehículo conectado que accede a determinados servicios digitales mediante una conexión WIFI, o Bluetooth que le proporciona el smartphone del usuario. Si en algún momento cambian los protocolos, los algoritmos, o las frecuencias de esas conexiones inalámbricas, no será posible establecer esa comunicación si no se actualiza el sistema para que sea compatible esos nuevos protocolos, algoritmos o frecuencias.

Aunque los problemas de obsolescencia (por interoperabilidad o ciberseguridad) que afecten a protocolos y algoritmos es posible que se puedan solucionar con una simple actualización de software o firmware (siempre que lo permita la capacidad de proceso y la memoria disponibles en el dispositivo), en algunos casos, como en los que se necesite un cambio en las frecuencias de funcionamiento de las conexiones inalámbricas, o en las interfaces, la actualización del sistema IT/OT también puede implicar un cambio en el hardware. Algo que debería estar previsto por los fabricantes del sistema IT/OT, si no desean tener problemas a lo largo del ciclo de vida del producto, especialmente, si ese ciclo es muy largo.

De hecho, vincular la conectividad de un vehículo, que tiene un ciclo de vida de 10 años o más, con un smartphone, con un ciclo de vida de aproximadamente dos años, genera mucha incertidumbre tecnológica y con ello, riesgos asociados a la necesaria gestión del ciclo de vida del sistema, especialmente en lo que se refiere a la ciberseguridad e interoperabilidad del sistema IT/OT.

Hay que señalar, que la interoperabilidad tiene una gran relación con la ciberseguridad de los sistemas IT/OT. Si tenemos que mantener alguna tecnología obsoleta por no poder adaptar el sistema IT/OT a una nueva situación tecnológica (por ejemplo, si no podemos actualizar un sistema operativo de ciclo de vida corto, por incompatibilidad con el hardware), aparte de generar una dependencia tecnológica irresoluble, que a medio plazo puede sacar nuestro producto del mercado, tampoco nos permitirá actualizar su ciberseguridad, lo que también puede sacar el producto del mercado.

Por ello, salvo que sea un sistema operativo móvil con una versión especial para automoción con ciclo de vida muy largo, que el sistema que controla todas las funciones del vehículo (sistema de información y entretenimiento) funcione con un sistema operativo de rápida evolución, como Android, también introduce incertidumbres tecnológicas y serios riesgos para la gestión del ciclo de vida.

Dada la rápida evolución de Android y de los dispositivos de hardware asociados a dicho sistema operativo, es muy probable que a medio o largo plazo se produzcan incompatibilidades con nuestro hardware. La primera consecuencia de esta incompatibilidad, es que no podamos actualizar nuestro dispositivo IT/OT a la siguiente versión de Android (algo que también le pasa a los smartphones cuando tienen más de dos años). La segunda consecuencia, es que se tenga que renunciar a las actualizaciones de seguridad, lo que puede que a corto o medio plazo puede acabar afectando a la seguridad operativa y funcional “safety” del vehículo.

Esta rápida evolución de smartphones también hace que los cambios en su hardware y su software sean muy disruptivos, especialmente en lo relativo a la conectividad, las interfaces y el hardware, lo que puede obligar a actualizar un sistema IT/OT con mucha frecuencia (tanto el software como el hardware) para adaptarlo al entorno tecnológico de cada momento.

Por ejemplo, si la conectividad con el vehículo se hubiera realizado mediante el puerto IR del smartphone, opción de conexión que estaba presente en muchos smartphones hace unos años, en este momento, en el que estas interfaces IR han desaparecido de casi todos los smartphones del mercado, sería imposible conectar el vehículo con el smartphone.

Si no podemos adaptar la conectividad de nuestro vehículo a la de los nuevos smartphones, la única solución sería usar un teléfono obsoleto y sin actualizaciones de seguridad, para realizar dicha conexión, lo que no es nada recomendable en el mundo actual. Recordemos que la seguridad lógica “Security” en un sistema IT/OT también puede afectar a la seguridad operacional y funcional “Safety” del sistema.

Si deseamos sacar al mercado un nuevo vehículo conectado, podríamos considerar la forma en la que le puede afectar a la conectividad de los smartphones la generalización de conexiones 5G, de las tarjetas eSIM (tarjetas SIM virtuales) y del protocolo IPV6.

En ese nuevo escenario tecnológico, que facilitaría enormemente los despliegues IoT y en el que quedarían patentes las mejores prestaciones (mayor velocidad y menor latencia) de los sistemas 5G en relación con las conexiones WIFI (incluso las más modernas), se podría producir la desaparición de las conexiones WIFI en los smartphones y con ello, la imposibilidad de usar smartphone para conectar el vehículo mediante WIFI a los servicios digitales asociados al mismo.

Del mismo modo, se podría considerar el impacto a corto y medio plazo en la conectividad de nuestro vehículo, o en la seguridad de sus conexiones inalámbricas, de la adopción masiva del nuevo protocolo de seguridad WIFI WPA 3, o del estándar WIFI 6 (ya en el mercado) y el nuevo estándar WIFI 7 (ya en desarrollo), por parte de los fabricantes de smartphones.

Evidentemente, añadir al vehículo una tarjeta eSIM, un hardware compatible 4G y 5G y soporte para los protocolos IPV 6 y WPA 3, lo que no debe tener un coste muy elevado,, nos ahorraría muchos problemas a medio y largo plazo. Esto no elimina la posibilidad de que también se siga proporcionando la conectividad a través de una conexión WIFI 6 y WPA 3. Esto es resiliencia, es decir, el poder usar varias opciones de conexión por si en algún momento hay alguna no disponible. Por ejemplo, hay fabricantes de vehículos que proporcionan un módem USB 4G, que en caso necesario y con un coste reducido, se puede sustituir por uno 5G en el futuro.

Para el usuario de un vehículo, al igual que le pasaba antes de que se digitalizasen, lo más importante es poder seguir utilizando el vehículo durante todo su ciclo de vida, con las mismas prestaciones y con la misma seguridad, que cuando lo compró. Algo que todos los usuarios lo tenían asegurado gracias a la garantía de disponibilidad de repuestos y del soporte técnico del fabricante, ahora con el vehículo conectado, ya no está tan claro ya que añadimos la necesidad de mantener la ciberseguridad e interoperabilidad del vehículo.

Esta situación genera muchas incertidumbres a los compradores potenciales y preocupaciones, a los que ya han comprado un vehículo conectado. De hecho, no se encuentran muchas referencias a la gestión del ciclo de vida de los vehículos conectados en la publicidad proporcionada por los fabricantes y considerando que la compra de un vehículo es la segunda inversión más grande tras la compra de una vivienda, está claro que es algo que debería cambiar.

Basta con ver la diferencia de servicios digitales disponibles en vehículos de la misma marca y modelo, con solamente un año de diferencia en el mercado, para darnos cuenta de posibles problemas a la hora de mantener una adecuada ciberseguridad e interoperabilidad del vehículo. En muchos casos ,y a pesar que estos cambios serían simples actualizaciones de software y que estaban estaban previstos en el “roadmap” del producto, la mayoría de los fabricantes no proporcionan la posibilidad de actualizar los vehículos más antiguos, ni siquiera mediante de un pago por parte de los usuarios. Si no nos podemos adaptar a los cambios que se producen en un año y en funcionalidades ya previstas por el fabricante, pocas esperanzas tendremos de que el vehículo se pueda adaptar a otros cambios que se produzcan a lo largo de su ciclo de vida, que además, pueden disruptivos, es decir, radicales y no previstos.

c) Problemas de seguridad lógica (“security”) a lo largo del ciclo de vida del producto, que en los casos más graves, pueden afectar a la seguridad operativa y funcional del producto, es decir, a su “safety”.

Debemos considerar que muchos dispositivos OT se rigen por normas, en ocasiones muy rígidas, que regulan su seguridad operativa y funcional (“safety”). Por ejemplo, los sistemas aeroespaciales, los sistemas médicos, o los sistemas de automoción tienen normas OT muy rígidas. Para los fabricantes de estos equipos, antes de la digitalización de sus productos y de la convergencia IT/OT, como fabricantes de sistemas OT puros, sus mayores preocupaciones eran que sus productos no presentasen un riesgo para sus usuarios, que hubiera repuestos y que se pudiera dar soporte técnico a los clientes, durante todo el ciclo de vida del producto.

En este escenario OT la seguridad operativa y funcional (“safety”), gracias a la modularidad tradicional de los sistemas OT, estaba garantizada. Si había un problema de “safety” asociado a alguno de sus componentes, se podría sustituir a un coste relativamente bajo y sin tener que retirar el producto del mercado. Por ejemplo, si se producía un fallo en un airbag de un vehículo, cabía la posibilidad de hacer una campaña de sustitución del mismo.

Sin embargo, con la convergencia IT/OT esto ya no es suficiente y vemos que fallos de seguridad lógica o de interoperabilidad (“security”) en el equipamiento IT asociado al equipamiento OT, pueden provocar problemas de seguridad operativa y funcional (“safety”).

Pensemos en los vehículos retirados del mercado por Volkswagen tras el problema de las emisiones. Realmente ha sido un problema IT/OT y no se ha podido solucionar, por la elevada integración e interdependencia entre la parte IT y OT de estos vehículos.

Otro ejemplo reciente de estos problemas en la convergencia IT/OT lo tenemos en el Boeing 737 MAX. El foco del problema ha sido sistema informático (IT) instalado para facilitar el trabajo de la tripulación tras una nueva configuración del avión que provocaba cambios en su aerodinámica y por lo tanto, en sus leyes de vuelo (OT). Lo que hacía este sistema IT era hacer que el avión se comportase, a la vista de los pilotos, como el modelo 737 anterior, no necesitando formación específica para poder volar el 737 MAX. El fabricante consideró que como era un sistema automático y que no necesitaba intervención de los pilotos, no tenían la necesidad de tener conocimiento de su existencia. Sin embargo, en caso de fallo de dicho sistema, las leyes de vuelo de la aeronave cambiaban drásticamente y como los pilotos no sabían la forma en la que debían actuar, el avión se convirtió en ingobernable y se produjeron dos accidentes con pérdidas de vidas. En el caso del Boeing 737 MAX, está tan enlazado el comportamiento de la aeronave (leyes de vuelo), con el sistema IT que lo controla (ordenadores de abordo), que este problema está siendo muy complicado de solucionar.

Además, regulación “safety” aeroespacial, que como hemos dicho, es muy estricta, suele dificultar, o incluso impedir, la aplicación de criterios de “security” en sistemas IT/OT aeroespaciales. Por ello, sería conveniente buscar una solución normativa que tenga en cuenta la necesidad de unas adecuadas medidas de “safety” y de “security” de forma concurrente.

En el ámbito aeroespacial están apareciendo normas de ciberseguridad, como los documentos ED-201, ED-202A, ED-203, y ED-205 elaborados por EUROCAE y que están siendo aceptados por AESA (Agencia de Seguridad Aérea Europea). En el mundo de la automoción está prevista para el año 2022 (quizás es demasiado tiempo para la fuerte digitalización que está sufriendo esta industria actualmente), una norma de UNECE sobre ciberseguridad.

Pero en ambos casos son normas de seguridad lógica (“security”) que se han de aplicar en paralelo a las de seguridad operacional y funcional (“safety”), pero con convergencia IT/OT ya no son dos mundos distintos y se crea una nueva realidad tecnológica..

La convergencia IT/OT genera problemas que están sobre la mesa desde hace unos años, pero hay pocos expertos en la materia y también hay poca documentación que nos pueda ayudar. Por ello es relativamente normal que haya empresas que no sean conscientes de estos problemas, aunque estén inmersas en procesos de digitalización de sus productos con una fuerte convergencia IT/OT, o ya tengan productos IT/OT en el mercado. Posiblemente, una buena consultoría y una buena concienciación de su personal de ingeniería en los problemas de la convergencia IT/OT, les podría ahorrar mucho tiempo, esfuerzos y dinero, al tiempo que mejoraría su imagen de marca y sus beneficios netos.

En relación a los problemas que están teniendo muchas empresas, algunas importantes, con la convergencia IT/OT hay un indicador curioso. Durante año 2019 las cinco cosas que más han preocupado a las compañías de seguros en relación a la responsabilidad civil, los daños en la imagen de marca, en la responsabilidad corporativa y las pérdidas económicas de las empresas, han sido las siguientes:

a) Tecnologías.

b) Ciberriesgo.

c) Gestión del cambio.

d) Regulación.

e) Rentabilidad de las inversiones.

Si confrontamos los datos anteriores con lo que supone un proceso de convergencia IT/OT, podemos ver que parte de la preocupación de las compañías de seguros proviene de problemas cuyo origen es la convergencia IT/OT.

¿Cómo nos podemos enfrentar a los problemas de convergencia IT/OT durante todo el ciclo de vida del producto? Esta pregunta que parece sencilla, realmente es de las más complicadas de contestar en el entorno tecnológico en el que estamos inmersos en este momento, principalmente por cuatro motivos:

a) No siempre hay un concepto claro y compartido entre todo el personal de la empresa, de lo que debe ser el ciclo de vida de un sistema IT/OT y sobre la forma en la que deben gestionar los problemas de “safety” y “security” durante el mismo. Para ello, es conveniente establecer unas buenas estrategias de gestión del cambio tecnológico y de la obsolescencia (interoperabilidad y seguridad) de los sistemas IT/OT. También hay que definir claramente, el periodo de tiempo en el que se desea que el producto no tenga problemas operacionales, funcionales o de ciberseguridad y decidir las tecnologías a utilizar en cada momento, con la intención de maximizar la presencia del producto en el mercado.

b) La convergencia IT/OT es un problema multidisciplinar (ciberseguridad, interoperabilidad, gestión del cambio, gestión del ciclo de vida del producto, inteligencia tecnológica y competitiva, ingeniería, idoneidad del producto, aspectos sociológicos, normativa, etc) y muy complejo, que solamente se puede solucionar con un enfoque sistémico que abarque todos los aspectos y elementos que afectan al sistema IT/OT durante todo su ciclo de vida.

c) No hay muchos expertos en la gestión de ciclo de vida, y menos, ahora que dicho ciclo de vida también implica la ciberseguridad (profesionales de los que hay mucha escasez) y la interoperabilidad de los sistemas IT/OT.

d) Hay una clara transferencia de atributos entre sistemas IT y OT, lo que implica que expertos en sistemas IT necesiten algo de formación en sistemas OT y viceversa. Por lo tanto, como poco, es necesario que haya alguien en la empresa con los conocimientos necesarios para poder coordinar ambos mundos antes separados y que además, pueda analizar adecuadamente todos los riesgos asociados a la convergencia IT/OT a lo largo del ciclo de vida del producto.

Esta transferencia de atributos es algo que ya se contempla en el mundo aeroespacial. Por ejemplo, la estrategia de Seguridad Aeroespacial española, recientemente aprobada, establece lo siguiente:

a) Hay que gestionar la obsolescencia de los sistemas embarcados durante todo el ciclo de vida (atributos de interoperabilidad y ciberseguridad típicos de sistemas IT).

Esto implica aplicar a los sistemas OT embarcados un ciclo de actualizaciones de seguridad (software y firmware) y una gestión de versiones del software (sistemas operativos, middleware y software de operación) a lo largo del ciclo de vida. Dicho de otro modo, es necesario aplicar a los sistemas OT embarcados un ciclo de actualizaciones similar a los de los sistemas IT, principalmente por motivos de obsolescencia o de ciberseguridad (“securty”).

b) Que los sistemas IT usados en el entorno aeroespacial tienen que ser redundantes, resilientes y resistentes (atributos típicos de sistemas OT).

Estos tres atributos han sido una constante desde los principios de la aviación.

La resiliencia es poder acceder a una determinada función de vuelo crítica mediante varios sistemas distintos. Los aviones usan equipos de navegación distintos al mismo tiempo y siempre se usa uno como principal y otro como secundario, para comprobar que el sistema principal está funcionando correctamente. La resiliencia nos permite seguir volando una aeronave con seguridad en un entorno degradado. Esta resiliencia, que antes afectaba solamente a la parte OT, ahora afecta a todos los componentes IT y OT de las aeronaves.

La redundancia, es algo que se usa en sistemas aeroespaciales, pero que también es común en los sistemas IT de alta disponibilidad. Consiste en tener en dos o más elementos de cada clase. De esta forma, una aeronave tiene duplicados los sistemas de navegación críticos, las radios, o los instrumentos de vuelo básicos. En caso de que falle uno, hay otro igual disponible. Evidentemente, sin redundancia, es complicado tener un adecuado nivel de resiliencia.

Finalmente, el atributo de resistencia implica que todos los sistemas de una aeronave deben estar diseñados para resistir ese entorno adverso en el sentido físico. Los sistemas aeroespaciales deben resistir cambios bruscos en amplios rangos de temperatura, cambios de presión, vibraciones, cargas de varias veces la fuerza de la gravedad, y no afectar negativamente al otros elementos del entorno, por ejemplo, mediante la compatibilidad radioeléctrica con el resto de los equipos de la aeronave, etc.

La Estrategia de Seguridad Aeroespacial dice claramente que ya no hay una prioridad de la seguridad operativa y funcional “safety” frente a la seguridad cibernética “security”. En su lugar establece todo lo contrario, es decir que hay una clara necesidad de obtener primero una adecuada seguridad cibernética (IT), para lograr la seguridad aeroespacial (OT).

Lo anterior relaciona claramente la seguridad lógica con la aeronavegabilidad de las aeronaves. Dicho de otra forma, es necesaria una adecuada seguridad lógica de todos los elementos del avión, que es un sistema IT/OT muy complejo y que incluye los sistemas de apoyo en tierra, como requisito previo e indispensable para que una aeronave pueda volar con seguridad.

Veamos más detenidamente lo que significa esta transferencia de atributos entre sistemas IT y OT. Por ejemplo, si se desea introducir un ordenador embebido en la cabina de una aeronave como un equipo de entrada y salida de datos, o para actualizaciones de software, aunque que es equipamiento IT, también deberá tener una certificación aeronáutica que garantice que es resistente a las condiciones ambientales adversas del medio aeroespacial, como la resistencia a cambios de presión, temperatura, radiación, vibraciones, etc.

De la misma forma, antes de que aparecieran los coches conectados, una ECU (Unidad de Control Electrónica) solamente se reprogramaba si había un fallo que afectase a la seguridad operativa o funcional del vehículo, es decir, a su “safety”. Pero ahora que forman parte de sistemas IT/OT y que en muchos casos se han convertido en una DCU (Unidad de Control Digital), también es necesario actualizarlas por motivos de “Security”, es decir, por fallos lógicos. En el caso de los aviones modernos, como el A400M, nos podemos encontrar, dependiendo de la configuración, hasta 100 DCU embarcadas.

También será necesario actualizar una ECU/DCU por motivos de interoperabilidad, es decir, para que puedan seguir funcionando en un determinado entorno tecnológico a lo largo de su ciclo de vida. Por ejemplo, actualizando el protocolo de seguridad WIFI del inseguro WPA 2 actual al más seguro y moderno WPA 3.

La necesidad de actualizaciones por interoperabilidad son necesarias ya que a diferencia de los sistemas OT que estaban aislados del entorno, los sistemas IT/OT ya no están aislados. Ahora también tienen que convivir con una realidad tecnológica compleja y cambiante, con la que tienen que interactuar de forma activa durante todo su ciclo de vida.

Cuando hablamos gestión de ciclo de vida y gestión de la obsolescencia en sistemas con convergencia IT/OT, hemos de tener en cuenta como mínimo lo siguiente:

a) La obsolescencia puede producirse a consecuencia del hardware, el software (incluido el firmware), los protocolos, los interfaces, los algoritmos, las normas o los estándares.

b) La obsolescencia suele tener un efecto en cadena sobre varias tecnologías del sistema. Es decir, es frecuente que por intentar mantener la interoperabilidad de un sistema IT/OT, puede que se tengan que cambiar interfaces, software, sistema operativo y hardware, lo que tiene un coste muy elevado, si no se planifica adecuadamente esta posibilidad y se minimiza el impacto.

c) A la vista de los graves problemas que nos puede representar la gestión de la obsolescencia en un sistema IT/OT, es más conveniente establecer estrategias que retrasen su aparición (usando hardware, sistemas operativos, herramientas de desarrollo y middleware con un ciclo de vida mayor), o que faciliten su gestión. Si no se establecen unas estrategias adecuadas para la gestión de la obsolescencia, puede que las únicas opciones sean la salida del producto del mercado, o la pérdida de funcionalidades básicas del mismo.

Entre estas estrategias destacan, la resiliencia de comunicaciones (usar dos métodos para lograr la misma conectividad), la modularización de las tecnologías problemáticas, o de futuro dudoso, el incremento de la capacidad de proceso (velocidad y memoria) para poder adaptarse a procesos más exigentes en el futuro (protocolos o algoritmos), adición de buses de expansión abiertos, uso de software con Soporte a Largo Plazo (LTS), o con garantía interoperabilidad descendente, sistemas abiertos, estándares abiertos, etc.

Si consideramos que un sistema operativo no es más que una capa que permite a los programas abstraerse del hardware subyacente. En un sistema IT/OT, que lo que se pretende es que funcione con la misma fiabilidad y seguridad durante todo su ciclo de vida, no tiene sentido usar sistemas operativos de ciclo corto, con frecuentes cambios que nos obliguen a realizar actualizaciones de versión en periodos muy cortos y en muchos casos, a la modificación de nuestro software y a la adaptación de las aplicaciones.

Lo que realmente se necesita en un sistema IT/OT, en el que el hardware no va a cambiar mucho y lo controla el fabricante, es un sistema operativo con un soporte y actualizaciones de seguridad equivalentes al ciclo de vida del sistema y de no ser posible, asumir los cambios de versión en el momento que más interese.

Dicho de una forma más simple, si se controla el hardware de tu producto, no tiene sentido complicarse la vida con el software.

En el caso de las aeronaves, en el punto medio de su vida operativa reciben lo que se denomina la MLU “Mid-Life Upgrade”, que puede ser el momento adecuado para hacer un “rolling” de versión del software. De esta forma, si se considera que el ciclo de vida de un sistema IT/OT va a ser de 30 años, se puede usar un sistema operativo con un ciclo de vida de 15 años, sabiendo que va ser necesario un cambio de versión a la mitad de su ciclo de vida para mantener la seguridad y la interoperabilidad del sistema. La ventaja principal, es que ese es un escenario no disruptivo, que se puede programar y preparar adecuadamente.

Casos típicos en los que la gestión de la obsolescencia puede implicar cambios en el hardware los tenemos cuando la obsolescencia afecta a interfaces (por ejemplo con desaparición de puertos PCMCIA o PC-CARD en los ordenadores), o a sistemas radio (cambio de frecuencias de las radios WIFI por cambios en el estándar).

Para que las actualizaciones en el hardware no sean un problema irresoluble, es conveniente tener especial cuidado cuando el sistema IT/OT utilice o dependa de tecnologías de rápida evolución (por ejemplo, comunicaciones inalámbricas, sistemas operativos de dispositivos móviles, conectividad móvil, etc), o de futuro dudoso, como por ejemplo, los algoritmos de cifrado tradicionales, por la irrupción de la computación cuántica en los próximos años.

Curiosamente, aunque un diseño modular puede ser una buena estrategia para luchar contra la obsolescencia, lo que se está viendo muchos en sistemas IT/OT y en especial, en sistemas IoT, es una elevada integración, que además es multinivel, es decir, que se produce a nivel de sistemas, placas y circuitos integrados en paralelo.

Por ejemplo, se pueden encontrar sistemas que controlan todas las funciones del vehículo, con un diseño monoplaca, con chips “todo en uno”, que integran sensores, procesos (incluidos algoritmos de seguridad y de fusión de la información generada por sensores), memoria, comunicaciones (incluida la parte de radio Bluetooth, 4G y WIFI) e interfaces (USB, CAM, etc).

Evidentemente el riesgo asociado a una elevada integración de sistema IT/OT en la gestión su ciclo de vida, depende precisamente de su extensión en el tiempo, pero esiembre debe ser un riesgo calculado y no irresoluble.

d) En la gestión del ciclo de vida, se debe tener en cuenta que suele haber una ventana de transición que nos permite, durante un tiempo limitado, pasar de una tecnología a otra, sin tener que desechar el sistema IT/OT, o realizar cambios mayores en el mismo. Por lo que se debe estar preparado para aprovecharla cuando ocurra y para ello, es necesario tener una buena información de lo que proporciona el mercado en cada momento.

Por ejemplo, cuando se generalizó la emisión digital de radio y televisión, se podían adquirir receptores digitales para poder ver las emisiones digitales en televisiones analógicas, posibilidad que estuvo disponible durante un tiempo limitado en el mercado.

En otros ámbitos de los sistemas IT/OT también se pueden producir ventanas de transición tecnológica, que se pueden aprovechar para mantener un producto en el mercado, o para trasladar a los clientes finales una posible adaptación de sus sistemas IT/OT a una nueva situación tecnológica. La intención es que no llegue, o que se retrase en el tiempo, una situación en la que la única opción sea la salida del producto del mercado.

e) Para poder gestionar la obsolescencia de forma adecuada es necesario disponer de un buen sistema de prospectiva tecnológica y conocer el “roadmap” de los productos de los proveedores. De esta forma nos podremos adaptar a los cambios que se van produciendo en la tecnología. Asimismo, debe haber alguien en la empresa que se preocupe por el control del estado del arte de toda la tecnología relacionada directa o indirectamente con los productos de la empresa..

Otra cosa que nos puede ayudar en la gestión de la obsolescencia, es la reducción de la incertidumbre tecnológica con el tiempo, lo que se puede hacer estableciendo estándares (por ejemplo, para las comunicaciones, conectores, buses e interfaces), específicos para el sector de actividad y que tengan ciclo de vida muy largo.

f) Es frecuente que las empresas no fabriquen un sistema IT/OT en su totalidad, es decir, que se dediquen a la integración de productos y servicios IT y OT de distintos fabricantes. Esto es algo muy visible en el mercado aeroespacial, médico y en el de la automoción. En estos casos, es importante que todos los proveedores y “partners” compartan el mismo concepto de convergencia IT/OT, de transferencia de atributos entre los sistemas IT y OT y de gestión del ciclo de vida del producto.

En este sentido, cuando los proveedores sean PYMES, se debe tener en cuenta que este tipo de empresas sufren más avatares empresariales que las grandes empresas, lo que puede acabar repercutiendo en nuestro producto. Asimismo, las menores capacidades de ciberseguridad de algunas PYMES, que incluso puede que no tengan un CISO (Chief Information Security Officer), puede acabar afectando a la ciberseguridad de nuestro producto.

g) Hay que intentar evitar que un “secreto” comercial o patente, provoque la aparición de “shadow IT”, o tecnología oculta en nuestros productos IT/OT. Si es el caso, lo más probable es que no se pueda realizar una adecuada gestión de la obsolescencia y de la ciberseguridad durante el ciclo de vida del producto y que se produzcan fallos de “safety” o “security” imprevistos y muy complicados de solucionar.

h) Hay que intentar minimizar la dependencia tecnológica y los mercados cautivos. Este objetivo se puede lograr usando estándares abiertos siempre que sea posible, y si no es posible, se puede recurrir a capas de abstracción que permitan cambiar de tecnologías en caso necesario, sin que ello suponga un cambio mayor en el producto, o su retirada del mercado.

i) Hay que elegir cuidadosamente las herramientas de desarrollo tanto en la parte OT como IT que se van a utilizar en la creación del sistema IT/OT. Si el ciclo de vida de esa herramienta de desarrollo, o del middleware asociado a la misma, es inferior al del sistema IT/OT, es posible que se acaben teniendo problemas de “safety” y/o “security” en el futuro, principalmente, por falta de soporte de dichas herramientas y de las librerías asociadas.

j) Si se trata de empresa muy arraigada en la creación de sistemas OT, es frecuente que en el proceso de convergencia IT/OT se contraten productos o servicios de empresas IT. Si es el caso, se ha de tener en cuenta la necesaria transferencia de atributos entre IT y OT y viceversa. Además, si no hay otros expertos en la empresa, se debería tener, como mínimo, a alguien en la plantilla que tenga la capacidad de coordinar todos los aspectos de la convergencia IT/OT.

Es posible que se desee contratar a una empresa puntera y de renombre en el ámbito IT, pero siempre que sea posible, sería conveniente contratar a empresas IT con una experiencia de varios años en la provisión de servicios IT a sistemas IT/OT del mismo sector de actividad.

Cuando se contrate a una empresa IT también hay que tener en cuenta el SLA (Service Level Assurance), el SQA (Software Quality Assurance) y todos los aspectos relacionados con la programación segura y defensiva. Evidentemente, ante un fallo funcional o de seguridad en la parte IT, no se debería tener que esperar dos meses para que la empresa de IT lo solucione. Aunque parezca impensable, este problema ha ocurrido recientemente con un gran fabricante de automoción y con otra empresa muy importante de equipamiento GPS.

En el caso de la empresa de automoción, el problema se produjo tras una actualización de sus sistemas en la nube, que provocaba que determinados servicios en línea, que además son de pago, dejasen de funcionar, situación que se ha prolongado durante más de dos meses.

En el caso de la empresa de equipamiento GPS, tras una actualización de la aplicación móvil, se empezaron a producir problemas en la conexión Bluetooth que impedían utilizar la función de seguimiento en tiempo real del deportista (telemetría de posición, ritmo cardíaco, velocidad, etc). Aunque dicha función puede ser crítica para la seguridad de deportistas en actividades “outdoor” cuando no van acompañados, y que dicha funcionalidad podía ser un factor determinante para la decisión de compra, ya que permite la localización del usuario en caso de accidente, dicha funcionalidad tardó en restaurarse más de dos meses. En ambos casos, el daño de imagen es para la empresa de equipamiento OT.

Hay que tener en cuenta también, que un 21.4 % de los ataques dirigidos a vehículos conectados se han producido a través de las infraestructuras IT (servidores de control telemático, servicios de movilidad, portales WEB, etc). Esto ha de ser tenido en cuenta cuando se diseñe la seguridad de un sistema IT/OT. Especialmente, cuando exista una empresa IT que proporcione estos servicios externamente o cuando se esté valorando acometer estos servicios internamente y no se dispone de personal con todo “know how” necesario. En todo caso, hay que considerar que los ciberataques pueden ir dirigidos al “frontend” o al “backend” del sistema IT/OT, o al nexo de unión entre el mundo IT y OT, que suele ser la nube, por lo que también se necesitarán expertos en ciberseguridad en la nube.

Otra curiosidad de los procesos de convergencia IT/OT, es que en ocasiones se aplican normas distintas a la parte OT que a la IT. Por ejemplo, nos podemos encontrar que tras hacer una transferencia de un vehículo conectado de segunda mano, a la empresa que proporciona los servicios IT a dicho vehículo, no le sirva para autorizar el acceso a los servicios digitales del nuevo usuario que el vehículo ya esté a nombre del nuevo titular en la Jefatura de Tráfico y disponga de los papeles que lo demuestra. Esto se puede producir por tener que cumplir con la normativa de protección de datos personales. Por ejemplo, la geolocalización del vehículo, o el seguimiento en tiempo real para el caso de robo. Aquí también tiene mucha importancia el borrado seguro de los datos del propietario anterior del vehículo tras una transferencia de titular.

k) También es indispensable disponer de un adecuado control de configuración de todos los sistemas IT/OT fabricados por la empresa y de sus distintas versiones si no se ha realizado una actualización (“retrofit”) de las versiones anteriores. Dicho control debe cubrir todos los aspectos relacionados con el hardware, software, firmware, protocolos, interfaces, herramientas de desarrollo, middelware, librerías (sabiendo si el enlace de las mismas es dinámico o estático), algoritmos, estándares, etc. Además hay que conocer en cada momento el estado de seguridad lógica de todo lo anterior.

De esta forma, se evitará lo que le ha ocurrido recientemente a Tesla, que tras una actualización perfectiva del software embarcado, algunos vehículos han quedado inoperativos por disponer de un hardware de una versión anterior y ligeramente diferente al que se usó para el desarrollo y prueba de la actualización.

l) Es necesario disponer, y utilizar de forma sistemática y reiterativa, de herramientas de análisis de riesgos, que usando una metodología fiable y un proceso de actualización continua de los riesgos, permitan evaluar en su conjunto, todos los riesgos de un sistema IT/OT y no de forma separada para la parte IT y OT.

Actualmente hay buenas herramientas que permiten evaluar de forma independiente los riesgos de sistemas OT e IT. Por ejemplo, para los sistemas IT tenemos la herramienta Pilar que usa la metodología Magerit. Pero no existe ninguna herramienta para analizar los riesgos combinados en un sistema complejo IT/OT.

Si se hubiera dispuesto de alguna herramienta de este tipo para el entorno aeroespacial, es posible que se hubieran detectado los problemas de seguridad operacional y funcional del Boeing 737 MAX asociadas al sistema IT/OT antes de salir al mercado.

Estos sistemas de análisis de riesgos combinados IT/OT también deberían permitir la evaluación los posibles riesgos a la privacidad o a la seguridad de los usuarios, derivados de determinadas funcionalidades del sistema IT/OT considerando la parte IT y OT de forma combinada.

Los sistemas IT/OT pueden ser tan complejos, que es prácticamente imposible realizar un adecuado análisis de riesgos sin contar con una herramienta informáticaque contemple todos los factores intervinientes en las áreas de “safety” y de “scurity”. Dado lo heterogéneo que es el mundo IT/OT, también es muy posible que sean necesarias herramientas de análisis de riesgos específicas para cada sector de actividad en el que se produzca convergencia IT/OT, por ejemplo, automoción, aeroespacial, medicina, etc.

m) También sería conveniente que el regulador arbitrase mecanismos para que fuera más rápido y sencillo aplicar medidas de “security” a sistemas con normativas de “safety” muy restrictivas y arraigadas en el tiempo, como es el caso del sector aeroespacial.

De hecho, como ya se ha dicho, sería conveniente que hubiera una única normativa IT/OT que contemplase en paralelo y de forma equilibrada, aspectos de “safety” y “security”, en lugar de añadir una nueva normativa de “security”, que muchas veces se tiene que aplicar en paralelo con la normativa de OT y en ocasiones, competir con ella en desigualdad de condiciones.

Hay que señalar, que los riesgos IT suelen ser abstractos y no son percibidos tan fácilmente como con los riesgos operativos o funcionales por los expertos de mundo OT. Por ejemplo, si nos encontramos una bolsa en el trabajo en un lugar extraño, es posible que nos genere un estado de alerta y llamemos al servicio de seguridad, sin embargo, si nos encontramos un pendrive no se suele percibir como una amenaza directa y muchos usuarios lo pincharán en su equipo para ver lo que contiene y averiguar el posible dueño del mismo.

Afortunadamente y aunque no hay normativa al respecto, ya se pueden ver algunas iniciativas interesantes, fruto de las lecciones aprendidas de los procesos de convergencia IT/OT, y que intentan que el sistema IT/OT tenga una uso adecuado y seguro durante el todo el ciclo de vida.

Puede que un futuro cercano, la incipiente normativa contra la obsolescencia programada, que se mueve por principios de protección del usuario y la ecología, también añada algo en el futuro sobre la obsolescencia sobrevenida. No debemos olvidar que lo que se pretende con la normativa contra la obsolescencia programada, es que el usuario pueda hacer un acceso seguro a las capacidades funcionales y operativas de los sistemas IT/OT durante un ciclo de vida razonable y eso puede ponerse en riesgo tanto tanto por la obsolescencia programada, como por la sobrevenida si no se gestiona adecuadamente.

En otros casos, tenemos a fabricantes que en el entorno IT/OT que aunque tienen claro que deben garantizar la funcionalidad, la ciberseguridad y la operación durante el ciclo de vida, no consideran la necesidad de solucionar los problemas de interoperabilidad en ese mismo periodo. Esto se debe a que estos fabricantes tienen sistemas IT/OT con un ciclo de vida corto (menos de 5 años). Pero esto no debería ser una norma general y aún así, en determinados escenarios en los que se tiene previsto un cambio tecnológico inminente, un ciclo corto también puede tener riesgos que deben ser gestionados y mitigados adecuadamente.

Un ejemplo de este tipo de fabricante es Samsung con el “Smart Evolution Kit” y que contempla un ciclo de vida de 4 años para sus SmartTV de gama alta. Debemos que tener en cuenta que un coche tiene un ciclo de vida de más de 10 años y una aeronave de más de 30, lo que cambia de forma drástica el concepto de ciclo de vida.

La decisión de Samsung de añadir el ”Smart Evolution Kit” a sus televisores demuestra una estrategia de gestión del hardware y del software, para que sus productos sigan estando en la “gama alta” durante todo su ciclo de vida y a un precio relativamente contenido para el usuario. Según expone Samsung, la intención de este “Kit” es el mantenimiento correctivo y perfectivo del producto y está orientado a la satisfacción de usuario (mediante la mejora de la velocidad de proceso, aumento de la memoria disponible, o mejora de las aplicaciones disponibles). Para lograrlo, el “kit” permite anular (“override”) el hardware preexistente en el televisor.

Pero aunque Samsung no haya considerado la necesidad de un mantenimiento adaptativo ante un posible problema de interoperabilidad en cuatro años, si se produjera un cambio disruptivo en el mercado que implicase un cambio de hardware, los televisores de Samsung tendrían más probabilidades de no tener que ser retirados del mercado y de seguir funcionando a un coste razonable para el usuario. Posibilidad que no tendrán los fabricantes que no dispongan de un bus de expansión como el usado por el “Smart Evolution Kit” de Samsung.

Como vemos, adoptando estrategias para garantizar la la funcionalidad, ciberseguridad o la operación de un sistema IT/OT durante su ciclo de vida, también se puede corregir un problema de interoperabilidad en caso necesario. Asimismo, la adopción de este tipo de estrategias, que puede que no tengan un coste muy elevado dentro del coste global del sistema IT/OT, pueden representar una diferenciación de nuestro sistema IT/OT en relación a los de la competencia, simplemente por el hecho de que el nuestro podrá seguir en el mercado y el de la competencia no.

Ya que hemos hablado de mantenimiento, otra de las cosas que tenemos que tener en cuenta en la convergencia de sistemas IT/OT es que deberíamos aplicar en a los sistemas IT/OT, los todos los tipos de mantenimiento que se aplicaban tradicionalmente a los sistemas IT y OT por separado. Estos tipos de mantenimiento son los siguientes:

a) Mantenimiento perfectivo. Nos permite añadir nuevas funcionalidades al sistema. Por ejemplo, la capacidad de acceder a los servicios de Android Auto a través de una conexión Bluetooth además de a través del cable de datos USB, que venía siendo tradicional en la mayoría de los vehículos.

b) Mantenimiento preventivo. Nos permite evitar o retrasar un fallo. Por ejemplo, si se descubre que las baterías de vehículos eléctricos duran mucho más si se cargan solamente hasta el 80%, podemos añadir una opción para que el usuario las cargue hasta ese nivel de forma opcional y aumentar su vida operativa por un uso más racional de las mismas.

c) Mantenimiento correctivo. Es el mantenimiento que nos permite eliminar fallos del sistema, los que pueden ser debidos a errores en la fabricación, o en la programación, o por el uso simple uso del dispositivo (fallo prematuro o desgaste). Por ejemplo, si nos falla un disco duro SSD en un sistema IT/OT se deberá cambiar por otro. En el mantenimiento correctivo es importante calcular el equilibrio entre el nivel de despiece disponible y el coste para el fabricante de mantener ese nivel de despiece. Si el coste del conjunto superior es contenido, no tiene sentido tener un despiece muy detallado de dicho elemento. Lo que no es de recibo, que ante un fallo de un componente de 3 euros y de fácil sustitución, sea necesario sustituir un elemento de 1.200 euros.

d) Mantenimiento predictivo. Es el mantenimiento que nos permite adelantarnos a los cambios tecnológicos del entorno. Por ejemplo, ante la irrupción de la tecnología 5G y la desaparición de la tecnología GSM o 4G, nos permitiría habilitar las medidas necesarias para poder cambar el módulo de acceso a la red telefónica y aumentar el ciclo de vida del producto.

e) Mantenimiento adaptativo. Es el mantenimiento que nos permite seguir usando un determinado sistema ante un cambio disruptivo no previsto por el mantenimiento predictivo o evolutivo. Por ejemplo, ante la caída de un algoritmo criptográfico que hace que el sistema sea vulnerable a ataques triviales, el poder cambar los algoritmos a otros más seguros, aunque requieran más capacidad de proceso y memoria.

f) Mantenimiento evolutivo. Es el mantenimiento que nos permite seguir usando la tecnología con los cambios naturales de la tecnología. Por ejemplo, si la conexión WIFI se realiza mediante el protocolo de seguridad WPA 2, que se considera vulnerable, este tipo de mantenimiento nos proporcionaría una actualización a WPA 3, que es un protocolo mucho más seguro, y que ha sido diseñado para sustituir al WPA 2.

Es posible que ya se tengan en el mercado productos con convergencia IT/OT que no contemplen adecuadamente todo esto de lo que estamos hablando, por lo que a medio o largo plazo puede quedar cuestionada su permanencia en el mercado. Si es el caso, habrá que intentar solucionar el problema de la mejor forma posible. Pero no debemos olvidar, que para no agravar el problema con otros productos que estén en desarrollo, es necesario iniciar lo antes posible todos los procesos que sean necesarios en la empresa para evitar problemas de ciberseguridad, interoperabilidad, funcionalidad o uso, durante todo el ciclo de vida del sistema.

Debemos comprender que aunque el escenario es complejo, si se hace bien desde el principio, se obtendrán muchos beneficios y en algunos casos, esos beneficios pueden representar incluso la supervivencia de la empresa en el mercado:

a) Mayor tiempo de presencia del producto en el mercado.

b) Posibilidad de un modelo de negocio basado en mantenimiento avanzado IT (evolutivo, adaptativo y predictivo), en paralelo a los tipos de mantenimiento más tradicionales del mundo OT (preventivo, correctivo y perfectivo).

c) Mayor satisfacción de usuario y prestigio de marca, minimizando los daños patrimoniales y en la reputación de la empresa, por la retirada temporal o permanente de productos del mercado debidos a problemas operacionales, funcionales, de interoperabilidad o de ciberseguridad.

d) Mayor facilidad en la gestión de la obsolescencia, minimizando el coste para la empresa y el usuario final, de las acciones que sean necesarias para llevar a cabo de dicha gestión.

Dicho con menos palabras, hay que evitar que la convergencia IT/OT sea un riesgo y hay que lograr se convierta en una oportunidad para la mejora del producto, satisfacción del usuario, mejora de la imagen de la empresa y para el incremento de los beneficios.