Идеальный плейбук: как быстро и грамотно реагировать на атаки

Бумажный кибербез

По оценке 73% ИБ-руководителей, их организации не готовы в полной мере отреагировать на крупную кибератаку, следует из глобального опроса 600 CISO, проведённого компанией Sygnia. При этом формальные планы реагирования на инциденты существуют почти у всех организаций — их внедрили 99% респондентов.

Получается, что несмотря на наличие стратегии реагирования, компании не уверены ни в самих планах, ни в своей способности выполнить их в условиях реального кризиса, считают в Sygnia.

Другая картина в России — документированные сценарии реагирования на инциденты, которые регулярно тестируются и совершенствуются, есть только у 15% организаций. Лишь 20% внедрили внутренние ИБ-стандарты с учётом трендов угроз. Меньше половины (40%) регулярно сканируют системы на уязвимости, почти треть вовсе не проводит проверку защищённости. Скажем честно, цифры пугающие, особенно на фоне активного внедрения ИИ.

Одного плейбука мало

Как создать правильный плейбук, рассчитать все риски и зашить их в сценарий? «Эффективный плейбук — это результат совместной работы ИБ, ИТ и бизнеса. ИБ определяет логику реагирования и координирует процесс, ИТ обеспечивает техническую реализацию, а бизнес задаёт приоритеты и рамки допустимого риска», — говорит руководитель центра мониторинга и реагирования на киберугрозы BI.ZONE Андрей Шаляпин.

Ключевые метрики эффективности плейбуков: MTTD ( время обнаружения), MTTR (время реагирования), MTTC (время локализации) и MTTRec (время восстановления). Дополнительные критерии: процент ложных срабатываний, доля инцидентов, закрытых по плейбуку без эскалации, и снижение повторяемости однотипных инцидентов, рассказала эксперт центра мониторинга и реагирования «Инфосистемы Джет» Анастасия Коробицына.

А как должны вести сами сотрудники, когда наступит час Х, какой KPI, когда атака уже произошла? «Качественная оценка: если выстроенный алгоритм реагирования позволяет джуну без ошибок и задержек выполнить работу мидла, то это отличный сценарий», — считает ведущий инженер-аналитик Аналитического центра кибербезопасности компании «Газинформсервис» Максим Федосенко.

Управляющий RTM Group Евгений Царёв также важными показателями называет уровень отклонения, то есть как часто аналитик отходит от шагов плейбука (если часто, то плейбук не годится). Другой критерий — точность, то есть приводит ли следование плейбуку к верному закрытию тикета.

ИБ-спецы отмечают, что единый плейбук «на все случаи жизни» малоэффективен для сложных инфраструктур — слишком велик разброс сценариев атак. Оптимально использовать гибридную модель: базовый с общими процедурами и специализированный для разных типов инцидентов, интегрированные с SOAR для автоматизации действий, говорит Анастасия Коробицына. Наиболее жизнеспособными в «боевых реалиях» реагирования являются модульные плейбуки, разработанные на основе покрытия конкретных тактик, техник, используемых злоумышленником, считает Максим Федосенко.

Приоритетные типы инцидентов и сценарии атак выделяются с учётом особенностей ИТ-инфраструктуры и бизнес-процессов компании. К первой категории угроз опрошенные «Киберболоидом» эксперты отнесли:

• вымогатели
• компрометацию учетных записей
• фишинг
• внутренние инциденты/нарушение политик безопасности
• утечки данных
• DDoS-атаки
• атаки на сетевой периметр
• шифрование данных
• вредоносное ПО
• эксплуатация уязвимостей
• подозрительная активность.

Второй уровень инцидентов — те, которые затрагивают меньше подразделений, носят локальный характер или встречаются редко. «Такой подход позволяет сосредоточить ресурсы на действительно критичных рисках и обеспечить практическую готовность к наиболее вероятным и значимым ИБ-событиям», — говорит Андрей Шаляпин.

Анастасия Коробицына отдельно выделяет BEC-атаки, инциденты с IoT-устройствами, атаки на цепочки поставок и долгосрочные APT-кампании — они требуют особого подхода и часто не формализованы в плейбуках. Плейбуки также должны содержать процедуры для выявления аномалий в поведении штатных утилит, чёткий алгоритм верификации. Например, является ли запуск AnyDesk санкционированным тикетом в Helpdesk или это что-то другое, отмечает Евгений Царёв. Специалисты компании «Авилликс» рекомендуют включать в плейбуки атаки на supply-chain/CI/CD и обходы MFA.

Отраслевые «фишки»

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

• Для промышленности и ТЭК (OT/АСУ ТП) приоритет — непрерывность процесса. В плейбуке может быть прямо запрещена изоляция хоста, если это приведёт к остановке конвейера или к аварии.
• В финтехе акцент на фрод-мониторинге и взаимодействии с ЦБ. Плейбук должен включать протоколы мгновенной блокировки транзакционных шлюзов. Важно реагирование на инциденты в платёжном процессе для банков.
• В ритейле ключевое — это защита персональных и корпоративных данных и доступность фронтенда в пиковые нагрузки. Плейбук должен быть ориентирован на работу с CDN, WAF и быструю очистку базы от вредоносного кода.
• В телекоме приоритет — быстрое восстановление услуг связи и отслеживание атак на биллинг.

Технический аккаунт-менеджер R-Vision Александр Винокуров напоминает, что субъекты КИИ обязаны направлять уведомление в ГосСОПКА в течение трёх часов с момента обнаружения инцидента для значимых объектов КИИ и в течение 24 часов — для иных объектов. Банки обязаны направлять уведомления в ФинЦЕРТ. Это также должно быть прописано в плейбуках.

Опыт компаний

Ozon

В Ozon выстроен формализованный процесс Incident Response (IR) с выделенной командой реагирования и координации ИБ-инцидентов. Команда находится вне SOC и занимается не только расследованием инцидентов (включая криминалистику, аналитику и координацию устранения последствий), но и проактивным поиском угроз. В этот процесс также вовлечены специалисты legal, PR, GR, а также службы физической и экономической безопасности. При этом IR в ИБ интегрирован с общим процессом реагирования ИТ-команды, отвечающей за технические сбои и отказоустойчивость сервисов. Плейбуки регулярно обновляются на основе практического опыта, результатов киберучений, threat hunting-активностей и данных threat intelligence. Формальный пересмотр проводится не реже одного раза в полгода, но изменения могут вноситься и быстрее, если появляются новые вводные.

В числе критичных сценариев для отрасли в компании отметили фишинг, DDoS-атаки, атаки через доверенные связи (trusted relationship) и supply chain-риски. При этом слабым звеном по-прежнему остаётся человек, поэтому Ozon большое внимание уделяет программам awareness и регулярным киберучениям для сотрудников. Для снижения рисков, связанных с партнёрами и цепочками поставок, применяются дополнительные процедуры проверки контрагентов и KYC-подходы. Защита от DDoS и других инфраструктурных атак строится на многоуровневой технической защите и постоянном мониторинге аномалий.

«Мы регулярно проводим киберучения разных форматов: как для проверки существующих плейбуков, так и для отработки новых сценариев — например, на основе кейсов других компаний или анализа активности APT-группировок. По итогам каждого инцидента или учений проводится обязательная retrospective-встреча: формируется подробный таймлайн, создаётся postmortem-документ и задачи на доработки, включая обновление самих плейбуков. Такой postmortem не закрывается до выполнения всех корректирующих действий», — рассказали «Киберболоиду» в Ozon.

Ozon актуализирует плейбуки под современные атаки, которые быстро эволюционируют и могут потребовать другого сценария реагирования. Поэтому помимо автоматизации — прежде всего на уровне SOC и обработки событий ИБ — компания инвестирует в развитие экспертизы команд, обучение специалистов, threat hunting и регулярные киберучения.

RWB (Wildberries & Russ)

«В нашем SOC плейбуки — это базовая основа для работы L1 (первой линии реагирования). Они покрывают наиболее критичные для нашей инфраструктуры сценарии, связанные с серверной инфраструктурой и пользовательскими машинами. Цель — чтобы аналитик не изобретал велосипед и не тратил время на типовые задачи, которые могут съедать чуть ли не 80% рабочего времени», — говорит руководитель SOC RWB (Wildberries & Russ) Игорь Гребенников.

Работа с плейбуками в компании организована так: автоматизировано только то, что однозначно и безопасно, а принятие финального решения и нестандартные шаги остаются за аналитиком. Реагирование выстроено вокруг проактивности, скорости и минимизации последствий. Первичный отклик ориентирован на то, чтобы как можно быстрее, буквально за несколько минут, изолировать угрозу — отключить хост от сети, заблокировать учётную запись и т. д. Далее — анализ и эскалация на L2, удаление угрозы, возвращение системы в строй.

Метрики эффективности плейбуков RWB: скорость реакции, нагрузка на L1, количество нештатных отступлений от плейбуков и нарушений SLA.

Плейбуки в RWB регулярно пересматриваются. Есть два типа триггеров:

1. Если меняются правила детектирования, обновляется SIEM или EDR, появляется новый инструмент или меняется схема эскалации между L1 и L2. При каждом изменении аналитику нужны новые инструкции. Плюс есть внеплановая актуализация после каждого значимого инцидента, если на разборе выяснилось, что плейбук не покрыл какой-то шаг или, наоборот, содержал лишнее действие.
2. Плановые ретроспективы раз в квартал, чтобы не пропустить момент, когда инструкция перестаёт соответствовать реальности.

Компания также проводит периодические учения и внеплановые проверки готовности. Используются разные форматы: от базовых проработок сценариев в стиле «прилетел фишинг с макросом в Word-документе» до полноценных тренировок с живой инфраструктурой. «В ходе учений мы обязательно оцениваем: насколько аналитик следовал шагам из плейбука, где он отступил — и это было оправданно или он просто забыл про пункт? Также смотрим на время каждого этапа, качество заполнения тикета, своевременность эскалации. Нам важно проверить не только знание плейбука, но и скорость реакции, умение принимать решения, когда инструкция не покрывает все 100% ситуаций», — говорит Игорь Гребенников.

После каждого реального инцидента и после крупных учений ИБ-команда обязательно проводит разбор полётов (lessons learned). Участвует не только SOC, но и смежные команды, если инцидент их задел (сеть, администрирование, разработка, поддержка пользователей). Разбор должен дать ответы на три вопроса: что сработало хорошо, что пошло не так и что нужно изменить в процессах, инструментах или плейбуках. Его результаты становятся основанием для доработки сценария реагирования в течение нескольких дней.

Московская биржа

«У нас более 1000 плейбуков, и мы постоянно готовим новые и обновляем старые. По сути, это регулярная работа. Плейбук должен быть не формальным документом, а инструкцией, содержащей актуальную информацию по угрозам, признакам реализации атаки и понятный для сотрудников план по реагированию на угрозу», — рассказал «Киберболоиду» директор департамента операционных рисков, информационной безопасности и непрерывности бизнеса Московской биржи Сергей Демидов.

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

Сервис «Грузовичкоф»

«В Сервисе работа со сценариями реагирования на киберинциденты находится на этапе становления. Реализовано ограниченное количество базовых сценариев, охватывающих наиболее очевидные и критичные угрозы, однако их пока недостаточно для полного покрытия текущего ландшафта рисков», — говорит директор по информационной безопасности «Грузовичкоф» Дмитрий Ляхов.

Значительная часть процессов реагирования выполняется вручную. Компания рассматривает развитие плейбуков и постепенное внедрение элементов автоматизации как одно из ключевых направлений, однако здесь есть объективное ограничение по ресурсам. Сервис строит систему реагирования с пониманием, что это сложный и многоплановый процесс, требующий особого внимания на каждом этапе. Он затрагивает не только технические аспекты, но и организационные процедуры, распределение ответственности, культуру работы с инцидентами. Команда формирует устойчивую системную базовую практику, чтобы далее плавно перейти к более технологичным и автоматизированным решениям.