Подрядчик ушел, ПЛК изменился: почему заводу мало журнала доступа

На промышленном объекте все может выглядеть правильно.

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

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

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

Подрядчик уже внутри модели угроз

В офисной ИТ-инфраструктуре подрядчик чаще воспринимается как пользователь с временным доступом. Его можно пустить по заявке, ограничить права, записать действия, закрыть учетную запись после работ. В промышленном контуре этого мало.

Подрядчик может загрузить проект в контроллер, обновить библиотеку, поменять уставки, изменить обмен со SCADA, подключить шлюз к старой линии, открыть удаленный сервисный канал или привезти инженерный ноутбук, который до этого использовался на других объектах. Все это может происходить штатно, в согласованное окно и с разрешения предприятия.

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

«В АСУ ТП подрядчика нужно рассматривать не как внешнего посетителя, а как участника изменения технологической логики. Он заходит легально, работает штатными инструментами и может менять проект ПЛК, параметры, библиотеки или обмен со SCADA. Поэтому для предприятия критичен не только факт допуска, а технически проверяемый результат: что именно изменилось и к какому состоянию можно вернуться», - говорит Владислав Ганжа, директор лаборатории кибербезопасности UDV Group.

Импортозамещение усилило этот риск. На одной площадке могут одновременно поддерживать старое оборудование Siemens, Schneider Electric, Rockwell Automation или ABB, внедрять российские ПЛК, настраивать переходные шлюзы и дорабатывать интеграции между старым и новым контуром. У каждой команды свои проекты, библиотеки, инженерные станции и понимание того, какая версия сейчас актуальна.

Чем больше таких вмешательств, тем труднее восстановить цепочку: кто внес правку, зачем она была нужна, когда ее загрузили и почему после нее система начала работать иначе.

Проект ПЛК стал объектом атаки

Раньше проект контроллера часто воспринимался как рабочий файл инженера. Его хранили на инженерной станции, у подрядчика, в сетевой папке, на ноутбуке или в архиве проекта. Главное, чтобы линия работала. Сейчас такой подход опасен.

MITRE добавила в ATT&CK for ICS подтехнику T0873.001 - Siemens Project File Format. Она описывает заражение проектов Siemens Step 7 и WinCC с последующей загрузкой в ПЛК штатными средствами разработки. Для промышленного рынка это важный сигнал: атакующий может работать не только с вредоносным файлом или сетевым доступом, но и с самим инженерным проектом.

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

Именно поэтому одного VPN-журнала, заявки и наряда недостаточно. Они показывают, что человек работал в контуре. Но не доказывают, что после его работы система находится в ожидаемом и проверенном состоянии.

На предприятии может быть три версии одного ПЛК

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

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

Здесь часто возникает опасная иллюзия: если программа есть в ПЛК, значит, ее можно считать обратно и получить полноценный проект. На практике все зависит от платформы и настроек загрузки. В CODESYS редактируемый проект можно восстановить только при наличии исходного архива, который отдельно сохраняется на устройстве. Если его не загрузили, в контроллере останется исполняемое приложение, но не полный инженерный проект.

Похожая логика есть и у других платформ. Для Schneider Electric Modicon восстановление редактируемого проекта зависит от того, были ли сохранены данные, позволяющие считать его из контроллера. В TIA Portal программу S7-1500 можно загрузить из контроллера, но это не всегда означает получение полного исходного проекта со всеми инженерными артефактами. Для российских ПЛК на базе CODESYS, ISaGRAF, MasterSCADA 4D и других платформ состав такого комплекта тоже будет отличаться.

Файл с названием final или project_last не является резервной копией в эксплуатационном смысле. Для восстановления нужен проверенный комплект: проект, версия среды разработки, компилятор, библиотеки, профили устройств, прошивки, аппаратные ревизии модулей и значимые сетевые параметры.

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

Журнал доступа не отвечает на главный вопрос

В промышленной среде многие изменения выглядят обычной работой инженера. Загрузка блоков. Online change. Запись параметров. Замена рецептов. Обновление прошивки. Корректировка обмена. Для средств защиты это может быть разрешенная сессия, а для производства - изменение поведения оборудования.

Классическая SIEM в такой ситуации увидит только часть картины. Она может зафиксировать вход через VPN, подключение к терминальному серверу, отдельные сетевые события и логи межсетевого экрана. Но из этих данных само по себе не следует, какой блок был изменен, какая библиотека заменена, какая уставка переписана и совпадает ли итоговая конфигурация с согласованной версией.

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

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

Везде логика одна: если предприятие не видит результат изменения, оно фактически доверяет подрядчику по умолчанию.

Наряд разрешает работу, но не подтверждает результат

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

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

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

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

После пусконаладки важно закрыть не только производственную задачу, но и все временные изменения, которые появились ради нее. Новую версию сравнивают с исходной. Правки сопоставляют с заданием. Временные учетные записи блокируют. Лишние правила удаляют. Общие пароли меняют. Это должно быть частью закрытия заявки, а не отдельной просьбой ИБ «посмотреть потом».

Приемка не может быть задачей одного инженера

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

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

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

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

Эталон - это то, что можно загрузить

После приемки остается главный вопрос: к какому состоянию предприятие сможет вернуться, если после работ появится сбой. Здесь начинается разница между архивом и эталоном.

Архив - это папка с файлами. Эталон - это проверенный комплект, из которого систему действительно можно восстановить на установленном оборудовании. В него входят проект, среда разработки, компилятор, библиотеки, профили устройств, прошивки, аппаратные ревизии модулей, значимые сетевые параметры и предыдущие подтвержденные версии для критичных элементов.

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

«Эталонная версия ПЛК - это не файл в защищенной папке и не архив с названием final. Это проверенный комплект, из которого систему действительно можно восстановить: проект, инженерная среда, компилятор, библиотеки, прошивки, профили устройств, аппаратные ревизии и критичные параметры. Если этот комплект не проверен, предприятие хранит не план восстановления, а надежду», - подчеркивает Владислав Ганжа, директор лаборатории кибербезопасности UDV Group.

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

Контроль подрядчика - это контроль изменений

Главная ошибка - воспринимать подрядчика как отдельный внешний риск. Опасен не сам внешний специалист. Опасна ситуация, когда его легитимный доступ не оставляет после себя технически проверяемого результата.

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

Тогда работа подрядчика перестает быть черным ящиком. Предприятие понимает, какая правка была ожидаемой, какая требует объяснения и где находится подтвержденная версия для восстановления.

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

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

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

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

Контроль подрядчиков в АСУ ТП - это не недоверие к внешним специалистам. Это отказ от доверия по умолчанию там, где легитимное действие может изменить физический процесс.

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

Для завода это и есть настоящая управляемость подрядных работ: не просто знать, кто пришел в цех, а понимать, что он оставил после себя в контроллере.