На gap-анализе химического предприятия в прошлом году мы нашли контроллер SIS (Safety Instrumented System) Triconex, подключённый к корпоративной сети через неуправляемый коммутатор. Без межсетевого экрана, без VLAN, без записи трафика в SIEM. В asset inventory этого соединения не существовало. Предприятие формально "соответствовало" внутренней политике ИБ - но политика была написана под IT-инфраструктуру и про промышленную сеть не знала ничего. Это типичная стартовая точка построения OT security program: разрыв между бумажным compliance и реальным состоянием сегментации. Два фреймворка - IEC 62443 и NIST SP 800-82 Rev.3 - закрывают этот разрыв, если применять их вместе. NIST задаёт программную рамку и risk management, IEC 62443 наполняет её инженерными требованиями: зоны, кондуиты, Security Levels, конкретные foundational requirements. Дальше - практическая последовательность внедрения: от пассивного asset discovery до подготовки доказательной базы для оценки зрелости ИБ OT.
Чем защита промышленных систем управления отличается от IT
Разница между IT и OT - не в масштабе сети, а в приоритетах и физических ограничениях. В IT тройка CIA выстроена привычно: Confidentiality -> Integrity -> Availability. В OT приоритет перевёрнут: Availability -> Integrity -> Confidentiality, а над всем стоит Safety - категория, которой в IT-домене просто нет. Подробнее - в нашем подробном разборе кибербезопасность критической инфраструктуры.На практике это выражается в ограничениях, которые делают стандартные IT-инструменты неприменимыми.
Нельзя сканировать сеть активными средствами. Обычный
nmap -sV по OT-сегменту может положить PLC. Контроллеры серии Siemens S7-300 при получении нестандартного TCP-пакета на порт 102 (ISO-TSAP) способны перейти в STOP. Legacy RTU на Modbus RTU/ASCII зависают от любого нераспознанного запроса. NIST SP 800-82 Rev.3 (раздел 6.2.1) прямо предостерегает от активного сканирования в live ICS-средах без валидации вендором.EDR не устанавливается на HMI и EWS. Windows-based HMI (Siemens WinCC, Wonderware InTouch, Ignition) работают на специфических сборках ОС, часто без возможности поставить агент стороннего ПО. На ПЛК и RTU агент не поставить физически - там нет ОС общего назначения.
Протоколы не содержат аутентификации. Modbus TCP - бинарный протокол без встроенной проверки источника. Отправка команды FC6 (Write Single Register) или FC16 (Write Multiple Registers) на порт 502 меняет уставки процесса без какой-либо авторизации. DNP3 в базовой конфигурации аналогичен. Атакующий в сегменте OT-сети видит весь трафик и может инжектировать управляющие команды - это механика атаки INDUSTROYER2 (2022, энергосистема Украины) и фреймворка PIPEDREAM/INCONTROLLER, нацеленного на контроллеры Schneider Electric и OMRON. Атака TRITON/TRISIS (2017) была направлена именно на SIS-контроллеры - уровень, который отвечает за физическую безопасность людей.
Baseline стабилен, а аномалии критичны. В IT-сети сотни новых соединений в минуту - норма. В OT-сегменте набор коммуникационных пар стабилен месяцами: HMI опрашивает ПЛК по Modbus FC3 (Read Holding Registers) каждые 500 мс, Historian забирает данные из SCADA-сервера по фиксированному расписанию. Появление нового IP или нового function code (например, FC8 - Diagnostics) - аномалия, которая в IT-SIEM утонет в шуме, а в OT-контексте требует немедленного разбора.
Два фреймворка - одна программа безопасности операционных технологий
Типичная ошибка - вести два параллельных workstream: один "по NIST", другой "по IEC". Это удваивает бюджет и путает персонал площадки. Правильная связка: NIST SP 800-82 Rev.3 + CSF 2.0 - программный скелет, IEC 62443 - инженерная спецификация. В NIST SP 800-82 Rev.3 (опубликован в сентябре 2023) ISA-62443-2-1 прямо рекомендуется как подходящий стандарт программы кибербезопасности IACS. Шесть функций CSF 2.0 (Govern, Identify, Protect, Detect, Respond, Recover) задают жизненный цикл. IEC 62443 наполняет каждую функцию OT-специфичным инженерным содержанием.Что изменилось в Rev.3 по сравнению с Rev.2 (2015): полное выравнивание с CSF 2.0 включая функцию Govern, расширенное покрытие IIoT и cloud-connected OT, обновлённые угрозы с учётом ICS-специфичного вредоносного ПО (TRITON, INDUSTROYER2, PIPEDREAM), а также явные перекрёстные маппинги между контролями SP 800-82 и IEC 62443.
Security Levels и Security Zones Conduits IEC 62443
Security Levels (SL) - не абстрактная шкала, а классификация по capability атакующего:| SL | Модель угрозы | Типичное применение |
|---|---|---|
| SL 1 | Случайное/непреднамеренное нарушение | BMS, управление освещением |
| SL 2 | Целенаправленная атака простыми средствами | Базовый контур управления, SCADA |
| SL 3 | Атака с использованием сложных средств и знаний OT | SIS, критические DCS-контуры |
| SL 4 | APT-уровень, государственные ресурсы | Ядерная энергетика, крупная химия |
Зона - логическая группировка активов с одинаковыми требованиями безопасности. Кондуит - контролируемый канал связи между зонами. В нефтегазовой инфраструктуре, по IEC 62443-3-2 (раздел 4.3), типичная defense in depth OT архитектура выглядит так:
- Зона Safety (SIS/ESD): минимум SL 3, изоляция через аппаратный data diode (outbound only)
- Зона Basic Process Control (DCS): SL 2, связь с Supervisory через firewall conduit
- Зона Supervisory (SCADA/Historian): SL 2, связь с Enterprise через выделенную DMZ с application-layer inspection
- Enterprise/IT: прямое подключение к OT-зонам запрещено
Маппинг контролей: от SP 800-53 к FR1–FR7
IEC 62443-3-3 определяет семь Foundational Requirements (FR) и 51 системное требование. NIST SP 800-82 Rev.3 (раздел 5) ссылается на контроли SP 800-53 Rev.5 с OT-оверлеями. Маппинг между ними - рабочий инструмент для повседневного внедрения IEC 62443:| SP 800-53 семейство | IEC 62443-3-3 FR | Что это значит в OT-среде |
|---|---|---|
| AC (Access Control) | FR1 (IAC) + FR2 (UC) | Уникальные учётки на HMI/EWS, MFA для remote access, ролевое разграничение: Read-Only/Operator/Engineer |
| AU (Audit and Accountability) | FR6 (TRE - Timely Response to Events) | Пассивный мониторинг ICS-протоколов без active polling в контрольной зоне |
| SI (System Integrity) | FR3 (SI) | Application whitelisting на HMI вместо традиционного AV, верификация firmware PLC |
| CM (Configuration Management) | FR3 + FR4 (DC) | Контроль целостности конфигураций PLC, версионирование logic-проектов |
| CP (Contingency Planning) | FR7 (RA - Resource Availability) | Резервирование PLC/DCS, тестирование восстановления без останова процесса |
| IR (Incident Response) | FR6 + процедуры 62443-2-1 | OT-специфичный IRP с участием process safety |
Когда вендор OT-оборудования заявляет, что MFA "невозможна" на legacy HMI - IEC 62443-2-1:2024 прямо допускает компенсирующие контроли: jump-host с MFA, запись сессии, ограниченные временные окна доступа. Тут главное - задокументировать компенсирующий контроль, принятый остаточный риск и обоснование невозможности нативной реализации. Этот документ становится audit artifact и для IEC 62443, и для проверки по ФСТЭК №31.
Построение OT security program по шагам
Шаг 1 - пассивный asset discovery
Нельзя защитить то, чего нет в инвентаризации (CSF 2.0, ID.AM-01). Разрыв между "задокументированными активами" и "реально подключенными устройствами" на промышленных площадках составляет 30-50% - по нашему опыту это стабильная цифра. Метод: SPAN-порт на OT-коммутаторах + пассивный инструмент с поддержкой ICS-протоколов (Claroty, Dragos, Nozomi Networks, или open-source Zeek с плагинами для Modbus/DNP3/S7comm/EtherNet/IP).Требования к окружению для пассивного asset discovery:
- SPAN/mirror port на каждом L2-коммутаторе OT-сегмента
- Сервер сбора: минимум 16 ГБ RAM, 1 ТБ storage для 30 дней PCAP
- Никаких active probes в OT-VLAN: исключительно пассивный capture
- Доступ к существующим network diagrams и firewall configs для верификации
Шаг 2 - зоны, кондуиты и назначение Target SL
Частая ошибка: рисовать Zone & Conduit как сетевую диаграмму. Это не сетевое упражнение - это классификация рисков, которая определяет подбор контролей. Последовательность:- Consequence analysis. Работайте с process safety инженерами. Документация HAZOP содержит оценки severity для каждого процессного узла. Маппинг: что произойдёт, если атакующий изменит уставку на этом ПЛК? Потеря контейнмента? Экологический выброс? Остановка линии?
- Группировка активов в зоны по общим требованиям кибербезопасности АСУ ТП, последствиям компрометации и операционной функции.
- Документирование кондуитов. Каждый канал связи между зонами: протокол, направление потока данных, механизм защиты (firewall rule, data diode, VPN).
- Назначение Target Security Level (TSL) каждой зоне на основе threat scenario и consequence severity.
Шаг 3 - компенсирующие контроли для legacy
Реальность OT ICS SCADA защиты: lifespan оборудования 15-25 лет. На площадке - PLC с Windows CE, HMI на Windows XP Embedded, RTU без TLS. IEC 62443-2-1:2024 (редакция от августа 2024) явно адресует legacy-системы, допуская компенсирующие меры вместо нативных возможностей. Формат документирования каждой компенсации:- Требование (например, FR1: аутентификация пользователей)
- Причина невозможности нативной реализации (WinCC 6.2 SP3, shared account - единственный режим)
- Компенсирующий контроль (jump-host с MFA + session recording + time-limited window)
- Остаточный риск и уровень acceptance
- Подпись asset owner
Оценка зрелости ИБ OT: подготовка доказательной базы
IEC 62443-2-1:2024 реструктурировала требования к asset owner в Security Program Elements (SPE) и ввела формальную модель зрелости. Оценка зрелости - не анкета "да/нет", а сопоставление текущего состояния с целевым по каждому SPE с визуализацией через heat map.
| Категория доказательств | Артефакты | Типичная проблема |
|---|---|---|
| Политики и процедуры | OT Security Policy, Patch Mgmt Procedure, IRP | Написаны для IT, не адаптированы под OT |
| Архитектура сети | Network diagrams с Zone/Conduit, firewall rule sets | Диаграммы устарели, не отражают реальные потоки |
| Asset inventory | Регистр OT-активов с firmware versions | Разрыв с реальностью 30–50% |
| Risk assessment | CRS, HAZOP-маппинг, TSL assignments | Consequence analysis без process safety team |
| Мониторинг и ICS incident response | OT-playbooks, SIEM logs | Playbooks - копия IT, нет OT-специфики |
| Change management | Записи об изменениях PLC logic, firmware | Изменения не логируются или логируются post factum |
Heat map по SPE - инструмент коммуникации с руководством. Каждый элемент оценивается: "реализован полностью", "частично", "не реализован". Результат - одностраничная карта strengths/gaps, привязанная к consequence severity зон. Именно она обосновывает каждую строку бюджетного запроса.
Detection в OT-среде: мониторинг без нарушения процесса
Detection-стратегия строится на двух принципах: пассивный сбор и protocol-aware анализ. Любой инструмент с active polling не имеет права находиться внутри контрольной зоны.
Пассивный мониторинг ICS-протоколов. Zeek с плагинами для Modbus, DNP3, EtherNet/IP, PROFINET или коммерческие решения (Claroty, Dragos) подключаются к SPAN-порту и разбирают трафик до уровня function codes. Пример правила для Suricata:
Код:
# Обнаружение записи в Holding Registers с неавторизованного IP
alert modbus any any -> $OT_PLC_NET 502 (msg:"MODBUS Write Multiple Regs from unauth src"; modbus: function 16; flow:to_server,established; sid:3000001; rev:1;)
- Новый MAC-адрес в OT-сегменте + отсутствие в asset inventory = P1
- VPN-подключение к OT jump-host в нерабочее время + Modbus FC5/FC6/FC16 (команды записи) = P1
- Сдвиг firmware fingerprint PLC без записи в change management = P2
- Появление нового function code (FC8 Diagnostics, FC43 Read Device ID) от существующего хоста = P2
Сценарий: компрометация OT через инженерную станцию
Разберём цепочку атаки с маппингом на MITRE ATT&CK for ICS - типичную для промышленных сред и не требующую APT-уровня ресурсов.Понедельник, 9:15. Инженер КИПиА подключает ноутбук к OT-сегменту для обновления logic-проекта. Ноутбук корпоративный, с доступом к email. Две недели назад инженер открыл фишинговое вложение - на машине работает implant.
9:20. Malware обнаруживает новые сетевые интерфейсы. Network Service Discovery (T1046, Discovery) - сканирование подсети 10.10.20.0/24, обнаружение портов 502 (Modbus TCP), 102 (S7comm), 44818 (EtherNet/IP).
9:22. Подключение к HMI через Default Accounts (T1078.001, Initial Access) - shared account
WinCCAdmin с паролем, который не менялся с ввода в эксплуатацию.9:25. Network Sniffing (T1040, Credential Access / Discovery) - перехват Modbus-трафика: function codes, адреса регистров, текущие уставки.
9:30. Запись новых значений в Holding Registers ПЛК через Modbus FC16 - изменение уставки давления в реакторном контуре.
Точки обнаружения:
| Время | Событие | Detection-механизм | Что ловит |
|---|---|---|---|
| 9:15 | Новый MAC в OT VLAN | Passive asset monitor | Устройство не в inventory |
| 9:20 | TCP SYN scan по 502, 102 | IDS на SPAN | Аномалия: scan activity |
| 9:22 | Login на HMI с IP вне whitelist | Windows Event Log + SIEM | Доступ с неавторизованного источника |
| 9:25 | Modbus FC3 bulk read с нового IP | Protocol-aware monitor | Новая коммуникационная пара |
| 9:30 | Modbus FC16 с нового IP | IDS + SIEM correlation | Команда записи от неавторизованного узла, P1 |
Сценарий не требует государственных ресурсов - достаточно скомпрометированного легитимного хоста и отсутствия сегментации. Zone & Conduit модель и контроль доступа (FR1 + FR2 по IEC 62443-3-3) разрывают kill chain на этапе lateral movement: инженерный ноутбук не должен иметь прямого маршрута к ПЛК в обход jump-host.
Чеклист gap-анализа OT security program
Нумерованный список для передачи ответственному за кибербезопасность АСУ ТП:
📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме
За три года работы с OT security programs на десятке площадок - от нефтепереработки до водоочистки - я вижу одну закономерность. Организации, которые начинают с покупки "OT SIEM" или "промышленного файрвола", через год обнаруживают, что инструмент стоит, а программы безопасности нет. Инструменты без фундамента - asset inventory, zone model, risk assessment с consequence analysis - дают ложное чувство защищённости. Самый недооценённый артефакт - CRS (Cybersecurity Requirements Specification) по IEC 62443-3-2. Это документ, который связывает бизнес-последствия с техническими требованиями к каждой зоне и позволяет обосновать каждую строку бюджета. Без него разговор с руководством - "нам нужен бюджет на ИБ". С ним - "вот зоны с SL 3, вот gap, вот стоимость закрытия, вот остаточный риск при отказе". Второй момент: оценка зрелости по IEC 62443-2-1:2024 с SPE-моделью - это измеримый прогресс, а не формальность. Кто реально готовил доказательную базу для аудита OT, знает: самый болезненный gap - не отсутствие файрвола, а отсутствие задокументированного change management на PLC logic. Если у вас есть опыт маппинга контролей IEC 62443 на требования ФСТЭК №31 или подготовки CRS для конкретных площадок - на codeby.net коллеги ведут тред с разбором типовых расхождений между спецификацией и реальной конфигурацией промышленных объектов.
Последнее редактирование модератором: