Barbarities I: Banca electrónica

– Con este post me gustaría inaugurar una nueva sección en SAW llamada Barbarities, destinada a albergar cual pozo ciego, todas aquellas atrocidades que desde el punto de vista de seguridad uno ha ido viendo con el paso de los años. Se anima al lector a que comparta sus experiencias –

Barbarities… Hoy: La banca electrónica.

Los bancos, dentro de lo que cabe, hacen un esfuerzo por entregar a sus clientes medidas de protección ante el fraude y robo online a la hora de operar a través de sus páginas web o apps móviles. Códigos de validación de transacción por SMS, uso de https (qué menos…), teclados virtuales anti Click-hacking o tarjetas de coordenadas son solo algunos ejemplos de estas protecciones.

[Read more…]

Gafas que no le gustan a la NSA

Como era de esperar, en el MWC de Barcelona se han presentado multitud de novedades en el mundo de la tecnología móvil, principalmente. Sin embargo, eventos previos a la apertura del MWC hay otros como es el MobileFocus. No voy a hablar de las últimas novedades de Samsung. Aquí el protagonista es… ¡AVG! Sí, sí, has leído bien, AVG. La compañía antivirus y su departamento de Innovación ha presentado en el MobileFocus unas gafas que te hacen invisible.

Y no, no hablamos de invisibilidad cual capa de Harry Potter. Pero bueno, “it’s something”. Según explican en esta noticia de AVG, es posible gracias a varios materiales utilizados para fabricar estas gafas. Básicamente permite que, a la persona que lleva estas gafas, no se le pueda identificar mediante cámaras y otros sistemas de reconocimiento facial. Bueno, a quien se anime a llevarlas… más que nada porque son un poco feas. Pero, dejando de lado los aspectos estéticos, ¿cómo funcionan? Tal y como explica AVG funcionan gracias a dos principales materiales utilizados para su fabricación.

Por un lado, el uso de LEDs infrarrojos. Estos LEDs, en caso de estar encendidos, hacen que las cámaras sensibles a la longitud de onda de estos LEDs no puedan detectar los rasgos faciales. Claro que con esas gafas, ¿quién puede?

Por otro lado, el uso de material retroreflectante. Básicamente es un material que, en el momento de realizar la fotografía con flash, devuelve la luz tal como llega. Tal y como muestra la imagen:

Vale, muy bien, AVG, ¿y todo esto a santo de qué? Según nos cuentan tienen varios motivos por los que centrarse en el desarrollo de estas fantásticas gafas. Tienen como premisa la preocupación por la privacidad del usuario. Por lo tanto, los motivos que expone AVG son los siguientes:

  • Dado el uso masivo de smartphones tomando fotografías en sitios públicos, es (más que) probable que en alguna de ellas podamos salir sin nuestro consentimiento.
  • Proyectos como StreetView de Google permitirían identificar a una persona en uno o varios lugares públicos. Punto en el que no estoy muy de acuerdo, ya que Google suele censurar las fotos en las que aparece alguna persona. <mode paranoid on>Otra cosa es el uso interno que haga Google con las fotografías originales…<mode paranoid off>.
  • Proyectos como DeepFace de Facebook permiten el reconocimiento facial de las personas. Por tanto, permitiría a organizaciones y compañías hacer uso de esta característica, no solo para identificarnos si no también para cruzar esa información con otros datos encontrados en la Red.

Sin lugar a duda es un proyecto interesante, dado que estamos rodeados de cámaras de seguridad y videovigilancia, además de smartphones que pueden ser utilizados para espionaje (o contraespionaje). Aunque si te ven con eso puesto, lo que está claro es que vas a ser el centro de atención y desapercibido no vas a pasar precisamente :)

¿Qué opináis? ¿Se merece un empujón este proyecto? ¿Qué otras ventajas y/o inconvenientes encontráis? ¿Gafas de marca apostando por esta tecnología? ¿Os imagináis unas Google Glass con esta función?

Ahí dejo mis preguntas al aire para que respondáis. Feel Free!

Recopilación de información (Information gathering) sobre Logs de Proxy (II)

La semana pasada estuvimos viendo LightSquid y SquidAnalyzer como herramientas de análisis de logs para Squid. Una tercera herramienta interesante es:

SARG (Squid Analysis Report Generator)

Esta aplicación se encuentra implantada en multitud de organizaciones y al igual que SquidAnalyzer se encuentra actualmente en desarrollo. Como punto fuerte, podemos señalar la velocidad de procesamiento, gracias a que se trata de una aplicación compilada.

[Read more…]

ThreatExchange: Facebook busca aliados para compartir información sobre amenazas

La necesidad de colaboración para atajar las amenazas de seguridad de la información es una obviedad de la cual tanto organismos públicos como empresas privadas se están dando cuenta y están tomando cartas en el asunto. Esta semana ha saltado la noticia sobre una red colaborativa nacida de las manos de Facebook cuyo objetivo es el de compartir fácilmente información de amenazas informáticas entre organizaciones, y aprender de los descubrimientos de otros con el fin de hacer los sistemas más seguros. Así lo define Mark Hammel, Responsable de ThreatExchange.

“Our goal is that organizations anywhere will be able to use ThreatExchange to share threat information more easily, learn from each other’s discoveries, and make their own systems safer. That’s the beauty of working together on security. When one company gets stronger, so do the rest of us.” [1]

A esta iniciativa de Facebook se unieron en primer lugar Pinterest, Tumblr (cuyo propietario es Yahoo!), Twitter y Yahoo!. Posteriormente se han sumado empresas como Bitly y Dropbox. Los promotores de esta iniciativa pretenden que se unan más empresas y expertos en seguridad para compartir de forma ágil la información sobre las amenazas a las que todos estamos expuestos en la red.

En primer lugar lo que solicitan para el registro es el nombre y una dirección de correo corporativa, imagino para posteriormente establecer un acuerdo con cada uno de las organizaciones adheridas. Resulta importante saber qué se puede hacer con esa información y qué medidas de seguridad hay implantadas para garantizar que el uso que se haga de esa información sea legítimo. Por lo que he podido comprobar, no aparecen las condiciones de la plataforma aunque aseguran que hay implantados controles de privacidad para que cada participante pueda compartir la información solo con el grupo o grupos que desee. Pero no puedo evitar preguntarme… ¿quién será el responsable de la información compartida? ¿Qué uso se podrá hacer de la misma? ¿Realmente van a compartir estas grandes empresas las amenazas que pueden vulnerar o han podido vulnerar sus sistemas?

Desde luego considero que es un avance esta conciencia de seguridad y que las grandes empresas colaboren por la seguridad de las organizaciones y de los propios ciudadanos pero, sin querer ser desconfiado, me llama la atención que esta iniciativa salga de Facebook. Sin lugar a dudas, es una empresa con unos números impresionantes, más de 1.350 millones de usuarios activos, pero la cual también ha sido noticia en otras ocasiones por su política de privacidad y el uso que hace de los datos personales de sus usuarios. No seré yo el que reniegue de este paso que han dado con el ThreatExchange pero estoy expectante para ver si organismos públicos o CERTs respaldan y colaboran con esta iniciativa.

Esta última semana también se ha publicado una noticia de que el gobierno de Estados Unidos ha dado un paso más en la lucha antiterrorista en la red. Ha creado una agencia cuyo objetivo es conectar las acciones de las diferentes agencias federales que actualmente se ocupan de la ciberseguridad. La agencia se llama Cyber Threat Intelligence Integration Center (CTIIC) [2]. Un movimiento más de los que vienen dando los estados en este sentido, que desde luego demuestran la importancia de la seguridad en Internet y van dando pasos en esta dirección.

Veremos cómo evoluciona la iniciativa ThreatExchange y los efectos que ésta tiene. Sinceramente ojalá tenga éxito y el verdadero objetivo sea mejorar entre todos la seguridad.

Doble factor de autenticación, o cómo ponérselo difícil a un atacante

La doble autenticación es uno de esos mecanismos de protección muy familiares para la gente relacionada con ciberseguridad pero que, sin embargo, es una gran desconocida para el gran público. Este artículo pretende llegar a ese sector, cuyas cuentas de usuario son cada vez más interesantes para posibles atacantes. En futuras entradas ya me meteré más en harina y veremos aspectos más interesantes.

Para acceder a cualquier servicio es necesario que el usuario se identifique, proporcionando un identificador único en el dominio, como por ejemplo un nombre de usuario (o nickname), dirección de correo electrónico, documento nacional de identidad, número de seguridad social, etc. Esta información identifica al usuario, pero no lo autentifica, puesto que esta información no es secreta y cualquiera podría saberla.

Al identificador de usuario le debe acompañar algo más para que el sistema confíe en él y le permita el acceso. Hay tres factores de autenticación:

  • Algo que el usuario sabe: password, pin, passphrase, etc.
  • Algo que el usuario tiene: USB, llave, tarjeta, generador de claves, etc.
  • Algo que el usuario es: huella dactilar, iris, secuencia ADN, firma, reconocimiento facial, reconocimiento de voz u otros identificadores biométricos, etc.

Los métodos tradicionales de autenticación, familiares ya para todos, se basan en el uso de un identificador único de usuario acompañado de una contraseña que solo el usuario conoce. Pero, ¿qué pasa cuando la contraseña es interceptada o robada por otro usuario? Nadie quiere comprobarlo en primera persona.

El doble factor de autenticación, conocido también como 2FA o TFA, se basa en el uso conjunto de dos de los factores anteriormente mencionados; el ejemplo más usado es la generación de claves basadas en tiempo, donde el usuario debe introducir su password seguido de una clave temporal. Ésta es de un solo uso, tiene una validez de pocos segundos y es generada generalmente en el teléfono móvil, el cual ha sido previamente configurado con una semilla para generación de claves. En este caso un atacante podría interceptar la clave del usuario y el código temporal, pero ésta última, al tratarse de una clave temporal de un sólo uso no le resultaría útil. El atacante necesitaría la semilla con la que se generan las claves temporales, pero ésta no circula por la red, por lo que un man-in-the-middle resulta inútil.

Otras veces la clave temporal se genera en el servidor y se le envía al usuario en un mensaje SMS al teléfono movil, o por correo electrónico.

Si piensas que las claves temporales no son algo práctico ahora también es posible comprar llaves de seguridad en Internet. Se trata de llaves USB que contienen un certificado, y que tienes que insertar en un puerto de usb en el momento de introducir tu password.

A pesar de todo, la doble autenticación no es infalible, y como suele ser habitual el eslabón más débil suele ser el usuario, aunque este tipo de soluciones se lo ponen técnicamente muy difícil a los posibles atacantes. Kevin Mitnick cuenta en su libro “Ghost in the wires” como engañó a un operador de red de una importante multinacional para saltarse esta protección, haciéndose pasar por un empleado que no encontraba su tarjeta de claves.

A estas alturas puede que ya te haya convencido para usar el doble factor de autenticación, y te estés haciendo la pregunta: ¿dónde lo puedo usar?

Por suerte cada vez más servicios ofrecen esta posibilidad, aunque por el momento no todos. Algunos ejemplos son Google, Dropbox, Facebook, PayPal, eBay y Twitter. En https://twofactorauth.org/ puedes consultar una tabla de servicios y, en caso de ofrecer la posibilidad del doble factor de autenticación, los mecanismos que ofrecen.

Para hacer un resumen, la doble autenticación:

  • Reduce o elimina el robo de cuentas mediante phising.
  • Elimina el robo de cuentas mediante ataques man-in-the-middle.
  • Dificulta la impersonalización.
  • Y lo más importante: da algo de que hablar con tus amigos cuando te preguntan: ¿qué es ese USB raro que tienes en tu llavero?

Entonces es cuando les puedes soltar este rollo que acabas de leer, o incluso escribir un artículo. Hasta el próximo post :)

Recopilación de información (Information gathering) sobre Logs de Proxy (I)

Uno de los elementos principales a la hora de gestionar el tráfico de una red es mediante la implantación de un proxy. De manera muy simple podemos considerarlo como un sistema que hará de “intermediario” entre clientes y servidores. Es decir, el cliente no accederá directamente a Internet, sino que a la hora de visitar un sitio web, realizará una petición al proxy y será éste el que navegue hacia el sitio web y le reenvíe la respuesta al cliente.

Tener implantado un proxy implica que todo el tráfico de los clientes que accedan a Internet, pasará a través de él y (por tanto) estará siendo monitorizado. Podemos pensar que la implantación de un proxy en una organización tiene como objeto llevar un control de la navegación de los usuarios, y aunque en parte puede ser cierto (lo que tiene sus implicaciones legales que no vamos a tratar aquí), también hay que decir que mediante una configuración adecuada de éste se puede evitar que los empleados accedan a sitios no permitidos, ya sea porque no sean recursos necesarios para el desempeño correcto de su trabajo o porque conlleven un peligro para la seguridad de la infraestructura de la organización.

Debemos recordar que con el simple hecho de acceder a un sitio web, si éste está contaminado y alberga un kit de exploits para diferentes navegadores y versiones, el cliente puede quedar automáticamente infectado en el caso de que su navegador o alguno de sus plugins posea alguna vulnerabilidad no parcheada. Lo que, como todos sabemos, es más frecuente de lo deseable.

Entremos en materia. Imaginemos que hace unos días, a partir de una revisión rutinaria del log del proxy, se detectó que varios empleados de la empresa estaban haciendo un consumo de decenas de gigabytes diarios cada uno. Lógicamente, esta revisión no se hace de manera manual y para ello existen diferentes alternativas que podremos usar para tener la información del proxy categorizada y ordenada. En este y el siguiente post veremos tres aplicaciones de análisis de logs para squid. Para llevar a cabo las pruebas se ha utilizado Kali sobre la que se han desplegado las aplicaciones. El objeto de este post no es detallar el proceso de instalación por lo que este paso queda como ejercicio para el lector (ejercicio sencillo, en cualquier caso).

LightSquid

LightSquid se trata de un conjunto de cgi y scripts en perl que se despliegan en el servidor web, y aunque a priori no ofrezca una interfaz muy moderna ni elegante, se trata de un buen aliado por rapidez y sencillez.

Si accedemos al día en particular nos aparecerá un listado con los usuarios.

Una funcionalidad interesante de lightsquid es que muestra una tabla con las horas de navegación de cada usuario.

La aplicación también mantiene listados de sitios navegados por mayor número de usuarios, ficheros de mayor tamaño descargado, así como listados de usuarios que han visitado determinado sitio. Lamentablemente es una aplicación sin desarrollo actualmente.

SquidAnalyzer

SquidAnalyzer es otro analizador de logs de squid hecho en perl, con mayores funcionalidades que el anterior y con una interfaz más elegante y cuidada (que vale, eso tampoco es muy difícil). Una vez seleccionado el periodo, nos aparecerá una pantalla resumen de la actividad durante el mismo.

En la parte superior, tendremos un menú en el que se nos mostrarán estadísticas de usuarios, URLs, dominios, recursos (agrupados por mimetype).

Una de las características más interesantes de este analizador es que es capaz de agrupar las peticiones por segmento de red, con lo que obtendremos un punto más de granularidad a la hora de hacer estadísticas de uso.

Accediendo a través de las subredes, obtendremos un listado de actividad de usuarios, tiempos de navegación, peticiones realizadas…

Una vez seleccionado el usuario, nos mostrará en detalle la actividad del mismo.

Aparte, podemos obtener estadísticas de tipo de ficheros mas descargados.

Por último podremos tener una vista general de sitios web con mayor actividad.

En la próxima entrada veremos SARG (Squid Analysis Report Generator) y analizaremos cómo encaja todo esto con el mundo de la seguridad.

Análisis de un OLE File con oledump.py

En esta entrada vamos a ver de una manera muy rápida como hacer un análisis de un fichero OLE y analizar los streams que contenga (en este caso se trata de una macro) con la herramienta y reglas de Didier Stevens. El documento no es muy complejo pero nos sirve para ilustrar cómo utilizar esta herramienta.

Hash del fichero cazado en un correo:

e4e46f746fffa613087bba14666a3ceec47e145f  Transferencia_Interbancaria.doc

Paso 1: Lanzamos yara con nuestra reglas:

[Read more…]

¿Te cuento un secreto?

Hace unos meses, llegó a España la aplicación Secret, tanto para Android como para iOS. Y eso ¿de qué va? Para quien no la conozca, las bases de esta aplicación son muy sencillas: puedes publicar mensajes cortos (similar a Twitter) con la peculiaridad de que nadie sabrá que los has escrito tú. Y claro, tampoco sabrás quién escribe las cosas que lees.

Una vez que has incorporado un cierto número de amigos (usando los contactos de tu móvil y tus amigos de redes sociales), podrás ver si las publicaciones que lees son de un amigo o del amigo de un amigo. Con eso se protege el anonimato de tus amigos (si sólo tienes 5 y lees una publicación de uno de ellos, es probable que adivines de quién se trata). También puedes ver las publicaciones de desconocidos sabiendo únicamente su localización.

Contado así no suena mal ¿no? De hecho, en las preguntas frecuentes de la propia aplicación ensalzan que el anonimato que ofrecen permite que la gente se muestre tal y como es y exprese sus verdaderos pensamientos. Incluso dan unas pequeñas indicaciones a sus usuarios para que se sientan libres de expresar lo que piensan, siempre respetando a los demás. Todo muy idílico.

[Read more…]

Alternate Data Stream: ADS – Flujo de datos alternativos en NTFS

Un flujo de datos alternativo (ADS – Alternate Data Stream) es una característica del sistema de ficheros NTFS que consiste en incluir metainformación en un fichero. Podríamos decir que son ficheros secundarios “ocultos” guardados dentro de otros ficheros. El objetivo inicial es almacenar información extra acerca del fichero principal, pero esta técnica también fue muy usada para propagar virus de forma transparente para el usuario.

Aclarar que en este artículo me voy a centrar sólo en el sistema de ficheros NTFS sobre Windows 8 en concreto. En otros sistemas de ficheros existen técnicas similares; el símil con sistemas de ficheros como ext3, ext4, JFS, HFS+, etc., serían los atributos extendidos (EAs – Extended Attributes). La limitación de los EAs es que no se puede incluir una imagen o un archivo ejecutable como sí puede almacenarse en los ADS. Pero como he comentado, en este artículo sólo nos centraremos en NTFS y los ADS.

Hay que tener en cuenta algunas consideraciones de los flujos de datos alternativos:

  • Una aplicación de escritorio solo leerá el flujo principal de un archivo. Es decir, mediante el explorador de Windows sólo se abrirá el fichero que pertenezca al flujo principal. Los flujos alternativos sólo se pueden ejecutar mediante consola de comandos.
  • De igual forma, con el explorador de Windows solo se verá el flujo alternativo, incluso, solo se mostrará el tamaño del fichero perteneciente al flujo principal. Si hay un vídeo de 100MB por ejemplo, éste tamaño no se verá reflejado en el tamaño del fichero.
  • Los flujos de datos alternativos se pueden ver y abrir mediante la consola de comandos.

La finalidad de los flujos de datos alternativos es asociar ficheros o información que pueda ser confidencial, a ficheros de forma que queden ocultos a usuarios. Pero de la misma forma se puede usar esta técnica para alguna actividad maliciosa.

Como particularidad, mencionar que cuando descargamos un fichero de Internet, lleva asociado un flujo alternativo llamado “Zone.Identifier”, que indica la zona desde donde se ha descargado el fichero. Windows después utiliza dicho valor para abrir o ejecutar los ficheros. El significado de los valores es:

Después de la introducción, vamos a ver un ejemplo de cómo crear y ver el contenido de un flujo de datos alternativo. Para el ejemplo vamos a tomar dos ficheros:

  • principal.pdf, lo trataremos como fichero del flujo principal
  • img_oculta.jpg, lo trataremos como fichero del flujo alternativo

Ejecutamos dir para el contenido de la carpeta. Importante, fijaos en los tamaños de los ficheros:

Creamos ahora el flujo de datos alternativo, el comando sería el siguiente:

type img_oculta.jpg > principal.pdf:img_oculta.jpg

¿Qué ocurre si volvemos a hacer un dir? Aparentemente nada ha cambiado…

Se puede observar que el tamaño del fichero principal.pdf no ha cambiado absolutamente nada. Ejecutemos ahora el comando dir /r:

Como se ve en la imagen, el fichero principal.pdf tiene un flujo alternativo identificado como :img_oculta.jpg. Este flujo de datos alternativo coincide en tamaño con el original img_oculta.jpg, de hecho éste se podría eliminar, pero el flujo de datos alternativo seguiría existiendo. También, como ya hemos comentado antes, el tamaño del fichero principal.pdf tampoco se ha alterado.

Para abrir el contenido del flujo de datos alternativo utilizaríamos el comando:

Nombre_de_la_aplicacion fichero.extension:alternativo.extension

En nuestro caso vamos a abrir la imagen oculta con el editor de imágenes de Windows Paint:

mspaint principal.pdf:img_oculta.jpg

En sistemas operativos antiguos como Windows XP, la ejecución de un flujo de datos alternativo se hacía mediante el comando start, pero a partir de Windows 7 esto no está permitido, por lo que se cambió a invocar directamente la aplicación para abrir el fichero.

Supongo que ya os habréis hecho la pregunta: ¿qué ocurre si añado un “.exe” como flujo alternativo? En este caso, nos encontramos con que a partir de Windows 7 no está permitido (por motivos de seguridad) ejecutar un “.exe” como flujo alternativo. Veamos un ejemplo.

Vamos a asociar a un fichero llamado principal.txt la calculadora de Windows:

type c:\Windows\System32\calc.exe > principal.txt:calc.exe

Ahora ejecutamos mediante el comando start:

start .\principal.txt:calc.exe

Y el resultado es un mensaje de error que dice “Windows no puede encontrar el archivo”. Tal y como esperábamos, no podemos ejecutar un fichero “.exe” en un flujo de datos alternativo. Pero como esperábamos, eso no es del todo cierto. Para saltarnos esta medida vamos a crear un script en Python, y mediante este script llamaremos al ejecutable. Por cambiar un poco del típico ejemplo, he decidido iniciar una instancia Google Chrome.

Creamos un fichero llamado script_py.txt con el siguiente contenido:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
import sys, string, os			
os.system('"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"')

Ahora asociamos el fichero como flujo de datos alternativo de un fichero de texto llamado principal.txt.

type script_py.txt > principal.txt:script_py.txt

Para ejecutar el script de Python lo haremos mediante la sentencia:

C:\Python27\python.exe principal.txt:script_py.txt

Si todo ha ido bien, con esto lograremos ejecutar un fichero “.exe” a partir de un flujo alternativo. En este caso, se abrirá una nueva instancia del navegador Google Chrome.

Esta técnica era muy utilizada por atacantes para insertar malware en flujos alternativos. Aunque hemos visto que en los sistemas operativos actuales no se puede hacer directamente, sí se puede de forma indirecta, por lo que sigue siendo un aspecto a tener en cuenta para garantizar la seguridad.

Aunque no se ha visto en el artículo, existen herramientas para ver los flujos de datos alternativos en modo gráfico. Una herramienta es AlternateStreamView de Nirsoft, la cual te permite escanear carpetas en busca de ficheros alternativos.

Sin lugar a dudas, hay que tener en cuenta los flujos de datos alternativos para garantizar la seguridad de los sistemas, y no ejecutar código malicioso que permanezca oculto. Además, este tema resulta muy interesante a la hora de realizar un análisis forense para una pericial, ya que podríamos obtener información relevante que a simple vista no está accesible.

Los sistemas de control aislados o el móvil perpetuo de primera especie

Existen ideas que se resisten a desaparecer. Y entre ellas hay un tipo especial, las que se basan en la confusión entre los propios deseos y la realidad. En ocasiones estas ideas se convierten en entes que sobreviven a su propia refutación. Durante siglos el ser humano ha ambicionado construir una máquina que sea capaz de funcionar continuamente, produciendo trabajo y sin aportes energéticos del exterior. Tanto la ha buscado que tiene hasta nombre: el móvil perpetuo de primera especie.

Durante siglos mentes por lo demás lúcidas han luchado contra la implacable realidad construyendo modelos que, una y otra vez, han fallado en el momento de ponerlos a prueba. Pero claro, sería tan maravilloso que semejante máquina pudiese existir… Tal vez con esta o aquella mejora pudiese funcionar. Hay que pulir esto y esto, refinar aquello. Todo en aras de la promesa de la liberación energética. Pero no. Es imposible una máquina tal en nuestro universo porque su mera existencia violaría una ley esencial del mismo: el primer principio de la termodinámica. Ante esta evidencia la Academia Nacional de las Ciencias de Paris decidió en 1775 que no aceptaría más proyectos de móviles perpetuos. Tal era el grado de consolidación de la termodinámica entonces que se adoptó como criterio infalible, ahorrando la necesidad de poner a prueba una y otra vez los dispositivos surgidos de la mente de gente con más buena intención que conocimientos físicos.

El caso es que hoy en día nos encontramos ante un caso similar. Cuando se trata de auditar la ciberseguridad de un sistema de control industrial, no importa el propietario, la tecnología o su propósito, en un gran número de casos acabamos topando con un ente al que podríamos denominar ‘el móvil perpetuo de los sistemas de control’ pero que se conoce habitualmente como ‘el sistema de control industrial aislado’. Y es que, efectivamente, si mi sistema de control estuviese efectivamente aislado y funcionase produciendo trabajo sin intercambiar información con el exterior, no tendría que preocuparme por su ciberseguridad, ¿no es cierto? Estaría asegurada de forma intrínseca.

Una y otra vez los ‘móviles perpetuos de los sistemas de control’ no resisten una investigación en profundidad. En el caso de los sistemas físicos basta definir un volumen de control en torno a nuestro móvil perpetuo y verificar si existe intercambio de energía con el exterior a través de esa frontera. En el caso de los sistemas industriales el concepto es el mismo, pero lo que buscamos son intercambios de información, de un tipo u otro. Siempre los hay: permanentes o temporales, síncronos o asíncronos, cableados o no, tontos (pendrives) o inteligentes (portátiles de mantenimiento). Y es que, ¿para qué sirve un sistema con el que no me puedo comunicar y que no puedo modificar de forma alguna?

La refutación caso por caso supone un importante gasto de energía desde el principio mismo del proyecto. Sería bastante útil que se adoptase un criterio equivalente al de la Academia de las Ciencias de Paris. De esta forma podríamos rechazar a priori cualquier reivindicación de aislamiento y podríamos ponernos a trabajar desde el principio.

Aunque, por otra parte, si configurase mi sistema de esa manera quizá entonces… sí, quizá…

Nota: la ilustración reproduce el ‘recipiente de flujo continuo’ de Robert Boyle. A nuestros ojos modernos puede producir hasta risa, que sin duda se tornará en sonrojo al pensar la opinión que tendrán los humanos del futuro al rememorar como en el siglo XXI se podía intentar defender el concepto de ‘sistema de información digital aislado’ (IMHO).