Введение

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

И так как недавно я получил статус Kaspersky Certified Systems Engineer - пришло время рассмотреть на практике один из примеров расширения возможностей мониторинга безопасности управляемых серверов.

Цель

При реализации интеграции средства управления антивирусной защиты (в нашем случае Kaspersky Security Center, далее KSC) с SIEM системой - мы, как ИБ аналитики/инженеры, можем получить следующее:

Централизованный анализ событий средств антивирусной защиты в SIEM (не будет необходимости мониторинга нескольких консолей одновременно);

Возможность использования в корреляционных правилах событий средств антивирусной защиты, что расширит покрытие возможных сценариев атак;

Возможность активного реагирования агентов SIEM при помощи средств антивирусной защиты (зависит от вендора SIEM);

Варианты реализации

В текущей статье мы будем рассматривать вариант интеграции KSC с Open-Source SIEM-системой Wazuh.

Если говорить про пересылку событий из KSC в SIEM-системы - то он поддерживает несколько вариантов реализации, а именно:

Экспорт общих/специфических событий приложений ЛК с управляемых устройств по протоколу syslog (поддерживается большинством SIEM-систем);
Экспорт общих событий приложений ЛК с управляемых устройств по протоколам CEF и LEEF (CEF для ArcSight / Splunk; LEEF для QRadar);
Чтение событий напрямую из публичных представлений базы данных сервера администрирования (v_akpub_ev_event);

Хоть последний вариант является наиболее функциональным, т.к. мы можем влиять напрямую на логику сбора событий из базы данных и их конечное содержание - его использование куда более трудное, т.к. он требует написания отдельных программ и решений для своей реализации (если вы, конечно, не гордый обладатель KUMA). Поэтому в статье мы будем рассматривать пример экспорта событий через протокол syslog.

Пререквизиты тестового стенда

Для более наглядной демонстрации возможностей интеграции мною был поднят тестовый стенд, со следующими характеристиками виртуальных машин:

Имя ВМ	IP-адрес	Назначение	Наличие KES	Наличие Wazuh Agent
test-ksc	172.16.0.20	KSC	-	-
test-wazuh	172.16.0.21	Wazuh	-	-
test-windows	172.16.0.30	Тестовая ВМ Windows	+	+
test-linux	172.16.0.31	Тестовая ВМ Linux	+	+

На ВМ test-ksc и test-wazuh были предварительно установлены KSC и Wazuh соответственно в All-in-One конфигурации, для простоты демонстрации (для передачи событий в формате syslog будет использоваться порт 514/tcp);

На сервер test-wazuh, дополнительно, будет установлен пакет net-tools для удобства диагностики работоспособности сетевых сервисов.

На ВМ test-windows и test-linux, в свою очередь, были установлены агенты администрирования KSC, дистрибутивы KESW 12.8 и KESL 12.2, а так же агент Wazuh (v4.11.2).

Инструкции по установке KSC и Wazuh по аналогии с данной средой можно найти по следующим ссылкам:

Инструкции по установке дистрибутивов агентов и средств антивирусной защиты - можно найти по следующим ссылкам:

Агент администрирования KSC: https://support.kaspersky.com/KSCLinux/15.1/ru-RU/92444.htm ;
KESW 12.8 - https://support.kaspersky.com/help/KESWin/12.8/ru-RU/50360.htm ;
KESL 12.2 - https://support.kaspersky.com/KES4Linux/12.2.0/ru-RU/263902.htm

Подготовка KSC

1) Необходимо выбрать то, какие события будут пересылаться в Wazuh.

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

Для этого зайдём в веб-консоль сервера администрирования (по стандартному адресу) https://172.16.0.20:8080 в раздел 'Assets (Devices) / Policies & profiles' и заходим в нужные политики в раздел 'Event configuration'.

Далее из необходимых категорий событий выбираем те, которые хотим экспортировать через syslog.

Для этого выбираем нужные события (или все, в зависимости от ваших потребностей) и нажимаем 'Mark for export to SIEM system by using Syslog':

После этого выбранные события будут помечены на экспорт:

В случае, если вы хотите экспортировать события приложения ЛК с конкретного управляемого устройства - необходимо выполнить аналогичные действия, но в свойствах данного приложения на устройстве (Assets (Devices) / Managed devices -> Выбираем нужное устройство -> Applications -> Выбираем нужное приложение ЛК -> Event configuration).

На тестовом стенде будут выбраны следующие общие события для экспорта в SIEM:

Приложение	Категория события	Тип события
KESW 12.8	Critical	Malicious object detected
KESL 12.2	Critical	Threat detected

2) Необходимо настроить параметры подключения к SIEM-системе на стороне сервера администрирования.

Для этого необходимо зайти в параметры экспорта событий через настройки KSC, а именно в разделе General -> Export to SIEM:

Приводим настройки в соответствие с настройками тестового стенда:

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

Подготовка SIEM

1) Настроим приём событий через протокол syslog.

Для этого, в рамках тестового стенда, подключаемся к 172.16.0.21 по протоколу ssh.

Далее от имени учётной записи root открываем файл конфигурации OSSEC (/var/ossec/etc/ossec.conf):

sudo nano /var/ossec/etc/ossec.conf

После этого, для дальнейшего удобства сопровождения конфигурации, вставим блок с конфигурацией syslog сразу после блока конфигурации агента:

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>tcp</protocol>
  <allowed-ips>172.16.0.20/32</allowed-ips>
  <local_ip>0.0.0.0</local_ip>
</remote>

*в поле local_ip можно использовать ip-адрес выделенного интерфейса для приёмки событий по syslog, а не 0.0.0.0;
*В поле protocol - можно использовать транспорт udp, а не tcp, для обеспечения большего быстродействия системы;
*В поле allowed-ips указываем
*Для дальнейшей диагностики в рамках глобальных правил OSSEC была включена функция logall, для записи всех поступающих событий в /var/ossec/logs/archives/archives.log.

Т.к. в нашем случае интерфейс у сервера Wazuh всего один - было принято решение запустить прослушивание сервиса на всех интерфейсах, для простоты конфигурации стенда.

После внесения изменений в конфигурацию - сохраняем файл, и последовательно выполняем следующие команды для её применения и диагностики результата:

sudo systemctl restart wazuh-manager
sudo systemctl status wazuh-manager
netstat -aon | grep :514

В случае, если служба удачно запустилась после рестарта (статус active), и на интерфейсе 0.0.0.0 начал слушаться порт 514/tcp - изменения успешно применены.

На этом этапе можно проверить работоспособность тестового стенда в плане отправки syslog-сообщений с KSC в Wazuh.

Для этого необходимо:

Зайти в веб-консоль MMC, в параметры экспорта событий в SIEM;
Нажать на кнопку 'Check connection'.

После чего в журнале /var/ossec/logs/archives/archives.log должна появится соответствующая запись с тестовым syslog-сообщением:

2025 Apr 29 20:15:04 test-wazuh-&gt;172.16.0.20 1 2025-04-29T20:15:04.476Z  | - TEST_SIEM_CONNECTION [event@23668 et="TEST_SIEM_CONNECTION" etdn="Test Siem Connection"]

Аналогично в веб-интерфейсе будет отображено оповещение об удачном соединении, в случае если выбран транспорт tcp:

В случае если вы увидели сообщение и/или оповещение об удачном соединении - то первая часть (конфигурация KSC и Wazuh) уже удачно пройдена.

2) Создадим правила декодирования и корреляции (decoder'ы и ruleset'ы) для включенных в экспорт событий приложений ЛК.

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

Моделируем ситуацию, при котором будет вызвано событие, для которого мы хотим сформировать декодер и правила корреляции;
Анализируем полученное сырое событие на стороне Wazuh, по результату составляя регулярное выражение для его 'матчинга';
Формируем декодер на основе сформированного регулярного выражения, тестируя его встроенными инструментами Wazuh.

Разберём данную методологию на основе события Malicious object detected.

Для этого на сервере test-windows и test-linux - запустим тестовый файл EICAR.

В случае с linux - через текстовый редактор nano необходимо создать файл eicar.com со следующим содержанием:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

Запуск данного файла гарантированно вызовет событие Malicious object detected, что мы можем подтвердить, посмотрев локальные отчёты в графическом интерфейсе KESW 12.8 (Вкладка Reports -> File Threat Protection) и просмотрев журнал KESL 12.2 через команду:

kesl-control -E --query "EventType == 'ThreatDetected'"

И т.к. до этого мы сконфигурировали отправку данного типа событий в SIEM - уже на стороне Wazuh мы сможем увидеть данное событие в журнале /var/ossec/logs/archives/archives.log, вызвав команду ниже:

cat /var/ossec/logs/archives/archives.log | grep 172.16.0.20

В моём случае сырое событие Malicious object detected выглядит следующим образом для test-windows:

2025 Apr 30 09:07:21 test-wazuh->172.16.0.20 1 2025-04-30T09:06:49.000Z test-windows KES|11.0.0.0 - GNRL_EV_VIRUS_FOUND [event@23668 p1="275A021BBFB6489E54D471899F7DB9D1663FC695EC2FE2A2C4538AABF651FD0F" p2="C:\\Users\\Administrator\\AppData\\Local\\Temp\\2\\c5e74b1f-d5e5-4a61-a8dc-fed3f6ed329c_eicar_com.zip.29c\\eicar.com" p5="EICAR-Test-File" p7="SEC-TEST-WINDOW\\Administrator" p8="60" p9="{\"engine\":1,\"method\":3,\"blacklist\":false,\"cloud_sb\":false,\"md5\":\"44D88612FEA8A8F36DE82E1278ABB02F\"}" et="GNRL_EV_VIRUS_FOUND" tdn="File Threat Protection" etdn="Malicious object detected" hdn="TEST-WINDOWS" hip="172.16.0.30" gn="Managed devices" engine="1" method="3" kscfqdn="test-ksc"] Event type: Malicious object detected\r\nName: smartscreen.exe\r\nApplication path: C:\Windows\System32\r\nProcess ID: 3956\r\nResult description: Detected\r\nType: Virus\r\nName: EICAR-Test-File\r\nUser: TEST-WINDOW\Administrator (Initiator)\r\nObject: C:\Users\Administrator\AppData\Local\Temp\2\c5e74b1f-d5e5-4a61-a8dc-fed3f6ed329c_eicar_com.zip.29c\eicar.com\r\nReason: Expert analysis\r\nDatabase release date: 4/29/2025 11:24:00 PM\r\nSHA256: 275A021BBFB6489E54D471899F7DB9D1663FC695EC2FE2A2C4538AABF651FD0F\r\nMD5: 44D88612FEA8A8F36DE82E1278ABB02F

И следующим для test-linux:

2025 Apr 30 09:30:26 test-wazuh->172.16.0.20 1 2025-04-30T09:30:21.000Z test-linux kesl|12.2.0.0 - GNRL_EV_VIRUS_FOUND [event@23668 p1="131f95c51cc819465fa1797f6ccacf9d494aaaff46fa3eac73ae63ffbdfd8267" p2="/home/test/eicar.com" p5="EICAR-Test-File" p8="60" p9="{\"engine\":1,\"method\":5}" et="GNRL_EV_VIRUS_FOUND" tdn="File_Threat_Protection" etdn="Threat detected" hdn="TEST-LINUX" hip="172.16.0.31" gn="Managed devices" engine="1" method="5" kscfqdn="test-ksc"] Initiator: Product; Task type: OAS; ID of running task: 5; User receiving access: test; Object type: File; File owner: test; Detection certainty: Sure; File: /home/test/eicar.com; Detected object name: EICAR-Test-File; Detected object type: Virware; MD5 hash: 69630e4574ec6798239b091cda43dca0; SHA256 hash: 131f95c51cc819465fa1797f6ccacf9d494aaaff46fa3eac73ae63ffbdfd8267; Unique ID: de7372b6cbf6a6ddb8903341a708b8db630a106c15b7d3a1e5fc5b25ec14d61b;

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

Далее если взять весь оставшийся синтаксис, выделив из него минимально полезную для нас информацию - можно сформировать следующий декодер:

<decoder name="kes_evt_virus_found">
  <prematch>\d \d\d\d\d-\d\d-\d\dT\d\d:\d\d:\d\d.000Z \w+ \w+| \. -</prematch>
  <regex type="pcre2">1 (\d\d\d\d-\d\d-\d\dT\d\d:\d\d:\d\d.000Z).+(GNRL_EV_VIRUS_FOUND).+etdn="(.+)" hdn="(.+)" hip="(\d+.\d+.\d+.\d+)"</regex>
  <order>evt_timestamp, evt_type, evt_etdn, evt_hdn, evt_hip</order>
</decoder>

Его необходимо поместить в файл /var/ossec/etc/decoders/local_decoder.xml.
В случае внедрения данных интеграций в продуктивных средах - рекомендую создавать отдельные xml-конфигурации в папке /var/ossec/etc/decoders/.

Далее на его основе можно создать правило корреляции (ruleset), в аналогичном файле /var/ossec/etc/rules/local_rules.xml:

<group name="kes,virus,">
  <rule id="101001" level="12">
    <decoded_as>kes_evt_virus_found</decoded_as>
	  <description>Kaspersky Virus Found: timestamp=$(evt_timestamp), description=$(evt_etdn), hostname=$(evt_hdn), hostip=$(evt_hip)
      </description>
  </rule>
</group>

Ровно как и для декодеров, в случае внедрения wazuh-интеграций в продуктивных средах - рекомендую создавать отдельные xml-конфигурации в папке /var/ossec/etc/rules/.

После внесения изменений - не забудьте перезапустить службу wazuh-manager:

sudo systemctl restart wazuh-manager

Проверка работоспособности

Для проверки работоспособности декодеров и правил - рекомендую использовать cli-утилиту /var/ossec/bin/wazuh-logtest c опцией -d (debug).

Ей на вход можно подавать сырые события, которые вы можете взять выше из статьи (отбросив служебные заголовки wazuh)

Успешным результатом тестирования логов будет следующий вывод в cli (например для test-linux):

**Phase 1: Completed pre-decoding.
		full event: '1 2025-04-30T09:30:21.000Z test-linux kesl|12.2.0.0 - GNRL_EV_VIRUS_FOUND [event@23668 p1="131f95c51cc819465fa1797f6ccacf9d494aaaff46fa3eac73ae63ffbdfd8267" p2="/home/test/eicar.com" p5="EICAR-Test-File" p8="60" p9="{\"engine\":1,\"method\":5}" et="GNRL_EV_VIRUS_FOUND" tdn="File_Threat_Protection" etdn="Threat detected" hdn="TEST-LINUX" hip="172.16.0.31" gn="Managed devices" engine="1" method="5" kscfqdn="test-ksc"] Initiator: Product; Task type: OAS; ID of running task: 5; User receiving access: test; Object type: File; File owner: test; Detection certainty: Sure; File: /home/test/eicar.com; Detected object name: EICAR-Test-File; Detected object type: Virware; MD5 hash: 69630e4574ec6798239b091cda43dca0; SHA256 hash: 131f95c51cc819465fa1797f6ccacf9d494aaaff46fa3eac73ae63ffbdfd8267; Unique ID: de7372b6cbf6a6ddb8903341a708b8db630a106c15b7d3a1e5fc5b25ec14d61b;'
		
**Phase 2: Completed decoding.
        name: 'kes_evt_virus_found'
        evt_etdn: 'Threat detected'
        evt_hdn: 'TEST-LINUX'
        evt_hip: '172.16.0.31'
        evt_timestamp: '2025-04-30T09:30:21.000Z'
        evt_type: 'GNRL_EV_VIRUS_FOUND'

**Phase 3: Completed filtering (rules).
        id: '101001'
        level: '12'
        description: 'Kaspersky Virus Found: timestamp=2025-04-30T09:30:21.000Z, description=Threat detected, hostname=TEST-LINUX, hostip=172.16.0.31'
        groups: '['kes', 'virus']'
        firedtimes: '1'
        mail: 'True'
**Alert to be generated.

Аналогично в веб-интерфейсе wazuh https://172.16.0.31, при попытке запустить тестовый файл EICAR - будет возникать алерт (пример для ВМ test-linux):

Вывод

Настраивая подобного рода интеграции - мы значительно повышаем видимость событий информационной безопасности, что, в перспективе, заложит основу для киберустойчивости организации;
Особенно если данные интеграции сопровождаются возможностью активного реагирования на инциденты (да, в wazuh есть active-response модуль), но про это можно написать отдельную достаточно познавательную статью.

Желаю всем сил на предстоящие майские праздники, не бойтесь тестировать интересные инструменты и подходы для обеспечения безопасности организации;
Временами это даже бывает полезно!

P.S. Не забывайте после тестов отключать logall в ossec, а то мало не покажется :*)

Интеграция KSC с SIEM на практике