Понедельник, 9:15 утра. SOC фиксирует аномальный всплеск Modbus-запросов с function code 0x10 (Write Multiple Registers) на участке, где штатный цикл опроса работает через FC 0x03 (Read Holding Registers). Через 12 минут оператор на HMI видит изменение уставок давления в реакторе. Антивирус на инженерной станции молчит - команды отправлены через легитимный TIA Portal. Но инженер, чьи учётные данные использовались, в отпуске уже неделю.
По данным IBM X-Force, 70% атак в 2024 году затронули критическую инфраструктуру. Mandiant M-Trends фиксирует медианное время обнаружения злоумышленника - 11 дней. В OT-среде за 11 дней можно переписать всю логику управления технологическим процессом. Ни один IT-ориентированный playbook к этому не готов.
Чем реагирование на инциденты ICS SCADA отличается от IT
Реагирование на инциденты в промышленных сетях строится на другой модели приоритетов. В IT классика - CIA (Confidentiality, Integrity, Availability). В OT - Safety, Availability, Integrity, и только потом Confidentiality. Не теоретическая разница - она определяет каждое решение во время инцидента. Подробнее - в нашем статье о кибербезопасность критической инфраструктуры.Протоколы без аутентификации
Modbus TCP родом из 1979 года. Встроенной аутентификации нет. Любой узел в сегменте, способный отправить TCP-пакет на порт 502, может записать произвольные значения в регистры PLC. FC 0x05 (Write Single Coil) переключает дискретный выход - клапан, насос, размыкатель. FC 0x06 (Write Single Register) меняет числовое значение - уставку температуры, скорость привода. EDR и антивирус эти команды не видят: легитимное TCP-соединение между легитимными хостами, чего ещё надо.DNP3 в энергетике формально поддерживает Secure Authentication (SA). На практике большинство инсталляций работают без него - включение SA требует перепрошивки RTU, а это плановый останов участка. По документам - можно включить. На практике - никто не включает.
Почему стандартные EDR и SIEM слепы в SCADA-среде
На PLC Siemens S7-300/400 нет операционной системы в привычном понимании - агент CrowdStrike Falcon или SentinelOne туда физически не встанет. Allen-Bradley ControlLogix работает на проприетарной ОС, сторонние процессы не поддерживает. RTU на базе Modbus RTU (RS-485) - микроконтроллер с прошивкой в десятки килобайт. Какой уж тут EDR.SIEM получает события с IT-сегмента: логи Windows, NetFlow, DNS-запросы. Трафик между HMI и PLC на уровне 2 Purdue-модели в корпоративный SIEM не попадает, если не настроен специализированный сбор - через Zeek с плагинами для промышленных протоколов, Nozomi Networks или Claroty. Без этого OT-сегмент для SOC - чёрный ящик.
Ограничения патчинга
По данным IBM X-Force, среднее время между публикацией CVE и устранением в организациях - 29 месяцев. Для OT эта цифра ещё хуже. На многих производствах PLC работают на firmware десяти-пятнадцатилетней давности. Обновление прошивки контроллера Schneider Modicon M340 - это остановка управляемого участка, перевод на ручное управление, верификация после перезагрузки. Плановое окно - раз в год при капремонте. Раз в год, Карл.Форензика PLC и RTU в промышленных системах
Форензика PLC в промышленных системах - совсем не то же самое, что работа с Windows-хостом. Нельзя снять образ диска - диска нет. Нельзя запустить Volatility - формат памяти проприетарный. Каждый шаг сбора артефактов несёт риск нарушения технологического процесса.Что собирать и в каком порядке
Порядок сбора volatile данных в OT - от наименее инвазивных действий к наиболее:- Сетевой трафик (пассивный захват). Зеркалирование порта на управляемом коммутаторе уровня 2 (SPAN/mirror port) и запись pcap через
tcpdumpили Zeek. PLC это не затрагивает, дополнительной нагрузки на промышленную сеть не создаёт. Начинаем всегда с этого. - Логи historian-сервера. OSIsoft PI, Wonderware InSQL, GE Proficy Historian хранят исторические значения тегов (process values) с метками времени. Изменение уставки, переключение режима, аварийный останов - всё отражается в historian. Для установления timeline инцидента это золото.
- Состояние PLC-программы. Выгрузка текущей программы (ladder logic, structured text, FBD) через инженерный софт - TIA Portal для Siemens, RSLogix/Studio 5000 для Allen-Bradley, Unity Pro для Schneider. Дальше - сравнение с эталонной копией из системы управления изменениями.
- Конфигурация сетевого оборудования. Таблицы MAC-адресов, ARP-кеш, правила ACL на промышленных коммутаторах (Hirschmann, Moxa, Cisco IE). Здесь можно обнаружить несанкционированные устройства, которых быть не должно.
Верификация логики PLC
Ключевой и уникальный для OT шаг - проверка целостности управляющей программы. Атакующий, получивший доступ к инженерной станции, может модифицировать логику PLC так, что оператор на HMI не увидит изменений - значения на экране будут подменяться (техника Transmitted Data Manipulation, T1565.002, Impact). Именно так работал TRITON - малварь модифицировала логику контроллера безопасности Schneider Triconex, при этом инженерное ПО показывало «чистую» программу. Красивый фантик, а внутри - перепрошитая логика.Проверка - побайтовое сравнение выгруженной программы с эталоном. Для Siemens S7 это сравнение блоков OB, FC, FB, DB с сохранёнными копиями. Для Allen-Bradley - сравнение .ACD-файлов через diff-утилиту RSLogix. Если эталонных копий нет (а их нет чаще, чем хотелось бы) - восстановить факт модификации можно по записям historian-сервера, проанализировав аномальные отклонения process values от baseline.
Анализ сетевого трафика промышленных протоколов
Разбор pcap с промышленным трафиком - основной метод форензики RTU и промышленных контроллеров, которые не поддерживают локальный сбор артефактов. Zeek (ранее Bro) с модулями для Modbus, DNP3 и S7comm даёт структурированные логи каждой транзакции.Фильтр в
tshark для выявления write-команд Modbus, которых не должно быть в штатном режиме:
Bash:
tshark -r ot_capture.pcap -Y "modbus.func_code == 5 || modbus.func_code == 6 || modbus.func_code == 15 || modbus.func_code == 16" \
-T fields -e frame.time -e ip.src -e ip.dst -e modbus.func_code -e modbus.reference_numDetection-чеклист: правила корреляции для OT SOC
Реагирование на инциденты в OT-среде начинается задолго до самого инцидента - с построения baseline и правил корреляции. Ниже - чеклист, который можно адаптировать под конкретный SIEM-стек.Базовые правила для Modbus TCP
| Правило | Логика срабатывания | MITRE ATT&CK |
|---|---|---|
| Write с неизвестного IP | src_ip NOT IN [engineering_station_list] AND modbus.func_code IN [5,6,15,16] | T1565.002 (Transmitted Data Manipulation) |
| Массовое чтение регистров | modbus.func_code == 3 AND count > baseline_threshold за 60 сек | T1005 (Data from Local System) |
| Обращение к нестандартному Unit ID | modbus.unit_id NOT IN [known_plc_ids] | T1040 (Network Sniffing) / разведка |
| Доступ по дефолтным кредам к HMI | Логин admin/admin, operator/operator на VNC/RDP к HMI | T1078.001 (Default Accounts) |
| Изменение firmware PLC | Upload-команда через S7comm или EtherNet/IP | T1109 (Component Firmware) |
| Отключение logging на коммутаторе | Изменение syslog-конфигурации на Hirschmann/Moxa | T1562.001 (Disable or Modify Tools) |
Построение baseline для промышленных протоколов
Baseline в OT - не «средний трафик за неделю». Промышленный процесс цикличен: утренний запуск линии, дневной режим, ночной простой. Baseline строится по нескольким параметрам:- Список пар «инициатор - PLC» с привязкой к function codes. HMI опрашивает через FC 0x03 каждые 500 мс - это норма. Инженерная станция подключается для программирования раз в квартал.
- Диапазоны значений process variables. Температура в реакторе 180-220°C, давление 2.5-3.2 бар. Выход за диапазон без команды оператора - аномалия.
- Расписание регламентных работ. Каждое подключение инженерной станции к PLC вне графика - событие для расследования.
Сценарий: киберинцидент на промышленном предприятии через скомпрометированную инженерную станцию
Типичный kill chain атаки на OT-сегмент с привязкой к TTPs - именно так выглядит большинство инцидентов, которые я видел в расследованиях.Kill chain от DMZ до PLC
Шаг 1. Initial Access - IT-сегмент. Фишинговое письмо с вложением, направленное инженеру АСУ ТП. По данным Verizon DBIR 2025, фишинг - вектор initial access в 36% инцидентов. Малварь закрепляется на рабочей станции инженера в корпоративной сети. Банально, но работает.Шаг 2. Lateral Movement - переход в DMZ. Атакующий эксплуатирует уязвимость в jump-сервере между IT и OT (T1210, Exploitation of Remote Services). По CrowdStrike, среднее время lateral movement после initial access - 62 минуты. В OT-контексте jump-сервер часто единственная точка перехода, и его компрометация открывает доступ ко всему промышленному сегменту.
Шаг 3. Credential Access в OT. На инженерной станции в OT-сегменте атакующий находит сохранённые пароли к TIA Portal, RSLogix, VNC-сессии к HMI (T1078.001, Default Accounts). Учётные данные к PLC часто валяются в проектных файлах в открытом виде или защищены дефолтными паролями.
admin/admin - не шутка, а реальность на половине объектов.Шаг 4. Impact - модификация логики. Атакующий использует легитимный инженерный софт для загрузки модифицированной программы в PLC. С точки зрения сетевого трафика - стандартная операция программирования. С точки зрения процесса - изменение уставок, отключение блокировок, подмена значений на HMI (T1565.002).
Где детектировать каждый шаг
Не каждый шаг этой цепочки можно обнаружить в OT - и Blue Team должна это понимать. Шаги 1-2 детектируются стандартными IT-средствами: EDR (CrowdStrike Falcon, SentinelOne) на рабочих станциях, SIEM-правила на аномальные подключения к jump-серверу. Шаг 3 требует аудита логонов на инженерных станциях (Windows Security Event Log, Event ID 4624/4625) и мониторинга запуска инженерного ПО вне графика. Шаг 4 - только через анализ OT-трафика: обнаружение write/upload команд в промышленных протоколах.Именно поэтому инженерная станция - самый критический актив. Это единственный хост в OT-сегменте, на который можно установить EDR-агент и с которого собирать логи в SIEM. Компрометация инженерной станции = слепота SOC в OT.
Восстановление производства после кибератаки без остановки линии
Количество производств, где все шесть пунктов закрыты, - единицы. Обычно есть пункт 1 (и то не всегда актуальный), а остальное - «как-нибудь потом». Именно это «потом» превращает управляемый инцидент в катастрофу.
Я участвовал в расследованиях, где отсутствие эталонных копий PLC-программ превращало четырёхчасовое восстановление в трёхнедельный проект обратной разработки ladder logic из дампа памяти контроллера. Три недели инженеры восстанавливали логику, которую можно было загрузить за 15 минут - если бы копия лежала в сейфе.
По Mandiant M-Trends, в 57% случаев организации узнают об инциденте от внешней стороны. В OT это значит, что к моменту обнаружения атакующий мог модифицировать логику десятков контроллеров. Без эталонов вы не знаете, какие из них «чистые».
Моя позиция после нескольких лет работы с OT-инцидентами: главная проблема - не отсутствие средств детектирования, а отсутствие базовых артефактов для расследования. Пассивный мониторинг Modbus-трафика через Zeek разворачивается за день. Sigma-правило на write-команды с неизвестного IP - 20 строк конфигурации. Но если нет baseline, нет эталонных программ, нет historian с достаточной глубиной хранения - детектировать нечего и восстанавливать не из чего.
NIST CSF 2.0 описывает это в категории DE.AE-01: «A baseline of network operations and expected data flows for users and systems is established and managed». Формулировка простая. Реализация на промышленном предприятии с 200 PLC и 5000 тегов - работа на месяцы. Но именно эта работа определяет, будет ли ваш incident response занимать 4 часа или 4 недели.
Проверьте свой чеклист forensic readiness прямо сейчас. Если из шести пунктов закрыты два - вы в большинстве. Если ноль - у вас не incident response plan, а надежда на удачу. Если выстраиваете мониторинг OT-сегмента или подбираете корреляционные правила под промышленные протоколы - на codeby.net коллеги обсуждают специфику интеграции Modbus/DNP3-трафика в корпоративные SIEM-стеки в тематическом треде.
