18/09/2018, 10:05

5 Nguyên tắc cơ bản việc công bố lỗ hổng bảo mật

Đâ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? Tiết lộ lỗ hổng là hoạt động khó khăn nhất với các nhà cung cấp phần mềm/phần cứng. Ngược lại, nhận được thông báo lỗ hổng từ bất kì nhà cung cấp nào cũng là vấn đề gây khó chịu với các tổ chức gặp phải. Các bản vá nhanh ...

Đâ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?

Tiết lộ lỗ hổng là hoạt động khó khăn nhất với các nhà cung cấp phần mềm/phần cứng. Ngược lại, nhận được thông báo lỗ hổng từ bất kì nhà cung cấp nào cũng là vấn đề gây khó chịu với các tổ chức gặp phải. Các bản vá nhanh chóng và bất ngờ sẽ làm gián đoạn hoạt động lớn.

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:

5 Nguyên tắc cơ bản trong tiết lộ lỗ hổng

Như bảng trên, mức điểm CVSS thấp và trung bình là lỗ hổng không có thông tin cố vấn và được sửa chữa. Cách tiếp cận này cho phép nhà cung cấp/dự án mã nguồn mở tập trung tìm kiếm vấn đề bảo mật nhưng không tiết lộ mọi lỗ hổng.

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?

Sự thực đối với các phần mềm có hiệu quả cao trong việc hướng tới cộng đồng lớn và sẵn sàng chào đón bên thứ ba tìm kiếm lỗ hổng sẽ luôn vững mạnh. Lỗ hổng luôn xảy ra. Thật ngu ngốc và nguy hiểm nếu nghĩ rằng che dấu lỗ hổng sẽ tốt cho khách hàng. Nếu đối xử không tốt với người tìm ra lỗ hổng và coi họ là tin tặc, rất có thể họ sẽ bán khai thác cho tin tặc, các tổ chức chính phủ hoặc các nhân tố đe dọa khác như một khai thác “zero-day”.

NGUYÊN TẮC #5 – Cởi mở với quy trình tiết lộ lỗ hổng bảo mật

Niềm tin là yếu tố cực kì quan trọng trong quy trình tiết lộ lỗ hổng. Đã có rất nhiều nhà cung cấp xử lý sai lỗ hổng trong sản phẩm của họ và phá vỡ sự tin cậy với khách hàng. Bước đầu gây dựng niềm tin là viết ra quy trình tiết lộ lỗ hổng. Có thể đăng tải công khai chúng lên website của công ty. Cho phép mọi người đánh giá và có những bình luận hữu ích về quy trình. Tài liệu/xuất bản về quy trình tiết lộ lỗ hổng là một bước minh bạch trong gây dựng niềm tin. Quy trình không nhất thiết phải hoàn hảo. Quy trình không nhất thiết phải giống các nhà cung cấp khác. Nhưng nó cần được viết ra và sẵn sàng với những người có quyền lợi sử dụng sản phẩm của bạn.

0