Когда говорят “нас атаковали”, обычно ищут дырку в firewall. На практике вход часто проще: подрядчик с доступом, инженерный ноутбук с устаревшим софтом, обновление “с проверенного сайта”, которое никто не верифицировал. Для OT это особенно болезненно: вредонос попадает не в офисный принтер, а в контур, где он может остановить линию.
Эта статья про supply chain риск в промышленной автоматизации: от внешних интеграторов до обновлений инженерных инструментов.
Короткий ответ
В OT цепочка поставок ПО - это не только вендор SCADA. Это подрядчики, их ноутбуки, плагины, драйверы, пакеты обновлений и удалённые каналы поддержки. Защита строится на трёх опорах: доверяй, но проверяй обновления, минимизируй и сегментируй доступ подрядчиков, веди прозрачный процесс допуска стороннего ПО через чек-лист и тестовый контур. Без этого один компрометированный поставщик может обойти классическую периметровую защиту.
Почему OT уязвимее к supply chain атакам, чем кажется
В IT можно быстро переустановить сервис и откатить релиз. В OT каждое вмешательство связано с окнами работ, техпроцессом и риском простоя. Поэтому уязвимый инструмент может жить годами “потому что не трогаем, работает”.
Вторая проблема - доверие “по умолчанию” к сервисным каналам. Интегратор подключается к HMI-серверу, ставит патч драйвера, оставляет временный агент, и это часто проходит без формального ревью состава ПО.
Третья - длинный хвост legacy: старые версии ОС, неподдерживаемые SDK, инженерные станции без EDR из-за опасения “сломает проект”. В таком контуре supply chain атака имеет высокий шанс закрепиться.
Основные векторы атаки через цепочку поставок
Компрометация поставщика ПО. Классический сценарий SolarWinds-типа: вредонос попадает в подписанное обновление, а дальше распространяется через легитимный канал.
Компрометация MSP/интегратора. Сценарий Kaseya-типа: через платформу удалённого управления атакующий получает доступ сразу к множеству клиентов.
Компрометация updater-механизма или сертификата. Сценарии Asus Live Update и похожие показывают, что подпись файла сама по себе не всегда гарантирует безопасность, если скомпрометирована инфраструктура выпуска.
Плагины и сторонние библиотеки инженерного ПО. Иногда в OT попадает “маленький полезный тул”, который тянет небезопасные зависимости и становится точкой входа.
Подрядчик с чрезмерными правами. Один VPN-аккаунт “на всех”, постоянный доступ без срока действия, общие пароли - и атака получает готовый коридор в технологический сегмент.
Инженерные инструменты: отдельная зона риска
Инженерная станция в OT часто имеет доступ сразу к ПЛК, HMI, historian и иногда к домену. Это “королевский” актив, но к нему относятся как к обычному ноутбуку “для наладки”. Ошибки здесь типовые:
•установка неподписанных скриптов и драйверов “по инструкции из чата”;
•перенос проектов на USB без контроля источника;
•отключённые обновления ОС и защитных агентов “чтобы не мешало”;
•использование одной учётки администратора несколькими подрядчиками.
Такой профиль делает инженерный софт не просто инструментом, а носителем lateral movement в OT.
Проверка обновлений: что реально делать до установки
Минимум, который должен стать нормой:
1.Проверка источника: загрузка только из утверждённого репозитория или официального канала вендора.
2.Криптографическая верификация: подпись, checksum, сопоставление хэшей с доверенным источником.
3.Песочница/стенд: сначала установка в тестовом контуре с типичной конфигурацией объекта.
4.Наблюдение после установки: мониторинг аномальной сетевой активности и поведения процесса.
5.План отката: заранее подготовленный rollback, а не “если что, разберёмся ночью”.
Самая дорогая ошибка - ставить патч прямо в прод под давлением времени.
Управление доступом подрядчиков
Рабочая модель для OT:
•персональные учётки вместо “общего сервисного логина”;
•доступ по заявке, только на окно работ, с автозакрытием;
•jump-host в DMZ и запись сессий для разборов;
•MFA там, где это технически возможно;
•запрет прямого выхода подрядчика из OT в интернет.
Цель не “запретить подрядчиков”, а сделать их работу прозрачной и управляемой.
Реальные кейсы и практический вывод для OT
SolarWinds, Kaseya, Asus - разные по деталям, но одинаковые по уроку: доверенный канал может стать вектором атаки. Для завода это означает, что вопрос “этот пакет от нашего поставщика?” недостаточен. Нужен второй вопрос: “как мы проверяем пакет и кто отвечает за допуск в контур?”.
Чек-лист оценки риска стороннего ПО перед установкой в OT-контур
Перед допуском любого внешнего ПО пройдите короткий контроль:
•Происхождение: известен владелец продукта и официальный канал поставки.
•Подпись и хэш: файл подписан, хэш сверен с доверенным источником.
•SBOM/состав: понятны ключевые зависимости и их версии.
•Уязвимости: проверены CVE по версии продукта и критичным библиотекам.
•Совместимость: подтверждена работа с вашей версией SCADA/PLC tooling на стенде.
•Привилегии: ПО не требует избыточных прав локального администратора без обоснования.
•Сетевые требования: известны все исходящие/входящие соединения и порты.
•Логи и аудит: продукт пишет достаточные логи для расследования инцидентов.
•Откат: есть инструкция rollback и контрольная точка восстановления.
•Владелец риска: назначен ответственный за допуск и сопровождение ПО после установки.
Если три и более пункта “в серой зоне”, установка в прод должна быть отложена.
Где уместен СТАБУР
В проектах на базе СТАБУР supply chain риск закрывается не одной “волшебной коробкой”, а процессом: реестр допустимого ПО, стенд перед продом, контроль подрядчиков и журнал изменений через MOC. Это даёт управляемость даже в смешанном парке legacy и новых систем.
Заключение
Supply chain безопасность в OT - это дисциплина доверия. Подрядчики и обновления нужны, но они должны проходить через прозрачный фильтр: проверка, стенд, ограниченный доступ, откат. Побеждает не тот, кто “никого не пускает”, а тот, кто точно знает, что, когда и кем было установлено в технологический контур.
FAQ
Достаточно ли антивируса на инженерной станции?
Нет. Нужны ещё контроль доступа, сегментация, проверка обновлений и журналирование действий подрядчика.
Можно ли вообще отключить удалённый доступ подрядчиков?
Иногда можно, но чаще это тормозит поддержку. Лучше управляемый доступ через DMZ и короткие сессии.
Что важнее: подпись файла или тест на стенде?
И то и другое. Подпись снижает риск подмены, стенд проверяет влияние на вашу реальную архитектуру.
Нужен ли SBOM для каждого внешнего инструмента?
Для критичного ПО - да. Хотя бы базовый состав зависимостей сильно ускоряет реакцию на новые CVE.
Кто отвечает за решение “ставим/не ставим”?
Совместно: OT-владелец системы, ИБ и эксплуатация. Без явного владельца решение размывается и риск растёт.