Chọn đơn vị Security Audit website không nên dựa chủ yếu vào giá thấp nhất, số lượng tool hoặc một mẫu báo cáo nhiều trang. Điều quan trọng hơn là nhà cung cấp có hiểu đúng mục tiêu, scope, methodology, evidence, risk context và cách handoff finding sang remediation hay không.
Một assessment tốt phải giúp doanh nghiệp trả lời: đã kiểm tra cái gì, bằng cách nào, finding nào được xác minh, giới hạn ở đâu và đội kỹ thuật cần làm gì tiếp theo?
Bài này cung cấp checklist chọn đơn vị Security Audit website. Nếu bạn chưa chắc nên dùng đội nội bộ hay external expert, đọc trước Tự Security Audit hay thuê chuyên gia?.
Đánh giá Scope và Methodology trước khi nhìn vào giá
1. Bắt đầu từ Scope, không bắt đầu từ Báo giá
Hai báo giá chỉ có thể so sánh hợp lý khi scope tương đương.
Trước khi hỏi giá, cần xác định tối thiểu:
- domain/subdomain nào;
- production hay staging;
- website/CMS/API nào;
- có authenticated testing không;
- role/account nào;
- server/config có nằm trong scope không;
- third-party integration nào;
- kỹ thuật nào bị loại trừ.
Một báo giá “audit toàn bộ website” nhưng không định nghĩa asset và boundary rất khó đánh giá coverage.
Tham khảo thêm Security Audit Scope.
2. Hỏi rõ Deliverable trước khi ký
Đừng mặc định “Security Audit” luôn bao gồm cùng một đầu ra.
Nên hỏi nhà cung cấp sẽ bàn giao:
- executive summary;
- scope và limitation;
- finding summary;
- technical finding;
- evidence;
- severity/risk model;
- remediation direction;
- retest status hoặc retest report nếu nằm trong hợp đồng;
- appendix/tool output nếu cần.
Một deliverable tốt phải đủ cho management ra quyết định và technical team hành động.
3. Phân biệt Security Audit với Vulnerability Scan
Nếu nhà cung cấp mô tả quy trình chủ yếu là:
- nhập URL;
- chạy scanner;
- export PDF;
thì cần hỏi rõ assessment có manual review, finding validation và context analysis hay không.
Automated scanning hữu ích để tăng coverage và tìm signal, nhưng không thay thế hoàn toàn manual review cho:
- authorization;
- business logic;
- role;
- architecture;
- configuration context;
- false-positive validation.
Nếu cần phân biệt loại assessment, xem Security Audit vs Vulnerability Assessment vs Penetration Test.
4. Yêu cầu nhà cung cấp giải thích Methodology
Không cần yêu cầu tiết lộ mọi test case nội bộ, nhưng họ nên giải thích được workflow ở mức đủ rõ.
Một methodology hợp lý thường có:
Scope → Planning → Mapping → Control Review/Testing → Finding Validation → Risk Analysis → Reporting → Remediation Handoff → Retest
Nếu methodology chỉ mô tả tên tool mà không nói cách validate finding, đây là dấu hiệu cần hỏi thêm.
Tham khảo khung tại Website Security Audit Methodology.
5. Hỏi Manual Testing được áp dụng ở đâu
Không phải mọi finding đều cần manual exploitation. Nhưng nhà cung cấp nên giải thích họ dùng manual review cho domain nào.
Ví dụ:
- authentication;
- authorization;
- session;
- business workflow;
- configuration;
- API;
- admin access;
- candidate finding validation.
Nếu trả lời “tool của chúng tôi tự động kiểm tra 100%” thì nên thận trọng với tuyên bố tuyệt đối.
Đánh giá Validation, Evidence và Risk Model
6. Kiểm tra cách họ xử lý False Positive
Một audit có giá trị cần phân biệt:
- signal;
- candidate finding;
- validated finding;
- false positive;
- observation;
- duplicate.
Hãy hỏi:
“Một scanner alert cần trải qua bước nào trước khi xuất hiện trong report?”
Nếu mọi alert được copy thẳng vào report, remediation team sẽ phải tự làm việc validation thay cho auditor.
7. Hỏi Evidence của Finding sẽ như thế nào
Finding không nên chỉ có tên vulnerability và severity.
Evidence phù hợp có thể gồm:
- request/response;
- config excerpt;
- permission state;
- log;
- version evidence;
- screenshot đã redact;
- controlled reproduction context.
Nhà cung cấp nên có cách giữ evidence traceable và bảo vệ dữ liệu nhạy cảm.
Xem thêm Evidence trong Security Audit.
8. Hỏi Severity được tính thế nào
Nếu report dùng Critical/High/Medium/Low, cần biết định nghĩa.
Hỏi rõ:
- có dùng CVSS hay framework nội bộ;
- version nào nếu dùng CVSS;
- có xét asset context không;
- compensating control được ghi thế nào;
- technical severity có tách remediation priority không.
Không nên chọn vendor chỉ vì họ gắn nhiều finding “Critical”. Severity cao không tự động đồng nghĩa assessment tốt.
9. Đánh giá khả năng hiểu Business Context
Auditor không thể tự biết:
- workflow nào tạo doanh thu;
- dữ liệu nào nhạy cảm nhất;
- role nào được phép làm gì;
- asset nào critical;
- downtime impact;
- control nào là temporary.
Nhà cung cấp tốt nên hỏi các câu này trong scoping/onboarding thay vì chỉ nhận URL rồi chạy test.
Đánh giá năng lực đội thực hiện và QA
10. Kiểm tra Experience có phù hợp Scope không
Đừng chỉ hỏi “đã làm security bao nhiêu năm?”. Hãy hỏi kinh nghiệm liên quan tới chính architecture của bạn.
Ví dụ:
- WordPress/CMS;
- custom web application;
- API;
- e-commerce;
- SSO/OAuth;
- cloud infrastructure;
- WAF/CDN;
- server configuration;
- role-heavy portal.
Một tester rất mạnh ở network pentest không tự động là lựa chọn tốt nhất cho business-logic-heavy application, và ngược lại.
11. Certification có nên là tiêu chí bắt buộc?
Certification có thể là một tín hiệu về nền tảng kiến thức hoặc quá trình học, nhưng không nên là bằng chứng duy nhất về chất lượng assessment.
Nên đánh giá đồng thời:
- methodology;
- sample deliverable;
- khả năng giải thích finding;
- experience phù hợp scope;
- QA process;
- evidence quality;
- communication.
Không nên giả định một chứng chỉ tự động bảo đảm mọi tester hoặc mọi engagement có chất lượng như nhau.
12. Hỏi ai thực sự thực hiện Audit
Người pre-sales và người test có thể khác nhau.
Nên hỏi:
- ai là lead tester;
- skill matrix;
- ai review finding;
- có peer QA không;
- có subcontractor không;
- subcontractor có access dữ liệu/report không.
Điều này đặc biệt quan trọng với website chứa dữ liệu nhạy cảm.
13. Hỏi QA Process của Report
Trước khi report được giao, finding nên có quality gate.
Có thể hỏi:
- finding có peer review không;
- duplicate được merge thế nào;
- false positive được xử lý ra sao;
- impact có được kiểm tra tránh phóng đại không;
- secret/PII được redact thế nào;
- severity override cần lý do không.
14. Xem Sample Report nhưng không chỉ nhìn thiết kế
Sample report nên được đánh giá về cấu trúc, không chỉ màu sắc.
Kiểm tra xem một finding mẫu có:
- affected asset;
- description;
- observed condition;
- evidence;
- impact;
- severity/risk;
- remediation;
- verification criteria.
Một report đẹp nhưng thiếu evidence hoặc remediation direction vẫn khó hành động.
Xem cấu trúc gợi ý tại Security Audit Report nên có gì?.
Đánh giá Retest, Data Handling và Rules of Engagement
15. Kiểm tra Retest có nằm trong Scope không
Đừng đợi tới khi fix xong mới hỏi “retest có tính phí không?” hoặc “có nằm trong engagement không?”.
Nên làm rõ:
- retest có bao gồm không;
- bao nhiêu finding/round;
- thời hạn yêu cầu retest;
- environment nào;
- đầu ra là status update hay report mới;
- finding partial/mitigated xử lý thế nào.
Retest nên xác minh target state và evidence mới, không chỉ rerun scanner.
16. Kiểm tra Data Handling và Confidentiality
Security audit có thể tạo artifact nhạy cảm hơn nội dung website bình thường.
Nên hỏi:
- report lưu ở đâu;
- evidence lưu ở đâu;
- ai có quyền truy cập;
- retention bao lâu;
- secret/PII được redact thế nào;
- kênh trao đổi credential;
- cleanup data sau engagement.
Không gửi production password qua email/chat thường chỉ vì vendor yêu cầu nhanh.
17. Kiểm tra Rules of Engagement
Một vendor chuyên nghiệp nên sẵn sàng thống nhất RoE:
- assessment window;
- allowed techniques;
- prohibited techniques;
- tester IP;
- rate limit;
- state-changing test;
- production/staging;
- stop condition;
- emergency escalation.
Nếu họ muốn “test toàn bộ tùy ý” trên production mà không cần RoE, đó là red flag.
18. Hỏi cách họ xử lý Critical Finding trong lúc Audit
Không phải finding nghiêm trọng nào cũng nên chờ đến report cuối.
Nên có escalation process:
- finding nào cần báo ngay;
- contact nào nhận;
- evidence tối thiểu;
- có dừng testing hay không;
- cách bảo vệ sensitive detail.
Đánh giá Remediation Handoff, Commercial và Red Flags
19. Đánh giá Remediation Handoff
Report nên hỗ trợ đội kỹ thuật sửa vấn đề.
Hỏi vendor có:
- debrief technical finding;
- giải thích root cause;
- phân biệt fix và mitigation;
- hỗ trợ clarification;
- định nghĩa verification criteria.
Không nhất thiết auditor phải trực tiếp sửa mọi finding, nhưng handoff phải đủ rõ.
20. Đừng chọn chỉ theo số lượng Finding
“Chúng tôi sẽ tìm được nhiều lỗi hơn” không phải metric chất lượng tốt.
Một report có 100 alert chưa validate có thể kém giá trị hơn 12 finding đã được xác minh, ưu tiên và có remediation rõ.
Metric nên quan tâm hơn:
- coverage;
- validation;
- evidence;
- root-cause clarity;
- actionability;
- QA;
- retest traceability.
21. Đừng chọn chỉ theo Giá thấp nhất
Giá có ý nghĩa khi scope và deliverable tương đương.
Một báo giá thấp có thể khác ở:
- không manual testing;
- không authenticated testing;
- scope hẹp;
- không retest;
- không technical debrief;
- không server/config review;
- chỉ scanner export.
Vì vậy hãy so sánh scope + methodology + deliverable + retest, không chỉ tổng tiền.
22. Red Flags khi chọn đơn vị Security Audit
- Cam kết “không thể bị hack” sau audit.
- Cam kết tìm 100% vulnerability.
- Không cần scope rõ.
- Không có Rules of Engagement.
- Chỉ nói về tool, không nói validation.
- Không giải thích false positive.
- Không cung cấp limitation.
- Finding không có evidence.
- Muốn credential production qua kênh không an toàn.
- Không có quy trình escalation.
- Không nói ai thực hiện test.
- Không xác định retest.
Bộ câu hỏi và Scorecard trước khi ký
23. Các câu hỏi nên gửi Vendor trước khi thuê
- Scope được xác định như thế nào?
- Những gì out-of-scope?
- Assessment có manual testing không?
- Có authenticated testing theo role không?
- Scanner alert được validate thế nào?
- Severity/risk model là gì?
- Evidence được trình bày ra sao?
- Ai là lead tester và ai QA?
- Data/evidence được bảo vệ thế nào?
- Critical finding được escalation ra sao?
- Report gồm những section nào?
- Retest có nằm trong engagement không?
- Remediation clarification có bao gồm không?
- Timeline phụ thuộc điều kiện gì?
24. Mẫu Scorecard so sánh Vendor
| Tiêu chí | Trọng số gợi ý |
|---|---|
| Scope clarity | Cao |
| Methodology + manual validation | Cao |
| Relevant technical experience | Cao |
| Evidence/report quality | Cao |
| Data handling | Cao |
| Retest/handoff | Trung bình-Cao |
| Communication | Trung bình |
| Price | Đánh giá sau khi scope tương đương |
Không cần biến scorecard thành công thức cứng. Nó giúp tránh quyết định chỉ dựa trên sales presentation.
25. Trước khi ký SOW cần chốt gì?
Tối thiểu:
- asset/scope;
- out-of-scope;
- assessment objective;
- methodology ở mức cao;
- start/end window;
- deliverables;
- data handling;
- RoE;
- emergency escalation;
- retest;
- commercial terms;
- change-scope process.
Scope thay đổi giữa engagement nên có change control, không dựa trên trao đổi miệng.
Chuẩn bị nội bộ trước khi Vendor bắt đầu
Sau khi đã chọn đơn vị, doanh nghiệp vẫn cần chuẩn bị asset, test account, architecture, backup, contact và data-handling requirement.
Checklist chi tiết tại Chuẩn bị gì trước Website Security Audit?.
Kết luận
Chọn đơn vị Security Audit website nên dựa trên khả năng tạo assessment có scope rõ, methodology hợp lý, validated finding, evidence tốt và remediation handoff có thể hành động.
Đừng dùng giá, số lượng tool, certification hoặc số finding như tiêu chí duy nhất. Hãy đánh giá toàn bộ chuỗi: Scope → Testing → Validation → Evidence → Risk → Report → Remediation → Retest.
Nếu đang cân nhắc route phù hợp trước khi chọn vendor, xem Tự Security Audit hay thuê chuyên gia bên ngoài?. Nếu đã sẵn sàng xác định phạm vi assessment, có thể bắt đầu từ trang Website Security Audit.