Тренировки Tabletop: учения по сценариям атак для руководства и ИТ
Лучшее время обнаружить, что в плане реагирования нет телефона директора, а юрист не знает о сроках уведомления клиентов, — это вторник днём на учении, а не воскресная ночь во время реального инцидента. Tabletop (настольное учение) именно для этого: команда садится за стол, получает описание сценария и обсуждает, как будет действовать. Никакой техники не запускается, никаких систем не трогают. Проверяются люди, решения и договорённости.
В предыдущих статьях серии мы построили процесс реагирования и посмотрели на технические проверки через purple team. Tabletop замыкает круг: он показывает, работает ли процесс, когда им пользуются живые люди, включая руководство. Как и вся серия, статья оборонительная: сценарий описывает ситуацию словами, а не инструкции по её воспроизведению.
Зачем это нужно и чем отличается от технических проверок
Технические упражнения отвечают на вопрос «видим ли мы атаку». Tabletop отвечает на другие вопросы: кто принимает решение об отключении сервера, кто сообщает клиентам, кто согласует расходы на внешних специалистов, что делать, если почта недоступна. Ответы на них почти всегда лежат за пределами ИТ-отдела, поэтому в учении участвуют руководители, юристы, представители бизнеса и пресс-служба.
Формат дешёвый: нужны переговорная комната на два часа, заготовленный сценарий и ведущий. Эффект при этом заметен уже после первого раза: команда видит свои слепые зоны без риска для бизнеса.
Шаги
Шаг 1. Определи цели и участников
Сформулируй одну-три цели. Примеры: проверить, знает ли руководство порядок эскалации; проверить, работает ли план связи при недоступной почте; проверить, понимают ли администраторы свои действия в сценарии утечки. От целей зависит выбор сценария и состав участников. Типовой набор: руководитель ИТ, администраторы и аналитики (в нашем стенде это те, кто работает с srv-siem01 и srv-dc01), руководитель бизнес-направления, представитель юридической службы, специалист по коммуникациям, представитель кадровой службы. Назначь ведущего, который знает сценарий и не принимает решений, и наблюдателя-писаря, который фиксирует ход обсуждения.
Паспорт учения
Дата и время: 2026-11-12, 11:00-13:00
Цели: 1) эскалация; 2) связь без почты; 3) решение об отключении сервиса
Ведущий: специалист по ИБ
Писарь: сотрудник службы поддержки
Участники: директор, руководитель ИТ, 2 администратора, юрист, коммуникации
Правила: без поиска виноватых, отвечаем «что сделаем мы», а не «что написано в плане»
Шаг 2. Напиши реалистичный сценарий
Сценарий должен опираться на реальные риски организации. Возьми типовой случай, который мог бы произойти именно у вас: компрометация учётной записи администратора, шифровальщик в одном из отделов, утечка базы клиентов, недоступность облачного сервиса. Опиши его как историю с таймлайном, а не как набор технических деталей. Участникам должно быть достаточно информации, чтобы принять решение, но не больше, чем реальный дежурный имел бы в тот момент.
Сценарий «Тихий вечер пятницы»
17:40 Служба поддержки получает три обращения: у сотрудников бухгалтерии не открываются файлы на общем ресурсе, появились файлы с незнакомым расширением.
18:05 Аналитик замечает в srv-siem01 всплеск обращений к файловому серверу из сегмента 192.168.10.0/24 от учётной записи сотрудника, который сейчас в отпуске.
18:30 Часть пользователей жалуется, что не работает почта.
19:00 Один из сотрудников пересылает в чат записку с требованием связаться с неизвестными по поводу «восстановления».
Заметь, что в сценарии нет ни одной команды, которую можно выполнить. Только события, которые наблюдают люди, и телеграммы на уровне «что вы видите».
Шаг 3. Подготовь вбросы (injects)
Вброс — это новая информация, которую ведущий выдаёт в ходе обсуждения, чтобы поменять картину. Они делают учение живым и проверяют гибкость плана. Подготовь 5-8 вбросов и привяжи их к времени. Хорошие вбросы создают давление и неопределённость.
Вброс 1 (+15 мин): журналист звонит и спрашивает о слухах про утечку.
Вброс 2 (+30 мин): выясняется, что резервные копии за последние сутки недоступны.
Вброс 3 (+45 мин): директор просит дать однозначный ответ, платить ли выкуп.
Вброс 4 (+60 мин): клиент пишет, что видит странные письма от вашего имени.
Вброс 5 (+75 мин): юрист напоминает о сроке уведомления регулятора.
Обрати внимание: вопрос о выкупе нужно обсуждать как управленческое решение с юридическими и этическими последствиями, а не как техническое. У каждой организации своя политика, и учение хорошее место, чтобы узнать, что думают руководители до реальной ситуации.
Шаг 4. Проведи учение
Начни с короткого вступления: цели, правила, формат. Подчеркни, что это не экзамен. Затем ведущий зачитывает первый эпизод и задаёт вопросы по очереди: что вы делаете первым, кому звоните, какие решения принимаете и кто их принимает. Участники отвечают от своего лица. Ведущий не подсказывает, а уточняет: «А откуда вы возьмёте телефон?», «А если этот человек недоступен?». Следи за временем: двух часов хватает на сценарий из пяти-шести эпизодов. Писарь записывает решения, спорные места и всё, что участники не смогли найти в плане.
Вопросы ведущего на каждый эпизод:
1. Кто принимает решение и на каком основании?
2. Кого и в какой срок нужно уведомить?
3. Какая информация нужна, и где вы её возьмёте?
4. Что сделаете, если основной канал связи недоступен?
5. Какие документы или плейбуки вы откроете?
Шаг 5. Разбор сразу после учения
Пока впечатления свежи, проведи короткий разбор по трём вопросам: что получилось, что нет, что изменим. Попроси участников оценить уверенность по шкале от 1 до 5 в каждой области: эскалация, связь, технические действия, юридические требования. Низкие оценки покажут, где слабое место. Не ищи виноватых: если выяснилось, что никто не знает, кто подписывает отключение сервиса, виноват процесс, а не человек.
Шаг 6. Оформи отчёт и план улучшений
В отчёт включи цели, сценарий, ход обсуждения, выявленные пробелы и план исправлений. Каждому пункту плана назначь владельца и срок. Типовые находки: устаревшие контакты, неясная передача полномочий, отсутствие шаблонов уведомлений, неизвестное местонахождение резервной копии плана реагирования.
Пробел | Действие | Владелец | Срок
Нет резервного канала связи | Завести отдельный мессенджер для команды | Руководитель ИТ| 2 недели
Неясно, кто отключает сервис | Закрепить в плане полномочия | Директор | 1 неделя
Нет шаблона уведомления клиентов | Подготовить вместе с юристом | Юрист | 3 недели
Через месяц проверь выполнение. Через полгода проведи следующее учение на другом сценарии и посмотри, исправились ли прошлые проблемы. Хороший признак: новых находок становится меньше, а старые не повторяются.
Шаг 7. Подготовь материалы заранее и отрепетируй ведение
Хорошее учение выигрывает от мелочей. Распечатай сценарий и вбросы, подготовь карточки с описанием ролей и таймер, чтобы эпизоды не растягивались. Заранее выясни, где хранится бумажная копия плана реагирования и у кого есть доступ, чтобы в ходе учения попросить участников реально найти нужный документ. Это жёстко, но очень поучительно: нередко оказывается, что план лежит на файловом сервере, который в сценарии как раз недоступен.
Ведущему полезно прогнать сценарий с коллегой за день до учения. Это помогает поймать нелогичные места и убрать лишние детали. Если в команде нет опыта, привлеки внешнего ведущего для первого раза: независимый взгляд помогает задавать неудобные вопросы, которые внутренний сотрудник стесняется задать директору.
Шаг 8. Усложняй постепенно
Первое учение пусть будет простым: один сценарий, понятные роли, спокойный темп. Со временем добавляй сложности: параллельные инциденты, недоступность ключевых людей (скажем, руководитель ИТ в отпуске, а его заместитель на больничном), сбой основной системы связи, вмешательство внешней стороны вроде регулятора или крупного клиента. Так ты проверяешь устойчивость процесса, а не только его наличие. Раз в год можно заменить настольный формат на практическое учение, где технические специалисты выполняют действия в лабораторном стенде, например на srv-lab01, а руководство принимает решения по ходу событий.
Лестница сложности учений
1. Один сценарий, один отдел, знакомые роли
2. Сценарий с вбросами и давлением по времени
3. Недоступны ключевые люди или основные системы связи
4. Параллельные события и внешние стороны
5. Комбинированное учение: решения руководства плюс действия в лаборатории
Не забудь о логистике после учения. В течение недели разошли участникам краткий отчёт и план действий, чтобы выводы не растворились в потоке текущих дел. Если ты опубликуешь итоги внутри компании, руководство увидит ценность формата и охотнее выделит время на следующее учение. А ещё полезно отметить успехи: если кто-то быстро нашёл нужный документ или принял чёткое решение, скажи об этом вслух. Учения должны оставлять ощущение пользы, а не стыда, тогда люди приходят на них охотно и ведут себя честно.
Периодичность подбирай по ресурсам: для небольшой компании два учения в год — вполне реалистичный минимум, для зрелой команды можно проводить их ежеквартально, чередуя сценарии и состав. Главное, чтобы после каждого из них список улучшений действительно выполнялся, иначе учения превращаются в ритуал.
Как внедрять поэтапно и проверять результат
Тема «Тренировки Tabletop: учения по сценариям атак для руководства и ИТ» не стоит внедрять сразу на всю инфраструктуру. Начни с одного сегмента лаборатории itpages.lab.local, например с нескольких хостов в сети 192.168.10.0/24, и зафиксируй исходное состояние: какие события уже собираются, какие правила есть, сколько ложных срабатываний даёт текущая настройка. Без этой точки отсчёта потом невозможно понять, стало лучше или хуже.
- Выбери пилотную группу систем и опиши ожидаемый результат одной фразой, которую можно проверить.
- Внедри изменение, неделю наблюдай за шумом и пропусками, правь пороги и исключения.
- Задокументируй настройку и владельца: кто отвечает за правило или процесс, когда его пересматривать.
- Только после этого расширяй охват на остальные сегменты и повторяй проверку.
Раз в квартал возвращайся к настройке и сверяй её с реальными инцидентами и учениями: защита, которую не проверяют, постепенно перестаёт соответствовать сети, которую она защищает.
Частые ошибки и как их избежать
- Слишком технический сценарий. Если обсуждение скатилось в споры про конкретные команды, руководство отключилось. Держи фокус на решениях и коммуникациях, а технические детали выноси в отдельное упражнение или purple team.
- Участие только ИТ. Без руководства, юристов и коммуникаций учение проверяет лишь часть процесса. Пригласи тех, кто будет принимать решения в реальной ситуации, даже если их график плотный.
- Превращение учения в экзамен. Когда люди боятся ошибиться, они отвечают «как положено», а не «как будет на самом деле». Объяви правило отсутствия наказаний и сам покажи пример, спокойно признав пробел.
Что дальше
Защита строится из нескольких слоёв — вот соседние темы серии: