Chi phí pentest: Yếu tố quyết định giá và cách đọc báo giá

“Một đợt pentest giá bao nhiêu?” là câu hỏi hợp lý nhưng chưa đủ dữ kiện, giống hỏi xây một căn nhà bao nhiêu tiền mà chưa nói diện tích, nền đất và mức hoàn thiện. Nhà cung cấp trả ngay một con số thường đang giả định phạm vi rất hẹp hoặc bán một gói cố định. Với người mua, vấn đề không phải tìm con số thấp nhất; vấn đề là biết mỗi báo giá đang bao phủ cái gì, bỏ lại cái gì và kết quả có giúp giảm rủi ro hay không.

Bài này không đưa khoảng giá thị trường vì không có bộ dữ liệu công khai, đại diện và có thể kiểm chứng cho dịch vụ pentest tại Việt Nam. Thay vào đó, nó cung cấp mô hình dự toán và checklist đọc báo giá để CTO, IT Manager hay procurement so sánh đúng mặt bằng. Nếu cần nền tảng khái niệm trước, hãy đọc penetration testing là gì.

Bạn đang mua ngày công, độ phủ hay mức giảm rủi ro?

Nhà cung cấp thường ước lượng bằng ngày công chuyên gia, sau đó điều chỉnh theo độ phức tạp, kỹ năng cần thiết, quản lý dự án và đầu ra. Nhưng người mua không nên đánh đồng nhiều ngày công với chất lượng. Một scope rõ và tester đúng chuyên môn có thể tạo giá trị hơn engagement dài nhưng dành nhiều giờ cho scanning, chờ quyền truy cập hoặc kiểm tra những chức năng không quan trọng. Câu hỏi cần hỏi là: đội kiểm thử sẽ dùng thời gian vào attack surface và kịch bản rủi ro nào?

NIST SP 800-115 nhấn mạnh việc lập kế hoạch, tiến hành kiểm thử, phân tích phát hiện và phát triển biện pháp giảm thiểu. Điều đó phản ánh một engagement đầy đủ: scoping và rules of engagement trước khi chạm hệ thống; execution có kiểm soát; phân tích tác động; báo cáo cho đúng đối tượng; rồi xử lý và xác minh. Một tool report xuất tự động chỉ bao phủ một lát rất mỏng của chuỗi này.

Mười yếu tố thực sự quyết định chi phí pentest

• Loại tài sản. Web, API, mobile, cloud, internal network, external perimeter và thick client cần kỹ năng, thiết bị và phương pháp khác nhau.
• Kích thước attack surface. Số ứng dụng, host, API operation, tenant, luồng nghiệp vụ và tích hợp quan trọng hơn con số “màn hình”.
• Số vai trò và mô hình phân quyền. User, manager, admin, partner, support hoặc nhiều tenant tạo ra ma trận kiểm tra quyền ngang và quyền dọc.
• Độ phức tạp logic nghiệp vụ. Thanh toán, hạn mức, phê duyệt nhiều bước, khuyến mại, đối soát và workflow bất đồng bộ cần thời gian phân tích thủ công.
• Hình thức black/grey/white box. Thông tin, tài khoản, source code và tài liệu kiến trúc được cung cấp ảnh hưởng thời gian khám phá và độ sâu.
• Môi trường và dữ liệu. Production đòi hỏi giới hạn an toàn nghiêm hơn; staging sai khác production lại làm giảm độ tin cậy và cần thêm công đối chiếu.
• Công nghệ chuyên biệt. GraphQL, gRPC, WebSocket, OAuth/OIDC, Kubernetes, native mobile, firmware hoặc hệ thống legacy có thể cần tester chuyên môn.
• Yêu cầu tuân thủ và báo cáo. Mapping theo ASVS, PCI DSS hoặc mẫu của khách hàng làm tăng công phân tích và biên tập, nếu đó là đầu ra thật sự cần.
• Điều phối và thời gian. Cửa sổ kiểm thử ngắn, ngoài giờ, nhiều timezone, quy trình phê duyệt phức tạp và yêu cầu onsite tạo thêm chi phí.
• Re-test và hỗ trợ khắc phục. Số vòng, thời hạn, phạm vi thay đổi và mức tư vấn cho dev phải được tính rõ thay vì để thành tranh cãi cuối dự án.

Cách mô tả phạm vi để nhận báo giá có thể so sánh

Một email chỉ ghi “pentest website công ty” buộc vendor đoán. Hãy cung cấp inventory đủ dùng nhưng chưa cần tiết lộ secrets: mục tiêu kinh doanh, URL/app, loại API, số endpoint hoặc operation ước tính, vai trò, tenant, workflow quan trọng, stack, tích hợp, môi trường, thời gian dự kiến và yêu cầu báo cáo. Đánh dấu phần chưa chắc chắn để nhà cung cấp đưa assumption hoặc discovery phase thay vì giả vờ precision.

Với procurement chính thức, dùng mẫu RFP và checklist scope pentest để mọi bidder phản hồi cùng cấu trúc. Nếu phạm vi chưa ổn định, yêu cầu tách option: baseline, recommended và hạng mục mở rộng. Cách này minh bạch trade-off hơn ép một con số trọn gói rồi phát sinh change request khi tester phát hiện thêm API hoặc vai trò.

Đọc một báo giá pentest từ trên xuống dưới

Trang giá chỉ là cuối phép tính. Trước nó phải có scope, out-of-scope, assumptions, methodology, timeline, team, deliverables, data handling, rules of engagement, re-test và commercial terms. OWASP Web Security Testing Guide là một khung công khai hữu ích cho web, nhưng câu “theo OWASP” vẫn quá rộng. Vendor cần nói họ dùng khung đó thế nào, điều chỉnh cho logic và công nghệ của hệ thống ra sao.

Chuẩn hóa ba báo giá mà không biến thành đấu giá ngày công

Tạo một scorecard có trọng số trước khi mở giá. Nhóm tiêu chí có thể gồm: hiểu phạm vi và rủi ro; phương pháp; kinh nghiệm tester; chất lượng báo cáo mẫu; an toàn engagement; bảo vệ dữ liệu; re-test; lịch; chi phí. Procurement, owner hệ thống và security chấm độc lập rồi thảo luận chênh lệch. Giá vẫn quan trọng, nhưng không nên được dùng để xóa mọi khác biệt về phạm vi và năng lực.

• Yêu cầu vendor ghi effort theo hạng mục, không nhất thiết lộ đơn giá cá nhân nhưng phải cho thấy thời gian phân bổ vào đâu.
• Gửi cùng một vòng Q&A cho mọi bidder; câu trả lời làm thay đổi scope phải được cập nhật cho tất cả.
• Đề nghị trình bày report mẫu đã ẩn danh và walkthrough một finding: từ phát hiện, xác minh, impact đến remediation.
• Phỏng vấn technical lead sẽ thực hiện hoặc QA engagement, không chỉ account manager.
• Tính total cost gồm thời gian nội bộ, môi trường, khắc phục và re-test; phí vendor không phải toàn bộ ngân sách.

Đừng quên phần ngân sách lớn nhất: khắc phục

Pentest tìm ra nợ bảo mật chứ không tự thanh toán nó. Lỗi phân quyền có thể cần đổi kiến trúc authorization; quản lý session có thể ảnh hưởng nhiều client; lỗ hổng logic đòi product owner sửa rule và test regression. Trước engagement, dành capacity cho triage, fix, QA và deployment. Đặt SLA nội bộ theo severity và exposure, nhưng cho phép security owner điều chỉnh theo bối cảnh thay vì chỉ nhìn điểm CVSS.

Re-test cần đúng phiên bản và đúng finding. Đội dev cung cấp commit/release, mô tả cách sửa và môi trường xác minh. Tester kiểm tra cả đường khai thác cũ lẫn bypass hợp lý, sau đó ghi trạng thái rõ: fixed, partially fixed, not fixed hoặc risk accepted. Nếu chấp nhận rủi ro, phải có người đủ thẩm quyền, lý do, biện pháp bù và ngày xem xét lại. Đây là nơi pentest nối vào quản trị thay vì kết thúc ở một file PDF.

Khi nào gói pentest giá thấp vẫn hợp lý?

Giá thấp không tự động là tệ. Một ứng dụng nhỏ, một vai trò, kiến trúc quen thuộc, tài liệu tốt và scope đóng có thể cần ít effort. Một retest giới hạn hoặc assessment tập trung vào thay đổi cụ thể cũng có thể rẻ hơn engagement toàn diện. Điều kiện là tên dịch vụ phải phản ánh đúng giới hạn. “Focused assessment cho module upload” không nên bị bán lại trong nội bộ như “toàn bộ nền tảng đã pentest”.

Ngược lại, automated vulnerability scan cũng có chỗ đứng trong chương trình liên tục. Nó giúp phát hiện phiên bản lỗi thời và cấu hình phổ biến với tần suất cao. Vấn đề chỉ xuất hiện khi mua scan nhưng kỳ vọng lỗi logic, authorization và chuỗi khai thác thủ công. Hãy xem bảng so sánh trong bài pentest và vulnerability scanning rồi ghi đúng loại assurance vào hợp đồng.

Kết luận: mua sự rõ ràng trước khi mua giờ kiểm thử

Chi phí pentest hợp lý là mức tiền cho độ phủ và chất lượng phù hợp với rủi ro, không phải con số giống mặt bằng truyền miệng. Người mua giỏi chuẩn bị scope, làm rõ assumption, đánh giá con người và đầu ra, rồi bảo vệ ngân sách khắc phục. Khi đó, báo giá trở thành một thiết kế engagement có thể kiểm chứng thay vì trò đoán xem vendor nào dám ghi con số thấp nhất.