Плейбуки в Kaspersky EDR Expert 8.1: Полное руководство

ℹ️ Информация: Приведенная на данной странице информация, является разработкой команды pre-sales и/или AntiAPT Community и НЕ является официальной рекомендацией вендора.

Плейбук (Playbook) в Kaspersky EDR Expert — это автоматизированный сценарий реагирования на инциденты информационной безопасности. Плейбук запускает алгоритм, включающий последовательность действий по реагированию, которые помогают анализировать и обрабатывать алерты или инциденты.

Зачем нужны плейбуки

Плейбуки решают три ключевые задачи SOC:

1. Скорость реагирования. Вместо того чтобы аналитик вручную собирал хеши, искал хосты и удалял файлы — плейбук делает это за секунды.
2. Стандартизация. Один и тот же тип инцидента обрабатывается одинаково, независимо от того, кто дежурит в смену.
3. Разгрузка аналитиков. Рутинные действия автоматизируются, и аналитик может сосредоточиться на расследовании.

Область применения

• Автоматическое реагирование на критические угрозы — ransomware, sandbox-детекты, компрометация учётных записей
• Первичная обработка алертов — сбор информации, обогащение данными TI
• Ручное реагирование — аналитик выбирает инцидент и запускает плейбук
• Расследование — сбор дампов памяти, образов дисков, ключей реестра

Дисклеймер

Эта статья основана на:

• Официальной справке Kaspersky EDR Expert 8.1
• Материалах KUMA Community (статьи «Триггеры в плейбуках» и «Действия в плейбуках»)
• Практическом опыте настройки плейбуков

Автор не является сотрудником «Лаборатории Касперского». Примеры и рекомендации носят характер best practices и могут требовать адаптации под конкретную инфраструктуру. Перед применением в продуктивной среде обязательно тестируйте плейбуки в режиме «Обучение».

Важно: Синтаксис jq-выражений, модель данных и имена полей могут меняться между версиями. Всегда проверяйте актуальную документацию для вашей версии.

Перечень возможностей плейбуков

Плейбуки в Kaspersky EDR Expert 8.1 предоставляют следующие возможности:

Основные возможности

Типы плейбуков

В системе существует два типа плейбуков:

Предустановленные плейбуки [KL]

Созданы специалистами "Лаборатории Касперского" и отмечены префиксом [KL] в названии.

Особенности:

• Нельзя изменять алгоритм (можно изменить только режим работы и триггер)
• Нельзя удалять
• Можно дублировать и настраивать копию
• По умолчанию работают в режиме Обучение
• Требуют предварительной настройки KUMA (обогащение событий)

Пользовательские плейбуки

Создаются и настраиваются администраторами SOC под конкретные задачи.

Обязательные параметры при создании:

1. Область действия (алерт или инцидент)
2. Триггер (условия автоматического запуска)
3. Алгоритм (последовательность действий)

Импорт/экспорт: Можно использовать XDR REST API для переноса плейбуков между тенантами.

Типы плейбуков и область действия

Критическое ограничение: Область действия

Плейбук может работать ТОЛЬКО с алертами ИЛИ инцидентами. Нельзя создать плейбук, который обрабатывает оба типа объектов.

Почему это важно:

• Если выбрали "Алерт" → в jq-выражениях используем alert.*
• Если выбрали "Инцидент" → в jq-выражениях используем incident.*
• Несоответствие приведёт к ошибке: "Expression does not match the selected scope"

Дочерние инциденты

Плейбуки НЕ могут запускаться автоматически для дочерних инцидентов!

Что это значит:

• Если у вас настроена сегментация и создаются дочерние инциденты
• Автоматические плейбуки сработают только для родительского инцидента
• Для дочерних инцидентов нужно запускать плейбук вручную
• Перед ручным запуском нужно выбрать активы и наблюдаемые объекты

Обходное решение:
Использовать сегментацию так, чтобы критичные инциденты не становились дочерними, или запускать плейбуки вручную через интерфейс.

Наследование тенантов

Плейбук принадлежит одному тенанту и автоматически наследуется всеми дочерними тенантами.

Особенности:

• Наследуются даже дочерние тенанты, добавленные после создания плейбука
• Можно отключить наследование при создании или изменении плейбука
• Дочерние тенанты могут дублировать и настраивать унаследованные плейбуки

Практический совет:
Если плейбук специфичен для конкретного тенанта (например, использует уникальные интеграции), сразу отключайте наследование, чтобы не засорять другие тенанты.

Архитектура и модель данных

Прежде чем писать триггеры и действия, нужно понять, как устроен плейбук внутри. Это критически важно — 90% ошибок при создании плейбуков связаны с неправильным пониманием контекста выполнения и модели данных.

Глобальные данные vs Операционные данные

В плейбуке есть два типа данных, и их нельзя путать:

Пример:

// Глобальные данные — имя инцидента
incident.Name

// Глобальные данные — хеши из наблюдаемых объектов инцидента
[incident.Alerts[].Observables[] | select(.Type == "sha256") | .Value]

// Операционные данные — то, что мы сохранили ранее через updateData
.input.hashes

Правило: Глобальные данные доступны на любом шаге, но их нельзя изменить. Операционные данные создаются и меняются шагами updateData.

Модель данных: Алерт vs Инцидент

Это фундаментальное различие, от которого зависит весь синтаксис плейбука.

Алерт (Alert)

Алерт — это одиночное событие или группа связанных событий, сгенерированных правилом корреляции. Структура:

alert
├── Name, Severity, Status, MITRE...
├── Assets[]              ← активы (хосты, пользователи)
├── Observables[]         ← наблюдаемые объекты (хеши, IP, URL)
├── BaseEvents[]          ← нормализованные события
├── OriginalEvents[]      ← исходные события
└── ScannedFiles[]        ← просканированные файлы

Инцидент (Incident)

Инцидент — это агрегация нескольких алертов, объединённых по расследованию. Структура вложенная:

incident
├── Name, Severity, Priority, Status...
└── Alerts[]              ← массив алертов
    ├── Assets[]          ← активы каждого алерта
    ├── Observables[]     ← наблюдаемые объекты каждого алерта
    ├── BaseEvents[]
    └── OriginalEvents[]

Критически важно: Чтобы получить активы из инцидента, нужно писать incident.Alerts[].Assets[], а не incident.Assets[] — такого поля не существует!

Контекст выполнения: Триггер vs Алгоритм

Это самая частая причина ошибок «Expression does not match the selected scope».

В ТРИГГЕРЕ плейбука

Триггер определяет, на какие алерты/инциденты срабатывает плейбук. Контекст — это сам алерт или инцидент, поэтому обращение идёт без префикса:

// ПРАВИЛЬНО для триггера на алерте
.Severity == "Critical"
.Name | contains("Ransomware")

// ПРАВИЛЬНО для триггера на инциденте
.Alerts[] | .Name | contains("Sandbox")
.Severity == "High"

// НЕПРАВИЛЬНО для триггера
incident.Alerts[] | ...   // префикс incident в триггере не нужен
alert.Severity            // префикс alert в триггере не нужен

В АЛГОРИТМЕ плейбука (executionFlow)

Алгоритм — это шаги, которые выполняются после срабатывания триггера. Здесь контекст другой, и нужно использовать полные пути:

// ПРАВИЛЬНО для алгоритма, работающего с инцидентом
incident.Alerts[].Assets[] | select(.Type == "host") | .ID

// ПРАВИЛЬНО для алгоритма, работающего с алертом
alert.Assets[] | select(.Type == "host") | .ID

// ПРАВИЛЬНО для доступа к операционным данным
.input.hashes
.input.hostIds

Визуальная шпаргалка

┌─────────────────────────────────────────────────┐
│           ПЛЕЙБУК (Playbook)                    │
├─────────────────────────────────────────────────┤
│  ТРИГГЕР                                        │
│  Контекст: сам алерт/инцидент                   │
│  Обращение: .Severity, .Name, .Alerts[]         │
├─────────────────────────────────────────────────┤
│  АЛГОРИТМ (executionFlow)                       │
│                                                 │
│  ┌───────────────────────────────────────┐     │
│  │ Глобальные данные (read-only)         │     │
│  │ alert.Assets[]                        │     │
│  │ incident.Alerts[].Observables[]       │     │
│  └───────────────────────────────────────┘     │
│                                                 │
│  ┌───────────────────────────────────────┐     │
│  │ Операционные данные (read/write)      │     │
│  │ .input.hashes                         │     │
│  │ .input.hostIds                        │     │
│  │ (обновляются через updateData)        │     │
│  └───────────────────────────────────────┘     │
│                                                 │
│  Шаги: action → decision → loop → parallel      │
└─────────────────────────────────────────────────┘

Чувствительность к регистру (КРИТИЧНО)

Kaspersky EDR Expert чрезвычайно чувствителен к регистру символов во всех jq-выражениях. Даже одна буква в неправильном регистре приведёт к ошибке выполнения плейбука.

Примеры ошибок из-за регистра

// ❌ ОШИБКА: Incident с заглавной буквы
Incident.Alerts[].Assets[]

// ✅ ПРАВИЛЬНО: incident строчными буквами
incident.Alerts[].Assets[]

// ❌ ОШИБКА: assets строчными буквами
alert.assets[]

// ✅ ПРАВИЛЬНО: Assets с заглавной буквы
alert.Assets[]

// ❌ ОШИБКА: type строчными буквами
select(.type == "host")

// ✅ ПРАВИЛЬНО: Type с заглавной буквы
select(.Type == "host")

// ❌ ОШИБКА: value строчными буквами
.Observables[].value

// ✅ ПРАВИЛЬНО: Value с заглавной буквы
.Observables[].Value

Таблица правильных написаний полей

Для Алертов (alert):

Для Инцидентов (incident):

ВАЖНО: Разный регистр для разных контекстов

Обратите внимание на критическое различие:

В глобальных данных (alert/incident):

// Заглавные буквы
alert.Assets[]
alert.Observables[]
select(.Type == "host")
.Value

В операционных данных (.input):

// Строчные буквы!
.input.assets[]
.input.observables[]
select(.type == "host")
.value

Практические рекомендации

1. Всегда копируйте имена полей из документации — не пишите по памяти
2. Используйте подсказки интерфейса — при вводе alert. или incident. система покажет список доступных полей с правильным регистром
3. Проверяйте регистр при возникновении ошибок — 80% ошибок связаны с неправильным регистром
4. Создайте шпаргалку с правильными написаниями полей для вашей команды

Получен алерт        │        ▼Получить HostID        │        ▼Получить информацию о пользователе        │        ▼Изолировать устройство        │        ▼Запустить IOC Scan        │        ▼Отправить уведомление