Managed Security Report: KPI & Bằng chứng

Managed Security Report không nên chỉ là danh sách alert đã xuất hiện trong tháng. Một báo cáo hữu ích phải giúp người đọc trả lời được ba câu hỏi: rủi ro đang thay đổi thế nào, đội vận hành đã làm gì và còn việc gì cần quyết định hoặc xử lý tiếp.

Report tốt phải cân bằng giữa KPI, bằng chứng và business context. Nếu chỉ có số lượng event, người đọc dễ hiểu sai: ít alert có thể do hệ thống an toàn hơn, nhưng cũng có thể do visibility kém; nhiều alert có thể là attack tăng, nhưng cũng có thể do rule quá nhạy hoặc telemetry mới được bật.

Mục tiêu và cách đọc Managed Security Report

Managed Security Report dùng để làm gì?

Báo cáo định kỳ nên phục vụ ít nhất bốn mục tiêu:

Operational visibility: cho thấy control, alert, incident và remediation đang ở trạng thái nào.
Accountability: chứng minh các capability trong scope đã được thực hiện.
Risk decision: làm rõ issue nào cần business owner phê duyệt, đầu tư hoặc chấp nhận risk.
Continuous improvement: chỉ ra recurring issue, bottleneck và control cần điều chỉnh.

NIST xem metrics là công cụ hỗ trợ decision making, performance improvement và accountability. Vì vậy KPI chỉ có giá trị khi gắn với quyết định hoặc hành động cụ thể.

Report không nên bắt đầu bằng Dashboard Screenshot

Một screenshot dashboard có thể hữu ích như evidence, nhưng không nên là phần mở đầu. Management cần summary theo risk và outcome, không phải hàng trăm biểu đồ chưa có giải thích.

Phần đầu báo cáo nên tóm tắt:

Overall security posture/trend trong kỳ.
Incident hoặc high-risk finding quan trọng.
Control nào thay đổi.
Remediation nào hoàn tất hoặc bị trễ.
Decision nào cần khách hàng/management.

Executive Summary nên ngắn nhưng có quyết định

Executive summary không nên dùng các câu chung chung như “hệ thống đang an toàn”. Thay vào đó, có thể trình bày:

Không có confirmed incident trong kỳ / có X incident theo severity.
High-risk backlog tăng/giảm và lý do.
Một control quan trọng được cải thiện hoặc drift.
Một dependency đang gây chậm remediation.
Một action cần owner quyết định trước kỳ tới.

Nếu không đủ evidence để kết luận trend, report nên nói rõ mức confidence hoặc data gap.

Scope, exposure và trạng thái control

1. Scope và Coverage phải xuất hiện trong report

Người đọc cần biết report đang nói về những asset nào. Nên liệt kê hoặc tóm tắt:

Domain/subdomain/app/API nằm trong scope.
Environment: production/staging.
Hosting/server/CDN/WAF/DNS được quản lý.
Capability nào active trong kỳ.
Coverage giờ nào cho monitoring/triage/response.
Data source nào bị thiếu hoặc gián đoạn.

Không có scope thì KPI dễ bị hiểu rộng hơn thực tế.

2. Asset và Exposure Change

Report nên ghi những thay đổi có ảnh hưởng attack surface:

Subdomain/service mới.
Port/public endpoint mới.
DNS/origin thay đổi.
Plugin/package/platform change đáng kể.
Admin account hoặc vendor access mới.
Asset decommissioned.

Những thay đổi này giúp giải thích vì sao vulnerability, alert hoặc risk trend thay đổi giữa các kỳ.

3. Vulnerability và Remediation KPI

Không nên báo chỉ số “tổng số vulnerability” đơn lẻ. Nên phân tích theo trạng thái và risk:

New findings trong kỳ.
Open high/critical-risk findings.
Findings đã retest và closed.
Overdue remediation.
Findings có documented exception/risk acceptance.
Recurring findings.
Median/percentile remediation time nếu dữ liệu đủ ổn định.

Metric cần phân biệt vulnerability discovery với confirmed finding. Scanner duplicate hoặc false positive không nên làm đẹp/xấu KPI một cách giả tạo.

4. Patch và Configuration State

Nếu patch/hardening nằm trong scope, report có thể cho thấy:

Critical/security update đã review.
Patch đã apply và validation result.
Patch pending do dependency.
Configuration drift được phát hiện.
Exception còn mở.
Rollback đã xảy ra trong kỳ.

Ở lớp server, có thể đối chiếu với Server Security Maintenance Checklist.

5. WAF, Rate Limiting và Bot Protection

Report edge security không nên chỉ khoe “đã chặn X triệu request”. Các chỉ số hữu ích hơn gồm:

Top attack categories/path có ý nghĩa.
False-positive incident hoặc exception mới.
Rule/threshold đã thay đổi.
Critical flow đã test sau change.
Origin bypass/exposure status.
Rate-limit/bot policy có gây ảnh hưởng legitimate traffic không.

Nếu rule được thay đổi, report nên link evidence/change record và validation. WAF Maintenance Checklist là một nguồn để chuẩn hóa review định kỳ.

10. Backup và Recovery Evidence

Nếu backup nằm trong scope, report nên cho thấy:

Backup job success/failure trend.
Last known-good copy.
Restore test đã thực hiện chưa.
Recovery issue hoặc data gap.
Backup credential/storage risk.

“100% backup jobs success” chưa chứng minh restore được; evidence restore test có giá trị cao hơn.

11. Access và Privilege Review

Report access có thể gồm:

New admin/service accounts.
Removed/stale accounts.
Privilege changes.
MFA coverage trên admin path.
Key/token rotation status nếu in-scope.
Vendor access review.

Không nên xuất secret hoặc sensitive identity detail không cần thiết vào báo cáo management.

12. Change và Rollback Evidence

Security operation thường tạo production change. Nên thống kê:

Security changes đã thực hiện.
Changes có validation pass.
Changes phải rollback.
Emergency changes.
Changes còn chờ approval.

Metric rollback không nhất thiết là xấu; rollback đúng lúc có thể chứng minh change control hoạt động.

13. Runbook và Process Health

Managed Security Report nên theo dõi cả quy trình, không chỉ hệ thống:

Runbook nào được sử dụng trong kỳ.
Runbook step failure.
Runbook overdue review.
Scenario cần tạo runbook mới.
Tabletop/test result.

Chi tiết cấu trúc có thể xem trong Managed Security Runbook.

Detection, incident, SLA và handoff

6. Alert và Triage Metrics

Alert metrics nên hỗ trợ đánh giá chất lượng detection và workload:

Alert volume theo source/severity.
Human-triaged alerts.
False-positive/noise rate.
Reclassified severity.
Alert chuyển thành incident.
Time-to-triage.
Alert bị bỏ lỡ SLA.

Một hệ thống tốt có thể giảm alert volume nhờ tuning mà vẫn tăng detection quality. Vì vậy không nên coi “nhiều alert hơn” là dấu hiệu dịch vụ hoạt động tốt hơn.

7. Incident Metrics

Incident report nên có cả quantitative và qualitative evidence:

Số incident theo severity.
Time-to-detect nếu đo được.
Time-to-triage.
Time-to-escalate.
Time-to-contain khi nằm trong scope.
Recovery time.
Root cause hoặc contributing factor.
Post-incident action còn mở.

Đừng ép mọi incident vào một con số trung bình. Một Critical incident và nhiều Low incident có đặc điểm khác nhau. Nên phân nhóm theo severity hoặc scenario.

8. SLA Performance

Nếu dịch vụ có SLA, report cần cho thấy:

SLA met/missed theo severity.
Metric nào được đo: acknowledge, triage, escalate, contain hay remediate.
Pause time do customer/vendor dependency.
Miss reason và corrective action.

Không nên chỉ ghi “99% SLA achieved” mà không nói denominator và metric definition. Chi tiết cách thiết kế SLA có thể xem trong Managed Security SLA.

9. Escalation và Handoff Quality

Một service có thể đáp ứng SLA nhưng vẫn handoff kém. Report có thể đo:

Số case cần escalation.
Case chậm do sai owner.
Third-party dependency.
Contact không phản hồi.
Case cần management elevation.

Security Escalation Matrix giúp chuẩn hóa các trigger và owner để metric này có ý nghĩa.

KPI, trend và evidence

KPI nào dễ bị “game” hoặc hiểu sai?

Một số metric cần dùng cẩn thận:

Số alert đã đóng: dễ thúc đẩy đóng nhanh thay vì điều tra đúng.
Số vulnerability giảm: có thể do scan scope giảm.
Zero incident: không chứng minh không có compromise.
100% uptime: không phản ánh integrity hoặc security.
Số request WAF chặn: không trực tiếp đo business risk reduction.

Metric nên có counter-metric hoặc context để tránh tối ưu sai mục tiêu.

KPI nên có Baseline và Trend

Một con số một tháng rất khó diễn giải. Nên so sánh theo nhiều kỳ hoặc baseline:

Open high-risk finding: tăng/giảm.
Median triage time: trend.
False-positive rate: trend.
Recurring issue: trend.
Overdue remediation: trend.

Khi telemetry source thay đổi, report phải ghi annotation để tránh so sánh sai trước/sau.

Evidence nào nên đính kèm?

Không phải tất cả evidence đều cần nằm trực tiếp trong PDF/report. Có thể dùng reference tới hệ thống lưu trữ:

Ticket/case ID.
Change record.
Alert/log query reference.
Retest result.
Backup restore record.
Approval/risk acceptance.
Post-incident review.

Evidence phải đủ để audit lại nhưng không nên phơi secret, token, raw personal data hoặc thông tin nhạy cảm không cần thiết.

Audience, cadence và action register

Report cho Management và Report cho Technical Team nên khác nhau

Một báo cáo duy nhất có thể có hai lớp:

Management view

Risk trend.
Incident/high-risk finding.
SLA/outcome.
Decision needed.
Investment/dependency.

Technical appendix

Detailed finding.
Alert/incident timeline.
Rule/config changes.
Evidence references.
Remediation owner/deadline.

Điều này giúp management không bị ngập chi tiết nhưng technical team vẫn có dữ liệu để hành động.

Report Cadence nên là hàng tuần, hàng tháng hay hàng quý?

Không có cadence universal. Có thể phân lớp:

Immediate: Critical incident/escalation.
Weekly: operational backlog/high-risk item cho hệ thống thay đổi nhanh.
Monthly: service KPI, remediation trend, control review.
Quarterly: strategic risk review, scope/capability, recurring issue và roadmap.

Business-critical site có thể cần review dày hơn site nội dung ít thay đổi.

Action Register phải là đầu ra của Report

Báo cáo không nên kết thúc bằng biểu đồ. Nên có action register:

Action	Priority	Owner	Due	Status	Evidence/Dependency
Ví dụ: loại WAF exception cũ	High	Security	Theo agreed SLA	Open	Cần regression test checkout

Action register biến report thành công cụ điều hành thay vì tài liệu lưu trữ.

Checklist Managed Security Report

Scope/coverage và data gaps.
Executive risk summary.
Asset/exposure changes.
Vulnerability/remediation status.
Patch/config/WAF changes.
Alert/triage quality.
Incident/SLA metrics.
Access/backup/recovery evidence.
Recurring issues.
Action register và decisions needed.

Kết luận

Managed Security Report tốt phải cho thấy risk, action, evidence và trend, không chỉ activity volume. KPI cần có định nghĩa, baseline và context; evidence cần đủ để kiểm chứng; và mỗi kỳ báo cáo nên dẫn tới action hoặc decision rõ ràng.

Đừng tối ưu service để có dashboard đẹp. Hãy dùng report để tìm bottleneck, recurring issue và khoảng trống responsibility, rồi biến chúng thành remediation và continuous improvement.

Nguồn tham khảo: NIST Cyber Security Metrics and Measures; NIST SP 800-61 Rev. 3; NIST SP 800-184; NIST Cybersecurity Framework 2.0.