Một incident cho một câu chuyện tấn công: case lấy thực thể làm trung tâm

Vấn đề phân mảnh

Phần lớn triển khai SIEM và SOAR tạo case từ rule. Một rule kích hoạt, một case được mở. Việc gom nhóm, nếu có, thường theo tên rule và một khung thời gian ngắn. Cách đó ổn khi tấn công đơn giản và nhanh. Xâm nhập thật thì không như vậy. Một kẻ tấn công có thể kích hoạt alert về thông tin đăng nhập, alert tiến trình đáng ngờ, alert lateral movement và alert truy cập dữ liệu trong nhiều ngày, mỗi cái từ một rule khác nhau, thường từ một sản phẩm khác nhau.

Kết quả là phân mảnh. Một cuộc tấn công thành nhiều case, đôi khi do nhiều analyst xử lý ở các ca khác nhau. Mỗi case nhìn riêng chỉ ở mức vừa phải. Analyst đóng case thứ ba là "có lẽ là việc quản trị" có thể không bao giờ thấy hai case đầu trên cùng host đã cho thấy dấu hiệu đánh cắp thông tin đăng nhập. Alert đến muộn, sau khi case liên quan đã đóng, thường mở một case mới thay vì nhập vào câu chuyện mà nó thuộc về.

Phân mảnh gây thiệt hại hai lần. Nó lãng phí công sức, vì cùng một ngữ cảnh lại được thu thập cho từng case. Và nó che giấu rủi ro, vì mẫu hình lẽ ra làm sự cố lộ rõ lại bị chia ra nhiều bản ghi mà không ai đọc cùng nhau.

Đặt thực thể vào trung tâm

Cách khác là tổ chức công việc quanh thực thể: host, tài khoản, địa chỉ IP và ứng dụng mà alert nói tới. Một thực thể có lịch sử, có nhịp hành vi bình thường, có vai trò trong nghiệp vụ và có các thực thể liên quan. Khi mọi alert được gắn vào các thực thể liên quan, câu hỏi chuyển từ "alert này nghĩa là gì?" sang "chuyện gì đang xảy ra với host này, và nó có khác thường không?".

Làm việc theo thực thể cần nhận diện thực thể tốt. Cùng một máy xuất hiện dưới tên ngắn ở log này, tên đầy đủ ở log khác và địa chỉ IP ở log thứ ba. Cùng một người có thể có nhiều tài khoản. Chừng nào các bí danh đó chưa được hợp nhất thành một thực thể chuẩn, việc gom theo thực thể chỉ tái tạo sự phân mảnh dưới một cái tên khác.

Vì sao đơn vị quyết định nên nhỏ

Nếu gom theo thực thể là tốt, gom mọi thứ của một thực thể vào một chỗ có tốt hơn không? Không hẳn. Một thực thể sống lâu, như một máy chủ bận rộn, có thể tích luỹ cả hoạt động lành tính lẫn tấn công thật qua nhiều tháng. Đóng "cả thực thể" là lành tính sẽ cuốn theo một cuộc tấn công thật cùng với nhiễu. Đo trên dữ liệu SOC thật luôn cho thấy sự đánh đổi này: gom theo rule sinh nhiều lỗi nhỏ, còn gom theo cả thực thể sinh ít lỗi hơn nhưng mỗi lỗi lớn hơn.

Lời giải thực tế là dùng thực thể làm khung xem và khoá, còn một cụm hành vi có giới hạn thời gian trên thực thể đó làm đơn vị được quyết định và đóng. Cách này giữ mỗi lần đóng đủ nhỏ để an toàn, trong khi toàn bộ lịch sử vẫn hiện ra đầy đủ.

Các "hub" không nên gộp những câu chuyện không liên quan

Một số thực thể chạm vào gần như mọi thứ. Domain controller, hệ thống định danh, file server trung tâm và console quản trị xuất hiện trong phần lớn hoạt động. Coi chúng là liên kết bình thường sẽ dẫn tới gộp quá mức:

• Hai cuộc xâm nhập không liên quan cùng xác thực qua một domain controller, và cách gom ngây thơ biến chúng thành một incident khổng lồ.
• Một service account ồn ào nối hàng chục host không có điểm chung nào khác.
• Một incident phình to đến mức không ai đọc nổi, tức là phân mảnh theo chiều ngược lại.
• Cách tốt hơn: hub được hiển thị như ngữ cảnh trong từng câu chuyện nhưng tự nó không bắc cầu nối hai câu chuyện với nhau.
• Liên kết giữa các thực thể nên có giới hạn thời gian, để hoạt động cách nhau nhiều tuần không bị nối chuỗi khi thiếu bằng chứng khác.
• Mỗi thực thể bị ảnh hưởng giữ chuỗi hoạt động mạch lạc của riêng nó, và incident cho thấy các chuỗi đó kết nối với nhau ra sao.

Đo lường thành công

Các đội chuyển sang incident theo câu chuyện nên đo nhiều hơn số ticket. Những câu hỏi hữu ích gồm: khi con người xác nhận một sự cố thật, nó đã bị chia thành bao nhiêu case riêng? Các alert đến muộn có nhập đúng câu chuyện không? Một lần đóng cuốn theo bao nhiêu alert, và bao lâu thì một lần đóng chứa thứ về sau được xác nhận là độc hại? Mỗi incident có đọc được không, hay đã thành bãi chứa? Theo dõi cả phân mảnh lẫn gộp quá mức giữ cho việc gom nhóm trung thực ở cả hai chiều.

ApexAI tiếp cận thế nào

ApexAI Autonomous SOC lấy thực thể làm trung tâm ngay từ thiết kế. Alert từ SIEM và EDR của bạn được gắn vào các thực thể chuẩn đã hợp nhất bí danh, case được hình thành quanh một thực thể và hành vi của nó theo thời gian, và incident nối các case làm nên một câu chuyện tấn công, kèm bằng chứng cho từng liên kết. Hạ tầng dùng chung như domain controller được hiển thị như ngữ cảnh mà không gộp những câu chuyện không liên quan. Analyst thấy một câu chuyện cho mỗi cuộc tấn công, cùng lịch sử họ cần, thay vì cùng một cuộc tấn công trong nhiều ticket.

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