UDV Group: четыре байта могут показать, изменилась ли программа ПЛК
На многих российских предприятиях контроллеры Siemens S7-300 и S7-400 еще долго будут частью действующей промышленной инфраструктуры. Они управляют энергоблоками, насосными, химическими производствами, металлургией и другими критичными участками. При этом вендор ушел с российского рынка, официальные обновления и патчи недоступны, а сами линейки постепенно выводятся из жизненного цикла.
Для CISO и главного инженера в такой ситуации важен не только вопрос замены оборудования. Есть более срочная практическая задача: понять, соответствует ли программа, которая сейчас реально работает на контроллере, утвержденной версии проекта. Если ответ нельзя получить быстро и доказательно, предприятие теряет контроль над одной из самых чувствительных частей АСУ ТП — логикой, которая управляет технологическим процессом.
Мы в UDV Group считаем, что для парка S7-300/400 первичный контроль целостности должен начинаться с того, что уже доступно в самой экосистеме Step7 Classic. Контроллер хранит короткие контрольные суммы аппаратной конфигурации и пользовательской программы. Это всего несколько байт, но они позволяют ответить на базовый вопрос: программа в ПЛК та же, что была принята как эталонная, или уже нет.
Если контрольные суммы проекта и контроллера совпадают, это признак соответствия утвержденной версии. Если расходятся, это повод разбираться, что изменилось, когда, кем и на каком основании. Такой индикатор не требует остановки процесса, не нагружает канал и может сниматься с работающего контроллера по расписанию. Для устаревающего парка без вендорской поддержки это часто становится самым доступным способом заметить изменение на уровне ПЛК.
Но checksum нельзя воспринимать как полноценную систему контроля целостности. Это индикатор, а не расследование. Он показывает, что программа или конфигурация отличаются от эталона, но не объясняет, почему это произошло и безопасно ли изменение для производства. Если вокруг него не построить регламент, четыре байта останутся просто числом на экране.
Главная ошибка — ожидать от контрольной суммы того, чего она не показывает. В S7-300/400 checksum чувствителен к программе и конфигурации, но не к каждому изменению текущих значений в рабочей памяти. Если инженер онлайн изменит значение переменной через Monitor/Modify Variables, контрольная сумма ПЛК не поменяется. Это нормальное поведение: значения переменных отражают живой процесс и могут меняться постоянно. Если бы checksum реагировал на каждое такое изменение, он потерял бы смысл.
Для ИБ это важное ограничение. Checksum не покажет, что оператор или инженер изменил уставку прямо на работающем ПЛК. Такой риск нужно закрывать другими средствами: журналами SCADA, разграничением прав, регламентом изменения уставок и контролем действий пользователей. Иначе предприятие будет уверено, что логика неизменна, но не увидит изменение параметра, который влияет на режим оборудования.
Есть и обратная ситуация. Если инженер изменит Actual Value в проекте на инженерной станции и сохранит блок, контрольная сумма проекта изменится, хотя в ПЛК ничего не загружалось. С точки зрения среды разработки это уже изменение проекта. Для мониторинга это может выглядеть как расхождение с контроллером, но не обязательно является инцидентом. Это означает, что эталон и фактическое состояние разошлись и такой разрыв нужно фиксировать в журнале работ.
Еще одна тонкость связана с выгрузкой данных. Upload одного блока и Upload всей станции ведут себя по-разному. При выгрузке отдельного DB среда Step7 может подтянуть текущие значения из рабочей памяти, из-за чего контрольная сумма проекта на инженерной станции изменится. При полной выгрузке станции такой эффект может не проявиться. Для CISO практический вывод простой: событие «инженер снял бэкап» нельзя выводить только из показаний checksum. Его нужно фиксировать отдельным регламентом.
Причина этих особенностей — архитектура памяти S7-300/400. В контроллере есть загрузочная память, рабочая память и отдельно проект на инженерной станции. Программа исполняется из рабочей памяти, проект хранится в инженерной среде, а checksum считается по загрузочной памяти. Поэтому он хорошо показывает изменение загруженной программы или конфигурации, но не отражает всю динамику текущих технологических значений.
Отдельный риск — загрузка блока данных из устаревшего проекта. Это уже не тонкость мониторинга, а сценарий с прямыми последствиями для производства. Когда инженер выполняет Download DB в ПЛК, в рабочую память вместе с блоком могут попасть значения переменных из офлайн-проекта. Если проект давно не синхронизировался с реальным контроллером, он может содержать старые Actual Value.
В результате безобидная на вид операция «перезалить один блок» способна сбросить актуальные уставки температуры, давления, скорости, положения задвижек и других параметров к значениям многолетней давности. Для непрерывного производства это может привести к скачку технологических параметров, аварийной остановке, повреждению оборудования или прямому ущербу.
С точки зрения информационной безопасности это еще и возможный вектор атаки. Злоумышленник или внутренний нарушитель может загрузить «правильно выглядящий» блок с подмененными Actual Value и вывести процесс из штатного режима, не меняя очевидную логику программы. Внешне это будет выглядеть как легитимный Download, а без истории изменений и регламента контроля выяснить причину будет трудно.
Поэтому перед любой загрузкой DB на действующий ПЛК критично убеждаться, что проект на инженерной станции синхронизирован с актуальными рабочими значениями. Полагаться на старую копию из репозитория, сетевой папки или ноутбука инженера опасно. Для АСУ ТП это не вопрос аккуратности документации, а вопрос сохранения управляемого режима оборудования.
Мы в UDV Group считаем, что автоматизированное снятие checksum может стать первым слоем контроля для S7-300/400. Делать это вручную через Simatic Manager в промышленном масштабе неудобно. Контроллеры позволяют получать контрольные суммы по сети через S7COMM запросом Read SZL. Это дает возможность снимать значения по расписанию, сравнивать их с эталоном и быстро видеть расхождения по парку ПЛК.
Но автоматизация должна начинаться не со скрипта, а с порядка работы. Сначала нужно провести инвентаризацию: какие S7-300 и S7-400 работают на объекте, какие версии CPU и прошивок используются, где хранятся эталонные проекты и кто имеет доступ к загрузке. Без этого мониторинг будет собирать данные, но предприятие не поймет, к каким активам они относятся и кто отвечает за разбор отклонений.
Следующий шаг — синхронизация эталонов. Перед фиксацией контрольных значений нужно убедиться, что проекты в репозитории действительно соответствуют состоянию контроллеров. На многих предприятиях эталонный проект последний раз обновлялся при вводе объекта в эксплуатацию. После этого могли быть пусконаладка, ремонты, доработки подрядчиков, изменения уставок и локальные правки. Если такой проект принять за эталон, система будет сравнивать ПЛК не с реальностью, а с устаревшей версией прошлого.
Третий шаг — фиксация контрольных сумм в управляемом хранилище. Эталонные значения нельзя держать в файле на диске одного инженера. Они должны храниться в системе с контролируемым доступом, историей изменений и понятной ответственностью. Иначе контроль целостности сам будет зависеть от локальных архивов и человеческой памяти.
Четвертый шаг — регламент реакции. Нужно заранее определить, какие изменения проекта считаются легитимными, как они согласуются, кто фиксирует новую контрольную сумму, кто расследует неизвестное расхождение и в какой срок. Если checksum изменился, команда должна не спорить, что это значит, а действовать по заранее описанному сценарию.
Для CISO важно правильно определить место checksum в общей архитектуре защиты. Это не замена контролю версий проектов ПЛК, не замена журналам SCADA, не замена управлению доступом и не замена расследованию. Это легкий сенсор первичного изменения, который помогает быстро понять, что программа или конфигурация контроллера больше не совпадает с эталоном.
Его ценность особенно высока на старом парке, где нет полноценной поддержки вендора, а замена контроллеров невозможна быстро. В таких условиях предприятие должно хотя бы знать, изменилась ли логика, которая управляет оборудованием. Без этого любой сбой, отклонение процесса или подозрение на вмешательство превращаются в ручной поиск по инженерным станциям, архивам и памяти специалистов.
Для нас в UDV Group главный вывод такой: контрольная сумма S7-300/400 не решает все задачи защиты АСУ ТП, но дает доказуемую точку входа в контроль целостности. Она помогает ответить на первый вопрос: программа в контроллере та же, что была утверждена, или нет. Дальше должны работать процессы — журнал изменений, контроль доступа, синхронизация эталонов, анализ причин расхождения и безопасное восстановление.
Если предприятие не знает, где хранятся эталонные проекты, кто имеет право загружать изменения, как фиксируются легитимные правки и что делать при расхождении checksum, снимать контрольную сумму почти бесполезно. Если эти ответы есть, четыре байта становятся первой линией контроля логики ПЛК, работающего без поддержки вендора.
