«А что будем делать, когда всё-таки взломают?»: как подготовиться к инциденту заранее на примере видеоигр

Привет, Хабр! Меня зовут Аскар Мусаев, я эксперт по непрерывности бизнеса в «Инфосистемы Джет». В статье я разберу, как системно проверить готовность компании не к предотвращению атак, а к действиям после успешного взлома, когда критические системы остановлены, а время на восстановление ограничено.

При создании киберустойчивой инфраструктуры много внимания уделяется проверкам защищённости: пентестам, Red/Purple Teaming, программам Bug Bounty и кибериспытаниям. Оценка часто сводится к бинарному вопросу «Взломали / Не взломали?». Однако, даже если взломать пока не удалось, это ещё не говорит об устойчивом к атакам бизнесе, ведь в тени остается вопрос: «А что будем делать, когда всё-таки взломают?».

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

*Для удобства термины «тестирования», «учения» и «проверки» используются в тексте как синонимы.

Чтобы с таблицей было понятнее работать, форматы и уровни тестирований я опишу на примере видеоигр.

Итак, что у нас есть по формату:

• Теоретическое, дискуссионное тестирование — обсуждения планов и потенциальных действий без какого-то сценария инцидента. Собрались, уточнили роли, проговорили, кто и что делает, сколько это займет времени, выявили недочеты в плане или зафиксировали обсуждение в новом плане.
  Это «режим обучения», где нам говорят, что W — это идти вперед, а с зажатым Shift мы побежим. Побегали по пустой комнате и поменяли какие-то настройки управления, если поняли, что что-то не устраивает.

• Настольное тестирование со сценарием или table-top — обогащенное сценарием инцидента теоретическое тестирование с целью всестороннего анализа планов и ответных мер на инцидент.
  
  Представьте прохождение на самом легком уровне сложности только для знакомства с сюжетом. Прошли игру, знаем, где ключевые боссы и развилки, но побочные квесты не трогали, а врагов побеждали одним ударом. Представляем, что нас ждет на hard’е и без сохранений (при инциденте), но ощущений этих не испытывали.

• Моделирование — практическая проверка какого-либо сценария реагирования или восстановления, то есть переезд работников на резервные рабочие места или восстановление небольшого сегмента инфраструктуры в ответ на шифровальщика с привлечением ИБ-команды.
  
  А вот здесь уже полное прохождение за какую-либо фракцию или на одну из концовок. И квесты посмотрели, и сложность была повыше. В общем, игра пройдена и механики изучены, следующая часть серии с такими же механиками не вызовет сложностей.

• Полномасштабное тестирование — моделирование с охватом всей компании.
  
  100% ачивка получена. Знаем все детали, посмотрели каждый сундук. Но и времени потрачено было немало.

• Функциональные или специальные проверки — проверяем не сквозной процесс, а только небольшую часть в его рамках.
  
  Арена, бесконечный квест или «гриндилка», где можно совершенствовать определенный навык ГГ. Вроде и не очень интересно, но периодически забегать надо.

Также стоит сказать про условные три уровня планов и их проверок, за аналогию возьмем жанры игр:

• Стратегический, определяющий ключевые векторы в реагировании и восстановлении. Обычно основные участники — топ-менеджмент.
  
  Игры в стиле интерактивного кино подходят для понимания данного уровня лучше всего. Сложные решения и непростой выбор — то, что делает игрок в интерактивном кино или топ-менеджмент при реагировании на кризис. И да, 4х-стратегии больше похожи на обычную деятельность высокого руководства, но речь-то про кризисную ситуацию!

• Тактический, координирующий основные работы и превращающий заданные векторы в конкретные задачи. Ответственность за него лежит на руководителях ИТ, ИБ, PR, а также на экспертах, обладающих обширными знаниями и пониманием полной картины.
  
  А вот это классические Real Time Strategy, управлять ресурсами в момент инцидента, давать задачи и возглавить команду спасения Азерота инфраструктуры. И не забыть лучшим по итогам выдать больше золота!

• Операционный, выполняющий конкретные задачи — от реализации DR-плана до публикации статуса по инциденту в телеграм-канале.
  
  Старые добрые шутеры, где всё решает скилл — это про операционный уровень. А уж если инфраструктура большая и сложная, планы не подготовлены, обилие legacy, то старые добрые шутеры перерастают в soulslike-игры.

Ну а теперь накладываем уровень на формат и получаем понимание того, что и как можем протестировать. Да, оптимально взять и везде провести полномасштабное тестирование, но насколько у вас хватит времени и ресурсов, чтобы проходить каждую игру на 100%?

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

Зарубежные практики и стандарты

Начать, конечно, стоит с классики: ISO 22301 и вся серия стандартов обеспечения непрерывности бизнеса придумана как раз для повышения устойчивости компаний при различных катастрофах и чрезвычайных ситуациях. Масштабный инцидент с шифрованием или уничтожением инфраструктуры тоже подходит под это описание.

Отдельный стандарт семейства — ISO 22398:2013 Guidelines for exercises (созданный в 2013 и подтверждённый без изменений в 2022 году) — вводит ключевое разделение упражнений на два типа: Discussion-based (теоретические обсуждения, например, настольное тестирование кризисного реагирования) и Trials (практические проверки с реальными действиями, такие как эвакуация команды на резервную площадку). Первые подходят для отработки стратегических решений и могут проводиться даже при отсутствии детализированных планов. Вторые эффективны на тактическом и операционном уровнях: они моделируют ситуацию, близкую к реальной, позволяют проверить полноту инструкций и замерить время реагирования и восстановления.

Эта классификация — не выбор «либо–либо», а основа для планирования многоуровневых проверок. Она помогает системно подойти к тестированию разных аспектов реагирования и восстановления, сочетая теоретическую проработку с практическими проверками там, где это критично.

Подробно проверки готовности и тестирование планов также затрагиваются в ISO 22313:2020 Guidance on the use of ISO 22301. Стандарт развивает классификацию, заданную в 2013 году, и также опирается на два уровня проверок:

• Теоретические, основанные на дискуссии (Discussion): проверки от совместного обсуждения плана до table-top-тестирований по разработанному сценарию длительностью в несколько часов.

• Смоделированные (Simulation): более масштабные учения, задействующие множество команд, со сложным разветвлённым сценарием, максимально приближенным к реальному инциденту.

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

Еще одна база — ISO/IEC 27031:2025 Cybersecurity – Information and communication technology readiness for business continuity (скорректирована в 2026 году). Стандарт в большей степени нацелен на проверки готовности технической инфраструктуры к восстановлению и разделяет тестирования на три блока:

• Теоретический обзор планов (Desktop process review) — обсудить план восстановления, проверить, что у исполнителей есть понимание инструкций и требующихся от них действий.

• Моделирование восстановления (Recovery simulation) — запустить тестовое восстановление компонента инфраструктуры, системы или сервиса.

• Проверка цифровой устойчивости (Digital resilience) — провести полную проверку ИТ-инфраструктуры, например, с переключением из ОЦОД в РЦОД.

Такие проверки хорошо подходят для тестирования DR-планов, но не позволяют охватить весь процесс реагирования целиком, включая коммуникации, взаимодействие со СМИ и принятие решений.

Еще один стандарт ISO, посвященный кризис-менеджменту, это ISO 22361:2022 Crisis management –Guidelines. Для проверки кризисного реагирования он предлагает нам воспользоваться уже знакомыми ISO 22313 и ISO 22398. При этом сам стандарт я бы рекомендовал прочитать всем, кто планирует учения с топ-менеджментом, чтобы понимать возможные фазы управления кризисом и модерировать тестирование, задавая правильные вопросы.

Из других рекомендаций и практик, не относящихся к ISO, можно выделить следующие:

1.       NIST SP 800-84 Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities охватывает более широкий спектр проверок, чем ISO/IEC 27031, хотя также делает акцент на DR-планировании. Его классификация тестирований отличается универсальностью:

• Настольные — теоретические обсуждения, как со сценарием, так и без него.

• Функциональные — практические проверки конкретных функций в рамках восстановления ИТ-инфраструктуры или коммуникаций, например, переключение на резервного провайдера.

• Тесты — проверка компонентов: от нагрузочного тестирования отдельных систем до полномасштабных учений.

Стандарт охватывает операционный и тактический уровни с уклоном в ИТ. Несмотря на дату публикации, а это аж 2006 год, он остаётся базовым документом в этой области. Актуальные руководства NIST (SP 800-61 Rev. 3, SP 800-184) ссылаются на 800-84 как на основу при рассмотрении вопросов учений и тестирования.

2.       Good Practice Guidelines 7.0 от Business Continuity Institute вводит, пожалуй, самую серьезную классификацию учений и тестирований:

• Основанные на обсуждениях (Discussion-based) — теоретические обсуждения без сценария.

• Сценарные (Scenario) — настольные тестирования по заранее разработанному сценарию.

• Моделирование (Simulation) — практическая отработка элементов реагирования с ограниченным воздействием на инфраструктуру.

• Полномасштабные (Live) — масштабные учения в стиле «дергаем рубильник и смотрим, что будет».

• Прикладные (Test) — специфичные проверки, от пожарной эвакуации до тестирования резервных копий.

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

Отечественные стандарты и рекомендации

В российской практике системные тестирования сквозного процесса реагирования и восстановления встречаются редко, как и теоретические классификации таких проверок. Чаще всего в контексте киберустойчивости упоминаются командно-штабные учения (КШУ). Термин заимствован из системы ГО/ЧС и описан в методических рекомендациях по подготовке и проведению командно-штабных учений в организациях МЧС России. Верхнеуровнево они выделяют три типа тренировок: практические (объектные), теоретические (штабные) и смешанные (командно-штабные, тактико-специальные).

На деле КШУ часто используется как собирательный маркетинговый термин — от Purple Team до обучения руководства. Логичнее всего под ним понимать настольное тестирование по сценарию (table-top), иногда с элементами практики. Такая интерпретация соответствует зарубежным аналогам.

Еще на отечественном рынке есть ГОСТ Р 59711-2022 Управление компьютерными инцидентами. Организация деятельности по управлению компьютерными инцидентами. Документ также вводит классификацию тренировок по проверке реагирования на инциденты:

• обсуждение (дискуссии);

• командные тренинги;

• практические занятия;

• смешанные (использование всех трех форм).

Однако, в отличие от зарубежных стандартов, документ не раскрывает каждый формат детально. Более того, в классификации смешаны критерии (форматы, способы и участники), из-за чего большинство проверок формально попадают в категорию «смешанные», что снижает практическую пользу от такой классификации. В остальном многообразии отечественных стандартов чего-то релевантного мне найти не удалось — дополнения от читателей приветствуются в комментариях!

Что делать с этой информацией?

Стандарты управления непрерывностью и кризис-менеджмента, особенно в контексте инцидентов ИБ, не предлагают нам универсального способа тестирования или волшебной проверки всего и сразу. На практике компании чаще фокусируются на защите «слева от инцидента»: даже после успешного Red Team редко моделируют ответные действия на уровне топ-менеджмента, PR и всей организации. Вместо сквозного тестирования реагирования проводят точечные функциональные проверки. Как показывает опыт, это сказывается на скорости реагирования при реальном инциденте: вместо отработанных процедур компания тратит критически важное время на обсуждение решений, которые могли быть приняты заранее.

На мой взгляд, оптимальное дополнение к проверкам защищённости — настольное тестирование со сценарием, построенным на успехах атакующих, с последующими специальными проверками гипотез по восстановлению, озвученных в ходе table-top.Такая последовательность даёт ответ на главный вопрос: насколько компания киберустойчива. Ведь даже при успешной атаке у неё окажутся и проработанный план действий, и подтверждённая техническая возможность восстановиться.