Статья Защита КИИ: Плейбуки реагирования на инциденты в АСУ ТП

Если вы пришли из мира, где инцидент - это «залили сервер, изолировали его, переустановили ОС, восстановили из бэкапа за 20 минут», то OT вас жёстко отрезвит. Первое, что вам скажет технолог: «Ты хочешь выключить этот контроллер? Там реактор, понимаешь? Ре-ак-тор. Давай, отключай, я посмотрю».

OT Incident Response: принципы, или «Забудьте всё, чему вас учили в IT»​

1.1. Safety vs Security: в OT safety ВСЕГДА приоритетнее security​

Это не просто фраза из учебника. Это аксиома, которая должна быть выжжена на подкорке каждого, кто заходит в промышленную зону. Многие мои коллеги из «чистого» IT, придя в OT, сначала пытаются применить стандартные процедуры: увидели подозрительный трафик на HMI - и давай изолировать его, отключать сетевой кабель. А в этот момент HMI - единственный интерфейс оператора для управления задвижкой, которая сбрасывает давление в трубопроводе. Отключили HMI - оператор не видит, что давление превысило норму, и автоматика не сработала (а она, кстати, могла быть тоже скомпрометирована). Итог - разрыв трубы, нефть в реку, штрафы, уголовные дела.

1.2. Отличия от IT IR: нельзя isolate/reboot, physical consequences, legacy systems​

Давайте разложим по полочкам, почему IT-плейбуки в OT не работают. Я встречал CISO, которые говорили: «У нас в компании отличный SOC, мы любой инцидент изолируем за 10 минут». Отлично, только в OT изоляция - это не всегда про безопасность.

1.2.1. Невозможность просто выключить/перезагрузить​

В IT вы можете перезагрузить сервер, и пользователи просто попьют чай. В OT перезагрузка PLC может обнулить его память, сбросить уставки, перевести клапаны в положение «fail-safe» (которое может быть закрыто или открыто - и это не всегда то, что нужно). Кроме того, многие legacy PLC (например, Siemens S7-300, которые до сих пор работают на 90% российских заводов) имеют время загрузки от 3 до 10 минут. Всё это время процесс может быть неуправляем. А если это непрерывный процесс - доменная печь, реактор полимеризации, турбина - остановка может привести к застыванию продукта в трубах, выходу из строя оборудования и многомиллионным убыткам.

1.2.2. Физические последствия​

В IT инцидент заканчивается утечкой данных, шифрованием файлов или простоем сервиса. В OT инцидент может закончиться физическим разрушением, травмами или гибелью людей. Это не преувеличение. Вспомните Stuxnet - центрифуги разлетелись на куски. Вспомните Triton (Trisis) - попытка перепрограммировать систему безопасности (SIS) на нефтехимическом заводе, которая могла привести к взрыву. В 2017 году в Саудовской Аравии атака на завод с использованием Triton чуть не унесла жизни людей, потому что злоумышленники пытались отключить системы аварийной остановки.

В России, к счастью, пока не было громких разрушений от кибератак (официально), но это не значит, что их не было. Я знаю минимум два случая, когда атаки ransomware в OT-сети приводили к остановке производств с физическими последствиями - например, разрыв трубопровода из-за того, что операторы не могли вовремя перекрыть задвижки, потому что HMI были заблокированы.

1.2.3. Legacy systems​

Ваш SIEM может не понимать протоколы Profinet, Modbus TCP, DNP3. А на контроллерах может стоять Windows NT 4.0, на которых нет агентов EDR, а системные логи хранятся в файлах размером 8 МБ и перезаписываются каждые три дня. Это legacy. И с этим надо жить. Вы не сможете поставить патч на уязвимость в PLC, потому что вендор уже не выпускает обновления, а замена контроллера - это проект на полгода и миллион рублей.

В IR это означает, что мы должны использовать альтернативные методы обнаружения: мониторинг сетевого трафика на уровне коммутаторов (NetFlow, зеркалирование портов), анализ изменения уставок через historian, физический контроль (камеры, датчики открытия шкафов). Мы не можем рассчитывать на то, что на legacy-системе будут современные средства защиты.

1.3. IR Team: OT engineers + IT security + management - cross-functional​

И последнее, что я хочу сказать в этом разделе: команда реагирования в OT - это не только «айтишники». Это междисциплинарная команда, где у каждого есть своя роль, и они не пересекаются до момента инцидента. И это главная проблема: когда случается инцидент, вы начинаете искать главного инженера, который ушёл в отпуск, а технолог говорит: «Я не понимаю, что вы от меня хотите».

В идеале у вас должна быть предварительно сформированная команда IR, в которую входят:

• IR Lead (обычно из IT security, но с пониманием OT).
• OT Engineer - тот, кто знает технологический процесс, уставки, логику контроллеров, и может оценить safety-риски.
• Network Engineer - кто знает топологию OT-сети, VLAN, ACL, может быстро изолировать сегмент, не нарушив работу критических приложений.
• Control System Vendor Representative - если у вас сложные PLC/DCS, желательно иметь контакты инженеров поддержки вендора (Siemens, Emerson, Honeywell и т.д.), которые могут помочь с диагностикой и восстановлением прошивки.
• Management - тот, кто может принять решение о safe shutdown, если потребуется. Это не CISO, это технический директор или главный инженер.
• Юрист/Compliance - для взаимодействия с регуляторами (НКЦКИ, ФСТЭК), потому что сроки уведомления - 24 часа, и промедление грозит штрафами.

В этой команде должны быть заранее прописаны роли и каналы связи (включая резервные, на случай если основная сеть скомпрометирована). И обязательно - проводить совместные учения (tabletop exercises) раз в квартал, чтобы в боевой обстановке не было хаоса.

Теперь, когда мы разобрались с философией и принципами, переходим к самому вкусному - к плейбукам. Я начну с самого распространённого инцидента: обнаружение несанкционированного доступа к HMI.

---

2. Playbook 1: Unauthorized HMI Access​

HMI (Human-Machine Interface) - это глаза и руки оператора. Это тот самый компьютер, на котором нарисованы мнемосхемы, кнопки пуска/остановки, значения параметров. Если злоумышленник получил доступ к HMI, он может:

• Отдать команды на исполнительные механизмы (открыть/закрыть клапан, запустить/остановить насос).
• Изменить уставки (например, задать давление выше допустимого).
• Заблокировать интерфейс (ransomware).
• Замаскировать атаку, подменяя отображаемые значения (как в Stuxnet).

Инциденты с несанкционированным доступом к HMI - одни из самых частых. Чаще всего это либо внутренние злоумышленники (обиженные сотрудники, подрядчики), либо компрометация учётных данных через IT-сеть, если сегментация плохая. Я не буду тут рассуждать о том, как это произошло - я расскажу, что делать, когда вы это обнаружили.

2.1. Detection: anomalous login, unusual commands, time-of-day violation​

Как вы вообще узнаёте, что на HMI кто-то зашёл не санкционированно? В OT нет типичных EDR с детектом на подозрительные процессы (хотя на современных HMI на базе Windows можно поставить, но часто не ставят из-за боязни повлиять на производительность). Основные методы обнаружения:

2.1.1. Аномальные логины​

Вы должны мониторить события аутентификации на всех HMI и инженерных станциях. Если используется Active Directory (что в OT редкость, чаще локальные учётки), то логи собираются в SIEM. Если нет - используйте syslog-сервер, куда HMI отправляют события (например, через Windows Event Log forwarding).

Что считать аномальным?

• Неудачные попытки входа с последующим успешным входом - классический признак подбора пароля.
• Логин в нерабочее время. У вас есть операторы смен: утренняя, вечерняя, ночная. Если кто-то залогинился в 3 часа ночи, а по графику его смена с 8 до 17 - это красный флаг.
• Логин с необычного IP-адреса. В OT-сети адресация обычно статическая. Если вы видите, что HMI-1 (192.168.1.10) залогинился на HMI-2 (192.168.1.20) с IP-адреса, который не принадлежит ни одному из известных устройств - это повод бить тревогу.

Инструмент: Для сбора логов с HMI, если они на Windows, я рекомендую использовать Winlogbeat (часть Elastic Stack) или NXLog. Они легкие, не нагружают систему, и их можно настроить на отправку только событий безопасности (Event ID 4624, 4625, 4648, 4672). Не ставьте тяжелые агенты SIEM на HMI, особенно на старые - они могут вызвать лаги и упасть.

2.1.2. Необычные команды, отправленные на контроллеры​

HMI отправляет команды на PLC через промышленные протоколы (Modbus, OPC, S7comm, DNP3). Если вы мониторите сетевой трафик, вы можете обнаружить аномалии в командах.

• Например, HMI обычно пишет в определённые регистры (DB-блоки в Siemens) только в определённых пределах. Если вы видите запись в регистр, который никогда не меняется оператором (например, уставка аварийной защиты), это аномалия.
• Или если вы видите частоту команд, нехарактерную для человека (например, 10 команд в секунду) - это может быть скрипт или вредоносное ПО.

Инструмент: Используйте IDS для промышленных протоколов. Бесплатные варианты: Zeek (Bro) с пакетами для Modbus, DNP3; Snort с правилами для ICS; более продвинутый - Claroty, Nozomi, Dragos (коммерческие). В российских реалиях часто используют ViPNet IDS или продукты «Код Безопасности» (например, «Континент-АП» с модулем IDS). Но если бюджет не позволяет, можно развернуть Zeek на зеркальном порту и писать свои скрипты для детекта аномалий.

Пример скрипта для Zeek (Modbus):

event modbus_write_single_register(c: connection, transaction: count, unit_id: count, register_addr: count, value: count)
{
    if (register_addr in modbus_critical_registers)
    {
        local allowed_values = modbus_critical_registers[register_addr]$allowed_range;
        if (value < allowed_values$min || value > allowed_values$max)
        {
            NOTICE([$note=Modbus::Critical_Register_Write_Out_of_Range,
                    $conn=c,
                    $msg=fmt("Write to critical register %d with value %d", register_addr, value),
                    $sub=fmt("Unit %d, register %d", unit_id, register_addr)]);
        }
    }
}

2.1.3. Time-of-day violation​

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

2.2. Containment: disable account, NOT disconnect HMI (process running)​

Итак, вы обнаружили подозрительную активность. Что дальше? Инстинкт подсказывает: «Выдерни кабель!». Не делайте этого, если процесс находится в рабочем режиме. Вместо этого:

1. Заблокируйте учётную запись, с которой был произведён подозрительный вход. Если это локальная учётка на HMI - заблокируйте её через групповые политики или вручную (если это возможно удалённо). Если это AD - отключите учётку в AD.
2. Измените пароли на всех HMI, которые используют ту же учётную запись. Сделайте это быстро, желательно автоматизированно (например, через Ansible, если у вас есть управление конфигурациями, но в OT с этим осторожно - сначала тестируйте).
3. Не отключайте HMI от сети, если он участвует в управлении процессом. Вместо этого можно ограничить его возможности на сетевом уровне: например, настроить ACL на коммутаторе, чтобы HMI мог отправлять только read-запросы на PLC, но не write. Это позволит оператору видеть данные, но не управлять - и это безопаснее, чем полное отключение.
4. Если есть возможность перевести управление на резервную станцию - сделайте это. Например, если у вас есть два HMI, работающих в режиме «горячий резерв», вы можете переключить управление на резервный, а основной изолировать для расследования.
5. Задокументируйте время и факт изоляции - это важно для последующего расследования и для отчётности перед регуляторами.

В одном из инцидентов, когда мы обнаружили аномальные команды с HMI, мы поступили так: обнаружили, что с определённого HMI (управляющего насосной станцией) в течение 5 минут было отправлено 50 команд открытия/закрытия задвижки - это явно не человек. Мы не стали отключать HMI, а на коммутаторе уровня L3 (или даже на самом PLC, если поддерживается) временно заблокировали все write-запросы с этого IP. Оператор на месте увидел, что кнопки не работают, позвонил нам, мы объяснили ситуацию, перевели управление на резервный HMI, а основной отдали на форензику.

2.3. Investigation: audit logs, network captures, camera footage​

После того как вы локализовали угрозу и обеспечили безопасное продолжение процесса, начинается расследование. В OT форензика имеет свои особенности, но здесь я опишу основные действия именно для HMI.

2.3.1. Audit logs на HMI​

Если HMI работает на Windows, соберите:

• Журналы безопасности (Security.evtx) - события входа/выхода, запуска процессов, изменения прав.
• Журналы приложений (Application.evtx) - могут содержать ошибки, связанные с запуском SCADA-клиента.
• Логи самой SCADA-системы (например, WinCC, iFIX, Citect). Они часто хранятся в своих форматах и содержат историю действий оператора: какие кнопки нажимались, какие значения изменялись. Без них расследование будет неполным.
• Логи RDP (если используется) - Event ID 1149 (успешное подключение), 4624 (логин), 4778 (сеанс повторно подключен).

Инструмент: Для выгрузки логов с HMI без остановки процесса используйте KAPE (Kroll Artifact Parser and Extractor). Это инструмент, который может собрать все артефакты с живого Windows-хоста без установки, просто скопировав файлы. Запускайте его удалённо через PowerShell, если есть доступ, или локально, если вы физически рядом. KAPE соберет всё: event logs, registry, prefetch, amcache, и вы сможете анализировать на своей машине.

2.3.2. Network captures​

Если у вас есть зеркалирование портов (SPAN) на коммутаторе, к которому подключён HMI, вы должны захватить трафик до того, как вы изолировали HMI. Но если вы не успели - ничего страшного, можно сделать дамп трафика с самого HMI (например, с помощью Wireshark в режиме захвата), но это может повлиять на производительность, поэтому делайте это только после перевода процесса на резерв.

Что искать в трафике:

• Подозрительные соединения с необычными портами (например, соединение с внешним IP через 443 или 80, если HMI не должен выходить в интернет).
• SMB-трафик - признак распространения ransomware (EternalBlue и т.д.).
• Аномальные Modbus/S7-запросы - например, запись в нестандартные регистры, массовая запись, повторяющиеся команды.

Инструмент: Wireshark с профилями для ICS. Скачайте профиль «Industrial» с Wireshark wiki - он подсвечивает поля для Modbus, S7, DNP3, делает фильтры быстрее. Также полезно использовать NetworkMiner для извлечения файлов из трафика (например, если передавался файл конфигурации PLC).

2.3.3. Camera footage​

Это часто недооценивают, но физический доступ - самый вероятный вектор в OT. Если в помещении с HMI есть камеры видеонаблюдения, запросите записи за время инцидента. Вы можете обнаружить, что подозрительная активность совпадает с появлением постороннего человека в пультовой, или что оператор, который якобы работал в нерабочее время, вообще не заходил в помещение - значит, учётка была скомпрометирована удалённо.

В одном расследовании мы нашли, что несанкционированный доступ к HMI был совершён через TeamViewer (оставленный подрядчиком). Камеры показали, что в момент инцидента никого в помещении не было, но на мониторе HMI двигалась мышь. Это подтвердило удалённый доступ.

2.3.4. Что делать с evidence?​

Вся собранная информация должна быть задокументирована и сохранена в неизменном виде. Используйте хэширование (SHA-256) для всех скопированных файлов. Если вы планируете передавать материалы в правоохранительные органы или регуляторам (ФСТЭК, НКЦКИ), важно соблюсти цепочку хранения доказательств. Но в рамках внутреннего расследования достаточно просто сохранить всё в защищённом хранилище.

После завершения расследования вы должны ответить на вопросы:

• Каков вектор атаки? (компрометация учётки, физический доступ, удалённый доступ через третье лицо)
• Какие действия были совершены? (просмотр, изменение уставок, попытка распространения)
• Был ли нанесён ущерб? (физический, финансовый)
• Какие системы были затронуты?
• Почему детект не сработал раньше?

Ответы на эти вопросы лягут в основу раздела «Lessons learned».

---

3. Playbook 2: Compromised PLC​

PLC (Programmable Logic Controller) - это сердце автоматизации. Если злоумышленник получил контроль над PLC, он может творить что угодно: от изменения логики работы до полного вывода оборудования из строя. Самое страшное в этом сценарии - что вы можете не заметить компрометацию, пока не произойдёт физический инцидент. Вспомните Stuxnet: контроллеры показывали нормальные значения, но на самом деле центрифуги разгонялись до разрушения. Поэтому обнаружение компрометации PLC - это самая сложная и ответственная задача.

3.1. Detection: firmware integrity check failure, unexpected logic changes​

Как вы узнаете, что PLC скомпрометирован? В отличие от IT, где есть антивирусы и EDR, для PLC такие средства редкость. Некоторые современные PLC имеют встроенные функции целостности (например, проверка подписи прошивки у Siemens S7-1500), но большинство legacy-контроллеров (S7-300, Modicon M340 и т.д.) - это «чёрные ящики».

3.1.1. Firmware integrity check failure​

Если у вас есть средства для проверки целостности прошивки (например, Siemens Security Integrity Monitor или решения сторонних вендоров), вы можете настроить периодическую проверку хэша прошивки. Если хэш изменился - это 100% признак компрометации. Однако это требует, чтобы вы заранее сохранили эталонные образы прошивок.

Практический инструмент: Для Siemens S7-300/400 есть утилита SIMATIC S7 TeleService или S7-200 PC Access, но для автоматической проверки проще использовать Snort с правилом на обнаружение записи в блоки загрузки (S7comm write to loader memory). Но это косвенный метод.

В российских реалиях для мониторинга целостности PLC часто используют продукты типа «Кибербезопасность АСУ ТП» от «Код Безопасности» или Industrial Security Manager от Positive Technologies, которые умеют опрашивать контроллеры и сравнивать текущую конфигурацию с эталонной.

3.1.2. Unexpected logic changes​

Изменение логики работы PLC - это то, что можно обнаружить через мониторинг сетевого трафика. Когда инженер загружает новую программу в PLC, это происходит через промышленный протокол (S7comm, Modbus, Ethernet/IP). Если вы мониторите трафик, вы увидите:

• Массовую запись в блоки данных (DB) или память программ.
• Команды типа «Download» или «Stop/Start PLC».
• Если вы ведёте historian (исторические данные), вы можете увидеть, что значения уставок или параметров изменились в момент, когда не было легитимной сессии программирования.

Инструмент: Для автоматического обнаружения изменений в PLC я использую Zeek с пакетом icsnpp (Industrial Control Systems Network Protocol Parsers). Он может парсить S7comm и выдавать события при обнаружении записи в определенные блоки. Также можно использовать GRASSMARLIN для визуализации сетевых потоков и выявления новых соединений между инженерной станцией и PLC, которые раньше не наблюдались.

Пример правила Snort для S7comm:

alert tcp $HOME_NET any -> $PLC_NET 102 (msg:"S7comm Write to DB"; flow:to_server,established; content:"|03 00 00|"; within:3; content:"|32|"; distance:0; content:"|05|"; within:1; sid:1000001;)

Это правило детектирует запись в DB-блок (код функции 0x32 для Siemens). Но это очень грубо, лучше использовать готовые правила от Emerging Threats или собственные, адаптированные под ваши технологические процессы.

3.1.3. Аномальное поведение самого процесса​

Иногда первый признак компрометации PLC - это не техническое обнаружение, а оператор, который говорит: «Странно, насос сам включился, хотя я его не включал» или «Давление скачет, хотя регулятор должен держать». Это может быть вызвано как сбоем в логике (ошибка программиста), так и злым умыслом. Поэтому очень важно, чтобы операторы были обучены сообщать о любых аномалиях, а не списывать их на «глюки».

У нас был случай, когда оператор насосной станции заметил, что частота вращения насоса увеличивается сама собой, хотя задание оставалось неизменным. Мы начали расследование и обнаружили, что в PLC была внедрена дополнительная логика, которая при определенном значении уровня в резервуаре увеличивала частоту, игнорируя задание оператора. Это была старая «закладка» программиста, который хотел оптимизировать процесс, но не задокументировал её. А мы приняли её за атаку. Но лучше перебдеть.

3.2. Containment: switch to backup PLC, manual control if available​

Итак, вы подтвердили, что PLC скомпрометирован (или есть высокая степень подозрения). Что делать?

3.2.1. Переключение на резервный PLC​

Если у вас есть резервный контроллер в режиме «горячего» резерва (hot standby), переключитесь на него. Это наиболее безопасный способ. Но важно, чтобы резервный контроллер не был скомпрометирован тем же вектором. Поэтому перед переключением убедитесь, что резервный PLC не был подключён к той же сети, что и основной, или что его прошивка не была изменена.

Если резервный PLC в «холодном» резерве (хранится на складе), то вам придётся его прошить эталонным образом и только потом подключать. Это займёт время, и в этот период процесс должен быть переведён на ручное управление.

3.2.2. Ручное управление​

Если резервирования нет, и вы не можете доверять PLC, единственный безопасный способ - перевести процесс на ручное управление (manual mode). Это означает, что оператор физически (через кнопки на панели или через обходные линии) управляет исполнительными механизмами. Для этого на каждом критическом узле должны быть предусмотрены такие возможности (например, байпас для клапана, ручной пускатель насоса). Если их нет - это серьёзный недостаток проектирования.

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

3.2.3. Изоляция PLC на сетевом уровне​

Если вы не можете переключиться на резерв или ручное управление, но процесс позволяет работать с текущим PLC (например, он просто шлёт данные, но не управляет опасными механизмами), вы можете изолировать его на сетевом уровне:

• Заблокировать все входящие соединения, кроме разрешённых (например, только от HMI).
• Запретить запись в выходные регистры (read-only).
• Если PLC поддерживает, перевести его в режим «stop» (но это остановит выполнение программы, что может быть опасно).

3.3. Recovery: reflash from golden image, verification testing​

Восстановление PLC после компрометации - это не просто перезагрузка. Это гарантия того, что вредоносный код удалён, и контроллер работает с эталонной конфигурацией.

3.3.1. Golden image​

У вас должен быть заранее подготовленный «золотой образ» для каждого типа PLC: прошивка, конфигурация, программа (логика), параметры. Этот образ должен храниться в защищённом месте (офлайн, с подписью). Если его нет - вы не сможете гарантировать восстановление.

Практический совет: Создайте репозиторий образов прошивок и программ для всех PLC. Для Siemens это .s7p или .awl файлы, для Modicon - .stx или .xef, для Allen-Bradley - .l5x. Храните их в системе контроля версий (Git) с хэшами. Периодически проверяйте, что образ соответствует тому, что загружено в PLC (если есть возможность безопасного сравнения).

3.3.2. Процедура перепрошивки​

Перепрошивка PLC должна проводиться по строгой процедуре, особенно если процесс находится в работе (даже если на ручном управлении). Я обычно делаю так:

1. Останавливаю PLC (если это безопасно) или перевожу в режим программирования, если процесс позволяет.
2. Загружаю эталонную прошивку через инженерную станцию, которая гарантированно чиста (лучше использовать отдельный ноутбук, не подключённый к сети).
3. Загружаю эталонную программу и параметры.
4. Проверяю целостность: после загрузки делаю дамп прошивки и сравниваю хэш с эталоном.
5. Провожу функциональное тестирование в режиме симуляции (если возможно) или на непроизводственном оборудовании. Для этого желательно иметь стенд-копию PLC с теми же входными/выходными сигналами.
6. Только после успешного тестирования подключаю PLC обратно в сеть и перевожу процесс под его управление.

3.3.3. Что делать, если нет возможности остановить процесс?​

В критических непрерывных процессах (нефтепереработка, энергетика) остановка для перепрошивки может быть невозможна. В таких случаях используется стратегия «поэтапного восстановления»:

• Замена PLC на резервный (если есть) с последующим восстановлением основного в «офлайне».
• Использование «горячего» резервирования, когда вы перепрошиваете один PLC, а второй держит процесс.
• Если процесс позволяет, дождитесь плановой остановки (например, ремонтную кампанию) и только тогда выполняйте восстановление. Всё это время контроллер должен быть изолирован и находиться под усиленным мониторингом.

---

4. Playbook 3: Ransomware in OT​

Ransomware в OT - это уже не гипотетическая угроза. Кейсы Colonial Pipeline, Norsk Hydro, и, к сожалению, несколько российских предприятий (о которых не принято говорить публично) показали, что шифровальщики могут проникнуть в OT-сеть через плохо сегментированную IT-инфраструктуру. И когда экран HMI блокируется с требованием биткоинов, а насосы продолжают качать нефть - это стресс для всех.

Особенность ransomware в OT в том, что оно может зашифровать не только файлы на HMI, но и (в редких случаях) прошить PLC, но чаще всего оно просто блокирует интерфейс оператора. Однако даже это может привести к катастрофе, если оператор не видит параметров и не может управлять.

4.1. Containment: enforce air-gap, isolate OT from IT immediately​

Как только вы обнаружили ransomware (или подозрение на него) в OT-сети, ваша главная задача - не дать ему распространиться дальше и сохранить управляемость процесса. Время здесь измеряется минутами.

4.1.1. Разрыв связей между IT и OT​

В большинстве случаев ransomware попадает в OT из IT-сети через открытые RDP-порты, общие файловые ресурсы, или через инженерные станции, которые имеют доступ к интернету. Первое, что вы должны сделать - разорвать все логические и физические связи между OT и IT. Это значит:

• Отключить все межсетевые экраны (firewalls) между IT и OT (или заблокировать правила на них).
• Отключить каналы удалённого доступа (VPN, RDP, TeamViewer).
• Если есть DMZ с историческими данными (historian), который передаёт данные в IT, - временно остановить передачу (или перевести historian в read-only, чтобы он не мог быть заражён из IT).

Важно: не всегда нужно физически отсоединять кабели - это может нарушить работу систем мониторинга. Но если вы уверены, что трафик между IT и OT не критичен для управления процессом, лучше физически разъединить.

4.1.2. Изоляция заражённых устройств в OT​

Если вы точно знаете, какие устройства заражены (например, HMI показывает вымогательское сообщение), изолируйте их на сетевом уровне:

• На коммутаторе отключите порт, к которому подключено заражённое устройство.
• Если это невозможно (устройство критически важно для управления), переведите управление на резервное устройство, а заражённое отключите.

В одном из инцидентов ransomware зашифровал исторический сервер (historian), который собирал данные со всех PLC, но не влиял на управление. Мы просто отключили historian от сети, а управление продолжалось через HMI. Это дало нам время разобраться.

4.1.3. Если заражены PLC​

Если ransomware каким-то образом зашифровал или повредил прошивку PLC (например, через S7-команды), ситуация становится критической. В этом случае вы должны максимально быстро перевести процесс на ручное управление или использовать резервные PLC, если они есть. Если резерва нет, и процесс критический - возможно, придётся останавливать производство. Это решение принимает главный инженер.

4.2. Assessment: which OT systems affected, is process running safely?​

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

4.2.1. Инвентаризация затронутых систем​

Вы должны оперативно выяснить:

• Какие HMI, инженерные станции, серверы затронуты? (шифрование файлов, блокировка, нестабильная работа)
• Затронуты ли PLC? (нужно проверить работу каждого контроллера, сравнивая текущие значения с ожидаемыми, проверить возможность записи)
• Затронуты ли сетевые устройства? (коммутаторы, маршрутизаторы - могут ли они быть перепрошиты)
• Какие данные были зашифрованы? (исторические данные, конфигурации, архивы)

Инструмент: Если у вас есть система управления активами (Asset Management) в OT, это сильно упрощает задачу. Если нет - вам придётся вручную проверять каждое устройство. Для этого используйте сканеры сетевых портов (например, nmap) из доверенной точки, но будьте осторожны - сканирование может вызвать сбои в работе legacy-устройств. Лучше использовать пассивный мониторинг (NetFlow, трафик) для определения доступности устройств.

4.2.2. Оценка безопасности процесса​

Самое важное: процесс идёт? Идёт ли он в безопасных пределах? Операторы могут управлять? Если HMI зашифрованы, но PLC продолжают работать по последним уставкам, и процесс стабилен - это временно приемлемо. Но если нет возможности контролировать и изменять параметры, нужно либо восстанавливать управление, либо останавливать процесс.

Мы используем Safety Assessment Checklist:

• Все критические параметры (давление, температура, уровень) находятся в пределах нормы?
• Есть ли возможность аварийной остановки (ESD) независимо от сети?
• Работают ли системы противоаварийной защиты (SIS)?
• Может ли оператор связаться с диспетчером по резервным каналам (радиосвязь, телефон)?
• Есть ли физический доступ к исполнительным механизмам для ручного управления?

Если на какой-то вопрос ответ «нет» - это повод для немедленной остановки.

4.3. Recovery: restore from offline backups, phased reconnection​

Восстановление после ransomware в OT - это длительный процесс, который требует тщательного планирования. Нельзя просто взять и восстановить из бэкапа все системы, потому что вы можете повторно заразиться, если источник остался в сети.

4.3.1. Восстановление из офлайн-бэкапов​

У вас должны быть офлайн-бэкапы всех критических систем АСУ ТП: HMI, инженерных станций, серверов historian, конфигураций PLC. Эти бэкапы хранятся на физически изолированных носителях (например, жёстких дисках в сейфе) и периодически проверяются на работоспособность.

Порядок восстановления:

1. Форматирование и переустановка ОС на всех заражённых устройствах (не полагайтесь на удаление вируса - переустанавливайте с нуля).
2. Установка необходимого ПО (SCADA, драйверы) с эталонных установочных дисков.
3. Восстановление конфигураций из бэкапов (проектов WinCC, iFIX, и т.д.).
4. Восстановление прошивок PLC из эталонных образов (если они были затронуты).
5. Проверка целостности - сравнение хэшей файлов с эталонами.

4.3.2. Поэтапное подключение (phased reconnection)​

После восстановления не подключайте все устройства сразу. Это может привести к повторному заражению, если какой-то узел остался скомпрометирован. Вместо этого:

1. Создайте «чистую» зону - выделите отдельный сегмент сети, изолированный от всего, где будут восстановленные системы.
2. Подключайте устройства по одному и проверяйте их работу. Начинайте с самых критичных (например, главный HMI), затем добавляйте второстепенные.
3. Мониторьте трафик на предмет аномалий. Если вы видите попытки распространения (SMB-трафик, попытки подключения к другим устройствам) - устройство всё ещё заражено.
4. Восстанавливайте связь с IT-сетью только после полной очистки OT и после того, как вы убедились, что IT-сеть тоже чиста (иначе ransomware придёт снова).

---

5. Compliance и Post-Incident​

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

В России субъекты КИИ обязаны уведомлять НКЦКИ (Национальный координационный центр по компьютерным инцидентам) об инцидентах. Игнорирование этого требования может привести к административным штрафам (для юрлиц - до 1 млн рублей по ст. 13.12 КоАП РФ), а в случае тяжких последствий - и к уголовной ответственности. Поэтому эта часть - не бюрократия, а обязательство.

5.1. ГосСОПКА: уведомление НКЦКИ - 24 часа для значимых инцидентов​

ФСБ России через ГосСОПКА (Государственную систему обнаружения, предупреждения и ликвидации последствий компьютерных атак) собирает информацию об инцидентах на КИИ. Порядок уведомления установлен приказом ФСБ № 282 (и последующими изменениями).

5.1.1. Сроки​

Срок уведомления - 24 часа с момента обнаружения инцидента. Это очень жёстко. В крупных компаниях есть выделенные сотрудники (обычно из отдела информационной безопасности), которые имеют доступ к личному кабинету ГосСОПКА (

Ссылка скрыта от гостей

). Уведомление подаётся в электронном виде через этот кабинет.

Что делать, если вы не успели или не знали? Лучше уведомить с опозданием, чем не уведомить вообще, но это может быть рассмотрено как нарушение. Поэтому процедура уведомления должна быть встроена в ваш плейбук: как только инцидент классифицирован как значимый, запускается таймер 24 часа.

5.1.2. Формат уведомления​

В уведомлении нужно указать:

• Категорию объекта КИИ (1, 2 или 3).
• Дату и время обнаружения инцидента.
• Описание инцидента (что произошло, какие системы затронуты, есть ли последствия).
• Предполагаемый вектор атаки (если известен).
• Меры, принятые для локализации.
• Контактные данные ответственного лица.

Форма есть в личном кабинете. Важно: не нужно писать «мы подозреваем», если есть факты. Пишите по факту.

5.2. ФСТЭК: отчётность для субъектов КИИ категории 1-3​

Если ваш объект КИИ имеет категорию 1, 2 или 3 (а большинство промышленных объектов имеют), вы также должны отчитываться перед ФСТЭК России. Отчётность регламентируется приказами ФСТЭК № 239 (о порядке ведения реестра) и № 31 (о реагировании на инциденты).

5.2.1. Отчёт о реагировании на инцидент​

В течение 30 дней после ликвидации инцидента вы должны направить в ФСТЭК (территориальный орган) отчёт, который включает:

• Описание инцидента (дата, время, причины, последствия).
• Меры по локализации и ликвидации.
• Результаты расследования (вектор атаки, уязвимости, которые были использованы).
• Меры по предотвращению подобных инцидентов в будущем (обновление плейбуков, технические меры).
• Акты проверки целостности систем (если применимо).

Этот отчёт должен быть подписан руководителем организации или уполномоченным лицом. Требования к отчёту могут отличаться в зависимости от категории объекта.

5.2.2. Изменения в реестре КИИ​

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

5.3. Lessons learned​

Вся работа по реагированию на инцидент была бы бессмысленной, если бы мы не сделали выводов и не улучшили свои процессы. «Lessons learned» - это не просто галочка, а возможность стать сильнее.

5.3.1. Post-incident review (PIR)​

Через 1-2 недели после инцидента, когда эмоции улеглись, нужно собрать всех участников команды (включая технологов, инженеров, руководство) и провести разбор полётов. Я провожу PIR по следующей структуре:

1. Хронология событий - минута за минутой, от обнаружения до полного восстановления.
2. Что сработало хорошо? - выделите сильные стороны. Например, быстрое переключение на резервный HMI, правильное решение не отключать PLC, эффективная коммуникация с технологами.
3. Что сработало плохо? - ошибки, задержки, нехватка информации, проблемы с доступом. Например, долго искали контакты вендора, не было под рукой эталонного образа прошивки, отсутствовала матрица safety-последствий.
4. Причина инцидента (корневая) - не техническая, а организационная. Почему это произошло? Не было сегментации? Не было мониторинга? Слабые пароли?
5. Меры по улучшению - конкретные задачи с назначенными ответственными и сроками.
   

5.3.2. Tabletop exercises (учения на бумаге)​

Плейбуки бесполезны, если их не тренировать. Раз в квартал проводите командно-штабные учения (tabletop exercises) - это когда вы собираетесь в комнате и проигрываете сценарий инцидента, имитируя действия по плейбуку. Это не требует остановки производства, но позволяет выявить слабые места в коммуникации и процедурах.

Как провести:

• Выберите сценарий (например, «компрометация HMI»).
• Назначьте ведущего, который будет сообщать «вводные» (например, «вы получили алерт о необычной команде на PLC»).
• Участники должны действовать по плейбуку, озвучивая решения (например, «я, как IR Lead, принимаю решение заблокировать учётку и связаться с технологом»).
• Ведущий может вводить неожиданные обстоятельства («технолог не отвечает», «процесс не позволяет переключиться на резерв»), чтобы проверить гибкость.
• После учения - разбор: что было сделано по плану, что не соответствовало, что нужно изменить в плейбуке.

Такие учения сильно повышают готовность команды. В реальном инциденте люди действуют быстрее и увереннее, если уже «проиграли» подобное.