Исключения телеметрии Kaspersky EDR Expert (on-premise)
В статье рассматриваются способы ограничения сбора и отправки EDR‑телеметрии в Kaspersky EDR Expert 8 (в Open Single Management Platform) на уровне защищаемого устройства, сервера сбора телеметрии и консоли.
Дата исправления: 01.10.2026
1. Принцип обработки телеметрии
Телеметрия — поток событий, зарегистрированных на защищаемом устройстве: запуск процессов, операции с файлами и реестром, сетевые соединения, DNS‑запросы и др.
Ключевая особенность архитектуры: анализ телеметрии выполняется на защищаемом устройстве. EDR‑агент в составе Kaspersky Endpoint Security (KES) не только передаёт события, но и проверяет их в режиме реального времени по IOA‑правилам «Лаборатории Касперского». При соответствии события IOA‑правилу агент выполняет его разметку: добавляет поля IoAId, IoAName, IoAAlert, IoASeverity, IoAConfidence, IoATactics, IoATechniques (MITRE ATT&CK) и другие. На сервер сбора передаются уже размеченные события.
Обработка события включает следующие этапы:
1. Защищаемое устройство (KES): регистрация события → проверка по IOA‑правилам и разметка → применение исключений, заданных в политике → буферизация и отправка. По умолчанию синхронизация с сервером выполняется каждые 30 секунд или при накоплении в буфере 1024 событий.
2. Серверная часть KEDR (OSMP): преднастроенный коллектор [OOTB] Kaspersky EDR принимает и нормализует события. Далее события передаются в хранилище для поиска угроз и расследований и в коррелятор. Правило [OOTB] EDR IOA alert создаёт алерт на основании событий, поступивших с признаком сработавшего IOA‑правила и признаком алерта.
3. Консоль OSMP: алерты, инциденты, поиск угроз.
На устройствах с высокой активностью (прежде всего на серверах) объём телеметрии значителен. Избыточная телеметрия создаёт нагрузку на следующие компоненты:
- защищаемое устройство — ресурсы CPU, RAM и дисковой подсистемы, затрачиваемые на регистрацию, потоковую проверку и буферизацию событий;
- каналы связи — трафик синхронизации;
- серверы сбора телеметрии OSMP — приём, нормализация, хранение и корреляция событий.
Объём телеметрии и количество нерелевантных событий можно сократить на трёх уровнях:
1. Уровень защищаемого устройства — политика KES. На этом уровне определяется, какие события регистрируются и передаются, какие срабатывания IOA исключаются, а также задаются параметры передачи.
2. Уровень сервера сбора телеметрии — коллектор и коррелятор KEDR8, правила агрегации алертов. Отменить разметку, выполненную на устройстве, на этом уровне невозможно. На сервере определяется, какие события сохраняются, на основании каких размеченных событий создаются алерты и как алерты группируются.
3. Уровень отображения — фильтры в разделах «Алерты», «События», «Поиск угроз». Фильтрация влияет только на представление данных и не изменяет сбор.
Чем раньше в цепочке обработки исключается событие, тем больше экономия ресурсов:
| Уровень | Устройство | Канал связи | Хранилище и коррелятор | Количество алертов |
|---|---|---|---|---|
| 1. Устройство: исключения сбора, ограничения передачи | снижает нагрузку | снижает нагрузку | снижает нагрузку | может снижать |
| 1. Устройство: исключения IOA | — | частично | частично | снижает |
| 2. Сервер: коллектор (фильтрация, агрегация) | — | — | снижает нагрузку | может снижать |
| 2. Сервер: коррелятор, агрегация алертов | — | — | — | снижает (разметка и передача событий с устройства продолжаются) |
| 3. Отображение | — | — | — | не влияет (только скрывает) |
2. Уровень 1. Защищаемое устройство (политика KES)
2.1. Настройка передачи данных
В KSC Web Console, которая подключена к KSC, управляющему устройствами, или в OSMP, если она управляет устройствами: Управление активами → Политики → политика KES → Параметры приложения → Встроенные агенты → Endpoint Detection and Response Expert (on‑premises) → вариант Endpoint Detection and Response Expert (версия 8.0 и выше) → Настройка передачи данных:
| Параметр | Значение по умолчанию | Назначение и рекомендации |
|---|---|---|
| Отправлять телеметрию на серверы сбора телеметрии | Включено | Включает передачу телеметрии |
| Отправлять телеметрию только с IOA | Выключено | Передаются только размеченные события. Существенно сокращает объём телеметрии, но ограничивает данные для ретроспективного анализа (см. 2.1) |
| Максимальная задержка отправки событий (сек.) | 30 | Период синхронизации. Увеличение значения сглаживает пиковую нагрузку, но увеличивает задержку поступления событий |
| Максимальное количество пакетов событий | 1024 | Размер буфера, при заполнении которого выполняется отправка |
| Включить регулирование количества запросов | Включено | Ограничивает передачу событий при превышении установленных лимитов. Выключать не рекомендуется |
| Максимальное количество событий в час | 3000 | Для серверов справка рекомендует увеличить значение до 60 000 |
При отсутствии связи с сервером события помещаются в очередь и передаются после восстановления соединения. Для предотвращения перегрузки сервера KES может передать не все события из очереди.
Режим «Отправлять телеметрию только с IOA»
Индикатор атаки (Indicator of Attack, IOA) — правило, содержащее описание подозрительного поведения в системе, которое может являться признаком целевой атаки. Поскольку проверка по IOA‑правилам и разметка выполняются на устройстве, агент передаёт на сервер только размеченные события, если параметр включен. Остальные события на сервер не передаются.
- Преимущество: существенное сокращение объёма телеметрии и трафика. Алерты по IOA продолжают создаваться, поскольку необходимые для этого события передаются с разметкой.
- Ограничение: в разделе «Поиск угроз» и на графе расследования отсутствуют события, не связанные со срабатыванием IOA. Ретроспективный поиск угроз (threat hunting) по таким устройствам фактически невозможен.
2.2. Общие исключения из телеметрии
Правила исключения предназначены для решения двух различных задач:
- «Не собирать» — сокращение объёма телеметрии: событие не передаётся на сервер (например, сетевые соединения доверенного приложения);
- «Исключить IOA» — из телеметрии исключается событие о срабатывании IOA‑правила, алерт не создаётся. Подробнее см. 2.2.1.
В KSC Web Console, которая подключена к KSC, управляющему устройствами, или в OSMP, если она управляет устройствами: Управление активами → Политики → политика KES → Параметры приложения → Общие настройки → Настройки телеметрии → вкладка Телеметрия EDR Expert (on‑premises) → блок Общие исключения → Добавить:
Для создания правила выполните следующие действия:
1. Укажите статус правила (по умолчанию правило включено) и имя правила.
2. Выберите действие при срабатывании правила:
- Не собирать — событие исключается из отправляемой телеметрии;
- Исключить IOA — из телеметрии исключается событие о срабатывании IOA‑правила.
Укажите вариант Исключить все или Исключить по GUID (несколько GUID указываются через запятую).
3. Задайте условие фильтрации: поле события, оператор и значение.
4. При необходимости сформируйте группы условий с операторами И / ИЛИ / НЕ (вариант «Добавить НЕ перед»), в том числе вложенные. Условия первого уровня объединяются оператором И.
Операторы условий:
| Оператор | Событие отфильтровывается, если… |
|---|---|
<, ≤, =, ≥, >, ≠ |
значение поля удовлетворяет условию сравнения |
похоже / не похоже |
значение соответствует / не соответствует маске (*, ?) |
одно из / ни одного из |
значение совпадает / не совпадает с одним из значений списка |
похоже на одно из / не похоже ни на одно из |
значение соответствует / не соответствует одной из масок |
существует / не существует |
поле присутствует / отсутствует в событии |
содержит |
значение поля содержит значение, указанное в условии |
равно |
значения равны без учёта регистра |
И (побитовый) |
результат операции & над значением поля и значением условия равен 1 |
Для устройств под управлением OSMP доступна кнопка Проверить правило, которая отображает таблицу событий, отфильтрованных созданным правилом. Рекомендуется выполнять проверку перед применением каждого правила.
Важно. Использование слишком большого количества правил может привести к увеличению нагрузки на Сервер сбора телеметрии и снижению производительности. Рекомендуется объединять условия с помощью масок и списков вместо создания большого количества отдельных правил.
Важно. Правило с действием «Не собирать» распространяется и на размеченные события. Если событие, на которое сработало IOA‑правило, соответствует условию исключения, оно не будет передано на сервер и алерт создан не будет. Условия правил «Не собирать» рекомендуется формулировать максимально конкретно (процесс, путь, тип события).
2.2.1. Исключения IOA
Способ 1. Из карточки алерта (если устройства находятся под управлением OSMP)
- Перейдите в раздел Мониторинг → Алерты.
- Откройте алерт и в разделе Сводная информация нажмите на имя IOA‑правила.
- На панели IOA‑правил нажмите Добавить в исключения, выберите политику KES и нажмите Далее.
- Задайте свойства правила исключения (условия, при которых срабатывание считается штатным, например процесс и устройство) и нажмите Добавить.
Исключение сохраняется в выбранной политике KES и применяется на устройствах после синхронизации политики.
Способ 2. Вручную в политике (В KSC Web Console, которая подключена к KSC, управляющему устройствами, или в OSMP, если она управляет устройствами:)
Управление активами → Политики → политика KES → Параметры приложения → Общие настройки → Настройки телеметрии → вкладка Телеметрия EDR Expert (on‑premises) → блок Общие исключения → Добавить → выберите действие Исключить IOA, затем вариант Исключить по GUID (GUID IOA‑правила; несколько значений указываются через запятую) или Исключить все и задайте условия, при которых срабатывание считается штатным.
Важно. Не рекомендуется использовать вариант «Исключить все» без конкретных условий: в этом случае на всех устройствах в области действия политики перестанут создаваться алерты по IOA‑правилам.
Пример Добавления правила общего исключения на основе GUID IOA правила
GUID для правила исключения телеметрии:
Результат: чтение /etc/shadow агентом резервного копирования на app01 больше не создаёт алерт. Если /etc/shadow прочитает любой другой процесс или этот же агент на другом сервере, алерт будет создан, как раньше.
2.3. Исключения по типам событий
Блок Все типы событий на вкладке Телеметрия EDR Expert (on‑premises) позволяет настроить исключения для отдельных типов событий.
- Нажмите на название типа события и выберите Настроить вручную.
- Чтобы полностью исключить тип события, выключите переключатель Отправлять событие. По умолчанию отправка включена для всех типов событий.
- В блоке Правила исключения нажмите Добавить и задайте условия.
Пример: Исключение всех событий по типу
Результат: События с выбранным типом не будут отправляться на сервер сбора.
Пример: Исключение телеметрии по типу события с условиями
Результат: события Registry Query от агента Zabbix больше не отправляются на сервер. Registry Query от всех остальных процессов и все другие события агента Zabbix собираются как раньше, в том числе Registry Modify, Connection и Process.
Чем это отличается от общего исключения (Пункт 2.2): правило создаётся внутри карточки типа события, поэтому условие по типу (EventType = Registry Query) задавать не нужно. Правило действует только на этот тип событий.
2.4. Поддержка типов событий в Windows и Linux
Исключения имеют смысл только для типов событий, которые регистрируются на данной ОС.
Поддержка типов событий в соответствии с моделью данных событий EDR Expert:
| Тип события | Windows | Linux | Примечание |
|---|---|---|---|
| Process, Process Terminated | да | да | Используются для обнаружения, исключать не рекомендуется |
| File Create / Modify / Rename / Delete | да | да | |
| File Read | да | да | В Linux — только при поддержке eBPF. Один из наиболее объёмных типов событий |
| File Attributes Modify | да | да | |
| File Creation Time Modify, File Hardlink Created, File Symlink Created | да | — | |
| File Owner Change, File ACL Change | да | да | В Linux — при версии ядра 4.19 и выше |
| Module | да | да | |
| Registry Create / Delete / Modify / Rename / Query / Save | да | — | Registry Query и Registry Modify формируют значительный объём событий |
| Registry Owner Change, Registry ACL Change | да | — | |
| Connection, Port Listen | да | да | Connection — типовой кандидат на исключение для доверенных процессов |
| Connection Close | да | да | Согласно справке, включение события «может привести к значительному увеличению использования ресурсов» |
| DNS | да | да | В Linux — только для внешних сетевых соединений |
| Code Injection | да | да | Исключать не рекомендуется |
| Process Access | да | — | Исключать не рекомендуется |
| Process Console Input | да | да | |
| AMSI Scan, Driver, Process Interpreted File Run | да | — | |
| Pipe Create, Pipe Connect, LDAP | да | — | |
| WMI Activity, WMI Consumer Register | да | — | |
| Bits Job Create / Complete / Start / Stop / Add File / Error | да | — | |
| Service Create / Modify / Delete | да | да | Исключать не рекомендуется |
| Scheduled Task Create / Modify / Delete | да | да | Исключать не рекомендуется |
| Executable Memory Mapped | — | да | |
| Windows Event Log | да | — | |
| Linux Event Log | — | да | |
| Device | да | — | |
| File System Mount / Unmount | да | да | |
| Threat Detect, Threat Detect Processing Result, Blocked Document, Applock | да | да | Исключать не рекомендуется |
| Agent Start / Stop / Install / Uninstall / Action, System Startup / Shutdown | да | да | Служебные события, объём незначителен |
2.5. Источник телеметрии (только Linux)
В Kaspersky Endpoint Security для Linux можно выбрать механизм сбора телеметрии. В Kaspersky Endpoint Security для Windows данный параметр отсутствует.
В KSC Web Console, которая подключена к KSC, управляющему устройствами, или в OSMP, если она управляет устройствами: Управление активами → Политики → политика KES → Параметры приложения → Общие настройки → Настройки взаимодействия с ОС → блок Настройки телеметри:
| Параметр | Значения | Примечание |
|---|---|---|
| Источник телеметрии | По умолчанию (eBPF и служба auditd) / Использовать только eBPF | Вариант «Использовать только eBPF» снижает нагрузку на устройство, однако, телеметрия для решений Detection and Response может иметь ограничения |
| Режим использования auditd | Монопольный (по умолчанию) / Режим многоадресной рассылки | Применяется только при источнике телеметрии «По умолчанию». Режим многоадресной рассылки используется, если служба auditd требуется другим приложениям |
3. Уровень 2. Сервер сбора телеметрии (OSMP)
Настройки серверного уровня не зависят от ОС защищаемых устройств. Они применяются к событиям, которые уже поступили на сервер. Следует учитывать, что:
- настройки сервера не снижают нагрузку на устройство и канал связи;
- на сервере невозможно отменить срабатывание IOA‑правила. Создание алерта может быть подавлено, однако устройство продолжит размечать и передавать соответствующие события.
- на сервере определяется, какие события сохраняются, на основании каких размеченных событий создаются алерты и как алерты группируются. Кроме того, на сервере работают пользовательские правила корреляции; исключения в них являются исключениями серверного обнаружения.
3.1. Коллектор [OOTB] Kaspersky EDR
Коллектор принимает и нормализует события. Обработка выполняется в следующем порядке: нормализация → фильтрация → агрегация → маршрутизация в точки назначения [OOTB] Storage и [OOTB] Correlator. Фильтрация на коллекторе снижает нагрузку на хранилище и коррелятор, но не на устройство и канал связи, поскольку событие уже передано по сети.
Консоль OSMP: Мониторинг → Ресурсы и сервисы → Активные сервисы → [OOTB] Kaspersky EDR (или Ресурсы и сервисы → Коллекторы). Окно Редактирование коллектора содержит шаги: Подключение источников, Транспорт, Парсинг событий, Фильтрация событий, Агрегация событий, Обогащение событий, Маршрутизация, Проверка параметров.
Важно. К коллектору [OOTB] Kaspersky EDR подключены все агенты. Фильтры и правила агрегации рекомендуется создавать как отдельные ресурсы (флажок Сохранить фильтр). Изменения следует предварительно проверить на тестовом стенде.
Шаг Фильтрация событий:
- в поле Фильтр выбирается существующий фильтр или значение Создать;
- в блоке Параметры фильтра условия задаются в режиме Конструктор или Код; кнопки Добавить условие и Добавить группу формируют условия и группы условий;
- кнопка Добавить фильтр добавляет в коллектор ещё один фильтр; фильтры, добавленные в коллектор, объединяются оператором И;
- условие задаётся левым операндом, оператором и правым операндом; доступны параметры Если не и без учёта регистра;
- поддерживаемые операторы: =, <, <=, >, >=, inSubnet, contains, startsWith, endsWith, match (RE2), hasBit, inActiveList, inDictionary, inContextTable, inCategory, inActiveDirectoryGroup, intersect;
- поддерживаются группы условий И / ИЛИ / НЕ и вложенные фильтры.
Важно. Фильтр коллектора определяет события, которые передаются на дальнейшую обработку: в интерфейсе шаг сопровождается подписью «Отфильтруйте события, с которыми будете работать», а в описании ресурса «Фильтры» указано, что дальнейшей обработке подлежат события, удовлетворяющие условиям. Следовательно, для исключения событий условие необходимо формулировать через отрицание: Если не или группа НЕ (например, «НЕ (тип события = Connection И процесс = доверенный процесс)»).
Примечание. Все поля события KUMA имеют значения по умолчанию: 0 для числовых полей и пустая строка для строковых. Условие может сработать на событие, в котором соответствующее поле отсутствует. Например, условие DestinationPort <= 1024 выполняется для события без поля DestinationPort. Рекомендуется включать в условия проверку типа события.
Шаг: Агрегация событий объединяет однотипные события в одно агрегированное событие.
| Параметр | Значение по умолчанию | Назначение |
|---|---|---|
| Предел событий | 100 | Количество событий, необходимое для срабатывания правила |
| Время ожидания событий | 60 сек. | Интервал накопления событий |
| Группирующие поля | — | Поля, по которым события считаются однотипными |
| Уникальные поля | — | При наличии этих полей событие исключается из агрегации |
| Поля суммы | — | Поля, значения которых суммируются |
| Фильтр | — | Условия отбора событий для правила |
При агрегации детали отдельных событий, включая разметку, не сохраняются. Агрегацию рекомендуется применять только к неразмеченным событиям массовых типов с низкой ценностью для расследований (Connection, DNS, Port Listen доверенных процессов). Не рекомендуется агрегировать события Process, Code Injection, Process Access, Service *, Scheduled Task *.
Шаг Маршрутизация → точка назначения → «Дополнительные параметры» → Фильтр). Рекомендуется передавать в [OOTB] Correlator полный поток событий для корректного создания алертов, а для [OOTB] Storage исключать события, заведомо не требующиеся для расследований. События, не переданные в хранилище, недоступны в разделе «Поиск угроз», в событиях алерта и на графе расследования.
3.2. Коррелятор
Коррелятор не влияет на объём телеметрии, но определяет, для каких событий создаются алерты. Алерт создаётся в течение 30 секунд после формирования корреляционного события. Исключения в правилах коррелятора действуют только для падавления алерта в зависимости от вида правила:
| Правила | Назначение | Действие исключений |
|---|---|---|
[OOTB] EDR IOA alert, [OOTB] EDR IOA SB alert |
Создание алерта на основании события, поступившего с устройства с разметкой (сработавшее IOA‑правило с признаком алерта; результат проверки в Sandbox) | Только временное подавление алерта. IOA‑правило продолжает срабатывать на устройстве, события размечаются и передаются |
[OOTB] OSMP Scanner detects, [OOTB] KEDR event monitoring |
Создание алерта по событиям компонентов OSMP (проверки YARA, IOC, Sandbox, Anti‑Malware; мониторинг источников событий) | Подавление алерта по заданным результатам проверок |
Консоль OSMP: Мониторинг → Ресурсы и сервисы → Активные сервисы → [OOTB] OSMP Correlator → Корреляция → Правила корреляции.
Правило [OOTB] EDR IOA alert. Правило отслеживает события EDR, в которых есть алерт IOA»;
- Наследуемые поля: HostOsFamily, EventType, IoAName, IoATactics, IoATechniques, IoAAlert, IoAId, IoASeverity, IoAConfidence, HostId, HostName, DestinationAccountID, SourceAccountID, ProcessUserName, DeviceAssetID, IoAVersion. Поля IoA* — разметка, выполненная KES на устройстве;
- правило входит в пакет и недоступно для редактирования. Изменить селекторы правила и добавить в него постоянные условия исключения невозможно;
- окно правила содержит вкладки Общие, Селекторы, Действия, Сервисы и Исключения. На вкладке Исключения отображаются временные исключения, добавленные из алертов.
Пример
Временные исключения из алерта используются для оперативного устранения ложных срабатываний. Права на изменение правил корреляции для их создания не требуются.
1. В разделе Алерты откройте алерт и нажмите Найти в событиях.
2. Откройте корреляционное событие, нажмите кнопку‑стрелку напротив нужного поля, выберите Добавить в исключение и нажмите Создать.
Следует учитывать:
- срок действия исключения по умолчанию — 7 дней.
- в исключение можно добавить только поле, присутствующее в корреляционном событии, — для этого поле должно быть указано в списке Наследуемые поля правила. Для [OOTB] EDR IOA alert это поля IOA (IoAId, IoAName), устройства (HostName, HostId, DeviceAssetID) и учётных записей (ProcessUserName, SourceAccountID, DestinationAccountID). Поля процесса (путь, имя исполняемого файла, командная строка) в список не входят, поэтому исключение срабатывания IOA для конкретного процесса на сервере создать невозможно — оно настраивается на уровне устройства;
Для алертов по IOA‑правилам временное исключение рекомендуется использовать как временную меру на период настройки постоянного исключения IOA на уровне устройства.
3.3. Правила агрегации алертов
Консоль OSMP: Мониторинг → Ресурсы и сервисы → Правила агрегации.
Правила агрегации алертов объединяют повторяющиеся события в алерты OSMP и связывают алерты с существующими инцидентами либо формируют новые инциденты. Объём событий при этом не изменяется, сокращается количество отдельных алертов. Предустановленное правило объединяет события, для которых сработало одно и то же правило корреляции, в течение стандартного интервала агрегации (30 секунд). Приоритет правил определяется их порядком в таблице. Для управления правилами требуется одна из ролей: Главный администратор, Администратор тенанта, Администратор SOC.
4. Уровень 3. Отображение
Настройки уровня отображения не влияют на сбор и обработку телеметрии и используются для удобства работы аналитика. Настройки не зависят от ОС защищаемых устройств.
- Разделы «Алерты», «События», «Поиск угроз» (Мониторинг): фильтрация по критериям, SQL‑запросу и периоду.
- Сохранённые конфигурации фильтра событий — предустановленные наборы фильтров для быстрого переключения представления.
- Фильтр по тенанту — при использовании мультитенантности.