UDV Group: подрядчик в АСУ ТП меняет не файлы, а технологическую логику
Работы подрядчика в АСУ ТП часто выглядят как обычная производственная задача. Предприятие меняет часть системы, ставит новый ПЛК, дорабатывает проект под другое оборудование, подключает шлюз к старой линии или обновляет обмен со SCADA. Есть заявка, согласованное окно, допуск на объект, пусконаладка, испытания и акт выполненных работ. Формально процесс закрыт.
Проблема появляется позже, когда оборудование начинает вести себя не так, как ожидали технологи. В этот момент журнал доступа уже не дает нужного ответа. Он показывает, кто и когда заходил в контур, но не объясняет, какая версия проекта была загружена в контроллер, какие блоки изменились, какие параметры переписали, чем итоговая конфигурация отличается от исходной и есть ли состояние, к которому можно безопасно вернуться.
Мы в UDV Group считаем, что подрядчика в АСУ ТП нужно рассматривать не как внешнего исполнителя, а как часть цепочки поставки и управления изменениями. Он входит в технологический контур легально, знает архитектуру объекта, использует инженерную среду и получает возможность менять логику, от которой зависит физический процесс. Ошибка с версией проекта, зараженный файл, забытая учетная запись или временный канал удаленного доступа могут выглядеть для средств защиты как штатная пусконаладка.
В 2026 году этот риск получил формальное описание сразу в двух плоскостях. В методических материалах ФСТЭК отдельно описаны меры контроля при работе с подрядчиками: доступ по заявке, минимально необходимые права, мониторинг действий и проверка загружаемых файлов. Почти одновременно MITRE добавила в ATT&CK for ICS подтехнику T0873.001 — Siemens Project File Format, которая описывает заражение проектов Siemens Step 7 и WinCC с последующей загрузкой в ПЛК штатными средствами разработки.
Для CISO это важный сигнал. Проект контроллера больше нельзя считать обычным рабочим файлом инженера или подрядчика. Это самостоятельный объект атаки. Через него можно повлиять на программу ПЛК, параметры, библиотеки, обмен со SCADA и итоговое поведение оборудования. Если такой файл проходит в контур без проверки, предприятие фактически доверяет не только человеку, но и всей среде, из которой он принес проект.
Поэтому вопрос для промышленной компании звучит иначе: она контролирует подрядчика как посетителя объекта или как участника изменения технологической логики. Если речь только о допуске, достаточно договора, заявки, наряда и записи в журнале. Если подрядчик меняет проект ПЛК, этого мало. Нужны эталонные версии проектов, контроль изменений и понятный порядок приемки новой конфигурации.
На практике подрядный риск часто начинается с обычной сервисной задачи. Инженер подключает ноутбук, который до этого использовался на других объектах, получает временную учетную запись, просит открыть дополнительные сетевые доступы, запускает ПО удаленного администрирования или подключает модем для диагностики. Работы завершены, линия принята, акт подписан. Но временное правило на межсетевом экране, учетная запись или канал удаленной поддержки могут остаться в контуре уже после ухода подрядчика.
Импортозамещение усиливает этот риск. На одной площадке могут параллельно сопровождаться Siemens, Schneider Electric, Rockwell Automation, ABB, отечественные ПЛК и переходные шлюзы между старым и новым оборудованием. У каждой команды свои проекты, библиотеки, инженерные станции и представление о том, какая версия сейчас актуальна. Чем больше таких вмешательств в действующую систему, тем труднее потом восстановить цепочку: кто внес правку, зачем она была нужна и почему после нее система стала вести себя иначе.
Для регулируемых объектов это уже не только эксплуатационная проблема. 187-ФЗ, приказы ФСТЭК № 239 и № 31 требуют управлять доступом и конфигурацией, согласовывать изменения, оценивать их последствия и фиксировать результат. Указ № 250 закрепляет ответственность за информационную безопасность на уровне руководителя организации. Выполнение работ можно передать интегратору, но ответственность за то, что осталось в технологическом контуре после этих работ, остается у предприятия.
Если действия подрядчика привели к компьютерному инциденту, реагировать и взаимодействовать с ГосСОПКА также должен владелец объекта. Договор и NDA помогут разбирать ответственность сторон после события, но не восстановят техническую картину. Для восстановления нужны другие данные: что именно изменилось в контроллере, где предыдущая рабочая версия и можно ли безопасно к ней вернуться.
Первое место, где проблема проявляется особенно остро, — версии проектов ПЛК. У предприятия может быть один проект на инженерной станции, у подрядчика — своя рабочая копия, а в контроллере — третья версия программы. Пока линия работает штатно, расхождение может не беспокоить. При сбое оно превращается в главный вопрос: какую версию считать рабочей и из чего восстанавливать систему.
Опасная иллюзия состоит в том, что программу всегда можно считать из контроллера и получить полноценный инженерный проект. На практике это зависит от платформы, настроек загрузки и того, какие данные были сохранены вместе с приложением. В CODESYS редактируемый проект можно восстановить только при наличии исходного архива, который должен быть отдельно сохранен на устройстве. Если этого не сделали, в ПЛК останется исполняемое приложение, но не комплект, который можно открыть, проверить и сопровождать дальше.
У других платформ логика тоже имеет ограничения. Online change может передавать в контроллер только измененные части программы без полной загрузки проекта и остановки оборудования. Для Schneider Electric Modicon восстановление редактируемого проекта зависит от того, были ли сохранены данные, позволяющие считать проект и открыть его в инженерной среде. В TIA Portal загрузка программы S7-1500 из контроллера не гарантирует получение полного исходного проекта со всеми инженерными артефактами, сертификатами и зависимостями.
Поэтому файл с названием final или project_last нельзя считать резервной копией в эксплуатационном смысле. Для восстановления может понадобиться точная версия среды разработки, компилятор, набор библиотек, профили устройств, прошивки, аппаратные ревизии модулей и пакеты целевой платформы. Если этот комплект ни разу не проверяли на совместимость, откат существует только в документах.
Для мониторинга действия подрядчика тоже не всегда выглядят подозрительно. Загрузка блоков, online change, запись параметров, замена рецептов или обновление прошивки для инженера являются обычной работой. Но для производства это может означать изменение логики, аварийной уставки, библиотеки или обмена со SCADA. Обычная корпоративная SIEM увидит VPN-сессию, вход на терминальный сервер или сетевое событие, но не объяснит, что именно поменялось в программе контроллера.
Чтобы восстановить картину, нужно сопоставлять журналы инженерного ПО, операции в сети, фактическую конфигурацию устройства и утвержденную версию проекта. Только тогда становится понятно, было ли изменение ожидаемым, связано ли оно с заявкой, совпадает ли с результатами испытаний и не осталось ли после работ лишних доступов.
Наряд-допуск, заявка и журнал работ подтверждают основание для присутствия подрядчика. Но они не подтверждают результат. Запись «скорректирована программа управления» может скрывать изменение одного коэффициента, правку аварийной логики, замену библиотеки или полную загрузку проекта. Для CISO важна не формулировка в акте, а технически проверяемое состояние после работ.
Контроль должен начинаться до подключения подрядчика. Сначала фиксируется фактическое состояние контроллера: не файл из папки инженера, а программа, конфигурация и критичные параметры, которые реально находятся на устройстве. После этого подрядчик получает доступ на ограниченный срок и только к тем узлам, которые указаны в заявке.
Само подключение должно быть управляемым. Лучше, когда внешний специалист работает через инженерную станцию или терминальный сервер внутри технологического контура. Так предприятие контролирует набор программ, сетевые направления и файлы, которые попадают в систему. Если без ноутбука подрядчика не обойтись, устройство нужно проверить, зарегистрировать и ограничить доступ конкретными адресами и временем работ.
После пусконаладки нужно закрывать не только производственную задачу, но и временные изменения, которые появились ради нее. Новую версию сравнивают с исходной, правки сопоставляют с заданием, временные учетные записи блокируют, лишние правила удаляют, общие пароли меняют. Это должно быть частью закрытия заявки, а не отдельной просьбой службы ИБ «посмотреть потом».
Приемка результата не должна оставаться задачей одного инженера по автоматизации. Он подтвердит, что линия выполняет производственную функцию, но может не увидеть дополнительный сетевой доступ, изменение прав или оставленный сервисный канал. Инженер АСУ ТП, владелец технологической системы, сетевая служба и ИБ должны смотреть на итоговое состояние вместе.
При этом контроль не должен превращаться в бюрократию вокруг каждой операторской уставки. Регулярно изменяемые параметры нужно отделять от основной логики, аварийных блокировок, конфигурации обмена, прошивок и настроек удаленного доступа. Проверять нужно не каждое движение в системе, а те изменения, которые могут повлиять на безопасность, устойчивость и восстановление технологического процесса.
Эталонная версия после работ — это не файл в защищенной папке и не архив с названием final. Это проверенный комплект, из которого систему действительно можно восстановить на установленном оборудовании: проект, среда разработки, компилятор, библиотеки, профили устройств, прошивки, аппаратные ревизии модулей и значимые сетевые параметры. Для критичных элементов отдельно фиксируются контрольные суммы и предыдущая подтвержденная версия.
Проект становится эталоном только после сравнения, испытаний и приемки. Если подрядчик внес согласованную правку, она должна завершиться не только запуском линии, но и обновлением проверенного комплекта. Иначе предприятие принимает производственный результат, но не получает точку восстановления.
Мы в UDV Group считаем, что начинать можно не со всего производства. Достаточно выбрать одну критичную линию, собрать имеющиеся проекты, считать фактические конфигурации контроллеров и проверить, можно ли восстановить систему из сохраненного комплекта. Обычно уже на этом этапе находятся несовпадающие версии, отсутствующие библиотеки, проекты без владельцев и резервные копии, которые никто ни разу не пробовал загружать.
После этого каждое изменение нужно связывать с заявкой, исполнителем, временем доступа, сравнением версий и результатом испытаний. Тогда работа подрядчика перестает быть черным ящиком. Предприятие видит, какая правка была ожидаемой, какая требует объяснения и к какому состоянию можно вернуться без импровизации на остановленном оборудовании.
Для нас в UDV Group главный вывод такой: опасен не сам подрядчик, а доверие к его действиям без технически проверяемого результата. Легитимный доступ в АСУ ТП не должен оставлять после себя неопределенность. Если после работ нельзя доказать, что именно изменилось, какие временные доступы закрыты и какая версия проекта теперь является эталонной, предприятие принимает на себя скрытый производственный риск.
CISO важно смотреть на подрядные работы в АСУ ТП как на часть управления киберустойчивостью. Пока программная логика воспринимается как приложение к оборудованию, восстановление зависит от того, найдется ли правильный проект, нужная среда разработки и специалист, который помнит историю изменений. Когда проекты, конфигурации, доступы и результаты работ фиксируются как управляемые активы, подрядчик становится не слепой зоной, а контролируемым участником жизненного цикла промышленной системы.
