Введение
В текущих реалиях постоянно растущих киберугроз для ИТ-ландшафтов организаций очень важно иметь совокупною "картину" по событиям, происходящим внутри управляемой инфраструктуры.
И так как недавно я получил статус 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/ksc/15.1/ru-RU/176383.htm;
Wazuh - https://documentation.wazuh.com/current/quickstart.html;
Инструкции по установке дистрибутивов агентов и средств антивирусной защиты - можно найти по следующим ссылкам:
Агент администрирования 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->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, а то мало не покажется :*)