Chi phí đánh giá bảo mật website, web app và API

Vì sao không có một bảng giá chung cho mọi website?

Một website giới thiệu chỉ có vài form công khai khác hoàn toàn web app có đăng nhập, nhiều vai trò, thanh toán, upload file và API cho đối tác. Cùng một domain nhưng số trạng thái, quyền truy cập và hậu quả khi kiểm soát thất bại có thể chênh lệch rất lớn. Vì vậy báo giá theo số trang hoặc một gói quét cố định không thể hiện đúng công sức xác minh.

OWASP ASVS cung cấp các yêu cầu có thể dùng để xác định phạm vi và mức độ kiểm chứng; OWASP WSTG cung cấp phương pháp kiểm tra theo nhóm chức năng. Hai tài liệu này hữu ích để hai bên thống nhất kiểm soát nào cần xem xét, nhưng phạm vi cuối cùng vẫn phải dựa trên kiến trúc, dữ liệu, vai trò và mục tiêu kinh doanh của hệ thống cụ thể.

• ✓Số domain, ứng dụng, API và môi trường được phép kiểm tra.
• ✓Số vai trò, loại tài khoản và ma trận phân quyền cần đối chứng.
• ✓Luồng có hậu quả cao như thanh toán, thay đổi quyền, upload hoặc export dữ liệu.
• ✓Yêu cầu về thời gian, phối hợp vận hành và giới hạn tác động.

Một báo giá bảo mật có giá trị không bán số lượng lỗ hổng. Nó xác định mức bằng chứng cần tạo để đội kỹ thuật biết rủi ro nào phải sửa trước.

Sáu nhóm công việc quyết định chi phí đánh giá

Nhóm đầu tiên là discovery và lập phạm vi: kiểm kê tài sản, đọc tài liệu, xác định dữ liệu nhạy cảm, tạo tài khoản thử nghiệm và thống nhất rules of engagement. Tiếp theo là lập bản đồ ứng dụng, xác thực, phiên, phân quyền, điểm nhận dữ liệu, dependency và cấu hình quan sát được. Chuẩn bị tốt giúp thời gian kiểm tra được dành cho các giả thuyết quan trọng thay vì tìm lại thông tin cơ bản.

Phần kiểm tra gồm rà soát kỹ thuật, đối chứng thủ công tác động thấp và xác minh phát hiện. Chi phí còn bao gồm phân tích ảnh hưởng, viết bằng chứng tái hiện, hướng khắc phục, walkthrough và retest. NIST SP 800-115 xem lập kế hoạch, thực hiện kiểm tra, phân tích phát hiện và xây chiến lược giảm thiểu là các phần của một quy trình đánh giá hoàn chỉnh; báo cáo không nên chỉ là đầu ra tự động của scanner.

• ✓01. Discovery, tài sản, mục tiêu và giới hạn kiểm tra.
• ✓02. Lập bản đồ kiến trúc quan sát được và bề mặt tấn công.
• ✓03. Kiểm tra xác thực, phân quyền, dữ liệu nhập, cấu hình và luồng nghiệp vụ.
• ✓04. Xác minh để loại false positive và giữ bằng chứng tối thiểu cần thiết.
• ✓05. Báo cáo, ưu tiên, hướng khắc phục và walkthrough kỹ thuật.
• ✓06. Retest các thay đổi đã thống nhất và ghi nhận rủi ro còn lại.

Một báo giá bảo mật đáng tin phải ghi rõ điều gì?

Proposal nên liệt kê tài sản trong phạm vi và ngoài phạm vi, loại tài khoản được cung cấp, thời gian kiểm tra, môi trường, hành động bị cấm và đầu mối khi có dấu hiệu ảnh hưởng dịch vụ. Cần phân biệt quét tự động, rà soát cấu hình, kiểm tra thủ công và xác minh khả năng khai thác; dùng một nhãn chung nhưng không mô tả hoạt động sẽ khiến hai bên hiểu khác nhau về độ sâu.

Đầu ra phải nói rõ cách đánh mức rủi ro, dạng bằng chứng, nội dung executive summary, chi tiết cho developer, số buổi trao đổi và phạm vi retest. Hỏi thêm ai sở hữu dữ liệu kiểm tra, lưu bằng chứng trong bao lâu và cách xử lý thông tin nhạy cảm. Những chi tiết này bảo vệ cả doanh nghiệp lẫn đội thực hiện.

• ✓Danh sách domain, API, vai trò và chức năng ưu tiên.
• ✓Rules of engagement, cửa sổ kiểm tra và kênh dừng khẩn cấp.
• ✓Phương pháp, tiêu chuẩn tham chiếu và những gì không được cam kết.
• ✓Báo cáo, walkthrough, retest, thời hạn lưu và xóa bằng chứng.

Giảm chi phí mà không làm mất chất lượng bằng chứng

Doanh nghiệp có thể giảm thời gian discovery bằng cách chuẩn bị inventory, sơ đồ luồng, danh sách endpoint, ma trận vai trò và tài khoản thử nghiệm hoạt động được. Chọn một release ổn định, đóng các lỗi đã biết và đặt đầu mối kỹ thuật trả lời nhanh. Nếu ngân sách giới hạn, hãy ưu tiên tài sản chứa dữ liệu quan trọng và luồng có thể thay đổi tiền, quyền hoặc trạng thái nghiệp vụ.

Không nên giảm chi phí bằng cách bỏ xác minh hoặc retest. Một danh sách dài false positive làm đội phát triển tốn nhiều thời gian hơn khoản tiết kiệm ban đầu. Phạm vi nhỏ nhưng có baseline, đối chứng, bằng chứng tái hiện và thứ tự khắc phục thường tạo giá trị tốt hơn phạm vi rộng chỉ dựa vào scanner.

• ✓Chuẩn bị hai hoặc nhiều tài khoản để kiểm tra phân quyền giữa vai trò và đối tượng.
• ✓Cung cấp dữ liệu thử và cách khôi phục trạng thái an toàn.
• ✓Chốt trước luồng quan trọng thay vì yêu cầu kiểm tra mọi màn hình như nhau.
• ✓Gom thay đổi để retest một lần có kế hoạch thay vì xử lý rời rạc.

Khi nào security review phù hợp và khi nào cần Pentest độc lập?

Security review phù hợp trước khi ra mắt, sau thay đổi lớn về đăng nhập hoặc phân quyền, khi cần baseline cho web app chưa từng được xem xét, hoặc khi đội phát triển cần backlog khắc phục có ngữ cảnh. Một phạm vi tác động thấp cũng phù hợp khi hệ thống production nhạy cảm và doanh nghiệp cần bắt đầu bằng các kiểm tra an toàn hơn.

Nếu hợp đồng, khách hàng hoặc tuân thủ yêu cầu một báo cáo Pentest độc lập; nếu cần xác minh khai thác sâu, kiểm thử hạ tầng, social engineering hay Red Team; hãy chọn nhà cung cấp có năng lực, bảo hiểm, pháp lý và rules of engagement phù hợp. Friday Works hiện công khai dịch vụ đánh giá bảo mật website, web app và API theo phạm vi, không quảng cáo một chương trình Pentest hoặc Red Team đầy đủ.