Cách viết RFP và scope pentest: Checklist để nhận báo giá đúng

Một RFP pentest tệ tạo ra ba báo giá không thể so sánh: bên A tính quét web, bên B tính kiểm thử thủ công web và API, bên C cộng cả mobile nhưng bỏ re-test. Procurement nhìn ba tổng tiền rồi chọn “giá tốt”, trong khi kỹ thuật chỉ phát hiện sự khác biệt sau kickoff. Một RFP tốt không cần dài hàng chục trang; nó cần loại bỏ những giả định làm thay đổi effort, rủi ro và đầu ra.

RFP — Request for Proposal — là yêu cầu đề xuất dùng để nhà cung cấp trình bày cách họ giải quyết nhu cầu. Scope là ranh giới tài sản và hoạt động. Rules of Engagement (RoE) là luật vận hành an toàn. Ba thứ liên quan nhưng không thay thế nhau. Bài này đưa ra cấu trúc có thể copy sang tài liệu nội bộ, đồng thời giải thích vì sao từng mục tồn tại để mày không biến checklist thành nghi lễ.

1. Bắt đầu từ mục tiêu, không bắt đầu từ tên công cụ

Mở RFP bằng bối cảnh và quyết định cần hỗ trợ: chuẩn bị go-live nền tảng thanh toán; đáp ứng yêu cầu assurance của khách hàng; kiểm chứng phân quyền multi-tenant sau đổi kiến trúc; hoặc đánh giá external perimeter sau M&A. Mục tiêu giúp vendor phân bổ effort. “Tuân thủ OWASP” chưa phải mục tiêu vì OWASP có nhiều dự án và mức kiểm chứng khác nhau.

• Mô tả dịch vụ và dữ liệu quan trọng bằng ngôn ngữ kinh doanh, không chỉ liệt kê stack.
• Nêu người dùng, tác động cần tránh và các abuse case đang lo ngại: truy cập chéo tenant, thao túng giao dịch, chiếm tài khoản, rò dữ liệu.
• Nêu trigger của engagement: go-live, thay đổi lớn, hợp đồng, audit hay chu kỳ quản trị rủi ro.
• Xác định audience của báo cáo: board, khách hàng, auditor, engineering hoặc nhiều nhóm với phiên bản khác nhau.
• Ghi success criteria: coverage đã thống nhất, finding tái hiện được, workshop bàn giao và re-test — không ép vendor phải tìm critical.

Nếu chưa chắc cần pentest, VA hay Red Team, giải quyết trước bằng ma trận Red Team vs Pentest vs Vulnerability Assessment. RFP không cứu được một loại engagement chọn sai; nó chỉ mô tả sai lầm rõ hơn.

2. Lập inventory đủ để vendor ước lượng

Vendor không cần secrets trong vòng RFP, nhưng cần hình dạng attack surface. Với web/API, cung cấp số ứng dụng, host, API operation hoặc spec, vai trò, tenant, workflow, tích hợp và loại authentication. Với mobile, nêu platform, số app/build, backend dùng chung, pinning hoặc anti-tamper. Với network/cloud, nêu dải IP, account/subscription/project, region, loại asset và mô hình truy cập.

Đừng dùng số trang web làm thước đo. Một SPA một màn hình có thể gọi hàng trăm API; một workflow hoàn tiền nhỏ có ma trận quyền phức tạp hơn website nội dung trăm trang. Nếu không có inventory API, hãy cân nhắc một discovery/scoping phase hoặc xuất spec từ gateway. Phần không biết phải được ghi là assumption để có cơ chế điều chỉnh có kiểm soát.

3. Chọn black box, grey box hay white box theo câu hỏi

Black box cho tester ít thông tin và hữu ích khi muốn nhìn từ ngoài, nhưng thời gian sẽ dành nhiều cho discovery. Grey box cung cấp tài khoản/tài liệu vừa đủ để tăng coverage logic và authorization; đây thường là lựa chọn thực dụng cho ứng dụng B2B. White box có source, kiến trúc hoặc cấu hình giúp đào sâu thiết kế, nhưng cần quy trình bảo vệ dữ liệu và làm rõ code review có nằm trong deliverable hay chỉ hỗ trợ pentest.

4. Viết Rules of Engagement để kiểm thử không thành sự cố

RoE cần được chủ hệ thống, security, vận hành và pháp lý phê duyệt trước khi bắt đầu. NIST SP 800-115 coi planning, logistics, legal và policy considerations là phần thiết yếu của technical security testing. Authorization phải xác định bên cho phép, tài sản, thời gian và hoạt động; một email mơ hồ từ người không sở hữu hệ thống không bảo vệ được tester hay doanh nghiệp.

• Cửa sổ và nguồn kiểm thử: ngày giờ, timezone, IP nguồn, VPN, maintenance window và blackout period.
• Kỹ thuật bị cấm/giới hạn: DoS, persistence, destructive action, exfiltration thật, phishing, physical test, pivot sang third party.
• Dữ liệu: dùng synthetic data khi có thể; quy tắc xem, chụp, tải, mã hóa, lưu và xóa bằng chứng nhạy cảm.
• Stop condition: dấu hiệu bất ổn, ảnh hưởng khách hàng, phát hiện asset ngoài scope hoặc yêu cầu từ control contact.
• Escalation: contact 24/7, mức severity phải báo ngay, kênh mã hóa và thời gian acknowledgement.
• Deconfliction: cách phân biệt test traffic với tấn công thật mà không vô hiệu hóa đội phòng thủ.
• Third-party: xác nhận quyền kiểm thử cloud/SaaS/integration và loại trừ tài sản doanh nghiệp không có quyền cho phép.

5. Khóa phương pháp và đầu ra đủ để dùng

Yêu cầu vendor mô tả cách kết hợp automation với manual testing, cách kiểm tra logic/authorization, cách xác minh false positive và cách QA. OWASP WSTG cung cấp testing framework cho web; OWASP ASVS có thể làm cơ sở yêu cầu kiểm chứng. Nếu map ASVS, ghi phiên bản và level/requirements cụ thể, vì câu “full OWASP” không có nghĩa hợp đồng rõ ràng.

• Executive summary: scope, risk themes, business impact, giới hạn và ưu tiên quyết định.
• Technical findings: điều kiện, bước tái hiện, evidence đã giảm dữ liệu nhạy cảm, impact, severity rationale và remediation.
• Scope coverage và limitations: phần đã/không thể kiểm tra, tài khoản lỗi, môi trường khác biệt, timebox.
• Raw/tool output chỉ là phụ lục khi cần, không được thay thế phân tích của tester.
• Readout workshop cho lãnh đạo và technical walkthrough cho owner sửa lỗi.
• Re-test report gắn với finding ID, version, trạng thái và bằng chứng xác minh.
• Attestation/letter nếu khách hàng cần, với wording không phóng đại rằng hệ thống “an toàn tuyệt đối”.

Yêu cầu report mẫu đã ẩn danh trước khi chấm thầu. Chọn một finding và xem liệu developer có thể sửa mà không cần đoán; xem executive summary có giúp lãnh đạo quyết định hay chỉ liệt kê CVSS. Bài chi phí và cách đọc báo giá pentest cung cấp scorecard chi tiết hơn cho phần commercial.

6. Đánh giá người thực hiện, không chỉ logo công ty

RFP nên hỏi team composition, technical lead, QA reviewer, kinh nghiệm với stack và domain, năng lực tiếng Việt/Anh cho workshop, cùng availability trong lịch. Chứng chỉ thực hành là một tín hiệu nhưng không thay thế report mẫu và phỏng vấn. Hỏi một tình huống: họ sẽ kiểm tra multi-tenant authorization hoặc workflow hoàn tiền ra sao; câu trả lời cho thấy cách tư duy rõ hơn danh sách tool.

7. Điều khoản thương mại và bảo mật không được để cuối cùng

NDA, data processing, ownership của report, quyền sử dụng evidence, subcontractor, retention, breach notification và secure deletion cần được pháp lý xem. Báo cáo pentest là bản đồ điểm yếu có giá trị với kẻ tấn công. Quy định cổng trao đổi mã hóa, ai được truy cập, vị trí lưu, thời hạn và xác nhận xóa. Vendor cần nêu có dùng AI hoặc dịch vụ bên thứ ba để xử lý dữ liệu/report không; doanh nghiệp phải chấp thuận trước nếu có.

Commercial terms phải nêu milestone, acceptance, change control, cancellation, payment, expense, thuế, số vòng re-test và thời hạn dùng re-test. Nếu app thay đổi lớn giữa test và re-test, đó có thể là scope mới; cơ chế xác định phải có trước. Đừng ép vendor fixed-price trên một inventory chưa rõ rồi ngạc nhiên khi proposal đầy exclusions.

8. Checklist trước khi phát hành RFP và trước kickoff

• Mục tiêu, audience và success criteria đã được owner kinh doanh/kỹ thuật phê duyệt.
• Ma trận scope có tài sản, môi trường, vai trò, workflow, API, integration và exclusions.
• Mọi bidder nhận cùng tài liệu, deadline, Q&A và mẫu phản hồi.
• RoE có authorization, cửa sổ, IP nguồn, kỹ thuật cấm, stop condition và escalation.
• Deliverables, report language, severity method, workshop và re-test được định nghĩa.
• Scorecard và trọng số được khóa trước khi mở commercial proposal.
• NDA/data handling/retention/subcontractor đã được rà soát.
• Trước kickoff: test account, seed data, backup, monitoring, contact và release freeze/change notice đã sẵn sàng.

Sau khi chọn vendor, lưu RFP, proposal, Q&A và RoE thành một baseline thống nhất. Nếu scope thay đổi, ghi change order với tác động effort và coverage. Khi nhận báo cáo, đối chiếu lại deliverables và limitations trước nghiệm thu; sau đó đưa finding vào quy trình remediation và ứng phó sự cố nếu bằng chứng cho thấy hệ thống đã có dấu hiệu bị khai thác ngoài engagement.

Kết luận: RFP tốt mua được sự minh bạch

RFP không cần khoe kiến thức bảo mật. Nó cần khiến các bên báo cùng một bài toán, phơi bày assumptions và cam kết đầu ra có thể nghiệm thu. Tổ chức làm tốt phần này sẽ nhận báo giá sát hơn, engagement an toàn hơn và báo cáo dễ chuyển thành hành động hơn. Quan trọng nhất, procurement và kỹ thuật ngừng tranh luận bằng tổng tiền của những gói vốn không giống nhau.