Saya mulai memberi perhatian lebih pada cara proyek-proyek blockchain membahas keamanan.
Daftar panjang bug bisa terdengar mengesankan di atas kertas, tetapi angka itu sendiri tidak memberi saya banyak informasi.
Yang lebih menarik dari kerja keamanan AEGIS milik Dusk adalah apa yang terjadi di balik angka-angka tersebut.
Audit menghasilkan 39 temuan, termasuk 7 yang diklasifikasikan sebagai kritis. Namun Dusk mengelompokkan isu-isu kritis itu ke dalam empat akar masalah yang mendasari, alih-alih memperlakukan setiap temuan sebagai masalah yang tidak terkait.
Pembedaan itu penting.
Jika lima masalah berbeda muncul dari asumsi yang sama, memperbaiki lima gejala tidak selalu membuat sistem menjadi lima kali lebih aman.
Salah satu contohnya adalah klaster biaya/pengembalian (fee/refund) Phoenix. Kelemahan dalam cara informasi biaya diikat di seluruh pembuatan bukti (proof), penandatanganan, dan eksekusi menciptakan beberapa kemungkinan hasil, termasuk pengalihan pengembalian dana, inflasi pasokan, bahkan potensi penghentian rantai.
Itulah bagian dari rekayasa keamanan yang menurut saya mudah untuk diremehkan.
Pertanyaan pentingnya bukan hanya “Berapa banyak kerentanan yang diperbaiki?”
Melainkan “Asumsi apa yang memungkinkan semuanya itu ada sejak awal?”
Untuk infrastruktur keuangan, perbedaan itu bahkan menjadi lebih penting. Sebuah patch bisa menutup jalur serangan hari ini. Menghapus asumsi yang mendasari dan keliru dapat mencegah seluruh keluarga masalah besok.
Mungkin proses keamanan yang kuat tidak diukur dari seberapa sedikit bug yang dimiliki sebuah sistem.
Mungkin proses itu diukur dari seberapa dalam tim memahami mengapa bug-bug itu bisa terjadi.
#dusk $DUSK @Dusk
Daftar panjang bug bisa terdengar mengesankan di atas kertas, tetapi angka itu sendiri tidak memberi saya banyak informasi.
Yang lebih menarik dari kerja keamanan AEGIS milik Dusk adalah apa yang terjadi di balik angka-angka tersebut.
Audit menghasilkan 39 temuan, termasuk 7 yang diklasifikasikan sebagai kritis. Namun Dusk mengelompokkan isu-isu kritis itu ke dalam empat akar masalah yang mendasari, alih-alih memperlakukan setiap temuan sebagai masalah yang tidak terkait.
Pembedaan itu penting.
Jika lima masalah berbeda muncul dari asumsi yang sama, memperbaiki lima gejala tidak selalu membuat sistem menjadi lima kali lebih aman.
Salah satu contohnya adalah klaster biaya/pengembalian (fee/refund) Phoenix. Kelemahan dalam cara informasi biaya diikat di seluruh pembuatan bukti (proof), penandatanganan, dan eksekusi menciptakan beberapa kemungkinan hasil, termasuk pengalihan pengembalian dana, inflasi pasokan, bahkan potensi penghentian rantai.
Itulah bagian dari rekayasa keamanan yang menurut saya mudah untuk diremehkan.
Pertanyaan pentingnya bukan hanya “Berapa banyak kerentanan yang diperbaiki?”
Melainkan “Asumsi apa yang memungkinkan semuanya itu ada sejak awal?”
Untuk infrastruktur keuangan, perbedaan itu bahkan menjadi lebih penting. Sebuah patch bisa menutup jalur serangan hari ini. Menghapus asumsi yang mendasari dan keliru dapat mencegah seluruh keluarga masalah besok.
Mungkin proses keamanan yang kuat tidak diukur dari seberapa sedikit bug yang dimiliki sebuah sistem.
Mungkin proses itu diukur dari seberapa dalam tim memahami mengapa bug-bug itu bisa terjadi.
#dusk $DUSK @Dusk
