Hablando de informes de auditoría, siempre he sentido que es uno de los mayores malentendidos en la industria de la encriptación: el check verde nunca equivale a “seguridad”, solo significa “no se cayó en el escenario de pruebas que diseñamos”. Las sandboxes de máquinas virtuales pueden eludirse, la lógica de deserialización puede dejar puertas traseras, el mecanismo de reembolso de comisiones puede tener fallos, y la verificación de firmas puede saltarse. Estos cuatro tipos de problemas están dispersos en distintos módulos, y eso por sí solo demuestra una cosa: no es que algún programador haya cometido un descuido, sino que el enfoque de seguridad, en puntos clave, tiene una ceguera sistemática. Cuando las instituciones de auditoría firman, ¿qué auditan? Auditan las rutas de ataque que ellos pueden imaginar; los hackers en la cadena siempre imaginarán rutas que el informe no contempla, por lo menos con una dimensión adicional.
La frase oficial “no se ha detectado que haya sido explotada” me la he oído tantas veces en años de gestión de riesgo que ya me rozan los oídos. El significado implícito de esa frase nunca ha sido “seguridad”, sino “aún no hemos visto evidencia”. Entre ambas cosas puede haber un periodo silencioso de explotación de meses, o también puede ser que el atacante ni pensaba hacer ruido, sino que simplemente encontró a otro comprador para monetizar. Cuántos proyectos han caído por esa frase: cuando la verdad sale a la luz, el dinero ya ha salido de la cadena y se ha blanqueado pasando por varias manos. La gente prudente jamás toma “no se ha” como una exención de responsabilidad.
Lo que esta vez me deja un poco más tranquilo es que el equipo eligió una reestructuración de raíz en lugar de “parchear para salir del paso”, y la ejecución mediante hard fork también estuvo bastante limpia y sin rodeos. Esto indica que el equipo, al menos, todavía tiene un sentido básico de responsabilidad de ingeniería, y no eligió cubrirlo para aguantar el golpe y pasar el mal momento. Pero la corrección de raíz resuelve estos problemas conocidos; la ruta de compatibilidad anterior, ¿se eliminó por completo?
¿Cuánto tiempo lleva corriendo la red principal? Y ya en la capa de ejecución central se expuso un fallo crítico. Este momento, de verdad, resulta especialmente llamativo. La ruta técnica, la sigo considerando adecuada: el rumbo hacia una arquitectura de privacidad y cumplimiento está bien. Pero que el rumbo sea correcto no significa que la madurez de la ingeniería esté a la altura; son dos cosas distintas. Mi postura actual es: extender la ventana de observación, frenar el ritmo de las posiciones. No voy a dar por bueno nada solo porque una respuesta haya sido rápida, y tampoco voy a negar por completo la lógica de largo plazo por un solo fallo. Una vez que la confianza se agrieta, reparar exige tiempo y una transparencia sostenida para irla reconstruyendo, y no se puede compensar con un anuncio.
¿Qué opinan ustedes sobre el nivel de este fallo? ¿Es una sacudida pasajera de la fase de ingeniería o hay una amenaza más profunda en el diseño de la arquitectura? Hablemos👇@Dusk $DUSK #dusk
La frase oficial “no se ha detectado que haya sido explotada” me la he oído tantas veces en años de gestión de riesgo que ya me rozan los oídos. El significado implícito de esa frase nunca ha sido “seguridad”, sino “aún no hemos visto evidencia”. Entre ambas cosas puede haber un periodo silencioso de explotación de meses, o también puede ser que el atacante ni pensaba hacer ruido, sino que simplemente encontró a otro comprador para monetizar. Cuántos proyectos han caído por esa frase: cuando la verdad sale a la luz, el dinero ya ha salido de la cadena y se ha blanqueado pasando por varias manos. La gente prudente jamás toma “no se ha” como una exención de responsabilidad.
Lo que esta vez me deja un poco más tranquilo es que el equipo eligió una reestructuración de raíz en lugar de “parchear para salir del paso”, y la ejecución mediante hard fork también estuvo bastante limpia y sin rodeos. Esto indica que el equipo, al menos, todavía tiene un sentido básico de responsabilidad de ingeniería, y no eligió cubrirlo para aguantar el golpe y pasar el mal momento. Pero la corrección de raíz resuelve estos problemas conocidos; la ruta de compatibilidad anterior, ¿se eliminó por completo?
¿Cuánto tiempo lleva corriendo la red principal? Y ya en la capa de ejecución central se expuso un fallo crítico. Este momento, de verdad, resulta especialmente llamativo. La ruta técnica, la sigo considerando adecuada: el rumbo hacia una arquitectura de privacidad y cumplimiento está bien. Pero que el rumbo sea correcto no significa que la madurez de la ingeniería esté a la altura; son dos cosas distintas. Mi postura actual es: extender la ventana de observación, frenar el ritmo de las posiciones. No voy a dar por bueno nada solo porque una respuesta haya sido rápida, y tampoco voy a negar por completo la lógica de largo plazo por un solo fallo. Una vez que la confianza se agrieta, reparar exige tiempo y una transparencia sostenida para irla reconstruyendo, y no se puede compensar con un anuncio.
¿Qué opinan ustedes sobre el nivel de este fallo? ¿Es una sacudida pasajera de la fase de ingeniería o hay una amenaza más profunda en el diseño de la arquitectura? Hablemos👇@Dusk $DUSK #dusk