He empezado a prestar más atención a cómo los proyectos de blockchain hablan sobre la seguridad.
Una larga lista de errores puede sonar impresionante en papel, pero el número en sí no me dice gran cosa.
Lo que encontré más interesante del trabajo de seguridad AEGIS de Dusk fue lo que ocurrió debajo de las cifras.
La auditoría produjo 39 hallazgos, incluidos 7 clasificados como críticos. Pero Dusk agrupó esos problemas críticos en cuatro causas raíz subyacentes en lugar de tratar cada hallazgo como un problema no relacionado.
Esa diferencia importa.
Si cinco problemas distintos provienen de la misma suposición, arreglar cinco síntomas no necesariamente hace que el sistema sea cinco veces más seguro.
Un ejemplo fue el clúster de tarifas/reembolsos de Phoenix. Una debilidad en la forma en que la información de la tarifa se vinculó a través de la generación de pruebas, el firmado y la ejecución creó múltiples resultados posibles, incluidos la redirección del reembolso, la inflación de la oferta e incluso una posible detención de la cadena.
Esa es la parte de la ingeniería de seguridad que me resulta fácil subestimar.
La pregunta importante no es solo “¿Cuántas vulnerabilidades se corrigieron?”.
Es “¿Qué suposición permitió que existieran desde el principio?”.
Para la infraestructura financiera, esa diferencia se vuelve aún más importante. Un parche puede cerrar una ruta de ataque hoy. Eliminar la suposición defectuosa subyacente puede prevenir toda una familia de problemas mañana.
Tal vez un proceso de seguridad sólido no se mide por lo pocos errores que tiene un sistema.
Tal vez se mide por qué tan profundamente el equipo entiende por qué esos errores eran posibles.
#dusk $DUSK @Dusk
Una larga lista de errores puede sonar impresionante en papel, pero el número en sí no me dice gran cosa.
Lo que encontré más interesante del trabajo de seguridad AEGIS de Dusk fue lo que ocurrió debajo de las cifras.
La auditoría produjo 39 hallazgos, incluidos 7 clasificados como críticos. Pero Dusk agrupó esos problemas críticos en cuatro causas raíz subyacentes en lugar de tratar cada hallazgo como un problema no relacionado.
Esa diferencia importa.
Si cinco problemas distintos provienen de la misma suposición, arreglar cinco síntomas no necesariamente hace que el sistema sea cinco veces más seguro.
Un ejemplo fue el clúster de tarifas/reembolsos de Phoenix. Una debilidad en la forma en que la información de la tarifa se vinculó a través de la generación de pruebas, el firmado y la ejecución creó múltiples resultados posibles, incluidos la redirección del reembolso, la inflación de la oferta e incluso una posible detención de la cadena.
Esa es la parte de la ingeniería de seguridad que me resulta fácil subestimar.
La pregunta importante no es solo “¿Cuántas vulnerabilidades se corrigieron?”.
Es “¿Qué suposición permitió que existieran desde el principio?”.
Para la infraestructura financiera, esa diferencia se vuelve aún más importante. Un parche puede cerrar una ruta de ataque hoy. Eliminar la suposición defectuosa subyacente puede prevenir toda una familia de problemas mañana.
Tal vez un proceso de seguridad sólido no se mide por lo pocos errores que tiene un sistema.
Tal vez se mide por qué tan profundamente el equipo entiende por qué esos errores eran posibles.
#dusk $DUSK @Dusk
