Thuật toán phân cụm nhằm chia bộ dữ liệu ban đầu về các nhóm nhỏ hơn mà dữ liệu có sự tương quan lẫn nhau. Đây là một công cụ hữu hiệu cho việc phân tích dữ liệu và giúp tìm hiểu về cấu trúc của bộ dữ liệu. Thuật toán phân cụm phân cấp là một loại thuật toán phân cụm nhưng cung cấp nhiều thông tin về cấu trúc của cụm dữ liệu hơn so với các thuật toán phân cụm dạng phẳng như Kmeans. Với việc có sự phân cấp rõ ràng, ta có thể khám phá nhiều thông tin với nhiều khía cạnh khác nhau trong việc phân chia các cụm.
Tuy nhiên, các thuật toán phân cụm đều có độ phức tạp thuật toán lớn, khiến cho việc xử lý trên bộ dữ liệu lớn là rất khó khăn và bất khả thi trên những máy chủ có cấu hình yếu. Các phương pháp áp dụng MapReduce chủ yếu nhằm song song hóa thuật toán phân cụm trên các tập dữ liệu nhỏ trên nhiều máy khác nhau, rồi gộp lại cho kết quả cuối cùng. Điều này giúp cho chi phí tính toán ở mỗi máy có thể linh hoạt hơn, số lượng xử lý giảm đi, nhờ đó mở ra khả năng xử lý được khối lượng dữ liệu lớn hơn, và thời gian xử lý dữ liệu giảm thiểu đáng kể dù cho các máy chủ không có cấu hình tốt nhất.
26 Ở dạng phân cụm này, ta sẽ làm quen với thuật ngữ dendrogram, là các dạng đồ thị dạng cây, có thể được minh họa qua hình 2.11.
PARABLE [10] hay PArallel RAndom-partition Based HierarchicaL ClustEring Algorithm, là một thuật toán gồm 2 bước: tạo các cụm địa phương ở
các node server sử dụng các bước map và reduce, rồi gộp kết quả bằng cách sắp xếp lại các dendrogram lại với nhau. Bắt đầu với chia N điểm dữ liệu về M partition đều nhau, nếu dư đưa về partition cuối cùng. Phân cụm dữ liệu ở các partition về cùng một số cụm là K. Sau đó, lấy dendrogram ở partition đầu tiên làm mẫu cho các cụm dữ liệu. Gộp từ từ các dendrogram ở các partition khác với dendrogram này. Các dendrogram có dạng cây, vì thế sẽ so sánh độ tương quan của leftChild1
của dendrogram1 với leftChild2 và rightChild2 của dendrogram2, nếu cái nào giống hơn thì gộp vào leftChild1, không thì gộp vào rightChild1.
Độ tương quan ở đây được miêu tả là: Cho N là số điểm dữ liệu ở cây con
LS là tổng tuyến tính của N điểm dữ liệu SS là tổng bình phương của N điểm dữ liệu Thì Similarity(a,b) = (LSa · LSb + SSa · SSb)/(Na · Nb)
SHRINK [11] là một thuật toán chia sẻ bộ nhớ cho thuật toán phân cụm dạng cây dùng phương thức single-linkage, gộp cụm từ dưới lên (bottom-up), cho các bài toán con có sự chồng chéo. Bắt đầu với chia bộ dữ liệu thành các tập nhỏ đều nhau D1, D2,...,Dk. Với mỗi bộ dữ liệu (Di, Dj) ta thực hiện tính dendrogram cho chúng. Gộp các dendrogram đôi một lại với nhau theo độ tăng dần về chiều cao của cây,
27 loại bỏ các điểm data point trùng nhau. Phương pháp merge được sử dụng là sort lại 2 dendrogram cần merge, so chiều cao tại cặp điểm nhỏ nhất của dendrogram1
với cặp điểm nhỏ nhất của dendrogram2, cái nào chiều cao nhỏ hơn thì sẽ thực hiện merge cặp điểm đó thành cụm và cho vào dendogram3. Tương tự cho đến hết, dendrogram3 là kết quả merge cuối cùng.
28
CHƯƠNG 3. HỆ THỐNG PHÁT HIỆN THỰC THỂ BẤT THƯỜNG TRONG LOG GIÁM SÁT
Trong chương này, tôi sẽ mô tả cách thức xử lý và giao tiếp của từng thành phần trong hệ thống phát hiện thực thể bất thường. Ở công ty tôi đã có thành phần thu thập dữ liệu tập trung và thành phần hiển thị cảnh báo được xây dựng cho một hệ thống trước đó, nên tôi sẽ sử dụng lại các thành phần này. Sau đó, tôi sẽ đi vào chi tiết kĩ thuật áp dụng cho thành phần mà tôi xây dựng là thành phần xử lý dữ liệu để lấy ra các sự kiện gắn với các thực thể bất thường. Phần xử lý dữ liệu này nhằm tạo ra một bộ khung quản lý cấu hình, một nền tảng cho phép các chuyên gia an ninh thông tin tham gia cấu hình, làm giàu tri thức cho hệ thống, đồng thời cũng cho phép các chuyên gia phân tích dữ liệu cài đặt các thuật toán thống kê và các thuật toán học máy, giúp cho hệ thống có thể phát hiện các kịch bản tấn công phức tạp và tinh vi hơn.
3.1. Kiến trúc
Dựa trên kiến trúc chung của UEBA và tham khảo các kĩ thuật xử lý với log dữ liệu cũng như các hệ thống UEBA hiện có đã trình bày trong chương trước hệ thống sẽ gồm bốn thành phần: 1. thu thập và tổng hợp dữ liệu, 2. phát hiện thực thể bất thường, 3. phân tích nâng cao và 4. giám sát cảnh báo. Kiến trúc tổng quát được mô tả trong hình 3.1 với hai thành phần được tích hợp từ hệ thống cũ.
29
Hình 3.1.Kiến trúc
Thành phần thu thập và tổng hợp dữ liệu là thành phần thường có ở hầu hết các hệ thống, nhằm thu thập dữ liệu cần phân tích về một nơi tập trung để quản lý và xử lý. Với các nguồn dữ liệu cần phân tích, chúng sẽ được cấu hình bắn dữ liệu lên cụm Kafka tập trung mỗi khi có dữ liệu mới đổ về. Qua đó, các dịch vụ khác có thể cùng đọc về và xử lý riêng cho từng nghiệp vụ khác nhau.
Thành phần phát hiện thực thể bất thường là nơi xử lý trung tâm, cài đặt các thuật toán chính để phát hiện ra các điểm bất thường trong dữ liệu. Nó sẽ đọc dữ liệu từ cụm Kafka về theo thời gian thực và xử lý lọc lấy kết quả theo cấu hình rồi đưa dữ liệu ra Redis để thành phần sau lấy về.
Thành phần phân tích nâng cao nhằm tối ưu kết quả, giảm tải cho các chuyên gia an ninh mạng. Với các thông tin sự kiện được đưa ra Redis, nó sẽ xác nhận lại các sự kiện nào đã từng được biết là không phải tấn công để loại bỏ đi ở bước này. Đa phần dữ liệu có tính lặp, nên bước này sẽ loại bỏ được phần lớn sự kiện. Những sự kiện còn lại sẽ lại đẩy về cụm Kafka tập trung để thành phần khác lấy về xử lý. Thành phần giám sát cảnh báo nhằm đưa ra các thông tin trực quan về số liệu phân tích cũng như đưa ra các cảnh báo tùy theo mức độ nghiêm trọng. Nó sẽ đọc liên tục từ cụm Kafka tập trung nhằm lấy ra các sự kiện bất thường ngay lập tức. Dựa theo các bộ lọc và sắp xếp để hiển thị các sự kiện theo thứ tự lên màn hình
30 giám sát, đồng thời gửi cảnh báo đến các chuyên gia để ngay lập tức kiểm tra sự kiện đó.
Với việc giao tiếp và chia tách thành các thành phần như trên, chúng có thể được phát triển riêng rẽ về logic, mở rộng khả năng xử lý độc lập tùy theo nhu cầu mà không ảnh hưởng tới các thành phần khác. Nếu có một dịch vụ nào khác đáp ứng nhu cầu của 1 trong 4 thành phần kể trên mà còn hiện đại và nhiều tính năng cao cấp hơn thì ta hoàn toàn có thể thay thế nó dễ dàng mà không lo lắng về việc phá vỡ luồng xử lý. Cuối cùng, các thành phần này đều có nhiệm vụ và chức năng riêng biệt, các hệ thống khác khi cần đầu ra của các thành phần này cũng có thể dễ dàng lấy về, ứng dụng cho từng nghiệp vụ khác nhau.
3.2. Thành phần phát hiện thực thể bất thường
Ở thành phần này, dữ liệu ở thành phần trước sẽ làm đầu vào để phân tích ra các sự kiện bất thường. Các nguồn log dữ liệu khác nhau có các định dạng cấu trúc được xác định sẵn sẽ dùng làm đầu vào. Các kịch bản theo dõi sẽ được cấu hình ở đây bởi các chuyên gia hoặc một đội vận hành cho hệ thống. Người cấu hình sẽ cần biết kịch bản này sử dụng nguồn log nào, và dữ liệu đó có cấu trúc ra sao nhằm cấu hình lấy các trường dữ liệu cần thiết cho việc xây dựng các hồ sơ hành vi và các đối tượng thực thể.
Ta sẽ chia phân vùng xử lý log thành các dịch vụ Microservices như hình 3.2.
Microservices là cách tổ chức các thành phần thành các dịch vụ con theo nghiệp vụ khác nhau, nhằm linh hoạt cho việc nâng cấp, sửa đổi, thay thế và mở rộng cho sau này. Từ nguồn dữ liệu ở thành phần thu thập và tổng hợp dữ liệu, ta sẽ đẩy chúng lên cụm Kafka tập trung để phục vụ cho các nghiệp vụ xử lý cho từng các
31 tiến trình khác nhau. Sau đây, tôi sẽ đi vào chi tiết từng dịch vụ trong kiến trúc này.
3.2.1. Dịch vụ API Gateway
Đây là dịch vụ giao tiếp với người dùng hệ thống, nơi sẽ nhận các yêu cầu khởi tạo các kịch bản từ người dùng, xử lý yêu cầu và diễn giải yêu cầu thành các cấu hình đầu vào cho các dịch vụ khác. Từ đó, các dịch vụ khác sẽ khởi chạy một tiến trình con nhận xử lý theo cấu hình đầu vào. Do đó, ta sẽ phải tổ chức thiết kế cơ sở dữ liệu cho dịch vụ này lưu trữ các cấu hình đã được khởi tạo để giúp người dùng truy vấn và kiểm soát các kịch bản đang chạy dễ dàng hơn.
Trong hình 3.3 mô tả cơ sở dữ liệu quan hệ dùng trong hệ thống Microservice, các bảng được dùng để lưu các cấu hình cho các service, tuy nhiên các service vẫn được cần lấy thông tin lẫn nhau để phục vụ việc phân phối dữ liệu lẫn nhau, vì thế tôi lựa chọn sử dụng cơ sở dữ liệu quan hệ. Các bảng này là cơ sở dữ liệu riêng của API Gateway, qua đó API gateway sẽ đẩy các yêu cầu tạo các tiến trình con chạy riêng cho từng kịch bản cho các service khác.
32
Hình 3.3.Cơ sở dữ liệu quan hệ trong hệ thống
Dưới đây là danh sách các bảng và ý nghĩa của chúng:
Bảng 3.1.Bảng dữ liệu nguồn data_source
Bảng data_source: lưu trữ thông tin các nguồn lấy dữ liệu về id (PK) id của các nguồn lấy dữ liệu về
filter lọc các loại dữ liệu cần phân tích status ngắt/mở việc lấy dữ liệu về updated_at lưu thông tin lần cuối sửa đổi created_at lưu thông tin ngày tạo
schema lưu thông tin schema của dữ liệu connectionStr lưu thông tin kết nối tới nguồn dữ liệu
33
Bảng 3.2.Bảng hành vi entities_behavior
Bảng entities_behavior: lưu trữ thông tin các hành vi phân tích id (PK) id của hành vi cần phân tích
datasource_id id của nguồn dữ liệu
name tên của hành vi
updated_at lưu thông tin lần cuối sửa đổi created_at lưu thông tin ngày tạo
Bảng 3.3.Bảng loại hồ sơ thực thể profile_type
Bảng profile_type: lưu trữ thông tin các kiểu hồ sơ id (PK) id của loại hồ sơ
name tên của hồ sơ
output_type kiểu dữ liệu đầu ra
number_feature số lượng đặc trưng cho 1 thực thể object_type kiểu dữ liệu đầu vào
34
Bảng 3.4.Bảng đặc trưng cần trích chọn feature_extractor
Bảng feature_extractor: lưu trữ thông tin các phép bóc tách dữ liệu extractor_id (PK) id của loại trích chọn đặc trưng
behavior_id id của hành vi theo dõi
input trường dùng để trích chọn đặc trưng output trường thông tin sau khi được trích chọn extractor_type loại đặc trưng được trích chọn
Bảng 3.5.Bảng luật quyết định decision_rule
Bảng decision_rule: lưu trữ thông tin các luật phân tích rule_id (PK) id của luật quyết định
alert_id (PK) id của cảnh báo
behavior_id id của hành vi theo dõi filter các luật lọc hành vi
updated_at lưu thông tin lần cuối sửa đổi created_at lưu thông tin ngày tạo
35
Bảng 3.6.Bảng cảnh bảo alert
Bảng alert: lưu trữ thông tin việc gộp các cảnh báo theo từng use case alert_id (PK) id của cảnh báo
name tên cảnh báo
status ngắt/mở bắn cảnh báo
updated_at lưu thông tin lần cuối sửa đổi created_at lưu thông tin ngày tạo
chain_type loại kill chain
chain_config lưu thông tin cấu hình kill chain
3.2.2. Dịch vụ Profiling Engine
Kế đó, ta có những Dispatcher là thành phần sẽ đọc dữ liệu cần thiết từ Kafka ra cho những kịch bản cụ thể. Chúng chỉ đọc những dữ liệu mà được lựa chọn từ trước, có format cụ thể, được phân loại theo những bộ lọc nhất định đã khai báo trên cấu hình. Ở bước này chúng sẽ loại bỏ các dữ liệu không cần thiết, dữ liệu sai, dữ liệu không đọc được nhằm giảm khối lượng xử lý cho các tiến trình kế sau đó. Nếu dữ liệu đó được dùng bởi nhiều kịch bản thì chúng sẽ tạo bản sao cho dữ liệu và gửi đủ cho những tiến trình phụ trách xử lý kịch bản đó. Dispatcher là một mô đun trừu tượng, chúng có thể là mô đun tách rời hoặc là gắn liền với từng service làm đầu đọc dữ liệu từ Kafka và phân phối lại dữ liệu cho các tiến trình con khác nhằm đảm bảo khả năng gia tăng xử lý về sau.
Các tiến trình con sau khi được khởi tạo từ cấu hình nhận bởi API Gateway sẽ được các Dispatcher gửi dữ liệu tới và sẽ làm nhiệm vụ tạo ra các hồ sơ cho từng thực thể khác nhau. Các hồ sơ này gồm có thông tin thực thể, và đếm tần suất các giá trị dùng để xét độ bất thường gắn với thực thể được cấu hình. Như là hồ sơ cho các các thư mục chứa log, còn giá trị để xét là phần mở rộng cho các văn bản bên trong thư mục đó, thì thực thể ở đây là tên thư mục, ta sẽ đếm số lần cho từng phần mở rộng được tạo ra. Nếu như thư mục này hay tạo ra hàng trăm văn bản có đuôi là “.log” hay “.txt”, mà tự dưng xuất hiện 1,2 văn bản có đuôi “.bz” thì đây là
36 hành vi tạo văn bản bất thường. Thông tin các dữ liệu này cũng được lựa chọn lưu xuống MongoDB nhằm phục vụ cho việc truy vấn, phân tích cho các service khác. Tạo profile cho các thực thể trong hệ thống là kĩ thuật điển hình trong hầu hết các hệ thống UEBA, bằng cách lưu các trạng thái lịch sử của thực thể với các hành vi hoặc tương tác với các thực thể khác, ta có thể mô hình hóa được thực thể đó, qua đó có thể bắt được các hành vi khác thường của thực thể để đưa ra cảnh báo hoặc phân tích nguy cơ đối với hệ thống. Kỹ thuật này yêu cầu phải xác định trước những dạng hành vi cần lưu trữ lại, và với một hệ thống, số lượng thực thể thường là lớn, ta phải suy nghĩ cân nhắc về việc thiết kế lưu trữ, sử dụng và truy vấn để đảm bảo thời gian xử lý được tối ưu.
Trong phạm vi của hệ thống này, cách thức sử dụng của profile là thường xuyên, liên tục và ở tần suất cao. Để đáp ứng được nhu cầu đó, tôi đã sử dụng cấu trúc dữ liệu mảng băm (hashmap), nhằm đưa khả năng truy vấn với độ phức tạp là O(1). Cụ thể, với mỗi thực thể, tùy vào từng hành vi mà ta sẽ lưu lại các giá trị lịch sử của chúng. Như vậy, khi cần xét các hành vi của thực thể nào đó, ta chỉ việc lấy ra giá trị (value) lịch sử bằng cách truy xuất thực thể (key) đó. Các hành vi khác nhau, ta có các mảng băm khác nhau. Các mảng băm này phục vụ để đưa ra các quyết định xem thực thể này có bất thường hay không. Tuy nhiên việc thiết kế các mảng băm để sử dụng sao cho phù hợp lại cần phải tính toán cho hợp lý. Ví dụ như hành vi sửa đổi file, ta có người A tạo ra một file mới, người B xóa một file, ..v..v.. Với hành vi như này, ta phải lưu các giá trị như loại hành vi, tên file, .v..v.. Điều này thực sự khó khăn khi phải lưu trữ khối lượng lớn dữ liệu, cũng như khi truy vấn được dữ liệu đó, phải xử lý trên các trường thông tin cũng tốn kém chi phí và giảm thiểu hiệu năng xử lý của toàn hệ thống, khó mà đáp ứng các tiêu chí đồng