Skip to main content
Loading...

В стандартной установке уже содержится множество парсеров для распространенных источников. Но от версии к версии формат событий может варьироваться, а количество различных источников, подключаемых к SIEM - миллионы.

В RuSIEM коммерческой версии и в RvSIEM free имеются инструменты для нормализации и подключения любых источников событий.

Что такое нормализация

Нормализация - процесс подготовки данных, извлечение ключей и их значений. Нормализация необходима для обработки по уже написанным правилам корреляции наравне с другими событиями от других источников, корректного поиска по сохраненным данным, построения комплексных отчетов и последующей обработки с помощью Data Learning, Machine Learning и Artificial Intelligence, а также корректного сохранения в базу данных.

Расмотрим пример: в компании имеется два пограничных маршрутизатора Cisco и Palo Alto Networks. Формат событий от этих устройств различен.

Событие от Palo Alto Networks выглядит примерно так:

<14>Feb 11 01:27:43 EXT01.uk 1,2019/02/11 01:27:42,001801044435,TRAFFIC,start,1,2017/11/29 01:27:42,10.0.1.23,192.1.1.70,10.160.1.240,192.121.118.70,Rule ID 57,,,zabbix,vsys1,Trust,untrust-micex,ethernet1/1,ethernet1/12

а событие от Cisco:

<113>Feb 11 01:27:59 firepower SFIMS: Protocol: TCP, SrcIP: 10.0.1.23, OriginalClientIP: ::, DstIP: 192.1.1.70, SrcPort: 50795, DstPort: 443, TCPFlags: 0x0, IngressInterface: inside, EgressInterface: outside, DE: Primary Detection Engine (13d1ae3e-1d3b-11e8-bae3-88193dbc790d), Policy: Access Policy, ConnectType: Start, AccessControlRuleName: TeamViewer_Block_All

Форматы очень различаются. Можно обернуть все событие в поле message и так его и сохранить. Но если потребуется сделать выборку, к примеру, кто подключался к ip:192.1.1.70, или сделать правило корреляции "подключение к критичному ресурсу 192.1.1.70", независящее от источника (кто сообщит в своих логах) - то без нормализации столкнемся с проблемой. Делая выборки по отдельным источникам мы не увидим полной картины и работа с такими данными будет затруднена. Поэтому, на этапе нормализации значения извлекаются в поля согласно таксономии в конкретной SIEM системе. Например, src.ip:"10.0.1.23", dst.ip:"192.1.1.70". Количество извлекаемых полей зависит от кейсов работы с данными событиями и необходимости в данных извлеченных значениях.

Транспорты событий

Для сбора событий используются транспорты:

  • syslog (plain, CEF, LEEF, TLS, etc)
  • filelog (различные текстовые форматы)
  • msevt (сбор событий с любых журналов Windows, в том числе приложений и кастомных)
  • wmi
  • mssql (универсальный транспорт для сбора с таблиц и представлений)
  • mysql (универсальный транспорт)
  • oracle (универсальный транспорт)
  • cisco_sdee
  • checkpoint_lea
  • 1C v8.3
  • и другие

Новые транспорты могут быть добавлены с обновлением продукта.

Транспорты позволяют собрать события с источников и направить на дальнейшую обработку.

Процесс обработки событий

Прием событий осуществляется микросервисом lsinput. При старте, он подгружает конфигурационные файлы из файловой системы, находящиеся в директории /opt/rusiem/lsinput/etc/ с расширением .conf (системные) и с постфиксом _user.conf (пользовательские). Микросервис открывает порты на входящие соединения и принимает поток syslog и зашифрованный поток от агентов. Задача lsinput - принять поток и роутить его в соответствии с типами событий на нормализацию в frs_server.

За нормализацию отвечает микросервис frs_server. При старте, он подгружает конфигурационные файлы из БД postgreSQL, описывающие прохождение событий и их нормализацию. Отличие от более ранних версий в том, что ранее frs_server также брал конфигурационные файлы в файловой системе. Сейчас большая часть конфигурационных файлов содержится в postgresql.

По умолчанию, frs_server прогоняет событие по подходящим авто-парсерам. Авто-парсеры - набор конфигурационных файлов, содержащих паттерны и процедуры обработки событий в соответствии с источником. Если от одного источника (например, syslog) идут в одном потоке события от mysql, auditd, ids и прочих источников - авто-парсер разделит этот поток на отдельные и направит в соответствующие парсеры.

За обогащение симптомами и корреляцию отвечает микросервис lsfilter. После нормализации, события проходят по бинарному дереву симптоматики и отправляются на корреляцию (или, в случае RvSIEM free - в lselastic).

Lselastic - микросервис, отвечающий за взаимодействие с базой данных Elasticsearch. Он управляет потоком данных, отслеживает ошибки, определяет методы сохранения в БД.

Так как при обработке или записи в БД могут возникнуть проблемы (сбой микросервиса, нехватка ресурсов, перезагрузка) - в каждом микросервисе существует буфер для сохранения событий (mq - message queue) во избежание потерь событий. У каждого микросервиса он различный, но управляет общей очередью продюсер в lsinput. Если буфера в каких-то микросервисах переполняются - lsinput продолжает принимать входящие события, кеширует их на жесткий диск, но не пускает далее в микросервисы до восстановления работоспособности и снижения очереди.

Системные и пользовательские сущности

Имеются системные конфигурационные файлы и пользовательские. Изменения в системных конфигурационных файлах перезаписываются при обновлении. С помощью пользовательских возможно создание собственных парсеров и источников и переопределение системных парсеров.

Формат конфигурационных файлов

Формат конфигурационных файлов по синтаксису схож с logstash, но имеет значительные отличия и не совместим.

Каждый конфигурационный файл любого микросервиса (lsinput, frs_server, lsfilter, lselastic) имеет структуру, определяющую:

  1. откуда взять событие - input
  2. что с ним сделать (обработчики) - filter
  3. куда событие отправить далее - output

Секция filter может быть пустой для роутинга события по другим маршрутам.

Обработка по конфигурационному файлу производится последовательно. Изменения в конфигурационных файлах вступают в силу после перезапуска микросервиса.

Как добавить свой парсер

Как было сказано выше, формат парсеров прост, схож с logstash (но не совместим). Настройка парсеров производится в разделе Настройки -> Парсеры. В этом разделе можно посмотреть системные парсеры, создать свой собственный и протестировать его.

Протестировать можно как на реальном потоке (выбрав соответствующий транспорт), так и на семпле события.

 

Для того, чтобы парсер заработал после вашей проверки - необходимо на странице Парсеры поставить чекбокс "Автоматически загружать" и включить его в разделе Настройки -> Источники, определив параметры потока. После данных действий, ваши события будут доступны наряду с остальными.

Если формат событий не определен, нет доступных парсеров для источника, то они должны быть доступны по поиску type:"unparsed" и сохраняются в отдельные индексы базы данных.

Возможно удаленное управление и работа с парсерами и источниками. Равно как и для других разделов - можно выбрать необходимый удаленный сервер в правом верхнем углу и из этого же интерфейса сделать все необходимые операции на другой ноде.

 

Более подробные инструкции по парсерам, операторам, функциям доступны в "Руководстве по подключению источников".