Dùng AI soạn bản nháp Sigma rule cho SIEM

Playbook giúp SOC dùng AI để phân tích hành vi, soạn bản nháp Sigma, kiểm tra log source, field và logic AND/OR trước khi chuyển rule sang truy vấn SIEM.

Một mô tả sự kiện vừa đến tay SOC: tài khoản Okta bị khóa sau quá nhiều lần đăng nhập. Việc cần làm không phải là viết vài từ khóa cho SIEM, mà là chuyển hành vi đó thành điều kiện phát hiện rõ ràng, đúng nguồn log và đúng logic.

AI có thể giúp soạn nhanh bản nháp Sigma rule. Nhưng AI không thể tự xác nhận SIEM của bạn có log nào, field nào hay truy vấn sau chuyển đổi có còn đúng ý nghĩa ban đầu hay không.

Nguyên tắc cốt lõi: AI hỗ trợ diễn đạt và rà logic; đội detection engineering xác nhận telemetry thực tế.

Sigma rule gồm những gì?

Sigma rule là tệp YAML chứa thông tin cần thiết để phát hiện hành vi bất thường, xấu hoặc độc hại khi kiểm tra log, thường trong bối cảnh SIEM.

Có thể chia một rule thành ba phần chính:

Detection: Điều kiện phát hiện hành vi. Logsource: Loại log mà rule cần tìm kiếm. Metadata: Thông tin như tiêu đề, mô tả, tác giả, tham chiếu, trạng thái hoặc mức độ cảnh báo.

Trong đó, phần detection là trung tâm của rule: nó mô tả chính xác dấu hiệu cần tìm trong các log phù hợp.

Trước khi viết YAML: tách hành vi thành dấu vết

Threat report là điểm khởi đầu, chưa phải rule. Trước khi yêu cầu AI viết YAML, hãy làm rõ:

Hành vi nào cần phát hiện? Hành vi đó để lại dấu vết nào trong log? Dấu vết nằm ở product và service nào? Field và giá trị nào đã được xác nhận? Các điều kiện phải đồng thời xảy ra hay chỉ cần một trong số đó? Hoạt động hợp lệ nào có thể tạo cảnh báo?

AI hữu ích nhất khi được giao một phạm vi dữ liệu rõ ràng. Đừng chỉ yêu cầu “viết Sigma rule phát hiện X”, vì điều đó dễ khiến mô hình tự điền tên field hoặc log source bằng suy đoán.

Dùng prompt theo cấu trúc sau:

text Bạn là trợ lý detection engineering cho SOC.

Nhiệm vụ: chuyển mô tả hành vi dưới đây thành BẢN NHÁP Sigma rule YAML.

Mô tả hành vi: <dán mô tả>

Log source đã xác nhận: product: <product> service: <service> field có trong log: <field và ví dụ giá trị>

Yêu cầu: Chỉ sử dụng các field đã được cung cấp. Nêu riêng thông tin còn thiếu cần xác minh. Giải thích logic AND/OR của điều kiện. Đề xuất false positive cần xem xét. Đặt status là test. Trả về: giả định, Sigma YAML và checklist xác minh.

Câu quan trọng nhất là: “Chỉ sử dụng các field đã được cung cấp.”

Nếu chưa có schema hoặc mẫu event, chưa nên yêu cầu AI tạo rule hoàn chỉnh. Thay vào đó, yêu cầu nó lập bảng phân tích:

text Từ mô tả hành vi sau, hãy lập bảng gồm: hành vi cần phát hiện bằng chứng log cần có log source cần xác nhận field cần xác nhận điều kiện logic dự kiến false positive có thể gặp

Không tạo Sigma YAML và không suy đoán tên field.

Hiểu đúng selection, AND và OR

Trong Sigma, các điều kiện phát hiện được tổ chức thành các nhóm gọi là selection. Mỗi selection chứa một phần định nghĩa của dấu hiệu cần tìm.

Tài liệu Sigma nêu hai quy tắc logic quan trọng:

Danh sách giá trị thể hiện quan hệ OR. Nhiều cặp field–value trong cùng một object thể hiện quan hệ AND.

Khi các điều kiện phải cùng đúng: AND

Ví dụ phát hiện thiết bị lưu trữ ngoài trong Windows Security log có thể yêu cầu:

EventID: 6416 ClassName: "DiskDrive"

Hai điều kiện nằm trong cùng một selection, nên đều phải khớp.

yaml detection: selection: EventID: 6416 ClassName: "DiskDrive" condition: selection

Đây là điểm AI dễ viết YAML trông hợp lý nhưng sai ý nghĩa. Khi review, hãy kiểm tra liệu các field cần đi cùng nhau có thực sự ở trong cùng một object hay không.

Khi một field có nhiều giá trị: OR

Nếu cần tìm một field có thể nhận nhiều giá trị, hãy dùng danh sách. Ví dụ với các sự kiện thay đổi group:

yaml detection: selection: EventID: 4728 4729 4730 condition: selection

Các giá trị trong danh sách được hiểu là quan hệ OR: event có một trong các EventID này sẽ khớp selection.

Keyword search: dễ viết, nhưng cần cân nhắc

Sigma cũng hỗ trợ tìm kiếm theo từ khóa trong log thô. Trong cách này, các mục trong keywords được xử lý theo quan hệ OR.

Ví dụ phát hiện hành vi can thiệp vào .bashhistory:

yaml detection: keywords: "rm bashhistory" 'echo "" > bashhistory' "truncate -s0 bashhistory" "history -c" "history -w" condition: keywords

Keyword search dễ bắt đầu, đặc biệt khi chưa có field chuẩn hóa. Tuy nhiên, tài liệu Sigma lưu ý rằng nhiều SIEM thường hoạt động tốt hơn với tìm kiếm dựa trên field.

Vì vậy:

Ưu tiên field-based detection khi log đã có field phù hợp. Dùng keyword search khi cần tìm chuỗi trong raw log. Yêu cầu AI giải thích vì sao chọn keyword hay field, thay vì chỉ trả YAML.

Ví dụ: bản nháp rule Okta

Tài liệu Sigma minh họa rule phát hiện tài khoản Okta bị khóa do vượt số lần đăng nhập:

yaml title: Okta User Account Locked Out status: test description: Detects when a user account is locked out. logsource: product: okta service: okta detection: selection: displaymessage: Max sign in attempts exceeded condition: selection falsepositives: Unknown level: medium

Ví dụ này cho thấy một rule tối thiểu cần liên kết rõ:

Nguồn log: Okta. Dấu hiệu: displaymessage có giá trị cụ thể. Điều kiện: selection đó phải khớp.

Trước khi dùng bản nháp tương tự trong môi trường của mình, SOC nên xác minh:

Log Okta đã được thu thập hay chưa. Event thực tế có field displaymessage hay không. Giá trị Max sign in attempts exceeded có xuất hiện đúng như vậy trong dữ liệu đang ingest không. Cảnh báo khóa tài khoản có phù hợp với mục tiêu giám sát của đội hay không. False positive cần được mô tả cụ thể hơn hay không.

Checklist review trước khi chuyển rule sang SIEM

Tài liệu Sigma có ví dụ chuyển rule thành truy vấn cho SIEM. Với vận hành hằng ngày, đội SOC có thể dùng checklist nội bộ sau trước khi triển khai:

Đọc lại mục tiêu phát hiện Rule cần phát hiện hành vi nào, và hành vi đó có được mô tả rõ không?

Xác nhận log source product và service có khớp với nguồn log đang có không?

Đối chiếu field với event thật Mỗi field và giá trị trong rule phải xuất hiện trong mẫu log thực tế.

Kiểm tra logic AND/OR Field nào phải cùng đúng? Giá trị nào là các khả năng thay thế?

Rà soát keyword search Nếu rule dùng keywords, hãy xác định liệu có field phù hợp hơn để tìm kiếm hay không.

Xem xét false positive Hoạt động quản trị hoặc vận hành hợp lệ nào có thể tạo tín hiệu tương tự?

Giữ trạng thái thử nghiệm khi cần status: test phù hợp để thể hiện rule vẫn cần được đánh giá thêm trước khi coi là ổn định.

Kiểm tra truy vấn sau chuyển đổi Khi chuyển Sigma sang ngôn ngữ truy vấn của SIEM, xác nhận truy vấn kết quả vẫn giữ nguyên logic ban đầu.

AI nên đứng ở đâu trong quy trình?

AI có thể hỗ trợ đội ngũ:

Tóm tắt mô tả hành vi thành các dấu hiệu cần quan sát. Gợi ý cấu trúc selection. Diễn giải logic AND/OR trong rule. Soạn bản nháp metadata, mô tả và false positive. Tạo checklist những field hoặc log source cần xác minh.

Nhưng AI không nên là bên cuối cùng quyết định:

Field có tồn tại trong telemetry hay không. Giá trị log có đúng với môi trường thực tế hay không. Rule có đủ chính xác để đưa vào vận hành hay không. Truy vấn SIEM sau chuyển đổi có đúng logic hay không.

Checklist trước khi merge Sigma rule

[ ] Hành vi cần phát hiện được mô tả rõ. [ ] Log source đã được xác nhận. [ ] Mọi field trong rule đã được đối chiếu với event thật. [ ] Logic AND/OR phản ánh đúng ý định phát hiện. [ ] Rule ưu tiên tìm kiếm theo field khi có thể. [ ] Keyword search chỉ được dùng khi phù hợp với dữ liệu. [ ] False positive đã được xem xét. [ ] Rule đang ở trạng thái phù hợp, chẳng hạn test khi còn cần đánh giá. [ ] Truy vấn sau chuyển đổi sang SIEM vẫn giữ đúng logic Sigma. [ ] Có người chịu trách nhiệm review trước khi triển khai.

AI có thể rút ngắn thời gian từ mô tả hành vi đến bản nháp Sigma. Nhưng một detection đáng tin cậy vẫn phụ thuộc vào log source đúng, field đúng và logic đúng.