Esta es la edición de final de año del recordatorio de que los números aleatorios y las computadoras no se llevan bien. En esta ocasión de la mano de John D. Cook, y RNG, PRNG, CSPRNG.

Empieza recordándonos que la mayoría de generadores de números aleatorios son generadores de números seudoaleatorios (pseudorandom number generators PRNGs).

Most random number generators are pseudorandom number generators (PRNGs). The distinction may be pedantic or crucial, depending on context. In the context of cryptography, it’s critical.

Y la vuelta de tuerca es que para la criptografía (y seguridad en general) no nos basta con estos números (que sería suficientes para simulaciones, integración numérica, juegos, …) sino que necesitamos los llamados generadores criptogr´ficos seguros de números seudoaleatorios (cryptographically secure pseudorandom number generator, CSPRNG).

A PRNG may be suitable for many uses—Monte Carlo simulation, numerical integration, game development, etc.—but not be suitable for cryptography. A PNRG which is suitable for cryptography is called a CSPRNG (cryptographically secure pseudorandom number generator).

¿La razón? Hay técnicas de análisis criptográfico muy pontentes, que pueden ayudar si hay sesgos o la calidad de los números generados no es buena por algún motivo.

If a PRNG fails statistical tests, it has some sort of regularity that potentially could be exploited by cryptanalysis.

Los generadores de números seudoaleatorios tienen buenas propiedades desde el punto de vista de la estadística, pero no tienen por qué ser seguros.

A PRNG may have excellent statistical properties, and pass standard test suites for random number generators, and yet be insecure.

Un generador de números aleatorios físico, con buenas propiedades estadísticas podría tener, sin embargo, buenas propiedades desde el punto de vista de la seguridad. Nombra el conocido caso de las lámparas de lava de Cloudflare (How do lava lamps help with Internet encryption?)

I suspect that a physical RNG with good statistical properties will have good cryptographic properties as well, contrary to the usual case. Cloudflare famously uses lava lamps to generate random bits for TLS keys.

Pero también puede ocurrir que los sistemas generadores físicos fallen las pruebas estadísticas (por ejemplo, que aparezcan sesgos).

A physical RNG might fail statistical tests. For example, maybe the physical process is truly random but biased.

¿Alguien de estadística en la sala?

Creo que venimos hablando de este tema desde las primeras versiones de este sitio, desde varios puntos de vista:

• Las diferentes industrias que se digitalizan cometen los mismos errores que las que lo hicieron anteriormente y no aprovechan lo que se ha aprendido en estos años. No sólo eso, sino que a pesar de desarrollar nuevas plataformas, no lo hacen con los principios adecuados, que garanticen que se hace bien.
• La industria del automóvil ya ha pasado varias veces por estos problemas (diez años va a cumplir, por ejemplo, este: [PFD] Remote Exploitation of an Unaltered Passenger Vehicle a cargo de Charlie Miller (uno de los primeros en ganar notoriedad con estos temas) y Chris Valasek, también curtido en estas batallas.

Em Hacking Kia: Remotely Controlling Cars With Just a License Plate Sam Curry nos hablan del caso del conocido fabricante Kia y una serie de fallos que permitirían a un atacante controlar algunas funciones importantes del vehículo conociendo su matrícula.

… a set of vulnerabilities in Kia vehicles that allowed remote control over key functions using only a license plate.

Esto incluía, claro, obtener información personal:

Additionally, an attacker could silently obtain personal information, including the victim’s name, phone number, email address, and physical address.

La cuestión es que con instrucciones y métodos muy sencillos era posible realizar los ataques porque casi todo parece estar mal: un identificador que es fácil de conocer, pero también otros fallos de acceso a los sistemas que realizaban las acciones. En el artículo se detallan las ideas principales.

Llevamos mucho tiempo (tal vez demasiado) en el que hacer programas inseguros no era algo que preocupara mucho a nadie. Desde hace algún tiempo venimos escuchando llamadas a la responsabilidad, regulaciones y tímidas amenazas para mejorar el tema. En CISA boss: Makers of insecure software must stop enabling today’s cyber villains Jen Easterly, directora de la Cybersecurity and Infrastructure Security Agency (CISA) de los EEUU ha ido un poco más allá, diciendo que los vendedores son los que están creando problemas, abriendo la puerta a los malos para atacar a sus víctimas.

“The truth is: Technology vendors are the characters who are building problems” into their products, which then “open the doors for villains to attack their victims,” declared Easterly during a Wednesday keynote address at Mandiant’s mWise conference.

Ya puestos, se quejaba también de darles nombres ‘molones’ a los grupos criminales, dándoles aspectos ‘glamourosos’.

Easterly also implored the audience to stop “glamorizing” crime gangs with fancy poetic names. How about “Scrawny Nuisance” or “Evil Ferret,” Easterly suggested.

Y no sólo eso, porque también afirmaba que el nombre de vulnerabilidades de los programas (software vulnerabilities) contribuía a difuminar la responsabilidad y que deberían llamarse defectos de los productos (product defects). No se trata de señalar las víctimas por no actualizar, sino a los autores por desarrollar productos que requieren esas actualizaciones Ya puestos, se quejaba también de darles nombres ‘molones’ a los grupos criminales, dándoles aspectos ‘glamourosos’.

Easterly also implored the audience to stop “glamorizing” crime gangs with fancy poetic names. How about “Scrawny Nuisance” or “Evil Ferret,” Easterly suggested.

Y no sólo eso, porque también afirmaba que el nombre de vulnerabilidades de los programas (software vulnerabilities) contribuía a difuminar la responsabilidad y que deberían llamarse defectos de los productos (product defects). No se trata de señalar las víctimas por no actualizar, sino a los autores por desarrollar productos que requieren esas actualizaciones.

Even calling security holes “software vulnerabilities” is too lenient, she added. This phrase “really diffuses responsibility. We should call them ‘product defects,’” Easterly said. And instead of automatically blaming victims for failing to patch their products quickly enough, “why don’t we ask: Why does software require so many urgent patches? The truth is: We need to demand more of technology vendors.”

Muy interesante.

Modestamente, ese mensaje también lo decíamos en En las Mesas de Debate AICAR ADICAE sobre ciberseguridad , aunque creo que es un mensaje que hay que trasladar cuidadosamente en determinados sitios porque hay gente que tiene comportamientos casi ‘suicidas’ y no deberíamos formentar tampoco eso.

Cuando debemos proteger un sistema normalmente tenemos que decidir a qué prestaremos atención primero. Luego, en qué punto debemos parar porque ya estamos razonablemente protegidos. Sin embargo, son decisiones que no son tan sencillas y en los que las reglas habituales para otros asuntos no siempre tienen sentido. En Why the 80-20 rule no longer works for cybersecurity hablaban justamente de eso.

El principio de Parto nos dice que aproximandamente el 80% de las consecuencias provienen del 20% de los motivos posibles, y esta es una regla que se utiliza en productividad, ventas, aseguramiento de la calidad y gestión de proyectos.

COMMENTARY: We’ve all heard about the Pareto Principle, the idea that approximately 80% of consequences result from 20% of causes. Organizations have long applied this “80-20 rule” to areas such as productivity, sales, quality assurance, and project management.

Esto también sucede en ciberseguridad, afirmando que con vigilar el 80% de los activos puede mitigar el riesgo. En algunos casos, incluso vigilando menos (pero los más importantes) puede ser suficiente:

Cybersecurity is no exception. Over the last 25 years, cybersecurity leaders have leveraged this principle to manage and secure assets, asserting that adequately monitoring 80% of assets can effectively mitigate risks. Some have gone as far as to believe that closely monitoring the crown jewel assets alone, even if they constitute just 1% of the total exposure, might be “good enough.”

Pero claro, la naturaleza de los ataques es tan variada y diversa que descuidar una parte puede ser justo lo que abra la puerta a nuestros problemas.

What does that unexamined 20% mean for these organizations? Most of the risk now gets concentrated in that bracket, which now contains the most attractive and exploitable assets for attackers.

Así que nos toca trabajar un poco más y estar atentos a todo lo que puede pasar, porque los problemas pueden venir por donde menos los esperemos.

Invest in the means to close the coverage gap now to future-proof the organization’s security strategy for the coming years. Leave the 80-20 rule behind.

En este sitio no hemos ido celebrando aniversarios ni nada de eso.Por este mismo motivo no era consciente del tiempo que llevamos aquí, el 6 de noviembre cumplimos diez añazos, así que he pensado que podríamos reflejarlo aquí.

Ni siquiera estamos muy seguros de que alguien lea, como para pensar en los aniversarios. Seguimos, en todo caso, en el espíritu de que al autor le sirve para leer, anotar, comentar…

Todo ha sido al actualizar un poco la plantilla (aprovechando que he tenido algunas sesiones sobre la web he repasado html y esas cosas) y cuando me puse con este sitio me di cuenta casualmente del detalle.