Pull to refresh

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

Level of difficultyMedium
Reading time10 min
Views567

Введение

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

И так как недавно я получил статус 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

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

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

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

Те самые политики
Те самые политики
Те самые события
Те самые события
Те самые события x2
Те самые события x2
Те самые события x3
Те самые события x3

Далее из необходимых категорий событий выбираем те, которые хотим экспортировать через 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:

Заветное Connected
Заветное Connected

В случае если вы увидели сообщение и/или оповещение об удачном соединении - то первая часть (конфигурация 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, а то мало не покажется :*)

Only registered users can participate in poll. Log in, please.
Применяете ли вы кросс-интеграцию ИБ-решений в среде Организации или своей деятельности?
100% Да1
0% Нет0
1 user voted. Nobody abstained.
Tags:
Hubs:
0
Comments0

Articles