Cómo puedo estar 100% seguro

Supongo que las películas y series creadas en la industria de los sueños han llevado a los espectadores a ver a los hackers como personas especiales con superpoderes para saber todo lo que tenga que ver con la tecnología con solo pasar unos dedos sobre algo con chips y electricidad. Casi a ver a los hackers como magos con conocimientos supremos. Brujos de la tecnología que son capaces de entender todo lo que hace una placa verde con chips con solo leer los números de serie.

Es verdad que te recorre una sensación similar cuando ves una técnica de hacking que no conoces. Una nueva forma de hackear algo, sea esto una aplicación web, una cerradura electrónica, o un avión, como cuando Hugo Teso, que es un hacker en la industria de la aviación, nos hizo una demostración de cómo cambiar unos grados los mapas de un avión para hacerlo aterrizar no sobre la pista de aterrizaje, sino sobre el monte ese que está al lado de ella en el aeropuerto de Bilbao, y dejó sorprendida a la comunidad de seguridad en el año 2013 con su charla en Amsterdam. La primera vez que la vi en una conferencia por invitación, yo mismo me sentía como ver a Jorge Luengo haciendo uno de sus magníficos trucos de magia. Hugo aún se ríe de mí de lo mal que lo pasé viendo la charla.

Pero la verdad es que cuando acaba la magia de la demo y comienza la explicación técnica de por qué eso ha funcionado como ha funcionado, por qué ha pasado lo que ha pasado y has visto lo que has visto, te das cuenta de que no hay más magia que la de muchas horas estudiando, probando, haciendo hipótesis, pruebas empíricas que las tiran para atrás, demostraciones fallidas y nuevas contra hipótesis para encontrar el punto exacto de eso que es nuevo, que no está documentado, y que cuando el mundo lo ve por primera vez en una conferencia parece casi magia. La magia de muchas horas trabajando.

Y si pensamos en la de cosas que hay que revisar y estudiar, estas son muchas, ya que una empresa normal hoy en día tiene mucha tecnología. Tiene mucha más de la que piensan ellos mismos. Mucha más tecnología incluso de la que te puedes estar imaginando tú ahora mismo, que estás leyendo este artículo. Y se encuentra escondida cerca, lejos y al lado mismo de cada uno de los empleados, procesos o servicios de la compañía.

Se encuentra escondida desde los lugares más próximos a ellos sin que tan siquiera los noten, como los sistemas electrónicos de los sistemas de aire acondicionado o los proyectores de vídeo que tienen en las salas de reuniones, hasta los más remotos que ni se imaginan, como el servidor DNS que resuelve la dirección IP de uno de los paneles de control que consultan los smart-radiadores (o lo que tú pienses) de su empresa para buscar actualizaciones de software que vendrán —o no— firmadas digitalmente, y que pueden hacer que un atacante se siente en tu red por algo que ocurrió en Noruega.

Hay tecnología en rinconcitos escondidos. Y también en grandes datacenters de cloud computing que manejan tus datos, sus usuarios, tus contraseñas, tu información sensible. Y la manejan lejos de tus manos, lejos de las manos de los técnicos informáticos. Lejos de los responsables de seguridad de las compañías. Están escondidos aquí y allá, y además, están vivos y mutando constantemente.

Cuando un hacker estudia un sistema informático, un programa, una librería informática, o un código fuente de una aplicación y la audita, da su recomendación de seguridad. Tiene fallos de seguridad descubiertos o no tiene fallos de seguridad descubiertos. Si los tiene —porque ya se conocían o porque el hacker los ha encontrado nuevos—, el código del sistema debe ser parcheado, y por tanto cambia. Y debe volver a ser auditado, estudiado y aprendido de nuevo. Y si cuando se vuelve a hacer no se encuentra ningún fallo de seguridad, ¿quiere decir que está seguro?

No. Quiere decir eso exactamente, que no se han encontrado fallos de seguridad conocidos en él. Pero mañana un hacker creativo encuentra una nueva forma de localizar y explotar nuevos fallos de seguridad en el código y vuelven a aparecer nuevos fallos de seguridad. Y es un juego infinito que llevamos años siguiendo en todos los programas y sistemas informáticos.

Para que os hagáis una idea, cada fallo descubierto es estudiado, analizado y corregido. Y para eso se crea un expediente en una base de datos donde se le asigna un identificador único. Ese identificador único es un código CVE de la base de datos de Common Vulneratilities and Exposures. Por supuesto, no son todos los que hay, ya que hay muchos bugs que los fabricantes corrigen sin reportar públicamente —yo he reportado muchos bugs que se han arreglado sin crear una entrada en la base de CVE—, pero es un buen indicador para que entendáis la magnitud y dificultad del problema.

En 2020 el número de fallos catalogados en la base de datos de CVE fue de 18.358, batiendo el número histórico de bugs —que es como se llaman a los fallos en los sistemas informáticos— en un año. Y fueron publicados diariamente. Una media de 50 nuevos bugs descubiertos al día, cada uno con una ventana de exposición distinta, que es como llamamos al momento desde el que se hace público el fallo hasta el momento en el que el fabricante publica la solución.

A este volumen de bugs, que cada uno de ellos puede estar escondido en una docena, una centena o un millar de los sistemas de una empresa, hay que unir que existen fallos humanos de operación, de configuración, o de aplicación de medidas de protección. Vamos, que una persona puede dejarse una contraseña por defecto en un sistema, o puede que un sistema traiga contraseñas por defecto que no estén comunicadas, puede que esté mal configurado un servicio, que para un ingeniero de sistemas conocerse el 100% de los miles de parámetros que se pueden configurar en una aplicación que funciona en una red empresarial no es siempre trivial.

Y luego llegan las novedades.

Claro, las aplicaciones no solo se actualizan por fallos de seguridad. Se actualizan también porque traen novedades, arreglan fallos de funcionamiento, corrigen incompatibilidades con otros elementos, por ejemplo, impresoras, ratones o protocolos de otros fabricantes, desde que no se conecta tu ratón BlueTooth a tu Mac o una aplicación saca mal los informes por un tipo de impresora.

Vete tú a saber qué interconexión de protocolos, funciones, señales ha sido ignorada por el programador, que para ellos hacer código no siempre es fácil. De hecho, leer el código fuente y ver los comentarios que dejan muchos programadores es como leer las notas de un libro que el propio autor escribió sobre ellos, y hay algunas muy divertidas.

Que yo digo que muchos desarrolladores de tecnología lo hacen como mi amigo Rodol, que programa echando dioses de oído. Años después aún me acuerdo de cuando le gritaba al ordenador porque no salía algo. El equipo le daba un error.

Y cuando disciplinadamente se iba al manual donde se encontraba la documentación, lo que ponía es algo que ayuda tanto como este mensaje donde dice que este error existe, pero nunca debería darse. Para que sepáis lo que sufren los pobres creadores de tecnología.

Así, cuando pasan estas cosas, los programadores atan con alambre su código, sin entender bien por qué algo funciona o no funciona, pero viendo empíricamente que está funcionando. Y puedes leer sus confesiones sobre estos renglones torcidos en el código que deja, en los comentarios, confesándose ante otro programador que pueda entenderlo bien. Este que os dejo aquí ya tiene unos años, pero me encantó.

Y es que el problema puede que no sea su código, sino que haya un fallo en el compilador que está utilizando —que es ese programa que convierte un programa escrito en letras y comandos por un humano en unos y ceros para que sea entendible por una máquina—, pero es que puede que el problema no esté en el compilador, sino en el sistema operativo que se ocupa de que el programa del compilador se ejecute sobre el hardware del ordenador. O a lo mejor es la función de una librería utilizada en el programa, que acaba de ser actualizada para arreglar un fallo y resulta que han inyectado nuevos bugs. Quién sabe…

Al final, la tecnología está viva y muta muy rápidamente, por lo que un responsable de seguridad, un autentico experto en tecnología o un hacker sabe siempre que estar 100% seguro es completamente imposible, y que lo mejor que se puede hacer es tener un equipo gestor de seguridad muy bueno que, con el límite presupuestario, sea capaz de gestionar el riesgo al mismo tiempo que la compañía sigue operando, pero créeme si te digo que todos sabemos que llegar al 100% de seguridad y no tener un incidente de seguridad es una utopía.

Ni en la empresa, ni en la vida personal, así que de lo que puedes estar 100% seguro es de que nunca vas a estar 100% seguro. Por si alguien tiene interés, en el año 2016 di una charla sobre cómo gestionar la seguridad informática en la empresa que sigue estando muy de actualidad.