На risk assessment подстанции 110 кВ мы нашли historian-сервер, маршрутизируемый напрямую в корпоративную сеть. VLAN существовали, ACL между Level 3 и Level 4 по Purdue - ни одного. CVSS единственной известной уязвимости на этом сервере показывал 6.5, Medium. В IT-контексте - обоснованный приоритет ниже критического, можно подождать окна обслуживания. В OT-контексте через этот historian атакующий получал прямой канал до RTU, управляющих коммутационным оборудованием. Физический импакт - обесточивание района на 40 тысяч жителей и риск повреждения силового оборудования.
Между формальной оценкой Medium и реальным сценарием каскадного отключения - методологический разрыв, который стандартные IT-фреймворки не закрывают. Эта статья - о том, как проводить оценку киберрисков критической инфраструктуры так, чтобы результат отражал реальные угрозы, а не был ритуалом для аудитора.
Почему IT-подходы к оценке киберрисков ломаются в OT-средах
В IT-безопасности приоритет - конфиденциальность (CIA triad с акцентом на C). В OT первичны доступность и целостность физического процесса. Запись мусорного значения в holding register PLC через Modbus FC16 (Write Multiple Registers) опаснее утечки терабайта корпоративных документов. Атакующий, отправивший FC5 (Write Single Coil) на дискретный выход контроллера, физически переключает состояние реле - открывает задвижку, отключает насос, меняет уставку защиты. Тут не данные утекают - тут железо двигается. Подробнее - в нашем материале про кибербезопасность критической инфраструктуры.
Modbus TCP, DNP3, PROFINET, EtherNet/IP - протоколы, спроектированные для надёжности и детерминированности, не для безопасности. Modbus не имеет аутентификации: любой узел с сетевым доступом к порту 502 может отправить FC16 и перезаписать регистры PLC. DNP3 Secure Authentication существует, но на практике встречается редко - большинство RTU в эксплуатации его просто не поддерживают.
Для пентестера, привыкшего к IT-инфраструктуре, OT-среда выглядит как сеть без единого средства защиты. В каком-то смысле так и есть: CrowdStrike Falcon, SentinelOne, Elastic - ни один из этих EDR-агентов не устанавливается на PLC Siemens S7-1200 или Allen-Bradley ControlLogix. SIEM получает логи с верхних уровней Purdue (Level 3-5), а трафик между HMI и контроллером на Level 1-2 чаще всего остаётся невидимым. В корпоративной сети endpoint без EDR - нонсенс. В OT это норма.
IT-команда привыкла к регулярному патчингу. В OT обновление firmware на Safety Instrumented System (SIS) может потребовать полной остановки технологического процесса на несколько дней. На реальных объектах встречаются контроллеры с firmware десятилетней давности - не потому что никто не знает об уязвимостях, а потому что остановка стоит десятки миллионов рублей и требует согласования с технологами за полгода. Попробуйте объяснить это IT-директору, который привык к ежемесячному Patch Tuesday.
Три реальных инцидента показывают, как эти различия приводят к катастрофам.
Водоочистная станция Oldsmar, Флорида (февраль 2021): по официальной версии FBI/CISA (AA21-042A), неизвестный получил доступ через TeamViewer с общим паролем на системе под Windows 7 и попытался увеличить концентрацию гидроксида натрия до потенциально летальных уровней. На объекте не было ни сегментации OT-сети, ни мониторинга промышленных протоколов. Оператор заметил движение курсора на экране - и это стало единственным средством детекции. (Примечание: альтернативные расследования KrebsOnSecurity и Reuters (2023) указывают на возможную операционную ошибку, а не внешнее вторжение - атрибуция остаётся спорной.)
Industroyer2 (апрель 2022): малварь, обнаруженная ESET и CERT-UA (alert #4435), спроектированная для управления выключателями подстанций через IEC-101/104, была нацелена на конкретную украинскую энергокомпанию. Атаку нейтрализовали до impact-стадии, но инцидент показал, насколько сложно восстановить baseline OT security posture после компрометации.
Colonial Pipeline (2021): DarkSide ransomware проник через legacy VPN-аккаунт без MFA, реквизиты которого утекли ранее. Атака поразила IT-биллинг, а не OT; остановка трубопровода была превентивным решением компании из-за невозможности выставлять счета. То есть трубопровод остановили не хакеры - его остановили бухгалтеры.
Все три случая объединяет одно: формальный risk assessment не отразил реальные векторы атак. Инвентаризация была неполной, threat model не учитывала OT-специфику, а impact-оценка строилась по IT-метрикам.
Фреймворки кибербезопасности OT и промышленных систем
NIST CSF 2.0 и NIST SP 800-82: промышленная безопасность OT
NIST CSF 2.0, выпущенный в феврале 2024 года, впервые расширил охват за пределы критической инфраструктуры и добавил шестую функцию - Govern (GV). Для управления киберрисками промышленных систем это существенно: Govern формализует пересечение операционного и киберриска - тот самый диалог, который исторически буксовал, потому что инженерные и ИБ-команды говорят на разных языках.Шесть функций CSF 2.0 в промышленном контексте:
- Govern (GV) - OT-специфичная политика кибербезопасности с учётом требований доступности процесса. По CSF 2.0 (GV.OC-01), миссия организации должна информировать управление киберрисками. Для OT это значит: допустимый уровень риска определяется через физические последствия, а не через стоимость данных.
- Identify (ID) - инвентаризация OT-активов (ID.AM-01). В IT стартовая точка - Active Directory. В OT-сети могут сидеть устройства, которые никогда не были документированы: legacy RTU, установленные десять лет назад, инженерные станции на Windows XP.
- Protect (PR) - управление идентификацией (PR.AA-01). В OT это борьба с shared accounts на инженерных станциях, внедрение MFA для удалённого доступа и jump-серверы в DMZ между IT и OT.
- Detect (DE) - baseline сетевых операций (DE.AE-01) для промышленных протоколов. Аномалия в OT - не массовый login fail, а незнакомый function code в Modbus-трафике или изменение периодичности polling.
- Respond (RS) - incident response (RS.AN-01) в OT отличается принципиально: изолировать заражённый контроллер можно, но при этом может остановиться физический процесс. Выбор между "потерять контроллер" и "потерять процесс" - нетривиальный.
- Recover (RC) - восстановление (RC.CO-01) включает возвращение к корректному состоянию физического процесса, а не только данных.
IEC 62443: зоны, кондуиты и оценка рисков
Где NIST CSF даёт организационную структуру, IEC 62443 спускается на уровень конкретной архитектуры. Ключевая концепция - зоны и кондуиты:- Зона - группа активов с одинаковым Security Level (SL). Каждая зона имеет SL от 1 (базовая защита от случайных нарушений) до 4 (защита от государственных акторов с неограниченными ресурсами).
- Кондуит - канал связи между зонами с контролируемым трафиком.
| Фреймворк | Фокус | Сильные стороны для OT | Ограничения |
|---|---|---|---|
| NIST CSF 2.0 | Организационный риск-менеджмент | Govern-функция, привязка к бизнес-миссии | Не задаёт конкретную архитектуру OT-сети |
| NIST SP 800-82 | Безопасность ICS | Детальные рекомендации по сегментации, учёт OT-ограничений | US-контекст, обновляется реже |
| IEC 62443 | Промышленная автоматизация | Зоны и кондуиты, Security Levels, lifecycle | Сложность внедрения, требует зрелого процесса |
| NERC CIP | Электроэнергетика | Обязательный для bulk electric system | Только электроэнергетика |
На реальных проектах оценки рисков используется комбинация: NIST CSF 2.0 как организационный фреймворк кибербезопасности OT, IEC 62443 для архитектуры и зонирования, NIST SP 800-82 для детализации контролей. Привязка к российской нормативке (ФЗ-187 "О безопасности КИИ", приказы ФСТЭК 235/239) добавляется поверх - но сам по себе compliance-подход без OT-специфичной модели угроз порождает бумажную безопасность. Категорию КИИ присвоили, галочку поставили, а historian торчит в корпоративную сеть без единого ACL.
Пошаговая методология оценки рисков промышленного объекта
Asset inventory в изолированной OT-сети
Оценка киберрисков критической инфраструктуры начинается с инвентаризации - и именно здесь большинство проектов спотыкается. В IT можно запуститьnmap и получить картину за часы. В OT активное сканирование способно вызвать fault state на PLC - контроллеры серий Siemens S7-300/400 могут переходить в STOP при активном S7comm-опросе или fuzzing промышленных протоколов (Digital Bond Project Basecamp, ICS-CERT ICSA-15-202-01). Положили контроллер сканером - получили остановку процесса. Не лучший способ начать проект.Решение - пассивный мониторинг трафика. Инструменты класса Claroty, Nozomi Networks, Dragos Platform подключаются к SPAN-порту коммутатора и анализируют трафик без отправки единого пакета в сеть. Они разбирают промышленные протоколы (Modbus, DNP3, S7comm, EtherNet/IP) и строят карту активов с firmware-версиями и communication patterns.
В одном задокументированном кейсе (Shieldworkz, 2024) крупная североамериканская энергокомпания обнаружила более 2 400 ранее неучтённых OT-активов при первом пассивном сканировании. Две с половиной тысячи устройств, которых не было ни в одной записи CMDB. Большинство сидели в операционной сети и молча работали годами.
Требования к окружению для пассивного мониторинга:
- SPAN/mirror-порт на managed-коммутаторе OT-сегмента
- Сервер/ноутбук: минимум 16 ГБ RAM, 4 CPU cores (захват на скорости 1 Gbps)
- Wireshark с диссекторами промышленных протоколов или специализированный OT-инструмент
- Согласование с OT-инженерами: точки подключения, время захвата, технологический регламент
Bash:
# Захват OT-трафика на SPAN-порту
tcpdump -i eth0 -w ot_capture.pcap port 502 or port 20000 or port 44818
# port 502 = Modbus TCP
# port 20000 = DNP3
# port 44818 = EtherNet/IP (CIP)modbus покажет Unit ID каждого slave-устройства, function code и данные регистров. Это даёт стартовую карту: кто с кем общается, по какому протоколу, какие операции выполняются. Уже на этом этапе часто всплывают сюрпризы - устройства, которые общаются с тем, с чем общаться не должны.Моделирование угроз и attack path analysis
После инвентаризации строится threat model. Для OT-среды работает модифицированный STRIDE, где каждая категория переосмысливается через физический процесс:- Spoofing - подмена команд контроллеру (атакующий отправляет легитимный function code от имени SCADA)
- Tampering - изменение уставок, логики PLC, калибровки датчиков
- Repudiation - логирование часто отсутствует на Level 1-2 (что произошло - никто не знает)
- Information Disclosure - утечка engineering diagrams, relay settings (по данным BigID, эта информация часто хранится на незащищённых файловых шарах вне контура OT)
- Denial of Service - остановка процесса через переполнение буфера контроллера
- Elevation of Privilege - из корпоративной сети (Level 4-5) в OT (Level 1-3) через скомпрометированный historian
- Reconnaissance: Vulnerability Scanning (T1595.002) - обнаружение HMI-интерфейсов и SCADA-порталов на периметре
- Initial Access: Exploit Public-Facing Application (T1190) - эксплуатация web-интерфейса HMI, или External Remote Services (T1133) - VPN/RDP до инженерной станции, или Valid Accounts (T1078) - учётные данные по умолчанию на shared accounts
- Lateral Movement: из IT-сети через historian или jump-server в OT-сегмент
- Impact: Service Stop (T1489) - остановка критических сервисов, Data Destruction (T1485) - уничтожение конфигураций PLC, Data Encrypted for Impact (T1486) - ransomware на Level 3, Impair Defenses (T1685) - отключение логирования
Отдельный вектор, который часто пропускают: компрометация через легитимную инженерную станцию. Инженер подключает ноутбук с Step7/TIA Portal к сети Level 2 для обновления проекта PLC. Ноутбук скомпрометирован через фишинг или вредоносный USB. Из инженерной среды атакующий получает прямой доступ к контроллерам - со всеми правами на запись проекта, изменение логики, перезагрузку PLC. CVSS отдельной уязвимости этот сценарий не покрывает: атака использует легитимные функции, а не эксплойт. Вот и попробуй объясни аудитору, что Medium-уязвимость - это ворота к физической катастрофе.
[Применимо: внутренний пентест OT-сети, grey box (доступ к инженерной станции с валидными учётными данными)]
Почему CVSS не работает для оценки уязвимостей ICS SCADA
CVSS разработан для IT-контекста. Его метрики не учитывают:- Safety: уязвимость с CVSS 4.0 на контроллере SIS может привести к травмам и гибели людей
- Каскадные эффекты: отказ одного контроллера вызывает цепную реакцию в технологическом процессе
- Стоимость простоя: для нефтеперерабатывающего завода час простоя - потери в десятки миллионов рублей
- Экологический ущерб: разлив, выброс, загрязнение - последствия, которые CVSS не моделирует
| Impact-категория | Низкий (1) | Средний (2) | Высокий (3) | Критический (4) |
|---|---|---|---|---|
| Безопасность | Нет пострадавших | Лёгкие травмы | Тяжёлые травмы | Угроза жизни |
| Доступность | Деградация <1 ч | Остановка <8 ч | Остановка <72 ч | Остановка >72 ч |
| Экология | Нет | Локальный ущерб | Значительный | Катастрофический |
| Финансы | <1 млн руб | 1-50 млн руб | 50-500 млн руб | >500 млн руб |
Для количественной оценки зрелые организации переходят на FAIR (Factor Analysis of Information Risk): вместо цветовой кодировки - распределение вероятности убытков в рублях. FAIR позволяет говорить с руководством на финансовом языке: "вероятность инцидента с ущербом более 100 миллионов рублей в течение 12 месяцев - 15%". Это понятнее для бизнеса, чем "у нас 47 рисков в красной зоне". Красная зона - это что? А 100 миллионов - это конкретно.
Чеклист: управление киберрисками промышленных систем
Нумерованный чеклист для передачи OT-команде или включения в отчёт по результатам оценки:Этот чеклист - стартовая точка для оценки киберрисков критической инфраструктуры. Полная методология требует адаптации под конкретную отрасль (энергетика, водоснабжение, транспорт, нефтехимия) и зрелость процессов на объекте.
За последние три года я оценивал OT-безопасность десятков промышленных объектов - и паттерн повторялся каждый раз. Формально risk assessment проведён, категория объекту КИИ присвоена, набор защитных мер на бумаге определён. При этом ни один документ не содержал анализа того, как конкретный Modbus FC16 на конкретном PLC приводит к конкретному физическому событию.
Оценка рисков в OT - это не таблица с цветовой кодировкой. Это карта, показывающая путь от скомпрометированного ноутбука инженера до открытия задвижки на магистральном трубопроводе, с оценкой на каждом шаге: какова вероятность, какой ущерб, что мешает атакующему и что ему помогает.
Пока оценка строится по IT-шаблонам с CVSS-рангами вместо анализа физического импакта, она остаётся ритуалом для аудитора, а не инструментом киберустойчивости. Проверьте свой historian-сервер прямо сейчас:
show ip route на ближайшем L3-коммутаторе покажет, есть ли прямой маршрут в корпоративную сеть. Если есть - у вас та же проблема, с которой начиналась эта статья.
Последнее редактирование модератором:
