NCSC.nl

1. Giới thiệu

Xã hội ngày càng số hóa. Ngày nay, hầu hết mọi quy trình đều có lúc cần đến máy tính, từ điện thoại di động đến phần mềm chuyên dụng. Mặc dù sự phát triển này tạo ra nhiều cơ hội mới, các lỗ hổng trong hệ thống CNTT có thể gây ra tác động lớn. Do đó, kiến thức về các lỗ hổng này cần được xử lý hiệu quả.

Đầu năm 2013, một số tổ chức bắt đầu công bố chính sách về cách báo cáo lỗ hổng. Sau khi tham vấn các bên này, Trung tâm An ninh mạng Quốc gia (NCSC) đã tóm tắt các diễn biến dưới dạng ‘Hướng dẫn để đạt được thực hành Công bố có trách nhiệm’ (tiếng Hà Lan: ‘Leidraad om te komen tot een praktijk van Responsible Disclosure’; sau đây gọi là ‘Hướng dẫn’). Thông qua chính sách này, các công ty cho thấy họ sẵn sàng tiếp nhận báo cáo lỗ hổng từ bên ngoài, mô tả các điều kiện tiên quyết và đưa ra cam kết. Quy trình này tạo ra sự rõ ràng và một môi trường tương đối an toàn để bên báo cáo điều tra và báo cáo lỗ hổng mà không trực tiếp phạm tội hình sự. Tại cuộc họp cấp cao của EU về an ninh mạng năm 2016, 29 tổ chức đã tái khẳng định tầm quan trọng của chính sách xử lý lỗ hổng bằng cách ký Tuyên ngôn Công bố lỗ hổng bảo mật có phối hợp (Coordinated Vulnerability Disclosure Manifesto)1 do CIO Platform Netherlands và Rabobank khởi xướng với sự hợp tác của NCSC.

Công bố lỗ hổng bảo mật có phối hợp (CVD) đã được chứng minh là có tầm quan trọng lớn đối với các bên công và tư. Họ phụ thuộc rất nhiều vào hoạt động không gián đoạn của các hệ thống thông tin trong thực tế hằng ngày. Các báo cáo về lỗ hổng trong hệ thống của họ đã giúp cải thiện tính an toàn và tính liên tục của các hệ thống trong những năm gần đây, một mặt bằng việc khắc phục lỗ hổng và mặt khác bằng việc góp phần nâng cao nhận thức chung của các công ty Hà Lan về an ninh CNTT.

Trong những năm gần đây, đã rõ rằng các bên báo cáo sẵn sàng làm việc trong các điều kiện của chính sách CVD do các tổ chức soạn ra. Các báo cáo được bên báo cáo gửi trực tiếp hoặc gián tiếp đến các tổ chức. Thực hành công bố có trách nhiệm đã cho thấy các bên báo cáo có thiện chí và các tổ chức dễ bị tổn thương đã hợp tác được với nhau và nhờ đó tiến thêm một bước trong việc tăng cường an ninh của hệ thống mạng và thông tin.

Với lần sửa đổi này, chúng tôi một lần nữa đã trao đổi với một nhóm rộng và đa dạng gồm các bên báo cáo, các bên tư nhân và nhà nước, cũng như Viện Công tố và Cảnh sát Quốc gia. Những cuộc trao đổi này đã xác nhận thực hành hiện tại và dẫn đến các bổ sung và cải tiến. Điểm cần lưu ý mới quan trọng nhất là việc trao đổi giữa người báo cáo lỗ hổng và tổ chức, cũng như với các bên khác sau khi lỗ hổng đã được khắc phục.

Các chương sau thảo luận về định nghĩa CVD, các thành tố cho chính sách CVD và quy trình trao đổi thông tin.

Lưu ý: Hướng dẫn trước đây dùng thuật ngữ ‘công bố có trách nhiệm’ (responsible disclosure), vốn là thuật ngữ phổ biến cho thực hành này vào thời điểm đó. Từ đó đã rõ rằng thuật ngữ này nhấn mạnh quá mức trách nhiệm của bên báo cáo, trong khi nguyên tắc cơ bản là bên báo cáo và tổ chức có khả năng bị tổn thương nên là các đối tác ngang hàng trong đối thoại. Tinh thần này được thể hiện tốt hơn bằng thuật ngữ thường dùng hiện nay ‘Công bố lỗ hổng bảo mật có phối hợp’ (Coordinated Vulnerability Disclosure, CVD), cũng là tên được dùng trong các tiêu chuẩn ISO 29147 và 30111 về quy trình này.

2. Lỗ hổng có phối hợp

Nhiều phương pháp đã được sử dụng trong 30 năm qua để nâng cao nhận thức về các lỗ hổng trong hệ thống CNTT. Ví dụ gồm:

‘Công bố toàn bộ’ (Full Disclosure), công khai hoàn toàn một lỗ hổng;
‘Không công bố’ (Non-disclosure), bán hoặc tự sử dụng một lỗ hổng;
‘Công bố lỗ hổng bảo mật có phối hợp’ (CVD), việc công bố một lỗ hổng có phối hợp.

Thực hành sau cùng được ưu tiên một cách rõ ràng.

Cộng đồng CNTT đã cho thấy sự sẵn lòng lớn trong việc chia sẻ kiến thức và kinh nghiệm. Do đó, tìm kiếm sự hợp tác với cộng đồng này có thể giúp cải thiện an ninh chung của các hệ thống.

Mục đích của công bố lỗ hổng bảo mật có phối hợp

Mục đích của CVD là góp phần vào an ninh của các hệ thống CNTT bằng cách chia sẻ kiến thức về lỗ hổng. Trong CVD, kiến thức được chia sẻ với một hoặc nhiều tổ chức có khả năng bị tổn thương nhằm đi đến một giải pháp chung cho lỗ hổng được tìm thấy, với sự hợp tác của bên báo cáo. Điều quan trọng là các tổ chức bị ảnh hưởng có đủ thời gian để khắc phục mọi lỗ hổng hoặc bảo vệ hệ thống nhằm hạn chế hoặc ngăn ngừa tổn thất hay thiệt hại ở mức tối đa có thể. Nền tảng của quy trình là công bố kiến thức về các lỗ hổng sau khi đã khắc phục.

Điều thiết yếu trong CVD là mọi bên tuân thủ các thỏa thuận về cách báo cáo một lỗ hổng và cách xử lý nó. Sẽ có ích nếu một tổ chức công bố trước các điều kiện tiên quyết, chẳng hạn hệ thống nào nằm trong phạm vi và có thể tiến hành loại nghiên cứu nào. Một nguyên tắc quan trọng cho các điều kiện tiên quyết này là về nguyên tắc tổ chức sẽ không tố giác bên báo cáo hay thực hiện các bước pháp lý khác nếu việc điều tra và báo cáo được thực hiện trong các điều kiện đã đặt ra. Bản Hướng dẫn này cung cấp cho các tổ chức định hướng trong việc soạn chính sách riêng để hiện thực hóa các nguyên tắc của CVD.

Như tên gọi cho thấy, điểm trung tâm của CVD là tổ chức và bên báo cáo phối hợp với nhau. Về mặt này, nên có càng ít mắt xích càng tốt giữa người báo cáo lỗ hổng và người trong tổ chức chịu trách nhiệm giải quyết vấn đề.

Có thể quan trọng khi thông báo cho nhiều bên cùng lúc nếu một lỗ hổng ảnh hưởng đến nhiều hệ thống. Trong trường hợp đó, NCSC hoặc các bên khác trong cộng đồng bảo mật có thể hỗ trợ quy trình CVD ở vai trò điều phối.

3. Các lĩnh vực trách nhiệm

Mục đích của việc theo đuổi chính sách CVD là để các bên báo cáo và tổ chức cùng làm việc nhằm giảm thiểu các lỗ hổng trong hệ thống CNTT. Việc thực hiện chính sách này nên được xem như phần bổ sung cho các biện pháp hiện có về an toàn thông tin. Các chủ thể khác nhau có vai trò và trách nhiệm riêng. Những điều này được giải thích chi tiết hơn dưới đây.

Tổ chức sở hữu/quản lý một hệ thống

Tổ chức sở hữu/quản lý hoặc cung cấp một hệ thống chịu trách nhiệm chính về an ninh của hệ thống đó. Nói cách khác, tổ chức cũng chịu trách nhiệm xử lý tiếp theo một báo cáo lỗ hổng.

Tổ chức có thể chọn soạn chính sách CVD riêng bằng cách dùng bản Hướng dẫn này và thông tin chính sách này tới các bên báo cáo tiềm năng. Bằng việc công bố chính sách CVD, các tổ chức thể hiện sự sẵn lòng tiếp nhận thông tin về các lỗ hổng.

Một bên thiết lập chính sách CVD có thể cam kết với nguyên tắc rằng họ sẽ không nộp đơn tố cáo với cảnh sát nếu các quy tắc áp dụng cho chính sách được tôn trọng.

Khi một bên báo cáo đã báo cáo một lỗ hổng, trách nhiệm thuộc về tổ chức. Điều quan trọng là phải nhận ra rằng bên báo cáo thường là người ở bên ngoài tổ chức. Bên này không thể nhìn trực tiếp vào các quy trình nội bộ có thể được kích hoạt sau khi một lỗ hổng được báo cáo. Do đó, các bên báo cáo sẽ đánh giá cao việc được thông báo về diễn biến trong việc giải quyết lỗ hổng. Sự trao đổi liên tục này cũng quan trọng để tạo ra những kỳ vọng đúng về việc xử lý tiếp theo và tính kịp thời của giải pháp.

Bên báo cáo một lỗ hổng

Bằng cách này hay cách khác, bên báo cáo đã xác định được một lỗ hổng và muốn góp phần vào an ninh của hệ thống CNTT bằng việc làm cho lỗ hổng này được khắc phục và có thể được công khai ở giai đoạn sau. Bên báo cáo có thể đã phát hiện ra điều gì đó thông qua quan sát thụ động hoặc bằng cách chủ động thử nghiệm hệ thống CNTT. Đương nhiên, bên này chịu trách nhiệm về hành động của mình và cách họ đã phát hiện lỗ hổng. Bên báo cáo tự chịu trách nhiệm nắm rõ các điều kiện mà một tổ chức đặt ra trong chính sách CVD của mình. Hầu hết các chính phủ và công ty đã công bố chính sách CVD trên trang web của họ.

Tuy nhiên, việc tìm lỗ hổng vẫn có thể liên quan đến vi phạm pháp luật. Trong bối cảnh CVD, tổ chức và bên báo cáo có thể thỏa thuận không tố giác bất kỳ hành vi phạm tội nào. Về mặt này, chính sách CVD do tổ chức công bố là nguyên tắc chỉ dẫn. Các bên cũng có thể thỏa thuận rằng sẽ không có hành động dân sự nào được thực hiện.

Nếu có nghi ngờ rằng bên báo cáo đã vi phạm pháp luật, trước hết chính sách CVD có thể giúp ngăn người báo cáo bị tố giác với nhà chức trách. Thủ tục này phụ thuộc hoàn toàn vào các điều kiện tiên quyết của chính sách mà tổ chức yêu cầu bên báo cáo tuân thủ và vào việc sự tuân thủ này có đạt được hay không, có thể kèm theo một cam kết tương ứng không nộp đơn tố cáo hình sự miễn là bên đó hành động trong các điều kiện của chính sách. Nếu có trình báo cảnh sát, sự tồn tại và việc tuân thủ chính sách CVD là một tình tiết liên quan ở Hà Lan, mà Công tố viên sẽ cân nhắc khi quyết định có khởi động điều tra hình sự và/hoặc truy tố hay không. Về nguyên tắc, cảnh sát và Viện Công tố (OM) sẽ không khởi động điều tra hình sự nếu bên báo cáo rõ ràng đã tuân thủ các quy tắc trong chính sách CVD của tổ chức liên quan. Tuy nhiên, Viện Công tố và cảnh sát có thể điều tra vụ việc thêm nếu có dấu hiệu cho thấy bên báo cáo đã cố ý hoặc vô ý đi quá xa trong hành động và/hoặc không tuân thủ chính sách CVD. Dựa trên cuộc điều tra này, Viện Công tố có thể quyết định có truy tố hay không.

Viện Công tố đã công bố một thư chính sách, trong đó đề cập cụ thể hơn các khía cạnh quan trọng khi đi đến quyết định điều tra và/hoặc truy tố. Chẳng hạn, liệu hành động của bên báo cáo có phục vụ một lợi ích công quan trọng hay không, liệu bên đó có hành động quá mức không tương xứng hay không, và liệu bên đó có lẽ đã có thể hành động theo cách khác, ít quyết liệt hơn hay không. Thư chính sách liên quan làm rõ thêm các khía cạnh này.2 Án lệ liên quan từ năm 20133 cho thấy các khía cạnh này cũng được tòa án xem xét nếu một tổ chức không có chính sách CVD.

4. Các thành tố của quy trình công bố lỗ hổng bảo mật có phối hợp

Các thành tố trong việc hình thành quy trình CVD cho tổ chức, bên báo cáo và NCSC được trình bày dưới đây.

Tổ chức

Việc thúc đẩy CVD bắt đầu từ một tổ chức sở hữu các hệ thống CNTT hoặc cung cấp một sản phẩm/hệ thống CNTT. Suy cho cùng, tổ chức này chịu trách nhiệm chính về an toàn thông tin của các hệ thống CNTT này. Để hợp tác hiệu quả với nhiều bên nhằm giải quyết các lỗ hổng, tổ chức có thể quyết định soạn và công bố một chính sách CVD. Việc soạn chính sách CVD riêng cho phép tổ chức chứng tỏ cách họ xử lý các báo cáo lỗ hổng. Theo cách này, một tổ chức cũng có thể định hình cách họ muốn nhận thông báo. Một quy trình như vậy có thể được tổ chức như sau:

Tổ chức thiết lập và công bố một chính sách CVD.
Trong chính sách này, tổ chức đưa ra các quy tắc rõ ràng cho việc nghiên cứu mà các bên báo cáo có thể thực hiện, chẳng hạn kỹ thuật nào được phép và hệ thống nào nằm trong hoặc ngoài phạm vi.
Tổ chức làm cho bên báo cáo dễ dàng gửi báo cáo. Một lựa chọn là dùng phương thức báo cáo chuẩn hóa; ví dụ một địa chỉ email cụ thể hoặc biểu mẫu trực tuyến. Ngoài ra, tổ chức có thể quyết định có chấp nhận báo cáo ẩn danh hay không.
Tổ chức dành năng lực nội bộ và thiết lập một quy trình để phản hồi báo cáo một cách thỏa đáng. Nên thiết lập quy trình để mọi lỗ hổng tìm thấy có thể được khắc phục thỏa đáng. Về mặt này, nguồn gốc của báo cáo là không quan trọng. Chẳng hạn lỗ hổng cũng có thể do một nhân viên nội bộ hoặc trong một đợt kiểm thử xác định.
Kinh nghiệm thực tế cho thấy sau lần công bố chính sách CVD đầu tiên, sẽ có mối quan tâm lớn hơn đến việc báo cáo lỗ hổng cho tổ chức. Tổ chức nên tính đến điều này khi lập kế hoạch năng lực (bổ sung).
Khi tổ chức nhận được báo cáo lỗ hổng, tổ chức bảo đảm báo cáo đến với bộ phận phù hợp nhất để đánh giá và xử lý báo cáo càng sớm càng tốt.
Tổ chức gửi xác nhận đã nhận báo cáo cho bên báo cáo, tốt nhất là có ký số để nhấn mạnh mức ưu tiên.
Sau đó, tổ chức sẽ trao đổi với bên báo cáo để xác định khoảng thời gian mà việc công bố (nếu có) sẽ diễn ra. Khoảng thời gian này sẽ phụ thuộc nhiều vào bản chất của lỗ hổng và loại hệ thống.
Như một hướng dẫn, khoảng thời gian xấp xỉ 60 ngày thường được dùng cho các lỗ hổng phần mềm. Khắc phục lỗ hổng trong phần cứng khó thực hiện hơn; có thể dùng hướng dẫn 6 tháng.
Có thể mong muốn kéo dài hoặc rút ngắn khoảng thời gian này theo thỏa thuận chung tùy thuộc vào việc có nhiều hay ít hệ thống CNTT phụ thuộc vào hệ thống được báo cáo lỗ hổng, hoặc lỗ hổng dễ hay khó giải quyết hơn.
Một lỗ hổng có thể tỏ ra khó hoặc không thể giải quyết, hoặc có thể có chi phí cao để giải quyết nó. Trong những trường hợp như vậy, tổ chức có thể đồng ý coi lỗ hổng là rủi ro được chấp nhận và không khắc phục, có thể sau khi trao đổi với bên báo cáo.
Tổ chức sẽ giữ cho bên báo cáo được cập nhật về diễn biến của quy trình.
Ngoài ra, tổ chức có thể đề nghị công khai ghi nhận bên báo cáo vì đã công bố lỗ hổng. Cũng có thể chọn công bố chung với bên ngoài.
Nên thưởng cho bên báo cáo vì đã báo cáo lỗ hổng trong hệ thống nếu bên đó đã tuân thủ các quy tắc của chính sách CVD. Mức thưởng có thể phụ thuộc vào chất lượng báo cáo. Việc thưởng cho bên báo cáo có thể tạo mối quan hệ tốt hơn giữa bên đó và tổ chức, cũng như tăng sự sẵn lòng của mọi người trong việc gửi báo cáo mới theo chính sách CVD.
Sau khi trao đổi với bên báo cáo, tổ chức có thể đồng ý thông báo cho cộng đồng CNTT rộng hơn về lỗ hổng nếu có khả năng lỗ hổng cũng tồn tại ở nơi khác.
Trong chính sách CVD của mình, tổ chức có thể tự cam kết với nguyên tắc rằng sẽ không nộp đơn tố cáo với cảnh sát nếu bên báo cáo đã tuân thủ các quy tắc nêu trong chính sách.

Bên báo cáo

Bên báo cáo là chìa khóa cho một quy trình CVD thành công. Bằng cách này hay cách khác, bên này đã xác định được một lỗ hổng và muốn góp phần vào an ninh của hệ thống CNTT bằng việc để tổ chức khắc phục lỗ hổng này và công khai nó. Làm như vậy, các bên báo cáo thừa nhận rằng họ có thể đóng góp quan trọng cho xã hội bằng cách tiết lộ lỗ hổng theo cách có phối hợp. Để đạt được quy trình CVD thành công, các thành tố sau đây là quan trọng đối với bên báo cáo:

Bên báo cáo chịu trách nhiệm về hành động của chính mình và phải tuân thủ cả nguyên tắc tương xứng lẫn nguyên tắc bổ trợ khi điều tra và báo cáo lỗ hổng. Nói cách khác, bên báo cáo không nên làm nhiều hơn mức cần thiết để chứng minh lỗ hổng và luôn phải báo cáo lỗ hổng trước tiên cho chủ sở hữu hệ thống/thông tin.
Bên báo cáo phải báo cáo vấn đề càng sớm càng tốt để ngăn các bên xấu phát hiện lỗ hổng và lợi dụng nó.
Bên báo cáo phải gửi báo cáo cho tổ chức một cách bí mật để ngăn người khác tiếp cận thông tin này.
Bên báo cáo không được để việc nộp báo cáo hay việc tiếp tục cung cấp thông tin phụ thuộc vào phần thưởng. Việc chủ động trao thưởng khi có báo cáo thuộc về tổ chức tiếp nhận, tổ chức có thể nêu các điều kiện tiên quyết trong chính sách đã công bố.
Bên báo cáo và tổ chức đưa ra các thỏa thuận rõ ràng về việc công bố lỗ hổng. Nếu có nhiều hơn một tổ chức liên quan, nguyên tắc cơ bản là các lỗ hổng chỉ có thể được công bố nếu tất cả các tổ chức đồng ý với việc này. Nên đưa ra các thỏa thuận này từ sớm.
Bên báo cáo và tổ chức liên quan có thể đưa ra thỏa thuận về việc thông báo cho cộng đồng CNTT rộng hơn. Chẳng hạn, tình huống này có thể áp dụng cho một lỗ hổng (dù đã biết hay chưa) được biết là tồn tại ở nhiều hơn một nơi. Trung tâm An ninh mạng Quốc gia (NCSC) có thể được mời tham gia quy trình này để hỗ trợ các nhóm đối tượng của chính quyền trung ương và hạ tầng trọng yếu hoặc để thông báo cho nhiều bên trong trường hợp có lỗ hổng ảnh hưởng đến nhiều hệ thống.

NCSC

Quy trình CVD trước hết là việc của các tổ chức và bên báo cáo. Tuy nhiên, NCSC sẽ khuyến khích việc sử dụng quy trình CVD. Sau khi trao đổi với bên báo cáo và tổ chức, NCSC cũng có thể tham gia chia sẻ thông tin về lỗ hổng với cộng đồng mà mình phục vụ (constituency) nhằm hạn chế thêm các rủi ro bảo mật phát sinh từ lỗ hổng.

Nếu việc báo cáo lỗ hổng không diễn ra như bên báo cáo mong đợi, hoặc nếu họ không muốn báo cáo trực tiếp lỗ hổng cho tổ chức, họ có thể liên hệ NCSC.4 Trong trường hợp này, NCSC có thể đóng vai trò trung gian khi cần thiết.

Chủ sở hữu hệ thống CNTT luôn chịu trách nhiệm về an ninh của hệ thống. NCSC không thể buộc chủ sở hữu hệ thống khắc phục lỗ hổng, cũng không thể bảo đảm rằng chủ sở hữu sẽ không có hành động pháp lý chống lại bên báo cáo. Do đó, bên báo cáo phải tính đến các thành tố nêu trên dành cho tổ chức và bên báo cáo khi tìm kiếm và báo cáo một lỗ hổng. Bên báo cáo có thể mong đợi NCSC làm hết sức để lỗ hổng được khắc phục và xử lý báo cáo một cách bí mật. NCSC không chia sẻ bất kỳ dữ liệu cá nhân nào trừ khi có nghĩa vụ pháp lý phải làm vậy.

Nếu có thể, NCSC sẽ sử dụng thông tin thu được về các lỗ hổng, sau khi trao đổi với các tổ chức và bên báo cáo, để tiếp tục chia sẻ kiến thức với cộng đồng CNTT. Chẳng hạn, họ có thể làm vậy bằng cách công bố một phần thông tin, viết hoặc cập nhật một tờ thông tin (fact sheet) hay sách trắng (white paper), hoặc bằng cách thông báo cho các tổ chức cụ thể.

Tùy thuộc vào tổ chức liên quan và bản chất của lỗ hổng được xác định, NCSC sẽ nỗ lực để đưa lỗ hổng đến sự chú ý của tổ chức liên quan. Tuy nhiên, chủ sở hữu hệ thống CNTT được đề cập vẫn chịu trách nhiệm về hệ thống.
Khi có thể và cần thiết, NCSC sẽ tư vấn cho tổ chức liên quan về cách khắc phục lỗ hổng.
NCSC sẽ xử lý các báo cáo một cách bí mật và sẽ không chia sẻ dữ liệu cá nhân của các bên báo cáo hoặc tổ chức tiếp nhận nếu không có sự đồng ý, trừ khi việc đó xuất phát từ nghĩa vụ theo luật định.
Bất cứ khi nào có thể, NCSC sẽ giữ cho bên báo cáo được thông tin về diễn biến trong liên hệ với tổ chức và việc khắc phục lỗ hổng.
Trong các trường hợp có báo cáo gửi cho NCSC, NCSC sẽ cố gắng kết nối bên báo cáo hoặc bên báo cáo tiềm năng với tổ chức.

Chẳng hạn, nếu một bên báo cáo đã tìm thấy lỗ hổng trong một sản phẩm phần mềm hoặc một lỗ hổng ảnh hưởng đến nhiều hệ thống khác nhau, bên báo cáo có thể đề nghị NCSC điều phối việc khắc phục và công bố lỗ hổng.

Cùng với bên báo cáo, các đối tác, các nhà phát triển và/hoặc nhà phát triển phần mềm và các đội bảo mật khác, NCSC sẽ giúp phân tích, khắc phục hoặc làm cho được khắc phục, điều phối và công bố lỗ hổng theo cách có kiểm soát. Toàn bộ quy trình này diễn ra với sự trao đổi chặt chẽ cùng bên báo cáo đã tìm thấy lỗ hổng.

Chính sách CVD cố gắng cân bằng giữa tầm quan trọng của việc công bố lỗ hổng càng sớm càng tốt để có thể thực hiện các biện pháp, và tầm quan trọng của việc các nhà phát triển cũng như nhà cung cấp có đủ thời gian để khắc phục lỗ hổng. Với quy trình này, NCSC dùng khoảng thời gian tiêu chuẩn 60 ngày giữa báo cáo và công bố công khai. Tuy nhiên, có thể có những hoàn cảnh mà người ta quyết định kéo dài hoặc rút ngắn khoảng thời gian này.

NCSC sẽ chỉ chia sẻ thông tin về lỗ hổng với bên thứ ba sau khi trao đổi với bên báo cáo. Trong bối cảnh này, điều thiết yếu là NCSC hợp tác và do đó chia sẻ thông tin về lỗ hổng với các bên liên quan để công bố lỗ hổng theo cách có phối hợp. Khi làm vậy, NCSC sẽ bảo đảm các bên phù hợp có thể làm việc để khắc phục lỗ hổng, giúp hạn chế mọi tổn thất hoặc thiệt hại và giúp thu hút sự chú ý đến lỗ hổng được tìm thấy.

5. Trao đổi thông tin và quy trình công bố

Năm năm thực hành đã cho thấy trao đổi thông tin rõ ràng là nền tảng của một quy trình CVD thành công. Có những điểm cần chú ý trước, trong và sau quy trình CVD.

Trao đổi về quy trình công bố

Công bố chính sách CVD là bước đầu tiên trong việc trao đổi về quy trình. Khi công khai một chính sách, các bên báo cáo được mời thông báo cho tổ chức về mọi lỗ hổng tìm thấy.

Một mặt, tổ chức có thể soạn các điều kiện cho việc nghiên cứu được thực hiện để phát hiện lỗ hổng và cách thức tìm liên hệ. Mặt khác, tổ chức có thể tự cam kết với nguyên tắc rằng sẽ không nộp đơn tố cáo với cảnh sát nếu các quy tắc của chính sách được tôn trọng. Cách tiếp cận này bảo vệ vị thế của bên báo cáo.

Chính sách CVD có thể được thay đổi hoặc cập nhật vào một thời điểm sau. Điều quan trọng là phải rõ ràng về các thay đổi ở khía cạnh này. Các bên báo cáo có lợi ích trong việc biết điều gì đã được thay đổi và khi nào. Chẳng hạn, có thể làm rõ các thay đổi bằng cách ghi ngày công bố ở đầu chính sách CVD, bằng cách mô tả tóm tắt các thay đổi bên dưới chính sách CVD hoặc bằng cách lưu trữ các phiên bản cũ của chính sách CVD.

Chính sách CVD có thể đưa ra hướng dẫn về cách trao đổi trong quá trình thực hiện, chẳng hạn bằng cách nêu các cập nhật định kỳ qua email hoặc cổng thông tin web. Ngoài ra, chính sách CVD có thể mô tả cách ghi nhận người báo cáo bằng việc nhắc tên khi có cập nhật, đưa vào đại sảnh danh dự (hall of fame) hoặc bất kỳ hình thức thưởng nào khác.

Trao đổi trong quá trình công bố

Bên báo cáo khởi động quy trình CVD bằng cách gửi một thông điệp đến tổ chức. Trong thông điệp này, bên báo cáo mô tả rõ ràng lỗ hổng đã phát hiện. Các yếu tố quan trọng là địa chỉ IP hoặc URL của hệ thống bị ảnh hưởng và các bước cần thiết để tái hiện lỗ hổng.

Điều quan trọng là tổ chức trao đổi rõ ràng với bên báo cáo để những kỳ vọng về quy trình được rõ.

Tổ chức có thể làm điều đó bằng cách gửi xác nhận đã nhận (tự động hay không) có kèm chỉ dẫn về khoảng thời gian sẽ gửi phản hồi nội dung đầu tiên hoặc tiếp theo.

Cũng có thể để ngỏ khoảng thời gian này và đưa ra chỉ dẫn ban đầu về thời hạn sau khi đánh giá nội dung báo cáo. Nên làm rõ càng sớm càng tốt về khoảng thời gian có thể đạt được giải pháp. Theo cách này, người báo cáo biết khi nào có thể mong đợi một kết quả.

Trong một số trường hợp, có thể ngày công bố đã rõ ràng với bên báo cáo; ví dụ do có bài thuyết trình tại một hội nghị hoặc vì bên báo cáo đã tự đặt ra thời hạn. Trong trường hợp này, vẫn quan trọng là bên báo cáo trao đổi rõ ràng mốc thời gian này, nêu nó càng sớm càng tốt và rõ ràng về khả năng/không có khả năng hoãn ngày này.

Bên báo cáo thường là người ở ngoài tổ chức, không có hiểu biết gì về các quy trình nội bộ có thể được kích hoạt bởi một báo cáo. Các tổ chức có thể giữ cho bên báo cáo được thông tin về diễn biến của quy trình qua các cập nhật định kỳ. Cách tiếp cận này giúp bên báo cáo thấy rõ rằng đang có việc làm ra giải pháp. Khi cần, tổ chức có thể yêu cầu làm rõ hoặc nhờ thử nghiệm một giải pháp trong quá trình thực hiện.

Nếu tổ chức không thể đáp ứng thời hạn giải quyết ban đầu, có thể thảo luận với người báo cáo để hoãn lại. Trao đổi thường xuyên có thể giúp người báo cáo nhận ra tình huống này sớm hơn.

Ý định chính của CVD là giảm nhẹ lỗ hổng, nhưng ‘công bố toàn bộ’ lỗ hổng luôn là một lựa chọn của bên báo cáo nếu họ cảm thấy quy trình sẽ kéo dài quá lâu. Biện pháp này là ‘cây gậy lớn’ như người ta thường nói, nằm trong tay bên báo cáo. Đương nhiên, cần ngăn tình huống này càng nhiều càng tốt.

Trao đổi sau quy trình công bố

Có nhiều lý do có thể khiến một bên báo cáo tìm kiếm lỗ hổng rồi báo cáo cho các tổ chức qua quy trình CVD. Với một số lượng lớn các bên báo cáo, một động lực quan trọng là sự ghi nhận (công khai).

Các bên báo cáo nhận được sự ghi nhận công khai qua lời cảm ơn trong bản cập nhật hoặc việc được đưa vào đại sảnh danh dự. Tuy nhiên, nhu cầu được ghi nhận công khai không áp dụng cho mọi bên báo cáo; thực tế có người không muốn công chúng biết đến. Do đó, trong trường hợp tổ chức đưa thông tin, nên xin sự đồng ý của bên báo cáo trước khi nêu tên họ.

Ngoài ra, các bên báo cáo cũng có thể quyết định trao đổi về báo cáo sau khi hoàn tất quy trình CVD. Chẳng hạn, bên báo cáo có thể mô tả quá trình phát hiện hoặc cảnh báo người khác về lỗ hổng. Một người báo cáo có thể quyết định gửi bài viết cho tổ chức để tham khảo. Vì về nguyên tắc quy trình CVD đã hoàn tất sau khi loại bỏ lỗ hổng, nên sau đó bên báo cáo được tự do trao đổi về nó, trừ khi có các thỏa thuận bổ sung trong chính sách hoặc trong quá trình thực hiện.

Danh sách

Trao đổi về quy trình công bố

Công bố chính sách CVD trên trang web
Rõ ràng về các hạn chế (xem chương 6 về các cách tiếp cận khác nhau)
Các hạn chế trong phương pháp điều tra
Hướng dẫn về trao đổi thông tin
Hướng dẫn về các khoản thưởng có thể có: đại sảnh danh dự, thưởng tài chính, áo thun, v.v.
Rõ ràng về mọi cập nhật chính sách CVD, bao gồm ngày thay đổi

Trao đổi trong quá trình công bố

Người báo cáo liên hệ với tổ chức về một lỗ hổng đã phát hiện.
Tổ chức quản lý kỳ vọng, chẳng hạn thời gian phản hồi cho phản hồi kỹ thuật đầu tiên
Tổ chức và người báo cáo làm rõ cho nhau về thời hạn giải quyết dự kiến
Tổ chức thường xuyên cung cấp bản cập nhật (về quy trình)
Khi cần, người báo cáo và tổ chức thảo luận về việc liên hệ với các tổ chức liên quan khác

Trao đổi sau quy trình công bố

Thảo luận về sự ghi nhận (công khai) và thưởng cho người báo cáo
Sắp xếp cách công bố thông tin về lỗ hổng, chẳng hạn giai đoạn nghiên cứu hoặc thông báo cho các tổ chức khác

6. Ví dụ về chính sách Công bố lỗ hổng bảo mật có phối hợp

Có nhiều dạng văn bản chính sách khác nhau về Công bố lỗ hổng bảo mật có phối hợp. Vì chính sách CVD đã công bố đóng vai trò như biển chỉ dẫn cho các bên báo cáo tiềm năng, hãy bảo đảm hình thức của chính sách này phù hợp với chính sách và chiến lược của tổ chức.

Các yếu tố sau là quan trọng trong một chính sách CVD:

phương thức liên hệ để trao đổi an toàn;
các điều kiện tiên quyết cho bên báo cáo;
kỳ vọng rõ ràng về cách xử lý một báo cáo;
phương pháp thưởng cho một báo cáo;
số phiên bản và ngày sửa đổi gần nhất.

Dưới đây là ba ví dụ: Nhiều tổ chức ở Hà Lan đã tham khảo ví dụ cơ bản của ResponsibleDisclosure.nl. Các tổ chức khác bổ sung thêm các điều kiện tiên quyết, xem chính sách của Fox IT. Còn có những tổ chức áp dụng định dạng tự do hơn để phù hợp với đối tượng của họ, xem chính sách của Bits of Freedom.

Tại Acme Corporation, chúng tôi coi an ninh của hệ thống là ưu tiên hàng đầu. Nhưng dù chúng tôi nỗ lực đến đâu cho an ninh hệ thống, vẫn có thể còn tồn tại các lỗ hổng.

Nếu bạn phát hiện một lỗ hổng, chúng tôi muốn được biết để có thể thực hiện các bước xử lý càng nhanh càng tốt.

Chúng tôi muốn đề nghị bạn giúp chúng tôi bảo vệ khách hàng và hệ thống của mình tốt hơn.

Vui lòng làm như sau:

Gửi email các phát hiện của bạn đến cert@example.com. Hãy mã hóa các phát hiện bằng khóa PGP của chúng tôi để ngăn thông tin quan trọng này rơi vào tay kẻ xấu,
Đừng lợi dụng lỗ hổng hay vấn đề bạn đã phát hiện, chẳng hạn bằng cách tải xuống nhiều dữ liệu hơn mức cần thiết để chứng minh lỗ hổng hoặc xóa hay sửa dữ liệu của người khác,
Đừng tiết lộ vấn đề cho người khác cho đến khi nó được giải quyết,
Đừng dùng các cuộc tấn công vào an ninh vật lý, kỹ thuật xã hội, tấn công từ chối dịch vụ phân tán, thư rác hay các ứng dụng của bên thứ ba, và
Hãy cung cấp đủ thông tin để tái hiện vấn đề, để chúng tôi có thể giải quyết nó càng nhanh càng tốt. Thường thì địa chỉ IP hoặc URL của hệ thống bị ảnh hưởng và mô tả về lỗ hổng là đủ, nhưng các lỗ hổng phức tạp có thể cần giải thích thêm.

Những gì chúng tôi hứa:

Chúng tôi sẽ phản hồi báo cáo của bạn trong vòng 3 ngày làm việc kèm đánh giá của chúng tôi về báo cáo và ngày dự kiến giải quyết,
Nếu bạn đã làm theo các hướng dẫn trên, chúng tôi sẽ không có bất kỳ hành động pháp lý nào chống lại bạn liên quan đến báo cáo,
Chúng tôi sẽ xử lý báo cáo của bạn với sự bảo mật nghiêm ngặt và không chuyển thông tin cá nhân của bạn cho bên thứ ba nếu không có sự cho phép của bạn,
Chúng tôi sẽ thông báo cho bạn về tiến độ giải quyết vấn đề,
Trong thông tin công khai liên quan đến vấn đề được báo cáo, chúng tôi sẽ nêu tên bạn là người phát hiện vấn đề (trừ khi bạn muốn khác), và
Như một biểu hiện của lòng biết ơn đối với sự giúp đỡ của bạn, chúng tôi trao phần thưởng cho mỗi báo cáo về một vấn đề bảo mật mà chúng tôi chưa biết. Mức thưởng sẽ được xác định dựa trên mức độ nghiêm trọng của sự rò rỉ và chất lượng báo cáo. Mức thưởng tối thiểu là một phiếu quà tặng trị giá 50 euro.

Chúng tôi cố gắng giải quyết mọi vấn đề càng nhanh càng tốt, và chúng tôi muốn đóng vai trò tích cực trong bài công bố cuối cùng về vấn đề sau khi nó được giải quyết.

Ví dụ: Fox-IT

Tại Fox-IT, chúng tôi coi an ninh của hệ thống, mạng và sản phẩm của mình là cực kỳ quan trọng. Dù chúng tôi rất cẩn trọng về bảo mật, vẫn có thể còn những điểm yếu. Nếu bạn đã tìm thấy một điểm yếu như vậy, chúng tôi muốn được nghe càng sớm càng tốt để có thể thực hiện các biện pháp phù hợp nhanh nhất có thể.

Các điểm yếu có thể được phát hiện theo hai cách: bạn có thể vô tình bắt gặp điều gì đó khi sử dụng bình thường một môi trường số, hoặc bạn có thể chủ động nỗ lực hết sức để tìm ra chúng.

Chính sách công bố có trách nhiệm của chúng tôi không phải là lời mời chủ động quét mạng kinh doanh của chúng tôi để phát hiện điểm yếu. Chúng tôi tự giám sát mạng kinh doanh của mình. Điều này có nghĩa là rất có khả năng việc quét sẽ bị phát hiện, và Trung tâm Điều hành An ninh (SOC) của chúng tôi sẽ tiến hành điều tra, điều có thể gây ra chi phí không cần thiết. Tuy nhiên, bạn được mời chủ động tìm kiếm lỗ hổng trong các sản phẩm của chúng tôi trong một môi trường ngoại tuyến không phải môi trường sản xuất và báo cáo các phát hiện của bạn cho chúng tôi. Trách nhiệm của chúng tôi đối với khách hàng có nghĩa là chúng tôi không có ý định khuyến khích các nỗ lực tấn công hạ tầng của họ; tuy nhiên, chúng tôi muốn nghe từ bạn càng nhanh càng tốt nếu tìm thấy lỗ hổng, để có thể giải quyết chúng một cách thỏa đáng.

Chúng tôi muốn làm việc với bạn để có thể bảo vệ khách hàng và hệ thống của mình tốt hơn.

Chúng tôi đề nghị bạn:

Gửi email các phát hiện của bạn càng nhanh càng tốt đến security-alert@fox-it.com.
Không lợi dụng lỗ hổng; chẳng hạn bằng cách tải xuống, chỉnh sửa hoặc xóa dữ liệu. Chúng tôi luôn xem xét báo cáo của bạn một cách nghiêm túc và điều tra mọi nghi ngờ về lỗ hổng, kể cả khi không có bằng chứng.
Không chia sẻ vấn đề với người khác cho đến khi nó được giải quyết.
Không dùng các cuộc tấn công vào an ninh vật lý, kỹ thuật xã hội hay các công cụ tấn công, chẳng hạn trình quét lỗ hổng.
Cung cấp đủ thông tin để có thể tái hiện vấn đề để chúng tôi giải quyết nó nhanh nhất có thể. Thường thì địa chỉ IP hoặc URL của hệ thống bị ảnh hưởng và mô tả về lỗ hổng là đủ, mặc dù các lỗ hổng phức tạp hơn có thể cần thêm thông tin.

Những gì chúng tôi hứa:

Chúng tôi sẽ phản hồi báo cáo của bạn trong vòng ba ngày làm việc, kèm đánh giá của chúng tôi về báo cáo và ngày dự kiến giải quyết.
Chúng tôi sẽ xử lý báo cáo của bạn một cách bí mật và sẽ không chia sẻ thông tin cá nhân của bạn với bên thứ ba nếu không có sự cho phép của bạn. Ngoại lệ là cảnh sát và cơ quan tư pháp trong trường hợp truy tố hoặc khi thông tin bị yêu cầu.
Chúng tôi sẽ thông báo cho bạn về tiến độ giải quyết vấn đề.
Khi trao đổi về vấn đề được báo cáo, chúng tôi sẽ nêu tên bạn là bên đã phát hiện vấn đề, nếu bạn muốn.
Rất tiếc không thể đảm bảo trước rằng sẽ không có hành động pháp lý nào chống lại bạn. Chúng tôi hy vọng có thể xem xét từng tình huống riêng biệt. Chúng tôi tự coi mình có nghĩa vụ đạo đức phải tố giác bạn nếu nghi ngờ điểm yếu hoặc dữ liệu đang bị lạm dụng, hoặc bạn đã chia sẻ hiểu biết về điểm yếu với người khác. Bạn có thể yên tâm rằng một phát hiện tình cờ trong môi trường trực tuyến của chúng tôi sẽ không dẫn đến truy tố.
Để cảm ơn sự giúp đỡ của bạn, chúng tôi trao phần thưởng cho mỗi báo cáo về một vấn đề bảo mật mà chúng tôi chưa biết. Chúng tôi xác định giá trị phần thưởng dựa trên mức độ nghiêm trọng của vụ xâm phạm và chất lượng báo cáo.

Chúng tôi cố gắng giải quyết mọi vấn đề càng nhanh càng tốt, thông báo cho tất cả các bên liên quan, và chúng tôi muốn tham gia vào bất kỳ bài công bố nào về vấn đề sau khi nó được giải quyết.

Ví dụ: Bits of Freedom

Sự phụ thuộc của chúng ta vào hạ tầng số ngày càng tăng. Điều này đúng với toàn xã hội, nhưng cũng đúng với chính chúng tôi. Vì vậy, chúng tôi cho rằng các chính phủ và tổ chức (bao gồm cả tổ chức của chúng tôi) nên cam kết mạnh mẽ trong việc bảo vệ hạ tầng số của chúng ta. Chúng tôi nhận thức rõ rằng, dù có ý định tốt nhất và sự cẩn trọng lớn nhất, vẫn có thể tồn tại các lỗ hổng trong hệ thống của chúng tôi. Nếu bạn tình cờ tìm thấy một trong những điểm yếu này, chúng tôi rất muốn nghe từ bạn để có thể giải quyết vấn đề.

Những gì chúng tôi mong đợi ở bạn

Khi bạn điều tra một trong các hệ thống của chúng tôi, hãy cân nhắc tính tương xứng của cuộc tấn công. Không cần phải chứng minh rằng khi bạn tung cuộc tấn công DDoS lớn nhất lịch sử Internet vào trang web của chúng tôi, trang web có thể trở nên không truy cập được. Chúng tôi biết điều đó. Chúng tôi cũng hiểu rằng nếu bạn lái một chiếc xe ủi vào văn phòng của chúng tôi, bạn có thể sẽ chộp được một trong những chiếc máy tính xách tay của chúng tôi.
Nguyên tắc tương xứng này cũng áp dụng khi chứng minh chính lỗ hổng. Bạn không nên kiểm tra hay sửa đổi nhiều dữ liệu hơn mức thực sự cần thiết để xác nhận phát hiện của bạn là đúng. Chẳng hạn, nếu bạn có thể sửa trang chủ của chúng tôi, hãy chỉ thêm một từ không gây tranh cãi thay vì chiếm quyền cả trang. Nếu bạn có thể truy cập một cơ sở dữ liệu, chỉ cần cho chúng tôi xem danh sách các bảng trong đó, hoặc có lẽ là bản ghi đầu tiên trong một trong các bảng đó.
Lỗ hổng trong một trong các hệ thống của chúng tôi nên được báo cáo càng sớm càng tốt bằng cách gửi email đến security@bof.nl. Tốt nhất là bạn mã hóa thư của mình bằng OpenPGP. Vui lòng cung cấp đủ thông tin để chúng tôi có thể tái hiện và điều tra vấn đề.
Khóa công khai OpenPGP của security@bof.nl
Bạn sẽ không chia sẻ hiểu biết của mình về lỗ hổng với các bên khác chừng nào chúng tôi chưa xử lý vấn đề và chúng tôi vẫn còn trong khung thời gian hợp lý kể từ khi bạn báo cáo vấn đề.
Bạn sẽ xóa mọi thông tin bí mật mà bạn thu được trong quá trình điều tra ngay khi chúng tôi giải quyết xong lỗ hổng.

Những gì bạn có thể mong đợi ở chúng tôi

Chúng tôi sẽ phản hồi báo cáo của bạn trong vòng ba ngày một cách chi tiết. Chúng tôi sẽ kèm theo ước tính thời gian cần thiết để xử lý vấn đề. Tất nhiên, chúng tôi sẽ thường xuyên cập nhật cho bạn về tiến độ của mình.
Chúng tôi sẽ giải quyết lỗ hổng càng sớm càng tốt. Ở đây tính tương xứng cũng quan trọng: thời gian cần để sửa một lỗ hổng phụ thuộc vào nhiều yếu tố, trong đó có mức độ nghiêm trọng và độ phức tạp của vấn đề đang xét.
Khi bạn tuân theo các hướng dẫn được nêu ở đây, chúng tôi sẽ không có hành động pháp lý nào chống lại bạn liên quan đến báo cáo của bạn.
Việc ghi nhận công sức của bạn là quan trọng với chúng tôi - nếu bạn muốn. Chúng tôi chỉ nêu tên bạn trong bài công bố về lỗ hổng nếu bạn đồng ý.
Để cảm ơn bạn đã giúp chúng tôi bảo vệ hệ thống tốt hơn, chúng tôi muốn thưởng cho mọi báo cáo về lỗ hổng mà chúng tôi chưa biết vào thời điểm đó. Phần thưởng sẽ phụ thuộc vào mức độ nghiêm trọng của lỗ hổng và chất lượng báo cáo.
Nếu bạn tìm thấy lỗ hổng trong phần mềm của bên thứ ba mà chúng tôi sử dụng và lỗ hổng đó thuộc phạm vi một chương trình bug bounty, chúng tôi sẽ không cố đòi khoản thưởng đó; bạn nên làm vậy.