Типичные ошибки предприятий при построении комплексной защиты АСУ ТП

По данным отчёта Dragos Year in Review за 2024 год, число ransomware-атак на промышленные организации выросло на 87%, а 75% инцидентов, на которые реагировала команда Dragos, привели к частичной остановке OT-систем. При этом большинство пострадавших организаций уже потратили значительные бюджеты на средства защиты. Проблема не в отсутствии инструментов — проблема в системных ошибках, которые обесценивают любые инвестиции в безопасность.

Ниже — семь просчётов, которые встречаются на предприятиях снова и снова, независимо от отрасли и масштаба.

1Подмена OT-безопасности IT-практиками

Самая распространённая ошибка — переносить корпоративные IT-политики на технологическую сеть без адаптации. Антивирус на серверах SCADA, групповые политики Active Directory для операторских станций, централизованное обновление Windows через WSUS — всё это выглядит логично с точки зрения IT-отдела и создаёт реальные риски для непрерывности технологического процесса (подробнее о специфике — в статье о разработке промышленного ПО).

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

IEC 62443-2-3 (Technical Report по управлению патчами для промышленных систем) требует, чтобы процедуры обновления отличались от корпоративных и учитывали влияние на доступность технологического процесса. Патч, прошедший тестирование в IT-лаборатории, не эквивалентен патчу, проверенному на стенде с реальной конфигурацией АСУ ТП.

Что делать

Разделить ответственность: IT-служба отвечает за корпоративную сеть (уровни 4–5 по Purdue), отдельная команда или выделенный специалист — за безопасность OT (уровни 0–3). Если выделенной команды нет, как минимум адаптировать каждую IT-политику перед применением в технологическом сегменте. Тестировать патчи на резервной станции. Использовать пассивный мониторинг вместо активного сканирования.

2Защита периметра без внутренней сегментации

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

Внутри технологической сети контроллеры, серверы SCADA, инженерные станции и историан обычно находятся в одном VLAN. Протоколы Modbus TCP, S7comm, EtherNet/IP не имеют встроенной аутентификации. Любое устройство в сети может отправить команду на запись регистра в ПЛК.

Уровень Purdue	Компоненты	Типичное нарушение
Уровень 3 (Site Operations)	Historian, MES-сервер, антивирусный сервер	Прямой маршрут к уровню 1 в обход DMZ
Уровень 2 (Area Supervisory)	SCADA-серверы, HMI-станции	Один VLAN с инженерными станциями
Уровень 1 (Basic Control)	ПЛК, RTU, контроллеры безопасности	Нет ACL между ПЛК разных технологических зон
Уровень 0 (Process)	Датчики, исполнительные механизмы	Диагностические порты HART доступны из сети уровня 2

IEC 62443-3-3 вводит понятие зон (zones) и каналов (conduits) — именно они определяют границы сегментации. Каждая зона объединяет активы с одинаковым уровнем доверия (Security Level, SL). Трафик между зонами проходит через контролируемые каналы с определёнными правилами фильтрации.

3Отсутствие инвентаризации OT-активов

Невозможно защитить то, о существовании чего вы не знаете. Тем не менее на большинстве предприятий полная инвентаризация активов технологической сети отсутствует. Есть проектная документация пятилетней давности, есть разрозненные таблицы Excel у разных подразделений, но единого реестра с актуальными версиями прошивок, IP-адресами и сетевыми связями — нет.

Без инвентаризации невозможно:

• Определить поверхность атаки — сколько устройств доступно из сети и по каким протоколам
• Оценить уязвимости — какие версии прошивок установлены, какие CVE к ним применимы
• Спланировать сегментацию — нельзя разделить сеть на зоны, не зная, что в ней находится
• Обнаружить аномалии — если неизвестен нормальный состав сети, любое несанкционированное устройство останется незамеченным

Серия стандартов IEC 62443 требует вести и поддерживать реестр всех компонентов системы автоматизации — без актуального реестра активов невозможно достичь даже минимального уровня безопасности SL-1. Приказ ФСТЭК России № 239 (для значимых объектов КИИ) включает инвентаризацию в состав обязательных мер защиты.

Пассивная инвентаризация

Активное сканирование в OT-сети опасно (см. ошибку №1). Альтернатива — пассивный анализ трафика. Системы класса Network Detection and Response (NDR) для промышленных сетей (Dragos, Claroty, Nozomi Networks, PT ISIM) подключаются к SPAN-порту коммутатора и восстанавливают карту активов по наблюдаемому трафику: MAC-адреса, IP, протоколы, типы устройств, версии прошивок (если протокол передаёт эту информацию).

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

4Покупка средств защиты без выстроенных процессов

Руководство выделяет бюджет, закупается SIEM, IDS для промышленных протоколов, межсетевые экраны следующего поколения. Оборудование монтируется, лицензии активируются. Через полгода SIEM генерирует тысячи событий в сутки, которые никто не разбирает. Правила на файрволе не обновлялись с момента ввода в эксплуатацию. IDS работает в режиме обучения, потому что никто не переключил его в режим мониторинга.

Средства защиты — инструменты. Без процессов эксплуатации они бесполезны.

Минимальный набор процессов, которые должны быть формализованы до закупки средств защиты:

• Управление инцидентами — кто принимает решение об изоляции сегмента сети, кто координирует расследование, каков порядок восстановления
• Управление изменениями — любое изменение в конфигурации сетевого оборудования, ПЛК или SCADA-сервера проходит через процедуру согласования и фиксируется
• Управление уязвимостями — регулярная проверка бюллетеней вендоров (Siemens ProductCERT, Schneider PSIRT, CISA ICS-CERT), оценка применимости и планирование обновлений
• Управление доступом — кто и с каких станций может подключаться к инженерным портам контроллеров, кто имеет права на изменение программ ПЛК

5Игнорирование удалённого доступа

Пандемия 2020 года ускорила внедрение удалённого доступа к промышленным системам на несколько лет. То, что планировалось как временное решение, стало постоянным. VPN-концентратор с доступом к SCADA-серверу, TeamViewer на инженерной станции, проброшенный SSH-туннель для диагностики ПЛК — всё это примеры решений, которые создавались «на неделю» и работают до сих пор.

Проблема не в самом удалённом доступе — он может быть необходим. Проблема в реализации:

• Один общий аккаунт VPN для всех подрядчиков
• Отсутствие многофакторной аутентификации (MFA)
• VPN-соединение ведёт напрямую в технологическую сеть, минуя DMZ
• Нет журналирования действий удалённых пользователей
• Нет ограничения по времени — подрядчик сохраняет доступ после завершения работ

Атака на Colonial Pipeline в 2021 году началась именно через скомпрометированный VPN-аккаунт. Один пароль без MFA — и атакующие получили доступ к IT-инфраструктуре, а затем из-за отсутствия уверенности в сегментации между IT и OT компания была вынуждена остановить трубопровод.

6Отсутствие плана реагирования для OT-инцидентов

Даже на предприятиях с зрелыми IT-процессами план реагирования на инциденты (Incident Response Plan, IRP) редко учитывает специфику технологической сети. IT-инцидент и OT-инцидент — принципиально разные ситуации.

Параметр	IT-инцидент	OT-инцидент
Приоритет	Конфиденциальность данных	Непрерывность процесса и безопасность персонала
Допустимая реакция	Изолировать заражённый хост немедленно	Оценить влияние изоляции на технологический процесс
Перезагрузка	Стандартная процедура	Может привести к аварийному останову
Сбор форензики	Снять образ диска	На работающем сервере SCADA невозможно без остановки процесса
Время восстановления	Часы — дни	Минуты — часы (или физический ущерб)

Требования ФЗ-187 обязывают субъектов критической информационной инфраструктуры (КИИ) уведомлять НКЦКИ об инцидентах. Приказ ФСБ России № 367 устанавливает срок уведомления — не позднее 24 часов с момента обнаружения инцидента. Для значимых объектов КИИ приказ ФСБ России № 282 сокращает этот срок до 3 часов. Без формализованного плана реагирования предприятие не способно выполнить эти требования.

Минимальный состав OT IRP

• Классификация инцидентов с учётом влияния на технологический процесс
• Матрица эскалации: кто принимает решение об останове — начальник смены, главный инженер, диспетчер
• Процедура изоляции сегментов без остановки критических процессов
• Контакты вендоров АСУ ТП для экстренной поддержки
• Процедура переключения на ручное управление
• Порядок уведомления регуляторов (НКЦКИ, ФСБ, ФСТЭК)
• Регулярные тренировки — не реже раза в год

7Игнорирование цепочки поставок

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

Атака TRITON/TRISIS (2017) на систему противоаварийной защиты Schneider Electric Triconex — один из наиболее показательных примеров. Атакующие получили доступ к контроллерам безопасности (SIS) через скомпрометированную инженерную станцию. Целью было изменение логики контроллера безопасности — по сути, отключение последнего рубежа защиты от физической аварии.

Элементы управления рисками цепочки поставок для OT:

• Проверка целостности — верификация хешей прошивок и обновлений ПО перед установкой
• Политика для подрядчиков — запрет подключения личных устройств к технологической сети, сканирование переносных носителей
• Резервирование конфигураций ПЛК — регулярное резервное копирование программ контроллеров с контролем изменений (version control)
• Мониторинг изменений — отслеживание несанкционированных модификаций программ ПЛК, уставок и конфигураций

IEC 62443-2-4 определяет требования к поставщикам услуг интеграции — Security Program requirements for IACS service providers. Если ваш интегратор не может подтвердить соответствие этим требованиям, это повод задуматься.

Чек-лист: с чего начать

Выстраивание комплексной защиты АСУ ТП — не проект с конечным сроком, а непрерывный процесс. Однако начинать стоит с конкретных, измеримых шагов:

• Провести инвентаризацию OT-активов (пассивными методами)
• Разделить ответственность за безопасность IT и OT
• Внедрить базовую сегментацию: минимум — файрвол между корпоративной и технологической сетью с DMZ
• Аудит удалённого доступа: убрать TeamViewer, закрыть неиспользуемые VPN-аккаунты, внедрить MFA
• Разработать план реагирования на OT-инциденты, провести табличные учения
• Начать мониторинг: хотя бы NetFlow/зеркалирование трафика на границе IT/OT
• Формализовать процедуру управления изменениями в конфигурациях ПЛК и SCADA
• Определить, подпадает ли предприятие под ФЗ-187, и если да — провести категорирование объектов КИИ