Сценарий учений для критической инфраструктуры: имитируем атаку и проверяем готовность

02.12.2025
5
1
1770976225791.webp


1. Зачем нужны киберучения в OT​


Киберучения в OT — это не роскошь, а must-have почти для любого предприятия. Запускать в продакшн отмазки в стиле «у нас всё работает» — прямой путь к санкциям от ФСТЭК. Учения для КИИ — это не блажь, а жёсткая проверка на вшивость. Смысл в том, чтобы придумать правдоподобную угрозу и заставить ваши планы, процессы и людей пройти через стресс-тест. Идеальный сценарий — это когда киберсценарий по пунктам бьёт по регламентам регуляторов, а итогом становится не красивая презентация, а реальное понимание, где у вас в обороне дыра размером с шлюзовую задвижку. Давайте посмотрим, зачем это всё нужно.

1.1. Регуляторные требования​


Если ваш объект — часть КИИ (критической инфраструктуры), то по ФЗ-187 и куче подзаконных актов (привет, ФСТЭК и ФСБ) вы обязаны эти учения проводить. Это не просто«рекомендации», а жёсткое требование. С их помощью учат ловить атаки, откатывать системы и не сыпаться при первом же взломе. Регуляторка тоже не дремлет: закон требует не просто защищаться, а ещё и тренироваться.

ФЗ-187 требует от КИИ не просто так сидеть, а тренироваться в отражении атак. ФСТЭК (приказы №235 и №239) вообще говорит: раз в год устраивайте учения по планам реагирования. Иначе – штрафы и головная боль при проверках ФСТЭК/ФСБ. Compliance, аттестация – всё как положено.

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

1.2. Проверка IR-процессов​


У вас наверняка есть толстая папка «План реагирования на киберинциденты» (IR-план). Учения — это момент, когда он выходит в свет. Можно смоделировать атаку по сценарию регулятора (например, по приказу ФСТЭК №17) и посмотреть, как ваша цепочка «обнаружили-зафиксировали-победили» работает в режиме реального времени. Сработает ли автоматическое оповещение? Поймут ли технологи, что к ним пришла не «поломка», а «взлом»?

1.3. Тренировка команды​

Самая большая проблема в OT-безопасности — это когда «айтишники» в панике кричат про «эксплойт в сети SCADA», а технологи на них смотрят как на инопланетян и спрашивают, не сломает ли это компрессор. Учения — лучший способ заставить эти два племени понять друг друга. Здесь отрабатывается та самая межфункциональная связка, которую требуют методички ФСТЭК. Кто кому и как передаёт команду на аварийную остановку? Как операторы работают с группой реагирования ФСБ? Только на практике команда превращается из разрозненных специалистов в слаженный экипаж, способный не просто «отчитаться», а реально отработать атаку.

2. Типы учений​

Учения бывают разные – от "посиделок за столом" до полного хаоса. Выбор зависит от ваших целей, бюджета и желания понервничать. Главное – помнить, что это не просто галочка в отчете, а реальная возможность подготовиться к неприятностям. Иначе потом будете вспоминать эти учения, сидя в темном цеху без электричества.


2.1. Tabletop Exercise​


По сути, это прокачанная диванная аналитика. Все ключевые игроки (безопасники, технологи, начальство) садятся за стол и по сценарию разбирают «а что, если...». Никаких кнопок не жмут, только рты работают. Главная цель — заставить технарей и айтишников наконец-то понять друг друга. Идеально, чтобы найти дыры в планах и договориться, кто кому звонит, когда всё горит. Риск нулевой, бюджет скромный, а пользы — вагон. Можно даже придумать особую настольную игру для этих целей.

2.2. Functional Exercise​


Здесь уже перестают болтать и начинают делать, но на «болванках». Команды отрабатывают сценарий на специальном стенде — тестовой копии вашей АСУ ТП или в симуляторе. Можно запускать тревоги, ковыряться в логах SIEM, пробовать «отрезать» сегмент сети или восстанавливать виртуальный ПЛК из бэкапа. Цель — проверить, работают ли ваши инструменты и процедуры в связке, и не забудет ли SOC-аналитик позвонить сменному инженеру, а не писать ему в корпоративный чат. Это уже ближе к жизни, но без риска остановить реальное производство.

2.3. Full-Scale Simulation​


Апогей. Всё по-настоящему (ну, почти). Команды реагируют на инцидент так, будто он прямо сейчас бьет по вашему заводу или подстанции. Часто это делается на «горячем» резерве, в нерабочую смену или на специальном полигоне. Тут проверяется всё: скорость, навыки, нервы и умение не посылать друг друга в трудную минуту. Это дорого, сложно и рискованно — можно реально что-то сломать, если не подготовиться. Но именно так вы узнаете, сколько на самом деле минут вам нужно, чтобы перейти на ручное управление, и увидите, как ваш безупречный план рассыпается при первом же контакте с реальностью. Делается обычно раз в год, и все потом месяц отходят.

3. Разработка сценария​

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

3.1. MITRE ATT&CK for ICS​


Это как "шпаргалка" для злоумышленников, только у вас. MITRE ATT&CK for ICS – это база знаний о тактиках и техниках, которые используют хакеры для атак на промышленные системы. Тактика – это общая цель злоумышленника (например, "получение доступа"), а техника – конкретный способ её достижения (например, "фишинг"). Там всё разложено по полочкам: от разведки до вывода из строя. Используйте её, чтобы придумать реалистичный сценарий, основанный на реальных угрозах. Не нужно изобретать велосипед – просто выбирайте техники, которые наиболее актуальны для вашей отрасли и систем. Это как конструктор "Лего" для кибератак. ICS расшифровывается как Industrial Control Systems – системы управления промышленными процессами.

3.2. Реальные кейсы: Triton, Industroyer​

Зачем придумывать что-то новое, если уже есть готовые примеры? Triton и Industroyer – это реальные кибератаки на промышленные объекты, которые показали, как злоумышленники могут вывести из строя критически важную инфраструктуру. Изучите эти кейсы, чтобы понять, какие техники они использовали, какие уязвимости эксплуатировали и как можно было предотвратить эти атаки. Это как смотреть видео с разбором полётов – чтобы не повторять чужих ошибок. Только не пытайтесь повторить их в реальности, пожалуйста.

Ребята из Triton полезли в сеть Saudi Petrochemicals и решили поиграть с системой Triconex SIS – штукой, которая должна была защищать от аварий. В итоге, они смогли перепрограммировать контроллеры, заставить систему "зависнуть" и остановить производство.

В сценарии для учений можно разыграть, как они искали уязвимости в протоколе TriStation, загружали свой вредоносный код (trilog.exe) и пытались обмануть систему безопасности, чтобы создать опасную ситуацию. Задача участников – вовремя заметить подозрительную активность, отрезать сеть и вернуть SIS к жизни. MITRE ATT&CK Evaluations использует этот кейс, чтобы проверить, как хорошо команды умеют бороться с такими атаками. В сценарии для учений можно смоделировать, как они искали устройства в сети, маскировались под системные программы (типа notepad.exe, ну а что, бывает и такое!), запускали вредоносный код по ночам и заодно стирали данные. Задача – засечь подозрительный трафик, изолировать ICS и скоординировать действия с энергетиками.

Industroyer (еще известен как CrashOverride) – это вообще цирк с конями, который вырубил электричество. Злоумышленники опять же через IT-сеть добрались до ICS, использовали протоколы IEC 101/104 и OPC DA, чтобы притвориться легитимными командами и выключить выключатели на подстанциях. И еще добавили модуль для стирания данных, чтобы наверняка.

В учениях этот сценарий идеален для отработки detection в промышленных протоколах. Как отличить легитимную команду от вредоносной, если синтаксис правильный? Как понять, что notepad.exe, который жрет 100% ЦПУ, на самом деле шифрует твои диспетчерские логи? И главное — как синхронизироваться с внешним контуром, когда свет погас на четверти района. Kaspersky на этот кейс уже давно маппинг сделал — бери и пользуйся.

3.3. Адаптация под предприятие​

Нельзя просто взять сценарий из интернета и запустить его у себя. Нужно адаптировать его под специфику вашего предприятия: ваши системы, процессы, персонал и риски. Учитывайте, какие у вас есть уязвимости (слабые места в системе безопасности), какие активы наиболее ценны и какие последствия могут быть, если эти активы будут скомпрометированы. Актив – это всё, что имеет ценность для вашей организации (например, данные, оборудование, репутация). Помните, что каждый завод и каждая электростанция уникальны, поэтому и сценарий должен быть уникальным. Иначе учения будут бесполезны.

4. Роли участников​

Учения — это командная игра, где у каждого своя задача. Если роли не распределить, получится бардак: атакующие будут скучать, защитники — паниковать, а наблюдатели — беспомощно жевать попкорн. В ОТ-сценарии состав команд особенно важен, потому что кроме классических кибербойцов есть главные герои — люди, которые дергают за реальные рычаги.

4.1. Red Cell (attackers) — злобные хакеры на зарплате​

Это не просто «плохие парни». Это ваши внутренние пентестеры или приглашенные спецы, которые играют по сценарию, но с креативом. Их задача — не просто «взломать», а следовать тактикам из MITRE ATT&CK, имитируя реальную APT-группу. Они думают как враг: ищут слабые места в периметре, пытаются попасть в сегмент АСУ ТП и достичь цели — например, записать вредоносный код на ПЛК или вызвать аномалию в процессе. Их успех — это находка для компании, а не позор для Blue Team.

4.2. Blue Team (defenders) — защитники, которые тушат пожар​

Их зона ответственности — обнаружение и отражение атаки. Но в ОТ это не только SOC-аналитики, сидящие за мониторами SIEM. Это сетевики, которые должны изолировать зараженный сегмент, и инженеры инфобезопасности. Их главная задача — не просто найти артефакт, а понять операционный контекст: «Этот трафик на порт 502 — это легитимный запрос от HMI или сканирование злоумышленника?». И самое важное — вовремя и четко передать информацию технологам.

4.3. White Cell (control) — режиссеры и судьи в одном лице​

Мозговой центр учений. Они знают сценарий наизусть, контролируют ход событий и вводят дополнительные вводные (инжекты), если всё идет слишком гладко или, наоборот, катится в тартарары. Их задача — обеспечить реалистичность и безопасность, не дать учению превратиться в хаос или, что хуже, нанести реальный ущерб технологическому процессу. Это арбитры, которые следят за правилами и фиксируют все ключевые моменты для будущего разбора полетов.

4.4. Технологи и операторы — те, кто спасает реальный мир​


Самая критичная роль в ОТ-учениях. Это не пассивные наблюдатели, а ключевые игроки. Они получают сигналы от Blue Team («У вас в системе SCADA аномалия!») и принимают операционные решения: перейти на ручное управление, инициировать аварийный останов процесса, проверить показания датчиков «вживую». Их реакция и взаимодействие с киберкомандой — это именно то, что отличает ОТ-учения от IT-шных. Именно здесь проверяется, сможет ли оператор отличить кибератаку от штатной неисправности и не нажать лишнюю кнопку в панике.

Заключение​

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

Главный итог любых учений — это не идеально отточенный сценарий и не гордость за победившую Blue Team. Это та самая грязь под ногтями, которую вы вытащите наружу: нестыковки в регламентах, конфликты между IT и автоматизаторами, недостаток прав у операторов или слепые зоны в сетевом мониторинге. Учения нужны, чтобы честно признаться: «здесь у нас дыра, а здесь люди не знают, кому звонить». И если после разбора полётов вы составили список конкретных действий, закрыли технические пробелы и научили айтишников говорить с технологами на одном языке — значит, время потрачено не зря. В противном случае это был просто дорогой спектакль с хорошей отчётностью, который не стоит ни копейки в реальном бою.
 
Мы в соцсетях:

Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab