CƠ SỞ LÝ THUYẾT
Tổng quan về Cyber Security Framework
Hiện nay, có nhiều khung bảo mật giúp phân tích và đánh giá khả năng bảo vệ hạ tầng CNTT của tổ chức trước các hành vi tấn công Trong số đó, các khung phổ biến nhất bao gồm Cyber Kill Chain, NIST Cyber Security và MITRE ATT&CK.
1.1.1 Cyber Kill Chain Framework Được phát triển bởi Lockheed Martin, Cyber Kill ChainFramework [3] là một phần của mô hình Intelligence Driven Defense, cho phép xác định và ngăn chặn các hành vi tấn công trên không gian mạng Trong mô hình sẽ tập trung xác định những gì mà kẻ tấn công (adversary/attacker) cần phải hoàn thành để đạt được mục đích của hắn Theo đó, mỗi cuộc tấn công sẽ gồm 7 giai đoạn sau:
Giai đoạn Mô tả chi tiết
Reconnaissance là giai đoạn quan trọng trong quy trình tấn công, nơi kẻ tấn công thu thập thông tin về mục tiêu Họ có thể sử dụng các công cụ như Google, Shodan và nhiều công cụ khác để thực hiện việc do thám này, nhằm tìm hiểu các điểm yếu và thông tin nhạy cảm của mục tiêu.
Kẻ tấn công sử dụng thông tin thu thập được từ các giai đoạn trước để thực hiện các cuộc tấn công, thường thông qua việc khai thác các lỗ hổng bảo mật Ví dụ, họ có thể áp dụng các công cụ như Metasploit và exploit-db để tối ưu hóa quy trình tấn công.
Kẻ tấn công thực hiện việc phát tán mã độc đến máy của nạn nhân và khai thác các lỗ hổng trong hệ thống mục tiêu, chẳng hạn như tấn công SQL Injection, Buffer Overflow và Remote Code Execution (RCE).
Installation Kẻ tấn công thực hiện leo thang đặc quyền để thực thi các
PowerShell, DLL độc hại, cài đặt các công cụ cho phép truy cập từ xa như RAT (Remote Access Tools)
Kẻ tấn công thiết lập các kết nối cho phép truy cập mục tiêu từ xa Actions on
Kẻ tấn công thực hiện mục tiêu đã đề ra như đánh cắp, phá hủy dữ liệu, tấn công từ chối dịch vụ, …
Cyber Kill Chain hiện vẫn là một trong những framework phổ biến được áp dụng trong nhiều tổ chức, bao gồm Bộ Quốc Phòng Mỹ và các đồng minh Mặc dù mô hình này mô tả đầy đủ các giai đoạn của một cuộc tấn công, nhưng nó còn thiếu các bước xử lý sau khi kẻ tấn công đã xâm nhập vào hệ thống Hơn nữa, các kỹ thuật phòng thủ trong Cyber Kill Chain chủ yếu dựa vào thiết bị phần cứng như tường lửa và hệ thống phát hiện xâm nhập, dẫn đến chi phí triển khai thường rất cao.
Hình 1.1 Sơ đồ các bước tấn công theo Cyber Kill Chain Framework [3]
Viện Tiêu chuẩn và Công nghệ Quốc gia Mỹ (NIST) là cơ quan trực thuộc
Bộ phận Quản trị Công nghệ của Bộ Thương mại Mỹ được thành lập để thúc đẩy đổi mới và cạnh tranh trong ngành công nghiệp Mỹ Nhiệm vụ của bộ phận này là cải tiến hệ thống đo lường, tiêu chuẩn và công nghệ, nhằm nâng cao nền kinh tế và cải thiện phúc lợi xã hội.
Hình 1.2 Sơ đồ các thành phần của NIST CyberSecurity Framework [17]
NIST CyberSecurity Framework là một bộ chính sách và quy trình được phát triển bởi các tổ chức an ninh mạng hàng đầu, nhằm tăng cường chiến lược an ninh mạng trong doanh nghiệp Hệ thống này cung cấp lý thuyết và hướng dẫn thực tiễn để giúp các tổ chức bảo vệ tài sản thông tin một cách hiệu quả.
Phiên bản 1.1 của NIST CyberSecurity, được nâng cấp từ phiên bản 1.0 phát hành vào tháng 02/2014, bao gồm 6 quy trình đã được kiểm chứng trong thực tế Mục tiêu của phiên bản này là cung cấp một số chức năng quan trọng nhằm nâng cao hiệu quả bảo mật thông tin.
Để nâng cao nhận thức về quản lý rủi ro an ninh mạng, các tổ chức cần tập trung vào việc đánh giá rủi ro đối với hệ thống, con người, tài sản và dữ liệu Việc nghiên cứu và áp dụng các chiến lược quản lý rủi ro như Đánh giá Rủi ro (Risk Assessment) và Chiến lược Quản lý Rủi ro (Risk Management Strategy) là rất quan trọng để bảo vệ tổ chức khỏi các mối đe dọa tiềm tàng.
Protecting critical services involves the development and implementation of robust security measures to ensure safety This includes essential aspects such as data security and information protection processes and procedures.
Để bảo vệ hệ thống mạng, việc xây dựng và triển khai giải pháp phát hiện các cuộc tấn công mạng là rất quan trọng Giải pháp này bao gồm việc phát hiện các sự kiện bất thường và các tiến trình lạ, giúp nhận diện sớm các mối đe dọa tiềm ẩn.
Để đảm bảo an ninh mạng hiệu quả, cần xây dựng và triển khai các hành động kịp thời khi phát hiện sự cố Một trong những bước quan trọng là thiết lập quy trình phối hợp và xử lý sự cố (Response Planning), giúp tổ chức ứng phó nhanh chóng và hiệu quả với các mối đe dọa.
Khôi phục hệ thống sau sự cố an ninh mạng là một quy trình quan trọng, bao gồm việc xây dựng và triển khai kế hoạch khôi phục hiệu quả Một ví dụ điển hình là lập kế hoạch khắc phục sự cố (Recovery Planning), giúp tổ chức nhanh chóng trở lại hoạt động bình thường và giảm thiểu thiệt hại.
NIST CyberSecurity Framework xác định đầy đủ các giai đoạn trong một cuộc tấn công, tạo cơ sở cho việc xây dựng chính sách an toàn thông tin cho tổ chức và doanh nghiệp Tuy nhiên, mô hình này không đề cập đến các kỹ thuật tấn công cụ thể, làm cho việc áp dụng để ngăn chặn tấn công trong thực tế trở nên khó khăn Do đó, nó thường chỉ phù hợp cho việc xây dựng các chính sách an toàn và an ninh thông tin cho tổ chức.
Giới thiệu về logs trên hệ điều hành Windows và Linux
Phần này sẽ trình bày về các loại logs mặc định trên hệ điều hành Windows và Linux, đồng thời giới thiệu một số cấu hình cần thiết để thiết lập Ngoài ra, chúng tôi cũng sẽ đề cập đến một số dịch vụ có thể cài đặt bổ sung để tạo ra các logs cần thiết, phục vụ cho quá trình giám sát hệ thống và điều tra, xử lý sự cố hiệu quả.
1.2.1 Nhật ký Windows Event Logs
1.2.1.1 Cấu trúc Windows Event Logs
Hệ thống nhật ký sự kiện trong Windows bao gồm hai loại chính: nhật ký hệ thống và nhật ký dịch vụ Người dùng và quản trị viên có thể truy cập hệ thống nhật ký này qua công cụ “Event Viewer” hoặc các câu lệnh tương tự Các loại nhật ký phổ biến trên Windows bao gồm nhật ký ứng dụng, nhật ký bảo mật và nhật ký hệ thống Ngoài ra, một số phiên bản Windows gần đây còn bổ sung nhật ký thiết lập và nhật ký chuyển tiếp sự kiện.
Thống nhật ký này sẽ ghi lại các sự kiện xảy ra trong quá trình hệ thống cung cấp dịch vụ cho người dùng, với thông tin chi tiết được trình bày trong bảng dưới đây.
Bảng 1.3 Bảng mô tả một số loại logs trên hệ điều hành Windows
Loại logs Mô tả chi tiết
Ứng dụng ghi lại các sự kiện phát sinh từ các chương trình đang hoạt động trên hệ thống, như lỗi xử lý tệp tin trong quá trình vận hành của hệ quản trị cơ sở dữ liệu.
Bảo mật hệ thống bao gồm việc ghi lại các sự kiện liên quan đến hoạt động bảo đảm an toàn, như các lần đăng nhập của người dùng và các hành vi sử dụng tài nguyên hệ thống như tạo, mở, hoặc xóa tệp tin Để tăng cường khả năng giám sát, người quản trị có thể kích hoạt tính năng kiểm toán (Audit) để ghi nhận thêm nhiều sự kiện vào các nhật ký (logs) này.
Thiết lập ghi lại các sự kiện liên quan đến việc cài đặt ứng dụng, bao gồm cả các lỗi phát sinh do thiếu thư viện Điều này hỗ trợ người quản trị trong việc kiểm soát quá trình cài đặt và cung cấp hướng xử lý hiệu quả khi gặp sự cố trong quá trình này.
Hệ thống ghi lại các sự kiện liên quan đến những thành phần quan trọng của hệ điều hành, bao gồm lỗi của các trình điều khiển và các sự cố phát sinh trong quá trình khởi động hệ thống.
Ghi lại các sự kiện nhận được từ các máy tính khác trong mạng
Trong hệ thống nhật ký sự kiện của Windows, bên cạnh Windows Logs, còn có nhật ký ứng dụng và dịch vụ (Applications and Service Logs) để lưu trữ các sự kiện từ ứng dụng và các thành phần quan trọng khác của hệ thống Chúng cho phép ghi lại các sự kiện như logs thực thi PowerShell và logs liên quan đến các tác vụ được lập lịch trên hệ thống.
Mặc định, tất cả các tệp nhật ký sự kiện trong Windows được lưu trữ tại C:\Windows\System32\winevt\Logs\ Mỗi tệp nhật ký có một kích thước tối đa, và khi đạt đến giới hạn này, các tùy chọn lưu trữ logs trên hệ thống sẽ bị ảnh hưởng.
- Overwrite events as needed (oldest events first): Cho phép tiếp tục ghi các sự kiện mới và xóa bỏ các sự kiện cũ khỏi hệ thống
Automatically archive the log when it is full to prevent overwriting events, allowing for the creation of a backup while continuing to record new entries in the log file.
- Do not overwrite events (Clear logs manually): Dừng việc ghi logs của hệ thống cho đến khi các sự kiện được xóa thủ công
Mỗi tệp nhật ký chứa nhiều sự kiện được lưu trữ dưới dạng XML, cho phép trích xuất thông tin qua Event Viewer hoặc truy vấn XPath Query bằng wevtutil Mỗi sự kiện có nhiều trường thông tin, bao gồm EventRecordID để xác định vị trí sự kiện, EventID để định danh giá trị lưu trữ, và TimeCreated để ghi nhận thời gian tạo sự kiện Lưu ý rằng giá trị của trường EventID có thể thay đổi tùy theo phiên bản hệ điều hành.
1.2.1.2 Cấu hình Audit trên Windows
Máy tính cài đặt hệ điều hành Windows tự động ghi lại thông tin cơ bản vào Windows Event Logs Để tăng cường khả năng giám sát an toàn và an ninh thông tin, Windows tích hợp dịch vụ kiểm toán (Audit) trong hệ điều hành Người dùng có thể tương tác với dịch vụ này qua giao diện đồ họa hoặc dòng lệnh bằng tiện ích auditpol và các câu lệnh PowerShell tương tự Sử dụng dòng lệnh giúp tự động hóa nhiều tác vụ, nhưng yêu cầu người dùng có kiến thức nhất định về hệ thống Windows để tránh lỗi trong quá trình thực hiện.
Hiện nay, các hệ điều hành Windows cung cấp hai loại chính sách kiểm toán chính là Chính sách Kiểm toán Bảo mật Cơ bản và Chính sách Kiểm toán Bảo mật Nâng cao Mặc dù cả hai đều cho phép ghi lại các logs cần thiết, nhưng Chính sách Nâng cao cho phép ghi lại nhiều thông tin hơn và phân loại thông tin chi tiết hơn.
Bảng 1.4 Bảng so sánh Basic Audit Policy và Advanced Audit Policy
Basic Security Audit Policy Advanced Security Audit Policy Đường dẫn cấu hình
Security Settings\Local Policies\Audit Policy
Security Settings\Advanced Audit Policy Configuration\System Audit Policies
+) Cung cấp 9 tiêu chí kiểm toán cơ bản
+) Cung cấp 10 tiêu chí kiểm toán và nhiều tùy chọn chi tiết hơn Phiên bản hệ điều hành hỗ trợ
Hỗ trợ tất cả phiên bản Windows, từ Windows 2000 trở lên
Chỉ hỗ trợ từ phiên bản Windows
Đối với máy tính Windows được quản lý bởi Domain Controller (DC), chúng ta có thể sử dụng chính sách nhóm GPO (Group Policy Object) để truyền tải cấu hình chính sách kiểm toán từ máy chủ DC đến các máy tính thành viên trong miền Trong trường hợp các máy chủ cục bộ hoạt động theo mô hình WORKGROUP, Local Group Policy Editor sẽ được sử dụng để thiết lập cấu hình chính sách kiểm toán Để biết thêm thông tin chi tiết về các chính sách và cách thiết lập cấu hình Audit trên hệ điều hành Windows, người dùng có thể tham khảo trang chủ của Microsoft.
Sysmon (System Monitor) is a system service and device driver for the Windows operating system Once installed, it enables comprehensive monitoring and logging of all system activities into the Windows Event Logs, specifically under the Applications and Services section.
Thu thập và chuẩn hóa logs về SIEM-Qradar
1.3.1 Giới thiệu Wincollect Agent Đối với các máy chủ Windows, ta có thể sử dụng Wincollect Agent [14] để thu thập logs về hệ thống SIEM-Qradar Về cơ bản, có 2 chế độ triển khai được
32 hỗ trợ là Wincollect Managed và Wincollect Standalone, trong đó mỗi mô hình đều có những ưu và nhược điểm riêng a) Triển khai Wincollect Managed
Trong mô hình này, cần cài đặt phần mềm Wincollect Agent trên mỗi máy chủ Windows để thu thập và gửi logs về hệ thống Qradar Theo khuyến cáo, mỗi Qradar Console có thể hỗ trợ tối đa khoảng 500 Wincollect Agent.
Hình 1.5 Chế độ Wincollect Managed thu thập logs trên máy chủ Windows
Một số tính năng chính khi triển khai thu thập logs trên các máy chủ Windows theo mô hình Wincollect Managed:
- Cho phép xây dựng Central Management trên Qradar Console
- Tự động tạo Log Source cục bộ tại thời điểm cài đặt
- Lưu trữ sự kiện (event) cục bộ, đảm bảo không có sự kiện nào bị mất
- Thu thập các sự kiện được chuyển tiếp từ Microsoft Subscriptions
- Cho phép thiết lập bộ lọc các sự kiện sử dụng Xpath Query hoặc tùy chọn exclusion filters
- Hỗ trợ cài đặt trên máy ảo
- Qradar Console có thể đẩy các bản cập nhật tới Wincollect Agent từ xa mà không cần truy cập trực tiếp vào máy chủ đó để cài đặt
- Cho phép lập lịch (Store and Forward) để chuyển tiếp các sự kiện b) Triển khai Wincollect Standalone
Khi cần thu thập logs từ hơn 500 máy chủ Windows, triển khai mô hình Wincollect Standalone là một giải pháp hợp lý Thay vì cài đặt phần mềm Wincollect Agent trên từng máy chủ, bạn chỉ cần thiết lập một máy chủ Windows làm trung gian (Log Collector) với Wincollect Standalone Máy chủ này sẽ thu thập logs từ cả chính nó và các máy chủ từ xa, sau đó chuyển tiếp dữ liệu về hệ thống.
Để tiết kiệm thời gian khi cấu hình số lượng lớn máy chủ trong hệ thống Qradar, người dùng có thể áp dụng các giải pháp hỗ trợ như IBM Endpoint Manager.
Hình 1.6 Chế độ Wincollect Standalone thu thập logs trên máy chủ Windows
Một số tính năng chính khi triển khai thu thập logs trên các máy chủ Windows theo mô hình Windows Standalone:
- Có thể cấu hình WincollectAgent bằng WinCollect Configuration Console
- Có thể cập nhật Wincollect thông qua Software Update Installer
- Lưu trữ sự kiện để đảm bảo không có sự kiện nào bị mất
- Thu thập các sự kiện được chuyển tiếp từ Microsoft Subscriptions
- Có thể thiết lập các bộ lọc sự kiện với Xpath Query hoặc exclusion filters
- Hỗ trợ cài đặt trên máy ảo
- Cho phép gửi sự kiện về Qradar sử dụng giao thức TLS Syslog
- Tự động tạo Log Source cục bộ tại thời điểm Agent được cài đặt
Bên dưới là sẽ so sánh và đánh giá tính năng khi triển khai 2 chế độ là Wincollect Managed và Wincollect Standalone
Bảng 1.11 Bảng so sánh Wincollect Managed và Wincollect Standalone
Cho phép tạo trung tâm quản lý từ Qradar Console Có Không
Khi cài đặt, hệ thống tự động tạo Log Source cục bộ để đảm bảo lưu trữ đầy đủ và không bỏ lỡ bất kỳ sự kiện nào Nó cũng thu thập các sự kiện được chuyển tiếp từ các nguồn khác, giúp quản lý và giám sát hiệu quả hơn.
Cho phép lọc các sự kiện sử dụng Xpath Query hoặc exclusion filters
Hỗ trợ cài đặt trên máy ảo Có Có
Qradar Console có thể gửi các bản cập nhật tới Có Không
Lập lịch để chuyển tiếp các sự kiện Có Không
Cấu hình mỗi Wincollect Agent sử dụng
Có thể cập nhật phần mềm Wincollect với
Tương thích với hệ thống Qradar triển khai trên nền tảng đám mây
Tương thích với hệ thống Qradar triển khai cục bộ Có Có
Mỗi chế độ triển khai hệ thống đều có những ưu và nhược điểm riêng Đối với các hệ thống vừa và nhỏ (dưới 500 máy), mô hình Wincollect Managed là lựa chọn tốt để quản lý cấu hình Wincollect Agent và thu thập logs hiệu quả, đặc biệt cho các máy chủ yêu cầu EPS cao như Domain Controller Trong khi đó, với các hệ thống lớn (trên 500 máy), mô hình Wincollect Standalone sẽ tối ưu hóa quy trình vận hành và hỗ trợ tốt hơn trong việc thu thập và quản lý logs cho các dịch vụ như DHCP, DNS, IIS, và Exchange Để kết nối Wincollect Agent với Qradar Console hoặc Event Collector, cần đảm bảo hệ thống mạng cho phép kết nối tới các cổng dịch vụ cần thiết.
Cổng 8413 được sử dụng để quản lý và cập nhật Wincollect Agent, với lưu lượng khởi tạo từ Wincollect Agent Dữ liệu được mã hóa qua kết nối TCP/IP bằng khóa công khai của Qradar Console và tệp cấu hình ConfigurationServer.PEM trên Agent.
- Cổng 514 sử dụng để Wincollect Agent chuyển tiếp các sự kiện về Qradar trên cả kết nối TCP hoặc UDP
Hình 1.7 Mô hình kết nối giữa Wincollect Agent và SIEM-Qradar
Để thu thập log từ xa trên máy chủ Windows qua cơ chế remote polling, Wincollect Agent sử dụng giao thức MSEVEN hoặc MSEVEN6 Cần kích hoạt cấu hình “Remote Logs Management” và cung cấp tài khoản có quyền Event Log Reader để đọc các tệp nhật ký Ngoài các logs mặc định, Wincollect hỗ trợ thu thập thêm các logs cần thiết như PowerShell và TaskSchedule, phục vụ cho giám sát an toàn thông tin qua các câu truy vấn XPath Query Thông tin chi tiết về cài đặt và cấu hình Wincollect có thể tham khảo trên website của hãng.
1.3.2 Thu thập logs trên máy chủ Linux
Trên các bản phân phối Linux như Ubuntu, CentOS, và RedHat, gói phần mềm rsyslog hoặc syslog-ng thường được tích hợp sẵn, cho phép gửi logs từ máy chủ đến các hệ thống quản lý logs tập trung như SIEM Mặc dù có cơ chế hoạt động khác nhau, cả hai đều dựa trên giao thức Syslog chung và được thiết kế theo cấu trúc mô-đun, giúp việc cài đặt và cấu hình trở nên dễ dàng.
SIEM-Qradar syslog-ng Port 514/TCP, UDP
Hình 1.8 Mô hình thu thập logs trên máy chủ Linux về hệ thống Qradar
Giao thức syslog, mặc định sử dụng cổng 514/UDP để gửi và nhận dữ liệu dưới dạng bản rõ, có thể được cải thiện với rsyslog và syslog-ng nhờ hỗ trợ giao thức TCP, giúp truyền tải thông tin một cách tin cậy và không bị mất gói tin Bên cạnh đó, việc cấu hình SSL/TLS trên kênh truyền TCP cho phép mã hóa các thông điệp, bảo vệ bí mật dữ liệu quan trọng và ngăn chặn việc nghe lén Để biết thêm chi tiết về giao thức và cách cấu hình, người dùng có thể tham khảo tài liệu của rsyslog hoặc syslog-ng.
Tổng quan về Rules trên SIEM-Qradar
1.4.1 Giới thiệu chuẩn sigma-rules Định dạng sigma-rules [13] là một chuẩn được phát triển dưới dạng nguồn mở, cho phép mô tả các dấu hiệu tấn công dựa trên logs một cách linh hoạt Mục đích chính của nó là cung cấp một cấu trúc chung, cho phép các nhà nghiên cứu hoặc nhà phân tích có thể mô tả các dấu hiệu tấn công mà họ phát hiện được và chia sẻ nó cho những người khác Từ định dạng sigma, ta có thể chuyển đổi nó thành các câu truy vấn trên nhiều nền tảng SIEM khác nhau một cách nhanh chóng
Về cơ bản, các rules được viết theo chuẩn sigma-rules sẽ có cấu trúc gồm các trường như bên dưới: title id [optional] related [optional]
- id {rule-id} status [optional] description [optional] author [optional] references [optional] logsource
{search-identifier} [optional] {string-list} [optional] {field: value} [optional]
timeframe [optional] condition fields [optional] falsepositives [optional] level [optional] tags [optional]
Thông tin chi tiết về các thành phần chính trong sigma-rules được mô tả trong bảng bên dưới [Bảng 1.12]
Bảng 1.12 Bảng đặc tả các thành phần chính trong sigma-rules
Thành phần Mô tả chi tiết title Tên thuộc tính: title
Nên đặt tên ngắn gọn, chứa nội dung chính của rules, độ dài tối đa khoảng 256 ký tự rule identification
Tên thuộc tính: id, related (không bắt buộc)
Mã UUID cho phép định danh và chia sẻ các quy tắc trên toàn cầu Để theo dõi mối liên hệ giữa các dấu hiệu, bạn có thể tham khảo trong trường liên quan, với giá trị loại có thể là: derived, obsoletes, merged hoặc renamed, cùng với trạng thái tương ứng.
Tên thuộc tính: status Cho biết trạng thái của rules Có thể có các giá trị sau:
- stable: cho biết rules hoạt động khá ổn định
- test: cho biết rules hoạt động ổn định, nhưng có thể cần tinh chỉnh thêm
- experimental: cho biết rules đang thử nghiệm, có thể dẫn tới kết quả sai hoặc gây noise khi áp dụng description
Mô tả ngắn gọn nội dung của rules, tối đa 65535 ký tự author
Tên thuộc tính: author Ghi lại thông tin người tạo rule reference
Tên thuộc tính: reference Tham chiếu các nguồn tài liệu tham khảo đã sử dụng logsource Tên thuộc tính: logsource
Mô tả dạng dữ liệu được áp dụng cho việc phát hiện Có thể gồm một số thành phần sau:
- category: mô tả logs sinh bởi một nhóm các sản phẩm cụ thể, ví dụ như firewall, web, antivirus
- product: mô tả loại log output, ví dụ như windows, sysmon, apache, v.v
- service: mô tả tập con của các log tương ứng với sản phẩm, ví dụ như sshd, applocker, v.v
- definition: mô tả nguồn nhật ký, gồm thông tin về mức
38 độ chi tiết của nhật ký hoặc các cấu hình cần áp dụng detection Tên thuộc tính: detection
Mô tả theo cấu trúc dạng lists hoặc maps cho phép tìm kiếm các dấu hiệu tấn công dựa trên log Điểm chung của chúng là:
- Tất cả đều được coi là chuỗi có phân biệt hoa thường
- Có thể sử dụng ký tự đại diện '*' hoặc "?" trong chuỗi
- Ký tự đại diện có thể cần chèn thêm "\", ví dụ "\*" Điểm khác biệt giữa cấu trúc lists và maps là:
- lists: chứa các chuỗi và được liên kết bởi dấu OR
Maps bao gồm các cặp khóa/giá trị, trong đó khóa là trường dữ liệu trong logs và giá trị có thể là chuỗi hoặc số Các giá trị trong map được kết nối với nhau bằng phép OR, trong khi các map được kết nối bằng phép AND Điều kiện được định nghĩa với cú pháp: Tên thuộc tính: condition.
Là thành phần liên kết các điều kiện, có thể thay đổi theo thời gian và các yêu cầu phát sinh Nó hỗ trợ các biểu thức:
- 1/all của search-identifier với 1 là một logic trong các lựa chọn, còn all là tất cả các lựa chọn
- 1/all of them: OR (1 of them) hoặc AND (1 of them)
The search-identifier-pattern "1/all of" functions similarly to "1 of them," but it is restricted to relevant search identifiers The wildcard character "*" can be used in appropriate positions within the pattern, such as in the example "1 of selection* and keywords."
- Phủ định với not, ví dụ keywords and not filters
- Dấu ngoặc: gộp các điều kiện ưu tiên VD: selection1 and (keywords_1 or keyword_2)
- Pipe: biểu thức đầu tiên phải là một biểu thức tìm kiếm, theo sau là một biểu thức tổng hợp với một điều kiện VD:search_expression | aggregation_expression
- Biểu thức tổng hợp: count, sum, min, max, agv, v.v
Tất cả các hàm tổng hợp, ngoại trừ hàm count, đều yêu cầu tham số là các trường dữ liệu Hàm count sẽ đếm tất cả các sự kiện phù hợp nếu không có tên trường nào được cung cấp.
39 sẽ đếm các giá trị riêng biệt trong trường này VD: count(UserName) by SourceWorkstation > 3 đếm tên người dùng riêng biệt nhóm theo SourceWorkstation special field values
Sử dụng để xét các trường hợp đặc biệt Các giá trị sẽ phụ thuộc vào hệ thống SIEM Một số giá trị có thể được sử dụng:
- Giá trị trống được xác định bằng ' '
- Giá trị null được xác định bằng null
- Giá trị tùy ý ngoại trừ null hoặc rỗng được xác định bằng not null fields
Tên thuộc tính: fields Danh sách các trường trong logs có thể dùng để phân tích thêm falsepositives
Tên thuộc tính: falsepositives Danh sách các trường hợp có thể trả về kết quả không đúng level
Mô tả mức độ ảnh hưởng, mức độ nguy hiểm của các hành vi được phát hiện trong rules Có một số mức sau:
- informational: Cung cấp thêm thông tin để phát hiện các hành vi tấn công
Các sự kiện low là những sự kiện đáng chú ý nhưng hiếm khi xảy ra, thường có liên quan đến các sự kiện khác Mặc dù không cần phải kiểm tra ngay lập tức, nhưng việc kiểm tra thường xuyên là cần thiết.
- medium: sự kiện cần được kiểm tra thường xuyên
- high: sự kiện có mức nguy hiểm cao
- critical: mức độ nghiêm trọng, cần kiểm tra ngay lập tức tag (optional) Tên thuộc tính: tags
Các quy tắc sigma có thể được phân loại bằng cách sử dụng một chuỗi ký tự viết thường, không có khoảng trắng, với dấu chấm làm ký tự phân tách, chẳng hạn như attack.t1234.
Ví dụ bên dưới cho phép phát hiện Web Shell dựa trên một số từ khóa thông qua logs của dịch vụ Sysmon
Hình 1.9 Ví dụ cú pháp của sigma-rules cho phép phát hiện Web Shell
1.4.2 Giới thiệu về Rules trên Qradar
1.4.2.1 Khái niệm Rules và Building Block
Tập luật là một bộ quy tắc do người quản trị thiết lập dựa trên các điều kiện cụ thể, nhằm phát hiện và tìm kiếm những điểm bất thường trong hệ thống Khi tất cả các điều kiện trong tập luật được đáp ứng, hệ thống sẽ thực hiện các hành vi đã được chỉ định trước, được gọi là phản hồi Trên hệ thống SIEM-Qradar, có hỗ trợ hai loại tập luật khác nhau.
- Custom Rules cho phép phân tích thông tin từ các sự kiện, luồng hoặc các offense để phát hiện những điểm bất thường bên trong mạng
Anomaly Detection Rules cho phép phân tích các luồng và sự kiện đã được lưu trữ trước đó để phát hiện bất thường trong mạng Các luật này yêu cầu phải có ít nhất một kết quả tìm kiếm đã lưu và sẽ được nhóm lại theo một tham số chung.
Trên SIEM-Qradar, người dùng có khả năng tạo, chỉnh sửa hoặc xóa cấu hình của các luật mặc định Hơn nữa, có thể tải xuống và cập nhật các luật mới từ kho dữ liệu IBM® Security App Exchange Bên cạnh khái niệm luật, Qradar còn tích hợp khái niệm Building Block (BB) để nâng cao tính linh hoạt và hiệu quả trong quản lý an ninh.
Mỗi BB có cấu trúc tương tự như một quy tắc, nhưng không bao gồm phần cấu hình phản ứng khi các điều kiện đã được thiết lập.
BB giúp đơn giản hóa việc cấu hình rule bằng cách nhóm lại các điều kiện phức tạp Khi cần cập nhật rule, người dùng chỉ cần thay đổi các BB tương ứng mà không phải chỉnh sửa từng điều kiện bên trong, từ đó nâng cao khả năng quản lý và cập nhật.
Trong hệ thống SIEM-Qradar, người dùng có thể tạo danh sách địa chỉ IP của các máy chủ trong mạng và viết quy tắc dựa trên danh sách này Khi địa chỉ IP của các máy chủ thay đổi, chỉ cần cập nhật danh sách mà không cần chỉnh sửa cấu hình quy tắc Hệ thống này bao gồm nhiều thành phần với các chức năng và nhiệm vụ khác nhau, giúp quản lý và giám sát an ninh mạng hiệu quả.
Thành phần Mô tả chức năng
Thực hiện thu thập các sự kiện từ các nguồn cục bộ hoặc từ xa sau đó chuẩn hóa và phân loại chúng theo low-level và high-level
Các luồng (flow) cho phép đọc gói tin và nhận dữ liệu từ các thiết bị khác, đồng thời chuyển đổi các dữ liệu mạng này thành các bản ghi luồng (flow records).
Xử lý các sự kiện hoặc các luồng dữ liệu nhận được từ Qradar Event Collectors
Thực hiện kiểm tra và liên kết các thông tin để tìm kiếm các hành vi nghi ngờ hoặc sự vi phạm các chính sách
Trong SIEM-Qradar, thành phần Custom Rules Engine (CRE) cho phép xử lý sự kiện và so sánh với các điều kiện đã thiết lập trong tập luật để phát hiện điểm bất thường Khi các điều kiện được thỏa mãn, CRE sẽ gọi Event Processor để thực hiện các hành động đã định trong Rule Response, như "gắn" sự kiện vào offense và cảnh báo trên giao diện hệ thống Mối quan hệ giữa rules và offense trong Qradar được mô tả rõ ràng trong bảng dưới đây.
Bảng 1.13 Bảng mô tả mối quan hệ giữa rules và offense trong Qradar
Thành phần Mô tả chức năng
CRE Thành phần CRE cho phép hiển thị thông tin về các rule và
