В АСУ ТП атака может выглядеть как работа инженера

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

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

Мы в UDV Group видим, что именно это делает Living-off-the-Land особенно опасным для АСУ ТП. Атакующий не обязательно приносит в инфраструктуру новый исполняемый файл. Он использует то, что уже есть в промышленной сети: учетные записи инженеров, RDP, VPN, PowerShell, WMI, диагностические утилиты, промышленные протоколы, инженерные станции и доверенные подключения подрядчиков.

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

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

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

Сигнатурная защита хорошо работает против известного. Отказываться от нее нельзя. Но Living-off-the-Land проходит мимо этой логики, потому что не всегда содержит вредоносный файл, новый хеш или очевидно запрещенное действие. Если авторизованный пользователь отправил команду «стоп», сигнатура видит разрешенный пакет. Она не понимает, должен ли этот пользователь останавливать этот механизм именно сейчас.

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

Арсенал такой атаки выглядит почти буднично. Промышленные протоколы Modbus, S7 и другие содержат штатные команды чтения, записи, запуска, остановки и изменения параметров. RDP, SSH и VPN нужны для распределенных объектов и удаленного обслуживания. Ping, трассировка и сканирование помогают строить карту сети. Учетные записи подрядчиков и старые технические аккаунты дают возможность двигаться почти без шума.

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

Мы в UDV Group считаем, что в таких условиях центр тяжести нужно переносить с поиска вредоносного файла на анализ поведения и промышленного трафика. Решения класса NTA для OT-сред должны видеть не только адреса и соединения, но и смысл технологического обмена: какая команда прошла, было ли это чтение, запись, запуск, остановка, перезагрузка или изменение параметра.

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

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

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

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

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

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

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

Для нас в UDV Group главный вывод такой: в АСУ ТП нельзя строить защиту только вокруг сигнатур. Они нужны, но не закрывают сценарии, где атакующий действует чужими учетными данными и штатными инструментами. Когда атака почти не отличается от повседневной работы, решающими становятся контекст, история взаимодействий и понимание технологического процесса.

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

Главный вопрос для предприятия простой: известно ли, что на самом деле происходит внутри промышленной сети в обычный рабочий день. Кто подключается, какие команды отправляет, какие изменения вносит и соответствует ли это норме. Без ответа на этот вопрос Living-off-the-Land остается почти невидимой атакой: формально все разрешено, но производство уже может быть под чужим управлением.