Managed Security Runbook là tài liệu biến một capability bảo mật thành chuỗi thao tác có thể lặp lại, kiểm tra và bàn giao giữa các kỹ sư. Nếu scope trả lời “dịch vụ có những capability nào” và SLA trả lời “mức phản hồi ra sao”, runbook trả lời câu hỏi thực tế hơn: khi trigger xuất hiện thì ai làm gì, theo thứ tự nào, dựa trên bằng chứng nào và khi nào được coi là hoàn tất.
Runbook tốt không phải tài liệu dài nhất. Nó cần đủ cụ thể để hai analyst khác nhau xử lý cùng một tình huống theo logic nhất quán, nhưng vẫn cho phép judgment khi evidence chưa đầy đủ. Với website production, runbook còn phải bao gồm validation và rollback vì một hành động bảo mật sai có thể làm gián đoạn chính dịch vụ cần bảo vệ.
Nền tảng của một Managed Security Runbook
Runbook khác Policy, Procedure và Playbook như thế nào?
Các thuật ngữ thường bị dùng lẫn nhau. Có thể phân biệt theo mục đích:
- Policy: quy định nguyên tắc hoặc yêu cầu phải tuân thủ.
- Procedure: mô tả quy trình ở mức tương đối ổn định.
- Runbook: hướng dẫn vận hành cụ thể cho một task hoặc event lặp lại.
- Playbook: thường bao quát scenario phức tạp hơn, có nhiều nhánh quyết định và phối hợp nhiều đội.
Trong thực tế Managed Security, tên gọi ít quan trọng hơn việc tài liệu có trigger, owner, action, evidence, decision point và closure rõ hay không.
Một Managed Security Runbook nên bắt đầu bằng Trigger
Runbook phải nói khi nào được kích hoạt. Trigger có thể là:
- WAF alert đạt điều kiện cụ thể.
- Vulnerability mới trên component public-facing.
- Admin login bất thường.
- Backup job thất bại.
- DNS/TLS change ngoài maintenance window.
- High CPU đi kèm request spike.
- Malware/file integrity alert.
- Finding đến hạn remediation.
Trigger cần đủ rõ để tránh tình trạng analyst mở runbook quá sớm hoặc quá muộn. Nếu trigger dựa trên threshold, threshold nên nằm trong config/policy có version thay vì hard-code trong nhiều tài liệu khác nhau.
Precondition: trước khi làm phải biết gì?
Trước action, runbook nên xác nhận precondition tối thiểu:
- Asset nào đang được xử lý và có nằm trong scope không?
- Environment là production, staging hay test?
- Analyst có quyền truy cập cần thiết không?
- Action có cần approval hoặc emergency authority không?
- Có snapshot/backup/config baseline gần nhất không?
- Critical flow nào cần test sau thay đổi?
- Dependency với developer, hosting, CDN hoặc DNS là gì?
Precondition giúp tránh lỗi phổ biến như áp rule lên sai environment hoặc sửa production mà không có rollback path.
Mỗi bước phải có Input, Action và Expected Output
Một bước runbook tốt nên viết theo dạng có thể kiểm chứng:
| Thành phần | Ví dụ |
|---|---|
| Input | Alert ID, request sample, asset, timestamp |
| Action | Đối chiếu log WAF và origin trong cùng time window |
| Expected output | Xác định request bị block, bypass hay chưa đủ evidence |
| Evidence | Log reference, screenshot/export, ticket note |
| Decision | Close noise / continue triage / escalate |
Cấu trúc này tốt hơn câu mơ hồ như “kiểm tra log và xử lý nếu cần”.
Decision Point phải được viết rõ
Runbook không nên chỉ là danh sách thao tác tuyến tính. Security operations luôn có nhánh quyết định. Ví dụ:
- Nếu alert là false positive → ghi evidence, close hoặc tune rule theo change process.
- Nếu finding đã được mitigated bởi compensating control → ghi lại trạng thái và review risk.
- Nếu có evidence compromise → chuyển Incident Response.
- Nếu cần action ngoài authority → escalation/elevation.
- Nếu validation fail → rollback và mở incident/change issue.
Decision point nên dựa trên evidence, không phải cảm tính của từng analyst.
Runbook phải gắn với Severity và Escalation Matrix
Một runbook không nên tự tạo severity model riêng. Khi bước triage cho thấy impact tăng, runbook cần tham chiếu cùng escalation matrix đang dùng cho toàn dịch vụ.
Chi tiết về cách chuyển signal thành alert/incident và khi nào escalation có thể xem trong Security Escalation Matrix.
Runbook cần tách Observation khỏi Conclusion
Analyst nên ghi evidence trước khi kết luận. Ví dụ:
- Observation: “03:12 UTC có admin login từ ASN mới, sau đó tạo API token”.
- Conclusion: “Khả năng account compromise cao”.
Tách hai phần này giúp reviewer kiểm tra reasoning và giảm bias. Nếu conclusion thay đổi khi có evidence mới, observation ban đầu vẫn giữ nguyên.
Các scenario runbook thường gặp
Runbook cho WAF Alert nên gồm những gì?
Một runbook WAF cơ bản có thể gồm:
- Kiểm tra rule ID, action và endpoint.
- Đối chiếu legitimate traffic và attack sample.
- Kiểm tra origin log để phát hiện bypass.
- Đánh giá false positive và business impact.
- Nếu cần thay rule/exception, tạo change plan.
- Dry-run hoặc pilot nếu nền tảng hỗ trợ.
- Apply change với authorization phù hợp.
- Read-back cấu hình.
- Test critical flow.
- Monitor sau thay đổi và chuẩn bị rollback.
WAF Maintenance Checklist có thể dùng làm nguồn cho các control định kỳ liên quan.
Runbook cho Vulnerability Finding
Scanner không phải điểm kết thúc. Runbook nên gồm:
- Xác minh asset và software/version.
- Loại duplicate/false positive.
- Đánh giá internet exposure và asset criticality.
- Kiểm tra exploitability/known exploitation khi có nguồn đáng tin cậy.
- Xác định owner remediation.
- Lập change/patch plan.
- Backup/snapshot nếu cần.
- Apply fix trong scope được phép.
- Retest.
- Đóng finding bằng evidence hoặc documented exception.
Nếu có evidence exploitation, runbook vulnerability phải chuyển sang Incident Response thay vì tiếp tục như maintenance thông thường.
Runbook cho Admin Account Alert
Với account nhạy cảm, runbook có thể yêu cầu:
- Đối chiếu user, time, source, device/session và MFA.
- Kiểm tra subsequent actions: role change, token creation, plugin/config change.
- Xác nhận với account owner qua kênh tin cậy.
- Nếu compromise: revoke session/token theo authority.
- Rotate credential khi phù hợp.
- Review phạm vi action đã thực hiện bởi account.
- Escalate incident nếu có unauthorized change.
Không nên chỉ reset password rồi đóng ticket nếu chưa kiểm tra attacker đã làm gì sau khi đăng nhập.
Runbook cho Backup Failure
Backup failure thường bị xem là operational issue, nhưng nó trực tiếp ảnh hưởng recovery capability. Runbook nên xác định:
- Job nào fail, từ khi nào?
- Last known-good backup là khi nào?
- Có đủ retention/alternate copy không?
- Failure do storage, credential, quota hay application?
- Critical recovery point có đang bị vượt không?
- Cần escalation mức nào nếu không có bản sao hợp lệ?
Closure không nên chỉ là “job chạy lại thành công”; cần xác minh artifact backup thực sự tồn tại và có thể sử dụng theo policy.
Authorization, change safety và evidence
Runbook phải định nghĩa Authorization Boundary
Mỗi action nên được gắn với quyền:
- Action analyst được tự làm.
- Action cần senior approval.
- Action cần customer approval.
- Action chỉ được thực hiện trong emergency authorization.
- Action hoàn toàn out-of-scope và phải handoff.
Điều này giảm cả hai rủi ro: analyst chậm vì không biết mình được phép làm gì, hoặc thay đổi quá rộng ngoài thẩm quyền.
Runbook cho Production Change phải có Rollback
Security fix có thể phá legitimate traffic hoặc critical function. Vì vậy các bước thay đổi production cần:
- Snapshot/baseline.
- Diff dự kiến.
- Dry-run/pilot nếu có.
- Approval đúng scope.
- Apply.
- Read-back.
- Functional validation.
- Monitoring hậu thay đổi.
- Rollback trigger và procedure.
API trả success không đủ nếu state lưu hoặc frontend thực tế sai.
Evidence nên được ghi ở đâu?
Runbook phải chỉ ra nơi lưu evidence: ticket, case management, incident platform hoặc repository được kiểm soát. Evidence có thể gồm:
- Alert/log reference.
- Timestamp.
- Config before/after.
- Command/output liên quan.
- Approval.
- Validation result.
- Rollback result nếu có.
- Closure reason.
Ở lớp server, Server Audit Logging giúp xác định event nào cần tồn tại để runbook có đủ dữ liệu điều tra.
Runbook không nên chứa Secret
Tài liệu vận hành có thể cần chỉ dẫn nơi lấy credential nhưng không nên nhúng password, token hoặc private key trực tiếp. Nên tham chiếu secret manager/vault và permission phù hợp.
Nếu runbook được export hoặc chia sẻ cho vendor, cần đảm bảo không vô tình lộ sensitive architecture hoặc recovery credential.
Governance, testing và metrics
Version Control và Change History
Runbook cần version, owner và last-reviewed date. Khi thay đổi:
- Ghi lý do.
- Ghi ai phê duyệt.
- Cập nhật dependency/contact.
- Test lại bước bị ảnh hưởng.
Runbook cũ có thể nguy hiểm nếu command, hostname, contact hoặc permission đã thay đổi.
Runbook cần được Test bằng Tabletop hoặc Simulation
NIST SP 800-184 khuyến nghị recovery plan và playbook cần được test và cải tiến. Với Managed Security, có thể test runbook bằng scenario nhỏ:
- WAF false positive trên checkout.
- Admin account compromise giả lập.
- Vulnerability critical nhưng patch gây lỗi staging.
- Backup fail trước một deployment lớn.
- Origin bị bypass CDN/WAF.
Mục tiêu không phải “diễn tập cho đủ”, mà tìm điểm runbook không thực thi được: thiếu quyền, thiếu log, contact sai hoặc rollback không tồn tại.
Runbook Metrics nên đo gì?
Không nên chỉ đo số lần runbook được chạy. Một số metric có ích:
- Time-to-triage.
- Tỷ lệ case cần escalation do thiếu authority.
- False-positive rate.
- Runbook step failure.
- Recurring issue.
- Tỷ lệ remediation được retest.
- Số lần rollback.
- Runbook aging: bao lâu chưa review/test.
Metric phải được dùng để cải tiến quy trình, không ép analyst đóng case nhanh bằng mọi giá.
Template và lỗi thường gặp
Template một Managed Security Runbook
- Name & purpose
- Owner & version
- Scope / applicable assets
- Trigger
- Preconditions
- Required access/tools
- Step-by-step actions
- Decision points
- Severity/escalation reference
- Authorization boundaries
- Evidence requirements
- Validation
- Rollback
- Closure criteria
- Review/test cadence
Những lỗi thường gặp khi viết Runbook
- Viết quá chung chung: “kiểm tra và xử lý”.
- Không có trigger hoặc closure criteria.
- Không phân biệt observation và conclusion.
- Không có owner/authorization.
- Không link tới escalation matrix.
- Không có validation và rollback cho production change.
- Nhúng secret vào tài liệu.
- Không version-control.
- Không test bằng scenario thực tế.
- Không cập nhật sau incident hoặc kiến trúc thay đổi.
Kết luận
Managed Security Runbook giúp biến kiến thức của một cá nhân thành năng lực vận hành có thể lặp lại. Một runbook tốt phải nối được trigger → evidence → action → decision → escalation → validation → closure, đồng thời giữ rõ authorization và rollback.
Runbook không thay thế judgment của analyst. Nó tạo một baseline nhất quán để analyst dùng judgment đúng chỗ, giảm thao tác tùy hứng và giúp service có thể audit, handoff và cải tiến theo thời gian.
Nguồn tham khảo: NIST SP 800-61 Rev. 3; NIST SP 800-184 về recovery planning/playbook; NIST Cybersecurity Framework 2.0.