Đâu là thời điểm thích hợp nhất cho các công ty tiết lộ một lỗ hổng bảo mật?
Những điều được nêu ra dưới đây là một vài nguyên tắc dành cho bất kì nhà cung cấp và dự án mã nguồn mở nào mới tiếp cận việc tiết lộ lỗ hổng. Nhà cung cấp/Dự án mã nguồn mở nên làm mọi thứ để giảm thiểu lỗ hổng trong sản phẩm của mình. Nhưng sự thật là không có gì hoàn hảo. Mọi điều có thể xảy ra và lỗ hổng là một điều hiển nhiên trong cuộc sống. Đây là lúc một quy trình tiết lộ lỗ hổng minh bạch và logic cần được rõ ràng với tất cả mọi người – giảm thiểu rủi ro và triển khai bản vá càng nhanh càng tốt.
NGUYÊN TẮC #1 – Luôn công bố tiết lộ đầy đủ về bất kì lỗ hổng nào đã được xác định có khai thác đang xảy ra.
Lỗ hổng đang được sử dụng bởi tin tặc, tổ chức chính phủ, hoặc các nhân tố đe dọa khác cần được tiết lộ công khai càng sớm càng tốt … thậm chí ngay cả khi chưa có bản vá. Đây không phải về danh hiệu hay danh tiếng của tổ chức. Nó thuộc về ý thức đạo đức, trách nhiệm pháp lý và sự an toàn chung. Lỗ hổng ngày không còn giống như bug hồi Windows 98. Nguyên tắc tiết lộ lỗ hổng khi các nhận có khai thác đang hoạt động nên được áp dụng với tất cả các nhà cung cấp. Những gì tiết lộ là một cố vấn lỗ hổng với những thông tin hiện có. Các phiên bản cố vấn mới sẽ được thường xuyên đăng tải khi thông tin mới được cập nhật, cách khắc phục được phê chuẩn và xác nhận bản vá sẽ được tung ra.NGUYÊN TẮC #2 – Không công bố tất cả lỗ hổng bảo mật
Điều này có thể gây sốc với một số người. Với những ai đã xây dựng và điều hành một quy trình phát triển bảo mật thì điều này cũng không phải mới. Các công ty bảo mật biết rằng có rất nhiều vấn đề bảo mật tiềm năng được tìm thấy và sửa chữa dựa trên kiểm thử của riêng họ. Và đa phần không tiết lộ với khách hàng. Công bố tất cả các lỗ hổng nhỏ sẽ làm giảm khả năng tập trung của khách hàng. Họ sẽ bị sao lãng khi xảy ra lỗ hổng lớn cần thực hiện các biện pháp ngay lập tức. Và quãng thời gian không thực hiện biện pháp cần thiết sẽ gây nguy hiểm cho khách hàng.Các nhà cung cấp có thể làm gì để đánh giá tất cả lỗ hổng? May mắn là chúng ta có một hệ thống đánh giá lỗ hổng Common Vulnerability Scoring System (CVSS). Nếu bạn nghĩ rằng bug có thể đã bị khai thác thì nên thực hiện đối chiếu CVSS để đánh giá bug đó.
Ví dụ, tổ chức Internet Systems Consortium (ISC) sử dụng CVSS để đánh giá lỗ hổng với mức thang điểm như sau:
NGUYÊN TẮC #3 – Giảm thiểu gián đoạn hoạt động
Tất cả tiết lộ lỗ hổng sẽ gây ra một vài kiểu gián đoạn hoạt động. Mạng và hệ thống sẽ cần được nâng cấp nhằm khắc phục sự cố. Nhà cung cấp/dự án mã nguồn mở cần lưu tấm vấn đề này và thực hiện biện pháp giảm thiểu gián đoạn. Không khách hàng nào muốn bỏ toàn bộ kế hoạch để sửa chữa lỗ hổng hoặc bị thúc giục nâng cấp bản vá. Dưới đây là một vài quy tắc chung:Nguyên tắc chung của giảm thiểu gián đoạn hoạt động là tìm thời điểm mạng/hệ thống “đóng máy”. Khi “đóng máy” được thực hiện sẽ không có sự tác động của con người trong quá trình khắc phục lỗ hổng (nên nhớ – con người là nguyên nhân số một gây ra sự cố mạng/hệ thống). Đôi khi thời điểm đóng máy có thể trùng với kì nghỉ hoặc sau thời điểm hoàn thành đơn hàng… Thời điểm tránh tiết lộ các lỗ hổng lớn bao gồm:
- Trong tháng 12 (kì nghỉ và mùa mua sắm)
- Trong tết Âm Lịch
- Trong lễ Ramadan của người Hồi Giáo
- Trong tháng 6 (nghỉ hè hoặc kết thúc năm tài chính)
- Tháng 8 tại các nước châu Âu với kì nghỉ hè
- Các thời điểm cố định mà một vài công ty có bản vá định kì hàng tháng như “patch Tuesdays” hoặc “patch Wednesdays”
NGUYÊN TẮC #4 – Dựa trên thực tế, thời điểm tiết lộ phụ thuộc vào các sự kiện bên ngoài
Nếu bạn tìm ra một lỗ hổng với đội ngũ của mình, bạn sẽ có thoải mái thời gian để sửa chữa và tiết lộ. Nhưng nhiều khi lịch trình của lỗ hổng sẽ phụ thuộc vào yếu tố bên ngoài. Các nhà nghiên cứu thường báo cáo lỗ hổng và nói rằng sẽ công bố tại một hội nghị bảo mật nào đó. Một vài trung tâm ứng cứu sự cố quốc gia cũng có cơ chế thời gian cụ thể nhằm đảm bảo các nhà cung cấp không giữ lỗ hổng cho riêng mình.Khi các “nhân tố bên ngoài” xảy ra, các nhà cung cấp/dự án mã nguồn mở cần thiết phải đàm phán một lịch trình hợp lí để triển khai bản sửa chữa càng sớm càng tốt cùng với giảm thiểu gián đoạn hoạt động. Đàm phán sẽ hữu ích nếu nhà cung cấp/dự án mã nguồn mở có một chính sách thân thiện với báo cáo lỗ hổng. Ví dụ:
- Nhà cung cấp có tạo ra thoải mái cho người báo cáo lỗ hổng? Ví dụ khi truy cập vào trang “/security” hoặc“/about” ( như www.example.com/security) có chứa hướng dẫn báo cáo lỗ hổng hay không?
- Nhà cung cấp có sẵn sàng chào đón và biết ơn người tìm ra lỗ hổng hay không?
- Nhà cung cấp có công nhận người tìm ra lỗ hổng trong tiết lộ lỗ hổng hay không? – Đưa tên và cảm ơn người tìm ra lỗ hổng sẽ tại ra thiện cảm lớn giữa nhà cung cấp và cộng đồng nói chung.
- Nhà cung cấp có sử dụng chương trình bug bounty để trao thưởng cho người tim ra lỗ hổng hay không?
- …
EmoticonEmoticon