Ich habe damit begonnen, mehr darauf zu achten, wie Blockchain-Projekte über Sicherheit sprechen.
Eine lange Liste von Bugs kann auf Papier beeindruckend wirken, aber die Zahl selbst sagt mir nicht viel.
Was ich an Dusk’ AEGIS-Sicherheitsarbeit spannender fand, war, was unter den Zahlen passiert ist.
Das Audit brachte 39 Findings hervor, darunter 7, die als kritisch eingestuft wurden. Aber Dusk hat diese kritischen Probleme in vier zugrunde liegende Ursachen eingeordnet – statt jedes Finding als ein unabhängiges Problem zu behandeln.
Dieser Unterschied ist wichtig.
Wenn fünf unterschiedliche Probleme von derselben Annahme herrühren, macht das Beheben von fünf Symptomen das System nicht zwangsläufig fünfmal sicherer.
Ein Beispiel war der Phoenix-Gebühren-/Refund-Cluster. Eine Schwäche darin, wie Gebührendaten über die Proof-Erstellung, das Signieren und die Ausführung gebunden wurden, erzeugte mehrere mögliche Ergebnisse – darunter eine Umleitung von Refunds, eine Aufblähung der Supply und sogar ein potenzielles Ketten-Halten.
Das ist der Teil der Security Engineering, den ich leicht unterschätze.
Die wichtige Frage ist nicht nur „Wie viele Schwachstellen wurden behoben?“
Sondern: „Welche Annahme hat es ihnen überhaupt ermöglicht, zu existieren?“
Für finanzielle Infrastruktur wird dieser Unterschied noch wichtiger. Ein Patch kann heute einen Angriffsweg schließen. Das Entfernen der zugrunde liegenden fehlerhaften Annahme kann verhindern, dass morgen eine ganze Familie von Problemen entsteht.
Vielleicht wird ein starker Sicherheitsprozess nicht daran gemessen, wie wenige Bugs ein System hat.
Vielleicht misst man ihn daran, wie tief das Team versteht, warum diese Bugs überhaupt möglich waren.
#dusk $DUSK @Dusk
Eine lange Liste von Bugs kann auf Papier beeindruckend wirken, aber die Zahl selbst sagt mir nicht viel.
Was ich an Dusk’ AEGIS-Sicherheitsarbeit spannender fand, war, was unter den Zahlen passiert ist.
Das Audit brachte 39 Findings hervor, darunter 7, die als kritisch eingestuft wurden. Aber Dusk hat diese kritischen Probleme in vier zugrunde liegende Ursachen eingeordnet – statt jedes Finding als ein unabhängiges Problem zu behandeln.
Dieser Unterschied ist wichtig.
Wenn fünf unterschiedliche Probleme von derselben Annahme herrühren, macht das Beheben von fünf Symptomen das System nicht zwangsläufig fünfmal sicherer.
Ein Beispiel war der Phoenix-Gebühren-/Refund-Cluster. Eine Schwäche darin, wie Gebührendaten über die Proof-Erstellung, das Signieren und die Ausführung gebunden wurden, erzeugte mehrere mögliche Ergebnisse – darunter eine Umleitung von Refunds, eine Aufblähung der Supply und sogar ein potenzielles Ketten-Halten.
Das ist der Teil der Security Engineering, den ich leicht unterschätze.
Die wichtige Frage ist nicht nur „Wie viele Schwachstellen wurden behoben?“
Sondern: „Welche Annahme hat es ihnen überhaupt ermöglicht, zu existieren?“
Für finanzielle Infrastruktur wird dieser Unterschied noch wichtiger. Ein Patch kann heute einen Angriffsweg schließen. Das Entfernen der zugrunde liegenden fehlerhaften Annahme kann verhindern, dass morgen eine ganze Familie von Problemen entsteht.
Vielleicht wird ein starker Sicherheitsprozess nicht daran gemessen, wie wenige Bugs ein System hat.
Vielleicht misst man ihn daran, wie tief das Team versteht, warum diese Bugs überhaupt möglich waren.
#dusk $DUSK @Dusk
