Нормализация событий
Для того, чтобы можно было осуществлять с данными событий различные манипуляции (сравнивать с помощью фильтров по заданными значениями, извлекать данные в директивах корреляции), необходимо их разобрать на составляющие поля, т.е. нормализовать.
Готовые модули
📄️ Модуль auditd-agent
📄️ Агрегация событий
Агрегация нескольких событий в одно с группировкой, оконными функциями и выводом полей
📄️ Модуль evtx
📄️ Модуль http-scraping
📄️ Модуль mirroring
Зеркалирование (пересылка) обработанных событий на внешние точки назначения
📄️ Модуль split
📄️ Модуль syslog
📄️ Условное выполнение (when)
Блок when для условного применения любого модуля процессора к событиям
📄️ Модуль xml
📄️ Модуль zeek
📄️ Динамические списки
Динамические списки: изменяемые наборы данных для обогащения и корреляции событий
📄️ Конвейер processors
Объединение модулей обработки в последовательный конвейер с помощью плагина processors
📄️ Условное выполнение (when) — справочник
Полный справочник условий when для модулей конвейера processors — equals, contains, regexp, compare, has-fields, or, and, not, cel
🗃️ Условная обработка (deny/if/assign)
1 элемент
🗃️ Обогащение данных
2 элемента
📄️ Процессор Anomaly
📄️ Модуль auditd - аудит Linux
Настройка модуля нативного сбора событий аудита Linux в Komrad Enterprise SIEM v4.5
📄️ Процессор Derive
📄️ Процессор Dissect
📄️ Модуль DNS
📄️ Процессор eBPF
📄️ Процессор ECS
📄️ Поля событий
Структура и описание полей событий KOMRAD
📄️ Извлечение данных из JSON документов
📄️ Нормализация событий с использованием GROK
📄️ Процессор JSON
📄️ Процессор извлечения направления трафика network_direction
📄️ Модуль для нормализации журналов nginx
📄️ Процессор Regex
📄️ Процессор Rename
📄️ Модуль reputation_list
📄️ Модуль sigma
📄️ Процессор SOV
📄️ Нормализация событий Suricata IDS/NSM
Работа с ненормализованными событиями
В случае, если мы получаем событие с коллектора, для которого не установлен модуль нормализации, либо под данный тип событий отсутствует подходящий модуль или регулярное выражение, то автоматически заполняются следующие поля внутренней структуры события KOMRAD:
-
CTime (Время создания) - время создания события, извлечённое из сырого текста события
-
GenerationTime (Время получения) - время получения события агентом/коллектором
-
WTime (Время записи) - время записи в хранилище
-
CollectorType (Тип источника) - тип агента или коллектора событий ИБ
-
Raw (Сырой текст) - исходный текст полученного события
-
CollectorID (ID источника) - уникальный идентификатор агента или коллектора событий ИБ
-
SetupID (ID инсталляции) - идентификатор инсталляции KOMRAD
-
TenantID (ID кластера) - ID кластера в мульти-кластерной инсталляции
-
SL (Метка безопасности) - метка безопасности для управления доступом к событиям ИБ
-
Producer (Место возникновения) - точка генерации события ИБ в KOMRAD - коллектор, коррелятор, Сканер-ВС
-
AggregationName (Метка агрегации) - метка агрегации событий ИБ
-
Count (Число агрегированных) - число агрегированных событий ИБ по метке агрегации
-
AssetIPs (IP активов) - IP связанных с событием активов
-
FwdIP (IP форвардера) - IP узла, с которого поступило событие в коллектор
-
FwdPort (Порт форвардера) - порт, который использовался узлом для направления события в коллектор
-
PluginIDs (ID модулей) - ID модулей, сработавших в нормализации события
Некоторые поля событий для коллекторов WMI и SQL (SQL.TaskName) генерируются только при получении события ИБ, для остальных коллекторов набор полей реализуется через Elastic Common Schema (ECS).
Также в KOMRAD реализована функция создания пользовательских полей событий.
Пользовательские поля
Расположение: manage ⇒ Настройка коллекторов ⇒ Поля событий ⇒ Пользовательские
Действия:
- Создать пользовательские поля, нажав на «Добавить»
- Задать уникальное название поля события в стиле
PascalCase, название поля для отображения, описание - Задать тип данных поля из выпадающего списка. Типы данных полей и их описание представлены в следующей таблице
- Сохранить
Таблица 1 - Типы данных полей
| Тип поля | Описание |
|---|---|
| string | представляет строковый тип данных |
| int | представляет целое число со знаком, которое в зависимости о платформы может соответствовать либо int32, либо int64 |
| int32 | представляет целое число от -2 147 483 648 до 2 147 483 647 |
| int64 | представляет целое число от –9 223 372 036 854 775 808 до 9 223 372 036 854 775 807 |
| int_slice | представляет неограниченный int |
| uint8 | представляет целое число от 0 до 255 |
| uint16 | представляет целое число от 0 до 65 535 |
| uint32 | представляет целое число от 0 до 4 294 967 295 |
| uint64 | представляет целое число от 0 до 18 446 744 073 709 551 615 |
| uint64_slice | представляет неограниченный uint64 |
| float32 | представляет число с плавающей точкой от 1.410^-45^ до 3.410^38^ (для положительных) |
| float64 | представляет число с плавающей точкой от 4.910^-324^ до 1.810^308^ (для положительных) |
| bytes | синоним типа uint8, представляет целое число от 0 до 255 |
| time | представляет временной тип данных |
| bool | логический тип, имеет одно из двух значений: true (истина) или false (ложь) |
| ip | IPv4 или IPv6 |
| ip_slice | представляет неограниченный IP |
| string_slice | представляет неограниченный string |
Поля со значением 0 не разбираются
Вы не сможете удалить пользовательское поле, которое использовалось в модуле, после удаления этого модуля
Работа с событиями в формате CEF
Если источник событий передает события в формате CEF (Common Event Format), то поля событий будут автоматически нормализованы KOMRAD.
Разработка модулей
Модули включают в себя регулярные выражения для разбора событий. Поля, извлекаемые из событий, могут быть добавлены в существующую стандартную структуру события, это осуществляется с помощью настройки маппинга с предварительным добавлением пользовательских полей.
Модули можно создавать самостоятельно и устанавливать разработанные вендором или третьей стороной.
Для разработки собственных модулей необходимо иметь сведения о структуре событий, отправляемых источником, примеры сообщений и знания по применению регулярных выражений для извлечения данных.
При создании модуля в карточке редактирования необходимо выбрать тип коллектора в поле "Коллектор".
Синтаксис модуля разбора JSON
Пример события:
{
"source": "zeek-stdout",
"sensor_id": "cec1da6b-b075-4556-a2b2-001c4fcb7b5c",
"message": {
"_path": "weird",
"_write_ts": 1611835445.742201,
"ts": 1611835445.742201,
"uid": "CD9l8s23k0bYTZK0fc",
"id.orig_h": "10.0.5.70",
"id.orig_p": 37842,
"id.resp_h": "10.0.5.152",
"id.resp_p": 10050,
"name": "active_connection_reuse",
"notice": false,
"peer": "zeek"
}
}
Расположение: manage ⇒ Настройка коллекторов
Действия:
-
Перейдите на вкладку «Модули» и создайте модуль, нажав на кнопку
Добавить -
Задайте уникальное имя модуля и нажмите кнопку
Сохранить -
В форму регулярное выражение вставьте конструкцию формата:
json:source;; AND sensor_id;; AND message.name;; AND message.id\.resp_hРазделителями между json-полями служит конструкция:
;; ANDДля выделения json-поля, которое входит в состав другого поля (в нашем примере это поле
name, которое находится внутри поляmessage), необходимо использоватьполе1.поле2/конструкцию. -
Введите описание
Для нормализации по полю, содержащему точку в названии, необходимо использовать экранирующий символ
\, как показано в примере. -
Нажмите
Проверить выражение и заполнить поля. В результате извлечённые поля будут следующие:Name: active_connection_reuseRespH: 10.0.5.152SensorId: cec1da6b-b075-4556-a2b2-001c4fcb7b5cSource: zeek-stdout -
Выберите соответствия для полей нормализации и нажмите
Сохранить
Универсальная нормализация всего события JSON
В системе KOMRAD присутствует возможность автоматического разбора приходящих событий. Это может быть необходимо в тех случаях, когда исходные данные приходят уже в формате JSON, например.
При создании модуля введите в поле "Регулярное выражение":
json:all
Далее укажите пример исходного события. В качестве примера:
{"resourceType": "Patient", "id": "example", "status": "generated", "use": "usual", "code": "MR", "system": "urn:oid:1.2.36.146.595.217.0.1","value": "12345", "start": "2001-05-06", "display":"Acme Healthcare"}
В поле "Описание" напишите примеры использования вашего правила и любые дополнительные заметки.
Теперь нажмите кнопку Проверить выражение и заполнить поля.
В столбце "Извлечённые поля" отобразятся полученные результаты. На картинке ниже можно увидеть, как прошёл разбор для указанного примера.

Эвристический анализ шаблона
Данный вид анализ применяется для определения структуры текста события.
В графу "Регулярное выражение" напишите выражение для извлечения структурированной информации из исходного текста записи лога. Используйте встроенные модули разбора: json, jsonschema, regex, grok. По умолчанию используется модуль разбора regex RE2, выбрать другой модуль разбора можно префиксом <имя_парсера>:
Для извлечения сразу нескольких полей используйте разделитель - ;; AND.
Примеры: json: .Hostname;; AND .Domain;; AND .fqdn или regex:.*.
Далее в поле «Пример исходного события» необходимо вставить сообщение с примером исходного события.
В поле "Описание" напишите примеры использования вашего правила и любые дополнительные заметки.
Нажмите кнопку Эвристический анализ паттерна.
Добавьте поля маппинга, сопоставив поле в регулярном выражении с соответствующим созданным пользовательским полем нормализации и нажмите на кнопку Сохранить.
Синтаксис регулярных выражений
Регулярные выражения являются формальным языком поиска и осуществления манипуляций с подстроками в тексте, основанным на использовании метасимволов.
Для поиска используется строка-образец (англ. pattern, по-русски её часто называют «шаблоном», «маской»), состоящая из символов и метасимволов и задающая правило поиска.
Для манипуляций с текстом дополнительно задаётся строка замены, которая также может содержать в себе специальные символы. Используются следующие метасимволы:
^— начало строки$— конец строки.— любой символ*— любое количество предыдущих символов+— 1 или более предыдущих символов?— 0 или 1 предыдущих символов( )— группировка конструкций|— логический оператор «ИЛИ»[ ]— любой из перечисленных внутри скобок символов, диапазон. Если первый символ в этой конструкции^, то массив работает наоборот – проверяемый символ не должен совпадать с тем, что перечислено в скобках{ }— повторение символа несколько раз\— экранирование служебных символов
Также существуют специальные метасимволы, которыми можно заменить некоторые готовые конструкции:
\b— обозначает не символ, а границу между символами\d— цифровой символ\D— нецифровой символ\s— пробел\S— символ, не пробел\w— буквенный или цифровой символ, или знак подчеркивания\W— любой символ, кроме буквенного или цифрового символа, или знака подчеркивания
Применение регулярных выражений и создание модуля
Предварительные условия:
- известен формат событий, которые отправляет источник по
Syslog. Как пример возьмем следующие события:
criticality: high: message: device is switching off
criticality: low: message: device configuration was updated
- для имитации отправки данных сообщений источником можно воспользоваться командой
nc:
echo -n "criticality: high: message: device is switching off" | nc -u IP_адрес_узла_коллектора 49050
Расположение: manage ⇒ Настройка коллекторов.
Действия:
-
На основе анализа событий принимается решение создать два пользовательских поля нормализации:
CriticalityиMessage. Для этого во вкладке «Поля событий» перейдите на вкладку «Пользовательские» и добавьте два поля, определив тип представления данных какstring -
Перейдите на вкладку «Модули» и создайте модуль, нажав на кнопку
Добавить -
Задайте уникальное имя модуля и нажмите кнопку
Сохранить -
Добавьте регулярное выражение и его краткое описание, которое будет разбирать события, при этом помечая значения поля критичности и сообщения
CriticalityFieldиMessageField, соответственно:^\w*\:\s(?P<CriticalityField>\w*)\:\s\w*\:\s(?P<MessageField>.*)$ -
Вставьте пример сообщения в форму «Пример сырого текста события», нажмите на кнопку
Проверить выражение и заполнить поля -
Добавьте поля маппинга, сопоставив поле в регулярном выражении с соответствующим созданным пользовательским полем нормализации и нажмите на кнопку
Сохранить -
Перейдите на вкладку «Коллекторы», выберите тип коллектора, с помощью которого осуществляется сбор событий (в примере используется Syslog-коллектор)
-
В левой панели выберите вкладку «Модули» и включите созданный модуль
-
Осуществите поиск событий от данного источника и убедитесь, что в карточке события в разделе «Пользовательские поля» появились значения полей
CriticalityиMessage
Дополнительно
- Модуль не будет разбивать события на поля нормализации, которые поступают на данный коллектор до его перезагрузки
- В связи с тем, что один модуль может иметь неограниченное количество регулярных выражений, необходимо при создании задавать описание.
Модули коллектора позволяют динамически конфигурировать модуль очистки и нормализации событий в коллекторах SIEM.
Модули извлекают значения полей в соответствии с набором заданных правил. В каждом правиле можно опционально указать правила приведения имён полей, также называемый "сопоставление полей". Рекомендуется приводить названия полей к стандартной схеме события ECS.
Типы модулей:
- regex
- json
- processors
Модуль json
Модуль json извлекает значения полей документа в формате json с помощью синтаксис GJSON
Пример модуля
Исходный текст:
{"timestamp":"2018-10-03T16:45:34.481113+0000","flow_id":116307482565223,"in_iface":"enp0s3","event_type":"alert","src_ip":"192.168.1.146","src_port":32876,"dest_ip":"93.184.216.34","dest_port":80,"proto":"TCP","tx_id":0,"alert":{"action":"allowed","gid":1,"signature_id":2013028,"rev":4,"signature":"ET POLICY curl User-Agent Outbound","category":"Attempted Information Leak","severity":2},"http":{"hostname":"example.org","url":"\/","http_user_agent":"curl\/7.58.0","http_content_type":"text\/html","http_method":"GET","protocol":"HTTP\/1.1","status":200,"length":1121},"app_proto":"http","flow":{"pkts_toserver":4,"pkts_toclient":3,"bytes_toserver":347,"bytes_toclient":1654,"start":"2018-10-03T16:45:34.252519+0000"}}
Модуль:
json:flow_id;; AND src_port
Извлекает в событие поля:
| Имя поля | Значение |
|---|---|
| FlowId | 116307482565223 |
| SrcPort | 32876 |
Модуль processors
Модуль processors содержит набор конфигурируемых процессоров события. Процессоры события можно конфигурировать, располагать в любой последовательности применения.
Доступные процессоры:
- Auditd
- Агент Auditd
- Split - разделить текстовую строку
- EVTX - разбор XML Журнала Windows
- XML
- Разбор Syslog
- Нормализация событий Suricata IDS/NSM
- Zeek
- Процессор извлечения направления трафика network_direction
- Модуль reputation list
- Модуль для нормализации журналов nginx
- Модуль DNS
- Условная обработка: deny, if, assign
- Справочник CEL-функций
- Grok
- Sigma
- JSON
- Regex
- Dissect
- Rename
- ECS
- eBPF (Tracee)
- Enrich - обогащение событий
- Derive - порождение событий
- Aggregation - агрегация событий
- Mirroring - зеркалирование событий
- Условное выполнение модулей (when)
- Anomaly - ML-детекция аномалий
- SOV - URL для PCAP Suricata