Vượt qua rule SIEM tĩnh và playbook SOAR

Một mô hình xây cho thời bình lặng hơn

Bộ công cụ SOC cổ điển dựa trên hai ý tưởng. SIEM thu thập log và chạy rule phát hiện trên đó; mỗi rule khớp sẽ sinh một alert. Nền tảng SOAR sau đó chạy playbook: chuỗi bước làm giàu thông tin và phản ứng được định sẵn, kích hoạt theo loại alert. Analyst đứng giữa, đọc alert và quyết định làm gì.

Mô hình đó giả định số nguồn dữ liệu vừa phải, rule viết xong thì đúng mãi, và các tình huống lặp lại đủ giống để một kịch bản cố định xử lý được. Ngày nay không giả định nào còn đứng vững. Môi trường thay đổi hằng tuần, nguồn cloud và SaaS tăng lên, còn kẻ tấn công cố tình hành xử như quản trị viên.

Vấn đề thứ nhất: alert dồn dập

SIEM xoay quanh rule đánh giá từng rule một cách riêng rẽ. Một chuỗi hành vi đáng ngờ trên một máy chủ có thể kích hoạt cả chục rule, và mỗi lần khớp thành một alert riêng với mức nghiêm trọng riêng. Các vận hành thường ngày như backup, triển khai phần mềm hay script quản trị trông rất giống kỹ thuật của kẻ tấn công và kích hoạt đúng những rule đó.

Kết quả thì analyst nào cũng quen: một hàng đợi trong đó cùng một hoạt động xuất hiện nhiều lần, phần lớn alert hoá ra hợp lệ, và vài alert thực sự quan trọng thì khó tìm. Các đội phản ứng bằng cách nâng ngưỡng hoặc tắt bớt rule, vừa giảm nhiễu vừa tạo ra điểm mù.

Gốc rễ nằm ở đơn vị công việc. Một alert mô tả một quan sát đơn lẻ. Một cuộc tấn công là một câu chuyện trải qua nhiều host, tài khoản và thời điểm. Chừng nào alert còn là đơn vị, analyst còn phải tự tay ghép lại câu chuyện.

Vấn đề thứ hai: playbook dễ gãy

Playbook có giá trị vì nó làm phản ứng lặp lại được. Nhưng nó cũng là code, và là code chạm tới nhiều hệ thống bên ngoài. Một phiên bản API đổi, một field bị đổi tên trong nguồn làm giàu dữ liệu, một đội tổ chức lại quyền sở hữu firewall, và playbook hoặc lỗi ầm ĩ, hoặc tệ hơn, vẫn chạy và âm thầm làm sai.

Mỗi playbook cũng chỉ mã hoá một lối đi cho một tình huống. Sự cố thực tế thì rẽ nhánh: cùng một loại alert có thể là job backup cấu hình sai trên máy này và là xâm nhập trên máy kia. Muốn phủ các nhánh thì cần thêm playbook, và bảo trì hàng trăm playbook trở thành một công việc riêng. Nhiều tổ chức rốt cuộc chỉ có một nhóm nhỏ playbook đáng tin và một danh sách dài không ai dám chạy.

Vấn đề thứ ba: rule trôi và mù trong im lặng

Rule phát hiện được viết theo field và định dạng log cụ thể. Khi một nguồn được nâng cấp, parser thay đổi, hay một field bị đổi tên hoặc chuyển chỗ, rule không nhất thiết báo lỗi. Nó vẫn chạy, không khớp gì và không báo gì. Nhìn từ console, đó chỉ là một tuần yên ả.

Điều tương tự xảy ra khi một nguồn log ngừng gửi, gửi trễ hoặc chỉ gửi một phần. Nếu không có bước kiểm tra liên tục rằng mỗi rule vẫn thấy đúng dữ liệu nó được xây cho, độ phủ phát hiện bị bào mòn mà không ai quyết định xoá nó. Các đội detection engineering hiểu rất rõ vấn đề này; ít đội có thời gian rà mọi rule trên mọi nguồn mỗi tuần.

Vấn đề thứ tư: tri thức bước ra khỏi cửa

Analyst giàu kinh nghiệm mang trong đầu một tấm bản đồ môi trường: tài khoản dịch vụ nào luôn chạy script lạ ban đêm, máy chủ nào kết nối hợp lệ tới một quốc gia bất thường, alert nào từ rule nào luôn là nhiễu. Tri thức ấy làm triage nhanh. Nó hiếm khi được ghi lại ở dạng mà hệ thống dùng được.

Biến động nhân sự cao và nhân tài khan hiếm. ISC2 ước tính khoảng thiếu hụt nhân lực an ninh mạng toàn cầu là 4,8 triệu người, và 90% người được khảo sát cho biết tổ chức của họ thiếu kỹ năng ^[1]. Mỗi người ra đi đặt lại một phần đường cong học tập của SOC, và mỗi người mới mất hàng tháng để dựng lại.

Giữ SIEM, đổi mô hình vận hành

Không điều nào ở trên có nghĩa là bỏ SIEM hay EDR. Chúng vẫn là nơi tốt nhất để thu thập dữ liệu giám sát và chạy phát hiện. Điều thay đổi là những gì xảy ra sau đó. Thay vì đổ vào một hàng đợi để con người xử lý từng alert, luồng alert đi vào một hệ thống đọc mọi alert, gắn nó với thực thể liên quan, dựng câu chuyện, kiểm chứng kết luận trên log thô và giữ lại những gì học được.

Phản ứng cũng đổi. Thay vì một script chạy mỗi khi điều kiện khớp, hệ thống chuẩn bị một đề xuất kèm bằng chứng, tác động dự kiến và cách hoàn tác, và một người phê duyệt. Nội dung phát hiện cũng cải thiện theo cách đó: thay đổi rule được đề xuất, thử trên chính lịch sử dữ liệu của bạn và được xem xét trước khi áp dụng.

Đây là hướng ApexAI theo đuổi: làm việc trên SIEM và EDR bạn đang chạy, bắt đầu bằng quyền chỉ đọc, và biến chúng thành một hoạt động biết học thay vì một đống rule và playbook ngày càng phình to. Trang Vì sao ApexAI giải thích bối cảnh rộng hơn.

Câu hỏi thường gặp