Durante los últimos días, me he encontrado volviendo una y otra vez a @Dusk . No porque las cosas que fácilmente llaman la atención, sino porque hay una parte más tranquila del proyecto que no deja de hacerme pensar.
Una cosa que valoro del incidente del 16 de agosto es lo rápido que reaccionó el equipo. Actuaron con rapidez para detener el flujo de fondos, reemplazar las direcciones afectadas y añadir las direcciones a la lista de bloqueo de la web wallet: un enfoque bastante familiar para gestionar las consecuencias de un incidente.
Había algo bastante interesante cuando revisé las nuevas direcciones después del incidente. En lugar de ver pequeñas transacciones usadas para sondear el sistema, casi todo permanecía completamente en silencio. Sin polvo, sin pruebas, sin señales de que alguien estuviera comprobando cómo respondería el sistema. Durante más de una semana, esas direcciones siguieron calladas mientras el puente permanecía desconectado.
Lo que más me llama la atención después del exploit no es necesariamente que ocurriera la vulnerabilidad, sino lo que #dusk decidió hacer después. Podrían haber restablecido el puente rápidamente para satisfacer la demanda de los usuarios, pero en cambio mantuvieron todo en pausa. Las nuevas direcciones no se tocaron. Nadie les obligó a esperar, y aun así eligieron la opción menos conveniente a cambio de otra capa de seguridad.
Honestamente, todavía no quiero etiquetar esto como una buena gestión del riesgo o simplemente como un proceso de recuperación lento. Quizá la respuesta esté en algún punto intermedio. Lo que se siente más seguro es que, tras el incidente, casi no hubo actividad adicional en la cadena—y ese silencio en sí mismo merece bastante la pena observarlo.
Me pregunto si alguien más está siguiendo estos datos: después de un incidente, ¿cuánto tiempo suele permanecer cada puente “en silencio” antes de volver realmente a estar en línea? Quizá ese periodo de silencio sea una de las formas más claras de ver cómo un equipo realmente aborda la gestión del riesgo.$DUSK $BMT $FOREST
Una cosa que valoro del incidente del 16 de agosto es lo rápido que reaccionó el equipo. Actuaron con rapidez para detener el flujo de fondos, reemplazar las direcciones afectadas y añadir las direcciones a la lista de bloqueo de la web wallet: un enfoque bastante familiar para gestionar las consecuencias de un incidente.
Había algo bastante interesante cuando revisé las nuevas direcciones después del incidente. En lugar de ver pequeñas transacciones usadas para sondear el sistema, casi todo permanecía completamente en silencio. Sin polvo, sin pruebas, sin señales de que alguien estuviera comprobando cómo respondería el sistema. Durante más de una semana, esas direcciones siguieron calladas mientras el puente permanecía desconectado.
Lo que más me llama la atención después del exploit no es necesariamente que ocurriera la vulnerabilidad, sino lo que #dusk decidió hacer después. Podrían haber restablecido el puente rápidamente para satisfacer la demanda de los usuarios, pero en cambio mantuvieron todo en pausa. Las nuevas direcciones no se tocaron. Nadie les obligó a esperar, y aun así eligieron la opción menos conveniente a cambio de otra capa de seguridad.
Honestamente, todavía no quiero etiquetar esto como una buena gestión del riesgo o simplemente como un proceso de recuperación lento. Quizá la respuesta esté en algún punto intermedio. Lo que se siente más seguro es que, tras el incidente, casi no hubo actividad adicional en la cadena—y ese silencio en sí mismo merece bastante la pena observarlo.
Me pregunto si alguien más está siguiendo estos datos: después de un incidente, ¿cuánto tiempo suele permanecer cada puente “en silencio” antes de volver realmente a estar en línea? Quizá ese periodo de silencio sea una de las formas más claras de ver cómo un equipo realmente aborda la gestión del riesgo.$DUSK $BMT $FOREST
Infrastructure 🔧
0%
Privacy 🔐
100%
Scaling ⚡
0%
1 Votos • Votación cerrada