"Если посмотреть на три классических уровня реагирования (Tier) глазами регулятора, модель выглядит не как пирамида, где Tier-1 — основа, а как матрешка. Внешний, видимый слой, это документация, процессы и отчеты для ФСТЭК, которые должен обеспечить Tier-3. Внутри — реальная работа инженеров (Tier-2 и Tier-1), и чем дальше внутрь, тем меньше формализма и больше автоматизации. Стандартный провал — пытаться натянуть все playbooks на одну гребенку. Playbook для оператора первой линии и сценарий для эксперта по расследованию, это принципиально разные документы, и смешивать их — гарантировать провал в момент реального инцидента."

Минимальный набор playbooks для Tier-1/Tier-2/Tier-3

Зачем разделять playbooks по уровням

Три уровня (Tier) в SOC, это не просто линейное расширение полномочий, а смена парадигмы работы. Tier-1 работает по регламенту, Tier-2 — по методике, Tier-3 — по стратегии. Playbook, который пытается охватить все три уровня, превращается в нечитаемый документ, бесполезный для оперативного реагирования.

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

Во-вторых, разный контекст и ответственность. Задача Tier-1 — максимально быстро и без ошибок классифицировать событие по известным шаблонам (True Positive, False Positive, Escalate). Его playbook, это алгоритм. Tier-2 расследует инцидент, его playbook, это набор методик и тактик. Tier-3 управляет последствиями и взаимодействует с регулятором, его playbook, это перечень контрольных точек и требований к отчетности.

Tier-1: Алгоритмизация рутины

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

Структура playbook Tier-1:

• Триггер: Конкретное событие из SIEM/SOAR (например, "Сработало правило ‘Множественные неудачные попытки входа в AD с одного хоста’").
• Цель: Однозначный ожидаемый результат ("Подтвердить атаку подбора учетных данных и заблокировать источник").
• Шаги: Последовательность проверок и действий с точными командами и ссылками.
  • Шаг 1: Проверить в SIEM-консоли детали события: IP-адрес источника, целевая учетная запись, количество попыток.
  • Шаг 2: Сверить IP-адрес источника со списком доверенных/внутренних подсетей (ссылка на список).
  • Шаг 3: Если IP внешний и не в белом списке, выполнить в консоли управления файрволлом команду: [КОД: Добавление правила блокировки по IP на межсетевом экране].
  • Шаг 4: Проверить, не является ли целевая учетная запись сервисной или тестовой (ссылка на реестр). Если нет — отправить автоматический шаблон уведомления владельцу УЗ через тикет-систему.
• Решение (Decision Tree): Простое дерево решений с вариантами:
  • Источник в белом списке → Пометить как False Positive, закрыть инцидент.
  • Источник внешний, атака подтверждена → Выполнить шаги 3 и 4, перевести инцидент в статус "Обработан".
  • Поведение нестандартное (например, атака изнутри) → Эскалировать в Tier-2 с пометкой "Требуется расследование". Ключевой принцип — любой шаг, который можно автоматизировать в SOAR, должен быть автоматизирован. Роль Tier-1 — контролировать и инициировать эти автоматизированные сценарии.

Tier-2: Методика расследования

На втором уровне заканчиваются шаблоны и начинается аналитика. Playbook для Tier-2, это не последовательность команд, а структурированная методика расследования для определенного класса угроз. Например, "Расследование инцидента с подозрением на утечку данных".

Структура playbook Tier-2:

• Класс инцидента: Определение (например, "Подозрение на компрометацию учетной записи привилегированного пользователя").
• Цели расследования: Не обработка, а поиск ответов. ("1. Установить факт компрометации. 2. Определить вектор атаки и точку входа. 3. Установить масштаб (какие системы и данные затронуты). 4. Найти индикаторы компромрометации (IoC) для охоты.").
• Фазы расследования (Tactics, Techniques & Procedures):
  • Фаза сбора артефактов: Где и какие логи собрать (логи аутентификации, журналы PowerShell, сетевой трафик с ключевых узлов), как создать дамп памяти с подозрительного хоста.
  • Фаза анализа: Методики анализа собранных данных. Как искать аномалии в сессиях, выявлять подозрительные исполняемые файлы, анализировать временные метки.
  • Фаза сдерживания (Containment): Варианты изолирования угрозы в зависимости от стадии атаки (блокировка УЗ, изоляция хоста в сети, отключение от критичных ресурсов). Важно: здесь не предписано одно действие, а даны варианты с оценкой последствий.
• Критерии эскалации в Tier-3: Четкие условия, при которых расследование передается на третий уровень (например, "Затронуты системы 1-го класса защищенности", "Есть признаки целенаправленной атаки (APT)", "Требуется взаимодействие с ФСТЭК или правоохранительными органами").

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

Tier-3: Стратегия управления и отчетность

Playbook третьего уровня наименее "технический" и наиболее "управленческий". Он фокусируется не на том, как что-то сделать, а на том, что должно быть сделано в рамках управления инцидентом и выполнения регуляторных требований.

Ядро playbook Tier-3, это контрольные точки процесса управления инцидентом (Incident Response):

• Активация плана реагирования: Кто и при каких условиях объявляет режим инцидента, как собирается группа реагирования (CIRT).
• Внутренние и внешние коммуникации: Протоколы оповещения руководства, взаимодействия с PR/юристами. Ключевой блок — протокол взаимодействия с ФСТЭК в рамках 152-ФЗ: что сообщать, в какие сроки, какие формы использовать.
• Принятие стратегических решений: Критерии для принятия решений о масштабном отключении систем, начале восстановления из резервных копий, публичном раскрытии информации.
• Постинцидентный анализ (Lessons Learned): Структура проведения разбора, шаблон итогового отчета, процесс обновления политик безопасности, playbooks и конфигураций систем на основе выводов.
• Регуляторная отчетность: Сбор и оформление доказательной базы для предоставления в регулятор. Какие артефакты, логи и отчеты по расследованию необходимо сохранить и как оформить.

  Как начать и что внедрять в первую очередь

Попытка сразу создать десятки идеальных playbooks для всех уровней обречена на провал. Начинать нужно с наиболее частых и критичных сценариев.

1. Для Tier-1: Выберите 3-5 самых "шумных" и массовых типов атак, которые уже умеет детектировать ваша SIEM. Например, сканирование портов, брутфорс, фишинговые письма. Для каждого напишите простейший алгоритмический playbook, даже если он будет выполняться вручную. Цель — стандартизировать рутину.
2. Для Tier-2: Возьмите 1-2 наиболее опасных сценария из модели угроз для вашей организации. Часто это компрометация учетной записи или подозрение на вредоносное ПО. Создайте каркас методики расследования, определив ключевые источники данных и последовательность анализа.
3. Для Tier-3: Разработайте один основной playbook — "Управление критическим инцидентом". Он должен описывать роли, точки принятия решений и шаблоны коммуникаций, включая взаимодействие с регулятором.

Следующий шаг — интеграция этих playbooks в SOAR. Автоматизируйте для Tier-1 все, что возможно: обогащение данных, блокировку IP, создание тикетов. Для Tier-2 используйте SOAR как платформу для оркестрации сбора артефактов, чтобы аналитик не бегал по системам вручную, а запускал готовые сборники.

Главный критерий работоспособности playbook — не его объем или красота, а то, используется ли он в реальной работе. Если аналитики Tier-1 и Tier-2 игнорируют документы и действуют по памяти или наитию, значит, playbooks не соответствуют их реальным задачам и контексту. Регулярные учения на основе этих сценариев — единственный способ проверить их адекватность и доработать.