Не знаю как вам, а мне в продукте Alienvault OSSIM (USM) всегда не хватало гибкости в настройке правил корреляции. Т.е. возможность-то такая есть, и позиционируется решение как “комбайн” в составе которого есть и SIEM компонент. Но возможности данного SIEM в части корреляции на данный момент весьма и весьма ограничены. Искренне надеюсь, что в будущих релизах разработчики добавят хотя-бы какое-то подобие lookup/active списков ну и как минимум возможность корреляции не только по полям DST_IP, SRC_IP, DST_PORT, SRC_PORT.

А пока же пришла мне в голову идея использовать SEC (Simple Event Correlator) для расширения функционала корреляции событий ИБ в OSSIM/USM.

Архитектура решения приведена на рисунке ниже.



Краткое описание работы решения


SEC, развернутый на сервере OSSIM или на отдельно-стоящем сервере, получает копию логов из текстовых файлов, обрабатываемых PLUGIN’ами OSSIM (в FILE 5). На основе проведенного анализа, SEC генерирует события и алерты, которые записываются в файл (FILE 6). Данный файл читается специально разработанным PLUGIN’ом для OSSIM. Таким образом, события, сгенерированные SEC, можно будет видеть в консоли OSSIM, назначать им приоритеты, выполнять оповещение и т.д.

Конечно, в данном решении будет затруднен drill-down поиск событий, породивших алерты SEC. Для компенсации этого недостатка возможно в алерты, генерируемые SEC, включать копии оригинальных событий их (алерты) породивших.

Далее разберу небольшой пример.

Пример очень примитивный и создан только для демонстрации функционала. В дальнейшей разработке функционал, который будет помещать «сырые события», на основе которых сработало правило корреляции SEC, в поля userdataX системы OSSIM. Таким образом, открывая в интерфейсе OSSIM событие, представляющее собой инцидент, сгенерированный SEC, сразу можно будет видеть и исходные события, его повлекшие.

Пример


Разберем пример. Скажем, нам хочется регистрировать события модификации сигнатур suricata.

Триггером для данного алерта будут два события следующие друг за другом:

  • событие демона auditd, свидетельствующее о внесении изменений в файл /etc/suricata/suricata.yml;
  • событие из лога suricata о старте сервиса suricata.

Предположим, что auditd уже настроен необходимым образом, для регистрации событий изменения конфигурационного файла suricata.yml. Тогда, для решения данной задачи нужно:

  1. настроить перенаправление лога auditd и suricata в файл, который читает SEC, скажем /var/log/sec_input.log
  2. настроить правило SEC, генерирующее алерт при выполнении вышеописанного условия;
  3. создать плагин OSSIM, читающий файл, в который SEC пишет логи алертов, /var/log/sec_output.log.

Настройка перенаправления


Здесь все довольно тривиально. Для решения задачи я использую следующую конфигурацию

syslog-ng (/etc/syslog-ng/syslog-ng.conf):
source s_audit_file { file("/var/log/audit/audit.log"); };
source s_suricata_file { file("/var/log/suricata.log"); };
destination d_sec { file("/var/log/sec_input.log"); };
log { source(s_ audit_file); source(s_suricata_file); destination(d_sec); };

Соответственно, журнал аудита и логи сурикаты(только остановка и старт) направляются в файл /var/log/sec_input.log. Этот файл читает SEC.

Настройка SEC


Содержимое основного конфигурационного файла SEC (/etc/default/sec):

RUN_DAEMON="yes"
DAEMON_ARGS="-conf=/etc/sec.conf -input=/var/log/sec_input.log -pid=/var/run/sec.pid -detach -log=/var/log/sec_output.log"

В нем задается файл, который читает SEC (параметр input), файл, в котором содержатся правила корреляции (параметр conf), и файл, в который SEC пишет лог срабатываний и просто информационных сообщений (параметр log).

Файл с правилами SEC (/etc/sec.conf) выглядит следующим образом:

type=PairWithWindow
ptype=RegExp
pattern=syscall=5\s+success=yes.*key="suricata-file"
desc=Suricata config modified
action=logonly
ptype2=RegExp
pattern2=threads initialized, engine started
desc2=src_ip=NULL dst_ip=NULL user=NULL msg="Suricata restart initiated with new config file"
action2=logonly
window=600

В нем присутствует всего одно правило, которое коррелирует два события от источников, как показано на рисунке ниже:



Плагин OSSIM


Плагин OSSIM создается для обработки событий, генерируемых SEC. Для удобства их обработки они(события) должны иметь один формат.

Данный плагин разрабатывается как обычный плагин для чтения текстовых файлов, как описано, например здесь. Если Вы не занимались разработкой плагинов, то рекомендую бегло прочитать статью по ссылке, чтобы все описанное дальше имело для Вас смысл.

Формат событий SEC для описания в плагине для данного примера я взял «из головы». Можно сделать его любым, добавить или удалить поля.

Для чего нужен единый формат? Ведь можно для каждого нового типа события SEC дописывать regexp в конфигурационный файл плагина?

Да, можно. Однако я – сторонник унификации. При наличии единого формата, все, что будет нужно для добавления новых типов событий SEC – это добавить одну строчку описания в соответствующий sql файл. Добавление новых типов событий будет очень простым процессом.
Итак, формат выглядит следующим образом (без syslog заголовка, естественно):

event_name=<имя события> src_ip=<адрес> dst_ip=<адрес> user=<имя пользователя> msg=<собственно информационное сообщение>

Пример сообщения SEC:

Sun Sep  3 23:26:06 ossim_server: src_ip=NULL dst_ip=NULL user=NULL msg="Suricata restart initiated with new config file"

Конфигурационный файл плагина sec.conf выглядит следующим образом:

[DEFAULT]
plugin_id=9006
[config]
type=detector
enable=yes
source=log
location=/var/log/sec_output.log
create_file=false
process=
start=no
stop=no
restart=no
startup=
shutdown=
[translation]
suricata_conf_change=1
[0001 - Suricata Modified Config]
event_type=event
regexp="(?P<DATE>\w+\s+\w+\s+\d+\s+\d+\:\d+\:\d+)\s+(?P<HOST>\S+)\:\s+event_name=(?P<EVENT_NAME>\S+)\s+src_ip=(?P<SRC_IP>\S+)\s+dst_ip=(?P<DST_IP>\S+)\s+user=(?P<USER>\S+)\s+msg=(?P<MSG>.*)"
plugin_sid={translate($EVENT_NAME)}
device={$HOST}
username={$USER}
src_ip={$SRC_IP}
dst_ip={$DST_IP}
userdata1={$MSG}

Конфигурационный файл sec.sql:

DELETE FROM plugin WHERE id = "9006";
DELETE FROM plugin_sid where plugin_id = "9006";
INSERT IGNORE INTO plugin (id, type, name, description) VALUES (9006, 1, 'sec', 'Simple Event Correlator');
INSERT IGNORE INTO plugin_sid (plugin_id, sid, category_id, class_id, name) VALUES (9006, 1, NULL, NULL, 'SEC: Suricata Config Changed');

Импортируем файл .sql:

ossim-db < /usr/share/doc/ossim-mysql/contrib/plugins/sec.sql

Включаем плагин:



И наслаждаемся результатом:



И подробнее:

Комментарии (0)