SLA Metrics trong SOC: MTTT, MTTI, MTTR
Tìm hiểu về các chỉ số SLA quan trọng trong SOC và cách cải thiện hiệu suất
📋 Mục lục
📊 SLA là gì và tại sao quan trọng?
SLA (Service Level Agreement) là thỏa thuận về mức độ dịch vụ giữa SOC và khách hàng, định nghĩa các chỉ số hiệu suất và thời gian phản ứng.
💡 Tại sao SLA quan trọng?
- • Đo lường hiệu suất: Đánh giá khả năng xử lý sự cố của SOC
- • Quản lý kỳ vọng: Khách hàng biết được thời gian phản ứng
- • Cải thiện liên tục: Xác định các điểm cần cải thiện
- • Tuân thủ quy định: Đáp ứng các yêu cầu pháp lý
⚡ MTTT - Mean Time To Triage
📋 Định nghĩa
MTTT là thời gian trung bình từ khi cảnh báo xuất hiện đến khi SOC Analyst bắt đầu xử lý (triage) cảnh báo đó.
🎯 Mục tiêu MTTT:
- • Critical: ≤ 5 phút
- • High: ≤ 15 phút
- • Medium: ≤ 30 phút
- • Low: ≤ 60 phút
🔍 Cách tính MTTT
Công thức: MTTT = Tổng thời gian triage / Số lượng cảnh báo
Ví dụ: 100 cảnh báo, tổng thời gian triage = 500 phút → MTTT = 5 phút
🔍 MTTI - Mean Time To Investigation
📋 Định nghĩa
MTTI là thời gian trung bình từ khi bắt đầu triage đến khi hoàn thành điều tra và xác định được bản chất của sự cố.
🎯 Mục tiêu MTTI:
- • Critical: ≤ 30 phút
- • High: ≤ 2 giờ
- • Medium: ≤ 4 giờ
- • Low: ≤ 8 giờ
🔍 Cách tính MTTI
Công thức: MTTI = Tổng thời gian investigation / Số lượng sự cố
Ví dụ: 50 sự cố, tổng thời gian investigation = 100 giờ → MTTI = 2 giờ
🛠️ MTTR - Mean Time To Respond
📋 Định nghĩa
MTTR là thời gian trung bình từ khi sự cố được phát hiện đến khi hoàn tất các hành động ứng cứu (contain, eradicate, recover) và hệ thống trở về trạng thái bình thường.
🎯 Mục tiêu MTTR:
- • Critical: ≤ 4 giờ
- • High: ≤ 24 giờ
- • Medium: ≤ 72 giờ
- • Low: ≤ 168 giờ (1 tuần)
🔍 Cách tính MTTR
Công thức: MTTR = Tổng thời gian respond / Số lượng sự cố
Ví dụ: 20 sự cố, tổng thời gian respond = 200 giờ → MTTR = 10 giờ
📚 Tham khảo SLA theo Severity
🚨 Critical Severity
Ví dụ: Ransomware attack, data breach, system compromise
⚠️ High Severity
Ví dụ: Brute force attack, malware detection, suspicious activity
⚡ Medium Severity
Ví dụ: Policy violations, unusual network traffic, failed logins
ℹ️ Low Severity
Ví dụ: Information gathering, reconnaissance, low-risk alerts
Lưu ý quan trọng về Metrics Terminology
Mỗi SIEM, SOAR, hoặc SOC platform có thể sử dụng các thuật ngữ và concept khác nhau để đo lường hiệu suất. Điều quan trọng là hiểu rõ định nghĩa của từng metric trong hệ thống bạn sử dụng.
📊 Một số concept phổ biến khác:
Ví dụ: Thời gian từ khi hacker truy cập trái phép đến khi SIEM tạo alert.
Ví dụ: IBM Resilient sử dụng MTTC để đo toàn bộ incident lifecycle.
Ví dụ: Splunk Enterprise Security tracking MTTA để đảm bảo không có alert bị bỏ lỡ.
Ví dụ: Palo Alto XSOAR có thể track MTTR như recovery time.
💡 Best Practice:
- • Document định nghĩa: Ghi rõ metrics nào bạn đang đo và cách tính như thế nào
- • Consistency: Đảm bảo toàn bộ team hiểu và sử dụng metrics giống nhau
- • Tool-specific: Tham khảo documentation của SIEM/SOAR bạn đang dùng để hiểu metrics của họ
- • Custom metrics: Có thể tự định nghĩa metrics phù hợp với quy trình của SOC bạn
🚀 Cách cải thiện SLA
⚡ Cải thiện MTTT
- • Automation: Tự động hóa việc phân loại và ưu tiên cảnh báo
- • Real-time monitoring: Giám sát thời gian thực với dashboard
- • Alert correlation: Gộp các cảnh báo liên quan thành một case
- • Staff training: Đào tạo SOC Analyst xử lý nhanh hơn
🔍 Cải thiện MTTI
- • Playbooks: Tạo quy trình điều tra chuẩn cho từng loại sự cố
- • Knowledge base: Xây dựng cơ sở tri thức về các sự cố thường gặp
- • Tools integration: Tích hợp các công cụ điều tra
- • Expert consultation: Kết nối với chuyên gia khi cần
🛠️ Cải thiện MTTR
- • Incident response plan: Kế hoạch ứng cứu sự cố chi tiết
- • Communication: Quy trình thông báo và phối hợp
- • Recovery procedures: Quy trình khôi phục hệ thống
- • Post-incident review: Rút kinh nghiệm sau mỗi sự cố
SOC Team
Đội ngũ chuyên gia SOC với nhiều năm kinh nghiệm
📅 Xuất bản: 20/01/2025 | ⏱️ 10 phút đọc | ⏱️ SLA Metrics