Se ha publicado Announcing the 2022 Accelerate State of DevOps Report: A deep dive into security.

Hemos hablado alguna vez de DevOps, de pasadada, la idea de ese conjunto de prácticas que aúnan el desarrollo de programas (Dev) y las operaciones relacionadas con ellos (Ops) con el objetivo de reducir el ciclo de ciclo de vida de los desarrollos informáticos.

El caso es que Google anda investigando estas prácticas, a través de encuestas para conocer las capacidades y prácticas alrededor de este concepto.

Over the past eight years, more than 33,000 professionals around the world have taken part in the Accelerate State of DevOps survey, making it the largest and longest-running research of its kind. Year after year, Accelerate State of DevOps Reports provide data-driven industry insights that examine the capabilities and practices that drive software delivery, as well as operational and organizational performance.

Pero hoy en día nadie habla en serio de desarrollo sin tener en cuenta la seguridad (que también sería una componente importante en el DevOps), y en la edición de este año profundizan en la cadena de suministro que ya lleva una temporada siendo un problema crítico.

To analyze the relationship between security and DevOps, we explored the topic of software supply chain security, which the survey only touched upon lightly in previous years.

Parece que el resultado es bueno, adoptando buenas prácticas, al menos de manera parcial.

Overall, we found surprisingly broad adoption of emerging security practices, with a majority of respondents reporting at least partial adoption of every practice we asked about.

Y, como suele pasar, los mejores suelen estar en ambientes con una cultura sana: confianza, y no penalizar los errores.

One thing we found surprising was that the biggest predictor of an organization’s software security practices was cultural, not technical: high-trust, low-blame cultures.

Con algunas ventajas añadidas como es reducir el estrés y fatiga de los desarrolladores y convertirse en lugares más atractivos para otras personas.

Not only that, survey results indicate that teams who focus on establishing these security practices have reduced developer burnout and are more likely to recommend their team to someone else.

Ya hemos contado muchos métodos para extraer información de equipos aprovechando la propia actividad de los mismos. En esa línea, pero sin sacar más información que las contraseñas, traemos hoy Recovering Passwords by Measuring Residual Heat.

Se trata de obtener imágenes térmicas de teclados y ver lo que se tecleó allí, en particular, las contraseñas.

Our first study shows that ThermoSecure successfully attacks 6-symbol, 8-symbol, 12-symbol, and 16-symbol passwords with an average accuracy of 92%, 80%, 71%, and 55% respectively, and even higher accuracy when thermal images are taken within 30 seconds.

En este caso el tiempo es importante, porque los teclados van perdiendo ese calor residual. Como dice Schneier, si alguien puede entrenar una cámara con nuestro teclado, seguramente tenemos problemas más graves.

Curioso.

Hoy traemos un tema algo menos técnico. Por cierto, que me parece que el sitio del que lo traemos últimamente ha bajado mucho el nivel de los artículos y ha perdido parte del interés que tenía. Pero aún podemos sacar alguna noticia. Podríamos decir que vivimos en una época de escalada ‘armamentística’: se van añadiendo recursos y herramientas a los que ya teníamos para tratar de aligerar el problema del fraude, donde los ‘malos’ son cada vez más eficientes buscando las debilidades y los defensores hacen lo que pueden, teniendo en cuenta que tienen en su lado al eslabón más débil de la cadena, que es el usuario en la mayoría de las ocasiones.

En 2FA is over. Long live 3FA! se hacen eco del creciente número de ataques y mecanismos que se están utilizando para atacar a los usuarios y los sistemas de identificación de doble factor (ya saben, además de la consabida contraseña, algo más que ayude a aligerar el problema de la autentificación. Ahora que ya casi estábamos convencidos de que era el camino a seguir.

In the past few months, we’ve seen an unprecedented number of identity theft attacks targeting accounts protected by two-factor authentication (2FA), challenging the perception that existing 2FA solutions provide adequate protection against identity theft attacks.

El problema, claro, es que casi siempre el segundo factor utiliza mecanismos que no son mucho más fuertes que la contraseña, y eso es un problema.

he problem with this type of second factor is that it is not necessarily stronger than a password; it is only timelier.

Esencialmente se utilizan dos tipos de ataques:

• Por un lado, mecanismos de ‘adversario en medio’ adversary-in-the-middle (AiTM), que tratan de obtener esos segundos factores iniciando ellos la actividad en nombre del usuario y haciéndole creer que ese código deben ponerlo en un sitio controlado por el atacante.

AiTM is a technique used by attackers for doing phishing attacks via a proxy. Rather than harvesting passwords and trying to use them later, the attackers proxy the attempted login of the user, including the second authentication factor (whether it is an OTP or MFA push), and create a new session for the attacker, in real time, that is then used for future access.

• Por el otro, lo que llaman fatiga multifactor, que trata de hacer llegar tantas peticiones de validación del segundo factor que el usuario baje la guardia y sea más fácil hacerle aceptar alguna de las que reciba.

The attacker then starts attempting to log in with the stolen credentials. Every time the attacker does so, the user gets a push notification on their app asking them to verify the authentication.

La propuesta sería añadir un factor más, fuera del alcance de un posible atacante, y típicamente ligados a dispositivos concretos.

The solution is to embrace MFA more broadly, moving to three-factor authentication (3FA) by adding an additional factor, but this time one that cannot be used by the attacker to authenticate from a foreign device. This can be done by tying the user authentication to a specific device or hardware token.

No sé yo…

Este sitio comenzó gracias al sistema de Páginas de GitHub con Jekyll (Cuarta etapa. Elegirmos en su momento Jekyll-now que nos permitía iniciar la página con comodidad. El proyecto está abandonado desde 2018 (y entonces sólo hubo pequeños cambios), así que había llegado el momento de buscar alternativas.

Hemos sido poco creativos porque descubrimos un proyecto ‘heredero’, Forever Jekyll que nos trae una actualización del tema-plantilla original y que podía darnos menos miedo a la hora de hacer el cambio.

El cambio lo hicimos en la página de GitHub de este sitio: fernand0.github.io. Tal vez haya una forma más ‘civilizada’ de hacerlo, pero esta me funcionó sin mucha dificultad. Recomiendo haber preparado los cambios que vayamos a relizar para que el sitio esté desaparecido el menor tiempo posible:

1. Eliminamos la página vieja, cambiándole el nombre (en este momento el sitio deja de estar disponible, cuidado).
2. Hacemos un fork del proyecto que vamos a usar.
3. Lo descargamos en nuestro sitio: git clone https://github.com/fernand0/fernand0.github.io.git
4. Actualizamos las personalizaciones que podamos necesitar (mejor tenerlas ya preparadas, porque si no el sitio estará desaparecido mientras realizamos el proceso).
5. Copiar las entradas que teníamos a _posts.
6. Hacer commit de los cambios y subirlos (git push).
7. ¡Ya está!

¿Qué hemos ganado con el cambio?

El aspecto parece un poco más moderno, las categorías vuelven a funcionar (y copiando el código tenemos también etiquetas; en realidad las etiquetas y las categorías se tratan de la misma forma, pero son páginas diferentes). Hay un buscador, que parece que funciona bastante bien buscando las entradas que contienen la palabras que introducimos. También tenemos iconos sociales modernizados (utilizando font awesome), entradas relacionadas para cada una de ellas. Aparecen los botones de compartir (no sé si los dejaremos, mi experiencia es que luego la gente los usamos poco). Son botones con imágenes locales, así que no hacen de espías de nuestra navegación para las distintas redes. Finalmente (hay más cosas, sólo señalo las que me llaman más la atención), un modo oscuro (pulsando el botoncito de abajo a la derecha).

Todavía faltan algunos ajustes y veremos si introducimos algún cambio más, pero ha sido mucho menos ‘doloroso’ de lo que pensábamos.

De vez en cuando vemos multas millonarias y la exposición en público de las empresas que no cumplen con sus clientes, pero algo que se da casi por supuesto es que nadie tiene problemas legales de manera personal por la ciberseguridad. Mucho menos por no hablar de los problemas de ciberseguridad de tu empresa. Sin embargo, parece que esto está cambiando y podemos leer en Former Chief Security Officer Of Uber Convicted Of Federal Charges For Covering Up Data Breach Involving Millions Of Uber User Records el caso de un juez federal en EEUU que declaró culpable de obstrucción a la ley a Joseph Sullivan por ocultar una brecha de seguridad que provocó la divulgación de datos de sus clientes.

Sullivan affirmatively worked to hide the data breach from the Federal Trade Commission and took steps to prevent the hackers from being caught. We will not tolerate concealment of important information from the public by corporate executives more interested in protecting their reputation and that of their employers than in protecting users. Where such conduct violates the federal law, it will be prosecuted.”

El caso es que no sólo hubo problemas de seguridad que afectaron a los datos de los clientes, sino que también hubo esfuerzos para ocultar estos problemas a la comisión de comercio, que vela por estos asuntos allá.