Chính sách chương trình là yếu tố cần thiết đối với mọi VDP và cần phải được soạn thảo cẩn thận. Chính sách chương trình là điều đầu tiên mà các nhà nghiên cứu bảo mật quan tâm khi tham gia VDP. Tiêu chí này đặt ra bầu không khí của chương trình, xác định kỳ vọng và xác định cam kết của bạn với các nhà nghiên cứu chọn tham gia.
Cách tạo và lưu trữ chính sách chương trình
Hãy tham khảo các nguyên tắc bên dưới để soạn thảo chính sách chương trình cho VDP. Chính sách chương trình thường chỉ dài từ 1 đến 3 trang và thường bao gồm các chủ đề sau:
- Hứa hẹn của một nhà nghiên cứu
- Nguyên tắc kiểm thử
- Phạm vi của chương trình
Chính sách chương trình cần được cung cấp cho tất cả các nhà nghiên cứu tiềm năng. Nếu bạn có kế hoạch triển khai VDP ở chế độ riêng tư chỉ cho một số nhà nghiên cứu được mời, thì chính sách chương trình cần có một số biện pháp kiểm soát quyền truy cập để cung cấp VDP cho những nhà nghiên cứu bạn đã mời nhưng giới hạn cho tất cả những người khác. Nhà nghiên cứu cũng cần một cách để gửi báo cáo, chẳng hạn như một biểu mẫu web hoặc email đại diện kết nối với một hệ thống bán vé để theo dõi báo cáo. Hãy cân nhắc vấn đề này khi thiết lập tài nguyên trực tuyến của VDP.
Các nền tảng săn lỗi và công bố lỗ hổng bảo mật của bên thứ ba thường cung cấp các tính năng như:
- Phương thức để bạn tạo, chỉnh sửa và xuất bản chính sách
- Các chế độ kiểm soát quyền truy cập để tạo một chương trình riêng tư
- Tự động mời tin tặc theo tốc độ thoải mái
- Chức năng hộp thư đến hỗ trợ việc xử lý báo cáo đến
Các nền tảng bên thứ ba cũng cung cấp nhiều dịch vụ tư vấn để giúp đơn giản hoá quy trình tạo và triển khai VDP. Thông thường, các nền tảng và dịch vụ tư vấn của bên thứ ba đều phải trả phí. Hãy cân nhắc chi phí và lợi ích khi sử dụng bên thứ ba so với việc xây dựng và quản lý chương trình nội bộ để xác định lộ trình phù hợp nhất cho tổ chức của bạn.
Để có thêm cảm hứng về những nội dung cần đưa vào chính sách chương trình của bạn, hãy đọc "Khung chương trình thông báo lỗ hổng cho hệ thống trực tuyến" của Bộ Tư pháp Hoa Kỳ.
Các bên liên quan đến chính sách của chương trình
Khi bạn soạn thảo chính sách chương trình, hãy cân nhắc cách làm việc với các bên liên quan. Nhiều nhóm có thể đưa ra ý kiến về những yếu tố cần cân nhắc để xây dựng chính sách.
| Bên liên quan | Những yếu tố nên cân nhắc |
|---|---|
| Pháp lý |
|
| IT |
|
| Kỹ sư |
|
| PR |
|
| Bảo mật |
|
Cam kết của nhà nghiên cứu
Nhà nghiên cứu hứa hẹn sẽ giải thích cam kết của tổ chức đối với những nhà nghiên cứu làm việc thiện chí bằng cách làm theo các nguyên tắc kiểm thử nêu trong chính sách này. Ví dụ: cam kết phản hồi tất cả báo cáo bảo mật mà bạn nhận được trong một khung thời gian cụ thể, cũng như trao đổi về quyết định sẽ chấp nhận và khắc phục báo cáo lỗ hổng bảo mật.
Ví dụ:
<Tên tổ chức của bạn> cam kết hợp tác với các nhà nghiên cứu bảo mật để giúp xác định và khắc phục các lỗ hổng bảo mật trong các hệ thống và dịch vụ của chúng tôi. Miễn là bạn làm việc thiện chí và tuân thủ các nguyên tắc nêu trong chính sách này, chúng tôi sẽ nỗ lực hết sức để cam kết thực hiện những điều sau:- Phản hồi sơ bộ về báo cáo lỗ hổng trong vòng 3 ngày làm việc
- Xác định xem chúng tôi sẽ chấp nhận (dự định khắc phục) hay từ chối (xác định báo cáo của bạn là rủi ro dương tính giả hoặc rủi ro chấp nhận được) báo cáo lỗ hổng của bạn trong vòng 10 ngày làm việc
- Luôn cập nhật cho bạn tiến trình khắc phục lỗi dựa trên báo cáo mà chúng tôi chấp nhận từ bạn
Việc sử dụng ngôn từ che giấu an toàn trong chính sách chương trình giúp đảm bảo với các nhà nghiên cứu rằng họ sẽ không bị áp dụng biện pháp pháp lý nào để kiểm tra hệ thống của bạn, miễn là họ hành động một cách thành thực và tuân thủ mọi nguyên tắc được giải thích trong chính sách này.
Nguyên tắc kiểm thử
Nguyên tắc kiểm thử mô tả hoạt động kiểm thử bảo mật trong phạm vi của VDP cũng như hoạt động kiểm thử không thuộc phạm vi triển khai và các nhà nghiên cứu nên tránh. Nếu có các loại lỗ hổng cụ thể mà bạn muốn nhà nghiên cứu tập trung vào, thì phần này là nơi phù hợp để nêu bật chúng.
Ví dụ:
Khi thực hiện kiểm thử bảo mật, vui lòng tuân thủ các nguyên tắc sau đây:
- Chỉ thử nghiệm dựa trên tài khoản và dữ liệu của riêng bạn (ví dụ: tạo tài khoản thử nghiệm). Nếu bạn xác định lỗ hổng bảo mật có thể dẫn đến quyền truy cập vào dữ liệu của người dùng khác, vui lòng kiểm tra với chúng tôi trước khi kiểm thử thêm.
- Nếu bạn vô tình truy cập vào dữ liệu của người dùng khác trong quá trình kiểm thử, vui lòng cho chúng tôi biết và bạn không được lưu trữ bất kỳ dữ liệu người dùng nào như vậy.
- Không thực hiện kiểm thử dẫn đến việc từ chối các điều kiện cung cấp dịch vụ hoặc làm giảm chất lượng dịch vụ sản xuất của chúng tôi.
- Tấn công phi kỹ thuật nằm ngoài phạm vi của chương trình này; đừng tìm cách tấn công phi kỹ thuật đối với tổ chức hoặc người dùng của chúng tôi.
Chúng tôi đặc biệt quan tâm đến các loại lỗ hổng bảo mật
và tác động sau đây:
- Thực thi mã từ xa
- XSS dẫn đến quyền truy cập vào dữ liệu nhạy cảm (ví dụ: thông tin về phiên hoạt động)
- Chèn SQL dẫn đến quyền truy cập vào dữ liệu hoặc chức năng nhạy cảm
- Lỗi logic nghiệp vụ dẫn đến quyền truy cập vào chức năng hoặc dữ liệu nhạy cảm
Chúng tôi ít quan tâm đến các loại lỗ hổng bảo mật sau đây. Các loại lỗ hổng này có nhiều khả năng
bị từ chối do nhầm lẫn hoặc là rủi ro được chấp nhận:
- Thiếu tiêu đề X-Frame-Options trên các trang mà không có chức năng thay đổi trạng thái
- Kết quả của trình quét tự động chưa được xác minh
- Các sự cố không có khả năng bị khai thác và/hoặc không ảnh hưởng đến bảo mật thực tế
Phạm vi
Phạm vi này xác định những thành phần mà nhà nghiên cứu có thể thử nghiệm, cũng như những thành phần không được xem là một phần của VDP. Phạm vi này cần được xem xét cẩn thận và mở rộng nhất có thể mà không làm quá tải nhóm của bạn. Bạn càng sẵn sàng đưa vào phạm vi kiểm tra, thì bạn càng có nhiều khả năng được các nhà nghiên cứu bảo mật tương tác. Tuy nhiên, đừng mở rộng phạm vi đến mức nhóm của bạn không thể bắt kịp các báo cáo sắp tới. Hãy bắt đầu với một vài tài sản trong phạm vi. Hãy mở rộng phạm vi khi bạn hiểu rõ hơn về khối lượng báo cáo mà bạn sẽ nhận được. Trước khi công khai VDP, hãy cố gắng đưa ra mọi thông tin trong phạm vi.
Xét về cách xác định phạm vi trong chính sách chương trình, việc thêm thông tin chi tiết về từng tài sản hoặc khía cạnh sẽ giúp nhà nghiên cứu bảo mật biết nội dung nào quan trọng đối với bạn và nơi cần tập trung nỗ lực. Bạn cũng có thể đưa ra các mẹo về cách an toàn để kiểm thử các tài sản của bạn. Ví dụ:
| Asset | mail.example.com |
|---|---|
| Nội dung mô tả | Miền chính để người dùng truy cập vào email của họ. |
| Các lỗ hổng và tác động thú vị |
|
| Các vấn đề có thể bị từ chối |
|
| Nguyên tắc thử nghiệm | Bạn chỉ được thử nghiệm trên những tài khoản bạn sở hữu hoặc có sự đồng ý rõ ràng để thử nghiệm. Khi tạo tài khoản thử nghiệm, vui lòng bao gồm "vdptest" ở vị trí nào đó trong tên người dùng. Bạn có thể tạo tài khoản thử nghiệm tại mail.example.com/new. |
Đây là bảng phân tích khá chi tiết. Ngoài ra, bạn có thể thêm một danh sách đơn giản gồm các thành phần thuộc phạm vi và ngoài phạm vi:
Trong phạm vi
- mail.example.com
- example.com
Ngoài phạm vi
- blog.example.com
Chuẩn bị nhân lực cho VDP
Bạn cần chuẩn bị sẵn một số nguồn lực trước khi triển khai VDP. Bạn sẽ cần các tài nguyên để:
- Xem xét báo cáo lỗ hổng được gửi đến
- Giao tiếp với tin tặc
- Tìm chủ sở hữu tài sản và báo cáo lỗi
- Sửa lỗi
- Quản lý lỗ hổng / theo dõi biện pháp khắc phục
Xem lại các bên liên quan chính
Nếu chưa, hãy xem lại các cuộc trò chuyện với các bên liên quan chính mà bạn đã thảo luận với VDP trước đó để đảm bảo các thông tin đó thống nhất về tiến trình ra mắt VDP, cũng như sắp xếp mọi tài nguyên cần thiết cho việc triển khai. Ví dụ: bạn nên làm việc với trưởng nhóm kỹ thuật để đảm bảo các nhóm của họ sẵn sàng xử lý các lỗi bảo mật có thể xảy ra trong một vài tuần đầu tiên sau khi ra mắt. Trong nhóm bảo mật của bạn, hãy đảm bảo những cảnh báo phân loại trong hệ thống phát hiện và phản hồi của bạn biết rõ ngày ra mắt VDP, đồng thời cân nhắc việc phân bổ thêm thời gian và tài nguyên khi bắt đầu thử nghiệm. Bạn cũng cần xây dựng một nhóm để hỗ trợ các hoạt động hằng ngày của VDP.
Xây dựng nhóm của bạn
Để vận hành VDP, bạn cần thực hiện một lượng lớn công việc vận hành, gây gián đoạn. Nếu cố gắng xem xét, xác thực về mặt kỹ thuật và phản hồi mọi báo cáo lỗ hổng được gửi đến, cũng như gửi mọi lỗi, theo dõi trạng thái và tự mình trao đổi thông tin cập nhật cho các nhà nghiên cứu, bạn có thể bị kiệt sức. Ngay cả khi đội ngũ bảo mật của bạn không có đông đảo, hãy tìm tình nguyện viên có chuyên môn về bảo mật để giúp xây dựng một nhóm nhằm vận hành và vận hành VDP. Bạn vẫn cần có một "chủ sở hữu" hoặc "lãnh đạo" đã xác định của VDP, chịu trách nhiệm cuối cùng cho sự thành công của VDP, nhưng bạn cũng sẽ cần một nhóm hỗ trợ cho người lãnh đạo đó.
Xây dựng lịch làm việc
Khi bạn đã có sẵn tài nguyên và sẵn sàng trợ giúp về VDP, hãy xây dựng một số cấu trúc phía sau bằng cách thiết lập lịch biểu làm việc. Bạn có thể tạo chiến lược này tuỳ thích, nhưng xoay vòng hằng tuần là phương pháp khá phổ biến. Khi làm việc trong tuần, bạn có trách nhiệm:
- Triage (Phân loại) – xem xét các báo cáo lỗ hổng sắp tới
- Xác thực báo cáo về mặt kỹ thuật và đưa ra quyết định "chấp nhận" hay "từ chối"
- Thông báo quyết định của bạn cho tin tặc báo cáo vấn đề
- Nếu cần, hãy yêu cầu tin tặc cung cấp thêm thông tin nếu bạn không thể tái hiện vấn đề
- Nếu lỗ hổng bảo mật hợp lệ, hãy gửi lỗi được chú ý đến đúng chủ sở hữu
- Quản lý lỗ hổng – phát hiện các lỗ hổng hiện có
- Xem xét các lỗi được gửi từ các tuần làm nhiệm vụ trước đây để đảm bảo đang tiến hành khắc phục dựa trên các tiêu chuẩn về mức độ nghiêm trọng và tiến trình sửa lỗi.
- Sử dụng các mẹo tìm chủ sở hữu để giúp thuyết phục chủ sở hữu xử lý các lỗi này
- Trao đổi thông tin – cung cấp thông tin cập nhật cho nhà nghiên cứu bảo mật về các báo cáo hiện có
- Nhà nghiên cứu có thể chủ động yêu cầu thông tin cập nhật về các báo cáo hiện có; kiểm tra điều này và phản hồi nếu cần
- Nếu lỗ hổng bảo mật được khắc phục, hãy thông báo cho nhà nghiên cứu để họ biết nỗ lực của họ đã mang lại thay đổi tích cực cho tổ chức của bạn. Thậm chí, bạn có thể bao gồm ngôn ngữ mẫu để yêu cầu nhà nghiên cứu cho bạn biết liệu bạn có bỏ lỡ bất kỳ điều gì trong bản sửa lỗi không, hoặc liệu bản sửa lỗi của bạn có thể bỏ qua bằng cách nào đó hay không.
Tuỳ thuộc vào số lượng báo cáo bạn nhận được, mức độ phức tạp của những báo cáo này và kỹ năng cũng như kiến thức của từng cá nhân làm nhiệm vụ, việc trực tiếp thực hiện có thể kéo dài từ vài giờ cho đến cả tuần. Sau đây là một số mẹo để xoay vòng thành công trong công việc:
- Đảm bảo nhóm của bạn đã sẵn sàng tham gia và hỗ trợ công việc trong những tuần đặc biệt nặng.
- Có sẵn quy trình bàn giao bàn giao hiệu quả; nếu có vấn đề cần người phụ trách nhiệm vụ tiếp theo xử lý ngay lập tức, hãy viết một số ghi chú bàn giao hoặc trò chuyện trực tiếp vào cuối tuần.
- Tạo lịch biểu tự động để đảm bảo mọi người biết khi nào họ làm việc. Việc này có thể đơn giản như tạo các mục trong lịch định kỳ cho từng cá nhân.
- Đặc biệt là trước khi bắt đầu VDP, hãy kiểm tra kỹ với nhân viên phụ trách để đảm bảo họ nhớ đây là tuần của họ và xem họ có cần trợ giúp không. Nếu bạn có nhiều tài nguyên chưa thành thạo về việc xoay vòng, hãy bố trí thêm các tài nguyên chuyên nghiệp hơn để đảm bảo họ cảm thấy thoải mái và có thể đặt câu hỏi khi chúng tăng tốc.
- Có quy trình linh hoạt hoán đổi các tuần. Chắc hẳn một người nào đó sẽ gặp tình trạng khẩn cấp và cần nghỉ ngơi trong tuần, hoặc một người nào đó sẽ đi nghỉ, v.v. Khi điều này xảy ra, hãy khuyến khích cả nhóm đổi tuần khi cần để hoàn thành lịch biểu của mọi người.
- Tạo một "bản tóm tắt" công việc nêu ra những nhiệm vụ phải làm, bao gồm cả tài liệu về cách thực hiện.
Quyết định sự lựa chọn nội bộ so với bên thứ ba
Cho đến nay, hầu hết các hướng dẫn đều dựa trên việc bạn xây dựng và chạy VDP nội bộ. Có nhiều dịch vụ tư vấn và nền tảng có sẵn có thể hỗ trợ bạn tạo và chạy VDP. Các bên thứ ba này thường tốn chi phí, nhưng họ có thể giúp bạn hướng dẫn cách tạo, triển khai và vận hành VDP. Một số công cụ thậm chí còn cung cấp dịch vụ phân loại để giúp bạn xem xét các báo cáo lỗ hổng sắp tới, giúp xử lý việc giao tiếp với tin tặc và chỉ chuyển báo cáo hợp lệ cho nhóm của bạn. Việc quyết định xem bạn tự xây dựng quy trình này hay sử dụng nền tảng của bên thứ ba sẽ phụ thuộc vào các yêu cầu và nguồn lực hiện có của bạn. Nếu ngân sách của bạn lớn nhưng số lượng nhân viên không nhiều, thì việc tận dụng một bên thứ ba để giúp chạy chương trình có thể là điều hợp lý. Nếu ngược lại, bạn nên đầu tư thời gian để tự xây dựng chương trình.
Đang nhận báo cáo
Nếu bạn quyết định sử dụng nền tảng của bên thứ ba, họ phải có một cách để tin tặc gửi báo cáo trực tiếp cho bạn. Nếu tự xây dựng chương trình thì bạn sẽ phải tự xây dựng. Đây có thể là địa chỉ email tự động tạo phiếu yêu cầu hỗ trợ hoặc lỗi trong công cụ theo dõi lỗi (ví dụ: security@example.com), hoặc có thể là biểu mẫu trên web với các trường biểu mẫu bắt buộc được liên kết từ hoặc trên cùng một trang với chính sách chương trình của bạn. Dù sử dụng hình thức nào, đây là cơ hội tốt nhất để bạn có thể thông báo cho tin tặc theo định dạng mà bạn muốn nhận được báo cáo. Xin lưu ý rằng việc yêu cầu tin tặc gửi báo cáo theo một định dạng nhất định không phải lúc nào cũng đảm bảo rằng họ sẽ gửi báo cáo, nhưng bạn không nhất thiết phải yêu cầu. Dưới đây là ví dụ về những điều bạn có thể yêu cầu trong biểu mẫu gửi báo cáo:
Tiêu đề: [Vui lòng thêm một dòng mô tả về vấn đề, ví dụ: "XSS trong mail.example.com
dẫn đến hành vi đánh cắp phiên"]
1.
2.
3.
Kịch bản tấn công và tác động: [Tính năng này có thể bị lợi dụng như thế nào? Vấn đề
này có ảnh hưởng gì đến bảo mật?]
Lời khuyên về cách khắc phục: [Bạn có thể đưa ra lời khuyên về cách khắc phục hoặc khắc phục vấn đề này tại đây.]