Khắc phục sự cố data ingestion trong Microsoft Defender XDR (TWL300 Lab 04, Phần 6/8)

Một nền tảng XDR mạnh đến đâu cũng vô dụng nếu dữ liệu ngừng chảy về. Lab 04 của chuỗi Microsoft Defender XDR (TWL300) tập trung vào một sự cố vận hành rất thực tế: data ingestion bị gián đoạn do app connector cấu hình sai. Bạn sẽ học cách phát hiện “khoảng trống” telemetry, kiểm tra sức khỏe từng workload Defender, ưu tiên xử lý và xác minh dữ liệu đã phục hồi.

Vì sao “vùng mù” ingestion lại nguy hiểm

Khi một connector (ví dụ Defender for Cloud Apps tới Box, Google Workspace) ngừng gửi log, các phát hiện liên quan sẽ âm thầm biến mất — không có alert nào báo rằng “bạn đang mù”. Đó là lý do mỗi SOC cần một quy trình chủ động phát hiện ingestion gap: so sánh thời điểm Last seen của connector với kỳ vọng, và dùng KQL để đo “nhịp tim” telemetry của từng bảng dữ liệu.

Bước 1 — Phát hiện ingestion gap qua app connector

Trong cổng Defender, vào System → Settings → Cloud Apps, dưới Connected apps chọn App connectors. Rà soát cột Status, mốc Last activity và mọi banner cảnh báo về sức khỏe/quyền. Mở flyout của một connector (ví dụ Microsoft 365) và chọn Test now để kiểm tra kết nối tức thời.

Hai lỗi thường gặp cần nhận diện: 401/Unauthorized (token hết hạn hoặc thiếu scope — cần re-authorize) và 429/TooManyRequests (vượt giới hạn polling — cần giảm tần suất hoặc phạm vi thu thập).

Bước 2 — Kiểm tra sức khỏe MDI, MDO và MDE

Tiếp theo, soát sức khỏe từng workload để khoanh vùng nguồn gây gián đoạn:

• Defender for Identity: vào Identities → Health issues để xem các vấn đề tenant/sensor (cấu hình sai, dịch vụ dừng, sensor lỗi thời).
• Defender for Office 365: xác nhận luồng telemetry email và các chính sách bảo vệ vẫn sinh phát hiện.
• Defender for Endpoint: kiểm tra xu hướng onboarding và heartbeat của sensor trên thiết bị.

Song song, mở Advanced hunting và chạy truy vấn “ingestion heartbeat” trên IdentityLogonEvents để đo khoảng trống. Truy vấn tính LastEvent, số Events và GapHours, rồi gắn cờ IngestionHealthy = Yes/No dựa trên cửa sổ thời gian kỳ vọng.

Lặp lại cách tiếp cận này cho các nguồn Endpoint, Email và CloudApp để có bức tranh đầy đủ về độ “tươi” của dữ liệu trên toàn bộ XDR.

Đọc kết quả “ingestion heartbeat” thế nào?

Giá trị GapHours là chỉ số quan trọng nhất: nếu nó nhỏ hơn cửa sổ kỳ vọng (ví dụ 6 giờ) và IngestionHealthy = Yes, nguồn dữ liệu đang khỏe. Ngược lại, GapHours lớn bất thường (hàng chục giờ) cùng số Events bằng 0 là dấu hiệu rõ ràng của một connector đã “chết”. Hãy đặt các truy vấn này thành scheduled query hoặc đưa vào dashboard health check hằng ngày ở Lab 01, để biến việc phát hiện vùng mù thành quy trình tự động thay vì kiểm tra thủ công.

Bước 3 — Ưu tiên connector và định nghĩa tiêu chí thành công

Không phải connector nào cũng quan trọng như nhau. Hãy ưu tiên theo mức rủi ro và độ phủ phát hiện: nguồn nào nuôi các phát hiện trọng yếu (đăng nhập, hành vi tải dữ liệu) cần được khôi phục trước. Định nghĩa rõ tiêu chí thành công — ví dụ: “telemetry CloudApp xuất hiện trở lại trong vòng 5 phút sau khi sửa” — để biết khi nào việc khắc phục hoàn tất, thay vì phán đoán cảm tính.

Bước 4 — Cấu hình lại connector và xác minh phục hồi

Áp dụng cách sửa tương ứng: với 401, chọn Re-authorize, đăng nhập bằng app admin và xác nhận scope; với 429, giảm tần suất/phạm vi polling theo mức nhà cung cấp hỗ trợ; rồi Save. Với Defender for Identity, vào System → Settings → Identities → Sensors và xác nhận Sensor status là Healthy với heartbeat cập nhật.

Cuối cùng, quay lại Advanced Hunting và chạy truy vấn kiểm chứng (đếm sự kiện sau “fix time”) để xác nhận telemetry đã chảy trở lại — bằng chứng khách quan rằng vùng mù đã được đóng.

Checklist xử lý sự cố ingestion

• ✅ App connector: Status, Last activity và kết quả Test now.
• ✅ Phân loại lỗi: 401 (re-authorize) hay 429 (giảm polling).
• ✅ MDI/MDO/MDE health issues đã rà, sensor Healthy.
• ✅ KQL heartbeat: GapHours trong ngưỡng, IngestionHealthy = Yes.
• ✅ Truy vấn kiểm chứng sau fix: có sự kiện mới được nạp.

Kết luận

Khắc phục sự cố data ingestion là kỹ năng vận hành cốt lõi: phát hiện gap, khoanh vùng theo workload, ưu tiên xử lý và xác minh phục hồi bằng dữ liệu. Một XDR chỉ đáng tin khi dữ liệu của nó liên tục và đầy đủ. Ở phần tiếp theo, chúng ta sẽ nâng tầm phân tích — ánh xạ một cuộc xâm nhập BEC theo MITRE ATT&CK. Theo dõi trọn bộ chuỗi tại Office365Vietnam.info.