Phát hiện bất thường: Các chiến lược giúp tăng cường bảo mật hoạt động IT
Phần lớn đội ngũ IT Operations hiện vẫn dựa vào các ngưỡng cố định (static threshold) và cảnh báo dựa trên chữ ký (signature-based alerting). Cách tiếp cận này có vẻ đáp ứng được nhu cầu, nhưng vấn đề là hạ tầng IT ngày nay liên tục thay đổi và không còn vận hành theo những mô hình đủ ổn định để các phương pháp này hoạt động hiệu quả. Bài viết sẽ phân tích các chiến lược phát hiện bất thường trong IT (IT anomaly detection) hiệu quả trong thực tế, những trường hợp phân tích hành vi (behavior analytics) mang lại lợi thế so với phương pháp cảnh báo truyền thống, cũng như những yếu tố doanh nghiệp cần chuẩn bị để triển khai hiệu quả trên quy mô lớn.
Hãy bắt đầu với một tình huống mà hầu hết chúng ta đều từng gặp: CPU của một server tăng lên 79%. Không có cảnh báo nào được kích hoạt. Đến 80%, ngưỡng cảnh báo mới kích hoạt và một kỹ sư nhận được thông báo. Lúc này, tình trạng suy giảm hiệu năng đã diễn ra trong suốt 40 phút - đủ lâu để các vấn đề về độ trễ (latency) lan sang những dịch vụ phụ thuộc, khiến sự cố khó kiểm soát hơn nhiều so với nếu được phát hiện ngay từ phút thứ 5.
Các ngưỡng cố định đơn giản là không thể nhận biết những gì đã diễn ra trước khi ngưỡng bị vượt qua.
Vậy làm thế nào để giải quyết vấn đề này?
Một chiến lược IT anomaly detection hiệu quả không chỉ kiểm tra xem một chỉ số đã vượt ngưỡng hay chưa, mà còn đặt câu hỏi: Hệ thống có đang hoạt động giống như trạng thái bình thường của chính nó không? Nếu câu trả lời là không, hệ thống sẽ phát hiện và cảnh báo bất thường từ sớm, trước khi ngưỡng bị vượt qua và các hệ thống giám sát tĩnh phát cảnh báo. Trong những môi trường hạ tầng có tính động, phân tán và liên tục thay đổi, khác biệt này có thể quyết định việc đội ngũ IT phát hiện và xử lý vấn đề từ sớm trước khi nó lan rộng, hay phải đối mặt với một sự cố nghiêm trọng trên môi trường production.
Phát hiện bất thường trong IT thực sự ý nghĩa gì trong ITOps?
Phát hiện bất thường IT (IT anomaly detection) là phương pháp xác định các sai lệch so với hành vi bình thường đã được thiết lập trên hạ tầng, mạng và ứng dụng, sử dụng các mô hình thống kê để phát hiện vấn đề trước khi chúng leo thang thành sự cố.
Behavior analytics là cách triển khai phương pháp này trong thực tế. Hệ thống phân tích dữ liệu telemetry trong quá khứ như lưu lượng mạng, mức sử dụng tài nguyên, tỷ lệ lỗi và các mẫu kết nối (connection pattern) để xác định trạng thái hoạt động bình thường của môi trường IT. Khi hành vi thực tế sai lệch đáng kể về mặt thống kê so với mô hình đã thiết lập, hệ thống sẽ xác định đó là một bất thường.
Điểm khác biệt quan trọng so với phương pháp cảnh báo dựa trên ngưỡng truyền thống nằm ở khả năng nhận biết ngữ cảnh. CPU ở mức 75% không nhất thiết là bất thường. Nhưng nếu CPU thường chỉ ở mức 30% vào sáng thứ Ba và đột nhiên duy trì ở mức 75%, đó lại là một sai lệch đáng chú ý. Hệ thống behavior analytics có thể phát hiện trường hợp thứ hai, trong khi ngưỡng cố định sẽ không cảnh báo trong cả hai trường hợp, trừ khi 75% chính là giới hạn đã được cấu hình.
Khi cảnh báo dựa trên ngưỡng không còn hiệu quả
Chi phí của tình trạng "quá tải cảnh báo" (alert fatigue) không còn là vấn đề lý thuyết. Theo một báo cáo gần đây, hơn 40% cảnh báo trong hầu hết các hệ thống là cảnh báo giả (false alarm). Qua nhiều năm, các quản trị viên IT đã nhận ra rằng, với các hệ thống mạng IT hiện đại, phần lớn cảnh báo thậm chí không yêu cầu phải xử lý.
Ở chiều ngược lại, vấn đề cũng nghiêm trọng không kém: các sự cố phát triển chậm, các chỉ số dần lệch khỏi trạng thái bình thường hoặc những thay đổi bất thường rất nhỏ thường bị các hệ thống dựa trên ngưỡng bỏ sót, đơn giản vì chúng không vượt qua một ngưỡng cụ thể để kích hoạt cảnh báo.
Hệ quả sẽ thể hiện rõ ở chỉ số thời gian phản hồi trung bình (mean time to respond - MTTR) của bạn.
5 chiến lược phát hiện bất thường trong IT
1. Triển khai Network Detection and Response (NDR) để phát hiện bất thường trong lưu lượng mạng
Các mẫu lưu lượng mạng (traffic pattern) là một trong những nguồn dữ liệu quan trọng nhất giúp đội ngũ IT nhận biết những gì đang diễn ra trong hệ thống. Lưu lượng east-west đột ngột tăng cao, số lượng kết nối đến các điểm đích bên ngoài bất thường hoặc một thiết bị vốn sử dụng ít băng thông bỗng tiêu thụ lượng lớn tài nguyên đều có thể là những dấu hiệu sớm của cả vấn đề về hiệu năng lẫn sự cố bảo mật.
Khi áp dụng behavior analytics cho dữ liệu luồng (flow data), đội ngũ IT có thể phát hiện những sai lệch này trước khi chúng gây suy giảm dịch vụ hoặc phát triển thành sự cố bảo mật.
Chẳng hạn, tính năng Security Analytics ứng dụng ML của NetFlow Analyzer có thể theo dõi hành vi thông thường của từng tài sản và phát hiện sai lệch, chẳng hạn một thiết bị âm thầm truyền dữ liệu ra ngoài trong thời gian ngoài giờ làm việc. Mỗi sự kiện sau đó được đối chiếu với framework MITRE ATT&CK® để cung cấp ngay ngữ cảnh cần thiết cho quá trình phân tích mà không cần triển khai thêm agent trên toàn bộ môi trường.
2. Giám sát hệ thống mạng để chủ động phát hiện tình trạng cạn kiệt tài nguyên
Tình trạng cạn kiệt tài nguyên (resource exhaustion) hiếm khi xảy ra mà không có dấu hiệu cảnh báo từ trước. Với khả năng quan sát toàn diện, đội ngũ IT có thể theo dõi quá trình này diễn ra từng bước trong nhiều ngày hoặc nhiều tuần, theo cách mà các phương pháp giám sát tĩnh (static monitoring) khó có thể phát hiện. Báo cáo dự báo (Forecast Reports) và phân tích mẫu (pattern analysis) giúp xác định mức sử dụng tài nguyên hiện tại cũng như dự báo mức sử dụng trong tương lai.
Behavior analytics sẽ theo dõi xu hướng này, liên tục giám sát các giá trị hiện tại và phát cảnh báo khi tài nguyên đang có xu hướng tiến gần đến ngưỡng giới hạn, thay vì chờ đến khi ngưỡng thực sự bị vượt qua.
Việc phát hiện một vấn đề liên quan đến tài nguyên hệ thống (capacity issue) sớm hơn ba ngày có thể giúp đội ngũ IT chủ động xử lý trước khi nó phát triển thành sự cố ảnh hưởng đến tính khả dụng của hệ thống (IT availability incident).
3. Thiết lập baseline hiệu năng dịch vụ để ngăn chặn sự cố trước khi vi phạm SLA
Trong các môi trường phân tán, hiệu năng bình thường của một dịch vụ có thể thay đổi tùy theo thời điểm trong ngày, ngày trong tuần, độ tải từ hệ thống upstream (upstream load) và trạng thái của các dịch vụ phụ thuộc downstream (downstream dependency).
Ví dụ, thời gian phản hồi (response time) 300ms có thể hoàn toàn bình thường vào giờ cao điểm nhưng lại là dấu hiệu bất thường nếu xảy ra lúc 2 giờ sáng.
Behavior analytics duy trì baseline theo từng dịch vụ và từng thời điểm (time-aware baseline), từ đó đánh giá các sai lệch về hiệu năng dựa trên ngữ cảnh thực tế. Đây là điều mà các ngưỡng SLA cố định (static SLA thresholds), vốn được áp dụng đồng nhất trong mọi thời điểm, không thể thực hiện được.
4. Kích hoạt tính năng dự đoán sự cố (failure prediction) để đảm bảo uptime liên tục
Một số mẫu bất thường (anomaly patterns) thường xuất hiện trước những dạng sự cố cụ thể, chẳng hạn như dấu hiệu rò rỉ bộ nhớ (memory leak), thông lượng ổ đĩa suy giảm dần (disk throughput degradation) hoặc cạn kiệt connection pool (connection pool exhaustion). Những mẫu này có thể xuất hiện ở nhiều vị trí khác nhau trong hệ thống mạng nhưng thường có các đặc điểm hành vi (behavioral fingerprints) có thể nhận diện được.
Với khả năng phát hiện bất thường (anomaly detection), doanh nghiệp có thể tiến tới tự động hóa khắc phục (automated remediation) và cảnh báo dự đoán (predictive alerting), qua đó rút ngắn đáng kể thời gian phản ứng khi có dấu hiệu sự cố.
5. Phân tích sau sự cố (post-incident forensics) để tăng khả năng phục hồi
Behavior analytics cung cấp baseline lịch sử để đối chiếu với hành vi hiện tại. Điều này có nghĩa là hệ thống có thể tái dựng chính xác thời điểm hành vi bắt đầu lệch khỏi bình thường, tốc độ lệch và những tài sản nào bị ảnh hưởng. Việc phân tích sau sự cố - vốn trước đây đòi hỏi phải đối chiếu log thủ công - giờ chỉ còn là một truy vấn trên bộ dữ liệu hành vi đã được xây dựng sẵn.
Behavior analytics cần những gì để hoạt động hiệu quả?
Chất lượng của chiến lược phát hiện bất thường trong IT thường tỷ lệ thuận với chất lượng và độ bao phủ của dữ liệu telemetry cung cấp. Việc đo lường (instrumentation) không đầy đủ sẽ tạo ra baseline không đầy đủ, dẫn đến cảnh báo giả (false positive) và làm xói mòn lòng tin vào hệ thống.
1. Telemetry hợp nhất trên toàn bộ hệ thống
Behavior analytics cần nhìn thấy bức tranh toàn cảnh môi trường IT, bao gồm: dữ liệu luồng mạng (network flow data), chỉ số hạ tầng (infrastructure metrics), trace ứng dụng (application traces) và các sự kiện trên endpoint (endpoint events).
Những bất thường xuất hiện đồng thời trên nhiều loại tín hiệu thường có độ tin cậy cao nhất. Chẳng hạn, lưu lượng mạng tăng đột biến đi kèm mức sử dụng CPU cao và số lượng lỗi kết nối gia tăng là một tín hiệu đáng chú ý hơn nhiều so với việc xem xét riêng lẻ từng chỉ số. Một hệ thống chỉ quan sát được một lớp sẽ không thể xác định những mối tương quan này.
2. Đủ dữ liệu lịch sử
Baseline cần được xây dựng dựa trên lượng dữ liệu lịch sử đủ lớn để phản ánh các chu kỳ theo tuần, xu hướng theo tháng và biến động theo mùa (seasonal variation).
Ví dụ, một baseline chỉ được xây dựng từ hai tuần dữ liệu có thể nhận diện nhầm mức tải cao vốn thường xuất hiện hàng tháng là một bất thường. Phần lớn hệ thống cần khoảng 60 đến 90 ngày dữ liệu trước khi khả năng phát hiện đạt mức đủ tin cậy để triển khai trong môi trường production.
3. Mức độ chi tiết theo từng tài sản (asset-level granularity)
Các baseline tổng hợp (aggregate baselines) có thể bỏ sót những sai lệch ở cấp thiết bị hoặc dịch vụ, trong khi đây lại thường là những bất thường có ý nghĩa nhất đối với hoạt động vận hành.
Behavior analytics cần duy trì baseline riêng cho từng tài sản (asset), từng dịch vụ (service) và từng luồng lưu lượng (traffic flow), thay vì chỉ dựa trên giá trị trung bình của toàn bộ môi trường. Cách tiếp cận này đòi hỏi nhiều tài nguyên xử lý hơn nhưng cần thiết để đạt được độ chính xác và mức độ tin cậy mà hệ thống yêu cầu.
4. Tích hợp với quy trình xử lý sự cố (response workflow)
Một điểm bất thường chỉ hiển thị trên dashboard mà không được xử lý tiếp sẽ không mang lại giá trị đáng kể. Behavior analytics cần được kết nối với hệ thống ticketing, quản lý sự cố (incident management) và khắc phục tự động. Phát hiện chỉ là bước đầu tiên, không phải bước cuối cùng.
Vấn đề baselining: Điều các CXO cần chuẩn bị
Một trong những lý do phổ biến nhất khiến các chiến lược phát hiện bất thường trong IT (IT anomaly detection) không đạt hiệu quả như kỳ vọng trong thực tế chính là thời gian cần thiết để xây dựng baseline (baselining timeline). Doanh nghiệp thường triển khai với kỳ vọng chất lượng cảnh báo sẽ được cải thiện ngay lập tức. Tuy nhiên, trong 60 đến 90 ngày đầu tiên, hệ thống vẫn đang trong quá trình học, có thể tạo ra các cảnh báo giả (false positives) và cần được tinh chỉnh (tuning), đồng nghĩa với việc đội ngũ kỹ thuật phải dành thêm thời gian để tối ưu.
Đây không phải là vấn đề của sản phẩm. Đó là khoảng thời gian cần thiết để xây dựng một mô hình có thể phản ánh chính xác trạng thái hoạt động bình thường của một môi trường IT phức tạp. Sai lầm nằm ở việc doanh nghiệp không tính đến giai đoạn này ngay từ khi lập kế hoạch triển khai.
Trong giai đoạn xây dựng baseline (baselining period), doanh nghiệp nên chạy phân tích hành vi (behavior analytics) song song với hệ thống cảnh báo hiện có và sử dụng nó chủ yếu để hỗ trợ điều tra và bổ sung ngữ cảnh, thay vì ngay lập tức dùng làm cơ chế cảnh báo chính. Khi baseline dần đạt độ tin cậy cao hơn, doanh nghiệp có thể từng bước chuyển vai trò cảnh báo chính sang behavior analytics. Các doanh nghiệp đã triển khai behavior analytics ở mức độ trưởng thành ghi nhận số sự cố liên quan đến mối đe dọa nội bộ (insider threat) giảm 44%. Tuy nhiên, kết quả này chỉ đạt được sau một quá trình xây dựng và tinh chỉnh có chủ đích, chứ không xuất hiện ngay sau khi triển khai.
Môi trường hạ tầng mà các đội ngũ ITOps quản lý ngày nay đã trở nên quá phức tạp để chỉ dựa vào phương pháp giám sát theo ngưỡng cố định (fixed-threshold monitoring). Behavior analytics không thay thế lớp giám sát này mà bổ sung một lớp phân tích phía trên, giúp phát hiện những vấn đề mà các ngưỡng cố định không thể nhận biết, cảnh báo trước khi chúng phát triển thành sự cố nghiêm trọng và cung cấp ngữ cảnh cần thiết để đội ngũ vận hành nhanh chóng đưa ra hành động phù hợp.
Tài liệu gốc: IT anomaly detection: Strategies that help secure your IT operations