Báo cáo là phần tồn tại lâu dài của một đợt kiểm thử xâm nhập (penetration test). Việc kiểm thử diễn ra trong vài ngày hoặc vài tuần; báo cáo là thứ mà lập trình viên dựa vào để sửa lỗi, ban lãnh đạo đọc và doanh nghiệp có thể chia sẻ với khách hàng hoặc đối tác. Một báo cáo yếu có thể khiến một đợt kiểm thử cẩn thận trông sơ sài, trong khi một báo cáo rõ ràng biến các phát hiện thành quyết định. Hướng dẫn này giải thích một báo cáo kiểm thử xâm nhập chuyên nghiệp thường gồm những gì, cách đọc báo cáo và những điều cần yêu cầu trước khi bắt đầu hợp đồng.
Đây là gì
Báo cáo kiểm thử xâm nhập là bản ghi bằng văn bản về những gì đã được kiểm thử, kiểm thử như thế nào, trong điều kiện nào và đã phát hiện ra điều gì. Báo cáo cần đọc được với hai nhóm đối tượng. Các bên liên quan không chuyên về kỹ thuật cần một bản tóm tắt ngắn về rủi ro tổng thể, các vấn đề quan trọng nhất và những ưu tiên được khuyến nghị. Các nhóm kỹ thuật cần đủ chi tiết về từng phát hiện để hiểu, tái hiện trong môi trường an toàn và sửa lỗi. Một báo cáo tốt cũng ghi lại các giới hạn của chính nó: những gì nằm ngoài phạm vi, những gì không thể kiểm thử và mọi điều kiện ảnh hưởng đến mức độ bao phủ, chẳng hạn không có tài khoản kiểm thử hoặc khung thời gian bị rút ngắn. Thiếu những giới hạn này, người đọc có thể cho rằng báo cáo bao quát nhiều hơn thực tế.
Dành cho ai
Hướng dẫn này hữu ích cho:
- Bên mua đang so sánh các đề xuất và muốn biết thực sự sẽ nhận được sản phẩm bàn giao nào
- Trưởng nhóm kỹ thuật sẽ nhận các phát hiện và cần lập kế hoạch khắc phục
- Nhà quản lý phải chia sẻ bản tóm tắt với khách hàng, đối tác, kiểm toán viên hoặc hội đồng quản trị mà không phóng đại kết quả
- Các nhóm đã từng nhận một báo cáo và thấy khó hành động dựa trên báo cáo đó
Giúp làm rõ điều gì
Nắm được cấu trúc mong đợi giúp kiểm tra:
- Phạm vi và quy tắc thực hiện (rules of engagement) trong báo cáo có khớp với những gì đã thống nhất hay không
- Mỗi phát hiện có bằng chứng, mức độ nghiêm trọng rõ ràng và hướng dẫn khắc phục thiết thực hay không
- Vấn đề nào cần hành động ngay và vấn đề nào có thể đưa vào kế hoạch của các chu kỳ phát triển thông thường
- Nội dung nào an toàn để chia sẻ ra bên ngoài và nội dung nào chỉ dành cho đội ngũ kỹ thuật
Những gì được bao gồm
- Tóm tắt cho lãnh đạo: bức tranh tổng thể, các phát hiện quan trọng nhất và những ưu tiên được khuyến nghị bằng ngôn ngữ dễ hiểu
- Phạm vi và quy tắc thực hiện: mục tiêu, môi trường, vai trò người dùng, ngày tháng, khung thời gian kiểm thử và các mục loại trừ
- Tóm tắt phương pháp: cách tiếp cận và các khung tham chiếu đã sử dụng, chẳng hạn hướng dẫn OWASP cho ứng dụng web
- Danh mục phát hiện: mỗi vấn đề có tiêu đề, mức độ nghiêm trọng, tài sản bị ảnh hưởng, mô tả, tham chiếu bằng chứng và tác động đến hoạt động kinh doanh
- Chi tiết kỹ thuật: các bước đội ngũ có thể dùng để hiểu và tái hiện vấn đề một cách an toàn
- Hướng dẫn khắc phục: các biện pháp sửa lỗi thiết thực và, khi hữu ích, các biện pháp giảm thiểu ngắn hạn
- Giới hạn: những gì không thể kiểm thử và lý do
- Phần kiểm thử lại: tình trạng của các phát hiện đã thống nhất sau khi đội ngũ của bạn sửa, nếu có bao gồm kiểm thử lại
Những gì không được bao gồm
- Tuyên bố rằng hệ thống an toàn hoặc không còn lỗ hổng nào sau khi kiểm thử
- Các phát hiện ngoài phạm vi đã thống nhất được trình bày như thể đã được kiểm thử
- Chứng nhận, phê duyệt tuân thủ hoặc ý kiến kiểm toán chính thức
- Triển khai các bản sửa lỗi, trừ khi được thỏa thuận riêng
Khi nào nên chọn
Hãy đọc hướng dẫn này trước khi ký một đề xuất kiểm thử, để có thể yêu cầu báo cáo mẫu và xác nhận cấu trúc. Hướng dẫn cũng hữu ích khi nhận được báo cáo: dùng các mục ở trên làm danh mục kiểm tra để xem có thiếu gì không. Nếu một bên liên quan yêu cầu "gửi báo cáo pentest", hãy quyết định trước xem họ cần toàn bộ tài liệu kỹ thuật hay chỉ cần bản tóm tắt cho lãnh đạo và một thư xác nhận tình trạng khắc phục. Chia sẻ rộng rãi toàn bộ chi tiết kỹ thuật làm tăng rủi ro, vì tài liệu đó mô tả các điểm yếu trong hệ thống của bạn.
Phương pháp của chúng tôi
Hãy yêu cầu làm rõ cách xếp mức độ nghiêm trọng trước khi bắt đầu kiểm thử. Nhiều nhà cung cấp dùng thang đo dựa trên khả năng xảy ra và mức độ tác động, đôi khi tham chiếu CVSS; điều quan trọng là thang đo nhất quán và được giải thích. Thống nhất cách lưu trữ và chia sẻ bằng chứng, cũng như các đầu mối liên hệ được chỉ định. Khi nhận được báo cáo, hãy lên lịch một buổi trao đổi kết quả để lập trình viên có thể đặt câu hỏi khi bối cảnh còn mới. Chuyển danh mục phát hiện thành các ticket có người phụ trách và ngày mục tiêu, và sửa các vấn đề có mức độ nghiêm trọng cao nhất trước. Sau đó yêu cầu kiểm thử lại các phát hiện đã thống nhất để báo cáo ghi nhận những gì đã được giải quyết. Dịch vụ Penetration Testing của chúng tôi bàn giao bản tóm tắt cho lãnh đạo, bản tóm tắt phạm vi và quy tắc thực hiện, danh mục phát hiện được xếp theo mức độ nghiêm trọng kèm tham chiếu bằng chứng, chi tiết kỹ thuật cho từng phát hiện, lộ trình khắc phục theo thứ tự ưu tiên và kết quả kiểm thử lại nếu có bao gồm kiểm thử lại. Dù chọn nhà cung cấp nào, hãy lưu từng phiên bản báo cáo, ghi lại những phát hiện được chấp nhận như rủi ro thay vì được sửa và ghi chú người đã đưa ra quyết định đó. Hồ sơ đó thường có giá trị không kém chính đợt kiểm thử khi lần tới có người hỏi về tình trạng bảo mật của doanh nghiệp.
Câu hỏi thường gặp
Bài viết liên quan
Bắt đầu
Quý doanh nghiệp muốn một báo cáo mà đội ngũ thực sự hành động được?
Hãy cho chúng tôi biết những hệ thống nào cần kiểm thử và ai sẽ đọc kết quả. Chúng tôi sẽ xác nhận phạm vi, quy tắc thực hiện và cấu trúc báo cáo bằng văn bản.
Yêu cầu phạm vi bằng văn bản