Защищенность АСУ ТП нельзя доказать одними документами

Защищенность АСУ ТП нельзя доказать одними документами

Изображение: recraft

Промышленные предприятия долго готовились к проверкам ФСТЭК как к ревизии документов: модель угроз, приказы, акты внедрения, схемы взаимодействия, перечни мер защиты. Но для АСУ ТП этого уже недостаточно. Если в документах написано, что удаленный доступ защищен, нужно показать, кто его согласует, как он предоставляется, где фиксируются действия пользователя и как выявляются нарушения.

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

Ситуацию усложняют новые правила категорирования КИИ. Постановление Правительства № 1762 от 7 ноября 2025 года изменило порядок выявления объектов КИИ: организациям нужно сопоставлять свои информационные системы, сети и АСУ с типовыми отраслевыми объектами. Распоряжением Правительства № 360-р от 26 февраля 2026 года утвержден единый перечень из 397 позиций для 14 отраслей. Для предприятий это означает пересмотр не только документов, но и фактического состояния технологической инфраструктуры.

Мы в UDV Group видим главный риск в расхождении между тем, что описано в документах, и тем, как система работает на самом деле. АСУ ТП меняется постепенно: инженеры добавляют оборудование, обновляют прошивки, открывают порты, настраивают новые маршруты обмена, подключают подрядчиков и временные сервисные каналы. Каждое изменение может быть оправдано производственной задачей. Но если оно не попало в модель угроз и схемы взаимодействия, защищенность существует только на бумаге.

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

Формальным может оказаться и внедрение средств защиты. Межсетевой экран установлен, принят по акту и указан в документах. Но если его правила давно не пересматривались, новые соединения добавлялись как исключения, а события не поступают на мониторинг, само наличие сертифицированного средства ничего не доказывает. Мера защиты становится проверяемой только тогда, когда предприятие может объяснить назначение разрешенных взаимодействий и показать, как выявляет отклонения.

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

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

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

Мы в UDV Group считаем, что эти методы не заменяют техническое исследование уязвимостей, но закрывают более практичную задачу: показывают изменения, которые чаще всего создают реальные точки входа. Для АСУ ТП часто опасна не только известная CVE, а несогласованная связь, временный доступ, забытое правило или конфигурация, которая давно отличается от утвержденной.

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

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

Главный вопрос, который предприятие должно задать себе заранее: сколько времени проходит между изменением в технологическом контуре и моментом, когда о нем узнает служба безопасности. Если ответа нет, отчет о защищенности теряет опору. Он может быть корректно оформлен, но не отражать реальное состояние производства.

Владельцем процесса оценки должен быть не только ИБ-отдел. В АСУ ТП за последствия остановки отвечает технологический бизнес-владелец: технический директор, главный инженер, руководитель производства. ИБ определяет требования и методы контроля, специалисты АСУ ТП оценивают допустимость действий для оборудования, ИТ обеспечивает инфраструктуру, а руководство закрепляет полномочия и ресурсы. Без такого распределения ИБ остается без доступа к системе, а производство — без понятной оценки риска.

Важен и переход от разовых проверок к регулярным показателям. Эту логику развивает проект изменений в приказы ФСТЭК № 235 и № 239: он предусматривает регулярный расчет показателей защищенности и зрелости. На дату публикации исходного материала документ оставался проектом, а планируемая дата вступления в силу указывалась как 1 сентября 2026 года.

Для нас в UDV Group вывод простой: защищенность АСУ ТП нельзя доказать объемом документов или количеством закупленных продуктов. Ее нужно подтверждать способностью видеть фактическое состояние технологического контура, вовремя замечать отклонения, оценивать их влияние на производство и выбирать действия, которые не создают новый риск.

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

UDV Group
Автор: UDV Group
UDV Group — российский разработчик в области кибербезопасности промышленных и корпоративных сетей.
Комментарии: