Tôi bắt đầu chú ý nhiều hơn đến cách các dự án blockchain nói về bảo mật.
Một danh sách dài các lỗi có thể nghe ấn tượng trên giấy, nhưng con số đó không nói cho tôi biết nhiều.
Điều tôi thấy thú vị hơn trong công việc bảo mật của Dusk về AEGIS là những gì diễn ra bên dưới các con số.
Cuộc kiểm toán tạo ra 39 phát hiện, trong đó có 7 phát hiện được phân loại là mức độ nghiêm trọng. Nhưng Dusk đã nhóm các vấn đề nghiêm trọng đó thành bốn nguyên nhân gốc rễ tiềm ẩn thay vì xử lý từng phát hiện như một vấn đề độc lập.
Sự khác biệt này quan trọng.
Nếu năm vấn đề khác nhau đều xuất phát từ cùng một giả định, việc sửa năm triệu chứng không nhất thiết khiến hệ thống an toàn hơn gấp năm lần.
Một ví dụ là cụm phí/hoàn phí của Phoenix. Một điểm yếu trong cách thông tin phí được ràng buộc xuyên suốt quá trình tạo bằng chứng, ký và thực thi đã tạo ra nhiều kết quả có thể xảy ra, bao gồm chuyển hướng hoàn phí, thổi phồng cung và thậm chí là khả năng làm chuỗi bị dừng.
Đó là phần của kỹ thuật bảo mật mà tôi rất dễ đánh giá thấp.
Câu hỏi quan trọng không chỉ là “Có bao nhiêu lỗ hổng đã được khắc phục?”
Mà là: “Giả định nào đã cho phép chúng tồn tại ngay từ đầu?”
Với hạ tầng tài chính, sự khác biệt này còn quan trọng hơn. Một bản vá có thể đóng một lối tấn công ngay hôm nay. Loại bỏ giả định lỗi nền tảng có thể ngăn chặn cả một họ vấn đề vào ngày mai.
Có lẽ một quy trình bảo mật tốt không được đo bằng việc hệ thống có ít lỗi đến mức nào.
Có lẽ nó được đo bằng mức độ sâu sắc mà đội ngũ hiểu vì sao những lỗi đó có thể xảy ra.
#dusk $DUSK @Dusk
Một danh sách dài các lỗi có thể nghe ấn tượng trên giấy, nhưng con số đó không nói cho tôi biết nhiều.
Điều tôi thấy thú vị hơn trong công việc bảo mật của Dusk về AEGIS là những gì diễn ra bên dưới các con số.
Cuộc kiểm toán tạo ra 39 phát hiện, trong đó có 7 phát hiện được phân loại là mức độ nghiêm trọng. Nhưng Dusk đã nhóm các vấn đề nghiêm trọng đó thành bốn nguyên nhân gốc rễ tiềm ẩn thay vì xử lý từng phát hiện như một vấn đề độc lập.
Sự khác biệt này quan trọng.
Nếu năm vấn đề khác nhau đều xuất phát từ cùng một giả định, việc sửa năm triệu chứng không nhất thiết khiến hệ thống an toàn hơn gấp năm lần.
Một ví dụ là cụm phí/hoàn phí của Phoenix. Một điểm yếu trong cách thông tin phí được ràng buộc xuyên suốt quá trình tạo bằng chứng, ký và thực thi đã tạo ra nhiều kết quả có thể xảy ra, bao gồm chuyển hướng hoàn phí, thổi phồng cung và thậm chí là khả năng làm chuỗi bị dừng.
Đó là phần của kỹ thuật bảo mật mà tôi rất dễ đánh giá thấp.
Câu hỏi quan trọng không chỉ là “Có bao nhiêu lỗ hổng đã được khắc phục?”
Mà là: “Giả định nào đã cho phép chúng tồn tại ngay từ đầu?”
Với hạ tầng tài chính, sự khác biệt này còn quan trọng hơn. Một bản vá có thể đóng một lối tấn công ngay hôm nay. Loại bỏ giả định lỗi nền tảng có thể ngăn chặn cả một họ vấn đề vào ngày mai.
Có lẽ một quy trình bảo mật tốt không được đo bằng việc hệ thống có ít lỗi đến mức nào.
Có lẽ nó được đo bằng mức độ sâu sắc mà đội ngũ hiểu vì sao những lỗi đó có thể xảy ra.
#dusk $DUSK @Dusk
