Mantengo la idea de que en un mundo en el que poca gente presta atención a la seguridad, parece que las únicas medidas que puedan ayudarnos un poco son las leyes. No lo digo solo yo, utilizo de vez en cuando un artículo de Bruce Schenier en el que hablaba del tema, Why Was SolarWinds So Vulnerable to a Hack? y me gusta citar un par de párrafos completos sobre el tema (los pongo al final).

El caso es que con las leyes, el cumplimiento y los procedimientos puede ocurrirnos que sigamos perdiendo de vista el objetivo, que es estar más seguros. De eso hablaban en Is the cybersecurity community’s obsession with compliance counter-productive?.

El ejemplo con el que empieza es ilustrativo: ¿alguien cree que en caso de accidente de nuestro avión tenemos más probabilidades de sobrevivir si las mesitas están correctamente plegadas y las maletas de mano están adecuadamente posicionadas en su lugar?

Does anyone think the chances of surviving a plane crash increase if our tray tables are locked and our carry-on bags are completely stowed under our seats?

Pero alguien lo indicó en alguna regulación y a nadie se le pasaría por la cabeza saltarse ese procedimiento.

Luego nos dice: casi todos los problemas de seguridad que aparecen en las empresas tienen que ver con vulnerabilidades no solucionadas, robo de credenciales y por ataques de programas maliciosos (que entran típicamente a través del phishing).

Esto no tiene mucho que ver con la normativa y, a lo mejor, centrarse en ella nos resta tiempo y personas para dedicarse a lo importante.

And how many would deploy those compliance and auditing resources to patch more vulnerabilities, invest in additional cybersecurity expertise, tools to identify and reduce their external threat footprint, and myriad other effective measures to genuinely reduce their organization’s cyber risk?

Luego reconoce que, seguramente, la gente de ciberseguridad sigue ese camino porque les permite tener las espaldas cubiertas.

The less obvious reason for our community’s love for compliance is that it covers behinds. “Yes, we were breached, but we did everything we were supposed to do, so don’t blame us.”

Pudiendo estar de acuerdo en la gestión de recursos creo que el autor pierde de vista que hay un número grandísimo de organizaciones que dedican cero recursos a la ciberseguridad. Así que, a lo mejor, poner leyes es una forma de obligarles a pensar en ella. En un mundo ideal todo el mundo haría su trabajo y, efectivamente, a lo mejor cada quien debería poder elegir a qué destina sus recursos. Pero el mundo no es así, lamentablemente.

Los párrafos de los que hablaba arriba:

There are two problems to solve. The first is information asymmetry: Buyers can’t adequately judge the security of software products or company practices. The second is a perverse incentive structure: The market encourages companies to make decisions in their private interest, even if that imperils the broader interests of society. Together these two problems result in companies that save money by taking on greater risk and then pass off that risk to the rest of us, as individuals and as a nation.

The only way to force companies to provide safety and security features for customers and users is with government intervention. Companies need to pay the true costs of their insecurities, through a combination of laws, regulations and legal liability. Governments routinely legislate safety — pollution standards, automobile seatbelts, lead-free gasoline, food service regulations. We need to do the same with cybersecurity: The federal government should set minimum security standards for software and software development.

Uno se sorprende de que todavía sucedan estas cosas (bueno, en realidad no, porque pasan con mucha frecuencia) pero tenemos lo que tenemos. Proteger algunos sistemas tiene sus propias dificultades, porque a veces supone adaptar dispositivos físicos, como pueden ser las tarjetas, los lectores, y otras infraestructuras, en un sistema de transporte. En Teens Hacked Boston Subway Cards to Get Infinite Free Rides—and This Time, Nobody Got Sued hablan del caso del metro de Boston donde unos quinceañeros consiguieron replicar un suceso de hace 15 años donde unos estudiantes ya habían conseguido viajar de manera gratuita en el metro de Boston. Y es que la historia se repite y estos quinceañeros consiguieron reproducir el ataque y mejorarlo, incluyendo la posibilidad de añadir cualquier cantidad de dinero a sus tarjetas, transformarlas en tarjetas de estudiante con descuento o incluso en una tarjeta de empleado con, claro, viajes gratis.

So the four teens extended other research done by the 2008 hacker team to fully reverse engineer the CharlieCard, the RFID touchless smart cards the MBTA uses today. The hackers can now add any amount of money to one of these cards or invisibly designate it a discounted student card, a senior card, or even an MBTA employee card that gives unlimited free rides. “You name it, we can make it,” says Campbell.

En esta ocasión, y por diferenciarse de la anterior, no sólo no han intentado bloquear la difusión de la investigación, sino que les han invitado a las oficinas del mentro a explicar cómo lo habían hecho. También, eso sí, les han pedido que expliquen poco alguna parte delicada, para que no sea tan fácil de reproducir.

El truco parece basarse en el análisis de varias tarjetas para observar en qué se parecen y en qué se diferencian, y así descubrir qué cambiar y cómo.

Muy interesante.

Hay una cita por ahí que parece que dijo el informático Donal Knuth y que se suele escribir como: ‘la optimización prematura es el origen de todos los males’

premature optimization is the root of all evil

Bien entendido, claro, que se refería al contexto de la programación y el desarrollo de programas (aunque seguramente se pueda aplicar en más casos). Sin embargo, también es cierto que en algún momento hay que optimizar (sobre todo para programas o bibliotecas de uso amplio, donde una pequeña mejora puede hacer que nuestros programas sean mucho mejores).

El año pasado alguna gente de Google publicaron Faster sorting algorithms discovered using deep reinforcement learning donde se hace justamente eso: con aprendizaje reforzado profundo tratan de obtener versiones mejores de los algoritmos que se utilizan habitualmente.

El resultado es interesante, pero lo que más llamó mi atención (sobre todo porque lo contamos en clase, en una versión mucho más grosera y poco refinada) como el manejo de los problemas de tamaño más pequeño puede ser el que marque la diferencia. En este sentido, se pueden ver en el artículo análisis bastante refinados de código en c++, sus versiones en ensamblador y cómo algunas instrucciones pueden ser importantes a la hora de obtener soluciones eficientes.

Por ejemplo, en la figura 4 se puede ver cómo el algoritmo original proponía evaluar la longitud de lo que se quería ordenar y según fuera 2, 3, ó 4, se lanzaba un algoritmo diferente. La propuesta de AlphaDev, sin embargo, primero mira si el tamaño es 2 y lanza un algoritmo especializado, si no, lanza el algoritmo para ordenar 3 elementos; si la longitud ya era 3 el vector ya estará ordenado, y si no lo era, llama a un algoritmo especializado en ordenar 4 con los 3 primeros ya en orden.

A flow diagram of the variable sort 4 (VarSort4) human benchmark algorithm. In this algorithm, a sequence of unsorted numbers are input into the algorithm. If the sequence length is four, three or two numbers, then the corresponding sort 4, sort 3 or sort 2 sorting network is called that sorts the resulting sequence. The result is then returned and output by the function. b, The VarSort4 algorithm discovered by AlphaDev. This algorithm also receives sequences of length four, three or two numbers as input. In this case, if the length is two, then it calls the sort 2 sorting network and returns. If the length is three then it calls sort 3 to sort the first three numbers and returns. If, however, the length is greater than three, then it calls sort 3, followed by a simplified sort 4 routine that sorts the remaining unsorted number. It is this part of the routine that results in significant latency savings.

No sé si las palabras (o el gráfico) ayudan a entender bien de lo que estamos hablando pero, desde luego, nos dan una pista de cómo pequeños detalles pueden marcar una diferencia.

Se puede leer un texto de carácter más divulgativo en AlphaDev discovers faster sorting algorithms

La semana pasada decía que nadie lee esto y algunas personas me dijeron que sí (hasta alguna errata habían detectado). Reconforta mucho recibir esos comentarios y la realimentación, ¡Muchas gracias!

Programamos con un conjunto de suposiciones bastante básicas (acerca del sistema, el almacenamiento, la memoria, el procesador, …), pero a veces puede ser interesante conocer un poco mejor cómo funcionan las cosas para sacar partido (o no meter la pata) de lo que estemos usando.

Sobre la memoria podemos leer What every programmer should know about memory, Part 1 que ya tiene unos años, pero que nos puede dar pistas interesantes. Hay hasta nueve partes, que se pueden ver enlazadas al final del texto, justo antes de los comentarios (se echan de menos, ¿eh? Casi nadie los mantiene por la selva en que se ha convertido la red en algunos aspectos).

In the early days computers were much simpler. The various components of a system, such as the CPU, memory, mass storage, and network interfaces, were developed together and, as a result, were quite balanced in their performance. For example, the memory and network interfaces were not (much) faster than the CPU at providing data.

View post on imgur.com

Después de la calurosa recepción de los comentarios sobre artículos de investigación (es broma, creo que podría escribir al revés aquí y nadie diría nada) traemos otro que me resultó intersante: Password policies of most top websites fail to follow best practices.

Y es intersante, porque con todo lo que vamos sabiendo sobre las contraseñas, muchos sitios siguen usando políticas viejas, anticuadas y hasta desaconsejadas.

En el resumen nos dicen:

We examined the policies of 120 of the most popular websites for when a user creates a new password for their account. Despite well-established advice that has emerged from the research community, we found that only 13% of websites followed all relevant best practices in their password policies. Specifically, 75% of websites do not stop users from choosing the most common passwords—like “abc123456” and “P@$$w0rd”, while 45% burden users by requiring specific character classes in their passwords for minimal security benefit. We found low adoption of password strength meters—a widely touted intervention to encourage stronger passwords, appearing on only 19% of websites. Even among those sites, we found nearly half misusing them to steer users to include certain character classes, and not for their intended purpose of encouraging freely-constructed strong passwords.

De las buenas prácticas que se recomiendan habitualmente, nos dicen:

• La recomendación: Comprobar las contraseñas contra listas divulgadas y otras que son fáciles de adivinar.

El resultado: 71 de 120 sitios no comprueban la contraseña en absoluto, permitiendo 40 de las más frecuentes.

• La recomendación. Rechazar la contraseña si aparece en alguna de estas listas. El resultado: De los que las comprueban, 19 bloquean menos de la mitad de las listas de contraseñas comunes.

• La recomendación: proporcionar información en tiempo real sobre la estimación de complejidad de las contraseñas.

El resultado: Sólo 23 de los 120 sitios comprobados tenían medidor de la calidad.

• La recomendación: establecer un requisito de dificultad mínima mediante estimaciones de la ‘adivinabilidad’ de la clave.

El resultado: de los 23 anteriores, 10 utilizan medidores basados en el tipo de caracteres que se utililiza, sin prestar atención a nada más.

• La recomendación: no exigir clases especiales de caracteres; permitir a los usuarios construir sus contraseñas libremente.

El resultado: 54 de 120 sitios exigen el cumplimiento de reglas sobre los caracteres.

• La recomendación: establecer un mímino de al menos 8 caracteres (NIST).

El resultado: 66 de los 120 sitios exigen esa longitud, al menos.

Las conclusiones son:

• La política de contraseñas es teatro de seguridad (security theater)
• Los sitios han preferido pasar a otros métodos (como autentificación multifactor) para aliviar los problemas (con sus propias dificultades/debilidades).
• Los sitios necesitan pasar auditorías de seguridad, pero estas auditorías recomiendan a veces prácticas obsoletas.
• Los sitios tienen otras restricciones que tal vez expliquen estas malas prácticas.

Se puede descargar el artículo en [PDF] Password policies of most top websites fail to follow best practices, la [PDF] presentación de Password policies of most top websites fail to follow best practices y ver el vídeo en Password policies of most top websites fail to follow best practices.