Xây dựng quy trình tối ưu tập luật

Một phần của tài liệu Nghiên cứu và phát triển hệ thống phát hiện bất thường dựa trên log (Trang 104 - 108)

CHƯƠNG 3 TRIỂN KHAI VÀ ĐÁNH GIÁ HỆ THỐNG

3.5 Xây dựng quy trình tối ưu tập luật

Trong quá trình giám sát an toàn thông tin, tập luật cần phải liên tục làm giàu, cập nhật thêm các dấu hiệu để sớm phát hiện các kỹ thuật tấn công mới. Đồng thời, nó cũng cần được tối ưu để giảm số lượng cảnh báo sai gây nhiễu cho hệ thống giám sát.

Thống kê số lượng cảnh báo trên hệ thống SIEM trong một tuần

Sắp xếp cảnh báo theo số lượng từ cao xuống thấp

Xác định các rules tương ứng và điều kiện của nó

Thống kê các sự kiện bị trigger bởi điều kiện của rules

Gửi khách hàng xác nhận hành vi và tạo Building Block False Positive Thống kê số lượng cảnh báo liên quan

sau 7 ngày thực hiện tối ưu luật

Hình 3.7. Sơ đồ quy trình tối ưu tập luật trên hệ thống SIEM

Để tối ưu tập luật, ta có thể thực hiện theo sơ đồ bên trên [Hình 3.7]. Cụ thể, gồm các bước sau:

96

Bước 2: Sắp xếp cảnh báo theo số lượng từ cao xuống thấp

Bước 3: Xác định các luật tương ứng với cảnh báo và điều kiện của nó

Bước 4: Thống kê các sự kiện bị trigger bởi điều kiện của luật

Bước 5: Gửi khách hàng xác nhận hành vi và tạo các Building Block False Positive rồi bổ sung vào tập luật.

Bước 6: Thống kê số lượng cảnh báo liên quan sau 7 ngày tối ưu tập luật và đánh giá hiệu quả của việc tối ưu cho từng luật.

Trong sơ đồ trên, tại Bước 4, thông thường, ta cần thống kê một số thông tin trong bảng sau:

Bảng 3.7. Bảng thống kê các thông tin cần thu thập để tối ưu tập luật

Process Path Process CommandLine Parent Process Path Parent CommandLine Log Source Username Source IP

Trong đó, các trường trên có ý nghĩa sau:

- Process Path: Đường dẫn tuyệt đối của tiến trình thực thi

- Process CommandLine: Tham số của tiến trình được thực thi

- Parent Process Path: Đường dẫn tuyệt đối của tiến trình cha khởi chạy

- Parent CommandLine: Tham số của tiến trình cha khởi chạy

- Log Source: Tên của log source ghi nhận sự kiện

- Username: Tên người dùng thực hiện

- Source IP/Destination IP: Địa chỉ IP nguồn/đích liên quan đến sự kiện Ngoài ra, với một số điều kiện khác, cần thu thập thông tin về các QID tương ứng với mỗi sự kiện, các EventID được sử dụng, Log Source Type, cũng như các Reference Set/Reference Data liên quan.

Để đảm bảo an toàn cũng như giảm tối đa rủi ro có thể có thì khi cấu hình whitelist một số điều kiện để tối ưu tập luật nhằm giảm cảnh báo False Positive, ta cần sử dụng các tham số, đường dẫn tuyệt đối, theo giá trị cụ thể, không sử dụng tìm kiếm từ khóa bằng giá trị %.

+) Để thực hiện whitelist một thuộc tính mà có nhiều giá trị, nên tạo một Reference Set để dễ dàng quản lý và cập nhật điều kiện. Quy tắc đặt tên RS như sau: TenKH_Rules_DieuKien. Ví dụ KHA_BB:UC001_ProcessPath. Tùy thuộc vào loại giá trị mà chọn kiểu của Reference Set tương ứng, thông thường chọn là

97

AlphaNumeric (Ignore Case) để lưu kết quả dưới dạng không phân biệt chữ hoa, chữ thường.

+) Xây dựng whitelist cho mỗi rules dưới dạng các BB theo quy tắc đặt tên như sau: BB:FalsePositive: BB:Rule_1, BB:FalsePositive: BB:Rule_2, v.v. Trong đó, mỗi BB sẽ sử dụng một số điều kiện sau:

-Nên viết điều kiện dưới dạng AQL (and when the event matches "Process CommandLine" ILIKE 'value' AQL filter query) với giá trị value thường là giá trị tuyệt đối của tham số, hạn chế/không sử dụng tìm kiếm từ khóa theo ký tự % trong câu điều kiện. Sử dụng ILIKE sẽ cho phép so sánh giá trị của 2 xâu ký tự mà không phân biệt hoa thường.

-Sử dụng Reference Set để quản lý chuỗi các giá trị cần whitelist. Khi có nhiều hơn 1 thuộc tính cần whitelist, nên sử dụng Reference Data.

+) Sau khi tạo BB:FalsePositive: BB:Rule_1, …, ta thêm chúng vào rules để giảm các cảnh báo False Positive theo cách bên dưới:

Điều kiện

Điều kiện 1

and NOT when an event matches any of the following BB:FalsePositive: BB:Rule_1, BB:FalsePositive: BB:Rule_2, …

Nếu dùng IMATCHES để viết các câu truy vấn sử dụng biểu thức chính quy, cần chú ý một số ký tự đặc biệt sau:

Bảng 3.8. Bảng thống kê các ký tự cần chú ý khi tối ưu tập luật trên SIEM

STT Ký tự Điều kiện trong AQL

1 \ \\

2 . \.

3 ‘ \’

4 “space” \s

Các ký tự trên có thể sẽ thay đổi tùy thuộc vào từng phiên bản Qradar. Nên kiểm tra kỹ các dấu chấm, dấu phảy, dấu cách cũng như các ký tự đặc biệt trong giá trị của thuộc tính khi sử dụng truy vấn AQL để đảm bảo luật được hoạt động đúng.

Để tối ưu nguồn logs trên máy chủ cài đặt một số dịch vụ như Sysmon, OSQuery, Auditd, ta có thể thực hiện theo các bước trong sơ đồ bên dưới. Đối với Windows Event Logs, hoặc Linux OS, có thể lọc bớt các sự kiện cần lưu trữ sử dụng các bộ lọc trong Qradar Log Source Management.

98

Thống kê số lượng sự kiện theo Log Source Type

Sắp xếp Event Name theo thứ tự số lượng từ cao xuống thấp

Thống kê các điều kiện ứng với các sự kiện có số lượng lớn

Xác nhận lại hành vi trong logs với khách hàng và đề xuất whitelist Thêm bộ lọc sự kiện vào tập luật trên

máy chủ để tối ưu nguồn logs Thống kê số lượng sự kiện theo Log

Source Type trong 7 ngày tiếp theo

99

Một phần của tài liệu Nghiên cứu và phát triển hệ thống phát hiện bất thường dựa trên log (Trang 104 - 108)

Tải bản đầy đủ (PDF)

(115 trang)