Coordinated vulnerability disclosure

Công bố lỗ hổng bảo mật có phối hợp (CVD)

Cách báo cáo, tiếp nhận và phối hợp xử lý các lỗ hổng bảo mật, kèm chính sách mẫu.

Công bố lỗ hổng bảo mật có phối hợp (Coordinated vulnerability disclosure, CVD) là một thuật ngữ trong bảo mật máy tính. Nó mô tả cách mọi người có thể chia sẻ các báo cáo về vấn đề bảo mật. Ví dụ như báo cáo lỗi, nguy cơ xâm nhập, cảnh báo tấn công, rò rỉ dữ liệu, xâm phạm trang web, v.v.

Bản dịch: العربية, Български, বাংলা, Čeština, Cymraeg, Dansk, Deutsch, Ελληνικά, English, Español, Eesti, Euskara, فارسی, Suomi, Français, Gaeilge, Gàidhlig, ગુજરાતી, Hausa, עברית, हिन्दी, Hrvatski, Magyar, Bahasa Indonesia, Íslenska, Italiano, 日本語, 한국어, Lietuvių, Latviešu, Nederlands, Polski, Português, Română, Русский, Slovenčina, Slovenščina, Svenska, Kiswahili, ไทย, Türkçe, Українська, اردو, Tiếng Việt, 中文

Mục lục:

Chính sách:

Giới thiệu

Tài liệu này giải thích công bố lỗ hổng bảo mật có phối hợp theo những cách có thể giúp mọi người cùng làm việc với nhau.

Mục tiêu của tài liệu:

  1. Giúp những người phát hiện vấn đề bảo mật và muốn báo cáo chúng.

  2. Giúp đại diện của các công ty hiểu nhu cầu, mục tiêu, thông lệ và các trường hợp đặc biệt của công bố có trách nhiệm.

  3. Đưa các chính sách công bố lỗ hổng bảo mật có phối hợp mẫu vào thư mục của kho mã.

Chúng tôi hoan nghênh pull request, issue trên GitHub hoặc email gửi đến security@joelparkerhenderson.com.

Công bố lỗ hổng bảo mật có phối hợp là gì?

Công bố lỗ hổng bảo mật có phối hợp mô tả ba bước khi ai đó phát hiện một vấn đề bảo mật (chẳng hạn một lỗi phần mềm) và muốn báo cáo cho nhà sản xuất (chẳng hạn công ty tạo ra phần mềm đó).

Các bước:

  1. Người phát hiện báo cáo vấn đề một cách riêng tư và với thiện chí cho nhà sản xuất.

  2. Nhà sản xuất cố gắng bảo vệ người dùng với thiện chí và cố gắng giải quyết vấn đề.

  3. Sau một khoảng thời gian đã thỏa thuận, vấn đề bảo mật được công khai.

Bước 1: Báo cáo sự cố

Bước 1 dành cho người phát hiện: báo cáo sự cố một cách riêng tư và với thiện chí.

  • Tốt: Người phát hiện gửi thông tin liên quan cho nhà sản xuất, chẳng hạn qua email đến địa chỉ email bảo mật của nhà sản xuất (thường là "security@example.com") hoặc qua biểu mẫu trên trang web của nhà sản xuất (thường là "https://www.example.com/security").

  • Xấu: đăng báo cáo lên blog công khai, hoặc báo cho giới truyền thông, hoặc đe dọa, hoặc cố bán vấn đề bảo mật cho tin tặc, v.v.

  • Mẹo: người phát hiện có thể chọn ẩn danh; nhà sản xuất cũng có thể chọn ẩn danh.

Nếu muốn, hãy tiếp tục theo dõi vấn đề.

  • Tốt: mở các kênh liên lạc, hoặc cung cấp thông tin tiếp theo, hoặc theo dõi tình hình.

  • Xấu: quên mất vấn đề.

  • Mẹo: người phát hiện có thể chọn giúp hoặc không, cũng có thể chọn giữ liên lạc hoặc không, và cũng có thể chọn thay đổi thỏa thuận nếu hoàn cảnh thay đổi.

Nếu muốn, hãy công bố vấn đề cho người khác.

  • Tốt: chờ khoảng thời gian đã định rồi công khai, chẳng hạn đăng thông tin liên quan lên một trang tin tức bảo mật, hoặc liên hệ các nhà nghiên cứu bảo mật bên thứ ba có liên quan, hoặc thông báo vấn đề trên bất kỳ trang mạng xã hội công khai nào, v.v.

  • Xấu: không công bố vấn đề cho người khác, trừ khi bạn cảm thấy làm vậy sẽ gây ra rủi ro vượt quá mức tương xứng cho bản thân bạn hoặc người khác.

  • Mẹo: nếu hoàn cảnh thay đổi, chẳng hạn phát hiện rủi ro cao hơn hoặc một khai thác đang hoạt động ngoài thực tế (active exploit in the wild), thì người phát hiện có thể công bố vấn đề cho người khác sớm hơn.

Bước 2: Bảo đảm đầu mối liên hệ

Bước 2 dành cho nhà sản xuất: bảo đảm các đầu mối liên hệ hoạt động được.

  • Tốt: Nhà sản xuất công bố một địa chỉ email liên hệ bảo mật (theo quy ước là "security@example.com") và lý tưởng là cả một khóa mã hóa email an toàn.

  • Tốt: Nhà sản xuất công bố một trang web liên hệ bảo mật (theo quy ước là "https://www.example.com/security") và lý tưởng là làm cho trang đó dễ tìm thấy, chẳng hạn qua chân trang, sơ đồ trang web và công cụ tìm kiếm của trang web.

  • Xấu: Nhà sản xuất không cung cấp địa chỉ email hay trang web, hoặc không làm cho chúng dễ tìm thấy.

Bảo đảm năng lực của nhân viên.

  • Tốt: Nhà sản xuất huấn luyện nhân viên hỗ trợ biết phải làm gì nếu nhận được yêu cầu về bảo mật, chẳng hạn cách trả lời bằng thông tin liên hệ, hoặc cách chuyển yêu cầu đó đến đúng nhóm nội bộ.

  • Tốt: Nhà sản xuất định kỳ xác minh rằng năng lực của nhân viên đang hoạt động tốt.

  • Xấu: Nhà sản xuất không huấn luyện hoặc không xác minh.

Phản hồi người phát hiện trong khung thời gian.

  • Nếu người phát hiện không nêu khung thời gian, hãy dùng một ngày làm việc, vì đây là tiêu chuẩn ngành và là thực hành tốt nhất hiện nay của ngành.

  • Nếu người phát hiện đặt câu hỏi, hãy trả lời. Điều này đặc biệt quan trọng khi người phát hiện xin phép được thử nghiệm. Hãy bảo đảm mọi câu trả lời đều rõ ràng và trực tiếp.

Phản hồi người phát hiện thông qua đầu mối liên hệ bảo mật được ủy quyền và/hoặc quy trình bảo mật được ủy quyền.

  • Tốt: một phản hồi từ địa chỉ email chuyên về bảo mật, chẳng hạn "security@example.com".

  • Ví dụ về điều xấu: phản hồi từ một địa chỉ email đa năng, chẳng hạn "help@example.com", hoặc từ bất kỳ ai không phải là chuyên gia bảo mật được ủy quyền.

Cho người phát hiện biết rằng vấn đề đã được ghi nhận là một báo cáo bảo mật.

  • Tốt: cách diễn đạt chuyên về bảo mật, chẳng hạn "Đội ngũ bảo mật của chúng tôi đã nhận được báo cáo công bố có trách nhiệm của bạn", hoặc "Quy trình bảo mật của chúng tôi có những bước tiếp theo sau", hoặc "Thông tin của bạn hiện đã nằm trong hệ thống theo dõi bảo mật của chúng tôi với mã số XYZ", v.v.

  • Xấu: cách diễn đạt đa năng, chẳng hạn "Chúng tôi trân trọng việc kinh doanh của bạn", hoặc "Chúng tôi coi trọng bảo mật", hoặc cách diễn đạt đùn đẩy trách nhiệm như "Chúng tôi đã chuyển email của bạn cho bộ phận khác", v.v.

Bước 3: Làm việc với thiện chí

Bước 3 dành cho người phát hiện và nhà sản xuất cùng nhau: làm việc với thiện chí.

Hãy hiểu rằng công bố lỗ hổng bảo mật có phối hợp mô tả một quy trình dựa trên thiện chí.

  • Mục tiêu số 1 là thiện chí giúp người dùng tự bảo vệ trước các rủi ro bảo mật.

  • Mục tiêu số 2 là thiện chí giải quyết vấn đề bảo mật.

  • Người phát hiện và/hoặc nhà sản xuất có thể chọn với thiện chí để các chuyên gia bảo mật khác tham gia, chẳng hạn liên hệ các nhà nghiên cứu bảo mật liên quan khác để giúp xử lý vấn đề.

Hãy hiểu rằng công bố lỗ hổng bảo mật có phối hợp không tạo ra bất kỳ nghĩa vụ nào.

  • Người phát hiện và/hoặc nhà sản xuất có thể rút lui bất cứ lúc nào, vì bất cứ lý do gì, có hoặc không có cảnh báo. Giữ cho tất cả những người liên quan được thông tin và cập nhật là điều lịch sự, nhưng không phải lúc nào cũng khả thi, thiết thực hay mong muốn.

  • Công bố lỗ hổng bảo mật có phối hợp không tạo ra bất kỳ thỏa thuận pháp lý nào. Nếu người phát hiện và nhà sản xuất đã có thỏa thuận pháp lý, chúng tôi đề nghị mọi người liên quan tham khảo ý kiến luật sư phù hợp; đừng dùng tài liệu này làm tư vấn pháp lý.

Hãy hiểu rằng công bố lỗ hổng bảo mật có phối hợp nhằm sử dụng giao tiếp tốt và nhằm bác bỏ sự đe dọa.

  • Công bố lỗ hổng bảo mật có phối hợp tốt nhất khi mọi người liên quan hiểu rằng mục tiêu số 1 là giúp người dùng tự bảo vệ trước các rủi ro bảo mật, và mục tiêu số 2 là giải quyết vấn đề bảo mật.

  • Công bố lỗ hổng bảo mật có phối hợp bác bỏ mọi hình thức đe dọa trả đũa, hăm dọa, đình chỉ, thu hồi, tống tiền, gánh nặng phải theo dõi, hoặc đổ lỗi cho nạn nhân.

Hãy hiểu rằng công bố lỗ hổng bảo mật có phối hợp có thể mang ý nghĩa khác nhau với những người khác nhau.

  • Người phát hiện và nhà sản xuất có thể hiểu khác nhau về công bố lỗ hổng bảo mật có phối hợp. Những cách hiểu này có thể không trùng khớp. Thiện chí bao gồm việc mọi người liên quan hiểu điều này.

  • Một số nhà sản xuất công bố chính sách công bố lỗ hổng bảo mật có phối hợp. Những chính sách này có thể là hướng dẫn hữu ích. Nếu người phát hiện chọn dùng một kiểu công bố lỗ hổng bảo mật có phối hợp khác, hoặc có cách hiểu khác về công bố có trách nhiệm, thì điều đó hoàn toàn ổn.

Hãy hiểu rằng thông thường người phát hiện đang làm ơn cho bên công bố.

  • Thông thường người phát hiện không cần sự cho phép của ai để công bố các lỗ hổng.

  • Thông thường thông tin của người phát hiện giúp ích cho bên công bố.

Xác minh thành công

Sau khi vấn đề được giải quyết, nhà sản xuất phải xác minh thành công.

  • Tất cả mọi người và các quy trình có xử lý việc công bố thành công không? Nếu có, tốt. Nếu không, hãy cân nhắc nghiên cứu sau sự cố, chẳng hạn phân tích nguyên nhân gốc (RCA), báo cáo hậu kiểm (post-mortem), sơ đồ Ishikawa, hoặc phân tích nhân quả dựa trên lý thuyết hệ thống (CAST).

  • Các vấn đề còn tồn đọng có được phân loại ưu tiên và theo dõi không?

  • Nhà sản xuất và người phát hiện đều hiểu phải làm gì cho các bước tiếp theo chứ? Điều này đặc biệt quan trọng cần làm đúng phòng khi có thể có thêm các công bố lỗ hổng bảo mật có phối hợp tiếp theo.

Hướng dẫn

Hướng dẫn cho công bố lỗ hổng bảo mật có phối hợp có thể đến từ nhiều lĩnh vực, chẳng hạn chuyên gia đạo đức, người ủng hộ pháp lý, kỳ vọng hợp lý của công chúng nói chung, v.v.

Nếu bạn đang tìm hướng dẫn, bạn có thể quan tâm đến ba lĩnh vực này, tất cả được mô tả bên dưới.

  • Người Samaritan nhân hậu

  • Nghĩa vụ cứu giúp

  • Nghĩa vụ chăm sóc

Người Samaritan nhân hậu

Wikipedia: Luật Người Samaritan nhân hậu

Luật Người Samaritan nhân hậu (Good Samaritan law) mang lại sự bảo vệ pháp lý cho những người giúp đỡ hợp lý những ai bị thương, bị bệnh, lâm nguy, hoặc mất khả năng tự lo (hoặc được tin là như vậy). Sự bảo vệ này nhằm giảm sự do dự của người ngoài cuộc khi giúp đỡ vì sợ bị kiện hoặc bị truy tố.

Nghĩa vụ cứu giúp

Wikipedia: Nghĩa vụ cứu giúp

Nghĩa vụ cứu giúp là một khái niệm mô tả hoàn cảnh trong đó một bên có thể phải chịu trách nhiệm vì không đến cứu giúp một bên khác đang lâm nguy. Nghĩa vụ cứu giúp có thể có các khía cạnh đạo đức và/hoặc pháp lý.

Nghĩa vụ chăm sóc

Wikipedia: Nghĩa vụ chăm sóc

Nghĩa vụ chăm sóc là nghĩa vụ tuân thủ một tiêu chuẩn thận trọng hợp lý khi thực hiện bất kỳ hành vi nào có thể thấy trước là gây hại cho người khác. Nghĩa vụ chăm sóc có thể có các khía cạnh đạo đức và/hoặc pháp lý. Một số điểm cần xem xét là: khả năng thấy trước tác hại hoặc thương tích, mức độ có thể có của tác hại hoặc thương tích tiềm tàng, tầm quan trọng hoặc giá trị xã hội của hoạt động mà bị đơn tham gia, tính hữu ích của hành vi đối với bị đơn, tính khả thi của hành vi thay thế, chi phí và gánh nặng gắn với hành vi thay thế, tính hữu ích tương đối của hành vi thay thế và mức độ an toàn tương đối của hành vi thay thế.

Các trường hợp đặc biệt

Các đội ngũ bảo mật của chúng tôi đã thấy nhiều trường hợp đặc biệt đa dạng.

Chúng tôi mô tả chúng ở đây để giúp mọi người hiểu những điểm mà ở đó có nhiều ý kiến khác nhau về điều gì có thể chấp nhận được và điều gì không. Chúng tôi khuyến nghị mọi người liên quan trao đổi với thiện chí về những vấn đề này.

Truy cập thông tin của người dùng khác

Ví dụ: bạn phát hiện một URL có chứa mã người dùng của bạn, và nó làm lộ một lỗi, và bạn tin rằng mình có thể sửa URL để đổi mã người dùng của bạn thành mã người dùng khác.

  • Người phát hiện làm điều này có chấp nhận được không, chẳng hạn với mục tiêu duy nhất là tìm hiểu xem nó có ảnh hưởng đến những người dùng khác không?

  • Việc nhanh chóng hiểu rõ phạm vi rủi ro đối với tất cả người dùng có quan trọng hơn việc bảo vệ vài người dùng mà thông tin của họ có thể đã hiển thị với tin tặc không?

  • Người phát hiện có thể làm điều này với bao nhiêu người dùng tùy thích không?

  • Người phát hiện cố gắng liên hệ người dùng để cho họ biết họ bị ảnh hưởng có chấp nhận được không? Đưa ra gợi ý giảm thiểu có chấp nhận được không?

Từ chối dịch vụ

Ví dụ: bạn phát hiện một lỗi vô tình làm tạm ngưng tài khoản của bạn, chẳng hạn kích hoạt khóa mật khẩu.

  • Điều này có được xem là một cuộc tấn công từ chối dịch vụ không?

Email không được yêu cầu

Ví dụ: bạn cố gắng báo cáo một vấn đề bảo mật cho những người trong công ty mà bạn nghĩ là có liên quan, và bạn tìm ra họ bằng cách tra cứu trên LinkedIn, Facebook, v.v., hoặc bằng cách dùng các quy ước đặt tên như "webmaster@example.com" hoặc "security@example.com".

  • Điều này có chấp nhận được không?

  • Điều này có được xem là email không được yêu cầu (unsolicited email) không?

  • Điều này có được xem là email không được phép (unauthorized email) không?

Các nhóm bị loại trừ

Ví dụ: bạn thuộc một nhóm bị loại trừ, chẳng hạn là trẻ vị thành niên, hoặc nằm trong danh sách trừng phạt, hoặc ở một quốc gia nằm trong danh sách trừng phạt.

  • Bạn gửi báo cáo có chấp nhận được không?

  • Báo cáo ẩn danh có chấp nhận được không?

  • Cố ý thay đổi thông tin có khả năng nhận dạng, chẳng hạn để thoát khỏi nhóm bị loại trừ, và với mục tiêu giúp bản công bố đến đúng người, có chấp nhận được không?

Bên thứ ba

Ví dụ: bạn phát hiện phần mềm của một công ty có lỗi liên quan đến một bên thứ ba, chẳng hạn tích hợp với một phần mềm khác hoặc một trang web khác.

  • Bạn báo cáo tất cả thông tin bạn tìm thấy cho cả hai bên có chấp nhận được không?

  • Có cần thiết phải thực hiện hai lần công bố có trách nhiệm riêng biệt, chẳng hạn một báo cáo cho một công ty và một báo cáo khác cho công ty bên thứ ba, với mục tiêu hạn chế thông tin gửi cho mỗi công ty không?

  • Người phát hiện kết nối các công ty với nhau có chấp nhận được không?

Phần mềm gây gián đoạn

Ví dụ: bạn đủ giỏi để viết một loại virus mà bạn tin là có khả năng giúp người dùng tự bảo vệ trước rủi ro bảo mật, hoặc xác định xem họ có đang gặp rủi ro không, hoặc khắc phục rủi ro bảo mật.

  • Điều đó có chấp nhận được không?

  • Người phát hiện hướng dẫn người dùng đến phần mềm như vậy, và/hoặc đến các hướng dẫn hay bài học mô tả cách tạo loại phần mềm này, có chấp nhận được không?

Công bố lỗ hổng bảo mật có phối hợp so với công bố có trách nhiệm

Công bố lỗ hổng bảo mật có phối hợp là thuật ngữ được ưa chuộng.

  • Khía cạnh quan trọng nhất là sự phối hợp giữa người phát hiện và nhà sản xuất.

Công bố có trách nhiệm (responsible disclosure) là một thuật ngữ không còn được khuyến khích.

  • Mọi người có những quan điểm khác nhau về thế nào là có trách nhiệm. Chẳng hạn, một số người ủng hộ rằng người phát hiện thông báo ngay cho công chúng, bất kể có tương tác gì với nhà sản xuất, mới là có trách nhiệm, còn việc công bố lỗ hổng bảo mật có phối hợp là thiếu trách nhiệm vì nó che giấu thông tin với công chúng.

Theo dõi