Trong Security Audit, một finding không nên tồn tại chỉ vì “công cụ báo đỏ” hoặc “tester nhìn thấy có vẻ bất thường”. Muốn một kết luận có thể được review, remediation và retest, cần có evidence đủ rõ để người khác hiểu điều gì đã được quan sát và tại sao finding đó đáng tin.
Security Audit Evidence là bằng chứng kỹ thuật hoặc vận hành được thu thập trong phạm vi assessment để hỗ trợ một observation hoặc finding. Evidence có thể là request/response, cấu hình, log, permission state, screenshot, version information hoặc dữ liệu khác phù hợp với loại kiểm tra.
Bài này tập trung vào cách thu thập, chuẩn hóa, lưu trữ, redact và đánh giá chất lượng evidence. Việc quyết định một candidate có đủ điều kiện trở thành validated finding hay không được tách riêng tại Security Finding Validation.
Evidence trong Security Audit là gì?
Evidence là thông tin có thể dùng để trả lời ít nhất ba câu hỏi:
- Điều gì đã được quan sát?
- Quan sát đó xảy ra trên asset và điều kiện nào?
- Người review có đủ dữ liệu để hiểu hoặc kiểm tra lại kết luận không?
Evidence không nhất thiết phải “kịch tính”. Một permission sai, một response header, một log event hoặc một configuration value đều có thể là evidence nếu chúng trực tiếp hỗ trợ finding.
Ngược lại, một screenshot đẹp nhưng không cho biết URL, thời điểm, user context hoặc điều kiện kiểm tra có thể là evidence yếu.
| Khái niệm | Vai trò | Ví dụ |
|---|---|---|
| Signal | Dấu hiệu ban đầu cần kiểm tra thêm | Scanner báo plugin có version đáng chú ý |
| Evidence | Dữ liệu hỗ trợ quan sát | Version thực tế, response, config hoặc log |
| Finding | Kết luận đã được mô tả và đặt trong ngữ cảnh | Plugin in-scope chạy version bị ảnh hưởng trong điều kiện cụ thể |
| Risk | Đánh giá mức độ đáng ưu tiên | Exposure, impact, likelihood, business context |
Evidence là nguyên liệu của finding, không phải finding tự thân.
Một Evidence tốt cần có những đặc tính nào?
1. Liên quan trực tiếp
Evidence phải hỗ trợ đúng kết luận đang được đưa ra. Nếu finding là “tài khoản cũ vẫn có quyền administrator”, evidence nên thể hiện account, role và trạng thái quyền liên quan. Một ảnh chụp danh sách user nhưng không thấy role chưa đủ mạnh để chứng minh kết luận.
2. Có ngữ cảnh
Evidence nên cho biết asset, environment, user/role nếu liên quan, thời điểm hoặc phiên kiểm tra, điều kiện cần thiết để quan sát và limitation quan trọng.
Thiếu context khiến cùng một ảnh chụp hoặc response có thể bị diễn giải theo nhiều cách.
3. Trace được về test hoặc control
Evidence nên liên kết được với test step, control objective hoặc workstream trong Website Security Audit Methodology.
Một traceability chain thực dụng:
Scope → Asset → Test/Review → Evidence → Candidate Finding → Finding
4. Đủ nhưng không dư thừa
Evidence tốt là evidence tối thiểu cần thiết để chứng minh vấn đề. Nếu một response đã đủ chứng minh access control gap, không cần tải toàn bộ dataset của người dùng khác. Nếu config đã đủ chứng minh secret bị expose, không cần tiếp tục sử dụng secret đó để mở rộng tác động khi scope không cho phép.
5. Giữ được tính toàn vẹn
Evidence phải được lưu theo cách giảm nguy cơ nhầm lẫn hoặc chỉnh sửa ngoài ý muốn. Tùy quy mô assessment, có thể dùng timestamp, naming convention, finding ID, hash cho artifact quan trọng, version history hoặc audit trail.
Không phải mọi website audit đều cần forensic chain-of-custody đầy đủ, nhưng evidence vẫn cần đủ integrity để review nội bộ.
Các loại Security Audit Evidence thường gặp
HTTP Request và Response
Đây là evidence quan trọng với web application testing. Nên lưu phần cần thiết như method, endpoint, parameter, relevant header, status code và response fragment có ý nghĩa.
Credential, session token, PII và dữ liệu nhạy cảm nên được redact khi không cần cho việc chứng minh finding.
Configuration Evidence
Có thể gồm web server config, application config, WAF rule, security header policy, permission, runtime setting hoặc control state. Nên trích đúng phần liên quan thay vì đưa toàn bộ file config chứa secret vào report.
Log Evidence
Log hữu ích để chứng minh một sự kiện đã xảy ra hoặc control đã/không ghi nhận hoạt động mong đợi. Evidence nên giữ timestamp, event type, asset/source, relevant identifier và đủ dòng trước/sau để hiểu context.
Screenshot
Screenshot phù hợp khi trạng thái giao diện hoặc control trực quan là một phần của bằng chứng: role hiển thị trong admin, MFA chưa bắt buộc, security setting, error page lộ thông tin hoặc trạng thái backup/restore.
Screenshot thường là evidence hỗ trợ, không phải lúc nào cũng thay thế request/response hoặc configuration evidence.
Version và Component Evidence
Version có thể đến từ package manager, CMS inventory, server package list, plugin metadata hoặc fingerprint.
Cần phân biệt observed version, inferred version và affected status. Không nên biến một fingerprint không chắc chắn thành finding đã xác nhận.
Permission và Access State
Evidence có thể là role/capability, filesystem permission, ACL, cloud IAM policy hoặc access matrix. Với access finding, context “ai đang kiểm tra với role nào” rất quan trọng.
Tool Output
Output từ scanner, SAST, dependency scanner hoặc configuration scanner có thể là evidence hỗ trợ. Nên kèm tool/version nếu cần, thời điểm chạy, asset, relevant rule/signature và validation status.
Tool output không nên được copy thẳng thành report mà không review.
Quản lý Evidence an toàn và có thể truy vết
Thu thập theo nguyên tắc “minimum necessary”
- Chỉ thu dữ liệu cần để chứng minh condition.
- Ưu tiên test account và test data.
- Redact token, password, API key và PII không cần thiết.
- Không tải dataset lớn nếu một record đã đủ evidence.
- Không giữ evidence lâu hơn retention policy cần thiết.
- Giới hạn người có quyền truy cập evidence.
Redaction: che gì và giữ gì?
| Dữ liệu | Thường nên làm |
|---|---|
| Password, API key, session token | Redact gần như toàn bộ, giữ prefix/suffix nếu cần phân biệt |
| Email/PII | Ẩn phần không cần thiết; ưu tiên test data |
| Internal IP/hostname | Giữ nếu cần traceability và người nhận được phép xem |
| Request parameter | Giữ phần cần để tái hiện logic, che dữ liệu nhạy cảm |
| Config | Trích dòng liên quan, che secret |
Không nên redact đến mức evidence mất ý nghĩa.
Evidence ID và naming convention
Với assessment nhiều finding, naming convention giúp tránh nhầm artifact. Ví dụ:
AUD-430-F05-E02
- AUD: loại assessment;
- 430: engagement hoặc project ID;
- F05: finding số 5;
- E02: evidence thứ 2.
Có thể thêm ngày, asset hoặc environment nếu cần. Điều quan trọng là naming nhất quán và traceable.
Evidence Log nên có gì?
| Trường | Mục đích |
|---|---|
| Evidence ID | Định danh artifact |
| Finding/Candidate ID | Liên kết evidence với kết luận |
| Asset | Biết evidence áp dụng cho đâu |
| Collected at | Thời điểm quan sát |
| Collector | Người/luồng thu thập |
| Type | HTTP, config, log, screenshot, tool output… |
| Sensitivity | Public/Internal/Restricted hoặc scheme nội bộ |
| Storage/Hash | Trace artifact nếu cần |
Quality Gate trước khi dùng Evidence cho Finding
Checklist kiểm tra chất lượng Evidence
- Evidence có đúng asset không?
- Có đúng environment và user context không?
- Thời điểm có hợp lý không?
- Evidence có trực tiếp hỗ trợ condition không?
- Có cần thêm artifact thứ hai để tránh kết luận sai không?
- Dữ liệu nhạy cảm đã được xử lý phù hợp chưa?
- Reviewer khác có hiểu evidence mà không cần đoán quá nhiều không?
Nếu trả lời “không” ở các điểm quan trọng, evidence nên được bổ sung trước khi finding được final.
Không dùng Evidence để phóng đại Impact
Một lỗi thường gặp là evidence chỉ chứng minh condition A nhưng report lại kết luận luôn impact B, C và D.
Ví dụ, directory listing đang bật không tự động chứng minh dữ liệu nhạy cảm đã bị lộ. Component outdated không tự động chứng minh attacker có thể remote code execution trong cấu hình hiện tại.
Report nên tách rõ Observed, Potential impact và Validated impact.
Evidence trong Audit khác Incident Response
Security Audit chủ yếu cần evidence để chứng minh control state hoặc finding. Incident Response có thể cần preservation nghiêm ngặt hơn để xây timeline, điều tra compromise hoặc phục vụ yêu cầu forensic/pháp lý.
Không nên mặc định mọi audit phải áp dụng forensic chain-of-custody đầy đủ. Nhưng nếu assessment chuyển thành incident investigation, quy trình evidence cũng phải thay đổi tương ứng.
OWASP WSTG và Evidence
OWASP WSTG tổ chức web security testing thành các scenario có objective và cách kiểm tra rõ ràng. Khi áp dụng vào audit, cách tốt là liên kết evidence với scenario hoặc control objective cụ thể thay vì chỉ ghi “scanner found issue”.
Ví dụ một Evidence Package tối thiểu
Giả sử finding là “tài khoản cũ vẫn giữ quyền administrator”. Evidence package có thể gồm:
- Asset: WordPress production.
- Context: authenticated admin review.
- Evidence E01: danh sách user hiển thị account và role Administrator.
- Evidence E02: xác nhận owner rằng account thuộc nhân sự đã offboard.
- Observed condition: account còn active và có privileged role.
- Không cần: reset password hoặc đăng nhập bằng credential của account nếu scope không yêu cầu.
Evidence như vậy đã đủ để remediation: disable/remove account và review access liên quan.
Kết luận
Evidence trong Security Audit phải đủ liên quan, có context, traceable và được xử lý an toàn. Mục tiêu không phải thu thập càng nhiều artifact càng tốt mà là tạo bằng chứng tối thiểu cần thiết để reviewer có thể hiểu và đánh giá finding.
Evidence tốt giúp giảm false positive, làm report đáng tin hơn và tạo điều kiện cho retest. Sau khi evidence đã đủ, bước tiếp theo là xác định candidate có thật sự trở thành finding hay không tại Security Finding Validation.
Nếu cần xem evidence nằm ở đâu trong toàn bộ workflow, tham khảo Website Security Audit Methodology hoặc trang Website Security Audit.