Managed Security SLA: Phản hồi & Escalation

Managed Security SLA nên định nghĩa cách một security event được tiếp nhận, ưu tiên, phản hồi, escalation và theo dõi đến khi có outcome rõ ràng. SLA tốt không chỉ ghi “Critical: phản hồi trong X phút”, mà phải nói chính xác đồng hồ bắt đầu lúc nào, “phản hồi” nghĩa là acknowledgment hay human triage, ai chịu trách nhiệm containment, điều gì làm severity thay đổi và thời gian nào nằm ngoài quyền kiểm soát của provider.

Không có một bảng thời gian phản hồi phù hợp cho mọi website. NIST SP 800-61 Rev. 3 khuyến nghị ưu tiên tốc độ incident response dựa trên scope, likely impact, tính time-critical và resource availability. Vì vậy, severity và SLA cần phản ánh risk thực tế của từng hệ thống thay vì sao chép một con số cố định.

Managed Security SLA là gì?

SLA là cam kết dịch vụ có thể đo lường giữa các bên. Trong Managed Security, SLA thường liên quan tới thời gian và trách nhiệm quanh alert, incident, remediation hoặc request. Nó khác với một runbook kỹ thuật: runbook mô tả cách làm; SLA mô tả mức dịch vụ và tiêu chí đo.

Một SLA hữu ích phải gắn với scope đã thống nhất. Nếu malware cleanup, code fix hoặc hosting change nằm ngoài scope, không thể cam kết “resolution time” cho toàn bộ incident như thể provider kiểm soát tất cả dependency.

Thời gian và clock rules trong SLA

Đừng gộp mọi loại thời gian thành “response time”

“Response time” quá mơ hồ. Một incident nên tách thành các mốc có ý nghĩa vận hành:

Detection time: thời điểm hệ thống hoặc con người phát hiện tín hiệu.
Acknowledgment: xác nhận alert/ticket đã được tiếp nhận.
Time-to-triage: thời gian để con người đánh giá sơ bộ severity, scope và next action.
Time-to-escalate: thời gian từ khi đạt tiêu chí đến khi thông báo đúng contact/đội chịu trách nhiệm.
Time-to-contain: thời gian đến khi thực hiện biện pháp giảm khả năng lan rộng hoặc impact, nếu containment nằm trong scope.
Time-to-remediate: thời gian đến khi nguyên nhân hoặc finding được xử lý.
Time-to-recover: thời gian đến khi dịch vụ hoặc critical flow trở lại trạng thái chấp nhận được.

Các mốc này không nhất thiết đều là SLA cam kết. Nhưng hợp đồng nên chỉ rõ mốc nào được đo, mốc nào chỉ là operational metric.

Acknowledgment không đồng nghĩa đã xử lý

Một ticket được tự động tạo sau 30 giây không có nghĩa incident đã được human triage. Nếu SLA ghi “response trong 5 phút” nhưng thực tế chỉ là email auto-reply, khách hàng có thể hiểu sai mức coverage.

Nên tách rõ:

Automated detection/notification.
Human acknowledgment.
Human triage.
Technical action.
Customer/vendor escalation.

Đây là lý do “24/7 monitoring” cũng không mặc định tương đương “24/7 response”.

Coverage hours phải được ghi tách biệt

Hợp đồng cần nói rõ từng capability hoạt động theo lịch nào:

Telemetry collection 24/7 hay theo giờ?
Automated detection 24/7?
Human triage business hours hay 24/7?
On-call escalation có hoạt động cuối tuần/ngày lễ?
Remediation/change có bị giới hạn bởi maintenance window?

Nếu provider nhận alert 24/7 nhưng chỉ human triage trong giờ làm việc, SLA phải thể hiện đúng thực tế.

Đồng hồ SLA bắt đầu lúc nào?

Đây là một trong những chi tiết dễ gây tranh cãi nhất. Có thể bắt đầu từ:

Thời điểm monitoring platform tạo alert.
Thời điểm ticket vào hệ thống provider.
Thời điểm alert vượt threshold và đủ evidence.
Thời điểm khách hàng report incident.

Cần chọn và ghi rõ một trigger có thể audit. Với alert tự động, timestamp từ monitoring/ticketing thường dễ kiểm chứng hơn “khi kỹ sư nhìn thấy”.

Khi nào đồng hồ SLA có thể pause?

Không nên âm thầm dừng SLA. Nếu có pause condition, hợp đồng phải định nghĩa trước, ví dụ:

Đang chờ khách hàng cấp access hoặc approval bắt buộc.
Đang chờ third-party vendor xử lý hạng mục ngoài quyền provider.
Maintenance/change window chưa mở và không đủ tiêu chí emergency.
Khách hàng yêu cầu trì hoãn remediation.

Mọi pause nên có timestamp, reason và owner. Nếu provider vẫn có hành động thay thế như containment hoặc monitoring tăng cường, cũng nên được ghi vào incident record.

Severity và mức ưu tiên

Severity nên được xác định thế nào?

Severity không nên chỉ dựa trên tên alert hoặc CVSS. Với website, cần kết hợp ít nhất các yếu tố:

Asset criticality: hệ thống có ảnh hưởng doanh thu, authentication, checkout, API hay dữ liệu nhạy cảm không?
Observed impact: downtime, data exposure, account takeover, unauthorized change hay chỉ suspicious attempt?
Scope: một user, một endpoint, một server hay nhiều environment?
Exposure: attacker có đang duy trì access hoặc exploitation đang diễn ra không?
Time sensitivity: chậm xử lý có làm impact tăng nhanh không?
Evidence confidence: incident đã xác nhận hay mới là signal cần điều tra?

Severity có thể tăng hoặc giảm khi evidence mới xuất hiện. SLA nên cho phép reclassification và ghi lại lý do thay đổi.

Một severity model tham khảo

Không nên coi bảng dưới đây là chuẩn bắt buộc; đây là mô hình để thiết kế ngôn ngữ SLA:

Mức	Đặc điểm tham khảo	Hành động ưu tiên
Critical	Confirmed compromise, critical flow down, active data exposure hoặc attack đang gây impact lớn	Human triage ngay theo coverage, escalation khẩn và cân nhắc containment
High	Strong evidence of exploitation hoặc control failure ảnh hưởng asset quan trọng nhưng impact còn giới hạn	Ưu tiên điều tra, giảm exposure và escalation sớm
Medium	Finding có rủi ro đáng kể nhưng chưa có evidence exploitation hoặc impact trực tiếp	Triage, remediation plan và deadline theo risk
Low	Hardening gap, hygiene issue, informational event hoặc risk thấp	Đưa vào backlog/review định kỳ

Severity taxonomy phải được customize theo business. Với một website thanh toán, checkout outage có thể Critical; với site nội dung ít quan trọng, cùng một loại outage có thể không ở mức tương tự.

Không nên đặt SLA chỉ dựa trên CVSS

CVSS hữu ích để mô tả đặc điểm kỹ thuật của vulnerability nhưng không thay thế business context. Một lỗ hổng điểm cao trên component không internet-facing có thể kém khẩn cấp hơn một issue điểm thấp đang bị khai thác trên endpoint public quan trọng.

SLA remediation nên cân nhắc exploitability, exposure, asset criticality, compensating control và dependency. Nếu có active exploitation, incident process có thể được kích hoạt thay vì chờ vulnerability SLA thông thường.

Escalation, authority và containment

Escalation và elevation khác gì?

NIST SP 800-61r3 lưu ý incident cần được escalation hoặc elevation khi cần. Trong thực tế Managed Security:

Escalation thường là đưa thêm chuyên môn, resource hoặc một đội khác vào xử lý.
Elevation thường là đưa vấn đề lên cấp quản lý hoặc business owner vì impact, risk acceptance hoặc quyết định vượt thẩm quyền kỹ thuật.

Hai đường này nên được định nghĩa trong escalation matrix thay vì chỉ có một danh sách số điện thoại.

Thông tin escalation tối thiểu trong SLA

Mỗi severity nên có primary technical contact, secondary/on-call contact, customer owner, business/management contact khi impact lớn, dependency vendor, kênh chính/dự phòng và điều kiện escalation tiếp theo nếu contact không phản hồi. Contact list phải được review định kỳ.

SLA chỉ cần xác định mức dịch vụ và điều kiện chuyển cấp; quy trình Alert → Incident → Escalation chi tiết nên được quản lý ở bài owner Security Escalation Matrix để tránh trùng intent.

Emergency authorization nên định nghĩa trước

Trong incident time-critical, chờ phê duyệt thủ công cho mọi action có thể làm impact tăng. Nhưng trao quyền quá rộng cũng tạo rủi ro production.

Có thể định nghĩa trước nhóm hành động khẩn cấp với giới hạn rõ, ví dụ: block một nguồn traffic cụ thể, revoke một credential đã xác nhận compromise, bật rule đã pre-approved hoặc isolate một endpoint. Mỗi action cần logging, read-back, validation và rollback khi phù hợp. Với thay đổi WAF, WAF Maintenance Checklist là một ví dụ về việc gắn rule/exception với test và validation định kỳ.

Những thay đổi rộng như block toàn quốc gia, disable toàn bộ API hoặc thay firewall sitewide thường cần level authorization cao hơn.

Containment SLA và Remediation SLA không giống nhau

Containment nhằm giảm impact sớm; remediation nhằm xử lý nguyên nhân hoặc finding. Một incident có thể được containment nhanh bằng cách disable endpoint nhưng code fix cần nhiều ngày. Nếu SLA chỉ dùng “resolution time”, hai loại outcome này dễ bị trộn.

Nên đo riêng thời gian đến khi có risk-reducing action, permanent fix, functional recovery và post-incident action.

Dependency với developer, hosting và vendor phải được phản ánh

Managed Security thường không kiểm soát toàn bộ stack. Nếu provider phát hiện lỗi business logic cần developer sửa, SLA của provider có thể cam kết triage, escalation, workaround và validation nhưng không nên cam kết thời điểm code fix khi không sở hữu development resource.

Tương tự, issue tại cloud/CDN/DNS vendor cần handoff rõ. Shared responsibility và inter-provider escalation là phần quan trọng của SLA.

SLA cho vulnerability remediation

Không nên áp một deadline duy nhất cho mọi finding. Có thể thiết kế policy dựa trên risk tier với các yếu tố:

Internet exposure.
Known exploitation hoặc exploit availability.
Asset criticality.
Privilege required.
Data/business impact.
Compensating controls.
Patch/fix availability.

Nếu chưa thể fix, SLA nên yêu cầu risk acceptance, mitigation tạm thời hoặc documented exception thay vì để item “quá hạn” vô thời hạn.

Evidence, KPI và review SLA

Evidence nào chứng minh SLA được đáp ứng?

SLA cần dựa trên timestamp và record có thể kiểm tra. Ở lớp server, Server Audit Logging giúp xác định nhóm sự kiện cần lưu để hỗ trợ điều tra và chứng minh timeline.

Alert/ticket creation time.
Human acknowledgment/triage timestamp.
Severity classification và lý do.
Escalation communication.
Containment/change record.
Customer/vendor dependency timestamp.
Validation/read-back.
Closure reason và follow-up action.

Không nên chỉnh sửa timestamp thủ công để “đẹp SLA”. Nếu metric bị miss, report nên thể hiện nguyên nhân và improvement action.

Managed Security SLA nên có KPI nào?

Một số metric hữu ích:

Time-to-acknowledge.
Time-to-triage.
Time-to-escalate.
Time-to-contain đối với incident đủ scope.
Tỷ lệ SLA met theo severity.
False-positive/reclassification rate.
Overdue high-risk remediation.
Recurring incident hoặc repeated finding.

Không nên dùng metric để gây áp lực “đóng ticket nhanh” thay vì giảm risk. Chất lượng triage và đúng severity quan trọng hơn một con số đẹp.

Ví dụ cấu trúc SLA mà không cần dùng “magic number”

Thay vì sao chép một bảng thời gian từ nhà cung cấp khác, doanh nghiệp có thể định nghĩa:

Critical: human triage ở mức nhanh nhất theo coverage đã mua; escalation ngay tới on-call và business owner; containment ưu tiên nếu có authority.
High: triage ưu tiên trong active coverage; xác định scope và mitigation; escalation nếu impact tăng.
Medium: đưa vào remediation workflow với owner/deadline dựa trên risk.
Low: review theo maintenance cadence hoặc backlog.

Sau đó tổ chức mới gắn con số cụ thể dựa trên staffing, business impact, coverage và khả năng thực thi. Cam kết không khả thi còn nguy hiểm hơn SLA dài nhưng thực tế.

Review SLA định kỳ

SLA không nên cố định nhiều năm khi kiến trúc và business thay đổi. Cần review khi website trở thành business-critical hơn, thêm API/payment/dữ liệu nhạy cảm, thay hosting/CDN/vendor, incident cho thấy escalation quá chậm, alert volume thay đổi đáng kể hoặc staffing/on-call coverage thay đổi.

Post-incident review là nguồn dữ liệu tốt để điều chỉnh severity model, contact matrix và response target.

Những lỗi thường gặp khi viết Managed Security SLA

Dùng “response time” mà không định nghĩa response là gì.
Cam kết resolution cho hạng mục phụ thuộc third-party.
Không tách monitoring 24/7 và human response 24/7.
Severity chỉ dựa trên tool score, không xét business impact.
Không có pause rule hoặc pause không được log.
Không định nghĩa emergency authority.
Contact/escalation matrix không được cập nhật.
Chỉ đo ticket closure, không đo containment hoặc risk reduction.

Kết luận

Managed Security SLA tốt phải biến kỳ vọng thành các mốc có thể đo: khi nào bắt đầu, ai triage, severity dựa trên gì, khi nào escalation, hành động nào được phép, điều gì pause SLA và evidence nào chứng minh kết quả. Không có một thời gian phản hồi universal cho mọi website; target phải dựa trên risk, business impact, coverage và resource thực tế.

Hãy ưu tiên SLA có thể thực thi hơn một bảng con số hấp dẫn nhưng mơ hồ. Khi incident xảy ra, clarity về owner, authority và escalation thường quan trọng không kém tốc độ.

Nguồn tham khảo: NIST SP 800-61 Rev. 3 về Incident Response; NIST IR 8286D về Business Impact Analysis và risk prioritization.