IBSN, blog, id

Directo desde el Vaticano...

hit counter




"No sabemos qué sistema operativo usa Dios, pero nosotros usamos Linux"
Hermana Judith Zoebelein
Webmaster del Vaticano
Seguir a @facemar en Twitter

Fernando Acero Martin

Crea tu insignia

Licencia Creative Commons

Blog Fernando Acero por Fernando Acero Martín se encuentra bajo una Licencia Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. El presente blog no tiene finalidad informativa, de creación de opinión pública, o de entretenimiento, tiene como finalidad principal, la enseñanza y la divulgación de experiencias, proyectos, pensamientos y conocimientos del autor.

Se permite la copia textual, la traducción y la distribución de los artículos del presente blog en cualquier medio, a condición de que este aviso sea conservado, no se modifiquen.

Se permite la cita.

El autor no cobrará por el ejercicio de los dos derechos anteriores, siempre que no se haga uso comercial de los mismos.

No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre.

Basada en una obra en fernando-acero.livejournal.com.
IBSN, blog, id

REALIDADES Y RETOS DE LA COMPUTACIÓN CUÁNTICA

En esta reflexión intentaré poner en claro la situación actual y explicar los importantes retos a los que hay que enfrentarse para lograr un computador cuántico de propósito general, que sea capaz de ejecutar cualquier algoritmo cuántico y como predicen algunos expertos, represente un verdadero riesgo para la criptografía tal como la conocemos en la actualidad, detallando la ponencia que tuve ocasión de impartir en la jornada sobre Tecnologías Cuánticas organizada por APTIE recientemente, en las que debatimos sobre el futuro de estas tecnologías, así como sobre la necesidad de elaborar una estrategia y una política científicas, que garanticen la seguridad de las comunicaciones.

Tras una serie de artículos aparecidos recientemente en prensa relacionados con los avances en computación cuántica logrados por IBM y Google y sus supuestas implicaciones catastróficas para la criptografía tradicional y para las criptomonedas, que bien podríamos calificar de FUD (Fear, Uncertainty and Doubt), he considerado interesante repasar algunas cuestiones que traté en dicha conferencia, que creo que pueden ayudar a comprender las implicaciones los recientes avances en computación cuántica.

Asimismo, durante la jornada se pudo comprobar que hay un gran debate en torno a la criptografía que ha de sustituir a la criptografía tradicional, que teóricamente sería vulnerable a la computación cuántica. Hay expertos que mantienen que la única solución ante el computador cuántico, es utilizar sistemas cuánticos para el intercambio seguro de claves. Sin embargo, para poder intercambiar claves de forma segura mediante métodos cuánticos, es necesario un canal cuántico punto a punto (por ejemplo una fibra óptica), algo que no es muy útil si queremos hacer operaciones de forma segura con nuestro banco usando nuestro teléfono móvil. Este importante hecho, fue oportunamente señalado por Luis Sanz, Responsable de Innovación en Seguridad del BBVA. Afortunadamente, existen algoritmos, muy parecidos a los que se utilizan actualmente, que si bien necesitan más memoria y capacidad de computación, tienen un nivel de complejidad lo suficientemente elevado como para ser resistentes a la computación cuántica.

CONDICIONES QUE HA DE REUNIR UN COMPUTADOR CUÁNTICO

Lo primero que tenemos que tener en cuenta en relación a las noticias sobre computación cuántica, es que una cosa es el plano teórico y otra bien distinta, una implementación funcional de un dispositivo cuántico plenamente operativo y de propósito general, es decir que pueda ejecutar cualquier algoritmo cuántico.

Para que un ordenador cuántico sea funcional, se necesita que cumpla las condiciones publicadas por David DiVincenzo, que es un físico teórico que trabajó para IBM y que lleva años investigando temas de computación cuántica,. Dichas condiciones son las siguientes:

a) El sistema ha de poder inicializarse a unos valores definidos y controlados (probabilidad arbitraria para que un qubit (bit cuántico) sea un |0> o |1>).

b) Ha de permitir la manipulación de qubits de forma controlada, usando un conjunto universal de puertas lógicas cuánticas, que permitan realizar cualquier operación lógica.

Frente a un ordenador tradicional, cuya puerta universal (la puerta que permite ejecutar cualquier operación lógica) es la NAND, en el caso del ordenador cuántico, la puerta universal es la CNOT (NOT controlada).

Asimismo, en los ordenadores tradicionales, se requieren puertas de tres bits para lograr la universalidad de las mismas, sin embargo, DiVincenzo demostró en el año 1994 que cualquier puerta cuántica se puede descomponer en combinaciones de puertas de dos qubits y de un qubit.

c) El sistema cuántico ha de mantener la coherencia cuántica (estado en el que un qubit está en estado de superposición cuántica, es decir, que tiene un |0> y un |1> al mismo tiempo) durante un tiempo superior al necesario para hacer los cálculos.

En la actualidad, los tiempos de decoherencia están en el orden de milisegundos a segundos, (pero usando temperaturas cercanas al cero absoluto y del orden de 0,015 ºK) y este hecho, junto a la enorme tasa de errores de las tecnologías utilizadas actualmente para fabricar qubits (superconductores y efecto túnel), son los factores que más limitan la potencia de un ordenador cuántico en este momento.

Si no se mejoran de forma sensible las técnicas de fabricación de los qubits, se comprueba de forma experimental, que al aumentar el número de qubits del procesador cuántico, también aumenta la tasa de errores y al mismo tiempo, disminuyen los tiempos de decoherencia. Es decir, el número de qubits del procesador cuántico, no es una medida muy adecuada para expresar la potencia de un procesador cuántico.

De hecho, la tasa de errores está vinculada con los tiempos de decoherencia y es proporcional a la razón entre tiempo de operación y el tiempo de decoherencia. Es decir, cualquier operación tiene ser completada en un tiempo mucho menor que el tiempo de decoherencia teórico, si no se desea que la tasa de errores se dispare hasta un límite que implique que el resultado sea inutilizable.

Si la tasa de errores se mantiene suficientemente baja, cabe la posibilidad de hacer una corrección de errores efectiva. Teóricamente, solamente se necesitan 5 qubits adicionales por qubit (según demostró Laflamme) para corregir los errores cuánticos de forma eficiente. Pero el problema es que con las tecnologías actuales de creación de qubits (como las puertas Josephson, que se basan en el efecto túnel entre dos superconductores a muy bajas temperaturas), generan qbits muy ruidosos y además es complicado que el comportamiento cuántico de dos qubits sea estadísticamente igual, lo que complica enormemente el escenario.

Lo dicho anteriormente provoca que se dispare el número de qubits necesarios para realizar cálculos cuánticos complejos fiables y repetibles. Es decir, existe una enorme brecha entre lo que dice la teoría y lo que se logra en implementaciones reales de procesadores cuánticos. Por ejemplo, mientras que en teoría se podría factorizar una clave de 2048 bits con aproximadamente 4096 qubits, si no fueran ruidosos, la realidad es bien distinta. Los investigadores Craig Gidney y Martin Ekerå, publicaron el pasado 23 de mayo de 2019, un documento titulado “How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits”, que demostraba que eran necesarios 20 millones de qubits ruidosos para factorizar una clave RSA de 2018 bits. Aunque parezcan muchos qubis, que lo son para la tecnología actual, el documento reduce en varios órdenes de magnitud la cantidad de qubits necesarios para factorizar con éxito una clave RSA 2048 bits, que anteriormente se estimaba en 2.000 millones de qubits ruidosos.

Es evidente que este documento se queda en el plano teórico y si se consideran las limitaciones tecnológicas actuales en el número de qubits de los procesadores cuánticos de propósito general (128 qubits para el procesador de propósito general de Rigetti ) y en los tiempos de decoherencia repetibles (90 ms para el procesador de IBM), podemos hacernos una idea clara de lo lejos que estamos de poder factorizar una clave RSA de 2048 bits mediante un ordenador cuántico y el algoritmo de Shor. Tampoco debemos olvidar que en este momento se recomienda usar claves RSA de 4096 bits o más.

Otro factor que afecta a la tasa de errores, además de la que hemos comentado relacionada con la dificultad de fabricación de qubits con un comportamiento cuántico similar, es la necesidad y dificultad de asilar el procesador cuántico de las interacciones cuánticas que provienen del resto del universo. A un ordenador cuántico le afecta casi todo, por ejemplo, los campos electromagnéticos, las vibraciones, la temperatura, la radiación y si intervienen partículas con masa en sus puertas cuánticas, hasta la gravedad, que es algo que no sabemos aislar en este momento. La primera consecuencia negativa de todas estas interacciones, es un aumento en la tasa de errores y la necesidad de qubits adicionales para corregirlos.

Como hemos dicho anteriormente, se están logrando tiempos de decoherencia cuántica de forma práctica y repetible, del orden de 90 milisegundos (procesador de IBM), lo que implica que teóricamente se podrían realizar 3.600.000 operaciones de puertas de 1 qubit (25ns por operación), o 900.000 operaciones de puertas de 2 qubits (100ns por operación). Pero como se ha dicho anteriormente, en la realidad estos tiempos de decoherencia son mucho menores, ya que cuanto más se acerca el tiempo de cálculo al tiempo de decoherencia máximo, también aumenta la tasa de errores. Si la progresión en los tiempos de decoherencia fuera lineal, cosa que podemos poner en duda con casi toda certeza, se lograrían tiempos de decoherencia de unos 10 segundos en el año 2027, algo que todavía está muy lejos de permitir una factorización de una clave RSA de 2048 bits, que un ordenador cuántico de 20 millones de qubits ruidosos, necesitaría unas 8 horas para hacerlo.

d)Se ha de poder leer el resultado tras las operaciones, qubit por qubit.

e)La tecnología cuántica ha de ser escalable en número de qubits y en la reducción de tasa de errores. Esto que parece sencillo, tiene grandes dificultades con la tecnología actual. La tasa de errores de los qubits actuales, obligan a usar una gran cantidad de qubits adicionales, lo que a su vez dificulta el entrelazamiento cuántico y reduce los tiempos de decoherencia.

Además, cuando hablamos de un ordenador cuántico de propósito general, es necesario que haga uso del entrelazamiento cuántico (fenómeno cuántico en el que en el cual los estados cuánticos de dos o más qubits se deben describir mediante un estado único que involucra a todos los qubits del sistema, aunque estén separados en el espacio) y de la interferencia cuántica (fruto de la dualidad onda corpúsculo y que es observable con el experimento de la doble rendija de Young), lo que añade otras complicaciones adicionales a la construcción de un ordenador cuántico de propósito general. En este momento, IBM ha logrado entrelazamientos de 16 qubits en sus procesadores cuánticos más modernos, por lo que todavía estamos lejos de poder enlazar la gran cantidad de qubits que necesitamos para poder factorizar una clave RSA de 2048 bits.

Dicho lo anterior, ya estamos en disposición analizar si un determinado avance en las tecnologías cuánticas puede ser útil o no para la fabricación de un ordenador cuántico de propósito general y de evaluar si una noticia sobre los riesgos de la computación cuántica para la criptografía tradicional tiene fundamento o no.

De hecho, muchas noticias recientes sobre avances en las tecnologías cuánticas aparecidas recientemente en prensa, como récords en el número de qubits entrelazados y en el tiempo de decoherencia, por la forma en la que se han logrado, no tienen aplicación a la computación cuántica, principalmente, por ser tecnologías que no permiten la inicialización, la manipulación o la lectura individual de cada qubit, algo que es fundamental para la computación cuántica, según las leyes de David DiVincenzo.

DIFERENCIAS DE UN ORDENADOR CUÁNTICO CON UNO TRADICIONAL

La principales diferencias entre un ordenador cuántico y uno tradicional son:

a) Un qubit está en un estado de superposición cuántica durante el tiempo de decoherencia, es decir, contiene al mismo tiempo un |1> y un |0>. Esto proporciona una enorme potencia a un ordenador cuántico, puesto que si en un ordenador tradicional de 8 bits tenemos 2^8 posibilidades, es decir (256 valores posibles), en uno cuántico de 8 qubits tenemos 2^256 valores simultáneos gracias a la superposición cuántica, lo que es un número enorme. Dicho de otro modo, un computador cuántico tiene todas las soluciones posibles de un problema antes de empezar a resolverlo.

Para ponerlo en un lenguaje más cercano, podemos decir que un ordenador cuántico de 20 qubits efectivos equivale a un ordenador de 12 teraflops/s (10 x 10^12 operaciones en coma flotante por segundo). Si consideremos el ordenador convencional más potente de la actualidad, denominado Summit y que alcanza 200 petaflops/s (200 x 10^15 operaciones en coma flotante por segundo), se necesitaría un ordenador cuántico de como mínimo 50 qubits para igualar su potencia. Aunque como veremos más adelante, la potencia de un ordenador cuántico no depende solamente del número de qubits de su procesador.

b) No se puede copiar un estado cuántico desconocido de un qubit en otro qubit (lo que es bueno para la criptografía, pero es malo para la computación cuántica, ya que añade una limitación importante a la hora de elaborar algoritmos cuánticos). Sin embargo, sí se pueden copiar bits tradicionales en qubits mediante puertas cuánticas mediante la puerta de Hadamard, que es el nexo de unión entre la computación tradicional y la computación cuántica.

Además, la puerta de Hadamard es una de las puertas cuánticas de mayor utilidad ya que permite que n qubits se pongan en superposición de 2^n estados. Además es la representación en qubits de la transformada cuántica de Fourier, operación que es básica para la factorización de claves RSA mediante el algoritmo cuántico de Shor.

c) En un ordenador tradicional podemos ejecutar cualquier algoritmo mediante puertas NAND usando las Leyes de Morgan, sin embargo, en el ordenador cuántico la puerta lógica universal es la CNOT (NOT Controlada) y necesitamos recurrir a la puerta de Hadamard para poder convertir qubits en bits y viceversa, cuando es necesario disponer de un mecanismo de “copia”, ya que no es posible copiar el estado de un qubit en otro qubit.

Además, todas las puertas cuánticas son reversibles, es decir, se pueden conocer las condiciones de entrada de una puerta cuántica mediante la lectura de la salida. Este hecho tiene dos consecuencias adicionales. La primera es que una puerta cuántica nunca destruye información mediante borrado o sobreescritura durante las operaciones. La segunda, es que las puertas cuánticas no deberían disipar energía durante las operaciones.

d) Una puerta cuántica puede ejecutar varias operaciones al mismo tiempo, es lo que se denomina paralelismo cuántico, lo que también es una consecuencia de la superposición cuántica. Este hecho nos permite calcular y conocer el resultado de varias operaciones cuánticas al mismo tiempo.

En este punto hay que aclarar que aunque la mecánica cuántica es de naturaleza claramente probabilística (principio de incertidumbre de Heisenberg), eso no impide que un ordenador cuántico pueda proporcionar resultados deterministas, ya que hay algoritmos cuánticos con probabilidad del 100%. Eso es en la teoría, ya que como hemos visto, en este momento existen problemas (tiempos de decoherencia, escalabilidad y tasa de errores principalmente), que dificultan obtener con facilidad esos resultados deterministas tan deseados. Por ejemplo, si se desea factorizar una clave RSA con el algoritmo de Shor, que es un algoritmo determinista.

HABLANDO DE LA POTENCIA DE UN ORDENADOR CUÁNTICO

Para considerar la potencia de un procesador tradicional se suele hablar del tamaño en bits de la palabra que usa (8, 16, 32 o 64 bits), del número de puertas lógicas contenidas en el procesador, del número de núcleos (procesos en paralelo), o de forma más general, del número de transistores que tiene el procesador. Sin embargo, esto no nos sirve para los ordenadores cuánticos.

La potencia real de un ordenador cuántico (también denominado volumen cuántico) no depende solamente del número de qubits, o del número de puertas cuánticas disponibles, depende de:


  • El número de qubits reales tras la corrección de errores (teóricamente se tiene que dividir por 5 el número de qubits brutos del procesador cuántico).

  • El número de puertas cuánticas (de un qubit y de dos qubits) que se pueden generar y usar con esos qubits del procesador.

  • La conectividad de cada qubit con los adyacentes, siendo lo normal en este momento, que un qubit se conecte con 15 adyacentes.

  • El número de operaciones que se pueden realizar en paralelo.

Según lo anterior, se podría pensar que un procesador cuántico de 50 qubits es más potente que uno de 40, sin embargo IBM ha demostrado que:


  • Duplicar el número de qubits, sin mejorar la tasa de errores al mismo tiempo, no aumenta la potencia de un ordenador cuántico.

  • Reducir por 10 la tasa de error, sin aumentar el número de qubits, puede incrementar la potencia de un ordenador cuántico en un factor de 24.

Lo anterior indica que es más conveniente avanzar en la reducción en la tasa de errores que aumentar el número de qubits del procesador, si se desea tener mayor potencia a corto plazo.

Si embargo, en las noticias recientes relacionadas con avances en computación cuántica se suele hablar solamente del incremento en el número de qubits, algo que como vemos, puede que no sea tan relevante a la hora de considerar un aumento en la potencial de un ordenador cuántico. Como sabemos,  el incremento en el número de qubits más que aumentar la potencia del procesador, lo que puede hacer es reducir los tiempos de decoherencia y al mismo tiempo, aumentar la tasa de errores.

Con lo que se ha dicho hasta ahora, se puede ver que hay una íntima relación entre varios factores y en algunos casos, hay valores que pueden empeorar cuando mejoran otros. Por ello, se puede ver que es necesario avanzar en paralelo en varios campos. Básicamente es necesario aumentar el número de qubits, hay que reducir la tasa de errores, hay que crear qubits con menos variaciones estadísticas en su comportamiento, hay que mejorar el aislamiento y hay que aumentar los tiempos de decoherencia, la temperatura de funcionamiento de las puertas cuánticas y el número de qubits entrelazados. Como se puede ver, nos encontramos ante un problema muy complejo y multidisciplinar, que necesita obtener resultados en paralelo si se desea avanzar en la capacidad de computación cuántica.

PROFUNDIZANDO EN LA TASA DE ERRORES

Ya hemos visto que hay una estrecha relación entre el número de qubits, los tiempos de decoherencia y la tasa de errores. También hemos visto las enormes limitaciones que imponen estos factores, a la hora de crear un computador cuántico funcional de propósito general. La realidad es que es muy complicado crear qubits que tengan un comportamiento estadísticamente idéntico, de hecho, es muy normal que haya procesadores con qubits inutilizables, o que queden inutilizables tras cierto tiempo de uso.

Por ejemplo, el procesador cuántico de Google de 52 qubits, con el que se ha dicho que se la logrado la supremacía cuántica con un problema de números aleatorios (una operación muy complicada de realizar con un ordenador tradicional), tiene un qubit que no se puede utilizar. En relación con la supremacía cuántica del ordenador de Google, también hay que señalar que se trataba de un procesador especialmente diseñado para resolver un algoritmo muy favorable para un ordenador cuántico. Es decir, no estamos ante la resolución de un problema común, ni ante un ordenador de propósito general

Al igual que el procesador de IBM, el ordenador D-WAVE One que fue instalado en Lockheed Martin en 2011, también tiene qubits que no son utilizables. De los 128 qubits disponibles inicialmente, actualmente solamente se pueden utilizar 108 qubits de forma efectiva, por diferencias estadísticas en el comportamiento individual de los mismos.

Hay que señalar, que este ordenador de D-WAVE, aunque usa los principios de la mecánica cuántica para sus cálculos, no es un ordenador cuántico de propósito general, ya que solamente es capaz de calcular valores óptimos de una función mediante el método Montecarlo, y no usa entrelazamiento cuántico, por lo que muchos autores no lo consideran un ordenador cuántico. Estos autores alegan que un ordenador tradicional también se podría considerar un ordenador cuántico, por los procesos cuánticos que se producen en los transistores y diodos que forman sus puertas lógicas.

Los dos casos anteriores son casos extremos en los que hay qubits que no se pueden utilizar, sin embargo, las variaciones en el comportamiento estadístico del resto de los qubits, provocan que se tenga que aumentar de forma considerable el número de qubits para corregir de forma efectiva los errores. Pero ello también reduce al mismo tiempo los tiempos de decoherencia del procesador y el número de qubits disponible para los cálculos.

La tasa de errores es el factor que más limita a la hora de factorizar enteros grandes con el algoritmo de Shor, mientras que tiempos de decoherencia, es lo que más limita a la hora de hacer cálculos repetitivos de larga duración, como por ejemplo, el minado de criptomonedas.

Asimismo, algoritmos como el del Grover, cuyo resultado no es determinista y que sirve para encontrar una secuencia no ordenada de datos en una base de datos, necesita que toda la base de datos esté en una memoria cuántica (es decir, en una memoria con superposición cuántica), lo que es un serio problema cuando hablamos de Terabytes de información a ordenar y consideramos nuestra limitada capacidad actual para superponer grandes cantidades de qubits y para mantener la coherencia cuántica, necesaria para realizar los cálculos.

Pasando a un entorno práctico real, consideremos el procesador del ordenador D-Wave Two (“Vesuvius”) que dispone de procesadores cuánticos de 512 qubits, que aunque como hemos dicho, no es un ordenador cuántico de propósito general, nos puede ayudar a ver la forma en la que nos afectan la tasa de errores y la complejidad de las operaciones, en el número de qubits necesarios y en la fiabilidad de los resultados.

En estos procesadores de D-WAVE, para cálculos que requieren 86 qubits en puertas cuánticas, es necesario usar un total de 344 qubits, siendo el resto para la corrección de errores.  Asimismo, aunque hay algoritmos cuánticos deterministas, la capacidad para lograr datos deterministas con un ordenador cuántico real, como hemos dicho, ello depende de la complejidad del problema y el número operaciones a realizar.

De esta forma, con los procesadores de D-WAVE, para resolver problemas “sencillos” que necesiten 40 qubits o menos, se logra el valor correcto el 100% de las veces, sin embargo, con problemas más “complicados” que necesiten 86 qubits o más, solamente se logra el valor correcto el 20% de las veces.

Como se puede ver, aunque se use un gran número de qubits para la corrección de errores, la fiabilidad cae en picado cuando las operaciones son complejas y requieren un mayor número de puertas y un mayor tiempo de proceso.

Hay otros dos problemas que aumentan la tasa de errores en los procesadores cuánticos de forma indirecta y que también debemos tener en cuenta. El primero es la escasa tensión usada en las puertas cuánticas basadas en superconductores (efecto túnel), que es del orden de los 10-100 microvoltios. El segundo, es la poca diferencia de energía entre estados cuánticos opuestos, lo que dificulta distinguir con éxito si el resultado de una operación es un |0> o un | 1> en un determinado qubit.

Otro límite a la hora de corregir los errores, que es consecuencia directa de la mecánica cuántica. Como sabemos, no se puede leer el estado de un qubit sin destruirlo, por lo que hay que predecir y corregir errores que todavía no se han producido y como se usan qubits adiconales para la corrección de errores, también se pueden producir errores en los qubits usados para la corrección de errores, lo que complica muchísimo las cosas.

Como vemos, la tasa de errores cuántica es un concepto complejo, puesto que depende del número de qubits que se pueden usar para corregir errores (teniendo en cuenta la coherencia y entrelazamiento), del tiempo de cálculo, del número de operaciones y lo ruidosa que sea la tecnología utilizada.

No hay un acuerdo sobre el número máximo de errores por el número de operaciones, hay autores que dicen que el límite es de un error cada 1.000.000 operaciones, mientras que otros dicen que el límite está en 3 errores por cada 100 operaciones. Sin embargo, lo más probable es que cada autor tenga un contexto tecnológico diferente y considere problemas y algoritmias distintas para sus cálculos.

LOS PROBLEMAS DE LA ENERGÍA Y LA REFRIGERACIÓN

Salvo que consideremos un ordenador cuántico con un procesador que use tecnologías cuánticas basada en fotones, en este momento, la mayor parte de los procesadores cuánticos son de estado sólido y usan puertas Josephson de efecto túnel basadas en superconductores. Esta tecnología, aunque es relativamente sencilla de fabricar, puesto que es muy parecida a la de los procesadores tradicionales, pero usando superconductores, tiene el problema de que necesita funcionar a muy bajas temperaturas y eso requiere de mucha energía, lo que limita enormemente que cualquier persona pueda tener un ordenador cuántico en su casa o en su empresa.

Las puertas superconductoras Josephson necesitan trabajar cerca del cero absoluto, más concretamente a 0,015 ºK. Trabajar a estas temperaturas requiere una elevada cantidad de energía para disipar el calor. Por ejemplo, si se desea disipar 1 vatio de energía de procesador trabajando a 0,015 K, se necesitarán 19,5 Kw de energía. Asimismo, si se desea disipar 1 vatio de energía a la temperatura de un condensado Bose-Einstein, a una temperatura de 0,00000017 ºK, se necesitará 1,6 Gw de energía, lo que es una fortuna en la factura de la compañía eléctrica.

Otro problema es que para poder trabajar a estas temperaturas, hay que usar Helio. Preferentemente helio3, que es un isótopo muy escaso en un momento en el que también hay poco helio. El helio3 tiene algunas ventajas frente al helio4 a la hora de refrigerar el computador cuántico. Por ejemplo, el helio3 tiene un mejor comportamiento termodinámico que el helio4 a la hora de trabajar a muy bajas temperaturas.

Esto implica que si no se desarrollan tecnologías cuánticas basadas en procesadores fotónicos, se tendrá que avanzar también en el desarrollo de superconductores que funcionen a mayores temperaturas y en la mejora del aislamiento térmico de los sistemas cuánticos.

Un procesador cuántico basado en fotónica, tendría las siguientes ventajas frente a uno basado en superconductores:


  1. No necesita trabajar a bajas temperaturas, por lo que también necesita poca energía para funcionar.

  2. No se ve afectado por los campos electromagnéticos, por el campo gravitatorio, por las vibraciones o la temperatura.

  3. Las puertas fotónicas son menos ruidosas y tienen una menor dispersión estadística en su comportamiento que las basadas en superconductores.

  4. No tienen los problemas de ruido asociados a las bajas tensiones y a las reducidas diferencias de energía entre estados cuánticos.

En resumen, hay muchos campos en los que es necesario avanzar y mucho trabajo por hacer para lograr un procesador cuántico de propósito general. Las cosas no son tan sencillas como aparecen en prensa y aunque en este momento no podemos considerar que la criptografía convencional esté en riesgo, no podemos decir que con la enorme inversión en la investigación de la computación cuántica que se está realizando por algunos países, la situación no cambie en breve.

Para lograrlo, es necesario elaborar una estrategia y una política científicas, que garanticen que no nos quedamos atrás en un sector estratégico para las comunicaciones y el desarrollo científico, como es la computación cuántica.

PUBLICADO EL 29 DE NOVIEMBRE DE 2019 POR APTIE:

https://www.aptie.es/datos-y-retos-de-la-computacion-cuantica/

IBSN, blog, id

Phishing y Spear Phishing , la ingeniería social hecha negocio

La mejor forma de defenderse contra el Phishing y el Spear Phishing, es formando al personal de la empresa para que no caigan en estos engaños, usar la firma digital en todos los comunicados y correos y establecer protocolos de seguridad, como la verificación por un segundo canal, que impidan pagos indebidos.

https://valenciaplaza.com/detectan-en-murcia-fraudes-por-email-como-el-de-la-emt-valencia

IBSN, blog, id

ACTUALIZACIONES OTA (ON THE AIR) Y SU IMPLEMENTACIÓN

Tras la publicación de mi artículo sobre la convergencia IT/OT, algunas personas me han preguntado por lo que opinaba yo sobre las actualizaciones OTA para paliar algunos de los problemas de los que hablaba en mi artículo. Sin duda es una pregunta interesante y es un tema apasionante que tiene posturas muy enfrentadas en el mundo IT/OT en este momento, pero también creo que es proceso inevitable y que en un futuro cercano, todas las actualizaciones serán mediante OTA.

No debemos olvidar que la logística de las actualizaciones por métodos alternativos al OTA son complejas y costosas en tiempo y dinero, especialmente cuando el factor de escala (número de dispositivos presentes en el mercado) es grande, o tienen una distribución geográfica dispersa o remota.

Es evidente que la creciente e imparable digitalización de todo lo que nos rodea, implica una necesidad inevitable de actualizaciones de software y firmware frecuentes, por motivos de seguridad o funcionalidad y el poder hacerlo mediante conexiones inalámbricas, tiene grandes ventajas, pero también tiene grandes riesgos, que se deben tener en cuenta y afrontar adecuadamente.

Las actualizaciones OTA también minimizan la posibilidad de que haya usuarios que descarguen actualizaciones para sus dispositivos o sistemas desde sitios indebidos, que no se compruebe la integridad del software antes de instalarlo, o que no actualicen sistemas por la complejidad del proceso, o por miedo a que haya problemas durante la actualización.

Asimismo, las actualizaciones OTA, tienen como principal ventaja para los fabricantes y los usuarios, el evitar que se tenga que acudir al servicio técnico para la instalación de actualizaciones, lo que implica molestias a los usuarios y tiene un enorme coste en tiempo y dinero, especialmente, si el factor de escala es grande (presencia del producto en el mercado) y hay una gran distribución geográfica del mismo, facilitando actualizaciones más frecuentes y una mayor satisfacción de usuario.

Muchos conocemos las actualizaciones OTA de los smartphones. Si nuestro smartphone está bajo soporte del fabricante, es frecuente que recibamos cada cierto tiempo un aviso de que hay una actualización disponible. Dicha actualización OTA la podremos descargar usando nuestra conexión 4G/5G o WIFI, e instalarla en el momento que nos parezca más adecuado. A través de estas actualizaciones, se puede cambiar el sistema operativo a uno más moderno, añadir funcionalidades nuevas, corregir errores o fallos de seguridad, o actualizar las políticas de seguridad del dispositivo ante nuevas amenazas emergentes.

Si pensamos en sistemas con un gran factor de escala y con una distribución geográfica dispersa, por ejemplo, los vehículos conectados, nos podemos hacer idea de las ventajas de las actualizaciones OTA. Aunque también es cierto, que hay muchos fabricantes que todavía son recelosos de estas actualizaciones OTA y solamente permiten la actualizaciones de las funciones críticas que afecten al safety o a la security, de forma presencial en el taller y por personal formado y debidamente autorizado para ello.

No cabe duda de que con el 5G y la generalización del protocolo IPV6, las actualizaciones OTA se aplicarán a todo tipo de dispositivos y sistemas conectados, y si se hace correctamente, pueden mejorar de forma sensible la ciberseguridad y la funcionalidad de estos dispositivos y sistemas, con un mínimo impacto para los usuarios y los fabricantes de los mismos.

Pero para que estas actualizaciones OTA sean seguras, considero que sería necesario como mínimo siguiente para los caso más exigentes en materia de seguridad, por ejemplo, para actualizar mediante OTA las Electronic Control Unit (ECU) de vehículos conectados o de aeronaves:

a) Lo primero que se necesita para las actualizaciones OTA, es un robusto y fiable “Software Update Management System (SUMS)”, con todo lo necesario para que estas actualizaciones se realicen de forma eficiente y con todas las garantías necesarias.

El SUMS debe incluir un sistema de gestión Public Key Infrastructure (PKI), que permita cifrar y firmar los paquetes de actualización, cifrar las comunicaciones, gestionar los permisos de los distintos actores, garantizar la trazabilidad de las actualizaciones y autenticar los extremos de la comunicación.

La gestión de la PKI a lo largo del ciclo de vida implica, el contemplar la posibilidad de compromiso de claves (revocación), la caducidad de las mismas (renovación), y los cambios en el criptoperiodo, tanto de los algoritmos de seguridad utilizados, como de las longitudes de claves utilizadas. El sistema PKI debe garantizar adecuadamente y sin fisuras, la privacidad, autenticidad e integridad de todos los actores y elementos que intervienen durante todo el proceso de actualización OTA.

El SUMS debe disponer de todos los mecanismos de seguridad criptográfica que sean necesarios para garantizar la integridad de las actualizaciones, desde el desarrollo de las mismas, hasta la instalación en los sistemas mediante OTA (verificar la trazabilidad del software o firmware).

El SUMS también debe contemplar un inventario con todo el hardware y software de todas las versiones fabricadas de un determinado sistema y sus partes, para garantizar que las actualizaciones OTA son las adecuadas para cada combinación de hardware/software del sistema a actualizar y sus partes constitutivas.

b) Cada sistema a actualizar mediante OTA, debe tener una identificación criptográficamente segura, única, invariable y verificable.

c) Antes de la actualización OTA, el sistema a actualizar entregará al SUMS su configuración actual de software y hardware, fecha/hora y estado de energía (si el sistema está alimentado mediante baterías) para que el SUMS pueda determinar la viabilidad y la actualización a aplicar en cada caso, especialmente, si se tienen que realizar actualizaciones progresivas en un sistema que no ha sido actualizado en mucho tiempo.

Asimismo, el SUMS se debe comprobar la algoritmia de seguridad y de las claves del sistema a actualizar (revocación y validez) y si fuera necesario, se actualizarán de forma segura antes de proceder a la actualización OTA.

d) La comunicación entre el SUMS y el sistema a actualizar mediante OTA, debe estar autenticada en los dos extremos y debe estar cifrada (VPN), para evitar ataques MitM (Man in the Middle) y con ello, la manipulación o el acceso a información sensible cuando la actualización se realiza a través redes publicas inseguras (se deberían considerar todas inseguras por defecto).

e) El paquete de software o firmware debe contener todas las firmas necesarias para comprobar su autenticidad e integridad, desde su creación hasta su instalación y ejecución exitosa en el sistema de destino (no manipulación o corrupción durante toda la cadena de suministro).

f) El paquete de software o firmware debe estar cifrado para evitar el acceso al mismo por personal no autorizado.

g) El paquete de software o firmware solamente se podrá descifrar e instalar en sistemas debidamente autenticados y autorizados.

h) Se deben mantener logs accesibles y detallados de todo el proceso de actualización OTA.

i) La actualización no debe interferir con el normal funcionamiento del sistema a actualizar. Es decir, si consideramos un vehículo,una aeronave, o un sistema médico, cuyo funcionamiento anormal puede afectar gravemente a safety o security, el proceso de actualización no debe interferir con el normal funcionamiento del mismo.

Por ejemplo, en el caso de una aeronave conectada, la actualización se podría descargar en vuelo sin mayores problemas, pero solamente se debería instalar y activar con la aeronave parada en tierra para evitar problemas funcionales o de seguridad mientras que se instala y arranca correctamente la siguiente versión.

Alternativamente, se tendrían que buscar soluciones técnicas que garantizasen las funcionalidades críticas de un sistema en funcionamiento durante las actualizaciones OTA. Por ejemplo, mediante tecnologías livepatching, como usadas por Suse o Red Hat para la actualización de sus núcleos sin la necesidad de volver a arrancar el sistema al terminar.

j) El sistema debe proporcionar la posibilidad de volver a una versión anterior (incluidas las configuraciones y parámetros de funcionamiento anteriores), si se interrumpe o falla una actualización OTA en cualquiera de sus fases. Esto evitará, si se produce un problema durante la actualización OTA, que queden inoperativos una gran cantidad de sistemas al mismo tiempo y sin una solución local inmediata.

Asimismo, como seguridad adicional, se deben proporcionar mecanismos para que siempre se pueda realizar una actualización OTA, aunque una actualización anterior no haya funcionado adecuadamente y haya provocado un bloqueo del sistema.

k) Las actualizaciones no deben alterar configuraciones anteriores, especialmente las relacionadas con safety o security del sistema, o con requisitos de funcionamiento del sistema, que sean obligatorios por Ley.

Si la actualización modifica el comportamiento del sistema, o añade funcionalidades nuevas, el usuario debe ser informado de ello tras la actualización, especialmente si hay implicaciones para la safety o security del sistema.

En este sentido, considero que el usuario debería conocer como mínimo lo siguiente:

1) Ciclo de vida del sistema o de sus partes y plan de actualizaciones funcionales y de seguridad previsto para las mismas.

2) Estado de las comunicaciones (funcionalidad y seguridad) y del contrato de comunicaciones, si depende del fabricante del sistema.

3) Algoritmos y claves presentes en el sistema, con su identificación, tamaños y fechas de caducidad.

4) El propósito de la actualización e instrucciones de seguridad (safety y security) durante la actualización y cualquier instrucción necesaria para el usuario antes de proceder a la actualización.

5) Del progreso de la actualización OTA en cada una de las fases (actualización de algoritmia o claves de seguridad, establecimiento de comunicaciones, descarga, validación, actualización, validación y tests) y tiempo previsto para la finalización de cada fase.

6) La identificación de la actualización, con indicación del sistema a la que va dirigida, con la fecha y hora de creación y de aplicación en el sistema.

7) Los sistemas o funciones que se han visto afectadas y la forma en la que lo han sido, indicando si son actualizaciones de seguridad, con su criticidad, o si son funcionales.

8) Si la actualización afecta a algún parámetro de funcionamiento, o es obligatoria por un requisito legal.

9) Si la actualización se ha realizado de forma segura, indicando los problemas detectados.

10) Si la actualización se ha realizado de forma adecuada y con éxito, pasando las verificaciones y validaciones posteriores.

Tras una actualización OTA, se deben realizar operaciones de “self test” para garantizar que todo funciona adecuadamente. En caso de que el resultado sea negativo, se deberá informar al usuario de los problemas detectados y de la forma de resolverlos.

IBSN, blog, id

Los problemas de la convergencia OT/IT y cómo sobrevivir a ellos.


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.


IBSN, blog, id

Programación defensiva y la búsqueda de los IOA







Poco a poco, las organizaciones están implementando sistemas de calidad y de seguridad del código fuente, con un mayor o menor alcance. Algunos se conforman con utilizar sistemas de análisis estático de código fuente y otros van más lejos, llegando a realizar fuzzing de sus aplicaciones más críticas. Pruebas de caja blanca, gris y negra, complementan los test funcionales, para garantizar la seguridad del código. Dicho lo anterior, podemos decir, con toda seguridad, que el concepto de programación segura no es ajeno a muchas empresas fabricantes de software.

Simplificando mucho, podemos decir que un programa funciona adecuadamente, cuando recibe una entrada esperada y se comporta de forma predecible y podemos decir que es seguro, cuando recibe una entrada no esperada y también se comporta de forma predecible. Es lo que denominamos un adecuado manejo de excepciones, el santo grial de la programación segura.

Ahora bien ¿qué es la programación defensiva? pues es cuando un programa es seguro, es decir, gestiona adecuadamente todas y cada una de las excepciones posibles y además genera un log avisando de dicha contingencia. Dicho de otro modo, es una forma adecuada de explotar con fines de seguridad, nuestro notable esfuerzo en encontrar y gestionar adecuadamente cada una de las excepciones que pueden afectar negativamente a nuestro programa.

Ya he hablado de la problemática asociada al aumento del tráfico cifrado y de lo lo interesante que es explotar todas las capas del estándar OSI, siendo la información obtenida más útil para el análisis de seguridad, cuanto más cercana es la capa al usuario.

Por lo tanto, un forma de paliar de alguna forma la pérdida de visibilidad de la capa de presentación por el uso de SSL/TLS, es potenciando la información disponible en otras capas y la de aplicación, es una de las más interesantes, por ser la más cercana al usuario.

A pesar de lo evidente del concepto y lo sencillo y rentable que es su implementación, lo cierto es que no todas las aplicaciones generan logs con las excepciones que gestionan y eso es un problema que pone las cosas muy complicadas a los responsables de seguridad a la hora de correlar eventos.

Una de las cosas más interesantes de la programación defensiva, es que nos permite anticiparnos a un ataque efectivo. Pensemos por ejemplo, en el último fallo del iLO4 de HP, bastaba este mandato para tener acceso sin autenticación a la gestión del sistema en remoto:


curl -H "Connection: AAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

Bien, hasta encontrar el fallo, el atacante ha tenido que probar muchas veces, un escenario de prueba y error, lo que podría ser detectado como un Indicador de Ataque (IOA) en nuestro sistema, aunque estuviera parcheado adecuadamente o se estuviera gestionando esa excepción (por ejemplo, podemos guardar en nuestro log, que se ha recibido una cadena de 26 caracteres idénticos, cuando el programa espera una cadena que cumpla determinadas reglas de construcción de la cadena y que la cadena tiene que ser de menor tamaño).

Es decir, cuando tenemos un IOA, tenemos algo mucho mejor que un IOC, que es un Indicador de Compromiso, y que lo que nos dice realmente, es que alguien ha ya vulnerado nuestro sistema y que nos toca recuperarlo y remediar los daños.

Los IOA nos permiten una defensa proactiva y reactiva, ante los primeros intentos sin éxito de un atacante, por lo que debemos intentar obtener el mayor número posible de dichos IOA, para correlar adecuadamente y rápidamente, los ataques en curso, antes de que tengan éxito.

El concepto de programación defensiva, se podría mejorar fácilmente, por ejemplo, si además de crear un log con las excepciones que gestiona el programa, nos avisa en las aplicaciones WEB, de las inconsistencias entre los datos incluidos interfaz de usuario y la validación de los mismos, antes de guardarlos en la base de datos. Con ello, la programación defensiva también nos puede proporcionar IOAs, ante ataques contra la lógica de negocio, como por ejemplo, los ataques producidos por Burp Suite actuando como HTTP proxy, o en modo scanner e intruder.

Eso es algo parecido a correlar que alguien intenta atacar por fuerza bruta un servidor SSH, o que está haciendo un escaneo de puertos, pero aplicado a las aplicaciones, si lo detectamos al principio, sabemos que algo está pasando, es eso es lo bueno de un IOA.

Si además se lograse una taxonomía adecuada de IOAs asociados a determinados ataques tipo a la capa de aplicación, podríamos detectar los intentos de ataque con más rapidez y precisión.

El efecto sería como quemar el pajar para encontrar la aguja, lo contrario a intentar buscar una aguja en un pajarcmediante bigdata y data minning, en los correladores de eventos con bases de datos monstruosas, lo que requieren grandes recursos de máquina, aplicaciones complejas y un tiempo precioso, que no siempre se tiene ante un ataque en curso.

IBSN, blog, id

TRÁFICO CIFRADO Y EL DILEMA DE LA RUPTURA DEL TÚNEL SSL/TLS







En 2017 Google dijo que la mayor parte del tráfico de su navegador Crome ya era cifrado. Posteriormente, en un intento de aumentar estas cifras, a partir de julio del presente año, Crome también marcará como inseguras todas las páginas web que no usen https. Pero junto con el tráfico web, hay otras muchas conexiones que se están haciendo cifradas desde hace tiempo, como por ejemplo el correo electrónico. Con ello, estamos perdiendo la posibilidad de saber lo que pasa realmente en la capa de presentación del estándar OSI, que es la que soporta el SSL/TLS.

Aquí he de decir dos cosas. La primera, es que el poder acceder y explotar la información presente en todas las capas del estándar OSI, es fundamental para una defensa en profundidad de los sistemas. La segunda, es que cuanto más cerca del usuario esté la capa OSI, más información interesante podemos obtener para la seguridad, especialmente, de las capas de aplicación, de presentación, sesión y transporte.

No cabe duda de que el cifrado de todas las comunicaciones es una enorme mejora en la privacidad de los usuarios, pero también hemos de tener en cuenta, que tiene un enorme impacto en la seguridad de las organizaciones, puesto que cuando el tráfico es cifrado, los sistemas perimetrales no pueden saber si lo que entra y sale de la organización es bueno o malo, propiciando la entrada de código malicioso, o la salida de datos sensibles. Además, al perder una gran cantidad de información útil de la capa de presentación, la correlación de eventos de seguridad se hace mucho más complicada.

En esta situación, disponer de un buen "endpoint", con capacidades avanzadas como Protección Contra la Pérdida de Datos (DLP), Protección Contra la Intrusión (HIPS), filtrado de spam, antivirus con sandbox, o control de dispositivos, se convierte en una necesidad crítica para la seguridad de la organización. Es decir, que de una seguridad centrada en los perimetrales con control de la capa de aplicación, que era relativamente cómoda de gestionar, volvemos a un concepto de seguridad descentralizada basada en endpoints, que es mucho más complicada de gestionar.

Para evitar este problema, algunos fabricantes de equipos de protección de perímetro, como cortafuegos o proxies de gama media o alta, permiten la ruptura del túnel SSL/TLS. Para ello, proporcionan un hardware lo suficientemente potente, como para poder realizar, sin penalizar el tráfico, este trabajo intensivo de descifrado, análisis y posterior cifrado de las comunicaciones. Como es lógico, este incremento en la capacidad de proceso y en las funcionalidades de los equipos, se materializa en un precio sensiblemente superior al de los equipos que no permiten la ruptura del túnel. ¿Pero nos vale la pena? ¿Funciona bien esta funcionalidad?. Lo que está claro, es que hay guías de seguridad que recomiendan activar la ruptura de túnel SSL/TLS en nuestra organización, si se tiene disponible esta posibilidad.

El funcionamiento es sencillo, el dispositivo de protección de perímetro dispone de una Autoridad de Certificación (CA) integrada y a partir de ella, se generan unos certificados, que hay que instalar en todos los sitios en los que sea necesario, por ejemplo, en el almacén de certificados de los navegadores, de los clientes de correo, de máquina virtual JAVA y en el caso de Linux, en el almacén de certificados propio del sistema operativo, o de lo contrario, tendremos problemas a la hora de actualizar nuestros sistemas.

Dicho de otro modo, el sistema de ruptura de túnel SSL/TLS se comporta como un Man in the Middle (MitM), que rompe el túnel para poder analizar el tráfico entrante y saliente de nuestra organización en búsqueda de amenazas y luego lo vuelve a cifrar, para garantizar la confidencialidad de las comunicaciones.

A pesar de que todo parece sencillo, mi experiencia de campo no ha sido todo lo buena que esperaba con esta funcionalidad. Por ejemplo, a pesar de incluir el certificado en el almacén de mis sistemas Linux, he sufrido la ruptura del sistema de paquetes en varias ocasiones, por problemas de conexión a algunos repositorios. Básicamente, algunos repositorios no eran visibles para mis sistemas Linux, cuando estaba activada la ruptura del túnel SSL/TLS.

Pero el problema de fondo es mucho más grave, aún sin entrar en escabrosas consideraciones, que darían para varios artículos, relacionadas con la legislación de protección de datos y los lógicos temores por parte de los usuarios, de que su tráfico esté siendo monitorizado. Algo que permite hacer esta tecnología, tal como avisan algunos fabricantes en sus manuales.

Creo que el problema más grave es que la CA que genera el cortafuegos no es una CA de verdad, por lo que sus certificados no son "trusted" por defecto y no están en donde deben estar, es decir, con todos los certificados de las CA que sí cumplen con todos los requisitos para serlo. Por ello, estos certificados se han de instalar a mano en el área de usuario y editar su confianza también a mano, lo que crea problemas de seguridad bastante preocupantes, sobre todo, si nuestros usuarios no son muy avanzados.

Además, instalar el certificado en todos los sitios en los que debe estar, no es una tarea rápida ni sencilla. Si se nos olvida en algún sitio, habrá cosas que no funcionarán adecuadamente y cuando hablamos de actualizaciones fallidas, estamos hablando de fallos graves de seguridad y de posibles problemas de continuidad.

Veamos un problema típico tras activar la ruptura del túnel SSL/TLS. Tras instalar en el área de usuario el certificado de nuestro cortafuegos en un Android 8.0.0, tanto en la parte personal, como en la de trabajo (correspondiente a la Carpeta Segura), cada vez que nos conectemos a la WIFI del trabajo e intentemos bajar el correo corporativo desde la Carpeta Segura, nos aparecerá el siguiente mensaje, que para un usuario concienciado y debidamente formado en ciberseguridad, debe ser bastante inquietante:

"Certificado no seguro para: XXXX@XXX.es. El certificado no proviene de una entidad de confianza. Si continua con este certificado, es posible que la seguridad de sus correos electrónicos y de su cuenta se vea comprometida."

Seguido de las opciones Ver, Cancelar o Continuar.

Aquí está el problema, ante un mensaje que aparece todos los días y varias veces en el teléfono, muchos de los usuarios pulsarán directamente Continuar, sin comprobar que el certificado es el que tiene que ser, quedando claramente expuestos a un ataque de Man in the Middle (MitM), en el caso que acepten un certificado falso. Y si pulsan Ver, que es lo más seguro, la única información fiable para saber si es el certificado correcto o no, comprobar el SHA-256 del mismo, algo que es complicado de recordar y verificar cada vez que nos salta el mensaje.

Además, de vez en cuando, cuando activemos o desactivemos interfaces de comunicación y cambiemos al mismo tiempo de entorno, por ejemplo, al desactivar la WIFI y activar, los datos en el teléfono, nos aparecerá un aviso de que tenemos un certificado instalado a mano, y que eso puede afectar a la seguridad de nuestras comunicaciones.

La mejor solución, es que los fabricantes de dispositivos de seguridad perimetrales, con capacidad de ruptura del tunel SSL, se lo tomen en serio y creen CA's que cumplan con todos los requisitos necesarios, para que sus certificados puedan incluir por defecto en el área de sistema junto con los de otras CA "trusted".

Mientras que eso no ocurra, tendemos que formar y concienciar a los usuarios para que la ruptura del túnel SSL/TLS, no sea un problema más grave del que quiere evitar.

Pero también debemos considerar que también será necesario manejar excepciones. Habrá tráfico que no se podrá romper sin crear problemas, como es el caso de los servidores de actualización de algunos sistemas, o tráfico personal de los usuario a lugares "trusted", como banca, administración pública, correo personal, etc. Para ello, en lugar de listas nominales, sería mejor disponer de sistemas basados en categorías, por ejemplo: "banca online" en lugar de tener que enumerar todos los bancos y luego, si es necesario, eliminar los bancos que no se desee mediante listas negras nominales.

Pero si profundizamos más, podemos tener otros problemas de seguridad cuando activamos esta tecnología, por ejemplo:

a) "Forward proxy decryption" puede que no funcione cuando hay autenticación mutua.

c) En algunos casos, por problemas de soporte de TLS 1.2, se puede producir un downgrade a un inseguro TLS 1.1, con todo lo que ello supone para la seguridad de las comunicaciones. Recordemos que TLS 1.0 y TLS 1.1 estaban "deprecated" en enero de 2018 por sus problemas de seguridad.

d) Puede haber esquemas de cifrado no soportados, por ejemplo, AES128-GCM-SHA256 o AES256-GCM-SHA256, que forman parte de TLS 1.2.

e) Finalmente, es posible que no se puedan descifrar las sesiones en la se use un intercambio de claves Diffie-Hellman para "Forward Proxy Decryption".

En base a lo anterior, si somos unos atacantes, vemos que hay mecanismos para poner la cosas complicadas al sistema que está haciendo la ruptura del túnel SSL/TLS, ya sea para que no funcione, o para forzar un peligroso downgrade de protocolo.

Por lo tanto, creo que antes de proceder a la ruptura del túnel SSL/TLS, es conveniente realizar un análisis detallado de las ventajas e inconvenientes, incluyendo en el estudio, las posibles alternativas para paliar los problemas del cifrado en la capa de presentación, como por ejemplo, la mejora de los endpoint y la implantación de un sistema de eficaz, para facilitar la gestión de los mismos de forma centralizada.

IBSN, blog, id

El síndrome de la UVI conectada, o el ataque al decisor.

No hay mucho escrito sobre la mejor forma de atacar un sistema de mando y control, lo que sería aplicable a entornos militares, o civiles, como infraestructuras críticas, sistemas de control industrial, o incluso, barcos o aeronaves.

Ahora que el CCN ha publicado un informe sobre ciberamenazas en el sector salud, en el que se destaca la enorme vulnerabilidad que supone la obsolescencia en estos sistemas críticos (principalmente por el uso masivo de sistemas operativos obsoletos y sin soporte del fabricante, como Windows XP), creo que puede ser interesante hablar sobre los ataques al decisor, o el síndrome de la UVI conectada.

Imaginemos una UVI en la que todos los sistemas de monitorización médica disponen de interfaz de red, y se encuentran conectados a un sistema de mando y control, donde el personal de guardia vigila a los pacientes.

Para hacer más realista el entorno, dicho sistema está conectado también a la red de propósito general del hospital, para acceder a otros servicios básicos del hospital, como la farmacia, historiales clínicos, administración, etc. En este entorno tan exigente, hay protocolos médicos, con unos tiempos de reacción muy definidos, y que en muchos casos, son públicos, lo que podría facilitar las cosas a un posible atacante.

Supongamos que el tiempo que transcurre entre que salta una alarma de azúcar alto en un paciente, hasta que el médico de guardia le inyecta una dosis masiva de insulina, son 20 segundos. Ese es el tiempo preciso que ha de estar activo el malware en el sistema.

Hablamos de un malware sin archivo y sin persistencia, ya que los sistemas de la UVI, como es lógico, están permanentemente conectados a la red eléctrica y a la red de monitorización, por lo que también se puede autoeliminar del sistema sin dejar rastro.

Supongamos también, que ese malware genera una alarma de azúcar alto en un paciente y que a los 20 segundos exactos, modifica el histórico de lecturas de azúcar a valores normales y finalmente, se autoelimina de la memoria del sistema.

En ese tiempo de 20 segundos, el médico de guardia habrá activado el protocolo de emergencia, e inyectado una dosis adecuada de insulina al paciente, lo que le habrá provocado un grave coma diabético.

Una vez abierta la investigación, para los responsables de la misma, parecerá claro que el médico se ha equivocado, o que ha intentado matar al paciente, minando gravemente su prestigio y credibilidad.

Los ataques de decepción, orientados a atacar al decisor, son muy peligrosos ya que provocan un daño, encubren el origen y pueden repetirse varias veces, hasta que haya datos suficientes como para considerar que está ocurriendo una anomalía estadísticamente poco probable.

Está claro que es mucho mejor atacar a un sistema de mando y control aéreo engañando sobre la posición real de los aviones, que bloqueando completamente el sistema, ya que en primer caso, se puede usar el ataque varias veces sin que el decisor sea consciente de que está ocurriendo algo raro y que está tomando decisiones equivocadas.

Alguien puede pensar que ese escenario de la UVI conectada es improbable, pero se tiene la certeza de que se ha utilizado en la central nuclear de Natanz (Irán) y se tiene la sospecha de que puede haber sido utilizado en otra ocasión, provocando varios choques de buques de guerra estadounidenses en el Pacífico, algo que estadísticamente era improbable.

Tal como narra la periodista Yolanda Quintana, en el capítulo 4 de su excelente libro titulado "Ciberguerra", hubo un Stuxnet 0.5, que poca gente conoce. Dicho malware tenía como misión retrasar el programa nuclear iraní, y socabar el prestigio de los científicos responsables del mismo, lo que lo retasaría todavía más. Desde mi punto de vista, algo más sutil, refinado y efectivo que, lo que hizo la versión 1.0 de Stuxnet destruyendo físicamente las centrifugadoras, algo muy evidente y que hizo sospechar rápidamente que algo raro estaba pasando en la planta.

Stuxnet 0.5, fue subido de forma anónima a la plataforma de análisis de malware VirusTotal en 2007, pasando desapercibido por todo el mundo. La versión 0.5 de Stuxnet, que como la versión 1.0, iba dirigido a los sistemas SCADA de Siemens que controlaban la instalación nuclear iraní, variaba la presión del gas de hexafluoruro de uranio en las centrifugadoras, para reducir drásticamente la producción de uranio enriquecido de la central. En julio de 2009, el Presidente de Irán aceptó la dimisión de Gholam Reza Aghazadeh, que era el jefe del programa nuclear de Irán, al parecer, por el fracaso de su gestión.

Es decir, Stuxnet 0.5, además de lograr un retraso de dos años en el programa nuclear de Irán y sin que nadie se diera cuenta de que estaba pasando algo raro en la planta, también logró minar, de forma drástica y definitiva, la credibilidad del decisor, lo que lo retrasó todavía más el programa nuclear iraní, mientras se buscaba un sustituto.

Este malware tan sofisticado y sutil, estaba diseñado para desactivarse automáticamente el 4 de julio de 2009, fecha muy cercana a la dimisión de Gholam Reza. Es decir, que nos encontramos en un caso que bien lo podemos asimilar al síndrome de la UVI conectada del que hemos hablado al principio.

Este tipo de ataques también son muy peligrosos en el entorno aeronáutico, cuando los pilotos (decisores), están acostumbrados a la enorme fiabilidad del vuelo automático.

Si un malware logra engañar al piloto, por ejemplo, desconectando el piloto automático sin que él lo sepa, o desconectando inadvertidamente el sistema automático de control de potencia de los motores, hay muchas probabilidades de que el piloto no se cuestione ese hecho, y el vuelo acabe en desastre. Hay un caso documentado de este tipo de comportamiento de los pilotos, que aunque no fue provocado por malware, ilustra muy bien lo que puede pasar cuando el decisor es "engañado" y tiene una fe absoluta en la fiabilidad del sistema.

Se trata del vuelo 214 de Asiana Airlines, que se estrelló el 6 de julio de 2013 en la aproximación al aeropuerto internacional de San Francisco. La investigación de la NTSB demostró que el piloto había usado una secuencia de comandos inusual, que tuvo como consecuencia la desconexión del sistema que controla automáticamente la potencia de los motores. Dicho sistema mantiene una determinada velocidad del avión, a un determinado ángulo de ataque, haciendo que el piloto pueda volar por posiciones de morro y se pueda olvidar del mando de gases.

El piloto de Asiana, que había realizado la mayoría de sus horas de vuelo en modo automático, tenía fe absoluta en el sistema, y no fue consciente de que el avión no iba a corregir la potencia de los motores, hasta que fue demasiado tarde, y tocó el suelo de forma catastrófica antes de llegar a la pista.

Ese mismo efecto ocurría si un determinado malware desconecta el sistema de control automatico de potencia y además, como hizo Stuxnet 0.5, falsea la información visual del estado de los sistemas, para que el piloto no sea consciente de que se ha desconectado dicho sistema.

Para complicar las cosas, el malware podría forzar que dicha información no se refleje en las cajas negras, para que en la investigación parezca que el accidente ha sido un fallo del piloto.

Es evidente que tendrían que ocurrir varios accidentes similares, en un determinado tiempo, para que alguien sospechase que algo raro estaba pasando y se pusiera a investigar.

Por ello, es muy importante que los sistemas críticos estén debidamente actualizados, con todo el hardware y software con soporte de los fabricantes , que dispongan de los mecanismos de seguridad adecuados, y que sus usuarios sigan escrupulosamente los procedimientos operativos de seguridad, de forma que se minimice la posibilidad de ser afectados por una amenaza desconocida, especialmente dirigida a nuestro sistema y que no pueda ser detectada o neutralizada por los sistemas automáticos de seguridad.

También hay que tener en cuenta que un ataque al decisor que esté bien diseñado, es casi tan complicado de detectar para un equipo de ciberseguridad, como los sucesos aleatorios de corta duración. Por ejemplo, exfiltraciones de datos mediante peticiones DNS falsas. Por lo que es necesario arbitrar mecanismos de detección eficaces, que pongan en evidencia este tipo de anomalías en sistemas críticos.

Mi recomendación es mantener unas estadísticas precisas de la normalidad y e investigar a fondo, cualquier cosa que se desvíe de dicha situación de normalidad. Los valores simulados de normalidad, no se van a corresponder con valores reales de esa misma normalidad, lo que nos puede hacer sospechar.

En otra ocasión hablaré de la ley de Benford, o la Ley del primer dígito, que se puede extender a tercero, al cuarto, etc y que nos puede ayudar a encontrar este tipo de anomalías altamente escurridizas en nuestros sistemas de mando y control.

IBSN, blog, id

La paradoja del falso positivo y la ciberseguridad

Cuando se gestionan eventos e incidentes de seguridad, lo peor que nos puede pasar es tener un falso negativo, es decir, una ciberataque con éxito, pero también hemos de temer los falsos positivos, puesto que nos hacen perder mucho tiempo de análisis y es necesario disponer de una adecuada capacidad para identificarlos y eliminarlos.

Cuando hablamos de falsos positivos, hemos de tener en cuenta la paradoja del falso positivo (https://es.wikipedia.org/wiki/Paradoja_del_falso_positivo).

Supongamos que tenemos que encontrar una aguja en un pajar, es decir, 1 aguja entre 10.000.000 de briznas de paja y alguien nos vende un sistema de detección de agujas entre la paja, con una fiabilidad del 99%, lo que a simple vista, y sin pensarlo demasiado, parece que es algo estupendo para lograr nuestro objetivo, en realidad es una pesadilla.

Lo cierto es que ese sistema nos proporcionará la no desdeñable cantidad de 99.999 falsos positivos, para encontrar la aguja en el pajar. Es decir, que entre los 100.000 positivos que nos proporcionará el sistema, la posibilidad de que falle la detección, es de un nada despreciable 99,9999 %. Dicho de otro modo, tendremos que revisar 100.000 muestras, una por una, para encontrar la aguja.

Pensemos ahora en el número de muestran que procesan diariamente nuestros sistemas de detección de malware. Aplicado lo anterior a la ciberseguridad, lo que quiere decir, es que nuestros sistemas de detección han de ser muy fiables, teniendo una tasa baja de falsos negativos y una tasa muy muy muy baja, de falsos positivos. Si no es así, sobrecargaremos nuestra capacidad de análisis de malware y forense, para poder discernir de forma fiable, lo que es un falso positivo y lo que es un positivo real.

Asimismo, si no podemos "adiestrar" nuestro sistema de seguridad para que sea capaz de ir aprendiendo lo que es un falso positivo y un falso negativo, estaremos condenados a tropezar con la misma piedra una y otra vez, entrando en un círculo vicioso del que es muy complicado salir. Dicho de otro modo, de nada nos sirve un sistema de detección de malware, si no tenemos una adecuada capacidad de gestión de los falsos negativos y de los falsos positivos.

Hace unos meses me mostraron un sistema con varios motores de detección de malware, en teoría muy fiables todos ellos. La idea era hacer un triaje inicial de las muestras sospechosas en el laboratorio forense. Pero ¿qué hago que uno de los motores con buena reputación me marca una muestra como positivo y los otros no?. Recordemos que el WannaCry solamente era detectado por unos pocos motores al principio. Cuando hice números con los datos que me proporcionaron, descubrí que dicho sistema iba a crearme más problemas que beneficios, y que era un ejemplo bastante claro de la paradoja del falso positivo.

Cuando usamos un sistema de detección para hacer triaje en el laboratorio forense, es necesario saber muchas cosas de él, como por ejemplo, los criterios utilizados para añadir las firmas nuevas y para eliminar las viejas, o los mecanismos usados para determinar que una muestra es un positivo, con los sistemas eurísticos o de sandbox que utiliza, algo que no siempre proporcionan de forma clara, estandarizada y consistente, los fabricantes de soluciones de detección de malware.

Si el sistema de detección funciona como un mero semáforo, y no nos proporciona información adicional, que nos ayude a decidir ante un positivo, no vamos a tener más remedio que recurrir a un análisis detallado de la muestra en el laboratorio forense, para estar seguros de que es un archivo malicioso, especialmente, si el positivo nos aparece en un archivo que consideramos que es necesario para el normal funcionamiento de nuestros sistemas.

Esto nos lleva a otro consejo importante. Hemos de ser muy cuidadosos a la hora de hacer cambios de configuración en nuestros sistemas de detección como por ejemplo, en los endpoint, especialmente, si observamos que los cambios introducidos provocan un aumento de los falsos positivos, o de los falsos negativos.

Cuanto mejor y fiable sea nuestro sistema de detección, menos nos tendremos que preocupar de la amenaza conocida y más nos podremos centrar en descubrir y eliminar la amenaza desconocida, tarea que es mucho más complicada, exigente y tediosa. Pero eso es algo que no podremos hacer adecuadamente, si tenemos a nuestros analistas y forenses buscando agujas en pajares, por tener una elevada tasa de falsos positivos, o por no poder "enseñar" a nuestro sistema a reconocerlos en el futuro.

Por este motivo, muchos fabricantes están añadiendo a sus sistemas de detección mecanismos de machine learning, o de deep learning, que mejoran la capacidad de eliminar los falsos negativos y los falsos positivos según aumenta la información fiable que maneja el sistema según lo utilizamos y le vamos "enseñando".

Sin duda, hay productos de detección de malware excelentes en el mercado. Principalmente, gracias a la enorme evolución que se ha producido en los mismos durante los últimos años. Pero también es cierto, que debemos tener en cuenta las matemáticas relativas al sistema, a la hora de tomar una decisión de compra.

IBSN, blog, id

Las métricas de la gestión de eventos e incidentes de seguridad

Algunos me preguntan por las métricas para valorar la gestión de eventos e incidentes de ciberseguridad y yo les digo que basta contestar cuatro preguntas básicas:

a) ¿Hemos actuado a tiempo?

b) ¿Sabemos lo que ha pasado realmente?

c) ¿Hemos mejorado la seguridad tras el evento o incidente?

e) ¿Hemos evitado que se produzca un evento o incidente igual o similar en el futuro?

Evidentemente, en el mundo digital, la velocidad es importante, desde la detección, a la mitigación o la recuperación.

Asimismo, el conocer lo que ha pasado, contestando a preguntas como ¿quién?, ¿cuándo?, ¿dónde? ¿cómo?, ¿por qué? , nos permitirá aplicar la inteligencia a nuestras decisiones. Sin duda, la primera y la segunda pregunta, son las más complicadas y requieren disponer de capacidades, como monitorizacion, análisis forense, ciberinteligencia, o análisis de malware.

Finalmente, aunque es cierto que si contestamos afirmativamente la última, también hemos de contestar afirmativamente la penúltima, lo contrario no es cierto siempre y si se produce ese caso, tenemos un serio problema.

Estas preguntas también sirven para descubrir procesos que no aportan nada a la seguridad. Yo recomiendo que todo aquello que aporta valor a la seguridad hay que sistematizarlo y lo que no aporta valor, hay que automatizarlo.