Những Kiến Thức Cơ Bản về KQL Mà Mọi Chuyên Gia SOC Cần Biết

Kusto Query Language (KQL) là nền tảng của việc tìm kiếm mối đe dọa và phân loại cảnh báo trong Microsoft Sentinel và Microsoft Defender. Nếu bạn đang làm việc trong một SOC, thành thạo KQL sẽ phân biệt những chuyên gia có thể nhanh chóng trả lời "điều gì đã xảy ra ở đây?" với những người bị mắc kẹt bấm qua các bảng điều khiển. Đây không phải là tài liệu tham khảo ngôn ngữ đầy đủ — đó là tập hợp thực tế được sử dụng liên tục khi làm việc.

Tại Sao KQL Quan Trọng trong SOC

KQL chỉ đọc và được tối ưu hóa để truy vấn các tập dữ liệu nhật ký lớn một cách nhanh chóng. Sentinel, Defender for Endpoint, Azure Monitor và Log Analytics đều sử dụng nó. Khi bạn biết nó, bạn có thể chuyển đổi giữa các sản phẩm với cùng một mô hình tinh thần: chọn một bảng, lọc nó, định hình đầu ra. Mỗi cuộc điều tra — phân loại email lừa đảo, tìm kiếm chuyển động sang bên — đều bắt đầu bằng một truy vấn.

Pipe Là Tất Cả

Các truy vấn KQL được xây dựng dưới dạng một đường ống. Bạn bắt đầu bằng một bảng và chuyển dữ liệu qua một loạt các toán tử, mỗi toán tử lọc, chuyển đổi hoặc tóm tắt kết quả trước đó:

SecurityEvent
| where EventID == 4625
| where TimeGenerated > ago(24h)
| summarize FailedLogons = count() by Account, Computer
| sort by FailedLogons desc

Đọc nó từ trên xuống dưới như một câu: bắt đầu với nhật ký SecurityEvent, chỉ giữ các lần đăng nhập không thành công (4625), giới hạn trong một ngày qua, đếm lỗi theo tài khoản/máy tính, rồi sắp xếp. Khả năng đọc tuyến tính đó là điểm mạnh lớn nhất của KQL so với SQL để tìm kiếm ad hoc.

Các Toán Tử Cốt Lõi Cần Ghi Nhớ

• where — bộ lọc chính của bạn. Sử dụng nó sớm và thường xuyên để giảm khối lượng dữ liệu trước các hoạt động tốn kém.
• project — chọn và đổi tên các cột cụ thể, loại bỏ tiếng ồn bạn không cần trong đầu ra.
• extend — thêm các cột được tính toán mà không loại bỏ các cột hiện có, hữu ích để phân tích chuỗi hoặc đánh dấu các điều kiện.
• summarize — tổng hợp dữ liệu bằng count(), sum(), dcount() hoặc make_set(), gần như luôn được ghép nối với by.
• join — tương quan các bảng, ví dụ, liên kết nhật ký đăng nhập với kho dữ liệu thiết bị để phát hiện các lần đăng nhập trên thiết bị không được quản lý.
• render — trực quan hóa kết quả dưới dạng timechart hoặc barchart trực tiếp trong trình chỉnh sửa truy vấn, tiện lợi để phát hiện các đỉnh.

Lọc Theo Thời Gian Được Thực Hiện Đúng

Luôn lọc theo TimeGenerated (hoặc cột dấu thời gian tương đương của bảng) càng sớm càng tốt trong đường ống. Các engine KQL tối ưu hóa nặng xung quanh các bộ lọc phạm vi thời gian, và việc đặt | where TimeGenerated > ago(7d) ở gần đầu thay vì ở dưới có thể là sự khác biệt giữa một truy vấn trả về trong vài giây và một truy vấn hết thời gian chờ trên một đơn vị thuê bao bận.```kql SigninLogs | where TimeGenerated > ago(1h) | where ResultType != "0" | where UserPrincipalName has "@yourdomain.com"

## Khớp Chuỗi: has vs contains vs ==

Một lỗi phổ biến là mặc định `contains` cho mọi thứ. `has` khớp các thuật ngữ toàn bộ và sử dụng một chỉ mục thuật ngữ, làm cho nó nhanh hơn đáng kể trên các bảng lớn. Chỉ sử dụng `contains` khi bạn cần khớp chuỗi con bên trong một từ (như một phần của miền), và sử dụng `==` để khớp chính xác trên các trường có cấu trúc như EventID hoặc IPAddress. Thói quen này sẽ tăng tốc độ tìm kiếm một cách đáng chú ý trên các bảng có khối lượng cao như `DeviceNetworkEvents` hoặc `CommonSecurityLog`.```kql
DeviceProcessEvents
| where ProcessCommandLine has "powershell"
| where ProcessCommandLine has_any ("-enc", "-EncodedCommand")

Xây Dựng Logic Phát Hiện Có Thể Tái Sử Dụng

Sau khi một truy vấn chứng tỏ hữu ích, hãy bọc nó dưới dạng một hàm với let, hoặc lưu nó dưới dạng Sentinel Analytics Rule với thực thi theo lịch. Tham số hóa các ngưỡng (như số lần đăng nhập không thành công) để cùng một logic có thể mở rộng quy mô trên các đơn vị thuê bao hoặc được điều chỉnh mà không cần viết lại từ đầu. Đây là cách các truy vấn tìm kiếm một lần phát triển thành các phát hiện đứng yên trang trí SOC tự động.

Những Cạm Bẫy Phổ Biến

• Quên TimeGenerated bộ lọc, gây ra các quét bảng toàn bộ chậm và tốn kém.
• Sử dụng summarize trước where, buộc engine phải tổng hợp dữ liệu chưa lọc.
• Tên cột không khớp khi nối các bảng — luôn kiểm tra schema trước bằng getschema.
• Lạm dụng contains, bỏ qua lợi ích lập chỉ mục và làm chậm các tìm kiếm quy mô lớn.

KQL thưởng cho các chuyên gia suy nghĩ theo đường ống thay vì các truy vấn phụ lồng nhau. Hãy bắt đầu mọi cuộc điều tra với một cửa sổ thời gian hẹp và một bảng cụ thể, sau đó mở rộng chỉ khi cần thiết.

Nếu điều này giúp bạn có một nền tảng vững chắc, hãy khám phá các phần Blue Team và Digital Forensics trên Korra Studio để có thêm các hướng dẫn truy vấn SOC thực hành và bài tập xây dựng phát hiện.