Содержание
Читайте в Telegram
|
Промышленное предприятие может выглядеть готовым к проверке. Есть модель угроз, приказы, акты внедрения, схемы сегментации, перечень мер защиты и уверенность, что технологическая сеть отделена от корпоративной. На бумаге все сходится. Проблема начинается в цехе.
За годы эксплуатации в АСУ ТП появляются новые маршруты обмена, временные подключения, инженерные станции подрядчиков, дополнительные порты, обновленные прошивки, исключения в межсетевых экранах и старые правила, назначение которых уже никто не помнит. Каждое изменение когда-то было нужно производству. Но если оно не попало в документы, реальная система и формальная картина начинают жить отдельно.
Теперь такой разрыв становится опаснее. ФСТЭК и регуляторная повестка постепенно смещают фокус с наличия документов на доказуемость защищенности. Организации придется не просто показать, что меры защиты утверждены, а подтвердить, что они реально работают в изменившейся технологической среде.
Документы могут быть правильными, а система - другой
АСУ ТП редко остается неизменной. Производство живет, инженеры решают практические задачи, подрядчики подключаются для пусконаладки, появляются новые участки, модернизируется оборудование, меняются сетевые взаимодействия. Формально это может быть нормальная эксплуатация. Но с точки зрения ИБ каждое такое изменение меняет поверхность атаки.
Самая типичная ошибка - считать технологический контур изолированным только потому, что у него нет постоянного выхода в интернет. Прямого канала действительно может не быть. Но остаются сервисные подключения, переносные инженерные станции, временные правила межсетевых экранов, беспроводные сегменты, удаленный доступ подрядчиков и компьютеры, которые одновременно видят корпоративную и промышленную сеть.
«Главная проблема проверок АСУ ТП в том, что документы часто описывают систему такой, какой она была на момент внедрения, а не такой, какой она стала после нескольких лет эксплуатации. Для регулятора и для бизнеса важен не сам комплект документов, а способность доказать, что утвержденные меры защиты совпадают с реальным состоянием технологического контура», - говорит Ольга Луценко, ведущий эксперт UDV Group.
В этом и заключается новый уровень ответственности. Если в документах указана защита удаленного доступа, предприятие должно показать, кто подключается, кто согласует доступ, как фиксируются действия и как выявляются нарушения. Если заявлена сегментация, нужно объяснить, какие взаимодействия разрешены и почему. Если стоит межсетевой экран, важно не его наличие по акту, а актуальность правил и контроль отклонений.
Сертифицированное средство защиты само по себе не доказывает защищенность. Оно доказывает только то, что продукт установлен. А защищенность начинается там, где организация понимает, что через него проходит, кто меняет правила, какие исключения согласованы и какие события действительно контролируются.
Проверить АСУ ТП как офисную сеть нельзя
В корпоративной ИТ-инфраструктуре активное сканирование давно стало привычным инструментом. Сканер проходит по адресам, опрашивает узлы, определяет версии ПО, ищет уязвимости и формирует отчет. Для офиса это может быть штатной процедурой. Для АСУ ТП тот же подход способен создать проблему вместо оценки риска.
Промышленные контроллеры, операторские станции и старые промышленные компьютеры не всегда рассчитаны на лишнюю нагрузку и нестандартные запросы. Устройство может перестать отвечать, разорвать соединение, уйти в нештатный режим или повлиять на обмен с системой верхнего уровня. Для корпоративного сканера процедура завершится успешно. Для производства это может означать ручной режим, остановку участка или потерю управления оборудованием.
Именно поэтому спор «сканировать или не сканировать» в АСУ ТП поставлен неправильно. Отказ от проверки сохраняет видимость стабильности, но оставляет риски невидимыми. Агрессивная проверка может повредить технологический процесс. Нужен третий путь: оценивать состояние промышленного контура методами, которые не мешают его работе.
«В АСУ ТП инструмент проверки сам может стать источником риска. Активный сканер, который безопасно отрабатывает в офисной сети, способен перегрузить устаревший контроллер или вызвать нештатную реакцию промышленного устройства. Поэтому задача не в том, чтобы отказаться от проверки, а в том, чтобы выбирать методы, допустимые для конкретного технологического сегмента», - отмечает Ольга Луценко, ведущий эксперт UDV Group.
Такой подход требует другой дисциплины. Сначала нужно понять состав оборудования, его ограничения и фактические связи. Потом - определить, какие проверки допустимы, в какое технологическое окно, с какой интенсивностью и на каком резервном или тестовом устройстве они заранее отработаны. Активное сканирование в промышленности должно быть точечной процедурой, а не универсальным способом пройти по всей сети.
Сначала нужно увидеть реальную сеть
Безопасная проверка АСУ ТП начинается не с поиска уязвимостей, а с восстановления фактической картины. Какие устройства реально работают. Какие протоколы используются. Какие узлы взаимодействуют друг с другом. Какие связи есть в сети, но отсутствуют в документации. Какие маршруты появились после пусконаладки или модернизации.
Для этого лучше подходит пассивный анализ трафика. Он позволяет видеть обмен, не отправляя дополнительные запросы на оборудование. Система не вмешивается в технологический процесс, но помогает понять, как он устроен на самом деле. Это особенно важно там, где любое активное воздействие на контроллеры и промышленные устройства требует осторожности.
Пассивная картина часто показывает то, чего нет в схемах. Например, неучтенное устройство, странную связь между сегментами, устаревший протокол, неизвестный обмен с инженерной станцией или взаимодействие, которое осталось после временных работ. С точки зрения производства это могло долго никому не мешать. С точки зрения ИБ это уже потенциальная точка входа.
Следующий слой - конфигурации и действия пользователей. Настройки коммутаторов, маршрутизаторов, контроллеров и рабочих мест можно сравнивать с утвержденными эталонами. Журналы показывают перезапуски сервисов, ошибки доступа, использование учетных записей и изменения, которые иначе остались бы незамеченными. А контроль привилегированного доступа позволяет понять, что именно делали внутренние специалисты и подрядчики.
Такие методы не заменяют технический анализ уязвимостей, но помогают найти то, что чаще всего создает реальный риск: неучтенные связи, несогласованные изменения, устаревшие настройки, лишние доступы и разрыв между документом и фактом.
Руководителю нужны не CVE, а управляемость
Достаточность защиты АСУ ТП нельзя оценивать только количеством найденных уязвимостей. Для руководителя гораздо важнее другие вопросы. У всех ли критичных активов есть владелец. Сколько соединений не согласовано. Какие изменения не отражены в документах. Все ли удаленные подключения проходят через утвержденную процедуру. Насколько быстро команда может восстановить хронологию действий при подозрении на нарушение.
Это переводит разговор из технической плоскости в управленческую. Не «сколько у нас уязвимостей», а «насколько мы понимаем, что происходит в технологическом контуре». Не «сколько средств защиты куплено», а «видим ли мы отклонения и можем ли принять решение без риска для производства».
Самый честный вопрос, который руководитель может задать своей команде: сколько времени проходит между изменением в АСУ ТП и моментом, когда об этом узнает служба безопасности. Если ответа нет, отчет о защищенности держится на предположениях.
«Для руководителя показательнее не количество найденных уязвимостей, а доля активов с назначенным владельцем, число несогласованных соединений и скорость, с которой команда узнает об изменениях в технологическом контуре. Если предприятие не может ответить, когда в АСУ ТП появилось новое взаимодействие и кто его согласовал, говорить о доказуемой защищенности преждевременно», - подчеркивает Ольга Луценко, ведущий эксперт UDV Group.
Здесь же становится понятна роль владельца процесса. Оценкой защищенности не может управлять только ИБ-служба. Она задает требования и методы контроля, но не всегда понимает допустимость действий для оборудования. Специалисты АСУ ТП знают технологический процесс, но могут не видеть ИБ-рисков. ИТ обеспечивает инфраструктуру, но не отвечает за последствия остановки производства. Поэтому владельцем процесса должен быть руководитель, отвечающий за технологический актив и последствия его простоя: технический директор, главный инженер или руководитель производства.
Без такого распределения ответственности ИБ остается без доступа к реальной системе, а производство - без понятной оценки риска.
Проверка должна идти вместе с эксплуатацией
Старый подход к проверкам строился вокруг подготовки к конкретной дате. Собрали документы, актуализировали модель угроз, подготовили акты, провели обследование, закрыли замечания. Но для современной АСУ ТП этого мало. Изменения происходят постоянно, значит, защищенность тоже нужно подтверждать постоянно.
Проект изменений в приказы ФСТЭК №235 и №239 как раз развивает эту логику. Он предусматривает регулярный расчет показателей защищенности и зрелости. На момент подготовки исходной статьи документ оставался проектом, а планируемой датой вступления в силу было указано 1 сентября 2026 года.
Для предприятий это важный сигнал. Доказуемая защищенность будет все меньше похожа на разовый отчет и все больше - на управляемый процесс. Нужно собирать данные об изменениях, доступах, работе мер защиты, состоянии активов и отклонениях уже в ходе эксплуатации, а не восстанавливать картину задним числом перед проверкой.
Иначе организация снова окажется в ситуации, где документы выглядят убедительно, но не отвечают на простые вопросы: кто подключался, зачем был открыт порт, почему правило межсетевого экрана осталось после пусконаладки, когда появился новый узел и как это повлияло на модель угроз.
АСУ ТП нужно не сканировать, а понимать
Промышленная безопасность в 2026 году все меньше похожа на формальное выполнение перечня мер. Предприятию уже недостаточно показать, что документы есть, средства защиты установлены, а технологическая сеть «изолирована». Нужно доказать, что реальное состояние АСУ ТП известно, изменения контролируются, удаленный доступ управляется, а отклонения выявляются без риска для производства.
Главная сложность в том, что АСУ ТП нельзя проверять грубыми методами офисной ИТ-инфраструктуры. Здесь цена ошибки выше, жизненный цикл оборудования длиннее, протоколы специфичнее, а последствия сбоя физически ощутимы. Поэтому зрелая проверка начинается с видимости сети, сопоставления фактических связей с документами и осторожного выбора методов оценки.
ФСТЭК идет не просто в документы. ФСТЭК идет в цех, где важна не декларация, а способность предприятия объяснить, что реально происходит с технологическим контуром. И если организация не видит свою АСУ ТП без опасного вмешательства в процесс, она не управляет защищенностью, а только надеется, что старая схема все еще соответствует реальности.
